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

[HashemReza]

Originally Posted by FRC4ME

What concerns me about many of the veteran frameworks going around is that they take a "black box" strategy; rather than showing rookies how to do it, they try to remove the need for a rookie to learn how to do it.

If that is the case, then I completely understand your reservations. In fact, I share them.

There is a clear difference between what I am talking about with regards to the original Kit of Parts (which is what I thought the OP was originally talking about), and Rookies using intense frameworks put out by Vets.

If the OP was talking about veteran teams putting out those frameworks, then I apologize. I personally feel as though that's along the lines of cheating, unless someone takes the time to go through and understand the framework given. Actually, if a rookie coder is able to go through and understand a framework it could very well help them along in their learning process, causing them to ask more questions, and find more answers.

Originally Posted by sircedric4

What if the team has no one with any programming experience? What if they don't know what a do loop or an if-then statement is? What if they have no idea what an API is, or if they don't understand what a object oriented programming structure means?

In this case, I would completely understand the use of a framework. This is one of those subjects where it is difficult to come to a definite conclusion. There is a fine line between a resource allowing someone to compete, and being "too helpful" and staunching the learning process.

EDIT:

Also, to your question OP, I would define it as such: If you can consider a team sustainable from year to year, it is a veteran.

[StevenB]

Originally Posted by davidthefat

... just because they are a rookie team, that does not mean that they can't compete with he veterans... IDK where this idea came from, but I don't like the kit idea that people are doing. This is not some government run multi billion dollar project... Software pretty much costs $0 for us, its all electrical and mechanic that gobble up the money, I don't get how being under funded rookie has ANYTHING to do with programming...

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.

[kamocat]

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)

[davidthefat]

Originally Posted by kamocat

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)

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

[yarden.saa]

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!

[Al3+]

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