Quote:
|
Originally Posted by ewankoff
From the way this discussion is going it looks like many people are not looking at the real intent of this rule. FIRST's goal is to teach student about technology, science, and engineering. When a part is fabricated student gain expierience with that part and machines used to make it. The rule inquestion, I beleive, is to force students to learn how to program and create code that works. If a team has already perfected code then this rule does not outlaw reuseing but only forces teams to re-implement it. The re-implementing of the code forces students to figure out how to make that specific code work with this years robot. If a team was required to retype or copy and paste then no-one benefits and does not coincide with the goals of first. The only thing that should be taken into consideration when copying code directly is that students should learn how it works and what makes it tick then the goals of FIRST are being fulfilled.
|
Everyone needs to read this carefully. I see quite a bit of arguing back and forth about whether a rule like this has any justification, and I think this post nails the question home. While software is without a doubt an integral part of a robot, it's implementation (not creation) is arguably simpler than a mechanical component. Once the concepts and code are developed and written, it only takes the click of a button to send it on it's way to the robot. Therein lies the problem: how do you arrive at completed concepts and code? The question seems to be "is it alright to use code/algorithms from previous years on current robots?" To take the question to a hypothetical extreme, without a rule like the one in question, a team could just drop in completed 2006 binaries into the 2007 robot and call it a day. Naturally, this wouldn't make much sense given the change in game play form year to year, but how far off from reality could it be if a team has not much more than a pusher/drive train bot from year to year? In that situation, how would a mentor tell their programming team "sorry guys, the code we had from last year is good enough, so we won't be needing you." More importantly, what do the students learn from that?
Break it down one step. Instead of binaries, copy and paste the source from the previous year. The compiled binaries are still the same if nothing has changed. Break it down further. Instead of complete source, just take snippets from the most complex parts, such as the camera tracker. Mentor to programming team: "Sorry guys, our code from the camera last year worked so well, we don't need to rewrite it. Just copy and paste it and call it a day." Again, what do the students learn from that?
If a team has the same general programmers from year to year, the rule does make it seem like a waste of time to re-write common code from year to year. However, at the same time I see seniors graduate from their teams and move off to college, carrying all their concepts and algorithms with them, leaving a rookie programming team scratching their head looking at the leftover code. Rewriting every year at least gives the experienced programmers time to properly explain why the code works, from algorithm to implementation, and gives the programmers-to-be the chance to ask questions and learn as things are put in place. Ultimately, isn't that the goal of FIRST? To inspire future engineers and help them find something they're interested in? How inspiring is it as a programmer to simply copy and paste existing code without understanding how or why it works? I believe that is the spirit of the rule.