Which language should we program in

[2185Bilal]

This year Team 2185 used Labview for their robot. But next year they were thinking on using some other language (either C++ or Java maybe even Python).

So my question is, is there any benefits to using Labview/C++/Java
Like is their any specific reasons to why teams choose the language they have

I heard from a friend on another team that there are pros and cons of each language. (Correct me if my wrong)

Also I would like seek some advice on which language to stick to, which one is the easiest, which one has less limitations, etc

Thank you very much in advance

[avanboekel]

There are quite a few threads on this topic.

http://www.chiefdelphi.com/forums/sh...light=language

http://www.chiefdelphi.com/forums/sh...light=language

http://www.chiefdelphi.com/forums/sh...light=language

http://www.chiefdelphi.com/forums/sh...light=language

Just the first couple that I found.

[Tom Line]

The summary of every one of those threads is:

Use what you are comfortable with and what your mentors and teachers are familiar with. If there is no specific langauge that your team has expertise in, then take your pick. There is nothing that one language can do that another cannot (of the languages listed), and I suspect you'd find that nearly every language is used by the championship teams.

[2185Bilal]

Really

Cuz i heard that vision processing was better in LV
but u have more control over the drive train

but i guess im wrong

[brennonbrimhall]

Since we have a Java class at our school, Java is what we use.

Between Java and C++, most of the differences are noted by the always awesome WPILib people: Brad Miller, Ken Streeter, Beth Finn, Jerry Morrison, Dan Jones, Ryan O’Meara, Derek White, Stephanie Hoag, and Alex Henning.

Here are their words verbatim from page 10 of the PDF:

Java

• Objects must be allocated manually, but they are freed automatically when no references remain. (Garbage Collection)
• References to objects instead of pointers. All objects must be allocated with the new operator and are referenced using the dot (.) operator. (e.g. gyro.getAngle() )
• Header files are not necessary and references are automatically resolved as the program is built.
• Only single inheritance is supported, but interfaces are added to Java to get most of the benefits that multiple inheritance provides.
• Checks for array subscripts out of bounds, uninitialized references to objects and other runtime errors that might occur in program development.
• Complies to byte code for a virtual machine, and must be interpreted. (Slightly less performance, but mostly unnoticeable)

C++

• Memory allocated and freed manually. (Subject to memory leaks)
• Pointers, references, and local instances of objects.
• Header files and preprocessor used for including declarations in necessary parts of the program.
• Implements multiple inheritance where a class can be derived from several other classes, combining the behavior of all the base classes.
• Does not natively check for many common runtime errors.
• Highest performance on the platform, because it compiles directly to machine code for the PowerPC processor in the cRIO.

[stundt1]

Since we have a Java class at our school, Java is what we use.

Same here

[gixxy]

Due to the libraries already being written for us it is all a matter of what you may know, and what you are comfortable with.

Labview is quick to learn and a visual language. Its more connect the dots to control the robot. However it is High Level and that can cause a decreased performance. (I believe Labview is fully interpreted. Please correct me if I am wrong)

Java is FULLY Object Oriented and has things built in like Garbage Collection (to automatically remove objects that are no longer needed), and this does make for a simplified learning experience with text programming languages. Java is also high level, but at least is compiled to byte code so it has a little more speed)

C++ is a lot more manual, you allocate yourself, you setup the objects and de-allocate them yourself, you have pointers, and so there is a lot more room for mistakes. However it will be the fastest running code, being that it is straight machine code for the cRio's PowerPC CPU.

Python is only supported by individual teams and I do not know how user friendly it is, I have next to no experience with it, however I do know that it is fully interpreted and that COULD cause some performance issues if you are going a lot of automated stuff.

Personally I think none of them are hard to learn (then again I was writing PHP at 13 and some Java at 15) There are tons of videos on all of them as well as books and other aids.



We chose Java because I had a little experience with it and the others on the Programming team felt they had enough confidence to do it, and boy it worked out for us!

[Alan Anderson]

Originally Posted by gixxy

Labview is quick to learn and a visual language. Its more connect the dots to control the robot.

It sounds like you might be thinking about NXT-G or RobotC, not LabVIEW. Yes, LabVIEW is visual programming, but it's "real" programming (rather than just plugging in predefined routines in a restricted environment the way "connect the dots" makes it sound).

However it is High Level and that can cause a decreased performance. (I believe Labview is fully interpreted. Please correct me if I am wrong)

Okay. You're wrong. LabVIEW programs get compiled into native machine code, just like C/C++ programs.

I won't nitpick your descriptions of the other languages.

We chose Java because I had a little experience with it and the others on the Programming team felt they had enough confidence to do it, and boy it worked out for us!

The conventional wisdom is to go with what your mentors know. I'm not going to contradict that, but I will say it's not strictly necessary. When the TechnoKats decided to use LabVIEW, the decision was made based on ease of learning and the level of support available rather than the level of comfort of the programming mentor (me). It was a learning experience for everyone, and I'm glad we did it.

[Jim Zondag]

Originally Posted by Alan Anderson

The conventional wisdom is to go with what your mentors know. I'm not going to contradict that, but I will say it's not strictly necessary. When the TechnoKats decided to use LabVIEW, the decision was made based on ease of learning and the level of support available rather than the level of comfort of the programming mentor (me). It was a learning experience for everyone, and I'm glad we did it.

Ditto: I chose Labview initially for these same reasons:

1. Labview is easier to teach. FIRST is an educational program, it is not just about building robots, it is also learning the processes and methods along the way. I chose Labveiw largerly because I find it easier to teach to new students with little experience and easier to do design reviews with non-coders, students and adults alike. If I were building robots by myself, alone in my basement, I would certainly write in C++, but since I work with a team of students and non-software people, it is more about the team than about me and what I like.

2. Labview has excellent support. The NI community is quite helpful and supportive of Labview for FRC, and there is a large local LV users community. I worked with them a lot back in 2009 during the control system migration. I helped many teams in this time period and since and NI was very helpful in resolving many issues quickly.

Third is the fact that, in the future, most of the world of software engineering will move to graphical methods. In my world, in automotive electronics, almost all of the software we 'write' is in graphical languages: Simulink, Stateflow, Statemate, Altia, etc. If we want to prepare these kids fo the future, we should pick our methods according to what they are likely to need someday.

You can achieve good results with any of the languages avialable. You will learn a lot no matter which path you choose.

[Jon Stratis]

Originally Posted by Jim Zondag

Third is the fact that, in the future, most of the world of software engineering will move to graphical methods. In my world, in automotive electronics, almost all of the software we 'write' is in graphical languages: Simulink, Stateflow, Statemate, Altia, etc. If we want to prepare these kids fo the future, we should pick our methods according to what they are likely to need someday.

Have any actual proof of this? There are certainly tasks and specific industries where graphical methods are the norm... but there are also tasks and industries where it most definitely is NOT the norm. Almost every major website you interact with is done through "traditional" programming, one line at a time. The video games kids play is done the same way. The iPhones or Android phones everyone carries are programmed the same way.

Where I work (in the medical device industry), all of our consumer products are prepared in C or Java. Some of our manufacturing and testing labs use visual languages, but a vast majority of our programmers spend every day looking at and writing lines of code, not connecting the dots in a visual interface.

My resume states I have experience in Java, C (and all the variants and successors of C), and Labview, along wiht some other languages. However, all of the calls I've gotten from recruiters browsing Linked-in want me for either Java or C related jobs. I haven't had anyone call and ask if I would be interested in a labview job.

[ItzWarty]

Originally Posted by Jim Zondag

Third is the fact that, in the future, most of the world of software engineering will move to graphical methods. In my world, in automotive electronics, almost all of the software we 'write' is in graphical languages: Simulink, Stateflow, Statemate, Altia, etc. If we want to prepare these kids fo the future, we should pick our methods according to what they are likely to need someday.

As stated by the previous poster.

There will always be pros/cons between numerous languages, and how they work - that's why so many languages exist in the first place.

Graphical programming languages definitely do have potential, though. A perfect example would be in dynamically creating user interfaces, where numerous elements are nested. In a case like this, numerous "controls" are created, and appended to other larger "controls". This sort of flow is extremely well expressed in a visual programming language.

--

To answer the original question:
Our Robot's source code was developed in Java.
The Operator Interface was developed in C# (which was influenced by C++/Java/Other Languages)
Last year we programmed the robot in LabVIEW.

Image processing was extremely to implement in C#, from the grounds up (directly manipulating the bitmap data). With C#'s ability to "pin" arrays to pointers, this code could execute at extremely fast speeds, and array element accessing did not have the overhead of bounds checking.

[AdamHeard]

Originally Posted by Jon Stratis

Have any actual proof of this? There are certainly tasks and specific industries where graphical methods are the norm... but there are also tasks and industries where it most definitely is NOT the norm. Almost every major website you interact with is done through "traditional" programming, one line at a time. The video games kids play is done the same way. The iPhones or Android phones everyone carries are programmed the same way.

Where I work (in the medical device industry), all of our consumer products are prepared in C or Java. Some of our manufacturing and testing labs use visual languages, but a vast majority of our programmers spend every day looking at and writing lines of code, not connecting the dots in a visual interface.

My resume states I have experience in Java, C (and all the variants and successors of C), and Labview, along wiht some other languages. However, all of the calls I've gotten from recruiters browsing Linked-in want me for either Java or C related jobs. I haven't had anyone call and ask if I would be interested in a labview job.

You'll see it more commonly in roles where programming is done by people who aren't actually pure CS people, and what they're doing isn't really a CS problem.

I know a lot of control loops are done in a graphical language where each block specifically represents some real world counterpart.

[brennonbrimhall]

Originally Posted by ItzWarty

Graphical programming languages definitely do have potential, though. A perfect example would be in dynamically creating user interfaces, where numerous elements are nested. In a case like this, numerous "controls" are created, and appended to other larger "controls". This sort of flow is extremely well expressed in a visual programming language.

If you find that most of your members come from FLL backgrounds, know that their programming is actually based on LabView; they might find visual languages easier to handle.

The first question when selecting a language is the ease of transition. If someone already knows in C++, C#, etc. and can teach that, then you should first consider those. We use Java because of our programming class at the our high school – we've got a background in it already.

Unless, of course, your point is to teach your team a knew language in the first place.

[wireties]

We use C++ on the robot and LabView to customize the dashboard. The C++ decision is mostly because of the expertise of the mentors. C/C++/C# are still the most popular languages by a considerable margin (like a 1/3 share between them). C/C++ and Java are great generic job skills. Many products like LabView (and I love all NI stuff!) have great application in specific vertical markets.

So my advice is to do what your teachers/mentors know. Favor C/C++ if you have options. And if you have no software teachers/mentors try LabView (for the remote support).

HTH

[daniel_dsouza]

Our team decided to use Java partly because the development environment is easy to set up (less than half an hour). All you have to do is download the relatively small IDE, and tell it to look in the update site for the robotics plugins. Netbeans, the Java IDE, also integrates nicely with our GitHub repository. On a team where a quarter of our team "helps" with programming, not spending several computer-hours installing LabView is a plus.

In the short run, Java is the language used in the AP Computer Science test. ASU uses Labview extensively in its engineering programs (or so I'm told). And in the real world, C++ and python takes a cut out piece of the pie. So what you plan to do with your programming future can also factor into this.

In terms of ease-of-use, I would think Labview would be the easiest. Having started out with the Lego Mindstorms sets, which are programmed with a (very) basic version of Labview, I can say that visually seeing loops and logic can be very convenient. That being said, line-code isn't that daunting. Not only are there great examples on the web (maybe a robotics forum), but FIRST also gives out comprehensive and ready-to-run examples (found with your plugins). For Java, the included javadoc provides outlines of all the WPI classes.

If I had to choose again which language I would use to program our robot, I would choose Java. There are some C++ aficionados on our team that point out that C++ doesn't need to be interpreted, and is therefore faster. However, Java is easier to pick up and wield, manages my memory, and doesn't have crazy grammar (to pointer or not to pointer...). Contrary to popular belief, Java offers all the capabilities that the other languages have!

In summary, Java. It is easy to install, useful now, use in the real world, has plenty of support, and is simple to use.

PS. This year, we encountered a team that arrived at competition with a C++ environment, but no usable code. By the end of the competition, one our members had set them up with a Java environment, written their code, and taught them a few tricks along the way!