Quote:
Originally Posted by rbmj
However, I do think that WPILib development should be a community effort rather than a centralized effort. I think that teams should be encouraged to contribute changes and code back to the WPILib project to be integrated and used by all teams. I'm not saying that it should accept everyone's code - it would take a good core team of maintainers to weigh the pros and cons of integrating each change - but even levels of openness such as having a public patch submission and discussion mailing list and allowing anonymous checkouts would be a huge step in the right direction.
|
Correct me if I'm wrong, but while they don't allow any anonymous checkouts, there isn't anything stopping you from making an account and performing a regular checkout, and then stripping WPILib down to suit your needs.
At least for Java, they include the source for WPILib in the sunspotfrcsdk directory. I've personally made some adjustments and added some convenience classes for my team's use. There is a Java library hosted on GitHub –
atalibj – that seeks to remedy some of WPILib's perceived flaws.
You do make a good case though for the separation of the business logic from the abstraction. Maybe we could have a bare bones WPILib, and a forked, framworked WPILib++.
Quote:
|
Originally Posted by Tom Line
The programming assets of FIRST are fairly limited and what they provide us now works for 99.31459% of the teams.
|
Just my 2 cents, but many of the teams that fall into the .68541% are fairly capable of handling their own programming and making their own modifications.
But beyond that, the constant dissatisfaction with materials and resources we're handed (whether it be mechanical or programmatical in nature) is what drives a lot of student creativity. Dissatisfaction (no, not necessity) is the mother of invention, and in FIRST, dissatisfaction with something is the perfect excuse to go find a reclusive student and inspire him or her.