Choosing a Language

I’ve decided to start a new series. I recently bought the book “Joel on Software” by Joel Spolsky. It is a collection of his blog posts. He still continues to produce more content today. Some of the articles in this book are a little dated but they seem to hold up to the test of time and continue to be highly regarded. I thought I would read through his book and provide my own commentary on his articles as they pertain to LabVIEW.

The first article in the book is titled: Choosing a Language. In this short article, Joel talks about various reasons why you might choose one programming language over another. He lists a few criteria and his choices of languages that best meet each criterion. Some of the criteria include speed, cross-platform, executable size, GUI Development, CLI development, and a few others. What I found interesting is that he ends with a couple of paragraphs about how syntax is one criterion he generally doesn’t care about. Text-based programmers may not care a whole lot about whether a language uses commas or semicolons, but I think a major reason a lot of developers reach for LabVIEW is its unique graphical syntax.

Why Choose LabVIEW?

The article got me thinking about why someone might choose LabVIEW over another language. I came up with a list of 4 reasons (in no particular order) of why someone might choose LabVIEW for a particular project. These are what I view as the strengths of LabVIEW.

  • Syntax – The main reason many people chose LabVIEW is the reason that Joel discards in his article – syntax.
    I think people chose LabVIEW’s graphical syntax for 2 main reasons:
    1. Engineers, LabVIEW’s main audience, tend to think graphically. We naturally draw flow charts and diagrams and so the graphical nature of LabVIEW is easily understood by engineers.
    2. Commas versus semicolons and square brackets versus braces, distract from solving the problem. In LabVIEW, we rarely have to worry about such mundane syntax problems. When programming in text, I often find myself using single quotes when I should have used doubles and those issues rarely seem to come up in LabVIEW. It’s refreshing.
  • Talking to Hardware – Talking to hardware is quite easy in LabVIEW particularly with NI hardware which of course integrates seamlessly.
  • Parallelism – Creating parallel threads in text-based languages can be cumbersome. In LabVIEW, it can be as simple as dropping another loop on a block diagram. No setting up threads or scheduling required.
  • Rapid Protoyping – In LabVIEW every VI has a front panel that acts as its user interface. This makes creating UIs quick, easy and intuitive. You can get a prototype up and running very quickly. There’s no separate compile step. Simply drop a few controls/indicators, quickly wire them up and press the run button. This reminds me very much of something like the REPL in Python, except with a builtin GUI.

Why Did You Choose LabVIEW?

Is there a reason that I am missing? If so please add it in the comments.

7 Comments on “Choosing a Language

  1. I think that finding useful, pre-defined code, is much simpler in LabVIEW. Suppose I have a signal and I want to do a Fast Fourier Transform on it. I search for FFT, drop a VI on my block diagram, wire up input and output and er … that’s it. It also gives me the confidence to go searching for something that I want but I don’t know where it might be. So I never feel “I want to do [standard mathematical process] but I don’t know how to do it.”

    • Hi Malcom
      I agree completely, a lot of libraries are immediately available in the profesional version already. But it takes time to explore although less time than to reinvent the solution.

  2. Right on the money, Sam. I think those would be my top four reasons as well. My fifth used to be discussed a lot, and you may recall that I tried to revive it a while ago. But it’s fallen so far out of discussion that at this point, it’s more of a gut feeling than a demonstrable characteristic: Speed of development. There is no question that I am MUCH faster at LV than with any text language, but that’s due mostly to my lack of current experience with text languages. I suspect, but can’t assert with evidence, that LabVIEW can be faster than most languages, when used within its domain. Curious what other peoples thoughts are on that.

  3. I agree Sam. These are definitely the main reasons I use LabVIEW for the majority of the projects I work on. But an additional would be language integration as you can incorporate code from c,c#, vb, etc into LabVIEW.

  4. Hi Sam, I agree, I have the same list πŸ˜‰

    like to add my 2$ct

    With a good programming language you can express yourself easily, there is almost a 1-to-1 link between the human language and the programming language counterpart. (that’s because the language was made by humans for humans!) It’s more than just being proficient in the LabVIEW environment (palettes, menus, dialogs, …) it’s a combination of knowing the basics and having a block diagram which provides a canvas where, like a painter, you can freely express, rearrange, organise and cleanup your thoughts/solution.
    With LabVIEW I tend to focus on the actual problem instead of the syntax/language/details to express the problem, the looks follows naturally (after some cleanup!)… LabVIEW gives me the expressiveness and the looks that allow me to focus on the problem. (and have fun doing your work!)
    And yes some programming constructs in LabVIEW do address high level functionality, so I do not need to worry about the details/implementation. The balance that NI has found seems just about right for me (except for express VI’s which I surely could do without, not the configuration part but the result πŸ˜‰

    • Martin,
      Good thoughts. A good programming language gets the syntax out of your way so that you can focus on solving the actual problem!

      My main disagreement with Express VIs is that they hide too much. The only way to see how they are configured is to open the configuration dialog box. I would much rather it was explicit on the block diagram. Also, as I think you are alluding to, if you ever click on the button to turn it into actual code, it is a complete mess.

  5. We are in agreement. Have the same β€˜ugchh’ reflex when looking at the code. Auto generated code / scripted is so not-elegant, it kinda hurts my eyes. It looks a bit like a 1.0 version hoping/begging to be upgraded to 2.0 πŸ™‚

Leave a Reply

Your email address will not be published. Required fields are marked *

*