When we talk about programming the LabWare LIMS, we have to be careful what we mean. The LabWare LIMS Smalltalk is NOT what we’re going to be using. Instead, think LabWare LIMS Basic.

The LabWare LIMS Smalltalk

The LabWare LIMS / ELN core system is actually written in Smalltalk. We don’t have access to change that and we wouldn’t want to. That is not what we do on LabWare implementation projects.

If you read our page about the LabWare LIMS, you’ll have read a bit about this, already.

The Labware LIMS Basic

When we program the LabWare system, we use LIMS Basic. It’s a proprietary language. That means that we can only use this language for this system. The purpose of this is to give the programmers functions that directly relate to programming this specific system.

For example, in a standard programming language, you’re not going to have built-in functions such as LogSample, which is just one example of the types of functions you’ll get in a proprietery language, such as LabWare LIMS Basic.

So, with the exception of instrument integration which uses the parsing scripts rather than LIMS Basic, or your database which will use whatever database tools that go with it, the programming will be done in LIMS Basic. We never use SmallTalk.

Back in that blog post about the event triggers and automation scripts, all that is going to be written with LabWare LIMS Basic.

What Brings This Up

Recruiters will sometimes mention the LabWare LIMS SmallTalk and ask for resources with that skill. When I question them, more, I come to find that that’s because their consulting requisition mentions SmallTalk. Notes to Customers and Consulting Companies: Never put LabWare LIMS SmallTalk in your consulting requisitions (well, unless you’re LabWare and looking for developers, that is).

Just one tiny bit of history: LabWare used to put out bits of SmallTalk code for special features. Customers would honestly sometimes hear about this and think they should be writing some LabWare LIMS SmallTalk code. But it’s been many, many years since LabWare has had this practice.

In General

In general, we don’t care what language was used to write a LIMS, ELN or LES. What we care about, and especially when you write your job reqs or look for consultants to work on your systems, is to mention the skills that the software vendor tells you you need in order to implement them. For LabWare LIMS, that would be LIMS Basic, never SmallTalk.

LabWare LIMS Basic Expert Needed?

So, if you need a LabWare LIMS Basic expert, feel free to contact me, right now. If you need someone who knows SmallTalk and is willing to try to hack your LabWare system with it, please move along…

Read More About the LabWare LIMS / ELN

2 Thoughts to “Labware LIMS Smalltalk – No!”

  1. Brian Meadows

    Let me say up front that I never worked on a project involving LIMS Basic.

    However, having seen both sides of the coin (programming team for a non-LIMS system which provided a proprietary language for users, and working on systems which offered an API) I have to say that I would have far more faith in a system which provided an API than one which forced you into a proprietary language. If you want to do something which isn’t covered in the LIMS design, then it’s generally easy if you have a detailed API, but otherwise you’re reduced to doing things like parsing reports to get at the data. I had to do one project involving the latter approach, and we were forever chasing problems which we tracked down to occasional spurious (usually) control characters which changed the format of the listing . Give me a choice and I’ll take writing my own code with calls to an API every day of the week.

    1. As a side comment on your response, Brian, I’ll add that quite a number of software vendors, LIMS and otherwise, now use REST or SOAP, for example.

Comments are closed.