New Year’s Python Meme

Here’s a short, 5 questions, 2009 Python meme. Copy-paste the questions, and blog your answers !

1. What’s the coolest Python application, framework or library you have discovered in 2009 ?

Nothing particularly stands out this year as a cool discovery, but the multiprocessing package, IronPython and GeoDjango all deserve a mention.

2. What new programming technique did you learn in 2009 ?

I’ve been dabbling more with metaprogramming and concurrency this year. Wise people are correct in that most of the time you don’t need metaprogramming, but it’s handy to understand for those rare occasions you do need to use it. As for concurrency, well it’s a very important subject these days and difficult to avoid now. I started looking at Erlang as a way to understand the issues and begin training my mind, and found Russel Winder’s “The GIL isn’t Evil” talk at EuroPython to be very helpful.

3. What’s the name of the open source project you contributed the most in 2009 ? What did you do ?

I’m ashamed to say I haven’t contributed much at all to open source this year. My sole contribution was a tiny patch to PyODBC for SQL Server XML datatype support. I’m going to make amends and contribute more in 2010 – I just haven’t found the right project to scratch my itch.

4. What was the Python blog or website you read the most in 2009 ?

Planet Python aggregator has been very useful. Michael Foord, Simon Willison, Ned Batchelder and Thomas Vander Stichele seem to have the most saved entries in my RSS reader so they deserve a mention but there are some excellent bloggers I’ve missed out!

5. What are the three top things you want to learn in 2010 ?

For Python: learn the Natural Language Toolkit (NLTK), make a serious effort with Twisted, and use Python with XMPP.

In general: learn a new language (LISP or Clojure is looking like the most likely), have a go at one of the non-relational databases like CouchDB, keep learning to be a better mentor to other developers.

Language for 2010

I’ve been a computer language geek for a long time. Even before I read the excellent book “The Pragmatic Programmer”, I would try and learn a new language every year or two – or at least look at new languages to get ideas. This year I added C# to my repertoire and made a return to learning Erlang, which was supposed to be my original choice for the year until the demands of needing to deal with .NET forced a more pragmatic change.

Even if you never use a new language long-term, just taking a look helps sharpen skills, bring about new insights or even create a renewed appreciation for your current language of choice.

My choice for 2010 is quite tricky, so I need some help in deciding from you, dear reader. The short list is as follows:

Squeak – http://www.squeak.org/

My Smalltalk knowledge is all read and no write, so time I actually learnt the language properly and wrote some code because it looks like such a simple and elegant language. I don’t think knowing and enjoying some Objective-C quite counts, somehow!

Squeak feels like the right way for me to learn Smalltalk. I even downloaded the software a while back, but am ashamed to say I just haven’t installed it yet.

Common LISP – http://clisp.cons.org/

LISP has been on my list (no pun intended) for years. I’ve done a tiny bit of EMACS LISP programming and the Amiga Installer uses a LISP dialect, but neither are really sufficient for me to say “I’ve done LISP”. Eric Raymond (I believe) said LISP was probably the best programming language to learn that you will never use, and I think he’s right. LISP featured things like garbage collection and dynamic typing back in 1958, features that some might believe are relatively new additions to programming languages.

I will, however, say that I don’t agree with people like author Neal Stephenson who insist LISP is the only programming language that can be described as beautiful.

Clojure – http://clojure.org/
Groovy – http://groovy.codehaus.org/

I made a brief look at Java (1.1) in 1996 thanks to a foresighted university lecturer, and again in 2005 when I was unemployed after returning from a season snowboarding. The JVM is pretty cool, but Java has changed a lot since the early days and not always for the better in my opinion. Apart from those two little forays, I’ve avoided the Java ecosystem as an area of interest. Now, however, things are changing. Non-Java languages on the JVM are gaining ground, including Jython and JRuby, but also new languages like Clojure and Groovy are appearing and revitalising the Java world.

Groovy seems to have quite a bit of interest from people in the Python community and, from what I’ve seen, I can understand why. It simplifies a lot of the complexity / boilerplate of Java, adds the power of dynamic typing that smug Pythonistas such as myself take for granted, and the name is suitably non-Enterprisey for me to take notice.

Clojure, on the other hand, is a dialect of LISP for the JVM. This would allow me to look into the JVM ecosystem while learning LISP. I also note there is CLR / .NET support as well, which is interesting – though I doubt I will be able to use it to interact with legacy .NET code at work.

Ruby – http://www.ruby-lang.org/en/

Not strictly a new language for me, but I briefly looked at Ruby on two occasions (notice a Java-like pattern here?). The first time was in 2005 for a possible Ruby developer job. They couldn’t find Ruby programmers so were looking for people with Perl and Python experience – I hadn’t heard of Ruby at the time, but it sounded interesting so I had a quick play with it. The second time was in 2007 when I read the “RESTful Web Services” book.

I must admit, I found Ruby terribly disappointing on both occasions. Please don’t flame me! A language that blends elements of Perl and Python, with some LISP-like tweaks, should be pretty cool, but it just felt syntactically awkward in places. Despite my disappointment, I can see why some people like it and it’s making more of an appearance in places I wouldn’t expect a dynamic language to be mentioned. I should really give it another go.

Now your turn…

So, what language from the list do you suggest I look at and why?

Software Development… Inspired by Flat Pack Furniture?

I’ve recently moved into the first place of my own, so I’ve become well-versed in the culture of Ikea furniture and the art of flat-pack assemblies. Even though the home DIY genes do not flow through my family line, and my attempts at woodwork at school were poor to say the least, I must admit to getting a certain pleasure from building self-assembly furniture and the results are, in my humble opinion, pretty damn good considering.

So what has this to do with software development? Well, I’m always looking outside the IT world for programmer inspiration and I had a moment of bizarre clarity while screwing together the parts of a dining room chair. As you do.

We, as developers, are always (hopefully) trying to find ways to make our work easier and of better quality. In an ideal world, we seek elegance, simplicity and usefulness. Things should be repeatable consistently, they should do the task at hand well, and should be easy for our users to use. And our ivory towers should be furnished by inexpensive yet stylish items.

Documentation

My moment of clarity began with the Ikea instructions for the chair. They offer clear details on how to go through the instructions, what you will need and what to do if it goes wrong. So what? Well, they do this without words: clear, simple, multi-lingual instructions. From a set of simple pictures, I know what additional tools I will need, the parts I should have in the box, I know to take it slow, remain calm, and give my local store a call if things are missing or it all goes horribly wrong. All from pictures. Can you imagine having to a) write down all those steps and b) repeat in dozens of languages? Can you imagine how many more pages you would find in those instructions?

Each of the build steps are equally clear and pictorial. The minimal amount of information is used to illustrate precisely what is required at every step of the process. When writing documentation, particularly user documentation, we can learn a lot from this. It’s so easy to write a big blob of text, slap together some full-size screenshots and call that a doc. It probably makes sense to us, since we wrote it – but does it make sense to someone else? Can we strip down the information to the essential minimum? Can we make the document clear and unambiguous? Can we show rather than tell? Are we repeating ourselves? Think about these things next time you write user documentation, detail a build process or comment your code.

Make It Easy

Ease-of-use isn’t just something we apply to anything user-facing. We don’t have lots of spare time these days and much as it’s an interesting intellectual exercise to work through a lot of hassles to get something to build or install, I’m a huge fan of things that Just Work. There are few things more tedious than having to wade through shark-infested waters or find specific versions of libraries just to run a simple application or fix a bug in the source code of a third-party tool.

Ikea’s furniture makes it a doddle to assemble. Using a minimal set of tools, anyone who can grasp a screwdriver and bang in a nail (straight is optional) can build decent looking furniture. I know, I’ve been there. The barrier for entry is low, and they’ve designed the items in such a way that it’s difficult to go wrong: the clear instructions are coupled with parts that have obvious ways to fit. If you find yourself forcing parts in with brute force, or a screw is not tightening up correctly, or bits are mis-aligned it’s likely down to user error. Complicated parts, like the back of the aforementioned chair, come ready assembled so a DIY dolt like me doesn’t have to worry: someone else did the hard work.

Good Enough

Ikea keeps costs down by operating the Good Enough principle. I see similar bits cropping up in various products (good reuse), hidden parts have little or no finish compared to visible parts (why waste paint or varnish?), the materials are often good enough for the job at hand, and there’s a minimal theme to parts anyway. My coffee table cost 8 quid and has a mere five bits to it, yet looks great and is fully functional. It’s a classic example of a design that meets the minimal requirement to get the job done.

Professional pride often means we take longer than we should in order to do “a really good job” when really we should aim to be good enough. I’m not expecting that table to be handed down to future generations, and the designer already knew that. As their customer I wanted something cheap and available to rest a mug of drink on in the evening. I didn’t want to wait several months for a master craftsman to build me a one-of-a-kind at great expense, especially if it might not actually be what I really wanted.

When writing code, take a good look at what you’re implementing. Is it a prototype? A demo? Is it going to last a year? A decade? Are people okay if it is rough around the edges or is it a life-critical system that has to work no matter what? Use the appropriate amount of time and effort to meet the requirements, and no more. Don’t add features you or the customer may not need – the cost of my table would’ve gone up a lot if the designer had started adding drinks holders, a cactus pot plinth, customisable colour panels and so on just in case I might need them.

Support

Finally, comes support. No matter how busy and understaffed the employees were (sounds like my office), there was always someone available to offer a hand where possible. You could interrupt them shifting crates or obviously fretting about dealing with lots of problems, but they made the time to help where they could. No matter how much of an irritating or clueless customer I could be. The warehouse could be on fire or buried under an avalanche, but that’s not the customer’s problem – the customer is trying to find his five-part coffee table and that’s the only thing happening in their world right now. No matter how overworked we are, the people using our software remain important – we’re creating code to scratch their own itches, solve their problems, create software that is of use and interest to others. Without them, we’re writing for one and that’s not so fun. Well, to me maybe. Don’t forget to make time for them.

And Enjoy

I’m sure there are other things to take away from my furniture-driven experience, but you get the idea(s). So the next time you look around at something outside the programming world, have a think about what lessons you can apply from the experience to your software development. I certainly will never look at flat pack furniture in quite the same way again.