In December, I posted about my early thoughts on Scala after using it for a short time. Initially, I thought that using Scala didn’t buy very much – the functional style could be adopted in in Java, and the syntax and libraries could be ugly.

Since that time, I’ve been using Scala almost exclusively, and I wish to revise my view: Scala is awesome.

While some of my initial thoughts still stand, particularly that Scala APIs often overuse operator overloading, much of my perception has shifted otherwise. Scala not only allows, but encourages solid functional programming principles that are difficult or impossible in Java.

Continue reading ‘Scala Second Impressions’ »

I recently read a book called The Career Programmer by Christopher Duncan. I typically don’t post book reviews unless I really love a book and want to spread the word, but in this case I felt compelled to post in order to spread the warning. I can’t remember a book I’ve hated more.

“The Career Programmer” is meant to be a dispensation of wisdom from a sage, a book that gives younger programmers keen insights from someone who has been in the industry for a long, long time. I tend to really enjoy books like this, so I picked up a copy. Unfortunately, it comes across as an anachronism, like the book time-traveled out of the mid-90′s. While reading it, I felt compelled to double-check the publication year, and was absolutely astonished that it was printed in 2006. The “wisdom” of the book is so hopelessly out of date with the current state of software development that I cannot recommend it to absolutely anyone.

Continue reading ‘Book Review: The Career Programmer’ »

There are a lot of things that annoy me in my industry: lack of commitment to writing quality code, no discipline regarding tests, and many, many more. These things irritate me, and I see them all the time, but there is one irritation I encounter that is so common that it dwarfs all others, at least in frequency.

How common is it? It’s so common that this post has been in my Drafts for about five years. What I mean is, I wrote it in reaction to someone irritating me at work, but decided not to post it because I was worried they would see it and know I was talking about them. And it’s been in Drafts since that day because I encounter it so often that any day I post it, it will be seen as a response to something that actually happened at work. There hasn’t been a break in the last five years where I could post it without at least one person thinking it was a reference to them. That’s how common it is.

In fact, I know posting even now, it’s going to look like it’s related to an occurrence this week. STFU co-workers, I wrote this shit ages ago.

Anyway, what I’m talking about is developers refusing to do things or complaining about doing things because they distract them from what they call “Real Work.”

Continue reading ‘Getting “Real Work” Done’ »

Whenever people start talking about NP-Complete problems, or even NP problems, one of the first examples they reach for is the classic Traveling Salesperson Problem. TSP makes sense because it intuitively can’t be solved quickly due to how difficult the problem sounds, so it’s reasonable for people to use it in discussions about P versus NP.

The problem is, 99% of the time people discuss Traveling Salesperson being NP-Complete, they are wrong. The Traveling Salesperson Problem, as it is usually described, isn’t NP-Complete at all. In fact, it’s not even in NP.

Continue reading ‘Traveling Salesperson: The Most Misunderstood Problem’ »

I love Test-Driven Development, but I’ve found that there are a number of different ways people actually do TDD in real-world projects. Over time, I have discovered that I have a particular way of working that I prefer above all others, and I would like to describe it.

Imagine you are writing some software that will have a number of interacting components. I’m going to suggest a toy example, one that will help illustrate what I’m talking about, but is not so complex to actually warrant it. Imagine you are going to write a Lottery game. Players will have lottery tickets, and they will listen for Callers to read out the winning lottery number (think Observer pattern). The Callers will use a Hopper with numbered balls, selecting the appropriate number of balls and then calling out the winning number at the end.

To follow the Single-Responsibility Principle, you think your game will probably have three classes:

1. The Hopper – this contains all of the numbered balls and, when asked, returns one to the caller (removing it).
2. The Caller – once the lottery has started, this will ask the Hopper for numbers and call out the final sequence of numbers to registered Players
3. The Player – this will observe the Caller, listening for numbers to be called and determine if he is a winner by comparing the numbers to his array of numbers (given at construction).

The Player is going to interact with the Caller, and the Caller is going to interact with the Hopper.

Continue reading ‘Need-Driven Development’ »