Six Word Stories about Programming Languages

Lest you miss it, Indefinite Articles (an interesting blog, specially if you like Ruby) has posted a collection of Six Word Stories about Programming Languages. Reminded me of these programming haikus. Funny and, as is often the case with really good humour, insightful. I also had a good laugh with this Agile Development’s Devil’s Dictionary. Yet another feed in my list.

A couple more exotic input methods

I’ve posted about novel ways to interact with our computers a couple of times before. I know this is a bit off-topic, but, to me at least, programming is also about transforming computers into something useful, and thinking about new ways to interact with them is an excellent way to pursue that goal. After all, all-time favorite languages of mine like Lisp or Smalltalk were born while people were struggling with making computers useful and/or accessible.

I’ve always loved the stories about how our current interaction paradigm was invented by Alan Kay and friends over at Xerox Parc, as recounted in books like Dealers of Lightning or the excellent Tools for Thought; or in papers like Alan Kay’s classic on the history of Smalltalk. The people exploring new ways to interact with computers look to me as the heirs of this tradition. I find also pretty interesting to try and imagine how on earth they’re implementing this new stuff, and would love to hear about the languages and environments they use.

Admittedly, the tricks i’m about to show you have, at first sight, no direct application to our work as programmers, but hey, you know what Hertz thought of his experiments on electromagnetic waves, don’t you?

Yeah, right, i’d better stop talking and show you the cool stuff. The first video (hat tip the Cynical-C Blog) makes true the dream of any physics teacher:

This beauty comes from MIT, but there are already commercial versions (including a free lite version) available from Pintar Media.

I found the second video i want to show you while reading about a ‘Minority Report’ interface created for US military (interesting on its own, by the way). It shows another ‘analogue’ input device called Blue Eye, a kind of universal photocopier (and part of the Visual Interaction Platform):

Blue Eye (WMV video)

OK. Probably more useful to designers than to programmers, but funny anyway, and perhaps a glimpse of the kind of devices we’ll be programming in the not so far future. A challenging prospect, don’t you think so?

Know your tools

Just to illustrate what i meant the other day when i exhorted you to pick a powerful enough editor, and, most importantly, learn how to use it, i think this Emacs Screencast is quite adequate. It’s made by a Ruby coder, but note that Emacs plays these kind of tricks (and many more) for virtually any language out there.

The point is, if your environment is not powerful enough to make this kind of things, you should be looking for something better. The keyword here is extensibility. If your environment is not able to automate a task, you should be able to extend it; and the best way i can imagine is having a full featured lisp at my disposal when i need to write an extension (here is the list of Emacs extensions used in the screencast, by the way). Phil Windley has also made a similar point recently, in his When you pick your tools, pick those that can build tools mini-article.

And of course, when your editor and your dynamic language conspire to provide an integrated environment, you’ve reached nirvana: that’s the case of Common Lisp and Slime, as shown in other widely known videos.

As said, the message is not that you should use Emacs, but that you should use the right tool. For instance, PLT Scheme users have other alternatives, like DrScheme, which can also be easily extended, as beautifully demonstrated by DivaScheme, an alternative set of key-bindings for DrScheme that you can see in action below:

You see, as programmers, we’re lucky: we can build our tools and make they work exactly the way we want. If your environment precludes your doing so in any way, something’s wrong with it, no matter how much eye-candy it uses to hide its deficiencies. (Yes, i have some examples in mind ;-) .)

Update: Phil has just posted an interesting follow-up to his tools article. His closing words nicely summarise what this post of mine is all about:

Note that I’m not writing all this to convert the dedicated vi users or anyone else. If you’ve got something that works for you, then good enough. But if you’re searching for a editor that’s programmable with plenty of headroom, then give emacs a try. There’s a steep learning curve, but the view is great from the top (or even half way up)!

Exactly!

Seven rants about successful programming, give or take two

A friend of mine has sent me this list with the Seven Secrets of Successful Programmers and asked for comments. Halfway my reply, it’s occurred to me that i might as well post them here and, hopefully, hear about your opinion too.

First of all, i’m wary of magic recipes and fast-food solutions. There’s no such thing as a quick recipe to become a proficient programmer. It takes effort, a lot of hard work. No secret list will spare you that; as we all know, there’s no silver bullet. Not that we can’t use a little help from more experienced programmers and hear their advice, but short rules of thumb are often problematic. Software is, well, soft, and it’s very difficult to come up with eternal truths to be carved in stone. I prefer the whole story, as recounted for instance in books like The Practice of Programming, or extended guides like Norvig and Pitman’s classic tutorial on Lisp style.

Don’t take me wrong. I don’t think there’s anything evil in trying to convey hard won lessons in little capsules. Otherwise, i wouldn’t be writing these musings in the first place. It’s just that i dislike oversimplifications; they go hand in hand with the notion that programming is just something to be done by underpaid coding monkeys, or that it should be as easy as clicking around with a mouse.

But let me turn back to the original purpose of this post, which was, oh yes, commenting on those seven recipes to success. Here’s my take on some of them.

  1. Code for human consumption. Dead on. I haven’t much more to add here. As almost a corollary, using an as higher as possible level language is a non-brainer. This secret is nicely expressed in SICP’s preface:
    Programs must be written for people to read, and only incidentally for machines to execute.

    But of course, really grasping what that means takes reading SICP, at least.

  2. Comment often and comment well. Sorry, but this one is completely misguided, at least in my book. I’m not refering to the comment well bit (which, as an aside, is as vacuous as you can get), but even here the secret’s author gives a bad example:
    Good comment: Disable button to prevent its activation
    Bad comment: Set cmd = False

    The bad comment is obviously bad, but the proposed solution is far from good. Code is to be read by programmers, not by nincompoops, and we all know that a disabled button cannot be activated. The problem in the above example is not a bad comment, but very bad variable naming: use isActive instead of cmd and comments are unnecessary. As they should be. Which brings me to the “comment often” part, which the author reinforces with this incredibly bad piece of advice: comment your code so that it can be understood just reading the comments. Beg your pardon? What happened with our rule number one? (and no, comments are not code).

    In my experience, the need to explain what a snippet of code is doing with a comment is a sure indication of bad coding. Good code is self-explanatory and needs few, if any, comments. Otherwise, you did something wrong, be it bad naming or poor function breakdown. Not to mention the issue of keeping comments and code synchronized during rewrites. So here’s my secret number 2: comment seldom, write self-documenting code instead. This will make your programs not only easier to understand and maintain, but of better quality.

    Of course, this does not imply, by any means, that documentation is not needed. Proper documentation of your public interfaces and modules, how they work together and their dependencies is a must (this being, by the way, one of the things i dislike about extreme programming and other agile methodologies). But it does not belong into your implementation’s comments.

    There’s a lot to say about how to properly document your code, and often the language you’re using influences the documenting style (for instance, via its abstraction constructions (modules, interfaces, protocols, categories, whatever)). Although i won’t discuss this issue further, i’d recommend reading this very interesting discussion over at comp.lang.smalltalk, which incidentally demonstrates how difficult is to come up with cure-all rules of thumb.

  3. Layout code to increase legibility. But of course. I am however quite surprised that anyone can list such an absolutely basic thing as a secret to success. If your programmers are not able to write properly laid out code… well, you’d better forget about success in the first place. An important consideration in this regard, though, is that your tools should make this task trivial.

    As in many other things, Emacs excels in this regard, making indentation and code layout a breeze. I won’t try to convince you of using Emacs, but if your only quibbles about it come from using and learning it for less than a month, please consider giving it a serious try. These comments may help you realize what’s in store for you; and, if you love programming, chances are you’ll appreciate the beauty and power of its design. The learning curve is steep, but again, you know what i think of those looking for easy solutions ;-)

    Whatever your final decision (there’s nothing wrong in using VIM if you like it better), please learn to use your editor and exploit all it has to offer. It’s your basic tool and it should be customizable and extensible enough to exactly match your needs and make your life easy. Don’t write Lisp using Notepad.

  4. Expect the unexpected and deal with it. Absolutely. I don’t have any quibble here. Error handling may well be the most difficult task we face during program construction. Elegant code for the nominal case is, in comparison, a piece of cake. When you introduce error handling code, things get messy with extraordinary ease. During all these years, i’ve had a very hard time writing error handling code that looked elegant, not to mention beautiful. Actually, i think i’ve yet to find the right way to tackle exceptional situations. Non-resumable exception systems a la Java/C++ often have caused me more problems that simpler mechanisms (like return values and design by contract with assertions), probably due to their non-local nature. Much more usable are Common Lisp’s condition system and Smalltalk exceptions. Taking a look at them, even if you’re not using those languages, is a healthy exercise that may change the way you think about error handling.

    I won’t venture any further advice (for now) on this thorny issue, except for one recommendation: plan your error handling strategy in advance, for it is not something that can be added easily to your program as an afterthought.

  5. Name your variables to aid readability. Sure, and we’ve already seen how important this is for self-documenting your code. But i thought it was clear by now that Hungarian notation is evil. If you want good type checking, use a decent statically typed language like Haskell; with dynamically typed languages, well, using prefixes to mark the type of an identifier is non-sense. Even in languages like C or C++ there’s much to say against this notation, if only for the fact that it defeats the much more important goal of readability. Josh Fryman summarized long ago my feelings on Hungarian notation in his nice article on coding standards, by stating his
    Theorem One:
    Hungarian Notation exists to make up for bad coding practices.

    At any rate, the secrets author is very right to stress the importance of consistency and uniform conventions. In this regard, i’ve also found useful the practice of adding a bit of metadata to a variable name’s to indicate its scope (static vars in C/C++, members in C++, Java or Objective-C, special variables in Common Lisp…). In an ideal world, my programming environment would be aware of this kind of metadata and automatically provide some kind of visual clue, but we’re not there yet.

The last two secrets are an exhortation to use short functions (that do just one thing, and do it well) and lexical scope. Very good advice, without further qualification. I’ve found that functional languages, specially those in the Lisp family, and, more generally, having closures at your disposal naturally reinforce these desirable qualities of the software i write.

Summing up, my feeling is that, important as the above issues are, they only scratch the surface. If i had to give you a single rule in your path to become a good programmer, it would be to never stop learning. Read a lot, and then more. Be proficient with at least 3 or 4 languages and 2 or 3 paradigms. Have a good grasp of how their compilers or interpreters are implemented. And find your own rules.

Happy hacking!

The object oriented cake

Aboutnext SplashWhile writing my latest post on NeXT, i remembered one of my favorite videos on programming ever: the 1992 demo presentation of NeXTSTEP 3 by, whom else, Steve Jobs. If you haven’t seen it yet, please take a look below, and keep repeating yourself that this was 1992, and that that machine had a clock under 50 MHz! One wonders what on Earth have we been doing during the last fourteen years.

I was about to write a brief overview of the amazing things demoed by Jobs, but the fine guys and gals of Rixstep have already done it for me: The object oriented cake is a guided tour for those of you lacking 35 minutes to see the movie. But i bet you’ll see it anyway after reading that article. More than once!

All these wonders where made using Objective-C. One would say that there’s something to OOP. Definitely, but there’s more than objects at play: Objective-C is a dynamical language, with a living runtime and powerful reflection capabilities. Despite its C-syntax (almost any C snippet is also an Objective-C snippet), its spirit is far closer to Smalltalk, and the right way to use Objective-C is to use it as a dynamically typed language. I’m convinced that these language traits were key to make the marvellous NeXSTEP system a thriving reality.

For the really curious among you, here‘s a bit more about the platform; and one can also take a look at the NeXTstep 3.3 developer documentation.

Smalltalk daily

VisualworksI’m sure this is old hat for all Smalltalk practitioners, or anybody with Planet Smalltalk in her feed list, but here’s a great way of learning a bit more about one of the most elegant programming languages ever:Smalltalk daily. James Robertson, Cincom Smalltalk‘s Product Manager, is one of the few guys around with the word manager in their job title that knows how to program; and he’s sharing his knowledge on a daily basis in the screencast series linked above. He started last month, and has managed to live up his self-imposed, tight scheduled of one post per day. Naturally enough, he uses Visual Works for his demos, but many of the videos are about generic Smalltalk features, available in other implementationa.For instance, see his explanation on Smalltalk variables and inspectors, or this review on classes and inheritance. (As an aside, there’s also an interesting podcast series on Smalltalk conducted by James… i wonder where he finds the time!)

DolphinSmalltalk environments are one of the most amenable to video demonstrations: the whole object graph of your running environment is there for you to explore in real time, and there’s lots of interesting ways to interact with it [0]. As a matter of fact, everybody seems to want to show you his favorite Smalltalk: see for instance Stefan Ducasse’s collection of Squeak videos or this nice flash demo of how to do TDD in Dolphin Smalltalk (one of the few Windows programs i wish i had in Mac or Linux).

I was trying to imagine an equivalent video on C or Java development and couldn’t stop yawning ;-). Enjoy!


[0] See this blog entry by Cees de Grot for an enthralling account of Smalltalk’s lifeliness.

Self awareness

SelfI’ve mentioned Self, the flagship of prototype based programming, a couple of times before. Not that i have, right now, much more to say about this very interesting paradigm and this particular implementation, which its creators describe (better than i could) in the following terms:

The Self system attempts to integrate intellectual and non-intellectual aspects of programming to create an overall experience. The language semantics, user interface, and implementation each help create this integrated experience. The language semantics embed the programmer in a uniform world of simple ob jects that can be modified without appealing to definitions of abstractions. In a similar way, the graphical interface puts the user into a uniform world of tangible objects that can be directly manipulated and changed without switching modes. The implementation strives to support the world-of-objects illusion by minimizing perceptible pauses and by providing true source-level semantics without sac rificing performance. As a side benefit, it encourages factoring. Although we see areas that fall short of the vision, on the whole, the language, interface, and im plementation conspire so that the Self programmer lives and acts in a consistent and malleable world of objects. (From Programming as an Experience: The Inspiration for Self)

(If you prefer a less heady introduction, this video is a delightful alternative, and there’s also the Self tutorial.)

Self on an MacBookChances are, however, that i will have more to say about Self in the near future, for i’ve just made a pleasant discovery. Self was developed at Sun during the late eighties and nineties, and last time i looked there was a 2004 version available for PowerPC. But the Self group seemed dissolved, and i got the impression that the coming of Intel Macs would see the end of its development. Well, as is often the case, i was wrong! As recently as June this same year, a new Self 4.3 was available for download, for both PowerPC and Intel Mac. Admittedly, it looks a bit outdated and changes in this version are less than earth-shakening, but it’s still great to experiment and healthily bend your mind for a while.

Smalltalk within SelfThe ideas behind Self are worth investigating too. For instance, you’ll find in the demo image a Smalltalk interpreter, and there’s much to be learned about the compiler’s implementation or the still on-going (latest release was this august) project of writing a metacircular virtual machine, aptly christened The Klein Metacircular VM. Finally, those of you on Linux or Windows can give a try to Self/x86, although i’m afraid this one looks might be abandoned by now. On the other hand, it’s Free Software, so any sufficiently motivated gal or guy can jump into the wagon! I’m sure it would make for an awesome learning experience.