ADAM was my first computer too. I had the version that plugged into a ColecoVision system. Mine, however, lasted years. I got in when I was in middle school and was still using it to print my Physics reports in 10th grade.
Exactly. I have American Girl from Tom Petty and the Heartbreakers on 4 albums (original album, Greatest Hits, Anthology & Box set). I only want it once in my TP&HB playlist. Duplicate songs works just the way I want.
The company I work for (big, multinational, etc.) has training courses in Windows Media format. A lot of the new hire stuff is now done on the desktop after the employee is hired and not in instructor taught courses. Also, once or twice a month there is another Ethics/Legal type training video that EVERYONE has to watch.
Sure, these could be converted into another format. But that is just another line item that needs to be done to switch to Linux. Once the "Things we need to spend money on because they don't work in Linux" list gets to a certain number, migration just isn't going to happen.
I agree. However, things have changed since the LabVIEW 4 days.
Non-DAQ apps: I know you weren't knocking LV, but it's important that everyone knows that is all LV is targeting. Some people say LV sucks because it can't do everything C can. Well, neither can Javascript, and I don't want to use a compiler written in Perl. It is a great tool for its domain. That said, a lot of new LV features are actually written in LV. NI has said (jokingly) that they are close to being able to rewrite LV in LV. I wouldn't be surprised.
Large Programs: A lot of problems result from not using best practices. Part of the blame is that LV is so easy to get up and running. Programmers never learn the correct way to do things. I've been doing LV for 5 years and I'm just getting really good. Some companies have very large programs written in LabVIEW. Our largest had over 200 user panels (windows) that accessed over 4000 channels of data. I know of larger.
My job requires me to program in LabVIEW. National Instruments (makers of LabVIEW) has added a lot of high level functions that allow me to do things that my German counterparts (multi-national company) need 5x more time to complete in C or C++.
I agree that many programmers don't like the visual data-flow method of programming. But LabVIEW has always been geared toward engineers and scientists, not compsci grads. I don't think any LabVIEW user would claim that LV completes with C or C++ for general app development (don't try to program a LabVIEW spreadsheet, even if it is technically possible)
The biggest advantage for someone like me is being able to see how the data flows. Also, LabVIEW is interactive, place stops and data probes while the program is running.
For programs involving data acquisition and presentation, LabVIEW is a lifesaver (provided your equipment has LabVIEW drivers, or you have rolled your own.)
Then again, everyone should use the tool that allows him or her to most productively attack a problem. I can solve DAQ problems quickly in LabVIEW. My German friends are starting to solve new problems in LabVIEW (one C holdout:). If you are more productive in another language and can still solve the problem, go for it.
Slashdot Mirror
ADAM was my first computer too. I had the version that plugged into a ColecoVision system. Mine, however, lasted years. I got in when I was in middle school and was still using it to print my Physics reports in 10th grade.
Exactly. I have American Girl from Tom Petty and the Heartbreakers on 4 albums (original album, Greatest Hits, Anthology & Box set). I only want it once in my TP&HB playlist. Duplicate songs works just the way I want.
Sure, these could be converted into another format. But that is just another line item that needs to be done to switch to Linux. Once the "Things we need to spend money on because they don't work in Linux" list gets to a certain number, migration just isn't going to happen.
I agree. However, things have changed since the LabVIEW 4 days.
Non-DAQ apps: I know you weren't knocking LV, but it's important that everyone knows that is all LV is targeting. Some people say LV sucks because it can't do everything C can. Well, neither can Javascript, and I don't want to use a compiler written in Perl. It is a great tool for its domain. That said, a lot of new LV features are actually written in LV. NI has said (jokingly) that they are close to being able to rewrite LV in LV. I wouldn't be surprised.
Large Programs: A lot of problems result from not using best practices. Part of the blame is that LV is so easy to get up and running. Programmers never learn the correct way to do things. I've been doing LV for 5 years and I'm just getting really good. Some companies have very large programs written in LabVIEW. Our largest had over 200 user panels (windows) that accessed over 4000 channels of data. I know of larger.
My job requires me to program in LabVIEW. National Instruments (makers of LabVIEW) has added a lot of high level functions that allow me to do things that my German counterparts (multi-national company) need 5x more time to complete in C or C++.
:). If you are more productive in another language and can still solve the problem, go for it.
I agree that many programmers don't like the visual data-flow method of programming. But LabVIEW has always been geared toward engineers and scientists, not compsci grads. I don't think any LabVIEW user would claim that LV completes with C or C++ for general app development (don't try to program a LabVIEW spreadsheet, even if it is technically possible)
The biggest advantage for someone like me is being able to see how the data flows. Also, LabVIEW is interactive, place stops and data probes while the program is running.
For programs involving data acquisition and presentation, LabVIEW is a lifesaver (provided your equipment has LabVIEW drivers, or you have rolled your own.)
Then again, everyone should use the tool that allows him or her to most productively attack a problem. I can solve DAQ problems quickly in LabVIEW. My German friends are starting to solve new problems in LabVIEW (one C holdout