Squeak-dev August 2005

squeak-dev@lists.squeakfoundation.org

157 participants
234 discussions

Re: Smalltalk and Self
by Marcus Denker 01 Sep '05

01 Sep '05

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

8 9

Current Harvesting Status/Organization
by Ken Causey 01 Sep '05

01 Sep '05

I'm wondering what the current status is of the harvesting process from the standpoint of the harvesters. I'm a little bit bothered by the most recent addition to 3.9alpha. Judging from the HTTP info 6667TallySupport-ab.cs went into the update stream on the 22nd or 23rd. For some reason this update has no preamble although the versions both in BFAV (closed by the Janitors) and with the issue (ID 1014) on Mantis have preambles. Also the issue on Mantis is still marked as new and there is no evidence that harvesting (beyond the review step) is occurring regarding this issue. I realize we are in a highly transitional time here and that as a result there may be some confusion, but even if we don't have solid stated procedures I would hope that anyone modifying the update stream will make some effort to maintain a minimum level of documentation regarding the handling of each issue. Admittedly I'm complaining here a little bit. But more than anything I would really like to have a bit better understanding of how updates will be entering the update stream in near future and what sort of changes, if any, those doing that work would like to see in the process. Very shortly I want to state publicly that in my opinion the future of Squeak progress is in the form of individuals and teams taking direct responsibility for packages and parts of the image. I think that anyone who has an interest in doing this should not wait and should speak up ASAP. Ken

7 8

LineMorph class
by Mariano Wahlmann 01 Sep '05

01 Sep '05

Hi, my name is Mariano Wahlmann, i'm using Squeak3.8 and I have a questions about LineMorph class: Why exists the new method as class method instead of having an initialize method?. I ask this because if you want to extend this class, you have to re-write new and initialize methods. Is this maybe a bug?. Thanks

4 4

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

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

RE: Smalltalk and Self
by Dean_Swan＠Mitel.COM 01 Sep '05

01 Sep '05

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

2 1

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

01 Sep '05

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

1 0

RE: Smalltalk and Self
by Jecel Assumpcao Jr 01 Sep '05

01 Sep '05

I was going to say that we are getting too off topic, but on second thought it is a good thing to remember the past as accurately as we can in order to better plan the future. What follows are just my opinions and I would be glad to receive any corrections, though I was very involved in both Self and Squeak and have a pretty good memory for events (but, sadly, not for names or numbers). 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. > > Source code available under an open source license is not the same thing as > "a Squeak-like open source **development project** for the language and > IDE." In other words, a license is not a project, and a legal document is > not a socio-cultural movement. The availability of the Self source code > never sparked anything resembling the level of enthusiasm or participation > engendered by the release of Squeak. I will argue that only two people mattered: Andreas (Windows) and Ian (Unix). Note that while the original Mac team (John, Dan and others) were far more important in that without them there would be no Squeak at all, Self had an equivalent team and I am only interested in the differences. We might call the phase from 1987 to about 1996 the "Objective-C" era where many people thought that the ideas in Self were really cool and decided to create their own language mixing these with other things they liked. Most of the languages in the following table are from back then, though Io and Slate are very recent projects from the same tradition: http://www.dekorte.com/docs/protos/ The phase from 1996 to about 2000 was the "Digitalk" era where many people thought that Self itself was cool but wanted something smaller that would run on the hardware they actually had. This got us OpenSelf, JSelf, DSelf and my own tinySelf variations. Note that by the start of this phase Self 4.1 was done and copies of the Self movie had been given out. This newer version of Self had been significantly refactored to make smaller implementations and porting easier. But for me to take a look at that would have required my signing a NDA and I decided to pass on that. I also wanted to buy some copies of the Self movie but they weren't making more. I was able to get permission to make my own copies in limited numbers for friends but wasn't allowed to distribute it more widely. Now this is just wild speculation on my part but my impression was that the Sun legal team was not at all happy with having Self 4.0 available under a BSD license but there was nothing they could do about it. This is what I was talking about in my previous email. There was an older version available to the public which we could legally do anything we wanted, but the current version and the video were locked away. So we continued to use this older version but it didn't seem wise to invest in it if that would upset Sun even if the license said we could. Of course not everybody worried about these things and at least three different people contacted me for help in porting Self to the PC. Though I encouraged them I didn't really expect them to do it. One would have to learn both Sparc and x86 assembly language, for example. And none had access to a running Self system. In 2000 things changed significantly at Sun and Self 4.1 was finally released with the same BSD license as all previous versions. Development was restarted and the following versions were also made available. Last year I received permission to make the Self movie available on the Internet. So things are much improved though we can never make up for all those years that were lost. These changes encouraged yet another person (Gordon Cichon) to try a x86 Linux Port though he stopped halfway. Harald Gliebe finished the port in 2001. In short: the Self world lacked its Andreas and Ian which was the main factor why Self and Squeak followed different paths. > Squeak was released in late 1996, at a time when there was still a > significant body of Smalltalk practitioners, many of whom at the time were > hungry for a free, open-source Smalltalk implementation (for a variety of > reasons that shouldn't need to be enumerated here.) Self has never been in > a similar situation. And regardless of its open-source availability, it has > always been perceived as a research project, not as a production-quality > development platform (regardless of the fact that perception is not always > reality.) There was certainly a vast lack of information about Self (as there is to this day) and that is the only reason your argument makes sense. As you said, perception is not reality. The reality is that Self was fully compatible with Smalltalk-80 through GNU Smalltalk's class library and an alternate syntax parser. You could use the familiar system browser, inspector and other tools if you wanted. The only things missing was MVC - this was a Morphic-only system. We are talking about an open source Smalltalk that outperformed VisualWorks by a significant margin (VW has since gained a lot of Self's advanced technology). > Also, as you yourself surmise, the difficulties involved in porting Self > from the Sun/SPARC platform to other platforms such as the x86 and/or the > Mac probably made no small contribution to the general lack of interest in > Self. The difficulty is easy to evaluate if you consider the history of JIT in Squeak. Squeak didn't depend on this and kept going even with the occasional complaints about performance, but for Self the choice was JIT or nothing. We ended up with nothing until 2001. > Other factors that may have been important would include a) Self was seen by > the "general public" as a product of Sun, and Java was seen as Sun's "golden > child"--this perception would have damped the enthusiasm of outsiders > regardless of Sun's attitude internally; b) Self is not statically typed; c) > Self syntax does not resemble C syntax; d) the pool of competent Self > programmers has always been far smaller than that of Smalltalk today, let > alone than that of Smalltalk in 1996; e) UML doesn't handle prototype-based > languages well at all (which in my view is a problem with UML, not with > Self); and f) many of those for whom most or all of the previous issues > would have been moot were and are far more interested in languages such as > ML, Sather, Haskel and Scheme. You make it sound like people were aware of all this and made a logical choice not to use (or at least look at) Self. I doubt that was the case for all but very few. The main thing is to see what we can learn from all of this and what should we do about it in relation to Squeak: 1) as Alan Kay likes to say, the main virtue most popular programming languages had was simply that of having a usable implementation for whatever computer people happened to be using. "Showing up is the better part of winning". Which is why I say that the Windows and Linux ports were the most significant event in Squeak's history (I would also praise John McIntosh's Mac development, which I am sure is not due to his name ;-). The PDA ports were also important though their full impact hasn't been felt yet. 2) people in general are reluctant to learn new things. Squeak started out as very familiar ("blue book" + color) and very slowly grew into something new. What we now have is shocking for many people. Some of us would like to see it become even more so, others would be happier going in the opposite direction. -- Jecel

1 0

Jump to page: