Smalltalk: Requiem or Resurgence? {Dr. Dobb's Journal (05/06/06) Chan, Jeremy}

Kendall Shaw queshaw at
Fri May 12 22:57:57 UTC 2006

Hmm, so many different people to reply to. I'll pick this one.

First off. Okay, I think my comments about "if it doesn't look exactly 
the same" are wrong. Yes, innovation is great, and there is plenty to 
improve upon in UIs. Some of the morphic GUI elements are pretty nifty, 
it's just that they are in some "weird" flat color and they appear 
within their own desktop on my OS desktop. So, I would refine what I 
said to be that "if your UI looks weird, it will be severely disadvantaged".

Like other people have said, if the app does something incredibly great 
than people will be so impressed that they won't care if the UI is "weird".

What is weird is subjective. So, if Microsoft makes it, or Apple (or KDE 
or Gnome), then it automatically becomes less weird than something 
someone else makes.

It there is an unusual UI that has a great feel to it, that can win out 
over the fact that it's unusual. Developing new UI ideas is good. 
Unfortunately, at this point, I don't think the new UI ideas in Squeak 
overcome the weirdness factor for normal desktop application users.

WxSqueak, if it could be launched without squeak's desktop appearing 
too, could probably make squeak more worth people's time to develop 
desktop applications with.

A great GUI would be different than the current GUIs and not be an 

goran at wrote:
> Hi!
> I am not really arguing here - just mentioning some pointers about these
> bullets that might be interesting to hear about:
> Kendall Shaw <queshaw at> wrote:
>> If your program doesn't look exactly like every other program and use 
>> exactly the same procedure they've had to use for every program, then 
>> game over, you might as well not have even bothered to write the program.
>> In squeak, the controls don't look or behave like the other controls a 
>> user will use on their computer, so game over, you might as well not 
>> have even bothered to write the program.
> ...or just use Dolphin for win32 apps - it is really nice for that.
> Or turn the app into a localhost webapp, like we are currently doing
> with the issue tracker we are writing.

My complaint about the GUI, doesn't have to do with Smalltalk, just Squeak.

>> It doesn't matter what I think about it. It's what the user is likely to 
>> think about it.
>> Most importantly though, I can't open emacs on squeak's desktop.
> wxSqueak doesn't "force" a deskop. Try the demo. And even so - why not
> run Emacs on the side? :) Or inside Squeak:

The point is that there is a barrier between the smalltalk in squeak and 
the files on my OS file system. Having a more functional editor inside 
Squeak, doesn't get rid of the barrier.

> And then we have Areithfa Ffenestri or what the heck it is called. ;)
> (the code for supporting multiple windows from within Squeak - but
> wxSqueak already gives you that actually)

Hmm. I'll have to look at Areithfa Ffenstri.

>> Also, I can't easily check a squeak application into a version control 
>> system, separate from other squeak applications, but together with other 
>> source files in other languages, and other files.
> Mmmmm, "easily"... well. There have been numerous approaches of
> mirroring Smalltalk code into files for that like MonticelloCVS or
> CVSTProj. I even hacked up a almost fully functional cvs pserver
> protocol implementation. ;) But these days Monticello is so convenient
> to use and just needs a file dir or an ftp server for team work - there
> is no real incentive to bother. Especially not now that MC2 is seeing
> the light.

The point again is about the Barrier between stuff that's in squeak, and 
what's on the file system. Even if there is some great squeak version 
control system, that means I'm locked into that system. I can't freely 
choose to switch over to Subversion or something else.

> And if the idea is to just "bundle" a snapshot with other snapshots of
> software - then just dump the .mcz into your choice of repo, no big
> deal.
>> I can't run find on a combination of squeak classes and other files.
> You shouldn't. ;) But apart from that aspect - adding a mirroring
> mechanism of source into files that is "live" shouldn't be that hard if
> someone really wanted to do it.

So, changing or extending squeak could make it different. I agree. If 
there were a live file system mirror that didn't depend on the 
individual instance of squeak that one person has on their desktop, that 
could eliminate the problem that I'm describing.

>> I can't easily include it in a test procedure involving multiple languages.
> Hmmm, why not? I mean - what makes Squeak harder to use in a test
> procedure than *any other* mixing of languages?

The barrier between stuff that's in squeak and what's on the file system.

>> I don't think you could easily distribute it as an rpm or a debian 
>> package etc. and deal with dependencies between squeak applications.
> You can very easily deploy a Squeak app as an rpm or deb. The simplest
> way is to just bundle the VM with the image. No external deps at all.
> And I can't see why Squeak would add any further obstacle than any other
> language in that respect.

Again there is the problem with squeak being monolithic. How would you 
handle dependencies between multiple squeak applications written by 
different people and dependencies on external software, from the 
external packaging system of your choosing, and not be locked into one 
particular packaging system?

>> I can't use installshield to integrate it into someone's squeak applications.
> Not sure what you mean. Making an "installshield" installer for a Squeak
> app is trivial. Just test:
> That is old though, Cees has improved it a bit and I am using it right
> now for our issue tracker.

That's an installer for Squeak right? Not a mixture of possibly 
interdependent software, some written in squeak and some not.

More information about the Squeak-dev mailing list