Java vs Labview

[Greg McKaskle]

Ahh I see now. The way to solve this problem would be to enforce having an else (like the default case in the case structure), right? And if you initialize something in one place and not another, you'd have a broken wire much like a case statement would give you one.

I'm beginning to see how it might turn into a bigger problem than it solves though.

It is only a bigger problem if incorrect behavior is a small problem

You will find SW group policies that require else's for every if, require curly braces for every section, require a default for every case, require decoration about exceptions that can be thrown, etc. They do this because they have been bitten by bad conventions and their response is to make their language safer than it came from the factory.

Surprise, surprise, I have a story. I think it was my second assignment at college, and it written in C and was probably supposed to read a file, sort the contents, and blah, blah, blah. But the professor wanted to make a point, so we were only allowed to use if's and gotos. No else's, no for's, no whiles, no switches, etc. Try it sometime. It really makes you appreciate structure and modern language features.

Greg McKaskle

[Alan Anderson]

Originally Posted by yash101

While you can use LabView outside of FRC, you can't write a regular computer application with it. Sorry, LV programmers, but you can't write games. Java and C++ are much more portable and don't require that you use a National Instruments product.

I maintain "regular computer applications" that were written in LabVIEW. They run on a generic Windows computer.

The LabVIEW Dashboard is a "regular computer application" that doesn't require National Instruments hardware in order to run.

I don't have the spare time to spend on writing games, but I don't see any reason I couldn't do it using LabVIEW.



I do not dispute that C++ and Java can be more "portable" and more "general purpose". But you're making unfair statements about LabVIEW that aren't really helping the discussion.

[efoote868]

Originally Posted by Greg McKaskle

Surprise, surprise, I have a story. I think it was my second assignment at college, and it written in C and was probably supposed to read a file, sort the contents, and blah, blah, blah. But the professor wanted to make a point, so we were only allowed to use if's and gotos. No else's, no for's, no whiles, no switches, etc. Try it sometime. It really makes you appreciate structure and modern language features.

That challenge sounds a bit like the LED cube we (me and a couple others) programmed in assembly for an end of semester microprocessor project. I've never taken a compiler for granted since.

[xXhunter47Xx]

What I'm seeing is people who are versed in Line-Based Code bash on Labview for being too simple. Labview users defend themselves by saying that it is much more complex.

I agree, Labview is very complex. You guys complaining about Labview probably haven't used it extensively enough. You don't have enough background information to actually fairly judge it. It's as if I judged C++ for creating too many lines of text because I don't know how to use command/subsystem prompts or certain functions that can shorten code confuse me so I don't use it.

The only problem I see with Labview is that not very many teams use it (at least in San Diego), so your code support is very low. Other than that, you just have to know how to use it.

TL;DR The sword is only as powerful as it's beholder. But if you choose the labview sword you won't get much tech support at regionals.

[yash101]

Originally Posted by Alan Anderson

I maintain "regular computer applications" that were written in LabVIEW. They run on a generic Windows computer.

The LabVIEW Dashboard is a "regular computer application" that doesn't require National Instruments hardware in order to run.

I don't have the spare time to spend on writing games, but I don't see any reason I couldn't do it using LabVIEW.



I do not dispute that C++ and Java can be more "portable" and more "general purpose". But you're making unfair statements about LabVIEW that aren't really helping the discussion.

Yeah. I guess I worded that kinda awkwardly to the point of confusion. While LabView is a nice language to have in your toolkit, I do not think it will be as useful as Java or C++ because they not only work everywhere, They are available to everyone, run on literally any main platform, UNIX/BSD/Linux, Windows, etc. Also, being able to write your own code can give you a different perspective of the big picture. Writing code yourself means that you will place small puzzle pieces until the jigsaw puzzle is complete and works perfectly. However, as FIRST is concerned, I, myself (this is my opinion) dislike JavaME because it has what I don't need but the stuff I need is hard to find.

Whether you want to use Java or Labview is based on personal preference, but I believe Java is the way to go if you have locked yourself down to those two choices. However, if you want to take into consideration, C/C++ may be more likeable on the cRIO because it is full, not Mobile Edition!

I, personally don't have too much LV experience. The first FRC program I wrote was in LV, only to find out that our team was using C++ (Silly me ). However, I did find the interface quite confusing.

I hope this helps

[Patrick Chiang]

Originally Posted by yash101

However, as FIRST is concerned, I, myself (this is my opinion) dislike JavaME because it has what I don't need but the stuff I need is hard to find.

I heard that the new roboRIO next year is going to run the regular Java.

[yash101]

Originally Posted by efoote868

That challenge sounds a bit like the LED cube we (me and a couple others) programmed in assembly for an end of semester microprocessor project. I've never taken a compiler for granted since.

Were you alowed to hack a bit and trick your instructor by placing some inline assembly? Maybe that could've made some things easier

@Patrick
I agree that we will use JavaSE next year, but right now, I'm concerning myself with this year! As a matter of fact, that backs my standing because it will be easier to use next year!

[fovea1959]

a viewpoint of a short-timer (4th year) mentor that is a grey beard professional Java developer and mentors a team that just switched from LV to Java, and talks regularly to a team that does C++ and another doing LabView. Many of the issues in this thread have come up in our corner of the world.

I'm also punchy: we just hosted a district competition this weekend that we also competed in. We're *tired*, and if someone asks me to tape another tarp on the floor, I'll die...

• does your school(s) teach any programming? if so, that's a *major* factor in the decision. 4237 (not my team, but I had a son go to school there) has taught C++ in their fine Math and Science Center for quite a while. The switch from LV to C++ between year 1 and 2 was a natural one for them, and has been a good one. We have 3 students in our school doing a remote Java AP class from a college in Florida, and I wish we could have snagged one of them for the team; they would be a *great* complement for our current "I understand I need to get done in 20 ms, and I'm pulling an well-deserved A in my Mechatronics class, but what's this try/catch stuff about?" programmers (not dissing our students!). I didn't have enough time in the off season to teach all of Java *and* teach WPIlib, so I setlled for just teaching a subset of Java (data types, classes, methods, looping, conditionals, methods, etc).
  
• our team did well with LV, until we started getting a lot of programmers. Divvying up a complex robot in LV over several developers working on several dissimilar PCs is no doubt doable, but we never figured it out. Telling a student "create and test a sub-VI on that computer and we'll integrate it into the overall build over here later" was always an exercise in faith for us, and a test of my ability to filter epithets when students were around. I'll concede that knowing how to do it in Java (and C++) is colored by my day job, and I'll bet that NI knows how to do it (and that knowledge is accessible to a determined team that's good with Google), but LV seems to be more tailored to work involving a small group of developers (one programmer can be a small group), or else developers with a highly homogenous build configuration.
  
• for text based: Java vs C++ is probably less of an issue than iterative vs command-based.
  
• support: San Diego must be very far from Michigan. I was the only 1 of 3 CSAs at our district competition that was strong in Java; all 3 of us were comfortable with LV problems. Our other district competition had a team with Java problems, and none of the CSAs had Java experience (*not* dissing the CSAs: they knew where to go for help, and all problems were resolved in a timely manner). A rookie team with an LV problem in Michigan doesn't have enough room in their pit to accomodate all the programmers from other teams that will run over to demonstrate GP once the "help" announcement hits the pit PA. C++ teams in trouble hear cricket noises. Java teams here seem to be in the middle, peer-support-wise.
  
• execution speed. um, how often does it really matter? bad code design or implementation can easily swamp any performance differences between languages. AFAIK (chime in here, folks, I welcome learning more), the heavy lifting for stuff like vision is all pretty much done deep in the bowels of the cRIO by language independent native code; do we really see a difference here? Perhaps I'm not experienced enough, but the only CPU performance problems we generally face are the "get done before the next packet comes from the driver station" and "don't let vision melt down your cRIO CPU" problems...
  
• deployment speed: it depends. I went and helped my old team with a LV problem last week, and got reminded of the "first deployment takes forever, redeployment of a handful of changed VIs is *so* quick" phenomenon. Java deployments, for major or minor changes, all seem to cost a near-constant-time build/copy/reboot (which will change in 2015).
  
• version control. we've done version control with SVN and GIT. the students *love* looking at a diff between Tuesday and Thursday and being able to answer precisely when the build team asks "ok, what did you change again?". doable with LV, but difficult, and it took us a while to get the tools in place to visually diff VIs.
  
• later applicability. using the language features I learn when programming my FIRST robot is knowledge with a limited lifespan. I was a decent S/360 and VAX assembler programmer once, but those skills are no longer applicable. The underlying concepts are still useful, and the some things (like learning to use an SCCS with good tagging features) are things that last decades. The OO concepts I learned with Borland Pascal is still useful with Java and C#, though the language is no longer widely used. yes, the syntax and APIs learned in FIRST do help with college and the first job, but don't bank on it for longer than that: the underlying concepts you learn carry you past that point, and you'll learn those regardless of language. How much of what concepts you learn will probably depend on language: LV and Java/C++ emphasize different concepts.
  
  
• Greg makes a *great* point: it's a sad day when we don't have a choice. I'm happy my team moved to Java (and they are *very* happy). If the school offers a C++ curriculum, then I'll take my old brain in, have it stretched, and support the students as they learn that. If my team gets smaller or I move to a different team with 2 or 3 programmers that are rabid about LV, I'll support them.
  

so the ultimate answer?

"it depends"...

don't just ask "what's best?". that's a religious war.

it's "we have this many programmers, they have this experience, they are this open-minded, we have this CS program at our school, our robot is this complicated, our workflow looks like this, and <insert more variables here>. What are the pluses and minuses of LV, Java, and C++ in our situation?"