Which programming language does your team use?

[gixxy]

I would like collect some data on which teams use which programming language. Naturally I expect LabView to be on top, however it would be nice to have some kind of idea how many teams use the other languages available.

[Yipyapper]

Coded in C++ for the first two years I was on the team, just switched to Java this year. I personally love how much cleaner the IDE we are using is (Netbeans) compared to the older one (WindRiver); perhaps it's the aesthetics.

Well, not that Netbeans is all flashy, but for some reason, it just looks... appealing. Colours, maybe? Maybe I'm just weird?

Either way, we use Java on the Netbeans IDE now.

[TheSoftwareGuy]

C++

LabView babies you too much, and also because I will be looking for a career in the software development field.

[AlexBrinister]

Our team uses C++. However, with the new Command-based robot thing, we might as well be coding in Java. We (unfortunately) used Wind River for the past two years but next year, we're probably switching to Vim and a terminal on Linux .

Alex Brinister

[apalrd]

Originally Posted by TheSoftwareGuy

LabView babies you too much, and also because I will be looking for a career in the software development field.

I totally disagree.

I work professionally in C (no ++, just C) and we use LabVIEW for our FRC code because of the fantastic development tools.

The biggest disadvantage is library code inefficiency in LabVIEW FRC, but we fixed most of that this year.

LabVIEW is also heavily used in test and industrial automation, especially where complicated software is needed for a one-of-a-kind unit. I know a guy who used to professionally work with LV FPGA to evaluate and test high-speed SPI IMUs and ASICs.

[AlexBrinister]

I think LabVIEW is just another way of looking at programming. The only thing I don't like about it is the clutter that one can accumulate. It's way too messy.

Alex Brinister

[apalrd]

It's only messy if you write it messy.


Like any other language, you have to divide it up into multiple files/functions and design the core architecture well for it to be neat.


You can also use the Clean Up VI tool to auto-organize the block diagram to make it neater. In general, if the VI dosen't clean up well with the clean tool, it's too complicated.

[Kusha]

We program in java because of AP Computer Science being taught in java. Students come in with a general understanding of the language. We have comp sci 1-4 at Pearce. I'm currently in computer science 4, where we get to do independent study. One of my independent projects was actually programming the robot. They compliment each other quite nicely. It look 2 years of convincing to get the team to switch from Labview

[kgzak]

I program in C++ for computer apps/other micro controllers but for FRC I prefer Labview. The tools supplied are very nice and make debugging quicker as you can look at all the inputs live.

[connor.worley]

C++. We know how to write it and it has the fastest build+deploy times.

[Tom Line]

Originally Posted by apalrd

It's only messy if you write it messy.


Like any other language, you have to divide it up into multiple files/functions and design the core architecture well for it to be neat.


You can also use the Clean Up VI tool to auto-organize the block diagram to make it neater. In general, if the VI dosen't clean up well with the clean tool, it's too complicated.

Bingo.

If I jumped into C++, ignored classes, subroutines, and just tried to write everything out line-by-line, it would be ugly.

Just because you don't understand or haven't been taught how to write clean LabView code doesn't mean it isn't clean.

One basic rule: If your code gets bigger than one or two screen-widths, you're getting too complicated and not splitting it up into Sub-VI's efficiently.

There's a whole host of other rules, but being that this is a Visual language, if you can't tell from a glance what it's doing, you're probably doing it wrong.

[Joe Ross]

Teams and CSA have been entering software data in the NI Parkway system. As of right now, there are 414 teams that have entered data. 42.5% LabVIEW, 37.4% Java, and 20% C++. See http://www.niparkway.com/frcts/reports

You can enter your data by going to http://niparkway.com, click on help out, choose an event that you are competing at, and then choosing your team.


330 is using Java for the robot, and LabVIEW for the dashboard / vision processing.

[AlexBrinister]

Originally Posted by Tom Line

Bingo.

If I jumped into C++, ignored classes, subroutines, and just trie to write everything out line-by-line, it would be ugly.

Just because you don't understand or haven't been taught how to write clean LabView code doesn't mean it isn't clean.

One basic rule: If your code gets bigger than one or two screen-widths, you're getting too complicated and not splitting it up into Sub-VI's efficiently.

There's a whole host of other rules, but being that this is a Visual language, if you can't tell from a glance what it's doing, you're probably doing it wrong.

The code I saw was incredibly complicated due to it being for some piece of random hardware. It was pretty messy. But you are correct, it does depend on the programmer and his/her practices. Our code is definitely a mess because nobody bothers to take the time to write it cleanly or clean it up after build season. Splitting projects into Sub-VIs (much like splitting a C++ project into different source and header files) would make things much neater. I think LabVIEW would be a nice thing to know, but I don't see myself using it for something as relatively simple as the robot code.

Alex Brinister

[Rangel]

On team 842 we used to use Labview for our FRC robot but this year we switched to Java. For our autonomous underwater robot though, we use C# with Visual Studio.

[nightpool]

Originally Posted by apalrd

It's only messy if you write it messy.


Like any other language, you have to divide it up into multiple files/functions and design the core architecture well for it to be neat.


You can also use the Clean Up VI tool to auto-organize the block diagram to make it neater. In general, if the VI dosen't clean up well with the clean tool, it's too complicated.

This. A lot of teams start out in labview, but don't learn any good practices or put any thought into organization. Then they get bigger and start coding more advanced features, but still have the same coding practices. It just ends up a mess.

That was my team last year, big and complicated code with no thought to organization. We ended up moving to c++ for other reasons, but some of it was making a clean break; allowing our programming team to break out of their bad habits and start thinking about organization.