Preferred Programming Language

[GeeTwo]

Originally Posted by axiomofdarkness

Just a note: Java actually only supports passing by value, while C++ actually supports both passing by value and passing by reference.

Correct about C++. Java objects are always passed by reference. AFAIK, java primitives are always passed by value.

[jkoritzinsky]

Originally Posted by GeeTwo

Correct about C++. Java objects are always passed by reference. AFAIK, java primitives are always passed by value.

Java passes references by value for objects. Java primitives are passed by value. Subtle difference, but it can matter sometimes.

[Spoam]

IMO, Java is the language for FRC if what matters most to you is competitiveness. The main problem with C++ is that the freedom it affords you comes with many language specific nuances (e.g. undefined behavior) that you simply don't want to be debugging. Additionally, this added freedom isn't very useful in robot code (especially because the FRC libraries are identical between languages). From a simple cost/benefit analyses C++ introduces more potential for bugs and introduces little or no competitive advantage in FRC (the performance difference tends to be negligible). A relevant adage I once heard goes something like "bad Java code should refactored and fixed in a good IDE, bad C++ code should be burned".

[virtuald]

Originally Posted by Spoam

IMO, Java is the language for FRC if what matters most to you is competitiveness.

BS. A skilled practitioner can be competitive with ANY language in FRC, without regards to the mechanics of the robot. Whether it's easy to do or not, is a separate question.

[Spoam]

Originally Posted by virtuald

BS. A skilled practitioner can be competitive with ANY language in FRC, without regards to the mechanics of the robot. Whether it's easy to do or not, is a separate question.

I agree. I actually vastly prefer C++ over Java in most circumstances. The tidbit with FRC is that you're rarely dealing with just skilled practitioners. The flexibility to use robot code written by a novice without worrying that a syntax error will cause a heap corruption that you'll spend 2 hours debugging is pretty significant in my experience.

[wt200999]

Originally Posted by Spoam

The flexibility to use robot code written by a novice without worrying that a syntax error will cause a heap corruption that you'll spend 2 hours debugging is pretty significant in my experience.

Sounds like a great reason to use LabVIEW!

[Jaci]

Guys, all we're doing now is discussing edge cases that can affect a programmers experience. To any outside observers viewing this thread, we're just confusing them more.

The answer isn't as simple as "in 0.1% of cases, this will happen in X language, so therefore, you MUST use Y language". The answer to the question "which language should I use" isn't black and white. Each language has its own pros and cons, and where it fits in in the grand scheme of thing. If they didn't, we wouldn't have thousands of different languages in existence today.

Referring back to OP, they want to know what language will prepare you for the real world, not which language is easiest to learn. You don't do FRC because it's easy to learn, it's hard to learn, hence "Hard Fun". If you want to be good at something, it will take hard work. If you want to be prepared for the industry, it takes hard work.

Let's try not to deviate from the question and answer what the OP wants to know, and hopefully, the reason most of you are here - what will prepare you for the future industry?

[jkoritzinsky]

Originally Posted by Jaci

Guys, all we're doing now is discussing edge cases that can affect a programmers experience. To any outside observers viewing this thread, we're just confusing them more.

The answer isn't as simple as "in 0.1% of cases, this will happen in X language, so therefore, you MUST use Y language". The answer to the question "which language should I use" isn't black and white. Each language has its own pros and cons, and where it fits in in the grand scheme of thing. If they didn't, we wouldn't have thousands of different languages in existence today.

Referring back to OP, they want to know what language will prepare you for the real world, not which language is easiest to learn. You don't do FRC because it's easy to learn, it's hard to learn, hence "Hard Fun". If you want to be good at something, it will take hard work. If you want to be prepared for the industry, it takes hard work.

Let's try not to deviate from the question and answer what the OP wants to know, and hopefully, the reason most of you are here - what will prepare you for the future industry?

From my limited experience, here's what I've realized about each language. I am probably wrong somewhere in here, so please correct me if I am.

LabVIEW: Industrial hardware. Primarily used in (non-SW or borderline non-SW) engineering roles. As a SW person, it has the least utility (in terms of usage in SW roles).

C++: High performance, high throughput computing. Used in low level (firmware), low latency (market trading, game dev), large calculation (ex. CAD, High throughput computing, supercomputers), and other projects that require the strength of C++. Also used in many other scenarios such as general business applications (usually "legacy" projects at this point), and mobile apps (cross platform ironically enough).

Java: General business applications, "enterprisiey" systems, web-backend code (sometimes), Android.

C#/.NET: Similar to Java, but more web-backend and lacks Android (w/o Xamarin tools). Some game dev with Unity engine.

Python: General business apps, utility scripts, some large calculation (with numpy), web-backend code.

There are many other categories I haven't covered, but this is a general idea. Basically, everything but LabVIEW will be great experience for a wide variety of programming careers. Of the current languages, C++ is the only one that will get you into the embedded firmware, high throughput computing scene, but Python is making some gains in some of the C++ space (not much in the real time systems or top tier game dev though).

[Arhowk]

Originally Posted by wt200999

Sounds like a great reason to use LabVIEW!

Eclipse can pick up on almost every single syntax error quite easily. I've dealt with issues such as users putting a space in front of their variable names in Labview causing them to fail for seemingly no reason. Labview has no advantage in this field.

[jdaming]

Originally Posted by Arhowk

Labview has no advantage in this field.

This is completely untrue and shows your lack of understanding. I use LabVIEW often in my Automation Engineering job and it has many advantages to traditional languages you just have to understand what those are (as many people have listed in posts above). I have experience with all three of the supported languages and python (never on a robot just in home use) and can certainly say that all of them have advantages and disadvantages, learn what those are and make an informed decision.

[Ether]

Originally Posted by Spoam

The flexibility to use robot code written by a novice without worrying that a syntax error will cause a heap corruption

Originally Posted by wt200999

Sounds like a great reason to use LabVIEW!

Originally Posted by Arhowk

Eclipse can pick up on almost every single syntax error quite easily. I've dealt with issues such as users putting a space in front of their variable names in Labview causing them to fail for seemingly no reason. Labview has no advantage in this field.

Originally Posted by jdaming

This is completely untrue and shows your lack of understanding. I use LabVIEW often in my Automation Engineering job and it has many advantages to traditional languages you just have to understand what those are

Without making any judgement either way regarding the claim in Arhowk's post, the phrase "in this field" in context seemed to be narrowly referring to syntax checking only.

[Alan Anderson]

Originally Posted by Arhowk

Eclipse can pick up on almost every single syntax error quite easily. I've dealt with issues such as users putting a space in front of their variable names in Labview causing them to fail for seemingly no reason. Labview has no advantage in this field.

First: if you're talking about LabVIEW variable names, I'm going to assume you don't know what you're talking about.

Second: LabVIEW is extremely proficient at not just detecting syntax errors, but at preventing them in the first place.

If you're talking about labels used in the RefNum Registry, then you have a point, but claiming "seemingly no reason" is overblown. A misspelled string passed to a RefNum Get function will give a distinct error.



In the typical TechnoKats robot code, each resource name exists only once in the entire program (it wouldn't have to exist at all if it weren't required in order for Test Mode to work properly). The problem of spelling a name two different ways simply does not occur. I know of at least three ways to do this, each with its own tradeoffs among such things as quickness of setup, speed of use, and simplicity of making major changes.