On 31 août 05, at 21:25, Jimmie Houchin wrote:


> Dean_Swan at Mitel.COM wrote:
> [snip]
>
>
>> 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.
>>
>>
>
> This doesn't make sense to me.
> Increases quality and makes more brittle.
>
> I would think that better quality code...
> More readable, understandable code...
> Potentially smaller set of code...
>
> Would lead to more robust and less brittle.
>
> Now as to single point of failure. Uh, maybe.
> But find and fix and it then should be fixed.
> And again leading to more robust.
>

same feeling here.


>
> [snip]
>
>
>> So I guess I'm still looking for somebody to show me the "good- 
>> ness" of Traits, because so far it looks interesting, but like a  
>> lot of work for a small increase in code reuse and a (hopefully)  
>> small decrease in performance, and we've been seeing a "small"  
>> decrease in performance with each successive version of Squeak for  
>> way too long now.  This is (of course), only my opinion.  I could  
>> certainly be in the minority here.
>> 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".
>>
>>
> [snip]
>
> Now, I have no real world (commercial) development experience. I  
> play with Squeak as my preferred environment for my projects. So  
> with that disclaimer, take what I say for what you paid. :)
>
> Squeak has had 20-30... years of single inheritance experience in  
> it. How much of Squeak's code is older than your project?
> How much of Squeak's code is older than developers on your project?
> (Rhetorical Qs)
>
> The point is that Squeak is a long lived, malleable, living  
> program. Much is spoken of the cruftiness or uncleanness or parts  
> of Squeak. This is despite the fact or due to the fact that it is  
> so long lived. In this place and this situation, improved  
> refactorability would be a great asset. It seems to me that is  
> greatly desired by the users and developers of Squeak that it be  
> refactored so that the original vision as expressed by Dan Ingalls  
> and as stated by you here in this message:
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2000-April/ 
> 000775.html
>
> """
>      I personally am opposed to gratuitous creation of new  
> classes.  I think it is contrary to one of Dan Ingalls' original  
> design principles of making the whole system simple enough to be  
> understood by a single person.  Squeak already defines about 1200  
> different classes in the base image, which I think is an awful lot  
> of different "kinds of things" to understand.
> """
>

nobody is for creating classes for the sake of it (even if we  
introduce Beeper :).
Now a class is an abstraction and having 3 classes instead of a large  
a difficult to read one is much better to
help you to understand.

For example: why halospec creation methods are defined on preference  
class and not on Halospec
this is just one examples.



> I don't know, but maybe Traits can help with the problem you  
> describe above. Maybe in introducing the flexibility of Traits we  
> can reduce some bloat without reducing features and functionality.
>
> I can only speak from my experience. But I constantly refactor my  
> code.
>

me too.


> Why, because I seldom get it right the first time. I write the code  
> and then run the code. Frequently it doesn't behave as I thought in  
> my mind. Why, because my understanding of the problem was  
> incomplete. As my understanding grows, I change, modify and  
> refactor my code. That may or may not be very professional, I can't  
> say. But I don't think it is too uncommon. Squeak makes such a  
> process less painful. Traits may further aid such processes.
>

same here.
Hence the importance of the RB engine because if refactoring takes  
one 10th of a second then you do it.
if it takes 5 min. then you don't.


> As for C++, it isn't Squeak. It isn't alive. Its frozen.
> C++ seems to me in its adding of flexibility added complexity.
> Here Traits seek to add flexibility while increasing simplicity.
>
> I can't speak for your project. But it doesn't seem like  
> simplicity, agility, or understandability of the system is a  
> priority. Hopefully it is so for Squeak. And thus I speak my case  
> as I understand it for Traits.
>

us too.
even if as I said in my exhcanges with andreas. Sometimes I would  
favor readability over fine-grained reuse.



> I would think that many, many, many commercial projects would  
> benefit greatly by many of these practices which simplify and  
> refactor code. Code seems to often live longer than expected and  
> often having unexpected consequences. Refactoring and having clean  
> code is of great value. Or at least it should be.
>
> I like Squeak because it is a living, organic system. I have used  
> too much dead software. Software that was fixed, frozen and  
> unmalleable. Incapable of doing what I wanted because the program  
> had no vision. Oh that all my software was in something like Squeak.
>
> Enough ramblings. My apologies for the run-on-ramblings. ;)
>

:)


>
> Jimmie
>
>
>