People get into arguments about what programming language is best to use for laboratory software projects. Some people argue for C#, others for Java, and we get into heated discussions about which languages are “real” programming languages and which should be dropped to the bottom of a deep ocean. In the end, for most projects, it doesn’t matter.
Using the Most Common Tools
Some companies would like to use the most common tools for software development. The theory is that then there are more people in the marketplace with the right skills, and also that they’d be less expensive that true LIMS, ELN or LES programmers. If that’s the criteria for adding features to your system, you need to figure that out before you buy a system.
Instead, the best way to approach any of these systems is to ask what the common development tools are for the brand you purchased. If you purchased a LabWare LIMS / ELN, for example, you will use LIMS Basic for all your programming except possibly instrument parsing (and let’s not start a debate on whether that’s actually programming or not, right now) but my point is this – that’s the tool you need for that brand of software. Whether or not it’s a “real” language or one used solely as a proprietary tool, this is the language you need to use. That’s what’s supported by the vendor and that’s what the support people can help you with. That’s what their user community is using and on which they can share experience with you. Use something else and you’re on your own. Use something else and you’re avoiding all the things you paid the big bucks for (security, event triggers, etc.).
When You Have Choices
Then, we start talking about systems such as Thermo Fisher Scientific’s SampleManager LIMS / LES and there are just more choices. Their proprietery language is VGL and, while there is an effort to move away from VGL, if your team is working with VGL, has experience with VGL, and not at a skill level to learn something else, you should probably stick with VGL, at least for the time being – at least long-enough to decide whether you need a new strategy.
Along with that, while you could technically use many languages, since most people who aren’t using VGL are using C#, you should just use C#. It might seem hard to learn but that’s where most of the examples and experience come from. Use something else and you’re less likely to find people who have done something similar.
And then, if you have a small system that has no programming tools associated with it, you should ask your software vendor if they have recommendations. If they don’t and if you’re going to be developing programs, that’s the time to start having the discussions around whether you prefer one development language and toolset over another and why that would be. For example, if your area has lots of Java developers around, that might be your sole reason for using that tool.
Yet, the other factor is to see if you can find people with experience with laboratory software, if possible. So, a multitude of cheap and high-level resources isn’t the only factor you should consider. Using people with experience in the industry can actually save you money.
In the end, it doesn’t matter what chest-beating we programmers do regarding what’s the “best” and “real” and “most robust” tools to use. What matters is to develop something most easily supportable by the people who will be supporting it, such as the vendor’s Help Desk, the user community around the software you’ve purchased, and the internal people who will maintain and develop the system. Anything else is just a pie-in-the-sky discussion that we like to have to feel “real” and make ourselves relevant.