Manni Wood

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.