This idea was prompted by an email to a work colleague on how to generally improve LabVIEW. I liked it so much that I’m presenting it as an idea. Please keep in mind that it is worded with an individual audience and may have been tamed down had I written it for this exchange. I hope you like it. It’s a holistic approach to what I think will take LabVIEW from where it is today to where it could be in a year or so. Hopefully the LabVIEW community thinks likewise.
If NI want to improve LabVIEW, here’s what I see needs to be done:
1) Reduce the price of LabVIEW Professional to $1500 (and get rid of LabVIEW Base – why teach poor programming practices)
2) Allow a standard web browser to be the user interface (without any plug-ins!)
3) Fold in some of the general purpose toolkits into the main product (best way to add new features!, but I can live without this)
4) Sell single board cRIO in quantities of one (at a reasonable price). And show the price on the NI website.
5) Reduce the price of LabVIEW RT, FPGA and embedded.
6) Offer more deployment platforms (RT, FPGA and embedded) – this is where NI will make money, by selling more hardware.
7) Offer general-purpose low-cost mini-board (a few digital and analog I/O and a controller). Think 32-bit Arduino-like. In fact, why not make it compatible with the Arduino shields (stackable plug in boards that add functionality).
8) Improve the robustness of LabVIEW (in preference to new features).
9) More tutorials, examples and learning documentation (helps users, reduces support costs and opens the door to cheaper LabVIEW).
10) Increase the user base by a factor of 4 (needed to get to “critical mass” for user community).
11) Have the same feature set across Windows, Macintosh and Unix (or at least reduce the gap).
12) Publish a textbook for experienced LabVIEW programmers that want to move step-by-step to object oriented LabVIEW programming (assuming this is the way to go, haven’t used it myself so not sure how useful it is).
13) Add features to make it a more general purpose programming language (to challenge C, C++ and C#). Don’t take it too far, we don’t need LabVIEW to write word processors and database programs, but we would like to write home automation software (my next hobby project), general purpose utilities and more commercial software to go with our products (as opposed to our current usage of just in-house software).
14) Improve controls and indicators to allow the same look-and-feel as “professional” programmes. Want to create an awful user interface? Just add a Toggle Switch! There done! (Can you imagine any commercial software written in any other language that would go out of their way to add a Toggle Switch looking control? Can you even begin to imagine this in, say, Windows?). Anyway, more controls and indicators that look like those of general purpose applications and a built-in powerful easy-to-use control and indicator editor.
That should do it for LabVIEW 2012. I’ve got more to take LabVIEW to the Top 20 programming languages.
LabVIEW should be able to get into the Top 20 programming languages, if NI gets a move on. This is due to its lead with intrinsic multiprocessor programming and deployment across platforms ranging from mini-board (not yet available, see point 7), Lego NXT, LabVIEW embedded for 32-bit microcomputers, FPGA based systems (eg. Compact RIO) and desktop PCs (Windows, Macintosh and Unix). The entire programming spectrum covered – who else can do this today! However, it’s important for NI to get moving and exploit this lead before others do it.