Strongly-Typed Thinking

In computer science, we talk about programming languages being strongly- or weakly-typed. A strongly-typed language insists that variables be of one type: an integer, a floating-point number or a string. The stronger the typing, the less tolerant the language when you use the “wrong” type. At the extremes, a strongly-typed language might reject arithmetic between an integer (e.g. 13) and a floating point number (2.40). A weakly-typed language will offer some implicit type conversion. PHP, our language of choice, will do its best to promote strings of text into numbers if you write code that treats the value like a number (e.g. “2abc” + 3 is 5).

This strong typing concept can be anthropomorphized like so. The strongly-typed language sees that you declared that variable as an integer. When you ask it to add it to what’s obviously a floating-point number, it stops everyone and declares your entire program broken. For example, Java might declare smugly, “Type mismatch: cannot convert int to short”. In it’s way, it’s being helpful. The rules are the rules, not to be broken.

In contrast, PHP might look at your mixing of types and do its best to sort out what you mean. “Oh, you must mean to treat that text like it’s a number,” it thinks. It adapts to context and provides the answer you most likely wanted. To be sure, in the realm of language design, there may not be one right answer. They are both valid approaches, although I don’t miss keeping track of elemental types myself when coding in PHP.

But have you ever noticed programmers can be strongly-typed or weakly-typed, too? Some programmers seem to have a thousand and one commandments inscribed in their mind’s programming bible. “Functions should have one way in and one way out,” they recite. “A function should only do one thing,” as they explain why they wrote nine different functions, each with only one line of code.

You will recognize these programmers when you propose a solution that violates their dogma. They will describe a terrible catastrophe, but will be unable to explain exactly why. Keep pushing them, and you might feel like you’re talking to a village elder. “This is the way we write code because that’s how our fathers wrote code, and their fathers before them,” they explain in reverent tones.

For me, the joy of coding is considering the whole of the context. We have guidelines, design patterns and experience–all to help us solve problems. I also like to think about the programmers who might come later to read and update my code. I like to imagine those programmers of the future are smart, smarter than me. I don’t assume they are like children who need strict rules. I don’t even like treating children that way.

The trouble with dogma, in programming or elsewhere, is that it drops context. It begs you to follow rules for their own sake rather than the reason you’re coding in the first place. I’d rather stay weakly-typed and keep routing around the slow nodes.