What’s the opposite of Functional Programming?
… Dysfunctional Programming? Alright it’s just a joke, no mailbombs please.
I do think that it’s fair to say that our industry has gradually grown more and more impatient with side-effect-driven programming models. That’s not to say that classical OO-designs will all be failures, they can and do succeed often enough — successes being directly proportional to the project’s unit-testing commitment. I think the power of coupling state with logic slides into hopelessly error prone apps a lot sooner than most of us expect.
Which brings me to a bad code smell I’ve noticed; I call it The Car With No Body. The reasons you’ll often hear for these type of ‘designs’ are because
- you can easily reach in and swap out different parts of your car, often while it’s running (neat!);
- it’s really easy to wire up anything to anything else, so new things can be added really fast. Cigarette lighters in the kiddie seats! A coffee grinder in each armrest! DVD-player controlled via the gearshift!
The problem here would be obvious with a car, but is maybe less-so in software. As the list of side-effects increases, the rate at which you can get things ‘kinda-working’ actually increases, but also the amount of effort to make them ‘really-work’ (without nasty bugs, edge cases, unexpected behavior) gets more and more arduous.
When sifting through that list of side-effects for the unwanted kind gets difficult for the people who built the system, how do you think it will be for new hires?
January 30th, 2008 at 3:56 pm
I’m shocked Ken! What happened to “Frankly Jimmy, I don’t give a damn?”
I agree with your complaint, but I think it’s too sweeping to reduce all of those problems down to side-effects or “side-effect oriented programs” (although you’re absolutely right that any side-effect makes it harder to reason about and understand a program).
Your “Car with no body” ‘anti-pattern’ is a perfect description and (I think) stands on its own with no mention of side-effects as a damning indictment of the worst practices in our business. It’s probably a pretty good indication that the authors are missing the need their software has to fill and are just hedging their bets (”What do you mean it doesn’t do what we need? It can do anything! And surely your ’something’ is a subset of my ‘anything’!”).
But functional programmers are just as prone to acting like you-know-who, as this great page shows:
http://www.willamette.edu/~fruehr/haskell/evolution.html
January 30th, 2008 at 4:12 pm
Dear Shocked: It’s funny, shortly after I blogged the idea I realized that I could imagine commiting the exact same sin that I’d blamed on OO purely via dastardly cascades of events passing around ‘dumb data’.
But by then it was too late to rewrite the whole premise, and frankly Jimmy, I don’t give a damn!
January 31st, 2008 at 1:28 pm
I’m awed! I say we lump the cascading events people with the side-effect-using armrest coffee grinder people and indict them all.
I’m only half joking. I think programs are hard to understand and debug in proportion to the number of states they can be in, and the complexity and indeterminacy of the events causing state transitions. I think side effects and cascading events are not so much similar sins, as sins that multiply each others’ effects.