Why we should remove {} from Squeak

Andreas Raab Andreas.Raab at gmx.de
Mon Oct 1 07:58:07 UTC 2001


Stephane,

First of all, if you're making a pretty polemic proposal (I think not only I
found your "examples" of {{}} etc. to be polemic and your last message just
dumped more oil on the fire) then you shouldn't be surprised to get
responses in a similar tone. Having said that, let me point out a few issues
that you seem to be overlooking (note that I'm *not* trying to be polemic
here, all of the examples I'm giving you are true to the point):

[Re: Difference between @ and {}]
> There is a big different @ is a message
> not a parsed construct with specific rules!!!!!

Sorry, but that's wrong. @ (and all binary operators) are just that: Parsed
constructs with specific rules. From a point of purety we don't need them.
We could just write:
	(1 add: 2) times: (3 add: 4)
and get exactly the same result that we get today from
	(1+2) * (3+4).
So fundamentally there is no difference whatsoever between @ and {} - both
are parsed constructs and both have specific rules.

[Re: Use of {}]
> > The construct is useful and widely used.
> Widely in which code????
> Where? more than OrderedCollection?

Counting all the references to OC comes up to 720 (on my system; your milage
may vary) - and very many of them are used in a form that would not be
equivalent to {}. Whereas the cumulative references to {} (note that you
have to add all of the #braceWith: variants as well as #braceStream:) come
out to 692. So the answer to "more than OrderedCollection?" is, yes, for
constructing an immediate collection of Objects, {} is in fact more used
than OrderedCollection. Again, I'm not trying to be polemic here - these are
facts that you can count for yourself.

[Re: Looking for simplicity]
> I thought that Smalltalk was looking for simplicity.

Simplicity and purety are two different things. "Simple" can mean different
things to different people. Originally, Smalltalk was intended to be a
language for kids (but, alas!, how far away has it gotten) and I don't think
that kids who learn in school that 4+5*6 equals 34 will find it simple that
Smalltalk evaluates this to 54. They might find it pure if they can
comprehend the reasoning behind it ... but simple?!

[Re: The price we pay]
> I like the simplicity of Smalltalk and I'm ready to pay the price to
> use convention for expressing private, dealing with operator
> by hand....

I think that is the real point. What price are we willing to pay. As I've
said above (and as has been pointed out by other posters) we could
theoretically live without a lot of constructs, including binary operators,
$ for character creation, #() for literal array creation, etc. But we're
simply unwilling to pay that price because we've got used to the convenience
these expressions give us. If that is so, then your message comes down to
two problematic points

#1: The ability to write horrible constructs
That's certainly an issue but I don't think it's as bad as you're making it.
Briefly glancing over some of the 672 methods that use brace construction I
couldn't find any that used it in a truly ugly way. Which means that most
people using the construct use it in the way it should be used. Ugly code
can be written with many syntactical constructs, including, for instance:
	(a := b > 5 ifTrue:["doSomeThing"]) ifNotNil:[
		...
	].
I find the above at least as ugly as some of your examples (note that the
hidden ifFalse: branch will in fact evaluate to nil and the assignment in
the expression doesn't help readibility either).

#2: Not being ANSI compatible
Again, certainly an issue but for people who wish to write stuff that ports
easily over to other dialects, they're not required to use this construct.
As you have pointed out, there are alternatives and if one wishes to write
easily portable code then he or she just has to pay the price. If not ...
why pay it?

Cheers,
  - Andreas

PS. One last note which might be considered a bit polemic so it comes only
after the actual message:

> Having operators is useful too, I would like to have
> operators too because I prefer to type
>    2 + 3 * 6 than 2 + (3 * 6)
> and because this is MATH and MATH are right!
>
> I hope you see my point.

If your point is that we should not have appropriate operator precedences,
then I don't see it. I find absolutely nothing wrong with them. There are
plenty of language (Prolog, for example) dealing with operator precedence
pretty well and at the same time not restricting people to use only built-in
operators. So actually I agree - I want operator precedences too! ;-)






More information about the Squeak-dev mailing list