Java vs Labview
 

Hello! I'd like to hear your opinions when it comes to comparing Labview with Java. Thanks!

Re: Java vs Labview
 

Well, they are very different. For a beginner programmer, Labview is great for learning programming logic, however, Labview has minimal application outside of FIRST. Java is great because it is widely used and will be a useful skill for anyone who learns it, however, if someone is just starting to program, they may have difficulty following the logic in Java. It really just depends on how much programming skill you already have, and how much you want to/are willing to learn.

Re: Java vs Labview
 

I usually recommend to teams that they use the language that is most familiar to their programming mentor.

As an aside, Labview is widely used in industry, it's not just a FIRST thing. A quick look at dice.com indicates they have >100 jobs listed with Labview as a keyword.

Re: Java vs Labview
 

LabView was used in the SpaceX Dragon capsule: http://k12lab.com/inspiration/spaceX.

Like anything, each has their pros and cons. You may want to try each one and see what you like better, and like Steve said, see what kind of mentor support you can get for either.

Re: Java vs Labview
 

We teach our students java because it's the AP standard in Computer Science courses taught to high school students who choose to take the course across the US. Also, speaking from experience here, Java was the first language taught when I entered university as a freshman Computer Engineering student. Java is more widely used throughout the world in various computing fields than LabVIEW is at the moment. Therefore I find it to be much more "useful" to my students to have it in their skill-set.

Not to knock on LabVIEW since I myself started out programming in LabVIEW. However when it came down to editing small portions of code to do exactly what I wanted them to do, I found that it was much easier to do in Java. Plus I didn't have any software mentor support at all when I started FRC programming. I used the internet resources like Chief Delphi to find my way.

While I know that there are many jobs that you can get with knowledge of a language like LabVIEW, I would definitely say there are a multitude more for those with a background in Java. The automation and commercial industries seem to be taking an interest in LabVIEW because of it's easier to understand logical and graphical interface, but for someone who has no problem understanding programming logic. I find LabVIEW somewhat restricting. Now had I been mentored properly using LabVIEW as my beginning language I might feel differently, but you can't change what hasn't yet happened.

Just my two cents.

Re: Java vs Labview
 

LabView is actually pretty widely used outside of FIRST. It is actually older than Java. As has been said, it is used primarily for control, automation and data acquisition applications. If you have students who have done FLL, making the jump to an FRC robot programmed in Java will not be difficult. That and the ease with which autonomous routines can be coded are two strong reasons for using LabView.

That said, we have been using Java since we switched from LabView in 2010. The reason is pretty much John said, the kids use Java in AP and IB Computer Science, so we have more Java capable programmers than LabView. As a computer science teacher (who has programmed and taught in C++ and Java) I find that Java's event driven programming paradigm makes understanding robot code easy when compared to using C++.

For me the biggest question to ask is do I have most capability (student and mentor) to support one language choice over the others. That trumps the relatively smaller differences in the capabilities of the languages. All three of the FRC programming language choices will allow you to do what you want with a robot.

Re: Java vs Labview
 

In case anyone is wondering Java or C++ each show well over 10,000.

Re: Java vs Labview
 

Team 900 is (almost) unanimously in favor of Labview. We used Java last year and had all kinds of trouble with getting the robot to actually move. We switched to Labview this year and our robot runs beautifully. Also, most of our programmers this year didn't have any experience with either language before the start of the year and they picked up Labview really quickly.

Of course, the number of programmers on the team at least tripled from last year to this year, so that could make a difference too...

Re: Java vs Labview
 

I'm not sure I agree with that statement. I consider myself as having failed the team this year by insisting on using what I know best (LabView). We had a couple of top-notch Java programmer students who lost interest because of my unwillingness to adapt. As a result I wound up doing all of the programming.

It seems to me that the mentors need to focus on whatever inspires the students and step back and let them go at it with occasional guidance when they go off on an unproductive tangent.

In the meantime. It's back to the Java tutorial for me.

My $.02

Re: Java vs Labview
 

For me it all really depends on the programming team as a whole. I am currently doing AP computer science learning java, but I am using LabView to program our robot. Our mentor for electronics and programming used LabView for awhile and we continue to use it until there is a want to shift. I haven't touched the java libraries for the FRC competition, but it shouldn't be difficult to pick up after reading the documents about it. I hate the discussion of which language is superior to another, because it just pressures people to go with a language they're not comfortable with. Between java and LabView, I have no preference of one over the other. They both work well and to for me it comes down to how do you want to see your logic.

Re: Java vs Labview
 

I'm not a neutral party, but you asked for opinions.

For your team?
I honestly don't know enough about your team to be able to make a recommendation. So, I'd say that you should look at the capabilities and ambitions of your students and mentors. It is quite easy to go through tutorials and program your robot in each of the languages and make your decision based on which language provided more successful moments. That is an intentionally vague description since success means something different for each team. In some cases it is a better robot, in some a better learning opportunity. Some want the easy road and some want a challenge.

Also, a bit of background.
What is LabVIEW? LabVIEW is a relatively popular domain specific language. It is generally not free and not targeted to general computing domains. People who program with LabVIEW don't normally consider their job title to be "LabVIEW Programmer". They are instead a physicist, a mechanical engineer, a test engineer, a robotics engineer, etc. This is true of many professionals who use Java as well.

FLL, by the way, has exclusively used a version of LabVIEW since the beginning. ROBOLAB, NXT, and EV3 all ship with a version of LV for young kids. ROBOLAB was actually an iconic language written in LV, but wasn't really a LabVIEW equivalent language. Additionally, WeDo the jrFLL language was designed for even younger kids. It is a cross between Scratch and LV and was written in LV.

My actual advice?
It isn't which tool you choose. What matters is how you decide to approach the task of programming the robot. I am thrilled when students truly understand how their mechanisms work and how their code plays an integral role. If only it could happen more often.

Greg McKaskle

Re: Java vs Labview
 

We were trying to decide on whether to do the reverse thing for next year (switching from Java -> LV), so we did an informal survey of the teams at our regional this weekend. Surprisingly, out of 33 teams, 3 teams were using LV, 2 C++, and most of the rest Java. It blew my mind how popular Java has become since it was introduced less than a year before I came into FRC.

We have used both languages, and here is a comparison from my experience. IMO, they both have their merits but I personally prefer Java, so that's my bias.
Java:
+ Easier to find and solve fatal bugs. When program fails, Java tells you exactly where it does and what you need to do to solve that problem, sometimes even if you have never seen that error before. Code errors are easier to post onto Chief Delphi and stack overflow than screenshots of your LV wiring.
+ Faster deployment cycle. 52 seconds on ours to be exact, yes we counted. The 4 minute LV re-deployment on our laptop can be a major problem if we have to make even a minor change in the elimination rounds. LV is also a memory hog, which is ironic because a lot of traditional programmers consider Java a memory hog.
+ More intuitive for "software engineers". Lines of code and all. Taught in AP CS and college intro CS courses. I've heard that LV is more intuitive for EE people with its resemblance to circuit diagrams.
+ Source version control. In a good IDE, revert your code to what you had at 12:34 pm on May 6th, 2007. The "undo" function for LV is very limited, and you can't compare code differences on GitHub or something similar AFAIK.
+ Documentation. You can browse through Javadocs on a browser, whereas my experience with searching through LV functions is a nightmare-filled trip into a Windows Help style interface. In Java Netbeans, you can hit control+space and have it come up with every available function for a certain device, listed by contextual relevance.

LV:
+ Click and drag. How much easier does it get? If you know "line-based programming" before you learn LV though, it can be a nightmare.
+ Easier to tune specific functions (ex: PID). You can add a bunch of controls to the frontend without adding much code. Sometimes Java's Smart Dashboard just doesn't cut it.
+ More support at our FRC regionals. The control system advisor team is filled with NI people. For Java problems, be prepared to consult your neighboring Java gurus.
+ Easier to implement concurrency. You can easily do multiple things on the robot at the same time. On the other hand, you can easily do multiple things on the robot at the same time (which can be unintended). I heard some teams using the subsytems thing in Java have this pretty easy too, but have yet to try that.
+ Sample code. LV sample code for FRC beats out Java sample code hands down, especially in the vision department. It's been developed longer, and it just covers more.
+ Vision. LV is better for vision development hands down. The fastest way to develop vision code in Java is to do it in NI's software, then copy the filters back into Java. The simplicity of it all is really one of the best unmatched feature LV has over Java.

For a decision, as others have mentioned it may be important to consider what the mentors and team already know. However, both languages are easily learned, and the most important factor is by far the personalities of the programmers:

If you have hardcore software writing students who know every single shortcut key available on the computer by memory, think wiring and electrical are hardware problems, and have 4 different flavors of Linux installed on their home computer, making them do LabView is going to end up in disaster.
Actual quotes: "why the !#%$ are these being executed at the same time", "give me a break, I just copied and paste and now every wire is broken", "I hit the limit on the Undo button so we lost everything we did yesterday"

If you have hardcore electrical students who know what every number on their 8-function multimeter mean (yikes), can trace 6ft long PWM wires through spaces too small for adult hands, and dumpster dive for broken down lasers in their free time (all real life examples), Java may not be the best idea.
Actual quotes: "frigging red syntax errors everywhere", "why did it only work the first time", and my personal favorite "I think we fried Java"

Re: Java vs Labview
 

Last year we used LabView and had nothing but problems. This year we used Java and out cRio crashed during our first event. After re-imaging it in safe-mode, we were able to get it up and running...

The trick to using Java: Image the cRio and select the Format Controller with a LabView image. Then image it again as Java without the Format Controller option selected.

Since then, everything has been flawless.

Re: Java vs Labview
 

This only applies for programmers who are inexperienced with computer vision. If you have two programmers with, lets say 3-4 years of experience in java and labview independently, the Java built (if we had a third using C++ he'd trump them all) will be faster and more percise. Note that in WPILibJ, some vision functions were missing and need to be wrapped

That is a great example. Just look below the search box

Search job title only (e.g. Java Developer)

100 jobs for labview, 16000 for java. With this ratio, for every team using LV there should be 160 teams using Java to balance the market demands.

This is probably the only scenario where Labview is good, you have a bunch of people inexperienced with code and just were inspired to write code because of the god tablets slid into their pockets, though Patrick does make a good point

Also, our team leader worked as a CSA at our 2nd district this year and noticed an enormous amount of teams (even rookies) using Java compared to last year.

Re: Java vs Labview
 

Why do you say that?

Re: Java vs Labview
 

I'm not sure I agree. NI Vision for LabVIEW has all the same features and functionality as the C++ version, and the Java version is just a wrapper for the C++ version. The VI's and classes are equivalent between the two. Our 2012 vision code was made with vision assistant for labview, and we used the same vision assistant algorithm for our 2013 java vision system, which worked exactly the same way as the 2012 one. All the vision VI's have classes that can be accessed in C++ and Java that have the same functionality.

Re: Java vs Labview
 

Maybe the algorithms are the same, but the raw speed is alot faster. Knowing what algorithms you want to use and simply typing them out is alot faster than dragging them from a box. Imagine typing this response by dragging a list of 100 words from a box into the text area. Personally, I've walked around Kettering and Traverse City and I didn't see a single LV team using a targeting system they built themselves.

As far as C++ over Java, dealing with pointers when handling images is so much nicer than dealing with complex structures.


The Java wrapping for the C++ library is incomplete. Take this snippet for example

~12 functions are API'd out in comments but only two of them are wrapped. For example, ~week ago I needed to rewrite our VP because the LED's from the white line arent close enough together to form a perfect rectangle so I needed to dilate the binary image, but NIVision.java had no dilate wrap.

Re: Java vs Labview
 

This is a debate that has been going on since we've had a choice of multiple languages to choose from. There really isn't any "right" or "wrong" choice or one being better than the other when it comes to this particular environment. It's matter of preference, skill sets and risk.

Let me share a little of my background so you may understand where I am coming from with my analysis for the choice of language. I'm the Mentor for my Team for both Software and Electronics. I've been a low level ASSEMBLY language programmer my entire career (33 yrs). I personally don't like any OOP(Object Oriented Programming) whether it be JAVA, C++ or Labview.

However, these are the choices we have to work with. So let me share my reasoning for recommending Labview.

#1) Risk - Software stability.
79 Bugs found in C++, 32 still open.
68 Bugs found in JAVA, 21 still open.
24 Bugs found in Labview, 10 still open.

Here’s the link where I obtained that information:
http://firstforge.wpi.edu/sf/go/projects.wpilib/tracker
Hence, Labview is the more reliable and stable platform.

#2) Interoperability
The hardware(CRIO) is designed and manufactured by NI as is Labview.
They are meant to and designed to work together seamlessly.
The JVM is by Oracle, FRC Java Library is a port by WPI, as is C++
(Do correct me if I'm mistaken on the port statement).
As such you now have 2 additional and different software vendors.
Do we all know the expression, too many cooks spoil the soup?
So if there is a bug where is it and who do you ask to correct it?
Is it my code? Is it the Library? Is it the JVM?, or is it the hardware?

My own personal summary.
1) National Instruments makes and supports the CRIO and it's Modules.
2) National Instruments makes and supports LabView.
So when something doesn't work as it should or as designed then you only have ONE company one vendor to go to for a solution.

I have had this very issue in my professional career with software and hardware products that are "supposed" to work together.
Here's how it usually goes.
Vendor A says it must be something with Vendor B's product.
Vendor B says it must be something with Vendor A's product.
Round and around it goes, until someone other(usually ME) than Vendor A or Vendor B clearly identify who's problem it really is.

So I'd rather have one vendor to point a finger at, that can't point it at anyone else except themselves.

I'm only sharing my thoughts, my views, my experiences, the decisions are ultimately up to your team.

Re: Java vs Labview
 

LabVIEW tends to get a bad rap for its graphical nature. When the cRIO was first introduced to FRC in 2009 I saw the choice of LabVIEW and C++ the same as I saw the choice between C and EasyC on the old controller. I told myself that 'I'm too good' for drag and drop. It turned out there is a lot more to it than that. LabVIEW has some powerful constructs which do take time to master, and the front panel features make tuning/debugging incredibly quick and easy.

I would actually say that LabVIEW has a steeper learning curve than its text based counter parts in many ways. As in any langauge it is very easy to make bad LabVIEW code. It seems that a lot of people stop learning the language when they have some of the basics down, and we end up seeing massive VIs of untamed wires and flat sequences which become hard/impossible to debug and maintain.

In the end I agree about using the language that you have a mentor/student with a good understanding in. When you have an instructor with a good understanding of how things work, it is easier to teach it, and more importantly prevent big design mistakes early on.

I would be interested in seeing the data behind this claim, or some type of metric. Do you have a side by side comparison of the raw speed for various algorithms? I would assume all three languages would be nearly identical since they all call the same functions. Honestly I would expect Java to be the slowest since it has to run on the JVM level compared to C++/LabVIEW which are both compiled to assembly with many optimizations along the way.

Knowing what functions you want and using Quick Drop I would imagine is close in speed to typing the name out in Java. Also the percent of time spent on actually writing code vs debugging is an important factor.

Its all about iterative design. In reality nobody is building a vision system 'themselves'. All of the functions and ideas we are using are built from years of industry and academic research as well as learning from previous years.

Should every team be reinventing the wheel each year? Most teams use the same type of algorithm, which is what the targeting system has been designed for. The example vision code is a good starting point and having a working vision algorithm is a big accomplishment for many teams. We don't all have to dive into OpenCV on a BeagleBone to track the retro reflective tape.

Re: Java vs Labview
 

That line was meant for writing speed, not execution speed.

Although, I know I have 3 CRIOs on hand to do vision processing, though I don't have any of the development software for LV. I'd be interested to see a speed test too. Guessing the fact that its Java ME and not SE, the order would probably be Labview > C++ > Java (but the times will be remarkably similar, as the C++ and Java vision libraries simply uproot to the LV libraries)



BinaryImage dilateImage = NIVision.dilate(threshholdImage, 3);

theres only so many functions to use.

Of course, this is an opinionated topic. Even so, I can't imagine doing something like our team's 2014 code in LV. We have 5011* lines spread along 31* files and selecting each of their functions individually is a pain, not to mention that our auton system is a vectorized system of quadruple key-value pairs generated from binary information read from files on the cRIO.

Petoskey Paladins won an award for an OpenCV Raspberry PI :O no idea what a BeagleBone is

I agree that not every team should be doing what the Paladins did but spoonfeeding the entire code to the programmer doesn't really teach him anything.

E/ Here's a snippet of code that took me a half hour to write in Java (few more to tune) and wouldn't even dare writing in LV

E/ Just noticed your signature. Of course you cant diss LV when you're getting paid to write it!

Re: Java vs Labview
 

I can imagine it, but that isn't really the same task. Procedural languages require you to name variables. Wires are not named. For loops and case statements are one drag for numerous lines of code. The editors are different. The languages are different.

The first year of FRC I watched a C++ programmer with print statements streaming by at a million miles per hour. I started helping and they kept adding print statements and waving the target around. We eventually hooked the camera up to LabVIEW, probed the image, saw that the camera wasn't focused, that the C++ programmer was holding the target way too close to the camera, and that they needed to modify the color threshold.

The tools are different and that is a good thing. FRC is all about exploring and learning new approaches. I don't use LV for all projects and I don't use C/C++ for all projects. Make your own choice, but please don't misrepresent.

Greg McKaskle

Re: Java vs Labview
 

... If you're binary image is returning dark you should probably throw out some test images on the different threshholding stages to make sure they're all behaving properly. The problem at hand here wasn't C++'s lack of proper probing techniques for vision processing (not familiar with C++ NIVision but im assuming its basically like Java) but rather the programmer's infamiliarity with proper computer vision debugging techniques. Those images could have been probed with BinaryImage.write

I can understand what you mean, but my main point is that if you're promoting the usage of LV as a language "used in industry," it seems misleading to someone who has no idea of the difference between languages. If you're planning on going into the industry with skills in programming, there are more diverse work options when you're working with a more well-known language. As i stated before, if you just want to learn programming as an introduction trade into engineering or just to try new things and have mentors that are comfortable with LV, than go ahead.

(Note that i edited that past post about four times before you posted)

Re: Java vs Labview
 

If you do machine level programing in the real world, it is likely not to be Java. Plant automation is generally done with languages proprietary to the hardware used in the plant. A lot of times it is a combination of structured text, ladder logic, & function blocks. They all have their strengths. If you end up with a career in automation, you will eventually learn to use them all.

Re: Java vs Labview
 

Some of our programming mentors have noted that learning languages becomes easier as you learn more (well given they have documented APIs)

Re: Java vs Labview
 

There is something to this analysis. If you want to "color inside the lines" and have the best vendor support you should use whatever the vendor would have the most incentive to make work right. And that is Labview.

But the quality of support offered does not need to be the deciding factor. Last year, my team used C++ and had some issues. This year we're still using C++ but we've basically junked WPIlib and gone our own way. And life is beautiful now.

Re: Java vs Labview
 

Oh, I diss it plenty, but then we go about trying to improve it.

The story about the professional C++ programmer trying to do image processing was simply a counter example. She was fast at typing code. She could add print statements super fast. But they weren't the correct tool. By the way, the probe in LV is where you right-click on a wire, choose probe, and a window opens to show you the live image at that point in the processing chain. The program keeps running, you can move the target, focus the camera, tweak the panel values, add an additional probe, etc. It isn't a language feature, but an IDE feature because NI and LV sell tools to do this sort of thing. We also used to sell a C/Basic IDE and compiler, but that is now simply a library that plugs into MSVC.

The "used in industry" or "most popular" judgements don't carry much weight with me either. I think it is better to identify a strategy for evaluating the tools on a realistic task. Evaluate, choose, use and become proficient.

New task? Rinse and repeat. There is overhead in learning a new tool, and overhead in using the wrong tool for the job. Find the balance.

The evaluation period can involve asking for popularity or opinions, but that only gets you so far. If we substitute music for robots, which instrument would you learn? Is it a waste of time to learn how to play an instrument that isn't popular? Learning musical notation, theory, and lingo are valuable whether you learn the violin or piano, but neither will work well in a marching band.

I think the topic here is productivity, not typing speed. The ability to progress from a problem statement to a reliable solution is common to much of engineering, industry, and life. LV's initial adoption was actually in instrument control. Composing and parsing packed arbitrary streams from oscilloscopes, DMMs, signal generators, scales, power supplies, etc. Programs would then be written to setup, evaluate, and sequence the instruments to automate repetitive testing. It is not that different from what you posted. So others have dared, succeeded, and their code has been running for decades.

As for the performance of the vision code:
By design, NIVision is divided into an inner library of kernel functions and outer rings of language wrappers. 98% of the processing time will be spent in the same code regardless of which language you choose. There will be some differences in allocation overhead and your own logic as to which operations to perform.

Back to the original topic. My goal is to get teams to learn a bit more about programming, computers, measurements, and control. And that means everyone on the team, not just the programmers. I kinda hope that all the robots don't look the same. I kinda wish they were more automated and more autonomous. I don't work in marketing or sales, so this popularity contest isn't really that exciting to me. I see amazing robots programmed in all three languages. And all the time I get to see kids gain confidence as circumstances require that they become the team programmer at the event and make the robot do stuff they didn't think they knew how to do.

Greg McKaskle

Re: Java vs Labview
 

We have tried C++ from 2012-2013 and we used labview in 2011 and this year.

From my experience (and I should note that I know Java, Labview, and a little of C (Enough to get my arduino running cool things)) C++ is harder to change and debug than labview. With labview, if we need to see why something isn't running right, we just probe and run in RAM and we can find the problem in minutes. C++ always seems to take longer for our team.

It is also easier to follow the flow in labview, especially if it isn't a tangle. C++ isn't something I could figure out.

And in terms of speed: Your teleop loop is running at 50ms. As long as it runs that speed, I dont see an issue. We even have periodic tasks running at 10ms for some loops.

TL;DR: Labview is easier for our team and we get the same performance.

Re: Java vs Labview
 

Almost every time I get in to a discussion about which language to use for FRC, someone starts talking about which language will yield faster programs. And the truth is that, compiled on to the cRIO there is not a "this language is faster than that language" rule.

It is true that in general if you write a program to run on your computer that a C++ application will run faster than a Java application. (Even this is a general principle and not a rule.) Because the Java application is compiled to Java byte code and run on the JVM. But when you compile Java into an application to run on a specific platform this is no longer a general principle. For example, I once used xCode to write some simple OS X native applications. I wrote the same applications in C++ and compiled them into OS X native applications. And which version was faster depended on what exactly I was doing.

For example, LabView is really good for integrating sensors and C++ is not natively friendly to event driven programming so the code is often not as natural to develop. Language choices always have tradeoffs, and it is more the exception than the rule that there is a clear "best" choice absent other constraints. If someone tells you that they use C++ (or any of the other choices) because "it is an industry standard" or "because it is faster" or my favorite "because it is better" (rather than "because it is better at a and b, which we do a lot") they probably have not made a well-informed decision.

A friend with a lot of C++ and LabView experience, who has programmed in Java quite a bit the last few years said that he would pick based on what the programming team has experience with. But absent that, he would say the more sensors you have, the more it makes sense to use LabView. He also said the bigger the overall code base, the more it makes sense to use C++ or Java. And in spite of his vast experience with C++ he nudged his team toward Java.

My own programming experience started with Fortran punch cards, then typed Fortran. Then I moved to Apple I Basic. At one point I was writing C and C++ large number processing algorithms for sensors and communication systems. I have used assembly. I also ventured into Pascal for while. I have taught C++ and Java. The past couple of years I have also taught MatLab. I used to be very resistant to OOP. I have come to believe that the larger the program, the stronger the case for OOP. I used to think that pointers we way better than the cumbersome structures used in Java. Then I started debugging big programs written in Java and I said "Wow, this takes a lot less time than it used to." I still use C for a lot of tasks. Lately I have seen a number of cool education-oriented tools with compiled Java (not the JVM) on machine level systems that run continuously and I think "The garbage collector alone is reason to use Java." I would be very willing to consider switching languages if we used RobotC (and its debugging tools). Again, my point is the same as a number of others. There is no best choice. Just make an informed choice and know that a well written program in any of the three language choices is probably going to run a lot better than a poorly written one in a supposedly better language.

Re: Java vs Labview
 

Not my experience. (And I know Java and C++ way more than LV.) Testing and debugging vision in Java or C++ has been a pain. It's a visual thing, so it makes sense a visual language does it better. The real time debugging features are pretty convenient too.

Comparing number of bugs reported on a single bug tracker is a pretty poor metric. It could be there are less people using LV, or maybe the opposite is true. It could be people using LV are reporting their bugs elsewhere. It could be because the Java and C++ bugs were solved 2 months ago but the people who develop for those libraries received the bug reports on another platform and didn't close them here.

The FIRST tracker may be "official", but I personally don't know anyone who uses it to report bugs. If anything, comparing the number of problem threads on Chief Delphi and replies would be a more comprehensive metric for which tool is more stable.

Hint: It's not the library, it's not the JVM, and it's not the cRIO. In all my 5 or 6 years of using FRC Java, I have personally never had to solve a problem that had to do with the library or the JVM or the cRIO, and I've never had the library behave in a way that is illogical for me. For me and the majority of teams I've helped or talked to at competitions, the library is never the problem.

Does this mean that the library is bugless and completely stable? No, but it's a much smaller problem than people seem to be making it, to the point where it's not a concern for most teams that will be using the common functions of the library.

Here's the thing though: FRC is designed to emulate real life engineering where knowing the vendors is important and you need to have fire drills on who to call if something fails, but for most teams, that's just not how it is.
The cRIOs, libraries, JVM...etc are all fairly reliable. The biggest points of failure are usually the wiring on your robot or the code that you wrote. Pointing fingers at vendors is much less helpful than being able to debug and solve your problem immediately, which I'll argue that text based languages are better for.

You can have spaghetti code in any language. It's just more literal "spaghetti" in LV. ;)
I wouldn't say it has a steeper learning curve. For a all the basic functionality on top of a robot (without fancy custom steering code, PID, or vision...etc), you can learn to program in LV before you learn why you should be setting the value of the jags to a double in Java or C++. Unless, of course, you already knew a text based language.

Not even close. Say we have a robot with 4 jags, and each need to be controlled by a separate joystick. Don't ask why, the team needs it done now. In Java, the project takes 5 seconds to create, I can write up the code required in 30 seconds (conservatively), deploy to the robot in 52 seconds, go get a soda, and be back before the LV project is even fully created.

Comparing the code production time, I'll assume you're fairly fast and don't make mistakes in LV. It takes you at least 2 blocks for each jag, open and set, then you need 2 blocks for each joystick, open and set, then for each you need to specify the port, module, and channel constants, and then wire them all together.
Then, copy and paste 4 times and change each constant. If the whole thing is in a while loop, you also need to clean the broken wires and then rewire each time. Even if each palette you need is already pinned on the side (or using quick drop), I have a hard time seeing anyone do all that in 30 seconds, not to mention LV sometimes needs to open up new files whenever you access new tiles for the first time.

Come on, now. There are things that are easier in LabVIEW (like debugging vision as you said), but for loops and case statements are not them. How much does it really take to create a for loop in text code? 2 seconds? Creating and hooking up the constant true/false conditional in LV takes more time, and finding the comparison operator in LV takes time too.
Imagine if you had to do a perfectly reasonable conditional like (a && (b || c) && (d < e + f * g)), the race is over for LV at that point.

Re: Java vs Labview
 

Greg,

I'd like to make a suggestion that I think would make editing in LV a little easier.

You see I have this love/hate relationship with the tools pallet. Sometimes I find that the tool auto select feature is very handy and at other times it just drives me nuts. Usually what happens is when I'm simply trying to use the pointer tool to select a vi in order to move or copy it but then milliseconds before I click the mouse I get too close to a terminal and it changes to the wire spool. Now I have to stop what I was trying to do and reach over to the keyboard to hit the escape key to shut off the wiring function. This really disrupts the flow of the work and I hope none of the students hear the comments muttered under my breath. I know I can turn the automatic selection off but then I'm constantly having to manually change tools. There simply has to be a better way of getting the right tool at the right time.

Anyway, one feature I'd like to see is a magnifier/zoom tool to help these 65 year old eyes to better see exactly where the pointer is with respect to the object I'm trying to work on whether it be a vi, a structure or an item on the function pallet. That would really be helpful. Especially on the typical driver station laptop with its dinky 13" screen.

Thanks for your continued support to the teams.

Dave Tanguay

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.

Re: Java vs Labview
 

None of us do yet we come back for more punishment.

Re: Java vs Labview
 

+1

Re: Java vs Labview
 

Look at Parkway from Virginia. Most of the issues after in the initial inspection issues were related either wiring or Java issues. Most of those Java issues were traced back to wiring or mechanical/hardware related.

I will say LabVIEW will get you up and running quick once you are coding. But While LabVIEW is installing, I can be testing and coding in JAVA provided I have an internet connection to do the updates.

Re: Java vs Labview
 

Was this because of bugs with the library causing it to not work, or just that you didn't know how to use it?

I have had the opposite experience: I can code a robot in Java significantly faster and better than in LabVIEW. Despite having more experience with LabVIEW.

As for which is easier to pick up if you are already into the build season: I think it depends on your robot. If you are going to need to make some complex code with PID and sensor feedback and a lengthy autonomous, Java is the way to go. 1-2 hours watching Brad Miller's youtube playlist on using robotbuilder, and your ready to dive in. But for more simple code, LabVIEW is probably easier to learn the basics due to its more self-explanatory structure.

Re: Java vs Labview
 

1- Not sure, didn't want to waste more time trying to root the problem. Thought the library was self-explanatory so it might be the former.
2- I probably would be able to do the same in C++ if we could get it to actually work
3- I learned about Mr. Miller's playlist just last week, would've really helped but whatever

Re: Java vs Labview
 

2 ANDs, an OR, a multiply, an add, a comparison. Now, if we include the inverting blocks, which will be another 2, that's a lot of blocks to be dragging around.

Point is, even if you do it in 3 (I can't think of a way now, but I'm sure someone better at LV than me can do it), that's still quite a bit slower than typing it out. Now, if you wanted to change the sequence or change the order of blocks... that's even more labor in LV.

A way that LV could (and IMO should) speed up this process would be to allow people to put together parts of the program while typing code. That way you wouldn't have to sacrifice any of the features and still be able to get things done faster. Maybe there is some way of doing this and I'm just completely ignorant.

Also, I don't know what they have against if-statements. Every C based language has if-statements. Plenty of visual languages out there have if statements. (Scratch, which is where I started programming in middle school, is a great example) How hard could it be to add in another block for if statement. They already have case structures. Someone out there's probably made a SubVI for if statements. If LV followed more traditional terminology and added in some basic stuff, they could totally convince a lot more people to switch without confusing their existing user base. Just a minor rant from a text programmer's perspective.

Re: Java vs Labview
 

I think a case structure can function as an if-statement; just wire a boolean value to the condition terminal. Am I misunderstanding?

Re: Java vs Labview
 

You're absolutely right and they do the exact same things (forget cases, I can use a while or for loop for the exact same functionality too), so this is going to seem like a petty request for some people, but the question I'm proposing is: if it ain't broke, why change its name? In every C like syntax language, there's an if-statement. I'd have to think hard to come up with a language without an if statement. Smalltalk, maybe?

It's extremely confusing for people who knew Java/C++ or most other programming language and switch to LV and find that something that is functionally the exact same exists but under a completely different name. It's things like this that turn people off from using LV, and first impressions matter. It took me a few weeks to be convinced that LV wasn't the language of the devil, and some other programmers I know still hate it with passion. (There were other LV interface quirks that had impatient high school me pretty annoyed: autoformat was too compact, copying and pasting over a while loop brings out a new dimension, broken wires everywhere, tiny connector nodes, unintuitive true/false in code, auto connecting with new blocks in proximity...etc.)

Then again, these are issues that most new programmers won't be having issues about and other languages definitely have their own problems, so what do I know? :)

Re: Java vs Labview
 

Fair points all around. I find that LabVIEW is easier to teach to people with zero programming background and are interested in control systems. The fact that it's proprietary is a bit of a turn-off, but I haven't had any bad experiences with it so far (and I had two summer jobs which forced me to use NI products exclusively!). That said, I'm still torn on whether I would use Java or LabVIEW to program a FIRST robot. Probably Java, now that I'm finishing up my CS degree and am very comfortable with OO paradigms. But if I'm working with students who still have much to learn, I like the intuitive nature of LabVIEW programs.

Re: Java vs Labview
 

That sounds like a good idea. And as I mentioned near the top of the third page. algebraic statements have been a part of LV since version 1.0. They are mostly for compact logic and math statements. Trust me, we have nothing against text or math or traditional ways of doing things. When we finally get around to it, there may/will also be a way of doing your logic with truth tables or K-Maps. But for now, algebraic and graphical are both supported.

And this is a good question. It is phrased in a somewhat confrontational way, but there is a question in there.

One of the values in seeing other languages is that not all languages are C-based, or Fortran or Algol either. If LV were a graphical version of Java or C, it would make perfect sense, and we might as well throw in break, continue, and goto statements as well. But, LV is a data flow language -- pretty different on purpose.

So here are the technical reasons why LV doesn't have an if/else.
1. If/else statements are the primary way to introduce uninitialized variables.
2. elif statemetnts often reevaluate expressions or bring in entirely new statements. This makes side-effects like leaving a motor running unclear and unpredictable.
3. The language is simpler to learn without it.

More detail:
#1. LV wires can be thought of as automatically named, tightly scoped variables. By making the if/else into a case, the else frame is required, and all values/wires/variable updates that happen in one frame must happen in all other frames. This forces the programmer to think about and deal with all conditional branches before they start running the program and forget. Most textual compilers go to great lengths to identify uninitialized variables, but they have to compromise between obnoxious warnings and runtime errors. By looking at the problem differently and not adopting the looser style of if/else, these issues are reduced by a huge amount.

#2. The evaluated logical expression inside the parenthesis of the if() and elif() can hide side-effects such as allocations, modifications to refcounts, and modifications to I/O. This is a common source of behavioral bugs. Case statements don't have this issue.

#3. Scratch is another popular graphical language. We work with the MIT Media Lab pretty regularly on LEGO stuff. We have plenty discussions about the tradeoffs and compromises in the languages. Note that they have two forms of if and no case. Neither has a goto. Hmm.

The point?
If you see a language that is missing a feature of C, or a feature of Scratch, or a feature of LV, it is good to notice it, good to question it. It may be that the authors of the language were lazy or sloppy, but that is pretty unlikely. More likely, the overall structure and goals of the language are trying to guide you to do something a specific and alternate way. Maybe their alternative way is better, maybe worse, maybe different. Ultimately, you decide, but learning the language and considering the alternative will at least stretch your brain a bit.

One last point: I sometimes find that people assume that computers understand the C language. They assume that the processor knows what an if() statement is and what a variable is. This simplified understanding is not correct, but it really doesn't affect anything while they learn the C language. But that clouds things with the learn the next language. They assume that Java is just some macros or some translation of C. And they make the same assumption about LV.

Just to be clear. The LV code you write does not get translated into C. It doesn't get translated into any textual language. It gets compiled into chunks of machine code that are scheduled based on runtime data flow and timing specifications in your diagram. Portions of it are close enough in concept to C that you can pretend they are the same. Other portions are different enough that you shouldn't.

By the way, the FPGA code is also written in LV. It actually does get translated into a textual language -- VHDL. The VHDL goes through sophisticated compilers and tools from Xilinx that produce the bit mask that defines the FPGA behavior. And there actually are other tools that translate LV diagrams into C, but they were built for embedded environments and they do not support all LV language features. The general LV that runs on cRIO and on Macs and linux and Windows computers directly generates machine code.

If you have other questions or comparisons I'll be happy to try and answer.

Greg McKaskle

Re: Java vs Labview
 

The flip side is that for people who start out learning LabVIEW, it's confusing to find that the equivalent of a Case block is done in a procedural language like C using several completely different structures, each with utterly different syntax.

Why is the name such a big deal, anyway? It's a different language, and things do not map directly from one to the other. If you insist on calling things by the name of something similar in another language, I think you make it even more confusing. Someone looking for something that acts like a C "switch" certainly isn't going to expect to find it named "if".

Re: Java vs Labview
 

Interesting take, but I still don't understand why an if-statement would be functionally different from case statements at all. A proposed if-statement structure would basically be a case statement, except it only takes boolean values, right? There wouldn't be any more null variable problems than case statements. And then, have a way to right click and attach else ifs to the initial if. I'm actually not sure if I understood this point though. What's the concern with uninitialized variables?

One benefit of this would be that it's easier to visually identify and understand long chained if/elif/elif/elif/elif.../elif statements where you have different conditional in each elif.
Example:
if (a == 1)
else if (b == 2)
else if (c == 3)
else if (d == 4)

An if-elif structure would be 1 structure with 3 squares attached to the bottom. If you're using case statements, you'd stack 4, one in each other. I'd argue the former looks nicer and more intuitive.

I agree that C style languages goofed up with the switch/case and the if statements using completely different syntax, and the falling through behavior is kind of weird. Probably something to do with legacy and how code used to be written. However, adding support for a new syntax (in this case, an if statement) almost always has less impact than getting rid of something, which is why I wish LV had an if statement, instead of wishing C got rid of if statements.

Another analogy would be like if NI decided that they're going to start calling while loops "gobblygooks", booleans "dingdongs", and arrays "cheeese". While they're at it, also make trues red and falses green. It's their language and it'd be perfectly within their rights to do so, nothing is functionally changed and LV is just as powerful as it was before, but it's one of those things that at least warrant the question, why?

Re: Java vs Labview
 

An if statement without an else has no way to specify values for the !if cases.

If(x==3) y=4;

When x isn't three, what value will y have? Perhaps y is already initialized, perhaps not, and that is an opportunity for an uninitialized variable. Sure, one x and one y and it is trivial to see, but as things scale, the structure and the usage pattern lead to a very large number of potential problems.

If/else is equivalent, and the documentation and instructors will typically say something to the tune of "If you are familiar with if/else statements in C/Basic, the Boolean switch is the equivalent". Then they should explain that the other case may seem unnecessary, but lets you ensure that the wire-equivalent of y gets a value that you explicitly specify and think through.

Right-clicking and arbitrarily adding else ifs to an if is prone to building an incomplete or tangled set of logic. For example, if you have four integer variables, a, b, c, d, and that is the complete logic statement, I'd schedule a code review immediately. That is almost guaranteed to have holes in what it handles and how it handles it. Similarly, a series of nested Boolean cases also raises my eyebrows, but it has a higher chance of being written correctly because of the else's. In all likelihood, the variables need to be transformed first into a more explicit state variable, and the action switch is driven that new value.

The other issues with cascading vertical boxes is that the either cannot have wires that leave their border, or the wire coordination is very unclear. This occurred in Mindstorms NXT. LEGO asked if we could draw the case statement flat, with a simultaneous view of all diagrams. The tradeoff is that wires may not cross the structure boundary. The 3D structure of the case, becomes nasty and difficult to edit and visualize when disassembled and placed into 2D.


For an example of the consideration that goes into extending any language and comparing it to existing de facto standards, here is a paper that describes why object oriented LV was done the way it was done. I don't have a paper for the equivalent thoughts on if/elses and cases, but I'm pretty sure the conversations did take place.
http://www.ni.com/white-paper/3574/en/

Greg McKaskle

Re: Java vs Labview
 

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.

Re: Java vs Labview
 

I believe Java (and C++) are more general purpose. 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. You can easily find a microcontroller or some development board that runs either Java or C++, and It'll be in the affordable range, good devel boards from $10 to $500. With Java or C++, you will be able to have a bit more of fun, because there are many APIs to allow you to do hardcore game programming. C++ and Java are also going to be more relevant in school because it can be used within classes to improve the course. I am working on an OpenCV application for my old Physics teacher because he is using those expensive DataQuest modules. Instead, I can set up a single computer and the other students can upload a video of their experiment to the computer. That'll quickly analyze their lab and give them the information that they need/want!

Re: Java vs Labview
 

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

Re: Java vs Labview
 

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.

Re: Java vs Labview
 

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.

Re: Java vs Labview
 

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.

Re: Java vs Labview
 

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 :D). However, I did find the interface quite confusing.

I hope this helps ;)

Re: Java vs Labview
 

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

Re: Java vs Labview
 

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!

Re: Java vs Labview
 

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?"