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.

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

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

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