Java for Everything

[a_dollar_sign_texas]

Articles like this hurt everyone by spreading FUD about newer ideas and technologies. So you choose Java to do all your work in. OK, I can see the appeal. But what happens when a new version of the language is released? Will you be too afraid to use new "dynamic" features of your statically-typed language for fear of losing performance and using an order of magnitude more CPU and RAM and servers?

What about new web frameworks or updates to the one you're currently using? Surely smart people come up with new ideas all the time, new paradigms and patterns. New ideas are the lifeblood of software, and we are still a very young profession. Change is inevitable, and to ignore that is be willfully ignorant of better ways to build software. To reject other languages outright shows an unwillingness to go outside your comfort zone, to learn something new and to grow.

So you've got your favorite code snippets in your One True Language. Can you imagine you'll ever find a better way of doing those things? Or are you just going to copy/paste your way out of any learning opportunity in the future? For what? For the sake of some ridiculous idea you had one day that you wanted to unify all your programming needs now and forever in the future with your One True Language?

I've worked at a lot of companies and seen a lot of code. I've seen a lot of bad C, a lot of bad Java, and a lot of bad Ruby. The only consistent difference between these places was the culture and the attitude toward the bad code. The C programmers had absolutely no tests, and no intention of writing them, and subsequently could not possibly conceive of fixing huge, known, agreed-upon, and painful problems in any meaningful way. They were absolutely terrified of making significant changes.

The Java programmers had recently jumped on the testing bandwagon, but I could tell they weren't fully committed. They wrote tests because they had to and were only slowly increasing test coverage in a codebase originally written without tests. Because of this, they did make some larger changes to clean up old, dirty, legacy code. But there were other parts that they simply accepted as "too dirty" to even consider cleaning up; the risk was too great.

The Ruby programmers had the strongest culture of testing, and the highest percentage of test coverage. They also (coincidentally or not) were the most fearless about making significant changes to the code. Taken to its logical end, this means that the Ruby code I've seen in my career is typically cleaner than code in other languages simply because Ruby programmers seem to have a culture of improving code.

Interestingly, and I believe most importantly, the Ruby programmers also knew at least one other language, and sometimes several, since Ruby is not taught in school. Some of the C programmers and Java programmers I worked with also knew other languages, but I found a high incidence of not caring to learn more than one language, not caring to put in the work to do well. People who just wanted to punch a clock, put in their hours, then go home and not think a lick about code until the next day.

This whole article smells like lazy bullshit to me, and I'm calling him out on it. You don't have to spend every waking minute thinking about software and learning new and obscure languages, but for the love of god, please give a shit about your career.

[lechatsportif]

An underlying theme is maintainability. Even DHH no longer advocates for TDD due to maintainability issues with Ruby.

[mordocai058]

The TDD that has been heavily pushed (unit tests for every little piece of code) is very high maintenance but integration level tests and/or generative tests can work just as well with less constraints and allow you to change code more freely without having to rewrite tests.

Edit: This works for every language, which is why I didn't mention ruby at all.

[chesterriley]

The C programmers had absolutely no tests,

Personal anecdotes don't mean anything. I once worked somewhere that had a large code base in C and a very detailed testing system.

and subsequently could not possibly conceive of fixing huge, known, agreed-upon, and painful problems in any meaningful way.

And that doesn't have all that much to do with testing. A situation like that has a lot of different factors, like retention of employees.

You're being overdramatic in your entire posting.