Why Squeak is not the answer
For some time now I've been busy with Squeak. It's nice to get a chance to work with Smalltalk which is one of the most consistent languages I've ever seen. This probably doesn't mean much - I haven't seen that many languages yet. Of course consistency comes with a price but I can appreciate the idea. And yes, I think "Everything is an object" and Garbage Collection are great concepts. The fomer allows for amazing introspection features out-of-the-box. And everyone that is still complaining about the latter should take a deep breath and read this paper about the G1 GC that will be "the long-term replacement for HotSpot's low-latency Concurrent Mark-Sweep GC". Memory management can't get much faster than that.
But Squeak isn't Java. Nor is it using the JVM as other projects do. This is partially because Squeak is dynamically typed and the JVM does not work for such environments (yet). What it means though is that you get a VM which vastly lags behind the current development. Also, dynamic typing is really not what I want, for a couple of reasons. Sure, I want local auto variables that take whatever type is necessary given their first assignment (and keep that type), but that's type inference! On the other hand, I don't what method parameters that can be everything. How are you supposed to write robust code unless you start to check every parameter for its type during run-time? And even if you do (ignoring the performance penalty), wouldn't that be a very strong hint that dynamic typing doesn't work well for method parameters?
In Squeak for example you have this "self changed: aParameter" method for every Object, which is called to indicate that your object has changed. What it does is to inform a list of observers (dependents in Smalltalk MVC speak), supplying aParameter to them. Now, everybody thinks differently about what aParameter should be. A symbol (think string literal)? A reference to self? Perhaps a code block (for the lack of callbacks)? There is simply no right or wrong here, the interface doesn't tell you! And so it happens that you find the changed-method (ab-)used in every possible way, destroying quite a bit of the MVC pattern's flexibility since you have to guess which kind of changed information you might get from any given model.
The way I see it, Squeak is "just" a class library around a "reflexive" Smalltalk80 implementation. And what is - right after the API design itself - the most important part of a class library? I am sure Squeakers won't be able to come up with the correct answer themselves so I help a bit: API documentation and example code.
With Squeak, you often only have "example" code (since "The Code is the Documentation."), or rather, class library code with the quality of example code, if you catch my drift. Seriously, forget it, I won't keep reading library code that lacks comments or any kind of explainations. Am I supposed to guess from the awesome code itself what parameter types are allowed? Or what to expect as the result? Even better, error handling? Well, the answer to the last one is easy. There is no error handling. At some point during the code execution the debugger will tell me that we tripped over the Squeak equivalent of a nullpointer exception. And this is library code!
OK, enough of this rambling - for now! I even left out the obvious things like missing SCM integration (no, Monticello is a joke) or this image-based development crazyness (guess why everyone keeps a clean image as backup?).
My next post will cover some gruesome examples (also code) which are likely to make you squeak.
Comments
No comments yet.
Post a Comment
This site's webmaster failed misserably in upgrading the underlaying web framework.
The comment system is entirely broken right now. Sorry!
