Manni Wood

I blogged not too long ago about heroic programming, and how when I was younger, I thought Real Programmers used Real Languages like C. Real Programmers littered their code with Difficult Stuff like memory allocation and crazy pointer arithmetic. Yet as I gained experience and looked at the architecture of open source projects I admired, I saw that Real Programmers actually cordoned off the difficult stuff and were confident enough in their own skills to not feel the need to show off. Real Programmers embraced simplicity and elegance (which is sometimes actually harder than just picking a couple of design patterns out of a book and hammering them into shape to fit your problem).

I thought that Joel Spolsky’s The Duct Tape Programmer was going in the same direction:

One principle duct tape programmers understand well is that any kind of coding technique that’s even slightly complicated is going to doom your project. Duct tape programmers tend to avoid C++, templates, multiple inheritance, multithreading, COM, CORBA, and a host of other technologies that are all totally reasonable, when you think long and hard about them, but are, honestly, just a little bit too hard for the human brain.

George Orwell said: “Never use a long word where a short one will do.” Orwell thought people who are trying to hide something, or who lack the conviction of their beliefs, hide behind large words and flowery, indirect language. I’ve always suspected that over-architected, baroque codebases hide something too.

So you would think that Spolsky would conclude his essay with “therefore, we should all try to be a bit more like duct tape programmers: while we do not want to write messy code or bad code, we do want to write simple code and not embrace complexity for its own sake. We should not be embarrassed when we do the simplest thing possible. We do not need to show off our programming chops at every turn. It’s OK to admit there was an easy solution and ship on time.”

But Spolsky does not say this. Instead, he concludes with:

One thing you have to be careful about, though, is that duct tape programmers are the software world equivalent of pretty boys… those breathtakingly good-looking young men who can roll out of bed, without shaving, without combing their hair, and without brushing their teeth, and get on the subway in yesterday’s dirty clothes and look beautiful, because that’s who they are. You, my friend, cannot go out in public without combing your hair. It will frighten the children. Because you’re just not that pretty. Duct tape programmers have to have a lot of talent to pull off this shtick. They have to be good enough programmers to ship code, and we’ll forgive them if they never write a unit test, or if they xor the “next” and “prev” pointers of their linked list into a single DWORD to save 32 bits, because they’re pretty enough, and smart enough, to pull it off.

Really? Because I thought the programmers who aren’t clever/silly enough to xor their “next” and “prev” pointers should especially try to emulate the best attributes of Duct Tape Programmers. Instead of hiding behind technologies that “are, honestly, just a little bit too hard for the human brain”, regular programmers should also try to just think hard about what it is they are trying to solve, and do it in the simplest, cleanest way possible.

I agree with Spolsky that whereas Duct Tape Programmers use every trick in the book to ship code fast, the average programmer should avoid those tricks. Makes sense to me.

But where Spolsky goes off the rails is implying that average programmers should also avoid the good habits of Duct Tape Programmers, like doing the simplest thing possible. Avoiding difficulty for its own sake (or out of a need to show off; or out of the need to follow a “best practice”) is not a clever trick reserved to the programming elite. It’s sound advice that should especially be followed by mere programming mortals, to keep them out of trouble, and to help them meet their deadlines.

Jeff Atwood wrote about FizzBuzz, a programming “challenge” that apparently a lot of CS grads have trouble solving. (I wonder how one graduates with a CS degree not knowing about if/else and looping? I’m self-taught, so I can’t relate any stories about classmates who just didn’t get it.)

Anyway, while reading about FizzBuzz, I quickly hacked up a solution in Python’s REPL (apparently, this desire to hack a solution is very common), but then I figured I should hack a solution up in Lisp, which I’ve been learning lately:

(loop for i from 1 to 100 do
  (cond ((and (= (mod i 3) 0) (= (mod i 5) 0))
         (print "FizzBuzz"))
        ((= (mod i 3) 0)
         (print "Fizz"))
        ((= (mod i 5) 0)
         (print "Buzz"))
        (t
         (print i))))

Of course, this got me to thinking about all the other programming languages I know, so I had to code something up in every C-syntax language I know:

In C, I can’t do anything outside of a function, so we have the standard main(). Before I learned C, I had C envy, and I figured “real” programming languages did not let you just hack code outside of a containing function (or method and class in OOP languages). But Lisp is considered a real languge, and my solution, above, executes just fine.

#include <stdio.h>

int main() {
    int i;
    for (i = 1; i <= 100; i++) {
        if (i % 3 == 0 && i % 5 == 0) {
            printf("FizzBuzz\n");
        } else if (i % 3 == 0) {
            printf("Fizz\n");
        } else if (i % 5 == 0) {
            printf("Buzz\n");
        } else {
            printf("%i\n", i);
        }
    }
}

In Java, of course, everything has to be an object, so I have to declare an object and a main method just to begin coding. And let’s not forget System.out.prinln instead of printf(). All this extra typing always makes me feel so Java-ish. ;-) The code is visibly wider than the C code. :-0

public class FizzBuzz {
    public static void main(String[] args) {
        for (int i = 1; i <= 100; i++) {
            if (i % 3 == 0 && i % 5 == 0) {
                System.out.println("FizzBuzz");
            } else if (i % 3 == 0) {
                System.out.println("Fizz");
            } else if (i % 5 == 0) {
                System.out.println("Buzz");
            } else {
                System.out.println(i);
            }
        }
    }
}

Turning to JavaScript was fun: I discovered that Ubuntu 9.04 has a command-line JavaScript parser built in. (Or had I installed it before?) So you can just write .js files with shebang notation at the top, and you’re one “chmod +x” away from running your JavaScript on the command line. Go, Rhino! Unlike the other C-like languages, JavaScript puts the Script in JavaScript: I just start hacking code outside of a function definition, as I would with Perl or Python:

#!/usr/bin/js

for (i = 1; i >= 100; i++) {
    if (i % 3 == 0 && i % 5 == 0) {
        print("FizzBuzz");
    } else if (i % 3 == 0) {
        print("Fizz");
    } else if (i % 5 == 0) {
        print("Buzz");
    } else {
        print(i);
    }
}

I’ll always have a soft spot for Perl: it’s the first language I was paid to code in; it launched my career.

#!/usr/bin/perl

for ($i = 1; $i <= 100; $i++) {
    if ($i % 3 == 0 && $i % 5 == 0) {
        print "FizzBuzz\n";
    } elsif ($i % 3 == 0) {
        print "Fizz\n";
    } elsif ($i % 5 == 0) {
        print "Buzz\n";
    } else {
        print $i, "\n";
    }
}

Bash is only slightly yukkier than Perl. Doing math inside $(()) is just a little odd, syntactically, but it gets the job done:

#!/bin/bash

for i in $(seq 100)
do
    if [ $((i % 3)) == 0 ] && [ $((i % 5)) == 0 ]; then
        echo 'FizzBuzz'
    elif [ $((i % 3)) == 0 ]; then
        echo 'Fizz'
    elif [ $((i % 5)) == 0 ]; then
        echo 'Buzz'
    else
        echo $i
    fi
done

SQL fanboy that I am, I couldn’t resist doing this in PostgreSQL. It came out rather clean and terse, which I guess shouldn’t surprise me too much. SQL is my favourite domain-specific language!

select case when i % 3 = 0 and i % 5 = 0 then 'FizzBuzz'
            when i % 3 = 0               then 'Fizz'
            when i % 5 = 0               then 'Buzz'
            else                         cast(i as text)
       end
  from (select generate_series(1, 100) as i) as lst;

And here’s the code I hacked together in Python’s REPL, starting this whole trip down languages-I’ve-known memory lane:

for i in range(1, 101):
    if i % 3 == 0 and i % 5 == 0:
        print 'FizzBuzz'
    elif i % 3 == 0:
        print 'Fizz'
    elif i % 5 == 0:
        print 'Buzz'
    else:
        print i

I must admit. Looking at the Python, I’m very glad I learned it. Is it just me, or does Python look like pseudo code? Like if you were thinking in your head “well, first I’d have to loop through the numbers 1 through 100, and then I’d have to check modulo 3 and 5, and then…” would the pseudo code in your head look a lot like Python? Python has often been called runnable pseudo code, and looking at all the languages I know, FizzBuzz certainly looks the cleanest in Python.

Then there’s Lisp, which I’ve been teaching myself lately. By contrast, Lisp is just a little bit yucky. I understand that, as Paul Graham says, Lisp doesn’t actually have a syntax, and its lack of syntax allows Lisp to support all sorts of interesting features like its awesome macros.

But tell me I’m not the only one who thinks “((and (= (mod i 3) 0) (= (mod i 5) 0))” is not very much fun for human eyes to parse. If nothing else, prefix notation puts verbs and nouns a little bit too far from each other. (I wonder if I’d be more OK with this if my mother tongue was Latin? Word order doesn’t matter in Latin…)

Makes me wonder what FizzBuzz would look like in PHP and Ruby.

I promised myself that I was going to learn more about ORM, but in my off time, I’ve been learning Lisp instead.

I still want to learn more ORM stuff (it’s everywhere, and popularity is a good reason to learn any technology) but it struck me that I already have strong SQL skills and 10+ years hacking Java (not to mention reading the GoF book) so learning ORM really well would be about as difficult as learning a new library. Combine my knowledge of OOP with my knowledge of SQL and use that knowledge to learn a library like Hibernate, or Django’s ORM, or Rails’ ORM. Done.

What I really wanted to do was learn Arc or Lisp, and really get a handle on a language whose feature set Paul Graham says other languages are converging on anyway.

Besides: Andrew Hunt and David Thomas recommend in their book, The Pragmatic Programmer, that I should learn a new programming language every year. I moved my J2EE project to Python/Django back in November; it’s been almost a year already! Time to crack open my copy of Practical Common Lisp and get serious once and for all.

Here’s a shout-out to a blog entry that says “Design patterns are common structures that appear in computer programs, but that can’t themselves be abstracted into a reusable component”.

I remember early on, when porting some of my Java code to Python, I wanted to make a singleton in Python. I turned to my copy of the Python Cookbook, and found that singletons are very rarely needed in Python, because Python’s modules exhibit essentially the same behaviour. It was one of those learning moments for me, when I realised that I was trying to write Python like Java, and that I should try to write Python more like Python. (In my own defence, we all do this when learning a new language. :-)

Here’s an observation by the always-fascinating Steve Yegge on design patterns:

About half of all design patterns out there (not just the GoF patterns) appear to be ways take perfectly natural design ideas and twist them to fit into someone’s static type system: recipes for pounding square pegs into round holes.

—Steve Yegge, Is Weak Typing Strong Enough?

Yegge’s quote also rings true to me, because I just don’t find myself doing a lot of design-patterny stuff in Python, presumably because Python’s dynamic typing and powerful built-in data structures (lists and dictionaries) prevent me from having to use a lot of objects and their attendant design patterns in the first place.

This makes me want to really, really learn Common Lisp, or Arc, or Scheme, or some language with full-fledged macros. What does this have to do with design patterns? I can’t really tell you, because I don’t know Common Lisp yet.

But here’s a sneaky suspicion I have.

I suspect that the same way half of the design patterns that Yegge mentions were invented to compensate for languages that lack dynamic typing and higher-level constructs, the other half of design patterns, and even entire frameworks (think: Ruby on Rails, Django) compensate for languages that lack true macros.

Now it could turn out that I’m wrong about this, or that there’s only a kernel of truth in my suspicion, but that the whole truth is more complicated.

But readers of my blog know that I give a lot of credence to Paul Graham’s idea that mainstream programming languages are slowly converging on the feature set of Lisp.

I’ve never heard of a Lisp or Arc framework for building database-backed web sites. Where’s Lisp’s Django, or Arc’s Rails, or Scheme’s Struts? I suspect that these languages don’t need frameworks, because macros are essentially tools for building project-specific frameworks.

Who among us has taken a framework like Django or Rails or Struts, and used the parts that solved our problems, and re-written or ignored the parts that didn’t solve our problems, or that introduced new problems? Now imagine what it would be like using a programming language that was essentially a framework construction kit; that allowed you to write a framework more quickly than learning and adjusting to a pre-existing framework?

The only higher-level abstraction I can think of off the top of my head is a language that enables you to easily construct your own domain-specific languages. (I like regular expressions for text searching and manipulation, and SQL for data searching and manipulation; imagine your own DSL for your exact business problem! That would even beat frameworks or even macros…)

Apparently, Perl 6 and the Parrot VM are going to try to tackle that exact problem. The problem is, Perl 6 hasn’t shipped yet. (I’ve only been waiting 10 years… ;-)

In the meantime, I really need to learn Lisp or Arc once and for all. I really want to learn about macros.

Any readers of my blog will know that my experience with data lies almost exclusively in data that are best modelled in a relational way. So I have a lot of biases that have evolved through playing a lot in that problem space:

• I like SQL a lot, but realise the SQL standard is an imperfect implementation of the relational model.
• (Heck, I know what the relational model is, after reading lots of C. J. Date.)
• I like writing SQL by hand, (roughly analogous to the way designers like to code their HTML/CSS by hand) because I think I get the best results that way.
• I think the object/relational impedance mismatch is best solved by simply avoiding the situation: don’t use ORM.
• If your data set is small but must be accurate (as has been the constraint on most of my projects), use a database that does this for you. (That is, declaring constraints in DML and having your RDBMS do the rest is a beautiful thing.)

On the other hand… :-)

I’ve been interviewing a places that use non-traditional data stores, sometimes on massive data sets, where ACID compliance is not paramount.

The challenges some of these project face sound really cool, and the tools they are using to meet those challenges would be a lot of fun to learn.

So first off, I should make something really clear: I have reasonably passionate views about RDBMSs, especially regarding small, accurate data sets, because I’ve done a lot of work in this area, with real-world consequences if I didn’t get things correct.

However, I also feel that not all data are relational!

Although I agree with C. J. Date that no other data model compares to the relational data model (at least in terms of being able to be specified in a rigorous way), not all data have to be stored in a way that conforms to the relational model.

For instance, I remember being a little bit afraid early in the development of Windows Longhorn (later to become Vista) when it seemed like they were going to make the entire file system a database. Really? I rather like the hierarchical file system! It turns out the Windows design team came to the same conclusion too.

Take server access logs. They are stored as flat files. Would they benefit from being stored in an RDBMS? I don’t know. It would be nice being able to run SQL queries on them. But you could also make the argument that sometimes a flat file is just a flat file.

Take documents. Some people store them in Lotus notes, some people store them as binary blobs in RDBMSs, and most of us still keep documents on whatever hierarchical file system our operating system currently uses.

Although I love the relational data model, as soon as you decide to use it for your data, you are immediately making certain decisions about the nature of your data, either implicitly, or explicitly.

I’ve played in the relational world for quite some time now, and am excited about looking at data through a different lens.

So maybe I’ll work on a project where modelling the data with objects rather than relations is the absolute right thing to do!

Maybe I’ll be on a project where transactions and constraints have to be enforced in the application layer, because the underlying data store cannot enforce these things itself (and that would be because the underlying data store has other strengths).

Maybe I’ll be on a project where the object model can be the definitive data model, because no other applications are ever given direct access to the underlying data store; so the data store will not have to be the final arbiter of what the data model is. Instead, the data will only ever be accessible as a web service, and so the API that we expose to the data will be the only legitimate view of the data.

I’ve played in the world of small, accurate relational data sets for quite some time. It could be fun to work with really large, semi-structured data sets, and see what sorts of solutions they require, and maybe challenge some of my core assumptions about data.

One thing I like about the job interview process (as I am going through it now) is that you learn what your blind spots are as a developer. It’s not very much fun to find out what those blind spots are, but I did get into this profession because I liked learning new things. And what’s more useful than learning about your weaknesses?

I had a great discussion with a coder I used to work with today, and he pointed out something that was staring me right in the face: I may agree with Ted Neward, Jeff Atwood, et. al. about object-relational mapping being an insurmountable problem (the Vietnam of computer science, as Neward called it) but my coder friend said:

“Look at the market place! ORM has won!”

And he’s right! So what I need to be asking myself is, if ORM really is the Vietnam of computer science, why is everybody using it? There’s an opportunity for me to learn something here, and my attitude towards ORM is not reflective of my more nuanced attitude towards a lot of other things.

Case in point: I was recently asked my opinion on stored procedures in the context of building web applications, and I gave my typically nuanced answer about their strengths and weaknesses, and how they had their uses, but did not need to be embraced 100% nor rejected 100%.

And that same truth is staring me in the face with ORM, and I’ve been ignoring it.

I have mostly worked on sites where the data model was already written, was quite messy, and the CRUD (create, read, update, delete) operations were all non-trivial. My blind spot so far has been assuming all situations are like this. The popularity of ORM seems to indicate that this is not always the case.

In fact, in discussions with other developers, I find that most projects take a hybrid approach to ORM: they use it where it speeds up development and does not adversely affect application performance, and they do not use it where hand-coded SQL is the better way.

My programmer friend recommended I take a look at ibator, a code generator for iBATIS that is sort of like a reverse ORM: it introspects your database, and creates all the CRUD code and Java objects for you. I don’t think I’m quite ready to dive into Hibernate yet, but ibator seems like a good place to start. If I get time, I will blog about my experiences with ibator.