Not Very Much About Primitives

According to the schedule I should be sending out a newsletter about the Primitive Obsession smell. But that newsletter would be a near-exact copy of last week’s blog post Replace Data Value with Object, since the smell Fowler & Beck are talking about is the same smell that is fixed by that refactoring pattern. If find yourself passing around a lot of primitives (e.g., integers, strings, etc.), then extract those suckers into objects. End of story.

Instead of talking about Primitive Obsession, I’m hoping I have something interesting to say about the kinds of knowledge you need to refactor effectively. Will it be interesting? I make no promises.

Recently I started learning Haskell. And while I’ve been able to write some Haskell code that works (mostly), I find that I have no idea how to refactor it.

Refactoring, I’m finding, requires two different types of knowledge. First, you have to learn how to spot problems. For this you can use intuition, code smells, design heuristics like SOLID, and so on.

Once you spot the problems, that’s when you use the second type of knowledge: how to write code.

The two types of knowledge don’t really overlap. The first is largely applicable across languages. Bad variable names, overlong methods (or functions), etc. – these can plague code in almost any language. So I can look at my Haskell code and say, “Gee, that function is doing way too much.”

But the next step, actually refactoring the code, requires you to actually know the language you’re working in. Yes, I need to break that function into smaller functions. But…how do I do that again? Yes, my code is clearly duplicating knowledge. But all my attempts to extract it lead to a compiler error. And so on.

All of this is to say something that everyone probably already knows: you’re going to write terrible code for a while when you learn a new language. That’s fine. Everyone is a beginner when they start a new language.