on Jun 29th, 2009Early bird defines the worm!
In his posting All contributions are Equal, some are more equal than others, Robert Konigsberg points out that contributing multiple ways of doing things can easily lead to more user complexity (e.g., by having multiple toString generators).
This is true and in my view, a risk for any system that has many strongly-opinioned contributors (pretty much any large open source project).
Toward the end of his post, he poses a process-level question about how to avoid the situation of some contributions being more equal than others…. I think the solution is the current de facto for Eclipse.org projects and that’s the (frequently unstated) reality that the early bird defines the worm.
When it comes down to it, those that initiate and then follow through on enhancements, fixes, documentation or other contributions get to choose when it comes to actual design decisions. Inevitably, there are design choices that some disagree with, even when all discussion is had completely in the open.
I think the truth of the early bird defines the worm statement is that we should provide incentive to organizations and individuals in the community to be more aggressive about contributing to existing Eclipse projects. This is because waiting for someone else to initiate, design, implement, test and document something often doesn’t work very well.
To some, it may seem like Eclipse Project development is effectively subsidized by others, but this is not true. Even for one’s own usage of Eclipse, contribution and community involvement with Eclipse.org projects pays dividends. There are many ways to contribute, from contributing discussion/ideas, to planning, to new example/app code, to helping to maintain existing code, to documentation, to build support, to testing and bug reporting, to providing bug fixes, to mentoring, and plenty of other kinds of support.
In my view, these are the ways to get your contributions into Eclipse, and influence the community around the software.
Here’s my understanding of where the toString() contribution originated.
Related posts:
Hi Scott,
So, does that mean using patch fragments _defies_ the worm? Har har har. Ahem.
Taking the toString example a little further, the person who is complaining about the quality of the toString implementation is a noted author of a Jolt-award winning book on Java development, from which he references his issues. I think he’s a user of Eclipse, but not necessarily someone who is involved in the community per se. (Case in point, his subsequent blog post was a comparably-sized review of the latest Netbeans release.)
So here’s a guy who, if you will allow me to presume for demonstrative purposes, is not interested in participating in the design sessions, but just wants an IDE that does good things so he can use it, and to recommend it to his students. But I’ll also presume if an early bird talked with him, he’d have lots of great ideas to share.
If you allow that presumption once more, someone like that, perhaps, is someone you want to actively pursue for these types of issues. Perhaps “The Early Bird Defines The Worm” is the way it is. But maybe it’s also an indication that the early birds might have saved some effort by talking to some other birds before defining the worm. (Sorry, it’s the best I could do to extend the analogy.)
Once again, I’m only hypothesizing. The toString implementation is nothing I have a problem with, I merely mentioned an observation of Cay’s dissatisfaction of the implementation. But I’ll be willing to acknowledge dissatisfaction for the other feature mentioned in my post: the hashCode and equals generator. (Now I want to be careful and clear again: my dissatisfaction does not mean I think someone did a bad job, it means I think it could be made better in my use case.)
But in that case, the feature was implemented long before I ever thought about Eclipse contributions, maybe even before I ever used Eclipse. So, in that case, I ask my original question: how can I get a hashCode and equals generator that better suits my needs without overwhelming the UI with duplication?
Thanks, Robert
Hi Robert,
I’ve deleted much of what you say before the below, because I basically agree with it and don’t have much to say in response.
>But maybe it’s also an indication that the early birds might have >saved some effort by talking to some other birds before defining >the worm. (Sorry, it’s the best I could do to extend the analogy.)
Maybe…but a few things to say about this:
1) Getting too much input about things like this (that have an aspect of programming language ‘taste’ or ‘style’ about them) have a diminishing returns aspect to them…that is, many have an opinion and getting more opinions can reach a counter-productive point (i.e. religious battles).
1a) Time for discussion always has to be limited/cut off when shipping time comes around…which, although sometimes inconvenient is ultimately a good forcing function (because its the releasing, usage, actual feedback that really helps the design)…as long as there’s a next release
.
2) I don’t really buy the argument that programming language designers (or even book authors) should be able to describe what they think is right for programming practice, style, etc…and then have tools implementers implement it. That’s just not how real software is done, IMHO.
3) I agree with you that considering various points of view is good, but in the toString case (i.e. a google soc student), after looking at the bug discussion I think there was a pretty good amount of review/feedback…it just didn’t happen to involve some points of view (Cay I guess). And FWIW, I don’t happen to agree about the super.toString() usage…as it can easily add a lot of unnecessary complexity to the result. I have no idea if this was going through the mind of anyone who implemented it, but I wouldn’t be too surprised.
RE: equals/hashcode…personally, I’m not inclined to use auto-generated versions of equals and hashcode either, just because implementing these methods are so subtle that falling back on code templates just doesn’t ever feel right to me. But I do also know that lots of people have lots of opinions about exactly what makes a perfect equals/hashcode…and I do think that although some have very good arguments, and I personally listen to them, they are ultimately opinions (that people sometimes want to treat as facts).
>So, in that case, I ask my original question: how can I get a >hashCode and equals generator that better suits my needs >without overwhelming the UI with duplication?
I think that this is where Eclipse’s flexibility can/does really shine…because if you want to introduce multiple ways of doing something, and give people preferences to choose among them…then it’s easy…e.g. extension points, new APIs, etc. I know nothing about how the equals/hashCode/toString generators were actually written, so I don’t know this for sure, but I would be that it would be almost trivial to (e.g.) provide multiple alternative styles, and let the use select among them (perhaps as user preferences, or on the code generation dialog…whichever works the best).
This does have a cost (more UI…i.e. to select among alternatives), but with some amount of cleverness I think this additional complexity can be minimized.
Anyway, my $0.02.
Scott, you’re the first one I’ve spoken with who has actually said that he disagrees with the assessment. That, more than anything else, is what I appreciate.
Yeah, extension points defining a variety of generators and a nice preference sounds like a good way to solve the problem locally.
In my opinion, it’s simple. Those who participate at Eclipse, get to set the technical direction. That is one of the values of participating in an open source community at Eclipse where there are a lot of commercial interests.
In Rob’s example, I think a simple bug would suffice. No one is perfect.
On Cay’s blog, it seems he figured out how to use the template mechanism in JDT. However, it seems no one has filed a but which makes me really sad… I really wish people would file bugs more at Eclipse. I don’t know how to make this any better.