As an example, a: b does not have a receiver.
Well, I don't consider this as a problem. In Java and C++, in a send to "this" (aka self) "this" can be omited and nobody has trouble here. Okay, both languages have a larger set of syntactic rules which contain enough redundacy to help people to understand the statement (and it also looks like a familiar function now :-) but even for Smalltalk I don't consider this as a problem.
The problem IMHO is that now "self a: b" and "a: b" doesn't mean the same. While the first expression always accesses an instvar of the self object, the second expression will assign a temporary called "a" if one exists.
SELF has exactly the same problem. The authors simly say that explicit self sends are considered as bad style and should be omitted - if possible. So you basically exchanged the ":=" to
I consider the simple syntax one of the great things about Smalltalk both for learning and for code readability.
If might sound funny for Smalltalkers, but it is my experience from teaching Smalltalk and Java that people don't consider Smalltalk as an easy to learn language but because it looks more alien, difficult to understand. Java or especially Python are easier to learn for most people.
Another problem with Smalltalk is also, that its implementation must be understood before you can understand Smalltalk code because even the simplest conditional statements explicitly show the way they're implemented.
If anything were to be done with variables, I would suggest making them first-class objects. As they are, they are different from everything else and break the uniformity of the language. Assignments could then be handled for example as
var assign: x
Then use
#var <= x
which could be implemented (I think) without great difficulties, for example...
Symbol >> <= anObject | r | r := thisContext sender receiver. r instVarAt: (r class allInstVarNames indexOf: self asString) put: anObject
How if you use something like
thisContext locals: 'temp1 temp2'
instead of
| temp1 temp2 |
at the beginning of methods, you could even setup and access local variables with a minimal change to the above code :-)
bye -- Stefan Matthias Aust // Bevor wir fallen, fallen wir lieber auf.