So I’ve been playing with Smalltalk, specifically Squeak, for a while now, and I’ve been trying to come up with a project. I’ve decided ultimately to build a simple Paint-by-Number game (example), just to see how it works out. I’m going to use TDD and continuous refactoring, after the fashion of this excellent tutorial, and I’m going to build off of Damien Cassou’s squeak-dev image.
This should be interesting. Before encountering (Smalltalk-inspired) Objective-C a few years ago and then (also Smalltalk-inspired) Ruby, my primary experience with OOP had been C++ and Java – both of which had left a rather sour taste in my mouth. Sure, I could see a few advantages, but they didn’t seem worth it – and now I realize why. Most development in those languages is really OINO – OOP In Name Only. People actually program procedurally, and create just as much (sometimes more!) spaghetti code as in traditional procedural languages!
One thing about Smalltalk that I think encourages “true” OOP development is the way that the development environment works. In C++ and Java, the file and class are the units of account – but in Smalltalk, all you see is one method at a time. I think this is an important observation; it actually encourages the developer to think more granularly, developing smaller and more targeted methods. Methods are visually separated from the class definition from each other – even instance and class methods are completely visually separated. My hypothesis is that this has a valuable psychological impact on design.
Interestingly, though, Ruby and Python developers still seem to do this. Perhaps not with the tenacity that Smalltalk programmers seem to, but I don’t seem to find ridiculously long procedures-masquerading-as-methods in their applications as often. Maybe it’s because of the nature of the communities, or maybe I just don’t have a large enough sampling of code. In any case, it’s an observation.
So, we’ll see how I do with this little project. I don’t imagine it should be too terribly difficult – the problem seems easily solved, at least from a distance. But now my first decision – how do I store puzzles?
This may not be as trivial as it sounds. The old-style Perl programmer in me wants to store it as a packed string. The C programmer wants a multi-dimensional array. The Lisper wants perhaps an array, perhaps a list of lists. But what’s the Smalltalk Way? A multi-dimensional array of “Cell” objects?