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
|