Hacker News Reader

Comment by thirdhaf | Hacker News Reader

LabView IS fun, I've written a couple of drivers and a (physical device) testing GUI with it. As I've been thinking about it more I see two hurdles to overcome with LabView though: - Layout: Spaghetti code becomes a very tangible issue if you don't follow guides on routing religiously. Intro courses only touch on this and LabView code in the wild are rarely clean. These visual routing guides are ORTHOGONAL to good code design practices which you also have to follow to make maintainable and understandable code. - Navigation: There is no VIM or Emacs for LabView code as far as I know. Navigating a codebase and following function references deeper and deeper down the rabbit hole becomes tedious pretty quickly. Visual breakpoints help here but there's no substitute for quick navigation, I never found a Ctags equivalent for this language.

(Caveat, EE turned software engineer ranting)

View on HN

True enough, LabView visual 'code' doesn't scale cleanly. One of the reasons for this 'spaghetti' is that the language combines control-flow and data-flow constructs in the same schema level. However, LabView remains the most successful graphical language to date, leaving MUCH room for future language innovations for those who dare to journey out of the scripting realm for software expression to deal with the scaling and many other engineering issues for a new paradigm.

I like your assessment of LabVIEW. I find that if your code is turning to spaghetti, you're not using enough sub-VIs. Try to find blocks of code that accomplish one thing and put that code in its own VI. As a bonus you get to design a little icon for your new sub-VI. :)

Your "rabbit hole" analogy is spot-on and I'm not sure how NI can address some of those problems. Some things like Ctags that are so valuable in text-based languages just seem to have no obvious analogy in a graphical programming language... it's fun to imagine though.

(Caveat, chemist talking about programming)

If you right click a VI in a LabVIEW project you can "Find Callers" and "Find SubVIs"

I'm using LV 2009, I'm not sure what version this was added.

I'm sure part of the issue was that I was trying to teach myself Labview under a deadline as a fresh college grad with zero oversight from anyone with experience with it.

I'm not a LabView fan for various reasons, but something neat they've added as of V8.0 (I think) is an auto-format tool which will take a mess of wires and organize it. Vastly improves readability, and works really well.

Hmm, we were still running 6.1 in 2008 which probably explains a lot. (No upgrade path allowed at that time)

Wow 6.1 is ancient... :-) LabVIEW 8.6 is a huge leap forward in usability, stability, and performance. If you can upgrade to 2011 that's even better.

-National Instruments employee

6.1 was running on an even more ancient PC from 2001. This was at a former employer so I have no influence over this system any more. The funny thing was that we had ample budget for this project, I think we spent about $10k on a very nice rack-mount SCXI DAQ and about $60k on other equipment but upgrading the computer system driving the whole thing was out of the question due to color-of-money issues and dysfunctional inter-departmental politics.

You're right, the auto-wire-organizer tool is fantastic. Every time I use it I wonder what algorithm LabVIEW is using to rearrange things - not an easy problem computationally I'm sure. I use it for small sub-VIs but I find that if I use it on a large project I can't find anything after using it - I was relying on spatial layout of the VI which was lost after auto-formatting.

I guess this is analogous to algorithmically reformatting code in a normal text-based programming language...

Reply on news.ycombinator.com