Stefan Matthias Aust wrote:

[ snip ]


> 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).  Interaction is of course possible but again
> you'd have to do it on your own.

I agree somewhat.
I like to keep my applications as portable as possible, and Squeak helps with
that,
perhaps at the expense of some reinventing. But there are interesting
parts of the world outside the Squeak image that I'd like my applications to
interact with.
And I'd like to be able to interact with those things as portably as possible.
Many of these can be reached through a network interface, but many cannot
(without writing lots of network interfaces for the rest of the world). 
I'd like to have my apps talk to relational databases, programs written
in other scripting languages, web browsers (multiple users simultaneously while
performing
potentially long-running queries from other systems), my PalmPilot, pager, FAX,
printer, etc.

>
> Squeak, as I think most people see it, is a toy, a playground for new
> ideas. It's not meant as an (rapid) application development system.
> Nothing against that.

I don't see it as a toy, although I more regard my work as fun when I am using
it.
It does need a bit of work here and there to be able to handle my current
projects, but
I don't think it is that far off. I do see it as a rapid application development
system.

>
> However, I see a demand for a second kind of Squeak.  A Squeak tailored as
> a tool - not a toy - for creating applications (games, financial programs,
> other tools, whatever).  Something like a free alternative to other
> commercial Smalltalk systems.  Something, which not only awakes warm
> feelings in the heart of true Smalltalkers but which attracts even ordinary
> people ;-)

Yes, I'd like to see this aspect or capability grown into Squeak. But would
prefer not to see
another fork in development. Too much of that is going on already.
I'd like to see a coordinated scheme that can handle these more mundane
applications
as well as the exciting new stuff.

> 
> Here's a sketch of a system (actually the changes that are needed to be
> applied) that IMHO is better suited to fullfill this.
> 
> The system architecture is based on a micro kernel which can be extended
> with binary modules.  There's still an image for development, but the
> deployment version will be created from modules.  Name spaces help to build
> independent modules.
> 

Sounds good.

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

I see two types of Smalltalk files: declarative smalltalk text files or binary
image packages.
Text files for quickie scripting scenarios where Perl or Python might be used
today. Binary
packages for fast startup and the ability to plug a powerful GUI development
environment into
my script when it crashes or needs help.

> 
> 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.

I like this. But it sounds like we need some threading support to do this
effectively.
I think threading to be an important addition to Squeak.

> 
> 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)
> 

OK.

> There's a Swing (a platform-independent Java-GUI) like GUI for Smalltalk.
> As GUIs are one of my favorite interests, I could write more about this in
> a different article.  The GUI should be event driven and very easy to use.
> In contrast to traditional GUI frameworks, it should use the idea of
> Morphic or the Oberon System/3 system of directly manipulationable widgets
> which would make a separate GUI builder superfluous.  I was very impressed
> when I saw a demo of the phaidros' Jump system - they use the same idea.

Yes. A commercial quality GUI is important.

> 
> Other modules should offer networking or database support.
> 

Yes. I've started on some database support, since it's those sorts of projects
paying my bills.

I'd also like to see multi-user persistent object support be available for many
platforms (Even a PDA plugged into the network might like multi-user access. And
doesn't everyone want persistence?) 

I wonder if something like an enhanced LOOM (virtual object memory) would be
adequate?

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

Perhaps. 

> 
> The system should stay as compatible as possible with both the ANSI
> Smalltalk and the existing Squeak system (in this order).
> 

I agree with this. But it would be best if we could structure things so that
these things could really interoperate. Be able to plug database access in to
store your music scores or your digital paintings or other multimedia Squeaky
work. Or be able to plug in the cool graphic stuff into your 
otherwise boring business app to really navigate and make sense of your mounds
of data. I'd like
the ability to build something like the current environment or the proposed
environment from the
same code base. 
I'd still like to keep compatible with the current mainstream Squeak
developements--I'd like to
be able to plug in the Construction Set to help teach my kids programming (I
need their help as soon as possible!)


> Comments?


> bye
> --
> Stefan Matthias Aust  //  Don't talk.  Just doIt.

That's what I feel. Why follow wander off into Pythonia because Squeak doesn't
do quite what
I want? Don't follow the snake: stick with the mouse. Just makeIt doIt.

-Mark Schwenk