Hi Andreas,
on Thu, 22 Feb 2007 09:17:21 +0100, you wrote:
Klaus D. Witzel wrote:
C'mon :) Isn't this the same with a) Interpreter, b) Seaside, c) Compiler & NewCompiler, d) Monticello, e) Morphics, f) <put your's here>
Not sure which part you are referring to here. Whether you mean the number of people really understanding those systems, or whether you mean that the self-implementing part, or whether you mean that the usefulness of any of the above is intrinsically tied to an tool dependency.
Let's say: yes.
I understand and share parts of your critique, in fact Traits seems to be more at the heart of "it" and lacks efficient tool support but, try to make a substantial change to a) - f) or ask more than the respective dozen of people to describe, in understandable terms, how these a) - f) effectly work: absolutely no difference, nil, zero, zippo. No offense intended, Andreas. But Traits is no exception the way it can be interpreted from your postings.
You are of course right. If you interpret it that way, it's not correct. My criticism is elsewhere: I am very upset about how much harder it is to understand traits than any of the things you mention above. I went through the NewCompiler in an afternoon, Seaside took me weekend, I actively hacked on Monticello. In all of these cases I was able to navigate and learn a large and completely unknown (and sometimes not too pretty) code base in a very reasonable amount of time.
In the traits implementation I failed miserably, and I am not quite sure why. That is my criticism of traits. And it is quite possible that this is related to insufficient tools, but I'm sorry, if I can't understand how things ought to work then I won't be able to help building tools for it.
I agree [with the implication as well as its anaphor :-]
Smalltalk (Squeak) was built and is maintained by an elitarian group of people (a), also the packages.
And "it" is being used, debugged and extended by an even more so elitarian group of people (b), which on SqP are called users (!). "it" being libraries, classes, methods, or whatsoever code (even isolated lines).
The (b)'s are even more skilled (resp. a second kind of skill) because they clean-up the junkyard[1] produced by (a) raisedTo: time.
For the time being, the application of Traits to itself seems to transcendent some of the (b)'s :)
But Traits must become usable for the (b)'s, no question.
/Klaus
[1] as an example, with Java you can't expect that your changes to core classes (example: java.lang.Class) will ever make it into the mainstream; this is an example of the kind code that I think is on the developer's junkyard.
Cheers,
- Andreas