PROGRAMMERS: WIND RIVER C++ vs LABVIEW vs JAVA [Archive]

apalrd

01-04-2010, 22:49

Personally I wouldn't call LabView coding at all...

LabVIEW IS coding. It's used often in the real world (although not on production things, many companies use it for testing and experimentation), its optimized to run on cRio's, can run on the FPGA too (although FIRST won't let us do that), has networked front panels, can execute C libraries (using Call Library Function), can run parallel tasks (multithreading) super-easily (try making two WHILE loops in C++ that run in parallel, you won't be able to do it as easy as you can in LabVIEW), the ability to make asynchronous calls easily (static VI ref + Invoke Node), built-in toolkits for PID, fuzzy logic, and toolkits available for many more cool things, through a number of sources, comparable to many C++ libraries. If you are just saying your language is better than LabVIEW, while I see how you could consider C++ or Java "real" programming, LabVIEW is real code too, it runs just as well, it is super-easy to debug, and it's alot easier to code then C++ or Java.

davidthefat

01-04-2010, 22:50

LabVIEW IS coding. It's used often in the real world (although not on production things, many companies use it for testing and experimentation), its optimized to run on cRio's, can run on the FPGA too (although FIRST won't let us do that), has networked front panels, can execute C libraries (using Call Library Function), can run parallel tasks (multithreading) super-easily (try making two WHILE loops in C++ that run in parallel, you won't be able to do it as easy as you can in LabVIEW), the ability to make asynchronous calls easily (static VI ref + Invoke Node), built-in toolkits for PID, fuzzy logic, and toolkits available for many more cool things, through a number of sources, comparable to many C++ libraries. If you are just saying your language is better than LabVIEW, while I see how you could consider C++ or Java "real" programming, LabVIEW is real code too, it runs just as well, it is super-easy to debug, and it's alot easier to code then C++ or Java.
But I will bet you C/C++ was used to program that LabView

AustinSchuh

01-04-2010, 22:52

Just cout or printf() or System.out.print() out the stuff you need, that has proven to do me well, no need for fancy GUI

I challenge you to tune a PID loop with only numbers streaming by. It's probably slower than writing code to plot what's happening yourself and then use the plotting software.

I agree with you that some problems can be easily debugged with prints, but there are other problems that are incredibly hard to debug with prints.

The Lucas

01-04-2010, 22:54

Personally I wouldn't call LabView coding at all...

When I saw this thread I thought "Over/Under 5 posts before some throws out this particular flame" Looks like it a push and I was right on. This argument is getting old and predictable.

My team uses C++ because that is what works best for us. All 3 languages are coding. I suggest everyone try to learn all 3 of them. Trying to argue that any one language is better for programming FIRST robots is a meaningless pursuit, it is all based on personal opinion. They certainly have their own pros and cons (which are fine to discuss) but all are equally capable. Try to focus on what you would tell a rookie team trying to choose between the 3.

davidthefat

01-04-2010, 22:55

I challenge you to tune a PID loop with only numbers streaming by. It's probably slower than writing code to plot what's happening yourself and then use the plotting software.

I agree with you that some problems can be easily debugged with prints, but there are other problems that are incredibly hard to debug with prints.

fstream it, write it into a txt file and read it after to debug... But still :ahh: lots of numbers

davidthefat

01-04-2010, 22:58

When I saw this thread I thought "Over/Under 5 posts before some throws out this particular flame" Looks like it a push and I was right on. This argument is getting old and predictable.

My team uses C++ because that is what works best for us. All 3 languages are coding. I suggest everyone try to learn all 3 of them. Trying to argue that any one language is better for programming FIRST robots is a meaningless pursuit, it is all based on personal opinion. They certainly have their own pros and cons (which are fine to discuss) but all are equally capable. Try to focus on what you would tell a rookie team trying to choose between the 3.

I personally will tell the said rookie team to pick up a C++ book and read it and study and meditate on it, IMHO its way more useful in the real world out of the 3. If you learn C++, you pretty much know Java (except alot of the java specific stuff), won't take you very long to pick up on java. Plus most real world applications are in C/C++, like Operating Systems, Games, and tons of stuff.

Greg McKaskle

01-04-2010, 23:00

To anyone thinking you may be interested in a programming career or a Computer Science or Engineering degree, I'd encourage you to be open to, and in fact get used to, learning new languages. Learn how to compare and evaluate the features looking for the weak and strong aspects of the language. It is also good to learn how to separate the language, library, and environment elements.

Greg McKaskle

apalrd

01-04-2010, 23:05

fstream it, write it into a txt file and read it after to debug... But still :ahh: lots of numbers

Or you could use LabVIEW and draw a graph of the data vs time in real time. Or just probe the variables as you want to see them.

As for your next post, as for the usefulness of C++, many tasks are being replaced by different languages. Look at the Unreal Engine. It does most of the work in UnrealScript, not C++. Look at some Source mods (notably Gmod) - they use Lua for scripting on top of a C++ back end - so the end user only ever works with the Lua end. Real things use a variety of languages, trying to argue that yours is "more used" is useless. Each language is used where appropriate, and will be determined by the user. If you like C++, use it. Don't complain about having to sift through all of the printf's that come with it.

davidthefat

01-04-2010, 23:08

Or you could use LabVIEW and draw a graph of the data vs time in real time. Or just probe the variables as you want to see them.

As for your next post, as for the usefulness of C++, many tasks are being replaced by different languages. Look at the Unreal Engine. It does most of the work in UnrealScript, not C++. Look at some Source mods (notably Gmod) - they use Lua for scripting on top of a C++ back end - so the end user only ever works with the Lua end. Real things use a variety of languages, trying to argue that yours is "more used" is useless. Each language is used where appropriate, and will be determined by the user. If you like C++, use it. Don't complain about having to sift through all of the printf's that come with it.

Well, those are different, they are game engines, I wanna be the ones making the engines... There is a difference, even if its scripted in Lua, its core is C++, its the C++ that uses the Lua SCRIPTING (Note SCRIPTING) language to interpret the game.

kgzak

01-04-2010, 23:17

I use LabView but I also know C++. I started programing in Visual Basic, joined the robotics team knowing very little about programing. My second year I picked up LabView and programed a basic robot in 3 hours. All it did was drive and shoot and had timers for the shooter but it took us to nationals. This was last year, now we have very advanced code that helped us win the Quality award at West Michigan.

davidthefat

01-04-2010, 23:19

Azores

01-04-2010, 23:55

I programmed our bot this year in Java because it's what I already knew best, so I figured I would use it so I'm not spending time learning to use another language instead of actually writing code or helping to actually construct the robot. Originally the programming team for us was planning on using C++, but when everyone else ended up not doing any programming...

Radical Pi

02-04-2010, 00:20

We have 2 programmers (including me), both of us were already fluent in C++ when we joined the team, so there was no argument over what language to use. I have done a fair amount of work in LabVIEW though (dashboard, some NXT programming before I discovered NXC), and I still prefer C++ and other text-based languages too.

On the argument over which language is better, I'd still have to go with C-style. In terms of useability, LabVIEW winds (it's by far the easiest to pick up), however in the more technical aspects it starts to fail. Have you ever looked at a disassembly of a LabVIEW program? I have (for NXT), and it does not look very good. I compared it side-by-side to a disassembly of an NXC program that does the exact same thing, and, even on a VM specifically designed for LabVIEW, the C code is so much simpler. The problem? No optimization. Lots of messy things show up in the LabVIEW that are just totally unnecssary for the operation of a simple program.

This of course, is not meant as a disrespect to LabVIEW. I'd imagine that during the switch from ASM to C there was the exact same argument of asm being so much more efficient than the C equivalents. What made the final difference? We figured out how to optimize the assembly so that the advanced structures of C took as little code as possible, and now it is super-hard to outperform C code in asm and still get a great program.

LabVIEW certainly has a future. It just needs that same time to mature and be able to match the output of the more established languages. Simple numbers can show this need. Earlier in the topic, I saw people talking about ~3 minute builds and downloads for LabVIEW. In C, I don't think I've clocked a full build and download in more than 45 seconds. Usually much less (on a pentium III to boot). Give LabVIEW time to become a high-performance language. Maybe not for the current generation of programmers, but give it 20 years, and I wouldn't be surprised to find dataflow languages creeping into our game engines (assumming the GNU guys get their hands on the language. It's a bit too pricey at the moment)

Al3+

02-04-2010, 02:12

I generally recommend C++ to people who are experienced with programming, and Java to most everyone else. My experience with Java has been that it's design choices make bugs in Java code easier to find. My biggest complaint about Java and C++ is that it's hard to get data back from them in a visually easy way to use.

We've been using text files to store constants recently. So, it's really easy to change constants and they stick across reboots. Edit it on the local machine, and run a script to FTP it up into place.

My first impression of Java (and this will remain my impression until I have to learn it for some reason) was that Java code contains lots of fluff. What is the real difference and what makes it better for newbies? Is it just the fact that it's easier to make memory problems in C++?

(I don't mean to be argumentative; I'm simply curious why it seems to be considered the norm to begin programming with Java. I don't know anything about the language except that it's interpreted and has C-like syntax.)

AustinSchuh

02-04-2010, 02:42

My first impression of Java (and this will remain my impression until I have to learn it for some reason) was that Java code contains lots of fluff. What is the real difference and what makes it better for newbies? Is it just the fact that it's easier to make memory problems in C++?

Java hides the idea of pointers. When I'm working with new programmers, the hardest things for them to learn how to work with are pointers. And not having to worry about pointers gets rid of the entire class of problems that you can get into with pointers. Java also does inheritance with objects nicer than C++. I have come away with a more "friendly" feel of Java after having worked with it as compared to C++.

Also, when there is an error in some Java code, it throws an exception with a nice stack trace, and then dies. This includes trying to dereference a null handle. C/C++ will typically just continue on after having written junk to a random spot in memory, or segfault, or even worse, segfault in an entirely different spot in your code. If you are good with your tools, this isn't that big an issue, but if you are just starting, segfaulting at a different random spot in your code is a royal pain to debug.

I'm not sure I agree with your fluff statement. I interpret you to be talking about code density, and I've found that Java has pretty much the same density as C++, if not slightly better code density.

FYI, Java gets compiled into a bytecode with a JIT compiler, which is pretty efficient. It runs fairly close to native speed.

Greg McKaskle

02-04-2010, 08:19

I'm impressed that you were disassembling the code, but the technology used for NXT and for the cRIO are quite different.

Also, while the issue you noticed is real, it isn't really the language or the NXT-G compiler, but the library differences. NXT-G libraries are kid-friendly and very high level. They are in fact written as subVIs in s simplified LV language. If you use the LV toolkit for the NXT, like they do for FTC, you can write much lower level statements and the overhead goes away.

As an example, in LV, you have a while loop. To construct a While-its-dark loop, a subVI call is dropped and called each iteration of the loop. The subVI is the sensor, and it is wired to the termination. The compiler doesn't know anything about a While-its-dark loop, that is the library and the editor composing something higher level but likely less efficient than you can do if you know the underlying code. Ideally it wouldn't be less efficient, but the flexibility of making While-its-quiet, While-I-have-time, and other loop times usually means tradeoffs. With enough time and effort the template and compiler passes can match hand-coding. But if the language/machine meets the needs of the intended audience, why are you spending money making it faster -- ship it.

As to the cost, ask a mentor how they value a day or week of their time. I believe I'm fully capable of making my own hammer, but I never have. If I want to drive a nail, I buy or borrow a hammer -- nails too. I guess it'd be cool if hammers were free, but wouldn't that really mean subsidized? How does free stuff really happen? The economics and politics is another interesting topic.

Greg McKaskle

efoote868

02-04-2010, 08:48

I have about 4-5 years experience programming in java.

At the start of the build season, I gave our programming team 3 assignments related to the drive train (which, by the way, I'm considering writing a white paper on after the season).
I told them not to worry about the language / syntax, and to worry about the pseudo code and the algorithm.

After each task, I explained the "right" answer (one that worked anyhow). It gave me a chance to clarify the original assignment, and a chance for them to learn a little bit about how to go about solving these math problems.

After the 3 assignments, I told them to code it however they pleased.
Naturally, I coded mine in Java, and the programming team tried to do the same.
I had no experience with Labview, and so another mentor and I went to "port" my code to labview.
It took us 30 minutes to wire everything up, and then an hour to thoroughly debug everything.
It took the others the better part of the week.

It was nice too, because I had made some mistakes in my code (arctan(x) vs arcsin(x) vs arctan(x,y)), and we were able to spot them very quickly, graphically.

The robot ended up getting programmed in Java, because the high schoolers rule the robot. I've looked at their code, and I have to say I'd much rather it be in labview for maintainability reasons.

Labview for rapid development, easier debugging, and better maintainability.

buchanan

02-04-2010, 10:12

At the risk of offending the C/C++ faithful, I'll come right out and say: Java is better than C++ for this kind of work. Not a LOT better, because the languages are more alike than different, but there are a few important differences, and these by and large favor Java:

1) The plurality of errors (and debugging time) in any significant sized C/C++ programming project are always around memory management. There are still ways to make MM mistakes with Java, but the "bread and butter" MM work that used to be the application's responsibility in older systems is taken care of for you by the Java runtime. This is important at all levels of programming skill and experience.

2) Concurrency (i.e. threads or tasks) is a first-class part of the Java language rather than an add-on as with C/C++ based systems. This means if you learned how to write Java threads in a class, from a programming book, or on another platform, your knowledge comes with you to the cRIO. Concurrent execution will be part of the picture in any reasonably sophisticated FIRST robot. It's inherently tricky, but with Java it's easier to do and easier to get right.

The theoretical "performance advantage" of C/C++ is largely myth/illusion. There are some VERY narrow situations in which it still applies, but Java compiler technology is quite good, and the compiler's runtime awareness gives it some performance advantages, too. The chances that your situation is one where C/C++ has a performance edge are quite small; the chances your situation is one where a Java program is more likely to be correct are much larger.

I speak as an expert with many years' professional programming experience in both languages. Java is simply a more evolved programming system (it's not just the language, the runtime system is part of the picture too).

One caveat is that the implementation quality of a system matters too. Even if Java is "better" as I've argued, a good C/C++ system may end up better than a poorly implemented Java. Having worked with C++/WR last year and Java this year in FIRST, both seem fine here.

If you want to leverage existing C/C++ expertise and don't want to fool with Java, go for it, and you'll do fine. If you're starting from square one, I highly recommend Java over C/C++.

virtuald

02-04-2010, 10:24

I personally will tell the said rookie team to pick up a C++ book and read it and study and meditate on it, IMHO its way more useful in the real world out of the 3. If you learn C++, you pretty much know Java (except alot of the java specific stuff), won't take you very long to pick up on java. Plus most real world applications are in C/C++, like Operating Systems, Games, and tons of stuff.

Right... the 'real' world... and how many years have you been working in the software industry now?

It just depends on where you end up in the 'real' world. Different languages are better for different tasks. There is a lot to be said for domain-specific languages (such as Matlab) and scripting languages (such as python). Just depends on what you're trying to accomplish and what you're used to.

Egg 3141592654

02-04-2010, 14:45

It really depends on the task. I myself know Labview and Java like the back of my hand, and I know the very basic things about C++ (not enough for a robot). I have chosen Labview the past two years only because it is much easier to debug and understand core concepts for beginners. Next year, our team is moving onto Java, only because, as a long time text coder, Labview was very confusing to trace.

In terms of performance, our Labview takes FOREVER to deploy and build, but there is no noticeable lag difference between the two when they are in the robot and running. C++ could potentially be a bit more frugal with memory to decrease junk code, but that depends who is sitting behind the computer monitor. I say it depends on the task to determine which is the stronger language to code in.

mathking

02-04-2010, 15:57

I will offer another plea to be open minded about languages when you make decisions, and listen to your mentors, many of whom have a significant amount of experience in programming.

As for Lab View not being real programming, put that right out of your mind. (I have always been impressed with LabView, and the first time I saw was more than 20 years ago.) I have been teaching CS for a while now, and I know that one of the constant "discussions" in computer science education circles is whether to start students on Assembly programming or not. I count myself firmly in the "not" category here. Learning to program is about learning how to break a problem down into smaller problems, finding algorithms to solve those problems, translating those algorithms in instructions the computer can understand and then debugging. The last step takes an order of magnitude more time than all of the others. Too much detail at the start tends to make you worse, not better, at programming. For learning the ins and outs of programming a robot LabView is a fine choice. It is really good for modeling and controlling embedded systems. If you are of the "I would rather not use that particular front end, I would rather use the 'real stuff' do my own C programming" consider that someone has to write the C compiler (a task you will likely have to undertake if you go far enough in studying CS). So why are you looking down your nose at using something that "was probably coded in C anyway" when you are just using something that was ultimately coded in Assembly, which is not itself really how the computer works by the way.

As for language choice, what you are familiar with will tend to be what you favor. But one job of a mentor (and a main job of a teacher) is to help you grow intellectually. One good way of doing that is making you learn something new. Even better is writing code on a couple of platforms and evaluating to see which is better for what you need. This year we developed code for both LabView and Java. Our decision this year to ultimately choose Java over LabView was due to our desire to use CAN, which was much easier in Java than LabView. But this doesn't mean that Java is superior, just that it served our purposes better.

I first learned programming in Fortran, then in BASIC. My first job programming was in C. I would say that C/C++ is what I am most comfortable using for my own coding, although teaching AP Computer Science has made me pretty comfortable with Java. If I am writing a simple program for myself I will often write it in Java just because it is easier to make a simple GUI and get it working. But one thing I tell my students is that they should never make their decisions about what language is best while they are in high school based on their perceptions of the real world. Even if their perceptions are accurate, what they learn in high school will not be what they use for most of their lives. When I was in high school (early 80s) my programming teacher told us we really needed to learn COBOL if we wanted to ever be employed in the field. So I did, and have never really used it. She wasn't wrong about the field at that time, but it changed. There was a big upsurge in COBOL jobs for a while leading up to Y2K, but now they are going away fast.

Now that I am at the end of my "open yourself up to new experiences" sermon, my two cents about language choice. I find that Java has a lot to recommend for this kind of robot programming. The way Java handles events, threads and exceptions is straightforward and easy to implement. It makes for much more robust code than typical C++ code. As for Java being filled with "fluff," most of the so-called fluff is just a standard implementation of coding standards that you will be forced to use by an employer if you ever code for big projects in any language.

synth3tk

02-04-2010, 17:09

I don't know (or care) if it's "the best", but we used Java. Our three (3!!!) student programmers either left, or didn't return, and none of the freshmen had no desire to learn programming at all. So I was stuck with the role. While we had default/leftover code from previous years written in other languages, myself and the team mentor decided to use Java. Randomly.

I'll tell you what, though, I knew absolutely nothing of Java as of January 9th, 2010, beside the fact that it's a programming language. That first week of build, I started learning the syntax, rules, and studied the default code. By week 4, the robot drove, and the pneumatic kicker worked. Had I been given more than 2-3 days of exclusive access to the robot, I probably would have had a nice autonomous working.

Also, quick note, never count out other languages, ever. Sure, you may love the most popular language used, but knowing X or Y may cost you a job/project.

Dkt01

02-04-2010, 18:39

Wind River is fast to build, but has a bit of a learning curve for those who know little C. I like LabView. It is easy to get used to, but it takes FOREVER to build. I've never tried Java, but I've heard it runs slowly on the robot.

davidthefat

02-04-2010, 19:47

CVassos

02-04-2010, 19:53

I've known C++ a lot longer than I have Labview, but when they introduced it to FRC I decided to try it and learn a new language. Which was great because it's just a new way of doing things. As for Labview not being a "real" language used in the "real" world, last summer I was doing research and while I was programming the device I was working on with a combination of Verilog(a hardware descriptor language) and C++ I had some friends in chip testing who were doing some "serious" programming using Labview. It's a language that is used widely by scientists and engineers. Although personally I prefer to code in C++

AmoryG

02-04-2010, 19:55

But I will bet you C/C++ was used to program that LabView

Deep down, isn't Java just C/C++ code as well? It means squat that LabView is built off of another language. It's still a language.

EthanMiller

02-04-2010, 20:42

My opinion is all this contains.

I used Java to program the robot this year. Last year, I used LabVIEW. And to be honest, once each was on the robot, I didn't see any difference in performance. We also didn't get any complaints from the drivers.

I'm probably going to try C++ next year.

I'm not an experienced programmer. I started programming on the TI graphing calculators, with the built-in BASIC-like language. Moving to LabVIEW was something different, and JAVA the same. And I can say - again, my opinion - that for this application, I didn't see that one was particularly better than the other.

I'm probably still going to learn Java and C/C++ for programming for the computer. LabVIEW programs can run on a computer, but that doesn't mean it's inexpensive to do so.

Thus, does being proprietary and costly make a language better or worse? Or does it merely make it more exclusive? And, is exclusivity a bad thing?

And as for LabVIEW not being programming: My opinion is that anything that is compiled into native code and executed on a computer is a programming language. This may not be accurate - I'm in 10th grade and starting programming, so correct me if I'm wrong in that definition - but LabVIEW fits it, and so to me is real programming.

Robototes2412

02-04-2010, 21:00

Java is faster than labview

dissassembled, labview code makes random calls that waste cpu cycles. Java code doesn't

Greg McKaskle

02-04-2010, 22:12

Bravo Ethan Miller. Very well said. That is the sort of attitude that makes it rewarding to work with FIRST.

Greg McKaskle

Greg McKaskle

02-04-2010, 22:20

Java is faster than labview

dissassembled, labview code makes random calls that waste cpu cycles. Java code doesn't

Can you elaborate on what led you to that conclusion? Better yet, do you have benchmarks?

Greg McKaskle

kgzak

02-04-2010, 22:49

:eek: The judges judge your code too? They never came over and asked me to show them my code...

Kind of, We told them how we used the camera to track the goal and how we can go an exact distance in autonomous.

Chris Hibner

02-04-2010, 23:31

What is "easiest" and "best" is really a matter of what it is that you're trying to do and where your experience lies.

Experience is a huge factor. Ask anyone in the world what the easiest spoken language is, and I'm sure almost everyone will answer that their native language is the easiest, because that's what they have the most experience in, and that is the language that they "think" in.

I know more computer languages than I have fingers to count them on. I have enough experience with languages to know that a) every language is "illogical" or "difficult" or "hard to follow" in many ways just because you're not used to thinking that way when you're new to it, b) every language becomes pretty cool in its own way once you learn the ins and out, and c) there are "different horses for different courses".

So what is "easiest"? It depends on the task at hand. If you have absolutely no programming experience and you want to be able to do some simple things on your robot, LabVIEW wins hands down (at least in the three choices given here). There aren't a lot of syntax peculiarities that you have to learn before you can get going. If you want to do some ultra-complicated stuff, then you can have a debate that no one will ever win.

If I have any advice, it's this: if you have a group of people that are highly experienced in one language, stick with it since that will be the easiest for you. If you have no experience whatsoever, go with LabVIEW.

Imadapocalypse

03-04-2010, 03:23

Personally java seemed to be the best fit. Being my first year as a programmer it would be natural the the first would be my favorite. But after seeing our programmers constantly struggle with the labview software it makes sense to go back to text based programming because it has more real world applications. The only problem I had with java was the unclear documentation of classes. Sometimes it was difficult to understand what exactly parameters were asking for. Otherwise it was very easy to code, simple to troubleshoot, and a breeze to build and run.

gvarndell

03-04-2010, 08:31

:eek: The judges judge your code too? They never came over and asked me to show them my code...

The judges want to know if (at least) some of the student team members know anything about that machine that's playing on the field -- including the software.
For obvious reasons I think, it doesn't reflect well on the team if none of them do.
And it goes beyond the technical.
At one regional we attended, a judge came up into the bleachers and asked me (I am old and my team affiliation was apparent owing to the team T-shirt I was wearing) if I had picked our alliance partners for the eliminations.
I told her she'd have to talk to the captains about it because I had given it very little thought.
Somehow, I think that was the answer she was hoping for (and it was the truth).

FRC4ME

03-04-2010, 14:51

My team switched to Java this year, primarily because it is the language taught in high school CS courses around here, and I am very glad we did. It is so nice to not have to explain memory management to the students or spend hours debugging a null pointer problem when the best the compiler can do is say, "something went wrong somewhere...probably." Most of the things you do in Java just "make sense," with very few syntactic quirks that seem unnecessary or silly to new students.

My main gripe with C++ is that it gives you far too many options. Should you pass by reference, pointer, or value? Here a hint; none of the three options do everything you want. The 2010 revision of the C++ spec will add another one: move reference (denoted by var&&)...this is getting a bit ridiculous. When defining a new class, you better write the copy constructor, destructor, and assignment operator (and move constructor in the new revision), or the compiler will do it for you (almost always incorrectly). Be sure to maintain exception safety in your constructors - 20% of my favorite C++ book is devoted to that subject. Put declarations in the header file and definitions in the source file; unless they're inline or templates.

And if that's not complex enough for you, with a Turing-complete preprocessor and template system, you can effectively rewrite the language (see: Boost libraries).

Java seems to be much better in the straightforwardness regard. Although I wish we weren't limited to CLDC 1.1: it has some idiosyncrasies of its own. ((Integer)vector.elementAt(index)).intValue is not an intuitive way of extracting an int from an array.

wireties

03-04-2010, 23:28

I've been doing this (software/hardware design) for 25 years using languages from assembly through C/C++/Pascal/Modula to PHP/Python and Perl. I've also used a few code generators which is what I think LabView really does. I am pretty sure LabView actually produces C (and maybe C++) source then compiles it. I know it did 15+ years ago. Albeit at a higher level, I too think LabView is really a language (and a very complex one at that) and NI is an awesome company.

Bottom line - you use different languages for different reasons at different times. To mitigate technical risk, it is wise for FIRST teams to use the supported language the mentors know best. Otherwise use LabView because you'll get the best newbie support from NI.

Languages like C and C++ are more powerful and normally faster in embedded systems. They make good programmers better but bad programmers intolerable. The VxWorks kernel is written in C and one can make C literally do anything on a FIRST robot. Java and LabvIew are another step removed, Java goes through the J2ME and LabView is (at least partially) a code generator. These abstractions have potential huge benefits but nothing is free. They are (at least a little bit) slower than C.

That is my 2 cents.

Greg McKaskle

04-04-2010, 07:57

I've been doing this ...

I agree with your overall post, but to correct a few details -- LV 1.0 was interpreted, but ever since LV2.0 released in 1990, it has been compiled. It compiles to machine code for various architectures. It doesn't need to generate C source. It doesn't do so primarily because C is such an unfriendly language for multitasking.

NI does sell an add-on module which allows targeting a wide variety of 3rd party embedded devices by generating C source and then using the vendor's C compiler. It was introduced maybe eight years ago, well after RT. That is not how RT works or how the desktop works.

Greg McKaskle

Radical Pi

04-04-2010, 22:42

Quick question: is the LV RT a bytecode based system (like Java) or is it just a run-time linked library?

Robototes2412

04-04-2010, 22:46

From what I've heard, its a bytecode system, but its is just a hair slower than java, and only enough to make java faster for the camera. The Java camera code is actually written in C++, which i raw machine code, being the fastest.

wireties

04-04-2010, 22:51

I agree with your overall post...

1990 - that long ago - now I feel old! Anyways, LabView is a great product and NI a great company. How efficient are the resulting binaries compared to code generated by commercial and open source compilers? NI does many things well but can it be that their compiler tech is way ahead of companies and open source contributors whose sole focus is compilers? Maybe so...

Why would one language be better in a multi-tasking environment than another? The VxWorks kernel and its native API are in C. Some languages (like Ada) have multi-tasking elements built into the language. I can see how they are more convenient. But you can't hide or abstract things w/o it being slower and/or less capable. Even the compiled versions of LabView must access the VxWorks API and the system call interface to interact with the OS. In any language some simple calls setup the tasks. The kernel does the multi-tasking for you w/o any further work by the application code (given a good design).

I love to use LabView for many kinds of tasks. But I would NEVER hire a software engineer to do embedded work that cannot use C/C++ effectively. Many times it is all that is available.

FRC4ME

05-04-2010, 11:07

Why would one language be better in a multi-tasking environment than another? The VxWorks kernel and its native API are in C. Some languages (like Ada) have multi-tasking elements built into the language. I can see how they are more convenient. But you can't hide or abstract things w/o it being slower and/or less capable. Even the compiled versions of LabView must access the VxWorks API and the system call interface to interact with the OS. In any language some simple calls setup the tasks. The kernel does the multi-tasking for you w/o any further work by the application code (given a good design).

One question I've always had is this: why does this argument end at C? Isn't the entire concept of a kernel a layer of abstraction in itself? Wouldn't it technically be faster to write the machine code directly rather than call POSIX API functions?

Everyone talks about C like it is the end-all-be-all of speed and efficiency, which confuses me because C is not the lowest level and seems like a rather arbitrary choice. Forgive me if I'm totally wrong; I'm no expert at the low-level stuff.

virtuald

05-04-2010, 11:20

One question I've always had is this: why does this argument end at C? Isn't the entire concept of a kernel a layer of abstraction in itself? Wouldn't it technically be faster to write the machine code directly rather than call POSIX API functions?

Everyone talks about C like it is the end-all-be-all of speed and efficiency, which confuses me because C is not the lowest level and seems like a rather arbitrary choice. Forgive me if I'm totally wrong; I'm no expert at the low-level stuff.

You're right, C is a (mostly) arbitrary choice, but its also a language that is available on almost any reasonably popular platform. So, for some definition of 'portable', C is generally the lowest level you will get to on a computer where you're not writing entirely machine-dependent code (with some caveats, of course).

If done correctly, the general stuff you write for one platform in C will work with little to no modification on some completely different platform. With machine code, you can't do that. The other thing is that C was designed to write things that used to be written in assembly language, so to some degree that influences its design and usage.

Tom Line

05-04-2010, 12:12

We like LabVIEW because we can do real-time analysis of things without re-downlading. Like making graphs vs Time of data points, probing data, and changing cal points. However, the largest negative I have is the build and download times. I once timed a build at 2 mins 41 seconds. The downloads are more reasonable, at around 1 minute. Overall, I would prefer LabVIEW over C++.

Ding ding ding. This is exactly why we promoted labview to beta teams over C++ etc.

The absolute ease of creating detailed front panels that provide real time feedback of ALL your variables, sensors, inputs, etc is an incredibly powerful tool. You can do the same thing in the other languages, but not nearly as quickly or easily. The tools are already provided for you in Labview - just drop the components you want on the front panel. Not having printf's is a wonderful thing.

I agree with the builds and downloads taking a bit, 4 minutes is pushing what you can handle during eliminations.

virtuald

05-04-2010, 12:52

The absolute ease of creating detailed front panels that provide real time feedback of ALL your variables, sensors, inputs, etc is an incredibly powerful tool. You can do the same thing in the other languages, but not nearly as quickly or easily. The tools are already provided for you in Labview - just drop the components you want on the front panel. Not having printf's is a wonderful thing.

I agree, having real time feedback on variables (and being able to provide that feedback as well) is an incredibly powerful tool. Thus why I created WebDMA, so you could have the same type of functionality in C++ -- incredibly simple to use. I haven't gotten around to adding graphs yet, but anyone reasonably competent in javascript could do it without too much effort.

http://code.google.com/p/webdma/

Greg McKaskle

05-04-2010, 18:45

Quick question: is the LV RT a bytecode based system (like Java) or is it just a run-time linked library?

LV RT, like desktop LV, generates native machine code -- PPC for the cRIO. It is not a VM.

Greg McKaskle

Greg McKaskle

05-04-2010, 21:27

Good questions. Quoted section marked with ***s.

*** How efficient are the resulting binaries compared to code generated by commercial and open source compilers?

The performance of compiled LV code varies depending on the data types and data access patterns in use. The LV compilers have traditionally been pretty simple, thus quick to target to new HW, but not as time or space efficient as more optimizing compilers. Over the last few years, this has improved quite a bit -- using LLVM internally in order to get better codegen.

*** Why would one language be better in a multi-tasking environment than another?

The C language knows nothing about threads or parallelism, those are added at the library layer. The C programmer needs to use explicit mutexes, semaphores, critical sections, and threads in order to ensure safe and correct execution in a multitasking environment. A C function foo(int a) doesn't declare how thread safe it is, it typically isn't analyzed for thread safety, and there are no keywords for marking it as reentrant, critical-section, etc.

By comparison, in LV, language features such as functions and wires are inherently multi-task-safe. By default, functions have a critical section around them, but a simple property change makes them reentrant. Each function call also allows for a priority change. Wires ensure the value read is delivered to each branch of the wire regardless of when it is executed, avoiding unwanted side effects.

So it isn't a matter of simply being better, but being more automatic and more safe. It is possible to write totally sequential LV code with no parallelism, but it is actually more natural to specify the code with dataflow parallelism exposed, which LV will then execute that way with the assistance of the OS. Similarly, it is possible to write C code that does lots of parallelism, but it is more natural to write the C code in a sequential form which will be executed with no parallelism. Compiler options for vectorizing C do exist, they have for decades, but the options are not used that commonly. Compilers for parallelizing C are more rare, are generally still a research topic, but seem to be on the near horizon.

*** The VxWorks kernel and its native API are in C. Some languages (like Ada) have multi-tasking elements built into the language. I can see how they are more convenient. But you can't hide or abstract things w/o it being slower and/or less capable. Even the compiled versions of LabView must access the VxWorks API and the system call interface to interact with the OS. In any language some simple calls setup the tasks. The kernel does the multi-tasking for you w/o any further work by the application code (given a good design).

The LV execution engine augments the OS scheduler to allow it to carry out execution according to the dataflow specification. It doesn't replace the OS threads package, but attempts to use it automatically and efficiently.

Greg McKaskle

Robototes2412

05-04-2010, 23:14

Then here's the question of the hour: can i write labview code in a line-based language, like python?

Greg McKaskle

06-04-2010, 08:13

Answer of the hour ... anything is possible, but NI doesn't provide a textual form of the language, at least not yet.

Greg McKaskle

Radical Pi

06-04-2010, 10:56

Answer of the hour ... anything is possible, but NI doesn't provide a textual form of the language, at least not yet.

is this a hint or something? :P

MikeReilly

13-04-2010, 11:08

Great stuff, and Greg I really appreciate your input. Sure you're from NI, but I feel you've been objective.

As a mentor, I'm bummed about the lack of growth in our programming team. We have 2 or 3 people usually doing some code, but one uber-coder who likes to pursue some ultracool stuff that most others can't keep up with.

Last year, that ubercoder had some personal issues and wasn't available for some chunks of time, so one mentor and his son learned to do just about everything in LV in a couple of weeks.

For teams that don't have an ubercoder who loves data, bits and bytes, go LV. If you have an AP Comp Sci class at your school, Java might be the way to go since you have a class of programmers at your school. For the code-jocks who like to have access to pointers and the core of code, they won't let go of C++.

But the bigger question is around the "I" in FIRST: is your goal to code, or inspire coders? For that, LV might be the biggest winner, and we're going to be making a bigger move into.

Kyler386

13-04-2010, 17:05

I can't say much in comparison with Java or C++, but I have threatened our LabView code into working with wire cutters...

BEEKMAN

13-04-2010, 17:44

fstream it, write it into a txt file and read it after to debug... But still :ahh: lots of numbers

correction, the write another C# program to make a graph of the data!!! now you have 2 languages!

byteit101

13-04-2010, 18:35

correction, the write another C# program to make a graph of the data!!! now you have 2 languages!

Like the ZomB Dashboard! (Its in C# and uses graphs!)
http://www.chiefdelphi.com/forums/showthread.php?t=82612&page=2
http://firstforge.wpi.edu/sf/projects/zombdashboard

We used these graphs to tweak our drive system to perfection
http://firstforge.wpi.edu/sf/page/do/viewImage/projects.zombdashboard/page/nice%20dashboard%20graph.bmp

DjMaddius

14-04-2010, 19:48

Personally, i love C++.
But cant stand the windriver software >.>

masoug

14-04-2010, 20:35

C++ is my favorite language, but I never used windriver, but I heard to was a $@#$@#$@#$@#$@# to use...

I SO TOTALLY agree with that!!!

For me, my experience with WindRiver was just completely filled with errors about no robot code, licensing problems, building errors, RAM use, and everything else in between.:)

I wish we had a better choice for C++...:rolleyes:

-Masoug

riptide

20-01-2011, 17:50

I have been in the programming business for some time and use all three languages. I always find this discussion very interesting. The battle of the languages. Who is faster, who is easier, who is used more, bla bla bla bla.

All three Languages eventually do the same thing in the end and that is they are compiled down to a much lower level set of instructions for the processor.

That being said, I really don’t think any of the three is better than the other as far as the application of a First robot, as they all share the same LabView libraries which I believe are written in C. If this was an interstellar probe or a very large distributed application that might be a different story.

For now would suggest the following:

LabView for a rookie team with no programming experience or someone majoring in engineering
Java for a team with someone who has experience with it or someone who is majoring in computer science/computer modeling
C++ for a team with someone who has experience with it or someone who is majoring in information technology/programming

fyrefrost

24-01-2011, 18:43

several of the programmers on our team know how to use C++ but none of them want to teach it so we always end up using labview. Which works fine. Except for when no one bothers to clean up the diagrams. Then debugging is impossible.

MagiChau

24-01-2011, 19:51

I prefer Java as of now compared to C++ and Labview. First of all, the compatible IDE is available for linux also. This is a huge plus for me because I like being able to use my IDE on linux also.

Labview, I do not like GUI that much. I do not like having to navigate through menus to find stuff. Needing to clean graphics to know what is happening was not appealing to me either. I understand that Labview probably is the easiest language to use as of now.

C++ the main offputting thing for me is the use of Windriver. I like Netbeans being available on multiple different operating systems too much.

I would find it extremely pleasing if Python becomes an official option for 2012. I think there would be a high chance like java, to be available on multiple operating system probably because of being open-source and that I do not mind not having to use symbols to enclose blocks of code.

Teaching programming is a very abstract thing. I find it best if you try to explore and ask mentor(s) if you are doing it right or clarify something. Programming for the robot is different from conventional programming since people took care of the lower level things so you could focus on getting the robot to do stuff. I would say the basics would need to be covered like how the basics of the language works and data types, functions, variables, arithmetic, case structures, and loops.

SudoSammich

24-01-2011, 22:19

Most teams just go with what they've got the most experience with from the conversations I've had with other programmers. Our team uses Java, but that's just because I've been the head programmer since the control system switched over, I've known Java for years and our programming mentor knows Java. That made it a relatively easy decision for us (though we did use LabVIEW for a year as well after the switch, didn't really like it). If you know C++, I'd say stick with that.

Greg McKaskle

25-01-2011, 07:49

All three Languages eventually do the same thing

I agree with this post, but have a few clarifications.

Java and C don't go through LV libraries. They call directly into NI libraries built for use with LabWindows CVI. This is NI's engineering oriented C development environment. There is often a glue layer or new set of entry points for LV to call into.

The FPGA program is written in LV.

Greg McKaskle

inkspell4

25-01-2011, 13:19

My team is working with java and we seem to be ggetting along just fine but overall i would recomend windRiver C++ as it will most likly give you more control and from what i know more teams use it than java so the fourms will be full of more people using it. I wouldnt rrecomend labview though as the interface is strange and it took along time for anyone including the mentor for our programing team to find it out and only one person has. The interface is much easier to use weather you use java or WindRiver.

Good Luck
From a fellow programer and electrical team member

Bethie42

25-01-2011, 13:53

2¢ from a rookie programmer here: our lead programmer graduated last year and I wound up taking his place this year. We had a bit of a hard time deciding between C++ and LabVIEW but went with C++, because I had a little experience with it and figured it was a bit easier for my brain to understand than what I'd seen of LabVIEW, heh.

With the help of a fabulous programming mentor, I've become reasonably competent in the last few months. My previous experience with programming was limited to some console applications [standard beginning-C++ stuff] and a bit of NXT G. It is so much better to jump in and start working with tangible applications. I am really enjoying working with a text-based language, but if I had to get a rookie programming team up and running I'd probably use LabVIEW, especially if they'd done NXT programming on an FLL team.

I suspect programmers' individual learning and working styles are a lot more important than the benefits of any particular language. I'm having crazy amounts of fun working with C++ and I think it'll be more of an asset to me in college than LabVIEW would have been, because I'm planning to major in computer science/programming.

WindRiver on the other hand.....not so much, heh. Not the most intuitive IDE I've encountered......
Incidentally, I once tried to get the WPI libraries running on my Mac at one point but ran into issues with the lower-down header files and so on. Is this even possible or would the lower-level architecture stuff have to be totally reworked? It would be rather cool to be able to compile code in, say, Xcode even if you still had to deploy from a PC. Annnnd I won't start the opensource/industry standard/real world debate :)

indubitably

25-01-2011, 17:12

From my experience, grizzled acients in the programming field would not be caught dead saying that LabVIEW is a true programming language. But when they say that C++ is better, I always tell them how people that are assembly purists laugh at C++ or any other high level programming language.

The fact of the matter is, LabVIEW is a programming language, and for FRC, it is quite a useful tool. Our team has many young, soon to be programmers with no previous experience. I feel we can teach programming concepts using LabVIEW without having to teach them the syntax of C++ or Java.

I think that if you are new to FIRST, you should probably start with LabVIEW and look into reprogrammin your robot in other languages during the offseason to figure out which one has the perks you are looking for.

For the record, I use LabVIEW because of the time it takes to write a program and even make test programs for it. I do, however, know C++ and Java but feel the cons outweigh the pros when it comes to FRC.

RoboMaster

26-01-2011, 01:56

We use LabVIEW because it seems to be clearly easier to learn and we find the graphical/data flow programming aspect to be quite intuitive. The concept of a front panel is also great for debugging. I know people have said you can create GUIs in the text based languages. But I think it's clear that LabVIEW makes this task way easier since that kind of functionality is built simply right in at its core.
I have worked in all 3 and I agree they have their strengths and weaknesses, but none of them is truly better than the others. I think a major weighing point is what the context and application is. I agree that rookie teams with no programming experience should go with LabVIEW, where as if you are familiar with one language already, then go with that. Inspiration and trying new things is always valuable, though, and if you have a strong team and programming group, it might help more than hurt to try a different language.

blackdog22

26-01-2011, 08:37

Even with veteran teams, C++ is more coplicated than Labview. A flow chart is more simple, understanding, and visual than written down code. I'm not trying to be mean to anyone who uses C++, but Labview is more useful. :D

grimmcoder

23-05-2011, 12:35

Hello All,
I think I will be the lead programmer next year and want to decide on a good language to use. This year we used LabVIEW and I really liked how it worked and how easy it was to use. Another member in the club who does not program for the club is very fluent in Java but does not program for the club. I saw his code, and it was easy to read, but could not figure out how to write it. My Dad and this last years leads Dad both know C++ and if we decide to go with that they can teach Me and any other members that are interested in programming next year. There are a a few Mentors that want to use C++ and a few wanting to use LabVIEW. I can see where the mentors wanting to do C++ are coming from, but I personally would like to use LabVIEW and so would the 2 Senior Programmers that are moving on. Please reply with feedback on my LabVIEW vs. C++ dilemma.
Thank You,
grimmcoder

lemiant

23-05-2011, 13:09

Like the ZomB Dashboard! (Its in C# and uses graphs!)
http://www.chiefdelphi.com/forums/showthread.php?t=82612&page=2
http://firstforge.wpi.edu/sf/projects/zombdashboard

We used these graphs to tweak our drive system to perfection
http://firstforge.wpi.edu/sf/page/do/viewImage/projects.zombdashboard/page/nice%20dashboard%20graph.bmp

Is there something like this for Java? It is probably my favorite language, but I'm considering labview just for the awesome debugging capabilities

lemiant

23-05-2011, 13:11

Alan Anderson

23-05-2011, 15:14

Please reply with feedback on my LabVIEW vs. C++ dilemma.

What's the dilemma? As the lead programmer, your preference should be the one with the most weight. I know you said that some mentors have other preferences, but is there anyone who is actually arguing against what you want?

grimmcoder

23-05-2011, 17:33

Well I guess no one is arguing against Me, just what they want to use because it would be better in the future, which I understand. I just want to go with which one would be best for the team and for the future of the team. At this point i can go any way I want, LabVIEW, Java, C++, I have the resources available to Me to learn a lot about each, I'm just not sure which way I should go and was hoping for more opinions. One idea I had was to try all 3 over the summer in a robotics setting and see which i like best, but thats just one idea and I'm open to any.

grimmcoder

25-05-2011, 11:23

Any other ideas? I'm open to any!

remulasce

25-05-2011, 18:17

Python! Check the subforum, under programming.

lemiant

25-05-2011, 18:19

Python! Check the subforum, under programming.

You can program the robot in PYTHON?!?!?!?!?!?

Kusha

25-05-2011, 19:46

Java, since it was my first language. Plus it's easier to use. IMO Labview is only good for debugging, but ...different to use.

remulasce

25-05-2011, 21:57

You can program the robot in PYTHON?!?!?!?!?!?

Ayup. http://www.chiefdelphi.com/forums/showthread.php?t=89185

lemiant

25-05-2011, 22:04

Ayup. http://www.chiefdelphi.com/forums/showthread.php?t=89185

Is there any good way of doing debugging with it?

remulasce

25-05-2011, 22:18

Print to NetConsole, or save a log to the CRIO.

grimmcoder

25-05-2011, 22:39

I'm really debating on going with C++ or LabVIEW. Any opinions between the two?

Alan Anderson

25-05-2011, 23:21

I'm really debating on going with C++ or LabVIEW. Any opinions between the two?

I'm a big fan of LabVIEW. The LabVIEW support FRC gets from National Instruments and WPI is wonderful. I also think it's a lot easier to work on a program as a group when the program is a dataflow diagram instead of a bunch of text.

C++ is great for someone who can get all the little syntactical details consistently right, but I'm not that someone. I find it way too easy to make subtle typing errors that result in a program that compiles without errors but doesn't work as intended.

JamesBrown

26-05-2011, 09:40

I'm really debating on going with C++ or LabVIEW. Any opinions between the two?

I agree with Alan (I find that is usually the case).

LabVIEW is the easiest language to use out of the three. It is simple to debug, simple to explain, and it just works. I love LabVIEW and am yet to see a real good argument against using it in any of these threads (with the exception of a situation where all of the team’s programmers are accomplished in using another language). There are a lot of people who believe that LV is not a real language or that it isn't really programming, this is garbage, LV is as capable as any other language we use, it is faster to code with, easier to debug, and you can easily show someone who doesn’t know how to code what the programming is doing in LV.

C++ is still my favorite language for programming outside of FIRST. It was my first programming language and even now that I have more in my tool box I still find myself going back to it all the time. I write in C++ all day at work, I am very comfortable with the language, with memory management (which isn't as difficult as many people in this thread seem to think) and with syntax. However I can't program in C++ as efficiently (based on time taken to code/debug) as I can in LV. I have seen quite a few of the most respected mentors on the forums come around to LabVIEW and that has really helped to solidify my support of using it.

I used to be one of the students who thought a graphical programming language wasn't true coding. Easy-C (which is good in its own right but is miles behind LV in terms of completeness) was new and many teams were going to it, I told my mentors that programming in Easy-C compared to C was like filling in a coloring book compared to writing a novel. This was a terrible comparison, C++ vs LabVIEW is like painting a room with a small brush vs using a paint roller, one is much faster and more efficient, and once your done no one will be able to tell the difference.

Ether

26-05-2011, 09:50

like painting a room with a small brush vs using a paint roller, one is much faster and more efficient, and once your done no one will be able to tell the difference.

You've not done much painting I imagine :-)

JamesBrown

26-05-2011, 09:58

You've not done much painting I imagine :-)

...won't be able to tell the difference from a distance?

I'll just have to add painting to the list of things Ether knows more about than I do, that list now consists of "everything about robotics" and painting. :)

StevenB

26-05-2011, 10:51

My first programming language was LabVIEW, in the form of the LEGO Mindstorms Robolab programming language. Robolab was (and still is) a straight dose of LabVIEW - I learned how to use the front panel, LabVIEW loop and case structures, and more.

A few years later I learned C on an old machine running DOS. I started programming for FRC in 2005, when it was straight C running on the microprocessor. Printf was about all we had for debugging, and I learned to make good use of it.

Now my current preference is Java, for three simple reasons: The Netbeans IDE is easy to set up and it's cross-platform, high school students taking AP computer science learn Java, and I'm comfortable and competent with the language.

I like LabVIEW, and I've found myself defending it against the angry jabs of frustrated mechanical engineering students at school. I've done some cool things with LabVIEW, and it does make a lot of hard tasks easy.
But I've never gotten really comfortable with LabVIEW. I feel like I spend more of my time hunting for the right block and rearranging things on the block diagram than I do actually programming. Maybe I'm just doing it wrong, but large programs seem difficult to manage and hard to change without making a mess. Comments seem more like labels and less like nodes in a thought process. That is, with Java/C++/Python/etc I can write out what I want to do in plain English and fill in code from there. That process doesn't seem as natural in LabVIEW, perhaps only because I'm not as fluent with it.

Have I just spent too much time with text-based languages and not enough with LabVIEW? Maybe I should stop thinking sequentially, and bask in LabVIEW's dataflow goodness? Or should I give up and become an old grouchy programmer who says LabVIEW isn't a real language?

Alan Anderson

26-05-2011, 13:41

But I've never gotten really comfortable with LabVIEW. I feel like I spend more of my time hunting for the right block and rearranging things on the block diagram than I do actually programming. Maybe I'm just doing it wrong, but large programs seem difficult to manage and hard to change without making a mess.

It took me two FRC seasons with LabVIEW to start creating subVIs. If you put everything all in one big VI, large programs do end up being difficult to manage. That's sort of the equivalent of putting your entire C++ program in the main() function. Instead, split functions out into appropriate chunks and it gets a whole lot simpler.

I rarely rearrange things on the block diagram by hand. The "clean up" tool is sufficient for my purposes. If a VI gets too big for me to find things quickly, that's a strong hint to me that it's just plain too big, period.

Comments seem more like labels and less like nodes in a thought process. That is, with Java/C++/Python/etc I can write out what I want to do in plain English and fill in code from there. That process doesn't seem as natural in LabVIEW, perhaps only because I'm not as fluent with it.

I just figured out this year how to do "top-down" programming in LabVIEW. You don't have to create complete functional blocks in order to use them. You can "sketch in" a placeholder with appropriate inputs and outputs, turn it into a subVI, pretend it does what you want while you code around it, and later come back and finish it.

In my own analysis, LabVIEW for FRC does lose out to C++/Java/Python in a couple of ways. First, code in a text-based language can be viewed, edited or sent by email without having to have the compiler available. Second, it still takes an annoyingly long time to build and deploy a program from LabVIEW. Those aren't enough to keep me from strongly preferring the ease of learning and speed of programming with LabVIEW. Now that our team's student programmer has had a season of experience, though, I'm going to dial back my preferences a bit and let him choose the path for next season.