Java is the right answer to the wrong question, Ruby is the wrong answer to the right question
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.
Can we please stop calling each other silly names over the languages we choose and move on to calling each other silly names over our choices for writing literate programs, eliminating redundancy, decoupling modules from each other, and so forth?
The very next time you find yourself being drawn into a debate about Java vs. Ruby, try saying something obscure, such as, Java is the right answer to the wrong question, Ruby is the wrong answer to the right question
and see if you can redirect the energy towards exploring new ground instead of stagnating in the same old tired place.
Do not follow in the foot steps of the Sages. Seek what they sought.
When we argue Java vs. Ruby, or testing vs. type checking, we are arguing about foot steps. Take the debate to the next level. What is it we are trying to accomplish with those features? What are we seeking?
My favourite example of this is the subject of automatic refactoring
. My current text editor doesn’t perform automatic refactoring (ducks). Are you about to blast a flaming comment or perhaps an entire blog post explaining what a dunderhead I am for not using an IDE that can move a method with a single dialog box?
Stop for a moment. Why
do we move methods? What are we trying to accomplish?
What is it about our code after we have refactored that makes the code better? Now you have a really juicy comment to make, a deep and insightful point of view to bring to a discussion. Let’s talk about that quality of good code first, and then we can talk about how to get there later, if ever.
So the next time you read that “Strong, static typing is superior because it enables the IDE to provide automatic refactoring support,” take a deep breath. Don’t nod and agree. Don’t shake your head and disagree. Ask a polite question: What are we trying to accomplish with automatic refactoring?
And when told that “Unit tests are superior to compiler type checking for catching bugs,” don’t settle for “catching bugs” as axiomatic. Ask what quality really
means for code.
Nothing is going to save us from talking ourselves to death
. But at least we can debate at a higher level of abstraction.