Stéphane,


Oh me, oh my!  I must apologize here.  I know that I am coming across
here as calling your baby "ugly".  And I can easily see how you might
think I am advocating some of the counterpoints I offer.  That isn't
my intent.

I'm glad that Jecel can afford to quit jobs like the one I describe.
I am not so lucky.  I don't necessaryily agree with the way things
are done, but they still manage to make a sizeable deposit my bank
acount every other Friday and give me interesting problems to solve
every day, so they must be doing something right.  So I give them
the benefit of the doubt and continue trying nudge the whole thing
towards a better state.

Early in my career, a marketing manager told me "The object of this
game is to remain employed."  I think this was good advice.


>Traits support a better factoring of code and reuse within and among 
>classes.

Agreed.  Please, teach us why this is important.  It is not
"intuitively obvious" even to some fairly sophisticated observers.


>> The other idea that I was trying to get across is that code reuse 
>> is a double-edged sword.  While it can reduce maintenance effort, 
>> and improve the overall quality of a code base, it also makes the 
>> codebase more brittle by introducing heavily loaded single points 
>> of failure.
>
>I do not buy that.
>I know a company that duplicated 3 millions of C++ code 15 times and 
>they are in trouble.

Three million lines of C++ code is a disaster already.  They wouldn't
need to duplicate it 15 times to get in trouble.  I would even say
3 million lines of any kind of code is trouble.  I don't believe that
there are many problems that people are currently trying to solve
with computers that justify this much code.  It's just too much
code for most people to understand.

I also assign some responsibility to the advancement of hardware
design.  When resources are abundant, people tend to be carefree
regarding their use of the resources.  If we didn't have hardware that
can run 3 million lines of C++, people wouldn't write 3 million line
solutions.

I am not trying to say that duplication is universally good.  I am
saying that 100% elimination of duplication ***can be*** very bad.

>> My point is 
>> that common behavior that COULD be reused and benefit from Traits 
>> is not usually identified until quite late in the game, after a lot 
>> of code has already been written, if it can be identified at all.
>
>then?

Then nothing.  You guys don't need a pat on the back.  You already know
that your work is significant and has value.  And just to state it
clearly, "I think that Traits is a significant development and has
significant value in advancing the state of software composition."
That doesn't mean I love it.  It is new and you should expect to
have to do some "marketing" if you want to see it accepted by the
masses.

>> So, in this 
>> respect I don't think that the Collection hierachy is a very strong 
>> example for showing the benefits of Traits.  You had my attention 
>> more with the RectangleMorph example.  There you were going to save 
>> 70 methods with only 3 classes involved.
>
>What can I say?
>You can use Smalltalk as it was 20 years ago.
>You can also use a trait image without using traits.

Oh come now Stef, you don't have to go getting all French on me. ;-)

You could say "Gee, maybe we could work on another paper that more
strongly shows the strengths of Traits and convinces the skeptics." ?

It's a strange phenomenon that there will always be detractors when
you try to introduce something new.  Often they are people who you
really don't like, but nevertheless, in order to prevail you must
still try to win them over.


>C++ is not flexible it is complex, complex and complex.

It is both, but we don't need to belabor this point.  I think we agree
that C++ is an abomination and scourge of good software development
everywhere.

>> Traits shows clear value in refactoring, but refactoring is "code 
>> cleaning", and it doesn't happen much in the real world.  In fact, 
>> it is sometimes "forbidden" because it is seen as a high risk to 
>> touch code that is "field proven".
>
>So what you are saying is that we shoudl not do anything.

No.  What I am saying is that there are very real, and significant
barriers to acceptance of Traits and the benefits thereof in real,
heavily funded and profitable projects, in spite of C++ and all
of the other ugliness that they are comprised of.

You need to know that there are really people out there who think
that "field proven" trumps "better designed, more easily maintained,
or more efficient", and many of these people are our bosses, and
they aren't completely wrong.

>So with that state of mind do you think that we would programming in 
>OOP today or still in assembly.

I think a lot of people program in C++ and Java.  I think very few
people engage in OOP, even though many may think that they do.

So if you've stuck with me this far (I know, I can be verbose, to say
the least),  I would just like to say you guys are very fortunate to
have Daniel Vainsencher on your side.  He gave a very nice, constructive,
diplomatic reply to my concerns.  And his reply more than anything else
persuades me that it is good to make the use of Traits possible in
Squeak.

And while I respect Daniel's reverence to Tracy Kidder, Ed Yourdon is
also worth consideration.

I still don't want to see anything get slower. ;-)

        -Dean




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20050831/7e677b31/attachment.htm