Hacker News Reader

Comment by wgrover | Hacker News Reader

You might find graphical programming languages like LabVIEW interesting; here's a little tutorial that shows what LabVIEW programs look like:

http://www.ee.buffalo.edu/faculty/paololiu/edtech/roaldi/tut...

"Wires" that carry values are color-coded according to their contents (integers are blue, floating point values are orange, booleans are green, etc.). Loops like FOR and WHILE are actual "loops" that encircle the repeated code. The flow of information along the wires determines the order of execution for the code, and you can debug your code by turning on a special mode that actually shows the information moving down the wires.

View on HN

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)

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.

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...

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.

A professor of mine and I were discussing this as we were poring over some freshman 1st semester programming projects done by primarily artistic students in Max/MSP, which is extremely similar.

Looking at a program from the scope of functions, it looks pretty unremarkable, but when you scope out to view the scale of functions you can start to make out the flow of control, etc. Even farther out, you can visually see separations of concerns that the student has implicitly created by the arrangement of the code. It was really remarkable viewing the architecture from 10,000 feet like that.

It redefined how I viewed liberal arts students.

Max/MSP does the same thing for DSP (audio) programming. http://cycling74.com/

Puredata does it for free! http://www.puredata.info

vvvv does it for video (similar to Max's Jitter, or pd's GEM, except better), for windows, for kinda free! http://vvvv.org

Reply on news.ycombinator.com