On Smalltalk

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

Smalltalk is generally considered to be an object oriented language but it’s actually a mixture of object oriented and functional techniques that made it so great. It’s the functional stuff, closures, anonymous functions, and higher order functions that make Smalltalk code so terse and easy to read. The objects provide the overall structure, but the functional stuff glues them all together and makes Smalltalk what it is.

I was considering writing more about it but a quick Google search turned up this great reference Smalltalk for Lispers from the Smalltalk/X Programmers Guide that gives an excellent introduction from a more functional point of view.

If you mix object oriented programming, manifest types, and procedural programming, you get Java or C#, not exactly a fun or flexible combination of language features. Mix object oriented programming, dynamic types, and light functional programming and you get Smalltalk and Ruby, much more fun and much more flexible and productive.

People often seem to forget “object” is meant as an abstract term that means “thing”. Object oriented programming is about programming with “things”. In that sense, functions are objects too. Not all objects need be created with named classes, and all too often people who complain about OO are really complaining about their misguided view of OO and the often made newbie mistake of trying to model everything with a class. It’s not called class oriented programming, it’s called object oriented programming. Maybe approaching Smalltalk from a more functional point of view will shed some light on more interesting ways to solve problems.

Tags: General, Lisp, Programming, Ruby, Smalltalk

As always, I enjoy reading what someone thinks of Smalltalk after a proper demonstration. I find Edwards thoughts on Smalltalk typical of that aha you get when you really see what Smalltalk’ers can do.

Edward was lucky, he had a Smalltalker handy to show him the ropes, few have that opportunity. I’m still amazed by how many people think they can grok Smalltalk by seeing syntax examples. Smalltalk isn’t its syntax, it’s its environment. Smalltalk is a living world of running objects, there are no files, no applications, just what’s running. To understand Smalltalk, you have to either actually use it for a while, or have a seasoned Smalltalker demonstrate it to you. Reading sample code just won’t cut it.

For better or for worse, Smalltalk is a world unto itself. It’s much more an operating system than a programming language. When Steve Jobs stole the idea for a windowing system and mouse from Xerox (not that they invented it), it was Smalltalk he was seeing. Even he readily admits he was so dazzled by the GUI he didn’t even notice Smalltalk, or the fact it was all networked with email, things we take for granted now but didn’t exist widely back then.

Sure, we package code and use source control, but our methods aren’t file based. Our source control systems are language aware, they can diff and merge code at the method level, auto merge and allow you to select, method by method, which version you want to keep. Smalltalk is different, top to bottom, it’s just different. Everything is live, code changes are live, applications don’t start, they’re simply always running. Object oriented programming means something entirely different to a Smalltalker than to someone doing OO in another language.

Ruby comes very close to Smalltalk. It’s a nice introduction to many if not most of Smalltalk’s ideas. It’s very pragmatic, fits in with the world around it, it’s based on files, works with your favorite text editor, etc. etc. But Ruby still isn’t Smalltalk. I use Ruby, I like Ruby, but Smalltalk is more productive when I’m working in unknown territory. Smalltalk is better for prototyping ideas quickly. A read eval print loop and hyper-linked documentation just doesn’t compare to a real Smalltalk workspace and a real Smalltalk browser where the code itself is hyper-linked and navigable and objects are things you can actually pick up and shake.

Smalltalk doesn’t have to be pragmatic, because it’s better than its imitators and the things that make it different are also the things that give it an advantage. Its syntax isn’t weird, C’s is. Weird isn’t even the right word, because what’s weird is totally relative and very dependent on your background experience. Smalltalk’s syntax is simply better.

Window window = new Window(0, 0, 800, 600);

Simply isn’t as expressive as…

window := Window top: 0 left: 0 width: 800 height: 600.

And this is a trivial example, the more complicated the code gets, the more of an advantage Smalltalk has. Ruby chose to go with a C’ish syntax, but by convention, mostly tries to fake the Smalltalk style anyway because it’s simply better.

window = Window.new :top => 0, :left => 0, :width => 800, :height => 600

So, if you still haven’t tried Smalltalk, and I mean really tried it, by writing an application in it, give it a go. You’ll never regret it, because everything you learn, and you’ll learn a lot, you’ll be able to bring back with you to whatever language you call home. Smalltalk will change the way you think, no matter what language you’re coming from. Whether it changes it for better or for worse is of course entirely up to you. If you’re afraid to try Smalltalk, then at least try Smalltalk Lite… uh, I mean, Ruby, you’ll enjoy it and still be able to use your existing tools. You can work your way up to the real thing.

PS: Lisp and Haskell are two other equally mind bending languages that I think everyone should learn, however, neither of them can touch Smalltalk’s development environment. That being said, learn them anyway.

Featured Resources…

Just like Smalltalk stands different than the rest, there is a wide range of cheap web hosting companies offering their best hosting packages. You will be able to register domain very quickly with some of these. If you have many domains, you can still avail this facility. For small business owners, the hosting companies like startlogic are coming up with the best solutions for their needs.

Tags: Lisp, Programming, Ruby, Smalltalk

I’m a Windows guy, I’ve always been a Windows guy. Windows today is more stable than ever. Seems now would be the best time of all to be a Windows guy. Slowly but surely though, I’m becoming a Linux guy.

Truth is, I was always a Microsoft guy, and that simply included Windows along with all of their development products. I used to be a hardware/network technician. I’d setup and maintain networks for medium to small businesses. Windows was always the way to go here, it’s what the users were accustomed to and expected. I’d usually setup a Windows NT server and from a dozen to maybe 30 client computers running various version of Windows including NT workstation. So Windows was just something I was always familiar with.

Even back then, I had the occasional urge to try other things. One of my first experiences with Linux involved using it as a firewall for a windows network on some cheap throwaway hardware that wasn’t good for much else. But it always seemed a pain to use, and I didn’t really understand it, despite having it working quite well for what I intended. I just didn’t see the point of not having a nice GUI and using cryptic commands to do everything.

Later, I learned to program in VBScript and VB using ASP and SQL. I became a web developer and abandoned the hardware gig. Software was so much more interesting. ASP became ASP.net, and VB became C# when I realized how crappy a language VB actually was. What made me want to change was my discovery of the original Wiki. I found a place where real programmers hung out and discussed anything and everything. I realized the world was bigger than VB. VB.Net fixed many of the issues with VB and is pretty much equivalent to C# in all but one area… culture.

What I really was abandoning was the VB culture. I’d outgrown it, I wanted to be involved in a culture that cared more about programming well. The VB culture is dominated by amateur programmers that are just happy to get something working, they tend to care very little about things like architecture, or patterns, or the aesthetics of good code. They don’t think of themselves as amateurs, many of them consider themselves experts, but start talking about object oriented programming or functional programming and the confused looks on their faces tells you they’ve not really looked into such things very deeply. Many think simply using classes makes code object oriented.

I was still firmly in the Microsoft camp at this point, though my change to C# had opened my eyes to Java, and more importantly object oriented programming. It was the Wiki that introduced me to Smalltalk. I just couldn’t help but notice how much Smalltalk was referenced whenever object oriented programming was discussed, nor how many famous authors credentials included a Smalltalk background. I decided I had to check out this Smalltalk thing. Now, at the same time, I was checking out the Lisp thing as well, but that’s not relevant to this story.

So I’m a web developer, my seeking tends to be guided by the need to make my job easier, to find better ways to automate myself. Obviously, I discovered Seaside. Seaside got me into a non Microsoft language. Around the same time, a buddy of mine who I’d met on the Wiki suggested cygwin. I’d been talking about wanting to learn a little more about Linux and he said I could do so without leaving Windows by using a better shell. Cygwin was the beginning of the end for Windows.

I started finding reasons to grep, cat, sed, sort, uniq. This was pretty cool, I was still in Windows but had a Linux command line and the shell became a bigger part of my toolbox. Now I find myself using a non Microsoft programming language, and having discovered PostgreSQL, a non Microsoft database. And now bash for my shell. Hmm…

So now I’m still hosting my apps on Windows servers, but I keep having problems crop up. I recently did a write up on Scaling Seaside which included a bash script for making sure the Seaside services were always up and running. Problem is, turns out the only thing making my Seaside services seem to die, was the bash script itself. Somehow lynx gums up Windows after a certain period of time and Windows starts having random network errors. I’ve taken the script down and now have another one running that uses wget and simply notifies me should any site I’m monitoring go down, or come back up.

So I find myself using all open source non Microsoft tools for everything except for the server’s operating system. Having become quite comfortable on the command line, it finally hit me, stop screwing with all these problems on Windows and try Linux again. Setting up new Seaside services on Windows is a multi step pain in the but. I’d thought I’d give a Linux a try and see how far it’s come since the last time I tried it. Boy was I surprised. In the next post I’ll detail my experience setting up a Linux server for hosting Seaside.

Tags: Linux, Lisp, Programming, Seaside, Smalltalk, Sql