Interesting Article on Smalltalk by David Chisnall

I just stumbled upon an article that interested Smalltalkers may have known for weeks already. It’s part 3 of a series called Influential Programming Languages and has been published on InformIT back in January 2011. It discusses which programming languages influenced the makers of Objective-C and what concepts were taken from them.

The articles focus on Algol, Simula, Smalltalk and Lisp, and interestingly ignore C and C++ completely, although I’d say you still feel the foul smell of C in Objective-C way too often.

Maybe David wanted to focus on visionary things and concepts that were borrowed from other languages and he regards C as an implementation detail of Objective-C, which is a valid point of view. A painful one sometimes (I personally am not a big fan of pointers and zero-based lists), but one that has been put lots of nice paint over

There are some nice quotes in it, but the article is (as is the whole series) definitely worth reading in hole:

Smalltalk [...] was created on a bet. In this case, the bet was whether it was possible to specify a complete programming language on a single piece of paper.
Smalltalk’s development system had a lot of features in 1980 that are only just starting to make their way into mainstream integrated development environments. Automatic refactoring tools are a good example. Amusingly, you’ll often hear people defending strongly typed languages by saying that these tools require type annotations—ignoring the fact that Smalltalk had them 30 years ago.

Although Smalltalk is rarely used today, one of its descendants is popular: Objective-C was created as a hybrid language, combining C and Smalltalk. If you want to write good Objective-C code, it’s worth your time to learn both languages.

I agree on this one. It never hurts to learn Smalltalk, not only if you want to work in Objective-C.

If you want to take this advice and really have a look, there are quite a few options to start with. It’ll be best to visit world.st and find out which environments are available and where to get them.

But be warned: Andy Bower from Object Arts, maker of Dolphin Smalltalk once said:

Smalltalk is dangerous. It is a drug. My advice to you would be don’t try it; it could ruin your life. Once you take the time to learn it (to REALLY learn it) you will see that there is nothing out there (yet) to touch it. Of course, like all drugs, how dangerous it is depends on your character. It may be that once you’ve got to this stage you’ll find it difficult (if not impossible) to “go back” to other languages and, if you are forced to, you might become an embittered character constantly muttering ascerbic comments under your breath. Who knows, you may even have to quit the software industry altogether because nothing else lives up to your new expectations

Should young programmers start in the green or in the brown field?

Many people view software maintenance as tedious, boring and ultimate penalty rather than a challenging and interesting job. And in fact, maintaining an old body of code can be painful and depressing. There’s so much to make you bang your head against the wall: bad programming style, wrong design decisions, stupid bugs and lots of areas where you simply don’t understand what for or why the heck somebody wrote such terribly bad code.

On the other hand, changing existing code, improving it, adding functionality to a running system can be fun and very satisfying. And there’s even some chance that there are hidden gems in old code. Something you can learn from people with lots of experience and good coding habits. It’s a challenging job to try and find out why certain deicisions were made as they are, and very often you’ll find out there once were good reasons for why something was done in quite some complicated fashion rather than in an obvious way.

So constantly being on an edge between breaking code and improving an existing system can be seen as dangerous and rewarding at the same time.

Being a young programmer, stuffed with only fresh ideas and little useful advice on how to write real software, it is surely a good thing to be put into a team with experienced developers. There’s so much to learn nobody ever told you and maybe nobody ever will.

So I think a new programmer should start maintaining a running system. They had a lot of time doing fresh development already during their education, and now it’s time to learn the rough edges. They should be given the chance to break an existing system. More than once. Because that is how you really learn to really be careful and not to judge existing code too fast.

Having to read and change crappy code does two things: it shows you how important it is not to write crappy code, and you’re forced to respect code. This body of code may have done it’s job for years, no matter how badly written it is. So it’s worth trying to be understood.

If you don’t handle it with respect, it will take its revenge: it’ll break and give you a hard time solving trouble tickets.

Putting new programmers into a think tank (where they presumably cannot break much) is no good for anybody. They won’t learn to understand the code in your organization, and they’ll write code that will be hard to understand for you. They won’t learn much and chances are they’ll simply write a system that’s completely out of spec. And they’ll have to learn things the hard way anyways, just later, when it’s probably even more risk to your project.

So I think young developers should start in a maintenance project rather than some fancy new strategic project.

We should resist the promise of “The young guys all can do Java a lot better than we can, so they should do the fancy new Java project while we maintain the really important core systems”.

Funny enough, chances are that if you bring the young into maintenance projects, the old guys will learn a lot from the young about newer concepts and tools that could make their jobs easier, and the young will learn a lot about how software is written in your organization. They’ll soon understand that you’ll have to accept bad code and weird decisions as long as they don’t fully understand the consequences of changing them.