Quote:
Originally Posted by spartango
If we want programmers to grow across the FIRST robotics competition, we need a great deal more code sharing between teams and individual developers...this doesnt just mean example code--"oh look, here's how to write ur teleop mode" doesnt help anyone as programming is never fully understood until you actually do it for yourself.
Instead, I think we should push for more abstraction and framework code, developed by experienced developers(metor or student), and the sharing with and teaching rookie developers, across team lines.
I say abstraction can be the vehicle for two reasons. First, abstraction makes programming a great deal easier to understand(the rationale for high-level languages), and also, as rookies learn those frameworks, they will begin to explore the possibilites of adding to them..
These are really high minded goals, but I believe they are within the capabilities of FRC teams. As an example, my team (192; Palo Alto, CA) has built a friendly framework for this years competition(and future years) in Java, and Open-sourced it to allow other teams to utilize it. It is available at http://code.google.com/p/grtframework
We offer as much support as is possible to users of the framework, and release it not after competition, but before it, just as teams are allowed to try out java. Our hope is that instead of fighting the language change, people can be helped into it and reap the benefits. |
Just to make sure I understand your point, you are saying that we need to develop more framework/abstraction layers to help improve the experience of FRC programmers. Eventually you hope that the more interested ones will contribute back to the frameworks. Did I miss anything?
I would disagree with the notion that showing functioning examples is a bad thing. Some people, myself included, learn better from taking code that works and breaking it. I like to call it "playtime". I generally dislike frameworks as I spend more time trying to figure them out than I would just writing code from scratch. Admittedly I am not one for reading documentation, I prefer just fiddling with stuff until it works (note, this applies to software only, hardware I read the manual at least twice). However, I do agree that providing frameworks will greatly aid many teams in developing functional programs. I also agree that developing a consistent, usable, and well documented framework is well within the limits of SOME FRC teams.