At 12:45 AM 3/30/2002 -0600, Aaron J Reichow wrote:
>> Remember, people aren't comparing Java to Squeak (or ML, or Haskell)
>> -- they're comparing it to C++.  In that comparison, Java looks pretty
>> good.
>
>On a Smalltalk list, I imagine they would be comparing Java to Smalltalk.

I thought that this list was already pretty much for the converted,
or at least the sympathetic.  "java sucks", "amen!" is, as they say,
preaching to the choir, at least here.  It may feel good, you may
get a good loud "amen" back, but it's not very productive.  Squeak's
a bit of a fringe language, if you could get a slightly bigger
bandwagon, that would probably be a good thing.  You might get
someone to write "Squeak for dummies".

> So, to get to the point, you should either quit whinging about
>> how much Java sucks and how misguided Apple is, or you should
>> do something about it.  And YOU should do something about it;
>> I also want to become more proficient in ML and Haskell, and I
>> will pursue whichever learning curve is gentlest.
>
>What would you propose?  I use Squeak in the real world, where
>non-squeakers see my apps.  I've written a couple small Mac apps with it
>that other people use.   I don't think trying to advocate to Apple would
>do much good.

There's at least one Squeak application that made me
go "wow!", and that was the player-piano/orchestra.  I
thought that was really cool.  However, I don't know what
was underneath it.  What would complete the "wow!" is seeing
that the code behind it (which I had a hard time finding)
is not too large, not too crammed full of special cases,
easy to reuse, easy to understand, easy to extend.

In terms of Java versus Squeak, I wouldn't promote Squeak for
writing compilers.  (Yes, I know some people do, but I know
someone who wrote an optimizing compiler in Fortran.  We did a
vectorizer in PL/1, too.  That doesn't mean it's a good idea.)
Java's type system isn't annoying enough there to make a
difference (and sometimes, it is very helpful to have
things statically checked), and a complex optimizing
compiler is not an easy thing to to test by pieces.

On the other hand, dealing with user interfaces, and presenting
data to users, seems to be something where Squeak's flexibility
might help you.  I'm working on something now that is best described
as underspecified ad-hoc middleware, in Java, and I find myself
bumping into what I know are artifacts of Java's type system,
frequently.  Furthermore, the development/testing goes in a much
different style than the compiler -- the server runs, I poink the
web page, I look at what comes out, if I don't like it, I dribble
in some breakpoints and try it again, stepping through to see
if I like what I see.  I don't debug compilers this way, you can
be sure of that.  The difference between this and a typical
compiler is that the interface (here) is very wide, and loosely
specified, and there's a relatively small amount of computing that
takes place between poink and redisplay.  In a compiler, the inputs
and outputs are well-specified, and there may be a tremendous
computing "distance" between them.

My one reservation is the threads.  Squeak (which is both a language
and an implementation) is, to my taste, weak there.  Java, a
language, is usually implemented with crappy threads.  My employer/
company (NaturalBridge) did a Java implementation that supports about
30,000 threads, which is "enough" for now, though in my personal
opinion clearly still limited.  Sun's trying to promote
asynchronous I/O (in jdk1.4) instead of cheap threads, which I
think is just plain insane on several counts.  It is vastly
easier to write (something like) a web server or transaction
processing engine if the code you are writing is structured
as a thread (or two) per transaction.  If Squeak has expensive
threads (like most Java implementations, not like NaturalBridge's,
not like Erlang) it will be somewhat limited for a class of
applications where I think it would actually be rather well-suited.

Another possibility, and here I would worry about security (maybe)
is in the design of games.  It just looks like Squeak should be
good for this, what with the nice UI.  I guess I should be a little
careful what I mean when I say "game".  I'm not talking about
3-D psuedo-realistic blood-n-guts foo, but little fun games,
along the lines of Tetris, or MacSokoban, or MozPong.  And maybe,
it could be put on the net.  It's been done before, but I would
hope that (because of the flexibility in the language itself) it
could be done better, or maybe very thoroughly (as in, could you
put together a framework so that you could implement every single
game in Hoyle, just "because it was there".)

So, I guess if I was going to do something productive, I
would download the latest stable version, and have another go
at doing something fun/useful, and take notes of everyplace
I got confused or frustrated, document that, and call it
Squeak for dummies.

David Chase