My team is switching languages, and we would love help.

[marshall]

Originally Posted by cbale2000

I'm also a bit curious about this. Seems to me that if it ain't broke you shouldn't fix it until it is.

Off-season is time for experimentation and learning. Granted, we aren't switching away from LabView anytime soon, we've got other learnin' to do.

[cbale2000]

Originally Posted by marshall

Off-season is time for experimentation and learning. Granted, we aren't switching away from LabView anytime soon, we've got other learnin' to do.

Right, but experimenting with other languages is one thing, deciding you're going to switch languages before you have anyone who knows the language you're switching to is another.
I'm even a little curious as to what prompted a switch, for most teams there isn't a whole lot that you can do in Java that you can't do in LabView, and if they don't have anyone who knows the language, what made them decide Java was better?

[Ari423]

Originally Posted by cbale2000

Right, but experimenting with other languages is one thing, deciding you're going to switch languages before you have anyone who knows the language you're switching to is another.
I'm even a little curious as to what prompted a switch, for most teams there isn't a whole lot that you can do in Java that you can't do in LabView, and if they don't have anyone who knows the language, what made them decide Java was better?

I agree you probably want to see how much effort switching will be before you decide to switch. If you see at the beginning of build season that no one knows Java sufficiently well, you should probably stick with LabVIEW for at least one more season.

As far as what you can do with LabVIEW vs Java, there are definitely some things easier to do with LabVIEW and ther things easier with Java. Which one you choose depends a lot on what you want to be doing with the language.

On my team, we have stuck with LabVIEW since our programmers (me) dont feel like learning Java for FRC. In certain parts of the code I could see where Java would be more useful, in other parts I'm glad I'm using LabVIEW. We might make the switch next year, since none of our other programmers know any LabVIEW, but they know non-FRC Java.

[Greg McKaskle]

Asking for advice and assistance is great approach. If you can get a knowledgable mentor to assist, that will probably more helpful than anything else.

Jumping in and trying to get over the hump on one Saturday is perhaps a bit ambitious, but if you can prep for it, it may be a good start. I'd recommend that you open examples and sample code and read through it a few times before getting to the actual robot. The environment may pose as many issues as the language, so you may find it useful to do some Eclipse projects even if they don't use WPILib or deal with robots. Learn to edit, compile, and debug simple things before jumping into a big project.

Learning a new language, or a new anything, is a prime skill to work on. I don't think I'm in the best position to help you out, but if you have questions or comparisons on the forum, I'll be happy to help.

Greg McKaskle

[GeeTwo]

I have sent links to this thread to JRWise and Gixxy.

First of all, let me caveat that I have never done what I'm suggesting here, but it seems to me that it should work well. Alas, I happen to live in the woods of Slidell and not the shoulds of theory.

Java is one of those languages that has so much built into it (or more literally has functionality available as pre-written classes) that you may want to approach it as a higher-level library driven languages, and bring in the details as needed. If you just have students plow through Java for Dummies or another bottom-up book or course, they'll get the idea that they need to code everything themselves, or that they'd rather do so for the few percent of CPU efficiencies it will buy. I suggest starting with one of the demo robots available from WPI or screenstepslive, and getting it working first. Teach everyone what's going on where, and why it's important. Make a few changes (implement code for more precise maneuvering, or change the robot driving from front-to-back without any physical modification).

Then, go back and do a generic bottom-up course in java. For each chapter, work one or two of the samples in the text, but make the take-away project a modification to the current code base that uses the content of the chapter. Roughly alternate chapters in the bottom-up book/course with obviously practical things that solve current team problems. Implement video streaming back to the driver station. Include sensor inputs and feedback. Figure out how to do limit switches and encoders. Learn to drive pneumatic systems, servos, and LEDs.