SampleManager: VGL Versus .NET

Volume IIEntry 58 of 67 in 20132 min read3 comments ↓

Written by Gloria Metrick on October 29, 2013. Published as written. It may not reflect how these systems work today.

In the SampleManager world, we love to talk about the .NET options. But, do we really use it?

For all the talking about .NET, the real truth of the matter is that legacy customers have a LOT of VGL code. And, when push comes to shove, it's easier to change the legacy VGL code than to rewrite entire programs. Customers talk about wanting to move to .NET but, as far as I've seen, are not willing to pay to rewrite their programs from VGL to .NET. That's not meant as a criticism, either. Customers have limited budgets and they are trying to use them to add features to their systems not to rework things that are already working.

The other is this -- while proprietary languages such as VGL were created for systems such as SampleManager in order to make it easier for non-programmers to learn to program them, the .NET code does not fall into that same category. Those languages are "real" programming languages. It's not that VGL doesn't benefit from being used by "real" programmers, too, just that it's somewhat easier to slide-by with lesser programming skills using languages such as VGL than it is with the .NET languages. In our industry, we now have many, many people programming these systems who are not programmers, which is true of other systems besides SampleManager, by the way.

Is this going to mean that we start seriously training more of our industry to be "real" programmers? No, I don't think that it does, actually. Our industry has not taken programming particularly seriously, in the past, and will probably not start, now, after all these years. I do feel sorry for the people who thought they would be modifying a few records and clicking a few buttons, but are suddenly struggling to figure out how to make a routine call and what kind of variable to pass into a program. But that's the situation we have created and, once again, not just with SampleManager but with our attitudes about programmers -- that we think we don't really need professional programmers and, as such, do not need to train our people on this skill.

Gloria Metrick
GeoMetrick Enterprises
http://www.GeoMetrick.com/

The conversation

3 comments from 2 people, February 21, 2014 to September 6, 2016. Gloria replied once.

February 21, 2014
Ian Cooper
On the SampleManager implementation that I'm currently involved in, we are doing a lot with .NET, especially around customizing the scheduler, some forms, and adding a background task to take all of the non-interactive label printing out of the timer queue. However, to be honest, this is the first time that I've ever been working on a project with any substantial .NET content.

For me, a big benefit to writing C# code rather than VGL is that we have a real development environment for C# (or VB.NET, if you're so inclined), including an intelligent text editor, project management tools, and a debugger that actually works. If you want, you can also use Microsoft Visual C# Express Edition, so there's no need to invest in the full Visual Studio suite to get most of the benefits.

But you're right, the industry doesn't take programming seriously, and it's a shame. SampleManager 11 replaces yet more old LTEs with .NET forms and offers incrementally greater customization (see, I'm using the right term here) with .NET. We need more people who cross over into the LIMS implementation roles from the IT and software development fields (like me) rather than laboratory operations (like many of my colleagues).
September 3, 2016
Karen
I came across this just now when googling VGL and disagree with some of the assumptions implicit in this blog post.

I am a chemist but have been coding on and off ever since I was in college in the 1970s

I did a lot of VGL programming back in the early 90's when SampleManager ran on VAXes and was accessed through dumb terminals. In fact back then I wrote a module to track equipment maintenance and calibration with a GUI (which was a pain using VT terminal commands!), including handling modular component instruments using a tree structure that I presented at a national Sample Manager user group meeting in Orlando.

I was at the point that I was directing and teaching the guy with an IT background from Fisons (who owned SampleManager at the time) some things about VGL.

Over the years I have done a lot of coding for use in the lab in Fortran, BASIC, Vax Datatrive, Vax PASCAL , LabView (which I hated) and in more recent years an XPlatform object oriented language that uses Basic like syntax and supports inheritance, class interfaces (instead of multiple inheritance), delegates etc... I have used other languages outside of work as well.

(BTW back in the stone age at the dawn of the microprocessor age when they though chemists should be able to build their won instruments I had to do some 6502 assembler for a course)

Basically I have been coding on and off for a very long time, mostly for use by others to help get things done... but have also sold code to those who make a living coding extending the capabilities of the the current language I use...

I say all that to show where I am coming from... I do take programing seriously and am reasonably adept at it.

That said I absolutely hate C based languages... Not because of any of the concepts but simply because of the syntax... It hurts my head to look at C based code...

I have a real problem with those that coding in anything but a C based language is not "real" coding...

To write good code in VGL (or any language) you need to know how maintainable code should be structured...

VGL abstracted you from a lot of housekeeping ... that is what made it possible to rapidly code solutions... Even huge ones like the one I wrote... That is always a virtue... These days more so than back then, with the processing power now available, there is no need to get into the the weeds...

Speed of development is more important than execution speed these days. BTW outside of back then VGL not being object oriented, the biggest potential issue was that IIRC it was not strongly typed. These days I prefer a strongly typed language, as it helps prevent bugs.

I've not seen SampleManger or VGL in the PC/.net era... So I don't know how VGL is hooked into the GUI ... I hope it is with event driven controls and that it is has been extended to be object oriented. If not I think they made a mistake.

With a good IDE that has thr ability to layout controls that can be access from VGL, and that has the VGL code in a platform independent layer above the OS, one could abstract out the complexity of .Net and so have have a lot of advantages in terms of speed of development for pros. It would also help insulate the specific LIMS implementation from underlying OS changes.

if it was set up that way, .Net IMO would only be needed for truly exceptional situations and would be best avoided.

BTW in my experience it is hard to get across the requirements for lab operations (particularly in R&D) to IT people with no Lab experience... it was because of issues with the usability of deliverables we got from our IT department, that, that i got involved in coding at work.
September 6, 2016
Gloria MetrickAuthor
Speed of development is no excuse for poor programming. Over the years, programmers will do absolutely ANYTHING to get out of properly structuring their code and documenting it. For example, back when we were using PASCAL, some programmers would insist that it didn't need comments because it was "self documenting" and it was no more true of that language than any other one, out there.

If companies want maintainability of their programs, they have to put the work into it to make them usable for the long term.

We talk much about how programs have a short shelf-life but we then use them for 20 years or so.

Comments are closed. This conversation is from 2013. Ask us to remove a comment

Working on the same problem in your lab?

Talk to a laboratory informatics scientist