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)
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.
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.
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".
On Tue, 31 May 2011 21:01:24 +0200, Igor Stasenko siguctua@gmail.com wrote:
2011/5/31 Kamil Tomsik info@tomsik.cz:
It's not anti-smalltalk post, it's just a list of smells. (not big ones)
ehm.. you saying:
- 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.