Quote:
Originally Posted by Alan Anderson
First off, I'd hardly call that a reasonable conditional.  But even so, you're totally ignoring the fact that LabVIEW wouldn't have those variables in the first place. The Java code that would have set them prior to evaluating the condition has no counterpart in a LabVIEW program. |
What? That's completely reasonable.
I took it straight out of our code this year.
"If the shoot button on the joystick is pressed, and neither of the arm limit switches are hit, and arm encoder value is less than calibrated base value plus (magic multiplier times shooter position)", execute shoot sequence.
It could be simplified and these boolean conditions could be defined before the if statement, but you're still going to have to put them into the program somewhere. If you want the same functionality in LV, you're still going to need at least 6 operators, and that's not counting the negation blocks. Obviously, these are edge cases, and we only have 3~4 of these types of logic statements on our bot, but I'm surprised anyone can argue that LV development is faster than Java development provided both sides knew their stuff (time for debugging, testing, tuning...etc aside).
Quote:
Originally Posted by Alan Anderson
When was the last time you used LabVIEW? It takes our system this year less than ten seconds from "Run as startup" to having the cRIO rebooting to run the newly loaded program. It's probably less than five if you're watching closely and ready to press Enter at exactly the right time.
|
I'm truly curious now. Tt takes our cRIO at least 11 seconds to restart. We know that because the console out is printing "Waiting for cRIO to reboot (11s)". When I played around with LV this year, it took me 2~3 minutes to just build the program. Then, it took half a minute to load the program onto the cRIO. Then, it restarted (~10s). Whole process was about 4 minute for us. Perhaps it's because our computer is old and slow, but that would only explain the build process; the remaining time should be at least as long as the Java deployment process.
Quote:
Originally Posted by Alan Anderson
I'm just going to contradict you there. Sorry, but you're making assertions that are flatly false. LabVIEW has applicability in the fields of medicine, aerospace engineering, industrial control, data collection and analysis, electronic device testing, cryptographic communication, process automation, user interface design, etc. And if you don't think knowledge of parallel processing, interprocess communication, dataflow concepts, modularization, etc. are significant, I don't know what to say.
|
I think your disagreement with him is semantic. I think by "limited applicability", he meant exactly those fields you mentioned, which can be seen as limited because I'd imagine LV doesn't cut it for most software projects on consumer devices (which is what most software writing grads at our uni end up doing), and you need specialized hardware to LV programs whereas C++ and Java are open and standardized. Basically, you may be able to do a lot of things with LV, but most things you can do with LV, you can also do with a C based language, yet the reverse is not true.
I wouldn't say LV teaches you parallel processing and such. It does it automatically for you and when you realize that's happening, it's probably because you don't want it to do that automatically. I've mentored students who started with LV, knew enough to program the bot, yet when we switched to Java, they had to relearn threading, OOP...etc, well, pretty much everything. The way LV presents those concepts is radically different from the way text base programming languages do, which is why it's uniquely good at some tasks, but the skills and concepts don't translate well to other languages.