What I'd love to see in Squeak

Lex Spoon lex at cc.gatech.edu
Sun Feb 1 18:17:23 UTC 2004


Thanks, Aaron, we desperately need more people who can give thoughtful
suggestions on the initial experience.  All the old hats can really fly
with the current interface and so we are blind to these things.


Aaron Lanterman <lanterma at ece.gatech.edu> wrote:
> 1) I'd love a read-eval-print-loop that acts like all the other
> read-eval-print-loops I'm used to. 

There's a more efficient way: type a line and hit alt-p.  If there is no
selection, Squeak will select the current line automatically.  Keystroke
for keystroke, this is about the same as a standard repl.

But anyway, I see no problem with your suggestion.  If a volunteer were
to code this up -- and it shouldn't take long!! -- then putting it in
sounds like a good idea.  There is a design elegance to Squeak's
workspace as it is, in that it has the same interface as every other
text window in the system, but in this case I don't think it's worth it
if people are getting frustrated.

By the way, people have often mentioned that they learn some great
things about Squeak after watching an experienced guy for just 10
minutes.  There seem to be a lot of little interface techniques in
Squeak such as this one about auto-selecting the line.  We should get
rid of these as much as possible when they have no purpose,  but in the
meantime, keep in mind that Squeak is far easier to learn if you have a
little bit of access to experts.  The semester I taught the Squeak
class, I made a special effort to spend a few minutes every class
writing code in Squeak or looking things up in Squeak, so that people
could see how the interface is worked by someone who is used to it.


> 2) A standard multidimensional array class, built into the image, that
> everyone can depend on and use in a consistent way. Squeak arrays as far
> as I can tell are 1-D. (Maybe I'm confused on that and someone can help
> me.)

Yes, that would be wonderful.  Let me reemphasize David's suggestion, tohugh,
that you go look at MathMorph from the SUGAR guys in Argentina.  They
have a general linear algebra package.

In my opinion, it is a real shame that the stuff from the SUGAR group in
Argentina has stayed forked so long.  Now that we have SqueakMap, it
should be relatively easy to keep all those gooides updated with the
current image.  But no one seems to be volunteering, including notably
the SUGAR folks.  Did these guys all graduate or something?  :)


> 3) As an aside, I've sometimes wondered if it might be a good idea to give
> options for alternate syntaxes, which could be translated on the fly to
> standard Smalltalk syntax - people could type code in a form they're more
> accustomed to, and see it translated into standard Squeak code. Then
> after they get comfortable seeing that, they may start typing more and
> more in standard Squeak right away. Squeak with syntactic sugar - maybe
> call them "SugarSqueaks." There could be "SugarSqueakFortranStyle,"
> "SugarSqueakCStyle," etc. or something like that.

Maybe.  Hard to say.  The keywords notation, I admit, is something that
seems like a serious improvement and is not just being different.  Try
mapping it down to a C-like syntax and you will see the problem.  What
is the C function name for collect:thenSelect: ?  The closest I've seen
are Ada and Common Lisp, both of which have a short name *plus* optional
named arguments to functions.  This is familiar syntax, but it is much
more verbose.

In the end, the syntax seems small enough that people can learn it
pretty quickly.  The main place that the current syntax is unfortunate,
I think, is for complex math formalas; they tend to get a bit larger in
Smalltalk than in C or Java.  But even then, I am not sure how to
improve things.  And in the end, no programming language around can
fully match match notation, anyway.  It's tempting to live with the good
enough syntax for most purposes, and then possibly to design a
specialized parser or other input tool for individual applications if
you really need one.


> Basically, the shock of the initial appearance of Smalltalk has prevented
> me from seriously exploring it for over a decade. (Well, that and you
> could get Turbo Pascal for the IBM PC for $99, and who knows how much a
> commercial Smalltalk from ParcPlace cost back them).

It cost a LOT.  I hate marketing, but a good marketing group sure could
have come up with a better strategy here, and Smalltalk's situation
would likely be a lot different.  People do not spend four digits very
often on a language just to try it out; they *do* spend four digits on a
language they know works well, if they are part of a major commercial
effort.


> So, I'm wondering how to help others get over that initial shock, so they
> don't just say "what the hell is this, this looks very cryptic" and not
> dig further to find the good stuff.


Yah.

Though also, remember that a lot of new users will be motivated to learn
new stuff as long as they are seeing successes along the way.  So
another whole approach is to give examples like:

	matrix openInWorld
	
and:

	simulation setAlpha: 3.
	simulation restart.

	
And so on; simple commands with high power.  This is how Joe the Box
works, as you know.  Trying to map their old concepts into Squeak is
going to have some amount of pain no matter what -- it just isn't going
to be exactly the same.  So for new people, it seems important to focus
on the new abilities that are around.

Someone should do Joe the Digital Sound Wave, for ECE folks.  :)


-Lex



More information about the Squeak-dev mailing list