4 ms·

I'm surprised he's not railing against LabView and Origin too.

by batbomb 13y ago

rwg 13y ago
Random "LabVIEW isn't a general purpose programming language...except it kinda is" story: About a decade ago, my then-boss dragged me to a weeklong LabVIEW training course. The course was geared toward scientists and engineers (like my boss — I was sysadmin/programming/IT), and the instructor wanted people to bring data, problems, etc. from their own research to work on during the "hands-on" afternoons. I didn't have research, but I did notice that LabVIEW could open TCP sockets... By the end of the week, I had written a barebones graphical MUA (e-mail client) that could read mail via POP3 and send via SMTP. "Written" entirely in LabVIEW. (The "code" was spaghetti – tons of boxes of all sizes and a rats nest of wires connecting everything together.) The instructor asked for a copy to take back to NI, and I'd like to think that some NI engineers got a good laugh and/or vomit out of it.
- thelukester 13y ago
  Yes, the cool thing about LV is allows you to turn an idea on a flow chart into code that resembles the original chart on the high level. And, nothing beats it for data acquisition and testing. Like all visual languages big projects and the finer implementation details can get ugly. Most people focus in LV's visual programming paradigm. But I think its real power come from the Flow Based Programming model. Functional programming is the trendy solution to the problem of concurrency these days. But I think FBP could offer some solutions in this domain too. NoFlo looks a promising new technology in this area. http://noflojs.org/ http://noflojs.org/
spystath 13y ago
I have written a bunch of programs for interfacing with instruments and when I started doing that I was using labview but it was such a pain. It was liberating when I found that VISA has python bindings. I now do all the instrument-interfacing code in Python+Qt. It is so much more productive that it makes me wonder why do people still want to use labview for this kind of job. I mean its visual language is complicated that it makes even the simplest things (like formatting a string) difficult. And on the top of that if you try to make something more complex the block diagram is completely unreadable. Madness.
- lbenes 13y ago
  It all boils down to using the right tool for the job. If you need performance, C will blow python out of the water. If you need a quick solution that’s light on data acquisition and heavy on algorithms, python will probably be a better choice. I’ve run into a highly concurrent, signal processing tasks handled beautifully with LabVIEW and its built in SP modules. Python would have been a terrible choice for that application.

I'm surprised he's not railing against LabView and Origin too.

by batbomb 13y ago

I'm surprised he's not railing against LabView and Origin too.

rwg 13y ago

Random "LabVIEW isn't a general purpose programming language...except it kinda is" story: About a decade ago, my then-boss dragged me to a weeklong LabVIEW training course. The course was geared toward scientists and engineers (like my boss — I was sysadmin/programming/IT), and the instructor wanted people to bring data, problems, etc. from their own research to work on during the "hands-on" afternoons. I didn't have research, but I did notice that LabVIEW could open TCP sockets... By the end of the week, I had written a barebones graphical MUA (e-mail client) that could read mail via POP3 and send via SMTP. "Written" entirely in LabVIEW. (The "code" was spaghetti – tons of boxes of all sizes and a rats nest of wires connecting everything together.) The instructor asked for a copy to take back to NI, and I'd like to think that some NI engineers got a good laugh and/or vomit out of it.

thelukester 13y ago
Yes, the cool thing about LV is allows you to turn an idea on a flow chart into code that resembles the original chart on the high level. And, nothing beats it for data acquisition and testing. Like all visual languages big projects and the finer implementation details can get ugly. Most people focus in LV's visual programming paradigm. But I think its real power come from the Flow Based Programming model. Functional programming is the trendy solution to the problem of concurrency these days. But I think FBP could offer some solutions in this domain too. NoFlo looks a promising new technology in this area. http://noflojs.org/ http://noflojs.org/

spystath 13y ago

I have written a bunch of programs for interfacing with instruments and when I started doing that I was using labview but it was such a pain. It was liberating when I found that VISA has python bindings. I now do all the instrument-interfacing code in Python+Qt. It is so much more productive that it makes me wonder why do people still want to use labview for this kind of job. I mean its visual language is complicated that it makes even the simplest things (like formatting a string) difficult. And on the top of that if you try to make something more complex the block diagram is completely unreadable. Madness.

lbenes 13y ago
It all boils down to using the right tool for the job. If you need performance, C will blow python out of the water. If you need a quick solution that’s light on data acquisition and heavy on algorithms, python will probably be a better choice. I’ve run into a highly concurrent, signal processing tasks handled beautifully with LabVIEW and its built in SP modules. Python would have been a terrible choice for that application.