

Nonblocking Algorithms and Scalable Multicore Programming - sbahra
http://queue.acm.org/detail.cfm?id=2492433

======
slacka
> "the design and implementation of correct, efficient, and scalable
> concurrent software is often a daunting task"

A few years ago, I had to help our EEs write some testing software in LabVIEW.
I was blow away by how elegantly it solves concurrency and fault tolerance to
bad data. It took no extra design to utilize multiprocessing and
multithreading hardware. All of the deadlock and race conditions problems that
threads introduce were a thing of the past.

Has anyone else had a similar experience? Why don't more people use LabVIEW or
languages like it outside of data acquisition?

~~~
DuskStar
I had some experience with LabVIEW for FIRST Robotics, and I honestly hated
it. I could fit so much fewer code on a screen, making it harder to
debug/understand, and the compile times were absolutely horrific. (2 hours for
the robot equivalent of "Hello, World!" is really unacceptable)

The following year we switched to C++, which compiled in <10s on the same
machine. Supposedly LabVIEW got some performance tweaks, but we didn't bother
to check back with it.

So while I never used the multithreading aspects of it (And I can see how they
would work, variables are passed in such a way to explicitly lay out what
modifies them), I can easily see people having issues with LabVIEW.

~~~
slacka
Yes, it's true LV has its own issues. It's a memory hog and the UI is
cluttered. Reminds me of where JavaScript was before V8 came out.

My experience was very different from yours. I couldn't believe how simple it
was to add an additional test in parallel. It was just a copy/paste, update
the functions, test parameters, and I/O. If only writing multithreaded code
was that simple. After my experience, I could see how LV could be a good fit
for computer vision apps running on highly parallel architectures.

It's too bad there aren't any other modern, open dataflow languages out there.
I wonder how much research academia has put into dataflow concurrency.

~~~
DuskStar
Oh I definitely agree with you there! LabVIEW was amazingly easy to just grab
and run with,and I didn't have any issues with the language design. I think
it's something with a ton of potential (especially for writing multithreaded
code), it just needs to compile large programs faster (maybe precompile
functions you import from libraries?) and shrink the default spacing between
elements.

I wouldn't call LabVIEW open, though - isn't a retail copy close to $3000?
(might be another reason it isn't as commonly used)

