Classical Applications (was Re: 17 new updates)

Joachim Durchholz joachim.durchholz at
Sat Feb 13 17:03:37 UTC 1999

Stefan Matthias Aust wrote:
> Joachim wrote:
> >Windows conformance isn't the primary goal. [...]
> There was once a time, I'd have demanded a strict Windows look as this
> is the only look you can use to sell applications.  At least, this was
> my personal experience.  Currently, I feel different.

Actually I think this is changing. The Java people already have decided
that they will do their own look-and-feel. I'd second that: Better a
well-working proprietary look-and-feel than half a dozen half-working
Actually the gaming industry does this all the times.

> A Windows-like feel is still important IMHO (that is, something that
> looks like a button should work like a button and an edit menu should
> contain the usual commands with the usual shortcuts) but the look
> might be different.

Possibly. You still have to placate the Mac, fvwm (sp?), KDE, ...
people. The feel of these GUIs is *definitely* different (to the point
that I avoid Unix machines because it would take me weeks to get as
proficient with its use as I'm with Windows right now).

> If you make your GUI customizable, a lot of people with real and good
> graphics design skills will jump in and create marvelous looking skins
> or themes, better than probably I could do this. Just look at the X
> Window window manager Enlightment or a program like EFX for Windows.
> The website has some 176 different new looks for Window
> borders.  It's amaizing.

Interesting. This looks like a call for factoring out the look-and-feel
aspects of a system. (Though I don't have the slightest idea how to do

> However currently Squeak hasn't a complete GUI framework and it looks
> either simply strange (and oldish) or just amateur-like (as the
> emphasize was always on functionality but not on optics).

I'm under the same impression. However, I doubt that those who are used
to this GUI style share it. I remember I found nothing wrong with the
old Windows 3.0 GUI, but when they switched to the three-dimensional
buttons and more "modern" stuff, my perception quickly changed. Working
with the old File Manager makes me nostalgic now...

> I think, I'm not the only one who judges programs by the first
> impression. If I download some shareware or freeware program and it
> looks ugly or isn't immediately understandable - there have to be very
> good reasons to try it further.  Anybody knowing Rational Rose?  It's
> a powerful (and very expensive btw) program, but its diagrams look
> ugly (and the preselected colors aren't easily to change) and it's
> very difficult to use.  I bet, they do it this way to sell not only
> programs but also training classes ;-)

This matches my experiences. I find that I'm very short on temper on
those programs that are not aesthetically pleasing, relatively
regardless of the actual useful content behind it. I try to fight that
tendency, but I'm only human after all.
I think Rational was seriously hurt by the deficiencies of the GUI. (And
they reworked it in a recent release. Curiously enough, the regular
stream of complaints about Rose on comp.lang.object entirely stopped
after that release.)

> >Squeak doesn't interface with version control systems (as far as I
> >know), so it can be difficult to keep everything consistent. The
> >large number of calls for help after a failed file-in of the newest
> >additions and modifications is actually a hint that Squeak has a
> >*serious* problem here.
> You're so right here.  Therefore, I think a modular Squeak would be
> required.

Modular, yes. Private/public methods, no (probably, tentatively - I'm no
expert in what has been tried for Smalltalk and didn't work already).

> >Having independent modules is generally a good idea, but I'm not sure
> >whether bootstrapping a fresh deployment system is really necessary;
> >other techniques might work as well.
> I've a different opinion here.  Stripping an image is like real
> horror.
> Perhaps it's my irreal distrust in the process, but you'll never be
> sure that all your unused methods are removed (especially if you use
> much polymorphism) but not more.  And you can't update just parts of
> your software or create an architecture which loads parts of the
> application on demand.

Hmm. I don't share this distrust, but then I have seen systems that work
well for this.
  Not in Smalltalk, but for SmallEiffel. It's a compiler for a
statically-typed language, so the techniques employed there may not work
well enough for Smalltalk, but I'll highlight its capabilities anyway.
  SmallEiffel (named in honor of Smalltalk actually) goes about by doing
something that I call "type-flow analysis". IOW it looks at all object
creations and does a pessimistic data-flow analysis about which point of
code these objects may ever reach. For methods that are known to be
called only for certain object types, dynamic dispatch is entirely
replaced by static calls (and a typical program can staticize about 90%
of calls). Calls with few (about two or three) alternatives are done
with an if-then-elseif...else construct. These things allow more
advanced optimizations, like call inlining, low-level data-flow
analysis, and peephole optimizations (not all of them actually in
  Ah yes, and now the most interesting (and controversial): Numbers. A
typical SmallEiffel program has dynamic dispatch removed for about 90%
(!) of all calls. Images can get as small as 4 KB (when all error
checking is removed; still included is a run-time system with garbage  
collection and dynamic dispatch). This is regardless of the size of the
standard library involved; anything that isn't needed is pruned out.
  Of course, these optimizations are at the expense of extendibility.
You cannot add a class to a running SmallEiffel system. You have to name
a top-level class with a feature that will be called on system start-up,
and the system will stop when the feature is done.

> >OTOH I don't think this is a real problem, if you don't specifically
> >need to write a non-GUI thing. Virtually every OS has a GUI, and if
> >you do everything within Smalltalk, you don't need a GUI-less
> >program; you just prepare a class with a method that does what you
> >want, with as much user interaction as you want.
> I might misunderstand you, but I think this is again the Smalltalk is
> the whole world, there's nothing outside of Smalltalk approach.

Right. Smalltalk isn't really intended to interface with an outside
world. I'm also pretty unsure whether this so much gain in doing that,
except for very special circumstances. The outside world has no notion
of object-plus-class, so you're perpetually guessing what class should
interpret some data if you want to do anything with it in Smalltalk.
(Well, the problem is the same with conventional processing, but if I
wanted to do conventional data processing I wouldn't switch to
Of course, there are exceptions, like networking or large databases
(small databases would work better within Smalltalk I think). But I
don't think it's worth the while to get access to a color-gradient text
label control.

> >> Optionally, a high performance full screen mode (based on DirectX on
> >> Windows for example) can be used for other kinds of applications
> >> (games, for example)
> >
> >Might be useful, but I doubt it can be done with reasonable effort.
> >Smalltalk graphics is based on BitBlt alone, so it cannot really make
> >use of all those 3D features.
> I think you thought about Direct3D here.

Right. You were talking about games, weren't you :)
Seriously, I think DirectX can be used to implement primitives, but I'm
unsure whether Smalltalk has the primitives that can be mapped to
DirectX. DirectX is a relatively new concept, and the BitBlt ideas are
rather old. If Smalltalk hasn't radically changed its underlying
mechanisms I don't think it can make much use of DirectX.

> >I don't think a separation is really needed. After all, it's very
> >difficult to decide which method is private; the class author would
> >need precognition to tell what his clients may ever need.
> IMHO this feature is very much needed if you want to create and
> maintain frameworks.  It's btw very easy to decide.  Basically its a
> contract between the author and the user.  By making the method
> public, the author promises to keep this method and its semantics.  By
> making all other methods private, (s)he reserves the right to change
> the implementation.

Right. But the implementer never knows what contract he should draw up,
because he doesn't really know his users and their needs. More
importantly, he cannot guess with any certainty which distribution of
private/public methods will minimize total effort: if too much is
public, he will impede his own work, if too much is private he will
impede the work of the users, and the latter is simply unknown.

I'd use a different style of contracts: Each routine announces its
preconditions and postconditions. Internal routines tend to have lots
and complicated preconditions (and strange postconditions), so nobody
will bother to use them unless they are *really* desperate.
  This would also make it easier to estimate the consequences of a
file-in: Which methods have a changes precondition or postcondition? A
file-in is potential trouble if it strenghtens a precondition or weakens
a postcondition.
  Finally, those preconditions and postconditions that are Boolean
expressions can be checked by the system at run-time; this has been done
in the Eiffel language and is considered *the* major advantage of the
language by the Eiffel community. (As one major contributor to
comp.lang.eiffel once said: "It's like having the system single-step
your code and alerting you whenever it detects something fishy.")

I can present this in a more formal fashion with all the necessary
details spelled out if anybody with a serious interest in implementing
this would like to see it. (Together with a rationale why I think which
mechanism is useful, so there is a basis for a discussion how much of it
should be included in Squeak, be dropped, or be done in an entirely
different way. Actually it's not my ideas: I'm stealing shamelessly from
Eiffel here.)

Of course decorating all the zillion methods in the Smalltalk image with
assertions is a large task. But I think it's worth the effort, and it
should take lots of uncertaincy out of the use of Smalltalk methods.

> >I recently read the article on Smalltalk's philosophy and found a
> >much more intriguing notion: that of protocol. Formalizing protocols
> >would make reading Smalltalk code much easier: If each parameter had
> >a declaration that said "only objects that answer to protocol foo are
> >allowed here", I could much more easily determine what a method is
> >good [...]
> That's a kind of type system similar to Java's interfaces and indeed
> very useful.

Not sure where you see the similarities, or wether they are relevant.

> However, it's difficult to enforce while keeping Smalltalk's dynamic
> type system.

Not at all. Use understands: in a precondition, and you're done :)
Of course it's all run-time checks, but that's the Smalltalk style
anyway. I do prefer static checking (for various reasons), but dynamic
checking is more powerful, and a modern system can do enough analysis to
precompute many checks at compile time.

Please don't send unsolicited ads.

More information about the Squeak-dev mailing list