I love the Boolean data type.
True or False. Those are your choices. Nowadays, almost every programming language implements them the same. C is the only language I can remember that’s still in use, that has some extra ambiguities because True and False are actually constants that evaluate to 1 or 0 respectively. So craziness like:
(true + true + true) == 3
can ensue. I love booleans because they are unambiguous and have virtually no boundary conditions to explicitly test for. Imagine the simple scenario of passing a parameter to a method. If it’s a boolean, you have 2 test cases. If it’s, say, an integer, you have to think about things like:
- Can this value be 0?
- Is it valid to be negative?
- What happens if I cast a decimal to it?
- What happens if I pass in another Int subtype (Long, UInt, etc.)?
- Is there a maximum value?
- If I’m passing this to, or receiving it from another app written in a different language, is the precision the same?
Ick. And of course, none of it gets into the documentation. (What documentation?!) All these ambiguities mean increased risk of bugs, or conversely, more testing time (whether you’re manually testing or writing unit tests). Not so with booleans. I love booleans.
I hate booleans.
Things in the analog world are very rarely boolean, true/false, yes/no, is/isn’t. There’s a lot of “it depends”. I hate booleans in conversations. They’re limiting. They’re conversation enders, not conversation starters.
Think about some of the big boolean debates out there in computerland these days:
- (Waterfall || Agile)
- (BigTestUpFront || QAbeforeRelease)
- (LooseTypingIsBetter || NoWayStaticTypingIsTheShit)
- (Interpretted || Compiled)
- (OpenSource || IntellectualPropertyRights)
The trouble with each of these booleans in conversation is that they are polarizing.
Son, if you ain’t with us, yer aginst us!
The truth is, in the analog world, most things are actually spectrums or scales, rather than on/off switches. We’d all be wise to remember this. Each of those boolean debates going on out there are silly. Each of them really has a scale that should really be the topic of conversation.
Agile || BDUF (Big Design Up Front): is the “how MUCH should we plan before we start writing code?” scale. A little? A lot? Half way? Pick the optimal point for your context. How big is your project? How many people? Is it for resale or contract development? How likely are the requirements to change?
Compiled || Interpretted: Can we not achieve the performance benefits of compilation and yet retain the “view source” beauty of interpretted languages? Does bytecode take us close?
LooseTyping || StrongTyping: Can’t objects still be created as a “class” but support some mechanism to override their default behavior in the 2% of cases you need that, so that we can still have the benefit of Auto-completion and Intellisense in our IDE’s?
I hate booleans in conversation. We’d all be better off to be talking about optimization for context than right or wrong in each of these cases.
I bet that if we shifted to focus to scales & context and away from booleans, we’d find that the roots of the disagreements in many of these cases would be because we operate in different contexts and therefore there is no single right answer. That would enlighten us all.
