Smalltalk & Squeak featured on Slashdot

Bob Arning arning at charm.net
Thu Apr 19 14:56:15 UTC 2001


Glyph,

First, let me say thanks for someone who can put their gripes in perspective and avoid unnecessary hyperbole. Here are some thoughts:

On Thu, 19 Apr 2001 04:32:11 -0500 Glyph Lefkowitz <glyph at twistedmatrix.com> wrote:
>There is no clear way to write an application in smalltalk. From the minute I understood what an "image" file was, I realized that this could be an interesting issue, but the real deep problem is that the community (or at least Squeak Central) doesn't seem to take this seriously, since it's certainly possible to create custom image files that do what you want your application to do. It seems like the attitude is that writing software that will last for more than a few months involves maintaining a fork of some version of the baseline virtual machine yourself. 
>
>In search of someone else's answer to this problem, I scoured the net for changesets, loading everything that I could. I downloaded approximately 50 changesets, and every single one either gave me a walkback upon filein or conflicted with another seemingly innocuous changeset in such a way that a basic task (opening a Browser window, or better yet, entering the debugger) would give me a walkback. 
>
>Despite the pleasantness of the debugger, the sea of broken links, broken instructions, and broken code only gave me three conclusions to jump to: 
>
>1.	The open-source segment of the squeak and smalltalk community in general is a bunch of slobs who just write broken code and expect their users to deal with it and/or fix it. 
>2.	Nobody actually uses squeak for anything but writing the squeak VM, and it is in fact unusable for anything else. 
>3.	It is nigh impossible to actually write and maintain a significant amount of code which stays current with the SqC image, despite many heroic efforts to the contrary; so you have to have 6 or 7 different images lying around that you can actually run squeak code. 
>Various things about my investigations into the squeak community show me that conclusion number 3 is probably the true one, but I could easily see a frustrated, but slightly less curious person than I in the same situation jump to 1 or 2, and go back to their previous language of choice. It is my sincere hope that the Stable Squeak project will fix this, and make most of this little rant invalid in 2 months time. :) 

WRT the 50 change sets you found on the web, it may be that the authors (and I could be one of them) never bothered to update their code for newer versions of Squeak. Sometimes the lack of response from the user community or loss of interest by the author consigned them to the "no longer supported" category. If folks do care about the change, I suspect it will likely be kept updated or even brought into the main image. Please bear in mind, too, that Squeak is still an active search for a "better" way to do things and this means change. To expect that all code ever written will continue to function flawlessly in all future releases is too much to ask, especially when some of the things you may have downloaded were clever modifications to the base image that the author felt provided sufficient benefit for the risk involved.

WRT maintaining your application in the face of this change, there are several options:
1. Stick with one base image. Choose a Squeak version - 2.8, 2.9, 3.0, whatever strikes your fancy, and don't update it. Your application will basically run forever, assuming you can keep the underlying OS and hardware functional for that long. ;-)
2. Pick an image and stick with it until the next release is final. Use 3.0, e.g. up until the time 3.1 is finished. Then (and perhaps waiting a bit longer to let someone else find the *last* bug) migrate to the new version. If you have written defensively, this probably won't be a big deal. I've migrated my email client from 2.4 to 2.5 to 2.8 and it's never been a big job - and I'm totally flagrant in my disregard for boundaries.
3. Grab the latest alpha release and take every update as it comes. You'll find that you have more frequent pauses to re-sync your code than in the previous approach, but they will likely be shorter pauses and they will be occurring at the same time others on the list are going through the same issues so there is likely to be opportunities for sharing tips.

I think any of these can work. Which suits you depends on your own style and the needs of the application.

>*	too configurable: Why isn't inboardScrollBars default? Is the 6 pixels of saved screen real estate really worth confusing everyone who's never used a smalltalk system before? 

Do you really mean *six* pixels? After complaining of carpal-tunnel-inducing features, did you actually turn ON narrow scrollbars? :-) If you take the standard 16 pixels and multiply that by 4 or 5 for some browsers, remember that some folks may have smaller screens than yours, think about wanting to see two browsers side-by-side, etc, it's not too hard to see why having flopout scrollbars would appeal to some. Add to that the implicit indication of focus they provide and I often find myself wondering why so many OS's and applications have scrollbars permanently visible.

>Why would you ever turn smartUpdating, decorateBrowserButtons, or optionalButtons off? 

I have smartUpdating on, but occasionally wish I didn't. I have in the past kept two different versions of the same method in two different browsers as a quick way of toggling some code when I was trying to see which worked best under different circumstances. That said, I agree, it's a good thing. As to the buttons in the browser, they are off in my image and will stay off. My primary goal is to see the code and understand it - anything that might lead my eye and brain elsewhere is suspect.

>Also, I've twice accidentally removed a button from a window without any clear way to put it back... it seems like there ought to be some modality associated with editing/exploring the GUI vs. using it. 

I was about to say that there is... Oops, there *was* a way, but it appears to have been disabled, itself. I'm not sure whether this was intentional or a side-effect, but it's easy enough to reinstate should one so choose. Let's think, though, about what it means. One of the things that makes Squeak so interesting is the direct manipulation of things on the screen and that means basically everything on the screen. Disabling this entirely is easy (as would be re-enabling it), but I suspect that, having done that, the next call would be for disabling the editing/exploration of *some* morphs but not others (after all, what is the GUI and what is other stuff?). Endless debate could ensue on this point.

>If you resize a window or pane, the resizing rect will flicker violently until you move the mouse. 

That's interesting - some Unix users reported this a few months ago, but I was never able to duplicate it on my Mac. It appeared to be a difference in the way the respective VM's reported events. Just for fun, I repeated the experiment today and did see it. Looks like the Mac VM has finally caught up(!?) with the Unix VM in this regard. I'll see about getting that fixed soon. FWIW, this only appears when the preference #fastDragWindowForMorphic is on. I run with this one off - have you tried that?

>*	lacking in features: There is no such thing as an "open" dialog, or a menubar, or a tabular data display widget, as far as I can tell. (of course, this could just be an artifact of the next point) The "file list" window is almost a reduction to absurdity about bad UI. The C community has Nautilus, and Smalltalk has managed to come up with this? 

Could you say a bit more about what you find lacking? I don't know whether it addresses any of your complaints, but there are some alternatives - see the class comment in FileList2, e.g.

Cheers,
Bob





More information about the Squeak-dev mailing list