.. as important as a programming language. So why bother? The agnostic coder doesn’t need to choose. He is at one with all languages, algorithms, and paradigms. Why? Because very few of these things actually matter. The language used is irrelevant. The paradigms shift and change like the seasons. The algorithms can always be improved, even if the mathematicians would have you believe otherwise.
So what is left?
What’s left is knowing what tool to use and when to use it. Knowing the right algorithm to use and why you’re using it. These two things are what matter most. They transcend the paradigms. They exist in each new language that is created, because they are ingrained into all languages. And yet no language encompasses all that you need to know about these two things.
Why do they matter?
The right algorithm to use is always going to be one of personal choice. “What?”, i hear you cry, “Surely the best algorithm is the one that works quickest”. Not so my impatient friend, not so. The right algorithm is the one that fits into the program neatly. It fits like a jigsaw piece. It makes the code around it feel complete, not forced due to speed or efficiency. Flow matters. And the right algorithm does not impede the flow, but gently helps the flow continue, never hurrying, never waivering, never stopping it.
“The right tool for the right job” is a truism is all professions, from the humblest of plumbers to the loftiest scientists. But what is the right tool for coding. That depends on the code to be written. But do not fall into the trap of the inexperienced coder. Examine the task first, then choose the tool. A carpenter who wants to carve a table leg has to know what chisel and mallet to use, but he needs to know what the finished table leg will look like first, lest the table leg become a matchstick.
Choose your environment well. Ask others what they would choose. But don’t be afraid of making the wrong choice. Good choices come from experience. Just like the experienced carpenter will better know which saw to choose, the inexperienced carpenter has to learn.
Only after you know what you’re going to build can you choose your language. However, the choice of language is not as important as how expressive the language will let you be. An artist could easily paint a blue sky on his picture with a painters roller, but he’ll be more expressive with a much smaller brush. Some languages are restrictive, other not. However you can only be expressive in a language you are comfortable with. If you’re comfortable with a restrictive language then use it, if not choose a less restrictive one, a scripting language, or whatever you feel happy with. Whatever you choose do not fall into the two most common traps. 1) Languages wars. 2) Using the same language for everything. Each language has it’s own merits. It’s own set of good and bad. It’s own idiosyncrasies. Some are well known, others not. Use each language for what it’s good at.
Do not fall for hype about a new language. The success of a hyped language is always outweighed by it’s inability to deliver on hyped promises in a few years time.
Each language is good in it’s own problem domain. Make sure you know your problem domain before choosing a language, and play to that language’s strengths. But embrace the weaknesses as well. Get to know the weaknesses of every language you can. This will help you decide which language to use much more successfully than believing you know what a language is good at.
In essence, be patient, know your problem, and choose your tools carefully. But remember that a rusty chisel is sometimes better that no chisel at all, but if you’d thought about it beforehand you’d have gone and bought a new chisel wouldn’t you?
