Re: I don't think being a rookie team has any effect on the programmers
 

In my experience, your argument has a fundamental flaw: you imply that the disadvantage of being a rookie team is funding. To put it simply, it's not: several teams I know were better funded as rookies than as veterans. The veteran advantage is about experience.

Why does being a rookie have an affect on the mechanical, electrical, and other aspects of robot design? Because as a team grows older, they learn all kinds of things. They learn things about how to manipulate balls effectively, or how to optimize a drivetrain, or develop a set of methods for designing their electrical layout.
Software is no different. Teams learn how to write good drive control algorithms, use different sensors effectively, or create a strategy for writing autonomous mode software.
And it's not about code reuse: today, I can code a PID algorithm in five minutes flat. But it took me many hours of research and more than a few experiments before I really understood what was going on. Similarly, I spent many hours my rookie year developing a good 1-stick drive algorithm, but it's only a dozen lines of code. FIRST rules say I have to rewrite that every year - but that's trivial. The veteran advantage is not lines of code. It's knowledge.

I used to feel the way you do - that people were working to make programming easier, and I was going to lose my competitive advantage. I was wrong.

As a result, various libraries and frameworks and so forth can only be a good thing. It's not "babying" the rookie teams - effective tools raise the playing field for all of us.

For example, I could proclaim that the Linux command line is the true way, and that anyone who uses a GUI is a wimp. In fact, all the people working on GNOME, KDE, etc, are just showing pity to the clueless masses. The test of manhood is one's ability to rule the command line. It should be a matter of pride that you can use a computer. No! GUIs are useful software tools that have helped make computers mainstream, and have ushered in a whole host of applications. In the same way, higher-level robot functionality has the potential to bring in all kinds of innovations.

Re: I don't think being a rookie team has any effect on the programmers
 

Honestly, I'm not trying to make headway in autonomous so rookies can do it better; I'm doing it because I'm appalled at the lack of autonomous in FRC, and I want to make it easier for EVERYONE, including myself.
My basic goal is to bring the coding of autonomous up high-level enough where people can say "go forward until even x happens", instead of having to create a loop themselves and poll that data.
If you've ever used Applescript, you may notice it's plain English.
Okay, all the sentences have a fixed form, but it's really easy to understand, and it's pretty easy to think it. When people are new to programming, they don't automatically translate "wait until this button is pressed" into "poll this input in a loop, and stop if the value is true".
I'd like to make it have the simplicity of NXT-G, but with much more power and configurability. It's not low-level tasks are what make someone a software architect, it's the structuring of how tasks rely on eachother.

In addition to this, I'd like to be able to modify a canned autonomous by just modifying a text file. No recompiling, no redeploying. (I could even make a bug-checker for the file to see if it would be interpreted properly)

Re: I don't think being a rookie team has any effect on the programmers
 

Concurred. This year we decided to code in Java, but 1) we coded in Labview last year, and lost the code, 2) none of the mentors knew how to program in Java, 3) the only dedicated programmer on the team last year was never here to help us. Another programmer and I had to figure EVERYTHING out ourselves, from installing the software to imaging the cRIO to deploying code, with no help from the mentors. (I'm sure they would have gone to the ends of the earth to help us if we asked; we just never asked because it wasn't necessary.) We managed to get this year's robot driving within half an hour of it being finished, and finish the kicker code, middle wheel code (see photos of our robot to see what I'm talking about), etc. within 2 days.

I'm obviously bragging, but I wouldn't call either myself or the other programmer geniuses. We're certainly not expert programmers either. We just looked online for examples, copied them, and then dug into the API for more info. That worked for everything except camera code, which was a pain in the rear end, but that's another story.

Re: I don't think being a rookie team has any effect on the programmers
 

:ahh: Surprisingly, I did that this year, just go forward until the IR sensor is triggered then kick and stop moving and retract kicker... LOL Did not track the target or aimed at all... The flaw was in our old revision of our codes, was that the robot was going too fast so the IR sensor did not trigger and it kept going until it ran up against the tower, which got us a penalty, yea I learned from mistakes and fixed it, our goal was not to get the balls in, just merely kick and stop moving and compress air for teh tele op

Re: I don't think being a rookie team has any effect on the programmers
 

It's harder to be a rookie team member then a rookie member of a team because there are so many things you have to learn by your self in few days since you get the software in the KOP. Other team already have the software. That's the difference!

Re: I don't think being a rookie team has any effect on the programmers
 

^ Then again, this is only the second year with LV/WR/the new control system in general, and only the first year with Java.

Six weeks is plenty of time to get the software working, even if everything goes wrong (as it always does). Now if you actually plan to do some fancy programming, that's another story...