Re: Java vs Labview
 

I wasn't going to enter the discussion about speed of development, but that last comment compels me.

First off, I'd hardly call that a reasonable conditional. :p 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.

“Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid.”
― Albert Einstein

Doing something in a way that Java makes easy will obviously favor doing it in Java. On the other hand, doing it in a way that LabVIEW makes easy favors LabVIEW, and so on.

Re: Java vs Labview
 

The 2013 project creation wizard was indeed slow. But the 2014 one is much faster, taking two seconds once I entered the IP address. Wow think what you can do with those extra three seconds.

As for how long it takes to create a for loop. I timed myself. Yeah, I know, it is sorta silly, but I do this thing for a living.

for(i=0;i<10;i++){
}

Takes me about nine seconds with no mistakes. Maybe I'm slow -- I balanced my own parenthesis and curlys after all.

The same code in LV without a pinned palette took under eight seconds.

But I'm sure that there is a way to configure emacs so that three meta key smashes and boom -- all done.

Anyway, this is getting silly even for me. Writing code is more than typing or drawing. LV is graphical because it cuts down on syntactical errors. LV has also supported algebraic syntax since version 1.0. It is called the formula node, and it is in the structure palette. The attached image shows the equivalent loop and formula.

By the way, this reminds me of the geekiest race I've ever observed. I was in college, working for the nuclear engineering department. Two grad students were poking fun at one another's choice of tool for formatting equations within their thesis. So how do two gentlemen end this dispute? With a race of course.

A neutral grad student found a gnarly fluid dynamics or neutron transfer equation that took up half a page in the textbook. He placed the books next to each participant and they were off. One was typing LaTex script, the other was using a graphical formula editor in MS Word. It took each of them several minutes, and they finished in a dead tie. It was like an episode of Big Bang, but I was there.

Anyway, have fun and good luck with whatever language you choose. It is of course fun to argue and compare, but don't let that get in the way of your robot tasks.

Greg McKaskle

Re: Java vs Labview
 

LabView is easier to learn for students with no programming knowledge and has some nifty features (e.g. automatic multithreading). It also takes forever to upload code (supposedly this will be improved on the roboRIO), is limited in applicability to other fields, and will not give students any significant programming knowledge that can be transferred to other languages.

Java is very widely used, not overwhelmingly difficult to learn, uploads easily, and is similar enough to most other C-based languages that students who learn to program the robot in Java will have a nice head-start if they ever intend to pursue programming. Unfortunately, the FRC Java API is frustratingly bad/poorly-documented, and programming the robot as anything other than a finite state machine is somewhat complicated.

Which is "better" depends critically on the utility function you're using to compare them.

Re: Java vs Labview
 

I disagree wholeheartedly.

Re: Java vs Labview
 

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 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.

Re: Java vs Labview
 

Surely you can't be serious.

Re: Java vs Labview
 

What? That's completely reasonable. :o 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).

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.

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.

Re: Java vs Labview
 

I think the FRC Javadocs are well written, intuitive, and easy to understand. It's where my students go first to look up functionality, right before Google, screensteplive, and then ChiefDelphi. If you asked me to do something new with the robot that I've never done before, say CAN features on the Jaguars, I'd be able to get pretty close on my first try. What part of the documentation do you consider badly written?

And don't call me Shirley. :D

Re: Java vs Labview
 

Last year, before we switched to java.

"Limited" and "none" are not the same thing - after all, we're not talking about prolog here. I'd say the same thing about programming in, say, IDL; it's certainly used in certain applications, even almost exclusively in some, but its applicability is at least an order of magnitude smaller than that of Java.

And I don't think it's all that contentious to say that learning LabView will probably not teach you how to program in other text-based languages, while learning Java probably will.


Pretty much this.

Re: Java vs Labview
 

You know... whenever my team members get in an argument like this I look at them with a straight face and say "my computer has more USB ports then yours does......."

Re: Java vs Labview
 

Thank you Alan. This is something I strive mightily (and still often fail) to convey to students. My old boss used to struggle to convey it to developers.

Re: Java vs Labview
 

As someone who has programmed for a living and now teaches programming for a living, I think Java is probably the best choice of the three languages if you want to balance ease of getting started and the most widely applicable learning. That said, the difference is a marginal one at best.

For instance, I find that students who come to my class having done FLL and knowing the LV based programming are a little slower at implementing their first programs than the kids who have programmed Ardiunos in C. On the other hand, when we get to the first big (meaning more than one class interacting) project, the kids who know LV style graphical programming go much faster. Yes this is probably in large part because they have to design the project on paper first (using a slimmed down UML style diagram). But if they had to do a large project in the vaunted "real world" they would likely be required to document their planning first. The LV-knowing students also are better at understanding how interrupted program flow works, because they have seen it laid out in front of them.

As Alan pointed out, not every problem is a nail. But when you are carrying around a hammer you tend to evaluate every problem as though it is a nail. Or to assume that problems that clearly aren't nails are some sort of weird exception.

Re: Java vs Labview
 

I just spoke to someone who is going to forward links to some studies that used LabVIEW and two popular text languages to determine whether LabVIEW or a text language were better prep for learning the next text language. The conclusion? LabVIEW was an equally good prep language. It doesn't bias people against textual languages, and doesn't punish them because they were learning the wrong thing. I wish the study had continued and attempted to measure how the diversity of prep languages benefitted the ability to learn the next.

When building WPILib, we attempted to make the libraries parallel across the languages, making it easy for teams to see past the syntax and see how similar operations can be carried out in different languages. I believe that this diversity of solution, in HW, and in SW is one of the key elements of project-based learning and in the competitions such as FRC. In my opinion, it will be a sad day if FRC has only one programming option -- regardless which option it might be.

...

When working on Mindstorms, our essential language elements were sequential operations, parallel operations, repetition, conditional operations, numeric math, and Boolean logic. We included strings and the rest is libraries of I/O for the brick. WeDo is for even younger kids and leaves out conditionals and Boolean operations. Both include a WaitFor block which can be explained either as a composed repetition/conditional or a unique element. I will argue that these are significant and are at the core of programming. Additionally, learning what an array is, what a string is, the difference between an integer and a float, learning that your timing specification for a delay is a minimum value and not an absolute; these are also common and significant concepts that are shared across all languages. Then there are the differences that can be used to demonstrate alternate solutions. Object based design has benefits, and drawbacks if not used appropriately. Pointers or references? Functional or Procedural? Iteration or recursion? This diversity and similarity is, I hope, offering a rich landscape to explore what programming is.

The languages I learned in college were not simply variations of Java. It didn't exist then, not even as oak, but that wan't the reason. Lisp, Pascal, C, prolog, Cobol, Fortran and assembly all have a profound learning value, not because they were textual, but because of the concepts they enable you to learn. At the universities we recruit from, they don't teach only Java. I think Java is a great learning language, and I think LabVIEW is a great learning language.

Greg McKaskle

Re: Java vs Labview
 

Without a clear definition of what the shoot sequence is, and what the conditions are for starting it off, I can't be confident that what I'm thinking of in LabVIEW would be equivalent. But I'd probably put the limit switch and arm encoder checks in the first part of the sequence itself.

How do you count 6? I'd do it with a single AND, a single multiply, and a single comparison.

Re: Java vs Labview
 

I like Line-based programming more than Labview, because for me it offers much more versatility to the program.
The reason I chose to do Labview this year was because I'm a first year programming leader, we were 3 weeks into the 6 week period, and the library was being non-compliant. My programming mentor did not mind, he really only wanted us to do what was comfortable and at that moment in time it was much more comfortable to get working code in a day than spending a week bugging out a library with only 3 weeks left.
Added to that, I had mechanical mentors yell at me for not finishing code when the robot was barely being built, and that I was not working fast enough.
Labview got them their beloved code fairly quickly.
And yet I still get flak for choosing labview, even though the robot probably wouldn't even work if I didn't.
I never win.

Anyways I digress, I say if you know labview well, as in subvi's and quick implementation, go for it. It's a neat little program for robot building, and if you're really good at it you can get a robot working in a couple days.
If you know line based code, go for Java/C++ instead. But be prepared ahead of time, because I thought I knew line based code and so did my underling, and we were extremely confused with the library. If you want to do Java next season, I suggest getting the hang of it now.