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:
- 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.
- 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 Prototyping – 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.