Choosing A Software Language For A Project

By James McNally | Software Engineering

If you aren’t a software developer, I imagine that the concept of different software languages must look very strange. This article outlines the main decision points I go through when choosing a software language for a project.

Pure Language

In the purest sense, a software language defines a particular set of structures and grammar to write software.

While you might wonder why we need more than 1 for this – it is mostly about control vs productivity.

A low-level systems language like C will give you a lot of control – but it means you spend time micromanaging the software instead of solving the problem at hand. It also makes it easier to create certain types of bugs in the low level details.

A higher level language like LabVIEW or Python instead tends to offer higher productivity as a trade-off for less control.

Starter code in C
Starter Code in Python

When the problem is well understood, and performance isn’t critical; this is a valuable trade-off. The web is generally built on these higher-level languages because the issues are well understood, and you can create products so quickly.

The other factor to a language is a particular style or approach to describing a program in it. This style may suit specific applications, or some developers may have a preference for one over another.


Around the core language though there is an ecosystem of developers, training and software libraries. This ecosystem is what will often drive languages into particular application areas.

For example, Python as a pure language isn’t a natural choice for heavy number-crunching. But it has been heavily used in data science for years, and there are dozens of frameworks and hundreds of libraries to support this use case mean you often have to write less code and can find support easily. This ecosystem means it is now the dominant language in this area.

LabVIEW is all about interfacing to the physical world. Not because the language necessarily has an advantage in this area, but because of the broad ecosystem of drivers and interfaces, it can support.


The final factor I often consider is where it is going to run. The deployment target is another factor that can drive language choice (although the differences tend to be more subtle).

If you want to end up running on a microcontroller, then you probably need C or C++ to ensure you can support the hardware. For the web, Python and Javascript are common languages and are easy to deploy.

LabVIEW is excellent on the desktop or National Instruments hardware, but if you want to target other industrial equipment, you may have to look to other languages again.

So What Should You Use?

I’m afraid I’m still not going to give you a single right answer for this. Choosing a software language for a project depends on what your customer requires from your application. Many are interchangeable as well, and sometimes the right language is just the one that you and your developer are comfortable using. 

At Wiresmith Technology, I focus on a few languages:

  • LabVIEW – This is our primary language and covers 80% of what I do. For desktop or applications on NI hardware, it is productive and performant (and I have a lot of experience with it). I will utilise the C language to boost it’s performance if required (which is rare).
  • Javascript/Typescript – Javascript is a key language of the web, and I reach for this for web-based components in projects. This gives customers remotely accessible dashboards with modern designs.
  • Rust – This is a new addition that I’m very excited about using more. As a low-level language, I can use it to write high-performance code that can target embedded devices and desktop systems while being more productive and creating fewer bugs than C or C++. My use case right now is for embedded systems that aren’t on National Instruments hardware.
  • Python – This is also relatively new to me and probably the last one I will reach for in many cases. However, it is great for quickly developing automation scripts.

I hope that helps you understand what you must consider to make a decision (even if it doesn’t give an answer!). Feel free to post questions below or get in touch.


About the Author

I founded Wiresmith Technology to help engineers improve their systems and products with quality measurement systems. I'm a Certified LabVIEW Architect, Certified LabVIEW Embedded Developer and LabVIEW Champion.

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.