Some of the comments in a the Barrier To Entry post bring up the point that maybe the Smalltalk IDE itself is one of those barriers.
It’s an interesting thing, the Smalltalk browser. Unlike most IDEs, it’s optimized for reading code rather than writing code. Other IDEs allow you to see any number of methods all at once, cutting and pasting text giant chunks at a time, they sure make you feel like you’re working. They don’t however, allow you to navigate the semantic structure of the code very well nor do they encourage the writing of well organized code.
Modern IDEs are getting better at this, but they’re doing it by copying Smalltalk. Smalltalk’s various code browsers (hierarchy, method, inheritance, senders, implementors, protocol, category, package, refactoring) let you explore the structure and relationships between existing code and its tools (transcript, workspace, method finder, message names) make finding and using existing code, or understanding existing APIs vastly easier than any other language I know of. Seeing the structure of code is always but a context menu or hotkey away.
Smalltalk’s browser is rather opinionated, luckily, thanks to Rails, opinionated software seems to be having somewhat of a revival. When it comes to writing code, the browser forces you into a certain mindset, one that other languages don’t force you into. When I create a method in Java/C#/Ruby, I have to choose little more than what file and class it belongs in. I *can* organize the code well, but there’s little incentive to do so and my unit of work is rather undefined, I could be slicing and dicing methods, classes, namespaces, etc., usually with the full screen devoted to code across various files or even god forbid in one giant file. This encourages a code now and organize later approach. Sadly, later often never comes, and the code is left functional but messy.
Smalltalk on the other hand, defines my unit of work as *the method* and by doing so forces me at every turn, to continually organize my code in semantically meaningful ways. When I create a method, I have to choose a class category, a class, and a method category to put the method in. If I don’t, Smalltalk kindly categorizes the method for me in a protocol called “as yet unclassified”. It’s almost an insult, but it’s also a not so subtle reminder than I’m writing code sloppily, faster than I’m thinking. It reminds me to slow down, think for a second, where does this thing belong.
It only takes a second to pick a meaningful category name, and these names are idiomatic, I see them all the time when I’m looking for code. Aha, we’ve linked writing code to reading code. By taking the time to properly categorize my methods I also learn where to look for code later, when I’m in reading mode. It’s a feedback loop, the more I read the better I write and the better I write the more I learn to read with accuracy, looking only where necessary. It’s as if the code itself *is* a concise form of documentation hyperlinked by semantic meaning using things that Smalltalkers call browsers. Browsers and hyperlinks, bah, that’ll never work!
And RDoc, what the fuck is that, looks curiously like a Smalltalk browser to me, but why should class comments be anywhere except on the class itself? Oh that’s right, Ruby doesn’t have a Smalltalk browser, they code in files, how quaint.
As for editing the method itself, I work on and view only one method at a time, and only the lower half of the browser is for editing code which punishes me if I write long methods that can’t fit into that tiny pane. Smalltalk at every turn encourages me to read more code than I write, reuse more code than I otherwise might, and write smaller simpler methods than I likely would in a text editor.
Writing smaller methods forces me to give them meaningful names. Giving them meaningful names and putting them in meaningful places makes the code easier to read and easier to find. Code that is easier to read and easier to find, is easier to reuse, easier to understand, and easier to compose into new solutions. It’s called bottom up programming, the foundation of which is small composeable methods.
I keep using the word small, maybe that’s a mistake on my part, what I really mean is concise. Methods with a single purpose that is clearly summed up by their name. These kinds of methods happen to be short in general, but that’s a side effect of their being focused on a single task. The Smalltalk browser encourages these kinds of methods by making writing long methods or paying attention to too many methods painful. Text editors are general purpose editor aimed at text, that could be anything from a blog post to a novel. Surely an editor intended only for code, and only for a particular style of code, can be made much more *domain specific*.
The Smalltalk browser is such an editor, its domain is highly factored heavily structured bottom up style object oriented code. If that’s the style of code you like to write, you’ll find the Smalltalk browser wonderful, if not, you’ll find it painfully opinionated and rude.
Take a peek at decompiled .Net framework sources, or Ruby sources and what you’ll find, are average line per method counts in the 50+ to even 100+ ranges. In Smalltalk, around 10 or so. To me, this is a clear indication that text editors are the wrong interface for writing clean simple well factored reusable code. Sure, I just pulled these numbers out of my ass, but they reflect my experiences and even then, I’m being polite, 1000 line methods are not at all uncommon in .Net.
Maybe adjusting to the Smalltalk browser is similar to adjusting to Lisp’s parenthesis. It’s something you desperately want to fix as a newbie and make it work like other languages. In Lisp’s case, trying to design an infix Lisp while in Smalltalk it’s a text and file based editor. In both cases, once you stop fighting the language and realize the difference is actually a great strength of the language rather than something that needs fixed. You realize it’s you that needs to change, you open your mind, accept that sometimes different is good, and take advantage of the new power these tools give you.
Experienced Lispers love their parenthesis and experienced Smalltalkers love their browsers. Rather than seeing the Smalltalk browser as a barrier, maybe, just maybe, you’d be better off seeing it as a new toy to play with. Something new to learn.
UPDATE: Here’s a few admitidly cramped screenshots of the various browsers. They do of course look much better maximized on your monitor.
Tags: General, Lisp, Programming, Ruby, Seaside, Smalltalk
Related posts
at: "
05 Dec 2006 > Squeak Image Updated";
at: "
A Squeak Smalltalk Development Example";
at: "
Popular Posts";
