Every so often, I get drawn into a discussion about the merits of static typing (Java, C, C#, ML) versus dynamic typing (JavaScript, Python, Ruby, Scheme). Many programmers seem to be firmly in one camp or the other. But somewhere in between, there’s a third door. Let me explain…

I hate dynamic typing.

Dynamic typing leaves too much room to leave mistakes in your code. Stupid ones, too, the kind where you try to subtract apples from golf clubs. And the kinds where you sort of forgot to implement the “else” part.

These are typical mistakes which could be proved, by the compiler, to never possibly work. Only it’s not even trying, and it’s leaving it all up to me, a dodgy forgetful emotional interrupted tired inferior human, to stare at it long enough to assure myself that it will work correctly in all possible situations. It won’t, of course.

I hate static typing.

Static typing makes you think about types when you want to think about your program. Before you can run anything, the compiler insists that everything is perfect, but you’re only just starting to build the shape of your code. You probably don’t know what it’s going to look like when it’s finished. Perfect is for later.

I hate lack of type inference.

Spelling out the types for each variable and parameter and return type and field makes your programs ugly. Most of that type information is implicitly clear to you, so it makes no sense that you have to always explicitly mention every type in the actual code. The compiler and IDE should do some of that for you.

I hate type inference.

Full-blown type inference makes type errors insanely difficult to locate. The compiler figures out that the types in your code aren’t adding up, but it has no idea where the error actually is. The problem is that often you have no idea, either.

The point I want to make is that the choice between dynamic and static typing is a false dichotomy. You don’t need to choose between showering and brushing your teeth. You do both. In the same way, you shouldn’t have to choose between static typing or dynamic typing. You should be able to use the appropriate tools in the appropriate places at the appropriate time. The right kind of static typing is discretionary static typing.

Luckily, programming languages are already moving in this direction. Yesterday, Google published a new programming language called Go:

Go is an attempt to combine the ease of programming of an interpreted, dynamically typed language with the efficiency and safety of a statically typed, compiled language

That sounds like just what the doctor ordered. C# from Microsoft is also steadily gaining some type inference and dynamic typing features. Both C# and Go are actively trying to fix some of the biggest pain points in the working programmers’ lives.

I for one will be taking a good look of what’s behind the third door. Will you?

I decided to change the name of this blog to something more descriptive and less “meh”. This blog is about developing software and managing development teams. That is, about hacking, and about being a boss. Frequently at the same time.

It is likely that RSS subscribers will see old posts coming up as new. I apologize for the inconvenience.

And now, back to our regular program.

When I was studying Scheme on a programming course at HUT, I remember I was a bit baffled of first-class functions. My previous experiences were with C, Pascal, Basic, and other languges which didn’t have first-class functions. Data is data, code is code. You don’t go mixing those two. Why would you want to create new functions on the fly and pass them around as values? Crazy talk!

What really made me understand was the following homework exercise:

Define cons, car, and cdr without using any built-in data structures. Hint: Use first-class functions.

As you may know, cons is a function which takes two arguments and returns a single value which contains the two argument values inside. This single value is called a pair (or sometimes a cons cell). The car and cdr functions extract the left and right parts of a pair, respectively.

Without further ado, here’s the solution. I suppose most readers aren’t necessarily familiar with Scheme, so I’m including both JavaScript and Scheme code.

function cons(a, b) {
  return function(x) {
    if (x) {
      return a
    } else {
      return b
    }
  }
}
 
function car(p) {
  return p(true)
}
 
function cdr(p) {
  return p(false)
}

(define (cons a b)
  (lambda (x)
    (if x a b)))
 
(define (car p)
  (p #t))
 
(define (cdr p)
  (p #f))

This really helped my understand what this lambda business is all about. It’s more than a function without a name. It’s less magical than generating code on the fly, which was what I first believed must be happening. A first-class function is a way to bind together some values (a and b) together with some code operating on those values (the if). The result is a function you can call like a regular function.

Sometimes, I’m a bottom-up kind of guy, so the final missing piece of understanding had to come from figuring out how lambda could be implemented by the compiler or interpreter. Here’s how:

function cons_f(a, b, x) {
  if (x) {
    return a
  } else {
    return b
  }
}
 
function cons(a, b) {
  return [cons_f, a, b]
}
 
function car(p) {
  return p[0](p[1], p[2], true)
}
 
function cdr(p) {
  return p[0](p[1], p[2], false)
}

So when the compiler encounters a function body which refers to variables outside the body, it kind of lifts the lambda into a top-level function. Any open variables are made into new explicit parameters for the function. The function value is basically a vector with a reference to this “normal” function, plus the values of the open variables at the time.

Technically this is not exactly how things happen, but hopefully you get the point. The point being that deep down, lambda is really not that much more special than allocating a vector.

As for the solution itself, we can actually do a bit better. We don’t really need to use a conditional:

function cons(a, b) {
  return function(f) {
    return f(a, b)
  }
}
 
function car(p) {
  return p(function(a, b) { return a })
}
 
function cdr(p) {
  return p(function(a, b) { return b })
}

(define (cons a b)
  (lambda (f)
    (f a b)))
 
(define (car p)
  (p (lambda (a b) a)))
 
(define (cdr p)
  (p (lambda (a b) b)))

We can go even more basic than this. The above code uses functions with two arguments. Let’s make it curried, and only use functions with one argument. It’ll change the API, though, so instead of cons(a, b) you call cons(a)(b).

var cons =
  function (a) {
    return function(b) {
      return function(f) {
        return f(a)(b) 
      }
    }
  }
 
function car(p) {
  return p(function(a) {
    return function(b) {
      return a }
  })
}
 
function cdr(p) {
  return p(function(a) {
    return function(b) {
      return b
    }
  })
}

(define cons
  (lambda (a)
    (lambda (b)
      (lambda (f)
        ((f a) b)))))
 
(define (car p)
  (p (lambda (a) (lambda (b) a)))))
 
(define (cdr p)
  (p (lambda (a) (lambda (b) b)))))

This is arguably as basic as it gets. We’ve defined cons, car, and cdr using nothing but function definitions and function calls.

Hopefully this little exercise helped you as much as it helped me. They say you don’t really know a programming language until you’ve learned to hate it with a passion. I’d say you don’t really know a programming language until you’ve implemented a compiler for it.

A long time ago, I was actively playing a MUD. A MUD is like World of Warcraft, only on a much smaller scale, and there are no graphics. It’s all text based. To make your character do anything, you have to type commands at the prompt.

The thing with this MUD was that fights were not strictly turn based. If you were too slow to cast your next spell, your wizard would be standing there with a vacant look in his eyes while some troll is bashing him to bits with a morning star. The faster you type, the faster you cast the next spell.

After a few hundred hours of playing, typing no longer exists as a separate activity. It’s automatic. You think “fireball” and the words appear on screen. Technically, your fingers are still pressing keys, but for all practical purposes your mind is now directly linked with the game.

The same kind of mind-to-machine link forms after enough practice with your programming language and IDE, or shell. You don’t need a sci-fi socket on the back of the skull for that. All you need is enough practice.

You also need a good keyboard.

A good keyboard is one which you forget is there. A good keyboard doesn’t jam the Enter key when you press it on the upper right corner. A good keyboard has zero packet loss from your brain to the computer.

My new favorite keyboard is the Apple aluminium keyboard. The tactile feedback is just right. It’s small, so there’s more room for other stuff on my desk. It’s thin, so I don’t need a separate wrist rest at all. It looks beautiful, and is obviously the result of a great deal of design work. This keyboard even sounds good.

I would be very interested to hear what you have to say about keyboards. What is your favorite keyboard? Give your opinion in the comments section!

How well do you know the fundamental unit of information, communication, computation?

When interviewing coders, I often like to ask them to explain how they would implement a function which counts the number of bits set in an integer. In Beautiful Code: Leading Programmers Explain How They Think, Henry S. Warren, Jr. gives a wonderful treatment of the population count problem. This C code implements a clever algorithm to compute number of set bits in one 32-bit word:

/* Counts 1-bits in a word. */
int pop(unsigned x) {
  x = x - ((x >> 1) & 0x55555555);
  x = (x & 0x33333333) + ((x >> 2) & 0x33333333);
  x = (x + (x >> 4)) & 0x0F0F0F0F;
  x = x + (x >> 8);
  x = x + (x >> 16);
  return x & 0x0000003F;
}

Can you figure out how it works?

For a really hard-core puzzle, try to figure out this piece of code from the Quake code. It computes the inverse square root of a floating point number:

float InvSqrt(float x){
   float xhalf = 0.5f * x;
   int i = *(int*)&x;
   i = 0x5f3759d5 - (i >> 1);
   x = *(float*)&i;
   x = x*(1.5f - xhalf*x*x);
   return x;
}

Wow. If you need to cheat (I did), the web is full of explanations. The one that really helped me understand was by Kalid Azad at BetterExplained.

I firmly believe that every programmer should try to build a good working understanding of the bit world. It’s not that you have to know that stuff to be able to write (most) programs. But look at it this way. That computer on your desk has a CPU in it. That CPU is executing billions of instructions per second to execute your code. Are you really not interested at all on what’s going on in there? Don’t you want to know why computers suck at math?

If the next coder you interview has trouble answering more than a couple of the following, that should be a no hire:
The next time you are interviewing a coder, here are some questions you could ask to probe their understanding of the binary system:

• What are the first ten powers of two?
• What is 0×7F in binary? In decimal?
• What does two’s complement mean?
• How would you extract the 8 low-order bits from a word?
• How would you count the number of bits in a word?
• What arithmetic operation does shifting right by one bit correspond to?

To me, total lack of understanding in this area is a big red flag and should cause a no hire. It means that you either haven’t been programming long enough to encounter these bit-level problems, or worse, you did encounter them but gave up for one reason or another.  It’s a real confidence booster to know that you can, if need be, go all the way down to the bit level to solve a problem or understand a bug.

It’s all ones and zeroes, right? The bits are your friends. How well do you know them?

Do you remember your last quarrel over whether the current architecture of your software is a good one? Were you defending or attacking?

I’m sure some parts of that discussion weren’t completely rational. Here’s a list of some of my favorite irrational arguments against fixing a broken architecture. Maybe the list helps you recognize them as irrational the next time you hear them or use them yourself.

1. It’ll be fine after these fixes

This one is popular among people who have never really written a lot of code, at least not of the high quality kind. They view software quality as something than can be added later. They think quality is something which can be poured in later, in controlled doses, carefully avoiding adding too much to avoid spending too much time on quality which is above the market expectation.

High software quality has to be built in right from the start. You can’t pour it in afterwards. If the design is poor, no amount of bug fixing will get you to rock solid. If you keep fixing it long enough, you might get to “works most of the time”, but you will never reach rock solid.

2. There is no problem

Flat-out denying that there is any problem is a powerful trick. Deny all evidence. If there is evidence, place the blame on third parties, the operating system, the users, whatever. If you have to, shoot the messenger.

The tendency to employ this technique seems to be stronger in people who have spent considerable amounts of time designing and creating the broken architecture. You probably define yourself through the work you have done, at least to some extent. What was the last thing you created which you are proud of? How hard would it be to admit that your creation is, in fact, a load of crap? I bet it would be easier for you to find fault somewhere else, or simply deny that there is anything wrong in the first place.

3. Developers always want to rewrite everything anyway

The power of this technique lies in the fact that there is a grain of truth in it. Many developers have this built-in tendency to build new stuff instead of patching up the old stuff. For me, I think it has something to do with how I was introduced to programming. I fell in love with creating new impressive things, and that’s what I want to do again and again.

However, that grain of truth is not a logical argument against fixing your architecture. If you know that the smelly guy down the hall always eats at Burger King and never at McDonalds, you still have no information about which is the better choice for lunch. All you know is that the smelly guy likes his whoppers.

4. It was built by our best engineers

The architecture was designed by your very best engineers, so it cannot possibly be a bad architecture, right? Besides, those engineers are too important to risk making them mad. If we can’t trust our best engineers, who can we trust?

Smart people do stupid things all the time. It’s often impossible to know beforehand how something turns out to work in real life. The smart thing to do is to adjust, refactor, redesign, and rewrite as necessary. It’s not very smart to keep going with the first thing that kinda worked.

5. This architecture will give us benefits in the future

This technique works best if you are vague. Things such as scalability and flexibility sound good, as do promises about how the architecture can be leveraged in the future to rapidly build new and innovative applications. Being very specific and concrete will probably reveal that the architecture is not, in fact, superior to the alternatives.

So, that was my list of favorite techniques to bury your head in the sand. When was the last time you used them yourself? What would you add to the list?

Porting software to another platform is tricky business. Take the first version of Safari for Windows as an example. It was not a great success, because Safari 3 on Windows did not quite fit in:

Other grumbles were more because Safari seems like a Mac-application, making it seem out of place on a Windows desktop.

Mac-users, firmly convinced of the superiority of the Mac platform may assume that a Mac-app running on Windows should “obviously” appear superior to Windows users. That’s not the case.

Even if you were to accept that the font rendering in Safari 3 is superior to Windows standard font rendering, the difference sticks out like a sore thumb. In Safari 4 for Windows Apple fixed most of the issues:

Safari now looks more like a standard Windows app. Previous versions stuck with the iTunes/OS X brushed metal interface, which stood out for several reasons: the buttons and scroll bars were standard OS X Aqua elements, rather than standard Windows items.

So, when porting to a new operating system simply getting it to run is nowhere near enough. Operating systems come with a culture, complete with their own installers, GUI style, jargon, and soft drink preferences. Your port has to match the culture.

Sometimes you need to port between platforms which aren’t operating systems. You might feel the need to support two or more different RDBMS’s, for example. SQL is a standard, right? What could go wrong? Jim Melton, the editor of the SQL standard for 20 years, said in SE Radio Episode 137: SQL with Jim Melton:

“It’s unclear exactly what the driving factors were for most of the organizations [for standardizing SQL]. I know for some of the vendors who eventually became dominant, ones like Oracle, IBM, and Sybase, the driving motivation was the ability to have the illusion of portability. Yes, I’m being honest here – so that you could sell your system to a customer and allow him to believe that there was some chance he would be able to port his programs, and that there wouldn’t be vendor lock-in.

Not all standards were born alike, huh?

So, all this is evidence that you shouldn’t take porting lightly. It’s easy to underestimate the cost or downplay the importance of porting the culture. And the technical side ain’t always a walk in the park, either.

After the initial port, you’ll need to develop, test, support, and maintain the software on two platforms instead of just the one. Introducing a second platform can effectively double the surface area for bugs to attach to. Also, once you’ve opened that door, why not add a third platform? A fourth? Are you sure it’s going to be worth it?

A colleague recently pointed me to the book Thinking Forth by Leo Brodie.

While it is heavily a book about Forth (the programming language), it’s even more a book about programming and problem solving in general. I don’t know Forth, and have no intention of learning it, but I found this book to be chock full of insight and humor which apply today just as well as they did when Thinking Forth was first published.

Among the fun parts are gems like this:

Among the pearls of wisdom, of which there are many, you can find this:

“You don’t understand a problem until you can simplify it.”

And this:

“Start simple. Get it running. Learn what you’re trying to do. Add complexity gradually, as needed to fit the requirements and constraints. Don’t be afraid to restart from scratch.”

Today, this would probably be called some sort of an agile method. I’m kind of thinking it’s just common sense.

Especially the first half of the book concentrates on universal concepts like analysis and planning, conceptual modeling, problem-solving techniques, and refactoring. This is how Brodie describes the book himself:

“We need a consistent and practical methodology for thinking about software problems. That is what I have tried to capture in this book. Thinking Forth is meant for anyone interested in writing software to solve problems. It focuses on design and implementation; deciding what you want to accomplish, designing the components of the system, and finally building the program.”

If you’re old-fashioned like me, you’ll want a dead-tree version.  The book is published under the Creative Commons license, so you can download the PDFs for free from the Thinking Forth Project website.

Thinking Forth was first published in 1984. It was around that time when I wrote my first computer program. This is certainly one of the books I wish I had read sooner.

This is a story, based on true life, on how you turn from a happy programmer into something sinister.

Stage 1: The happy creative programmer

You’re developing a new exciting product.  You’re the senior programmer in a small and talented team.  You’re responsible for a lot of the core functionalities - you get to write a lot of code and make a lot of the important design decisions. Things go swimmingly, and you’re having the time of your life.

Stage 2: The proud father

You and your team ship the first version of the product.  Despite the highly embarrassing bug in the installer, someone buys it.  You’re now spending most of your time on improvements, bug fixing, and polishing the existing features.  It’s not quite as fun as implementing all that new stuff, but still very rewarding.  It’s your baby, and you want to take care of it.

Stage 3: The product guru

You’ve ironed out the biggest kinks, and the product is selling well.  Your user base is growing, and you’re busy planning what cool features to put in the next big release. However, with the growing number of users, the support requests start rolling in. The support engineers don’t yet quite know the product, but you’re happy to help (your baby).  By now, there’s enough questions and inquiries coming your way to be a bit of a distraction, but you can still find stretches of a couple of hours or even a full afternoon here and there to work on the next version.

Stage 4: The grumpy asshole programmer

The next big version ships.  The customer base keeps growing still, and together with it, the volume of tricky problems grows fast.  The support staff is competent enough to take care of all the easy cases, so you’re left with the hairiest problems.  Since you’ve been so helpful in the past (your baby), many people have developed a habit of just coming to you when they encounter a problem they can’t immediately handle themselves.  You try to counter by producing documentation, and it helps a little.  Still, you spend an increasing fraction of afternoons with a queue outside your door.

Finally, you develop a fatalistic attitude about getting anything done.  You’re still the lead developer.  How in the hell are you supposed to get anything done when there’s someone constantly bothering you about how this-or-that works, requesting help in troubleshooting customer issues, and demanding estimates on how long it would take to add this-and-that feature?  Before, you got almost no email.  Now, you’re afraid to open your email.  In fact, you avoid opening your email before lunch just so you could get something done.  In response, people begin calling your mobile and checking by your office if you don’t answer their email in 10 minutes.  You stop even trying to code, because you would be interrupted anyway.

You stop being nice to people, hoping that they would in turn stop asking you things.  It doesn’t help, since you’re the resident expert on the product.  You throw empty Pepsi cans at people coming to your door, and fantasize about throwing full ones. You hide in meeting rooms and turn off your phone.  In the evenings, you fashion tiny phallic figurines out of Blu-Tack and stick them on product managers’ doors.   None of this helps much, but it kind of makes you feel better.

No matter what you try, you are trapped and there is no escape.  You have become the grumpy asshole programmer.

This is a breakdown of yearly expenses for one software developer (in USD), highly irresponsibly gathered from various sources on the internet.  For illustrative purposes only, parts may be missing, your mileage will vary, batteries not included.  But, I think it’s not that far from the truth.

So, what does this picture tell me?  Lots of things.

The opportunity to save on, say, office chairs is extremely limited.

You really really don’t want high turnover.  Any extra salaries you have to pay really hurts.

Spending an extra 20% on an extra nice office is worth it, if you get an extra 2% of productivity from your developers that way. That’s about 9 minutes per day.

You want to maximize the bang for the buck you get from the big fat red blob.  If you don’t give your software developers proper tools, such as two good monitors, plenty of RAM, and a proper chair, you are a raving lunatic.

What does the picture tell you?  What does it tell to your boss?  Your CFO?

Update: The references for this data:
PayScale – Software Developer Salary, Average Salaries
How much does an employee cost?
IFMA workplace study: Average space per employee
InformIT: The Cost of Managing Paper: A Great Incentive to Go Paperless!
2009 Health Care Cost Survey Reveals High-Performing Companies Gain Health Dividend
Herman Miller chairs prices (assumed to last 10 years)
Prices for monitors and RAM you can check e.g. at newegg. Assumed to last a year or two.