Tuesday, October 2, 2007

Why so passionate? Can't we all just get along?

OK, this might seem a little silly but I have now seen at least three separate posts on the very same topic. It all started with this post over on raganwald: Java is the right answer to the wrong question, Ruby is the wrong answer to the right question which opened up with a quote.

"Large code bases are the problem, not the language they’re written in. Find a way to break/decompose big code bases into little ones."

Which addresses a topic that comes up a great deal. This quote is used as a jump point to discuss the ongoing silliness that we all seem to occasionally get mired in, which is a discussion of why one language is bad and another good... or in some cases why a particular feature of a language is bad and another feature in a different language is good.

What if There is no One Answer to the question of which language to use, or if static typing is better then good unit testing? Is it really so hard to grasp that one should use the right tool(s) for the job at hand? As a for instance, if you were building a deck on your house you might pick supplies for that project that you like but you would balance that choice with the needed strength to make sure the deck does not collapse after it is built. Why does the discussion of things like Java vs. Ruby and Static Typing vs. Unit testing always have to break down into a feces throwing match?

Lastly Bejamin Stein asks How confident are you, the programmer, that the change you just made will work? In my opinion this is a sub question that SHOULD get asked after the correct tooling has been chosen. As a programmer I have a desire to know that my change isn't going to effect the world, lots of tools can help me with this (not the least of which is a simple grep). I would also hope that my chosen tool for a project can help me with knowing what a change may effect but that may not always be true because of the type of project or type of tool chosen. This question may also only apply to larger (i.e. Medium to Large) projects with multiple people because knowing your change doesn't effect everyone may reduce work someone else has to do making the teams you work on faster as a whole. If I know it is just me writing the code for me and no one else I may not care if I effect the world because in the end I have to fix it anyway.

All I want to do is get along - Choose the right tool for the job at hand, and have some good support as to why that tool was chosen. Be it statically typed, dynamically typed, easy to write a unit test for - or not so easy. Different projects, different tasks, DIFFERENT tools, perhaps even a DSL tossed in for good measure.
Post a Comment