I hereby issue a challenge to the programming departments of each team: use a different language each year.
The Rules:
-Use a different language each year.
-The 4 languages to use are C++, Java, LabView and Python. Feel free, however to add others to the mix.
-There must be at least a 4 year interval before a language is reused. In other words, no programmer should ever use the same language twice.
I’m going to avoid the temptation to write a really long post and just ask 1 thing.
Why?
Python is not a real, supported FRC language.
There are 3 choices if you want any help at all.
I too question why.
“Jack of all trades; master of none.” comes to mind almost immediately.
I like the idea of the challenge but I think it would be kind of hard to implement. The teams I have experience with have never really had a “dedicated” programming team, generally they do electrical and pneumatics as well.
On the other hand I have been looking into using python to program our robot, even though it is not ‘officially’ supported.
My goal has always been to be the “Jack of all trades; master of none.” as ttldomination stated.
We’ve used 3 different languages in the past 3 years. Hey, it happens when your team is founded with freshman, they grow up and learn new stuff! 
I think we’ve found our preferred language by now, Java.
Well, that saying can really be considered either good or bad.
In competition, especially FIRST, I think it is widely accepted that it’s better for you to do one thing really really well as opposed to do a lot of things at a mediocre level.
I’ll throw out a reason. Learning multiple languages helps you learn to think in terms of programming structures, or design patterns, ie., you become more meta and less syntax.
That said, I would probably use a base language year over year and have off season challenges to re-implement in a new language. Then switch if your team decides it wants to.
I’m a big fan of Robo-Cobol and think that most teams should moving that way.
I can see taking an existing robot and trying to program it in some other language as a possibility. So it’s a teaching moment.
On the other hand to program a robot during a season because it’s a different language seems like a bad idea.
I can definitely see the benefit of multiple languages. In fact, when I first saw this thread, I thought it was a challenge to learn a new language every year, but as an individual rather than as an entire team, and thought “wow, that’s a really cool idea.” And even having a team to try to learn some of the other languages during the off-season would be pretty cool, although I could think of better things to be spending code training time on. Coding your competition robot in a different language every year, though, is just counter-productive. One of the biggest problems I could see teams running into is having mentors who only know one of the languages well, then having to find new mentors every year because the old ones decide not to try to learn the new language.
Our team has always programmed in labview. In 2012 we implemented vision for the first time. In 2012 & 2013 we used C for vision, this summer me and another student are forcing ourselves to write every vision project in C++. By next summer I hope to be using python for some projects. Our scouting program was written in C# this year. The reason we write in so many languages is because our mentors that help with programming just happen to know different languages.
While we don’t switch programs every year, we offer a wide variety, so if you don’t find labview amusing, you can try another. I personally don’t care what language a teammate programs in as long as they enjoy it and it works.
I believe this is a safer alternative than switching languages every year. It still provides the diversity, but the veteran experience is still there.
It’s true that learning other languages is useful, like when the mother cat and her kittens were suddenly confronted by a dog. Mother cat barks furiously and the dog runs away. “See?” the mother cat says to her kittens. “Now you see why is important to learn a foreign language!”
I agree with rsisk, that learning multiple languages helps teach programming structure and method. LISP and FORTH, for example, have a very logical format. (APL too, for that matter.) Maybe not as readable, but it makes sense. Robo-COBOL, on the other hand, is very readable, but oh-my! The typing! The typing!
Our team used LabVIEW ever since it was introduced. The school district’s FLL and FTC teams are already using LabVIEW, and we’re starting to see those kids coming up to FRC already knowing how to do the basics. We (the mentors) would prefer sticking to the one language “just in case”. What if your lead programmer can’t make it to a competition? Can your relief pitcher pick up the language real quick? I don’t mind exploring/learning other languages off-season, but let’s keep everyone focused on one language – whatever it is – during build season.
The build season is 6 weeks. The programming team is lucky if they get a vetted mechanically robot at the end of week 4. More like the last week or the last week end . Not a time for the programming team to be dealing with a new language. I want our programming team to be up to speed and ready to run hard when the robot is finally ready for them. If we change a language it would have to start in the summer and continue through the fall to be ready for the season. We have students that have multiple years of lab view experience and can run with a project. I would hate to throw all that experience away. We have used some arduino boards and some programmers have been exposed to c and c++ with them. I prefer a master of one.
At FRC, you really only need to learn one language. Consider the pit area for a team. They have lots of tools to work with – but no two tools are designed for precisely the same purpose. A Philips screwdriver will not replace an allen key or some extruded aluminum (MacGyvering aside). Us programmers only have four tools/languages to work with (yes, Python is a perfectly viable option, don’t dismiss it), but these tools are all intended to do the same thing. That’s why FIRST remains primarily a mechanical competition, not really a programming one, and why teams will stick with a language.
In short, I think it makes sense to select a single language that suits your team for robot-related tasks, but also broaden your palate with non-robot languages – 254 just released an amazing Ruby-based CAD program, for example, that relied on some not-trivial SQL. Or 245, who released a scouting app written primarily in Javascript, designed to calculate OPR, CCWM, etc. There are two branches of FRC programming – the Robot, and some utilities for your team.
Robo-Cobol 74:
000100 IDENTIFICATION DIVISION.
000200 PROGRAM-ID. FOURDIVISIONSNOSUPPORT
…
Seems to me that this is sort of an opt-in venture. Sounds like fun but I am not sure most teams would want to chance that they switch to an unfamiliar language on what will most certainly be a new platform they will not probably have weeks into a 6 week build. Definitely worth learning to do outside of the build season however.
Gonna be hard to get the IBM mainframe on the robot in the weight limit.
Exactly. If you do this challenge you SHOULD be preparing before build season starts. That way you are ready when the time comes. Also, it helps if the programming team starts working before the robot is done so that they don’t have to do everything in 2 weeks or less.
We actually practice on the old robots in the fall, reprogramming them thru all the parts, simple stuff to more complex sensors/buttons/motors combinations.
During the first week of build, we all set a rough idea of what is needed on paper, with the electronics mentor doling out port numbers etc. The programmers usually got ahead of the prototype robot (or the multitude of pre-prototype mock-ups) with only tweaking of code (if we’re lucky) or rewriting code (if the manufacturing group changed the design).
Yeah, that’s what turned me off to COBOL, way back when, to my 13-year-old fingers, the typing, typing, typing of code, though I never actually did much coding. Though the card punch units the high school had made a pretty neat and satisfactory hole-punch sound. Robo-COBOL is, of course, much easier. 
COBOL taught me how to spell Environment correctly 
Man that brings back memories
Ok Gramps…
But seriously, I like the idea of teaching new technologies and skills. I do not like the idea of making this stuff harder than it already is.
IBM did have 370’s on a computer card Micro 370 which would fit on a robot today! On the other hand, getting a punch card reader that size will be a problem :rolleyes:
Thanks for the COBOL laugh, COBOL was my second language after Fortran. For awhile I worked at place that had Object Oriented COBOL, it was pretty cool.