Marcus Denker | 1 Sep 2005 01:05
Picon
Picon
Favicon

Re: Smalltalk and Self


Am 01.09.2005 um 00:12 schrieb Jecel Assumpcao Jr:

>
> In short: the Self world lacked its Andreas and Ian which was the main
> factor why Self and Squeak followed different paths.
>
But if you then look at the development of Tweak/Croquet
and the latest discussions on the vm-list, it seems they learned their
lesson and now are using a much more closed (hostile?)
form of development...

So something clearly did not went the right way with Squeak from their
perspective.

One thing that the Traits discussion again has shown that it is very  
hard
to innovate in Squeak. There is a huge hostility against doing new
things, even if the alternative is complete standstill.

     Marcus

Dean_Swan | 1 Sep 2005 01:16
Favicon

Re: Traits approaching mainstream Squeak


Hi Jimmie,

Wow!  Talk about an effective argument.  I digest this into:
 "You said.... and Traits supports this, so it is good."  It's nice
(and sobering) to know that people actually read my blather.


And regarding the bit about brittleness, I agree that in general,
smaller is better, but sometimes in a world with hundreds of
people working on the project it is better to "make your own"
than to use the one provided in the common library.  Really, we
do have a common library and there are some people always working
on it and it is always a source of headaches (at least from my
perspective), and invariably, "my own" is smaller and simpler
than the Swiss Army Knife the library guys are trying to provide
as a one size fits all solution.

I know I have seemed to be very opposed to Traits, but I am not so
opposed to the concept as I am to the runtime cost of accessors.

If I could wish for only one single improvement to Squeak, it would
be better send performance.  I've looked at this problem on and off
for a while now, but as for you, Squeak is mostly a personal thing
for me (DSP and media streaming for VoIP is the day job), and I
haven't yet come up with anything better than what Squeak currently
has.  My best ideas just take too much memory to be acceptable (to me).

It still bothers me that we have telephones now with megabytes of
RAM in them.  There's more computer in the phone on my desk now than
there was in the computer on my desk not so many years ago.

Anyway, Thank You.

        -Dean




Jimmie Houchin <jhouchin <at> cableone.net>
Sent by: squeak-dev-bounces <at> lists.squeakfoundation.org

08/31/2005 03:25 PM
Please respond to The general-purpose Squeak developers list

       
        To:        The general-purpose Squeak developers list <squeak-dev <at> lists.squeakfoundation.org>
        cc:        
        Subject:        Re: Traits approaching mainstream Squeak



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.

[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.
"""

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.
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.

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.

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




Simon Michael | 1 Sep 2005 01:13
Gravatar

Re: Wiki Vandalism again

Jochen F. Rick wrote:
> Are there any keywords they are using? like viagra? hot asian women? etc? 
> that you want me to ban?

Hi Jochen,

you won't be able to keep up that way.

Here's a system that has been effective for me for a while:

- accept unrestricted edits from identified users, who have clicked once 
to set a (permanent) username cookie

- block edits by anonymous users which contain more than N occurrences 
of "http://", where N is 0, 1, or whatever. Give some kind of indication 
so that the legitimate anonymous user knows what happened and how to 
become identified to remove the restriction. Trade-off - if you make 
this hurdle too low the spammers may jump it.

Dean_Swan | 1 Sep 2005 01:20
Favicon

Re: Traits approaching mainstream Squeak


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





David P Harris | 1 Sep 2005 01:31
Gravatar

Re: Smalltalk and Self

Marcus Denker wrote:

>
> Am 01.09.2005 um 00:12 schrieb Jecel Assumpcao Jr:
>
>
>>
>> In short: the Self world lacked its Andreas and Ian which was the main
>> factor why Self and Squeak followed different paths.
>>
> But if you then look at the development of Tweak/Croquet
> and the latest discussions on the vm-list, it seems they learned their
> lesson and now are using a much more closed (hostile?)
> form of development...
>
> So something clearly did not went the right way with Squeak from their
> perspective.
>
> One thing that the Traits discussion again has shown that it is very  
> hard
> to innovate in Squeak. There is a huge hostility against doing new
> things, even if the alternative is complete standstill.
>
>     Marcus
>
>
>
Jecel-
Thanks for the history lesson.  I think I agree with your points. 

Marcus-
But if one wants the status quo, surely one just adopts a specific Squeak. 
Traits would seem at this point to be the best of both worlds: 'old' 
Squeak is unaffected, and experimenters can try out the newer technology. 

David

Dean_Swan | 1 Sep 2005 01:53
Favicon

RE: Smalltalk and Self


Alan Lovejoy wrote on Tue, 30 Aug 2005 23:07:00 -0700
> Jecel>I don't understand - Sun wasn't able to utterly kill Self in 1995
> > because they *had* previously released it all as open source.

Well, Sun has demonstrated the ability to kill things quite dead.  Remember NeWS?  Such a shame.  So Gosling went off and tried to recreate the glory of NeWS in Oak (becomes Java).  Sigh....

        -Dean

David P Harris | 1 Sep 2005 01:53
Gravatar

Re: Smalltalk and Self

Dean_Swan <at> Mitel.COM wrote:

>
> Alan Lovejoy wrote on Tue, 30 Aug 2005 23:07:00 -0700
> > Jecel>I don't understand - Sun wasn't able to utterly kill Self in 1995
> > > because they *had* previously released it all as open source.
>
> Well, Sun has demonstrated the ability to kill things quite dead. 
>  Remember NeWS?  Such a shame.  So Gosling went off and tried to 
> recreate the glory of NeWS in Oak (becomes Java).  Sigh....
>
>         -Dean
>
>------------------------------------------------------------------------
>
>
>  
>
I'd have to say he missed the mark by quite a wide margin :-(
I bought a second-hand Sun 3/60 so I could run NeWS....

David

Jecel Assumpcao Jr | 1 Sep 2005 02:41
Favicon
Gravatar

Re: Smalltalk and Self

Marcus Denker wrote on Thu, 1 Sep 2005 01:05:22 +0200
> Am 01.09.2005 um 00:12 schrieb Jecel Assumpcao Jr:
> > In short: the Self world lacked its Andreas and Ian which was the main
> > factor why Self and Squeak followed different paths.
> >
> But if you then look at the development of Tweak/Croquet
> and the latest discussions on the vm-list, it seems they learned their
> lesson and now are using a much more closed (hostile?)
> form of development...

My impression is the opposite. From the very start Squeak has been about
rumors, followed by neat demos, with public releases only happening much
later. Both Tweak and Croquet started out following this tradition and
then became much more open last year.

> So something clearly did not went the right way with Squeak from their
> perspective.

The first major part of Squeak that was developed in a relatively public
way was the 3.3 modules and that led to a lot of anger and people
leaving our community. While I don't think there was any relation at
all, I can understand it if some people hesitate to do things this way
again.

My impression is that most of the core Squeakers like the open source
way but aren't fanatics about it. Only John Maloney has spoken out
against it and feels Scratch is better as a closed product.

> One thing that the Traits discussion again has shown that it is very  
> hard to innovate in Squeak. There is a huge hostility against doing new
> things, even if the alternative is complete standstill.

Things have always been this way. I have told this story several times,
but perhaps some people still haven't heard it. Back in 1998 I had to
make a serious choice in my project: either go with Squeak or develop my
own technology (with the goal of making it more Squeak compatible over
the years). My own technology would be based on Self so I would have to
buy a Sun machine (without a monitor!) for US$5000 as a development
system. If I adopted Squeak instead I could get the most high end PC
possible (to compensate for Squeak's lower performance) and would still
have money left over for other investments. And to me a strong community
is far more important than technology (see Linux vs BSD). So I poked
around to see what people's reaction would be if I tried to get the
simplifications I felt were needed into the core of Squeak. My
impression was that a vocal (and possibly large - it is hard to tell)
part of the community would reject my changes and I would end up with a
fork, all alone with a few people cheering on from the sidelines. We
will never know if I was right, of course. My decision was that if I
couldn't have the community anyway, then I might as well not compromise
on the technology.

Meanwhile, other people have been following other paths. Some are very
conservative while others tried new things. I think there is very good
and allows the community to accept things as they demonstrate their
value rather than having to bet on them beforehand. Once the
demonstrations are available, however, rejecting them without trying
doesn't make sense.

-- Jecel

Sean Glazier | 1 Sep 2005 03:02
Picon

RE: Wiki Vandalism again

The spammers have tools to get around those.

-----Original Message-----
From: squeak-dev-bounces <at> lists.squeakfoundation.org
[mailto:squeak-dev-bounces <at> lists.squeakfoundation.org] On Behalf Of oxe
Sent: Wednesday, August 31, 2005 4:24 PM
To: squeak-dev <at> lists.squeakfoundation.org
Subject: Re: Wiki Vandalism again

how about adding one of those "type in the letters you see here" jobbies ?

that must be getting to be a fairly standard package by now..

orion

Jochen F. Rick nadja-at-cc.gatech.edu |squeak devlists| wrote:
> Are there any keywords they are using? like viagra? hot asian women? etc? 
> that you want me to ban?
> 
> Peace and Luck!
> 
> Je77
> 
> PS reply to me and not the list.
> 
> On Wed, Aug 31, 2005 at 08:41:29PM +0200, Hans-Martin Mosner wrote:
> 
>>Hi,
>>recently I've been fixing vandalized Swiki pages almost every day - 
>>looks like somebody has implemented some auto-vandalizer script or so.
>>Could the nice folks who run the Swiki (hi Mark!) maybe add some code 
>>which checks whether the e-mail alert addresses contains HTML tags and 
>>reject (or silently ignore) submissions in that case? That would at leas 
>>stop this one vandal.
>>
>>Cheers,
>>Hans-Martin
> 
> 

WonDerer222 | 1 Sep 2005 03:56
Picon
Favicon

Re: Smalltalk and Self

Please remove my email address from your address books.
Thank you
 
 
 
 
In a message dated 08/31/2005 7:53:42 PM Eastern Daylight Time, dpharris <at> telus.net writes:
Dean_Swan <at> Mitel.COM wrote:

>
> Alan Lovejoy wrote on Tue, 30 Aug 2005 23:07:00 -0700
> > Jecel>I don't understand - Sun wasn't able to utterly kill Self in 1995
> > > because they *had* previously released it all as open source.
>
> Well, Sun has demonstrated the ability to kill things quite dead.
>  Remember NeWS?  Such a shame.  So Gosling went off and tried to
> recreate the glory of NeWS in Oak (becomes Java).  Sigh....
>
>         -Dean
>
>------------------------------------------------------------------------
>
>

>
I'd have to say he missed the mark by quite a wide margin :-(
I bought a second-hand Sun 3/60 so I could run NeWS....

David



 


Gmane