Classical Applications (was Re: 17 new updates)

Bijan Parsia bparsia at email.unc.edu
Fri Feb 12 04:44:39 UTC 1999


At 5:43 PM -0500 2/11/99, 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.

There is a very, very, very, very, very good reason to do this and it's
*not* portability ;)

It's completeness. The idea that your *whole* computing world can fit
inside your head...that you don't have to engage in a radical mode shift as
you explore your system.

And example of this is how in many Smalltalks, the VM is outside the
system. You can't browse the code (it's probably not even written in
Smalltalk). If you're going to mess with it you have to go to a whole other
set of tools. Bleah! I say, *bleah*!

If I understand things correctly, one of the main goals of Squeak Central
is to make an "exquisite *personal* computing system". Of course, the more
personal, the more it must be tailored to one's own personality. If one is
a developer, developing applications for others, it may be that the needed
tailoring is so extreme as to move Squeak away from the personal system
goal. But, of course, there's nothing stopping *anyone* from setting up a
Squeak Pro Central with the specific goal of migrating the system toward
professional cross-platform development. I'd even bet that Regular Squeak
Central would help out and, as is reasonable, sync up.

But there are extant Smalltalk systems that meet the pro needs. I don't see
that Squeak loses by their existence and Squeaker's use of them.

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

Well I use it for rapid application development, I guess. But for personal
apps. I'm not a programmer (OK, this is a somewhat confusing statement, but
true in an important sense ;)), and I'm *certainly* not a professional
programmer.

Would there be barriers to using it in a corporate setting? I'm sure. I'm
also fairly sure that for certain purposes those barriers could be overcome
with the current 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 ;-)

Where *is* this demand? Who is it demanded of? Perhaps you meant 'need'?
'Niche'? 'Market space'?

Strange enough, the people I've "won over" to Squeak were *all* "ordinary
people". I'm utterly baffled by the apparant tension between you're notion
of a "tool" and the alledged appeal to ordinary people. Let's not run away
with the rhetoric here. If Squeak doesn't do something for you, do
something to it until it does or adopt one of many fine alternatives.
Squeak won't die; you won't die :)

[snipped a bunch of specs]

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

Well, if I understand your desire, *no* Smalltalk system does the "strict
separation" of public and private methods, and most Smalltalks don't want
such a separation. (I don't.) Of course, it's relatively easy to add, I
understand

>The system should stay as compatible as possible with both the ANSI
>Smalltalk and the existing Squeak system (in this order).
>
>
>Comments?
>bye
>--
>Stefan Matthias Aust  //  Don't talk.  Just doIt.
						   ^^^^^^^^^^^^^^^^^^^^^^^
I go back to taking 		this line				to heart.

Cheers,
Bijan.





More information about the Squeak-dev mailing list