<br><font size=2><tt>Hi Jimmie,</tt></font>
<br>
<br><font size=2><tt>Wow! Talk about an effective argument. I digest this into:</tt></font>
<br><font size=2><tt> "You said.... and Traits supports this, so it is good." It's nice</tt></font>
<br><font size=2><tt>(and sobering) to know that people actually read my blather.</tt></font>
<br>
<br>
<br><font size=2><tt>And regarding the bit about brittleness, I agree that in general,</tt></font>
<br><font size=2><tt>smaller is better, but sometimes in a world with hundreds of</tt></font>
<br><font size=2><tt>people working on the project it is better to "make your own"</tt></font>
<br><font size=2><tt>than to use the one provided in the common library. Really, we</tt></font>
<br><font size=2><tt>do have a common library and there are some people always working</tt></font>
<br><font size=2><tt>on it and it is always a source of headaches (at least from my</tt></font>
<br><font size=2><tt>perspective), and invariably, "my own" is smaller and simpler</tt></font>
<br><font size=2><tt>than the Swiss Army Knife the library guys are trying to provide</tt></font>
<br><font size=2><tt>as a one size fits all solution.</tt></font>
<br>
<br><font size=2><tt>I know I have seemed to be very opposed to Traits, but I am not so</tt></font>
<br><font size=2><tt>opposed to the concept as I am to the runtime cost of accessors.</tt></font>
<br>
<br><font size=2><tt>If I could wish for only one single improvement to Squeak, it would</tt></font>
<br><font size=2><tt>be better send performance. I've looked at this problem on and off</tt></font>
<br><font size=2><tt>for a while now, but as for you, Squeak is mostly a personal thing</tt></font>
<br><font size=2><tt>for me (DSP and media streaming for VoIP is the day job), and I</tt></font>
<br><font size=2><tt>haven't yet come up with anything better than what Squeak currently</tt></font>
<br><font size=2><tt>has. My best ideas just take too much memory to be acceptable (to me).</tt></font>
<br>
<br><font size=2><tt>It still bothers me that we have telephones now with megabytes of</tt></font>
<br><font size=2><tt>RAM in them. There's more computer in the phone on my desk now than</tt></font>
<br><font size=2><tt>there was in the computer on my desk not so many years ago.</tt></font>
<br>
<br><font size=2><tt>Anyway, Thank You.</tt></font>
<br>
<br><font size=2><tt> -Dean</tt></font>
<br>
<br>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>Jimmie Houchin <jhouchin@cableone.net></b></font>
<br><font size=1 face="sans-serif">Sent by: squeak-dev-bounces@lists.squeakfoundation.org</font>
<p><font size=1 face="sans-serif">08/31/2005 03:25 PM</font>
<br><font size=1 face="sans-serif">Please respond to The general-purpose Squeak developers list</font>
<br>
<td><font size=1 face="Arial"> </font>
<br><font size=1 face="sans-serif"> To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org></font>
<br><font size=1 face="sans-serif"> cc: </font>
<br><font size=1 face="sans-serif"> Subject: Re: Traits approaching mainstream Squeak</font></table>
<br>
<br>
<br><font size=2 face="Courier New">Dean_Swan@Mitel.COM wrote:<br>
[snip]<br>
> The other idea that I was trying to get across is that code reuse is a <br>
> double-edged sword. While it can reduce maintenance effort, and improve <br>
> the overall quality of a code base, it also makes the codebase more <br>
> brittle by introducing heavily loaded single points of failure.<br>
<br>
This doesn't make sense to me.<br>
Increases quality and makes more brittle.<br>
<br>
I would think that better quality code...<br>
More readable, understandable code...<br>
Potentially smaller set of code...<br>
<br>
Would lead to more robust and less brittle.<br>
<br>
Now as to single point of failure. Uh, maybe.<br>
But find and fix and it then should be fixed.<br>
And again leading to more robust.<br>
<br>
[snip]<br>
> So I guess I'm still looking for somebody to show me the "good-ness" of <br>
> Traits, because so far it looks interesting, but like a lot of work for <br>
> a small increase in code reuse and a (hopefully) small decrease in <br>
> performance, and we've been seeing a "small" decrease in performance <br>
> with each successive version of Squeak for way too long now. This is <br>
> (of course), only my opinion. I could certainly be in the minority here.<br>
> <br>
> Traits shows clear value in refactoring, but refactoring is "code <br>
> cleaning", and it doesn't happen much in the real world. In fact, it is <br>
> sometimes "forbidden" because it is seen as a high risk to touch code <br>
> that is "field proven".<br>
[snip]<br>
<br>
Now, I have no real world (commercial) development experience. I play <br>
with Squeak as my preferred environment for my projects. So with that <br>
disclaimer, take what I say for what you paid. :)<br>
<br>
Squeak has had 20-30... years of single inheritance experience in it. <br>
How much of Squeak's code is older than your project?<br>
How much of Squeak's code is older than developers on your project?<br>
(Rhetorical Qs)<br>
<br>
The point is that Squeak is a long lived, malleable, living program. <br>
Much is spoken of the cruftiness or uncleanness or parts of Squeak. This <br>
is despite the fact or due to the fact that it is so long lived. In this <br>
place and this situation, improved refactorability would be a great <br>
asset. It seems to me that is greatly desired by the users and <br>
developers of Squeak that it be refactored so that the original vision <br>
as expressed by Dan Ingalls and as stated by you here in this message:<br>
http://lists.squeakfoundation.org/pipermail/squeak-dev/2000-April/000775.html<br>
<br>
"""<br>
I personally am opposed to gratuitous creation of new classes. I <br>
think it is contrary to one of Dan Ingalls' original design principles <br>
of making the whole system simple enough to be understood by a single <br>
person. Squeak already defines about 1200 different classes in the base <br>
image, which I think is an awful lot of different "kinds of things" to <br>
understand.<br>
"""<br>
<br>
I don't know, but maybe Traits can help with the problem you describe <br>
above. Maybe in introducing the flexibility of Traits we can reduce some <br>
bloat without reducing features and functionality.<br>
<br>
I can only speak from my experience. But I constantly refactor my code.<br>
Why, because I seldom get it right the first time. I write the code and <br>
then run the code. Frequently it doesn't behave as I thought in my mind. <br>
Why, because my understanding of the problem was incomplete. As my <br>
understanding grows, I change, modify and refactor my code. That may or <br>
may not be very professional, I can't say. But I don't think it is too <br>
uncommon. Squeak makes such a process less painful. Traits may further <br>
aid such processes.<br>
<br>
As for C++, it isn't Squeak. It isn't alive. Its frozen.<br>
C++ seems to me in its adding of flexibility added complexity.<br>
Here Traits seek to add flexibility while increasing simplicity.<br>
</font>
<br><font size=2 face="Courier New">I can't speak for your project. But it doesn't seem like simplicity, <br>
agility, or understandability of the system is a priority. Hopefully it <br>
is so for Squeak. And thus I speak my case as I understand it for Traits.<br>
<br>
I would think that many, many, many commercial projects would benefit <br>
greatly by many of these practices which simplify and refactor code. <br>
Code seems to often live longer than expected and often having <br>
unexpected consequences. Refactoring and having clean code is of great <br>
value. Or at least it should be.<br>
<br>
I like Squeak because it is a living, organic system. I have used too <br>
much dead software. Software that was fixed, frozen and unmalleable. <br>
Incapable of doing what I wanted because the program had no vision. Oh <br>
that all my software was in something like Squeak.<br>
<br>
Enough ramblings. My apologies for the run-on-ramblings. ;)<br>
<br>
Jimmie<br>
<br>
</font>
<br>
<br>