There are many reasons to fall in love with the keyword message syntax and dynamic type system of Smalltalk.
One reason is that (depending on appropriate names) you easily understand the intention of a method. If not you can easily find out by browsing the code.
In the non-Smalltalk land you have to spend your time reading api descriptions. And you will find horrible examples like this. Just scroll up and see how many ways there are to set an attribute ;)
Smalltalk does lend itself nicely to "descriptive coding", but it can also be done almost as well in other languages like Java by using good function and method names.
ReplyDeleteThe example you give for the drawbacks of static typing is not necessarily ugly; each of the setContext methods might have a different behaviour depending on the type of its method parameters. It could always just have taken Object as a parameter. What does suck in Java is that primitive types such as int, bool and so forth aren't subclasses of Object.
Also, reading API descriptions doesn't suck any less than having a second browser open for looking up class protocols.
Amen brother.
ReplyDeleteA well learned skill for Smalltalk developers is knowing how to browse, seeking senders, implementers and even test cases to see and understand how an object works.
Smalltalk teaches us to think of the code as something living and dynamic. I often use the metaphor of asking an object questions to understand what it does.
Hi Michael,
ReplyDelete>static typing is not necessarily ugly
Agree that it's not necessarily ugly and beauty is in the eye of the beholder. But there are two reasons this can be seen as ugly code. One is the drawback of static typing (method with the same name for each type) and the other is that there are additional methods - one for an option and one for another boolean option. Maybe only one parameter with an extensible configuration object could have helped here ;)
I've seen ugly code in Java, C#, C/C++, ... and even Smalltalk. But guess where I've found more examples.
API descriptions are good - but an intention revealing name in addition is definitely a timesaver! Do you think you will always remember the full API description and differences between all these methods when you hunt for bugs and step over such a method in the debugger later ...