"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."
Bill de hÓra, calming a heated debate
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.
1 comment:
Along your line of "There is no One Answer", i've found it always best to state that one must use the right tool for the right job as just as there is no perfect job, there is no perfect tool.
The problem we see here in the Java versus Ruby (in this case) is more of a human social issue. We see it in religion: Christianity / Islam / Judaism vs. Everyone Else. We see it in automotive brands: chevy vs. ford, honda vs. vw, japanese cars vs. american cars, etc. We see it in clothing, and in school groups: japs vs. goths, preps vs. metal heads. Some people want so badly to belong to a group, and to enforce their specialness they dictate that all others must be trounced upon / walked over.
Why should this condition/mindset be any difference amongst computer enthusiasts? It doesn't make it right, however it seems to make sense given that the geeks of society had to put up with a bit of force separation from other groups simply because we chose to not be ashamed of our intelligence.
Before anyone gets the wrong idea that I'm intentionally separating "geeks/us" from "them" as a way of feeling special, that's not the case. A classification pushed upon others from an external source, that eventually gets claimed by the original target of said classification does not equate with the aforementioned self classification for the purpose of exclusivity. So to make a rather long story not as long as it could be just realise that the problem isn't specifically java vs. ruby, it is just an extension of the us vs. them syndrome.
On one last matter pertaining to the issue of knowing that the change you just made not breaking the world, there are answers: peer review, unit tests, regression tests, automation, procedure and above all clean disciplined design methodologies.
Eric
Post a Comment