Squeak-dev September 2005

squeak-dev@lists.squeakfoundation.org

157 participants
266 discussions

Re: Traits approaching mainstream Squeak
by Blake 01 Sep '05

01 Sep '05

On Wed, 31 Aug 2005 22:36:07 -0700, Alan Lovejoy <squeak-dev.sourcery(a)forum-mail.net> wrote: > Blake> I'm intrigued by the question of "is inheritance necessary" > > Perhaps a better question would be "Is inheritance optimal?" Or even > better: "When is inheritance optimal, and when is it not? And when it > isn't, > what alternatives are better?" > > --Alan Well, yeah, I was just shooting for brevity rather than technical precision.<s> I don't know how other people work, but when I learn a new programming technique, I push it till it breaks. I'm looking forward to testing traits out thoroughly.

1 0

Re: Traits approaching mainstream Squeak
by Chris Muller 01 Sep '05

01 Sep '05

> Is any of this seriously debated? I mean, traits notwithstanding, has > anyone who has ever built a large hierarchy of objects NOT run into the > above problems? Traits are not required to avoid bloat or duplication that comes with inheritance, just use composition. Granted, it requires explicit delegation (or a DNU hack) but, many times, only a small portion of the behavior of the provided by the Collection (or whatever) is needed. This, in fact, can help understand a system better because the only "inherited" behavior is explicitly declared by the fowarding messages. I'm not at all opposed to Traits in the image, especially if it is not disruptive to function or performance. I'm sure I'll even find a good use for it some day.. - Chris

3 2

Re: Traits approaching mainstream Squeak
by Dean_Swan＠Mitel.COM 01 Sep '05

01 Sep '05

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(a)cableone.net> Sent by: squeak-dev-bounces(a)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(a)lists.squeakfoundation.org> cc: Subject: Re: Traits approaching mainstream Squeak Dean_Swan(a)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.ht… """ 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

2 1

downloading and installation help
by ron 01 Sep '05

01 Sep '05

Hi, I am new to Squeak and also a beginner in using the Linux operating system. I have successfully downloaded these packages: PracticalSqueak.zip Squeak-3.8-6665-i686-pc-linux-gnu-3.7.7.tar.gz from this address: http://www.duke.edu/~bmp5/squeak/getsqueak.html and extracted them in a folder in my home/ron directory. But I am confused on what to do next. I found the squeak bin executable in: /home/ron/Squeak/Squeak-3.7-7/i686-pc-linux-gnu/usr/local/lib/squeak/3.7-7/squeak copied it to /user/local/bin/squeak then set my kde menu to /user/local/bin/squeak but Squeak doesn't start up. I am using fedora core 3 Can you tell me what I am doing wrong? Your help would be greatly appreciated. Thank You, Ron

3 2

Re: Smalltalk and Self
by WonDerer222＠aol.com 01 Sep '05

01 Sep '05

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(a)telus.net writes: Dean_Swan(a)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

2 1

Wiki Vandalism again
by Hans-Martin Mosner 01 Sep '05

01 Sep '05

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

5 4

Jump to page: