Stefan Matthias Aust wrote:
> 
> >Another, entirely unrelated question is: How do I start writing a
> >"classical application". I.e. something with a polished, shiny user
> >interface, where the user isn't aware that he's doing Smalltalk
> >(other than, of course, in an About box where Squeak is listed among
> >the credits)?
> 
> That's not easy with Squeak as one requirement would be a "polished"
> and "shiny" GUI which IMHO Squeak doesn't have.  If you're comfortable
> with Windows applications, Dolphin Smalltalk (www.object-arts.com)
> might be a better tool.  DS is free until you want to actually deliver
> an application.  In that case, you've to buy an application deployment
> kit.

Windows conformance isn't the primary goal. Of course, many are used to
Windows, so some degree of conformance would be helpful - but it's a
nice extra, not a KO criterion.

> If you still want to use Squeak, you've to create your own framework.
> Fortunately, this isn't as difficult in Smalltalk as you might think.

Difficulty is less of an issue. The interesting question is: How much
work is it? :)
Seriously: how do I start doing my own framework? How much of the
existing framework must be replaced, rewritten, or modified? How much
traps for the unwary lurk on that road? Do I have to read specific texts
to know enough, do I have to fiddle with the system, or do I just go
ahead and everything will magically work as I wanted it?

> Second, Squeak isn't very good in interacting with other tools.  It
> completely ignores the hosting operation system and does what is does
> on its own (Newest example is true type support - really cool but the
> reinvention of the wheel).

It's not a serious problem. More precisely: It is not a problem at all,
at least for one-man shops.
There may a problem for large teams. 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.

> Interaction is of course possible but again you'd have to do it on
> your own.

Well, most is already there. What I'm missing is sound that doesn't
start croaking and stuttering once I begin to move large windows around
(or start other CPU hogs), but I think (I *hope*) that's more a question
of priorities than anything else.

> Here's a sketch of a system (actually the changes that are needed to
> be applied) that IMHO is better suited to [make Squeak suitable for
> developing commercial applications]:
> 
> The system architecture is based on a micro kernel which can be
> extended with binary modules.

Already present I think. Theres a Howto for doing your own primitives,
isn't it?

> There's still an image for development, but the deployment version
> will be created from modules.  Name spaces help to build independent
> modules.

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.

> A small core without GUI can read in and process Smalltalk files.

Visual Works can do that (it's called "headless system" there). They use
it for Internet servers and the like.
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.

> There's more than one Screen possible and Screens can be manipulated
> from Squeak - this would allow a multiple window application with
> keeping compatibility with the old system.

This would be generally useful. Multi-CRT systems are becoming
commonplace, so it would be a good idea to have more than one Screen
object anyway (each with separate size, resolution, placement, and color
depth). Macs have had this for a long time, X has this from the
beginning, and Windows is now beginning to catch up.

> 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.
For Windows, it would be easier to make a Squeak that runs in
full-screen mode and use the hardware screen as Screen object.

> Other modules should offer networking or database support.

Networking should be present already (Swiki etc.).
However, both networking and database support are extremely difficult to
get right. Both tend to separate data from their classes, and that
creates all sorts of difficulties.

> The system needs a full documentation of all public methods and a
> strict separation of public and private methods, similar to the
> JavaDoc output.

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.
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
for. Protocols could also be used to implement some interesting
reliability mechanisms as introduced in the Eiffel language (most
prominently Design by Contract, see http://www.eiffel.com; don't let
yourself get confused if you see Eiffelists talk about classes, as an
Eiffel class is both a Class and a Protocol).

Regards,
Joachim
-- 
Please don't send unsolicited ads.