The One-language-per-year Challenge

[E Dawg]

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.

[Pault]

I'm going to avoid the temptation to write a really long post and just ask 1 thing.

Why?

[apalrd]

Python is not a real, supported FRC language.

There are 3 choices if you want any help at all.

I too question why.

[rsisk]

Originally Posted by Pault

I'm going to avoid the temptation to write a really long post and just ask 1 thing.

Why?

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.

[Foster]

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.

[techhelpbb]

Originally Posted by Foster

I'm a big fan of Robo-Cobol and think that most teams should moving that way.

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.

[rsisk]

Originally Posted by techhelpbb

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.

COBOL taught me how to spell Environment correctly

Man that brings back memories

[Andrew Schreiber]

Originally Posted by rsisk

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.

[Foster]

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

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.

[Roger]

Originally Posted by Andrew Schreiber

I do not like the idea of making this stuff harder than it already is.

So I guess APL is totally out of the question, huh?

Seriously, APL should be taught first, then when they are totally lost, tell them you'll give them something simpler, like C. I'm sure there's a Sheldon Cooper quote in there somewhere.

[techhelpbb]

Originally Posted by Roger

So I guess APL is totally out of the question, huh?

Seriously, APL should be taught first, then when they are totally lost, tell them you'll give them something simpler, like C. I'm sure there's a Sheldon Cooper quote in there somewhere.

I have found that nothing makes a programmer learn the value of a QWERTY keyboard faster than a wire-wrap tool:
http://www.homebrewcpu.com/Pictures/..._wrap_side.jpg

For those studying the electronics they'll never forget the real value of a netlist after that.

Extra points if you can wire-wrap a whole cRIO from CMOS chips.

No seriously, though, part of the pain of building these robots at all is that often times the core concepts and subtle core things you must do to get anything done is still sometimes a matter of imagination. Let alone twisting that into something unique and reliably functional.

One should not loose sight of what it was like to learn when first you had to build the computer. Disputes about the 'best' language for something tend to start to look like a luxury.

[Foster]

Originally Posted by techhelpbb

I have found that nothing makes a programmer learn the value of a QWERTY keyboard faster than a wire-wrap tool

Going to guess that less than 50 of us know what that is or have used one.

And CMOS? Really TTL isn't good enough for you?

Finally, one of my early jobs at the University was to help maintain the computer billing system that was written in APL. Clearly a write once read never language.

My programming language arc is Fortran, COBOL, MAD, ALGOL (and variants like ESPOL), APL, TECO (ask anyone, its a programming language wrapped in an editor), Assembler (oh PDP8 Assembler how I loved thee) , BASIC (and variants like Visual Basic), Pascal, C and (C++), Lisp, AWK, ICON, Forth, XLISP, TADS, Bob, Logo, Pilot, Smalltalk, TCL, Java, Javascript, Python, Ruby, Processing, Labview and Lua.

I'm working on English, hope to master that soon.

[techhelpbb]

Originally Posted by Foster

Going to guess that less than 50 of us know what that is or have used one.

I can help with that I still have and use them.

And CMOS? Really TTL isn't good enough for you?

I value my 74181 collection. Harder to get these days.

My programming language arc is Fortran, COBOL, MAD, ALGOL (and variants like ESPOL), APL, TECO (ask anyone, its a programming language wrapped in an editor), Assembler (oh PDP8 Assembler how I loved thee) , BASIC (and variants like Visual Basic), Pascal, C and (C++), Lisp, AWK, ICON, Forth, XLISP, TADS, Bob, Logo, Pilot, Smalltalk, TCL, Java, Javascript, Python, Ruby, Processing, Labview and Lua.

* PRESS PLAY ON TAPE *

No PHP, Perl, MegaBASIC, QuickBASIC, BASICA, GWBASIC, F#, Ada, DarkBASIC, GLBASIC, FreeBASIC, RCL, PureBASIC, Commodore BASIC, Delphi (Object Pascal), SED, PolyFORTH, pBASIC, SPIN and XCore C/C++?

Come on you're acoustic coupling it in at what like 300 baud?


At some point it does start to get down to this....yes we can make it do that....but it might be wise to not ask how unless you are prepared to absorb way too much information.

[E Dawg]

Originally Posted by Foster

I'm working on English, hope to master that soon.

No one can master English. Not even computers understand normal
English, hence the fact that there are over 100 programming languages .

[Pault]

Originally Posted by rsisk

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