2011/5/31 info@tomsik.cz info@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@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.