Fear and loathing of the "perification" of Smalltalk

Peter William Lount peter at smalltalk.org
Thu Sep 13 08:03:58 UTC 2007


Paolo Bonzini wrote:
> (My first post to squeak-dev, I think).
>
>>    "Same as using curly braces but importantly NO syntax changes 
>> needed!"
>>    list := [a. b. c] objects.
>
> I don't buy this.  You simplified the syntax, and you have added 
> complexity to the compiler.  Because no, you cannot implement this in 
> pure Smalltalk (unlike ifTrue:ifFalse: or ifNil:ifNotNil:).  Making up 
> Smalltalk-like syntax that does not have anything to do with 
> Smalltalk, is one of the most common mistakes I've seen, and the most 
> common sign that your love for a language has been corrupted into 
> religion.
Ok, it's fine with me that you don't buy this. That's means we have 
different opinions about it which is excellent in my view. Difference 
can often foster innovation and advancement. Time will tell if it does 
in this case.

I never said it can be implemented in "pure Smalltalk". In fact I 
explicitly stated that a "new statement evaluator" in addition to the 
existing one would be needed.

Ah, it's not making up Smalltalk-like syntax! How do you think that it 
is? In fact adding curly braces to Squeak changed Smalltalk and could 
force all other versions of Smalltalk to adapt, which would be making up 
new syntax for Smalltalk and putting pressure on the other dialects to 
adopt it.

How is it a mistake to have Blocks do the job instead of curly braces?

It seems to me that the curly braces are a mistake since they are really 
a "macro" capability but limited to a single form of macro, the creation 
of an array for easy initialization! Why not have additional macro 
capability - a generic macro capability? Why not let blocks do the job?

Now, I know that you and others will raise the specter that you can't 
implement this notion with blocks since given your ideas of how to 
implement it it wouldn't be efficient and would mangle the virtual 
machine. Well, I've heard this and maybe it's time to mangle the virtual 
machine for Smalltalk up a bit! Time for some innovation! Nothing like 
stirring the pot to get it either.

Ok, "common mistakes" and "common sign that your love for a language has 
been corrupted into religion". I have no idea what you are going on 
about here, but it's bordering on an ad hominem personal attack. If 
that's not it's intent please explain it in less incendiary terms. Yes, 
I do have affinity for Smalltalk, and yet I find myself designing and 
implementing a language inspired by it; so while I might casually say 
that I love Smalltalk I also say that it needs improvement and it needs 
to catch up with some features in icky languages such as, ick, 
JavaScript; and it needs to be shaped to support the kind of 
applications that I want to build with it. No other language that I know 
of, and I've looked at a huge number of computer languages, can do the 
job so I'm taking Smalltalk further than it's ever been taken before.


>>    "More flexible version that lets you collect the evaluated results
>>    into an arbitary collection of your own choosing."
>>    [a. b. c] addObjectsTo: aCollection.
>
> If you want, you can modify the compiler so that
>
>    aCollection addAll: {a. b. c}
>
> becomes
>
>    aCollection add: a; add: b; add: c.
>
>>    "Wow, even into a stream."
>>    [
>>        1 to: 1000 do: [:count | count random ]
>>    ] streamObjectsInto: aStreamOfRandomIntegers
>
> ???  Before proposing something, please ensure that it is implementable.
What? Why?

Besides, your statement is just silly for a number of reasons. First off 
it's just silly to ensure that. Secondly what makes you think that it's 
not implementable? Just because you can't see it? Come on, get creative. 
Finally, please don't place limits or restrictions upon me, thank you.
>
> This would add just "1" to the stream if it parallels to
>
>      aStreamOfRandomIntegers nextPutAll: {
>          1 to: 1000 do: [:count | count random ] }
>
> I prefer to add a tiny bit of complexity to the parser, than to add 
> compiler special cases that get out of control much more easily than 
> new syntax.
>
> In GNU Smalltalk, there are two common use cases for {...} that are 
> not easily replaceable:
>
>     aStream nextPutAll: ('%1 (%2)' % { self name. self age })
>
>     Dictionary from: { 'Sun'->'Sunday'. 'Mon'->'Monday' "etc" }
These could easily be done with the Block version that I've explained. 
See the other recent posting by me on this for details on the new 
statement collecting evaluator for Smalltalk.

These two example show how clean this is in Smalltalk using existing 
syntax and the new evaluator for blocks.

    aStream nextPutAll: ('%1 (%2)' % [ self name. self age ] values )

    Dictionary from: [ 'Sun'->'Sunday'. 'Mon'->'Monday' "etc" ] values


The future can be created in steps or in giant leaps. The notion of 
adding a new evaluator to Smalltalk that collects the results of 
statements is but one of many new things that can be done with blocks. 
Reusing exisitng syntax in a way that integrates into the message 
passing and object paradigms of Smalltalk just makes sense to me as it 
keeps the syntax as pure and clean as possible. It keeps the language to 
the original spirit of message passing and elegance, simplicity and 
beauty. As soon as you sacrifice the language design to implementation 
issues by adding icky special purpose syntax for each new capability or 
feature you've already taken the road to "perlification".

The choice isn't always easy to make. Beauty and elegance are very 
important. The insights into the unique unary, binary and keyword 
message sending syntax was an impressive leap forward in the creation of 
Smalltalk. Let's not pollute it for the sake of making life easy for 
compiler writers and virtual machine implementors.

All the best,

Peter William Lount
peter at smalltalk.org



More information about the Squeak-dev mailing list