Hacker News Reader

Comment by luu | Hacker News Reader

Labview beats the snot out of anything else for building, say, custom spectrometer control and data acquisition systems. I know, because I had to do this. I’ve seen mooks try to do the same thing in C++ or whatever, and laugh scornfully at the result

What's so great about LabVIEW for spetroscopy? I ask because, as part of my MS thesis, I built a fourier transform spectrometer. After messing around for a few days with some LabVIEW code someone else had written for a similar task, I wrote the control code in C in a couple of hours, including the time it took to learn the (deprecated) LabWindows C API. I have no doubt that LabVIEW has improved since I did my thesis (almost ten years ago), but it's not obvious, a priori, that graphical programming should be better for controls.

View on HN

It's not that Labview is great for spectroscopy. It's that it is great for building things to control large, complex scientific apparatus (mine was an X-ray Fourier spectrometer; the X-ray beamline was also controlled in this way), manage streaming data from dozens of sensors, do the analysis, and rapidly change things around if you stick new hardware in it or need to run things differently. There was C and DSP programming involved on a VxWorks VME crate where things needed to go fast or talk to unsupported hardware, but controlling the whole mechanism was done via Labview. There was no other sane way to manage the complexity.

Oh no, graphical programming languages again. Slightly OT but I think you made the right choice. I'd like to refer you to a series of posts detailing the practical issues from a few days ago:

http://news.ycombinator.com/item?id=4496494

While any LabView code I've ever seen (admittedly not much) looked like a horrible mess to me, I disagree with your view on graphical programming languages.

I've done a reasonable amount of programming in Max/MSP and while, again, most code I've seen online was a horrible mess, I attribute that to the fact that these languages usually target non-programmer audiences who, sadly, don't get taught about proper encapsulation, abstraction, naming conventions (ie use actually descriptive names!) and software patterns.

My own code read (to me - though others have commented on it too) almost like something you'd write on a whiteboard to show how the software works to non programmers. I encapsulated each chunk of code that does a single task into its own component, so an individual component (ie diagram) never had more than a few high level "things" connected together, so you can tell - at a glance - what does what. Of course, this means that there are many layers of components, from very high level all the way down to low level, but the point is that with proper encapsulation, visual languages are no harder to understand, read or manage than textual ones and I personally feel that, in many ways, they're actually easier.

I also found debugging Max/MSP code to be the best debugging experience that I've ever had, due to the fact that you can visually see where data comes from and flows and you can intercept it at any point to see whats happening.

I also found Max/MSP a dream to do experiment-driven-development and code design and far superior to using the Python and Clojure (the two languages I use most at the moment) REPL's. I think one of the reasons is that while I'm still experimenting with concepts and design/algorithm ideas, I do not need to name things, I can just lay down a few components, connect them and see what happens. In textual languages, everything needs a name, so often you end up with a, b, x etc. I should point out, though, that when I design software (architecture or algorithms), I do it with boxes and lines, so graphical languages may just be a good fit for how I think and I guess not everybody is like that.

Don't even think of keeping things tidy, wires will be everywhere, and the auto-arranger doesn't work well.

With proper software engineering practices, this is not an issue. Without proper software engineering practices, we have the same issues in textual languages.

Modern Tools

This is a very good and important point, but its not inherently a graphical language problem. Things like version control and diffs - sure. They just work in textual languages, but in general, all languages start off with tooling problems. I do believe that good diff tools could be developed for graphical languages and that they would be at least as good as for textual languages and writing a git-compatible file format is obviously possible too (in fact, Max/MSP files look a tiny bit like JSON IIRC). This of course doesn't change the reality that currently there definitely is a tooling problem, so you are very right! But it need not always be that way.

My only complaint about Max/MSP is that I'm one of those people who hates the mouse... I spend most of my days in a keyboard-centric window manager using vim and a keyboard centric web browser, so graphical languages aren't exactly ideal from that point of view.

I've also spent a fair amount of time working in Max/MSP and I would support nearly every statement you said here, even though I'm not a programmer that thinks in graphical terms.

The 'wires going everywhere' thing is potentially a problem, but I usually took it to mean that it was time for more encapsulation or better code organization, which is I think more or less what you were suggesting. On the other hand, lots of artists create amazing work that's so will make you think you're going to have a heart attack just looking at the rats nest. But hey--these are programming amateurs and they're doing amazing things, really fast! I know some musicians who could cook up amazing stuff in Max so fast I would still be thinking about how I would structure the code and they'd be demoing it. It's also important to remember that much of what we focus on as professional programmers is less important to artists for whom cost of implementation is far more important than reuse.

Regarding version control, yes, modern max patches are in fact serialized to disk as JSON. There's an option you can set that causes the program to perform a sort on the structure on save, hopefully minimizing the diff. I worked w/ max patches in git for years, and it was fine though I never really tried to do anything even remotely interesting like merge from another branch; I treated my max patches more like binaries in version control that happened to be stored really efficiently.

In the end, much of the work I would do in Max involved writing a lot of things in C/Java/Javascript and wiring it up, and the reason is, as you alluded to, the mouse. It's just not as productive to move boxes around for me as it is to write text, but boxes and lines make really great glue code for putting together inputs, outputs, and a set of algorithms into a single work, especially if that work is time-related in some way.

these are programming amateurs and they're doing amazing things, really fast!

It's also important to remember that much of what we focus on as professional programmers is less important to artists for whom cost of implementation is far more important than reuse.

These are two things I did not touch on in my comment at all, but you are of course correct and I feel its important enough to mention again. The fact is that people without programming backgrounds are doing amazing things and that they seem to be finding it much easier than with textual languages. The fact is that graphical languages are very successful both in audio (Max/MSP, Reaktor, Synthmaker etc) and graphics (voreen and blender embed a visual language) where they are used successfully by a lot of non-technical people. I've also seen them used in game engines, both for shading/effects/materials and for scripting of game logic[1]. As you mentioned, however, the goals and priorities of these people are generally not the same as those of professional programmers, so often writing once - but quick - is much more important to them than re-usability and modularity and that's perfectly ok if that's what makes sense for them.

boxes and lines make really great glue code for putting together inputs, outputs, and a set of algorithms into a single work

Graphical languages make for fantastic glue code/dependency injection. XML has been traditionally used to externally glue components together and IMHO is often more complex than doing it in the code itself and not really all that much more flexible at the end of the day. Graphical languages are IMHO ideal for this as they show at-a-glance, at a high level, how components in the system are connected, yet still allowing the lower level nitty-gritty algorithms to be managed in a textual language, which may be more optimized for those tasks.

[1] http://www.unrealengine.com/features/kismet/

If you're interested in writing software, labview is a bad choice. If you're interested in solving problems on a computer, labview is often the only choice. Things like it will probably eventually make your job obsolete, as more people can draw flow charts than can deal with correct programming practices.

What's so great about LabVIEW for spetroscopy?

LabVIEW probably has a library to talk to the spectrometer.

Apart from that, LabVIEW has very little advantage.

Reply on news.ycombinator.com