[squeak-dev] smalltalk evolution

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Tue May 31 21:25:00 UTC 2011


2011/5/31 info at tomsik.cz <info at tomsik.cz>:
> In short:
>
> 1.) binary messages make sense only for math. I've never implemented even
> one binary message, have you? (for non-math things)
>
> Why not step further and make dsl for equations? let them live outside of
> language.
> (with everything common to math world)
>

Example : / for building file path

> 2.) keyword messages with more than 2 arguments are just ugly - they smell
> in the "missing another object" way. And 2 arguments are rare too. I would
> allow one argument at top.
>

They are rare anyway...
In my experience, the 16 arguments limit, though well founded from
Object POV, is limiting interoperability with 3rd party library
(LAPACK) and that's just boring.
My opinion is that educating is better than just forbiding.
We can tolerate exceptions. Anyway, the workarounds we'll build might
well be much uglier...

dic := Dictionary new.
SystemNavigation default allBehaviorsDo:  [:e |
	e selectorsDo: [:s | (dic at: s numArgs ifAbsentPut: [Set new]) add: s]].
dic collect: [:e | e size]
->
a Dictionary(0->18320 1->10083 2->3560 3->1331 4->556 5->201 6->88
7->47 8->24 9->4 10->7 11->1 12->3 13->3 14->1 15->1 )


> 3.) unary messages - I would drop them too, and the reason is - I don't
> write a lot of "return" code, I give orders, I want actions from my objects.
> I don't want another objects on which I can operate (or get another ones,
> and again and again). But another syntax sugar for passing "yourself" would
> be needed :-/.
>
> 4.) all of this could result in consistent syntax like:
> receiver doSomething: yourself.
> receiver doSomething: param.
>

I'm not convinced it would ease readability.
OK, imperative shall be the preferred mode, tell don't ask, but
eliminating queries altogether is a bit totalitarian to my taste.
I invite you to rewrite a utility library, say Graphics, with this
style and come back with the result if you are pleased with it.

> this simplification also allows like-english cascade:
> receiver doSomething: param, doSomethingElse: anotherParam.
>
> or multiple receivers (like F-Script):
> receiver, anotherReceiver, anotherReceiver doSomething: yourself,
> doSomethingElse: param.
>
> This is not proposal, just my current "state-of-thinking".
>

Designing a language is a very interesting topic. But a very involved one too.
I'd say try it, eat your own dog food and share a posteriori opinions,
it will be much more fruitfull.

Nicolas

> On Tue, 31 May 2011 21:01:24 +0200, Igor Stasenko <siguctua at gmail.com>
> wrote:
>
>> 2011/5/31 Kamil Tomsik <info at tomsik.cz>:
>>>
>>> It's not anti-smalltalk post,
>>> it's just a list of smells. (not big ones)
>>>
>> ehm.. you saying:
>> 1. different message types with different precedence -> distraction,
>> parentheses
>>
>> now, just for comparison, count the number of precedence rules in
>> another procedural languages.
>> in smalltalk there are only 4: unary, binary, keywords, cascade.
>>
>> I can imagine that we can easily get rid of binary messages.. and
>> replace them with keywords, so
>> instead of writing:
>> a + b.
>> one must write:
>> a add: b.
>>
>> but that will lead to much larger number of parens everywhere.
>> Keyword syntax should stay. It is most superior form of expression
>> known by myself, because if message selector is picked carefully,
>> then it tells, what arguments are expected for each keyword, unlike to
>> C where function could have 5-10 arguments
>> and you have to refer to its source code in order to write down the
>> correct arguments to make a function call.
>>
>>> Smalltalk is great language.
>>>
>>
>> What makes a smalltalk great is not just language, but also
>> environment. If you look at it purely from syntax point of view, then
>> i'm
>> afraid, you don't see a whole image.
>> Because without dev tools, it will be not much better than PHP, Ruby
>> or Javascript, where you on your own with source code, and have to
>> manually navigate through code.
>
>



More information about the Squeak-dev mailing list