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