(replying to other comments in this thread) Personally, I still like
reading Slashdot. It may have a problem with signal-to-noise sometimes,
but you can always browse at +2 or higher to eliminate much of the
clutter. Considering how Slashdot readers might come look at this list,
we might want to be a bit more broadminded.

In the case of this post, I think the student had numerous good points
that Squeak should address. (Obviously the student and I might disagree
about the value of the Smalltalk keyword syntax which I love and
consider a real strength of the language -- now, if I could just merge
it with Python's indentational significance which I also love.) In part,
this is exactly what Tom in "Re: Announcing to the world.." was
concerned about -- the rough edges of Squeak make it unpleasant for many
people to pick up -- especially people used to other systems. Because
Squeak does not clearly win in every category(e.g. modularity, speed) it
becomes a "compromise" to use it -- not a "no brainer".

Here are some substantial issues raised by the student with my
elaborations:

The student wrote:
> The Squeak IDE is one of the most frustrating pieces of software 
> I've ever had to use. 

I've taught computer programming to biology majors for several
semesters, and I've definitely learned that the "listen to your users
but ignore what they say" applies equally for students giving feedback
on a course. Yet, if someone points something out, there probably is an
issue somewhere. 

This frustration could come from several reasons (MP3 support was
mentioned) but I know there are deeper issues with Squeak, as the
student goes on to point out.

There are numerous typical issues learning Smalltalk as well which may
have arisen if the instructor was coming from Scheme (a fine language --
check out DrScheme.) 

LearningWorks attempts to address some of them -- principally that it is
difficult to know what is important in the image (a recent post to this
list raised this as well). They have made changes to the browser and
debugger to hide unnecessary complexity for a particular learning
exercise.

Also, because there are no firewalls in the sense of having development
tools in one VM talking to an application in another via remote
debugging (as is now common under say VC++ or some Python development
tools) it is difficult to experiment with the core of the system.

> Slow, 

Very true, depending on your machine. I'd like to know what version and
machine the student used. Squeak Version 3.0 is near unusable on the
180-Mh PPro NT system I use. Yes, my machine is behind the times, but
Squeak1.13 under MVC was much snappier, and I use other OO systems on
that machine with various GUIs that work well. Granted in about 10 years
machines will be 1000X faster, and 100000X faster in 20 years, but that
doesn't mean unnecessary waste is a good thing, in part because we want
Squeak then to run on $0.01 machines, which will be same as what I have
now. I think the sluggishness is probably a symptom of design and
implementation issues. I've even heard key Morphic developers have said
on this list it needs an overhaul for various reasons. 

Also, the lack of modularity makes it hard to put in place an
alternative faster GUI. Why not just use an earlier version? Because
only 3.0 (2.9?) was trying hard to be event driven and have that support
in the VM. Lack of events meant lost clicks and such which is
frustrating in earlier versions (and makes Squeak unsuitable for user in
a shippable application because I know users won't put up with any
significant number of lost clicks these days.).

> ugly as sin (both the original MVC and the newer Morphic GUI), 

Obviously this is a matter of choice. But MVC is not the pretty out of
the box (although it could be in theory). And Morphic, while it looks
better, still has IMHO issues with how the development process (e.g.
handles) integrates with the pretty look (though handles look nicer in
3.0). 

> and bloated as all hell. 

Right on. We've gone from a base system that was several megabytes to
one that is about twenty. There are endless extra classes in the system
contributing to learner confusion. Again, this stems in large part from
lack of modularity. GNU Smalltalk for example has a package loading
system and ships with a small core -- why can't Squeak?


 > But good luck trying to turn it into a binary to 
> distribute to your friends, because you can't! 

Absolutely correct. And this is a big issue for many people. There is no
one click make an EXE. You can ship the entire system but for hello
world or a text manipulation program it takes up way too much space
(again lack of modularity) and there is more than one file that need to
go (at least the EXE and the image) and in the minimal case you will get
complaints on startup. Obviously Perl and Python have this issue too
(although Python can be "frozen" into an EXE with a script).

And don't ask them to try and learn the language either, because there's
no documented API, and the purportedly self-commented code really isn't. 

> Did I mention that that same code sometimes breaks on you, 
> fresh from an install? Yep, believe it.

Wouldn't surprise me too much, given the lack of modularity. Well,
actually it would if what the student did was identical from a base
image, but I'd accept that it happens (perhaps for subtle reasons the
student does not notice like load order). Again, there is a flaw in the
approach somewhere that this can be perceived to be happening.

Obviously it is stinging to everyone involved with Squeak to get remarks
like these (after 4+ years since release) but these issues raised do
exist and they are one reason Squeak has been less successful than it
will be. (Personally I'd like nothing more than to fix all these
shortcomings if I could find the time.)

I think one reason these problems persist is that SqueakC wants to
create a development environment for children and novices (who just stay
in Morphic and maybe do some scripting, as their examples show, and they
have accomplished amazing things as the Morphic 3.0 car demo shows) and
Squeak is good enough now for those sorts of apps (especially sicne they
control the mainline that is "supported" in the sense of being rolled
forward). 

I want a development environment for the power programmer, and perhaps
so does that student, and Squeak still lacks in many of those areas (as
useable as Squeak is for someone willing to put up with its limitations
and use it for the things that Squeak does well right now).

-Paul Fernhout
Kurtz-Fernhout Software 
=========================================================
Developers of custom software and educational simulations
Creators of the Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com

Ned Konz wrote:
> 
> On Wednesday 18 April 2001 07:21, Wouter Gazendam wrote:
> > Might be an interesting advocacy:
> > http://slashdot.org/article.pl?sid=01/04/18/001236&mode=thread
> >
> > Wouter
> 
> There's an interesting response from a Georgia Tech student (one of Mark
> G's?):
>  http://slashdot.org/comments.pl?sid=01/04/18/001236&threshold=1&commentsort=0&mode=thread&pid=52#60
> 
> The overall tone is summed up by:
> 
> "Squeak has been the worst programming language I've ever had to deal with
> (out of the seven or eight I've learned).
> The Squeak IDE is one of the most frustrating pieces of software I've ever
> had to use."
> 
> But (s)he goes on to describe why.
> 
> --
> Ned Konz
> currently: Stanwood, WA
> email:     ned at bike-nomad.com
> homepage:  http://bike-nomad.com