I really dislike MySQL. I haven’t used it in a long time, but I remember that it basically just stores all of its data in a flat text file. No transactions, no write-ahead log. In fact, there’s barely even any real data integrity. You have to run a repair process on boot to fix table corruption in the case of hard shutdown. There was an alternative thing you could do that fixed that, but it was an option, and no one had it enabled by default. You should just use Oracle.
I don’t care what database you prefer; if you know MySQL, that block quote should have you cringing. It’s not that those complaints were never true—there was a time when MySQL only spoke MyISAM, and MyISAM did remain the default for a while after InnoDB landed as a supported database engine. But InnoDB has been the default since MySQL 5.5 shipped, in 2010. That’s around the same time that Windows 7 shipped. Docker did not exist. MongoDB hadn’t yet had its first birthday. Backbone, let alone things like Angular and React, hadn’t even been invented, and jQuery was pretty much your only sane bet for a cross-browser JavaScript library.
In tech, things change quickly. Yet I routinely come across people who hold opinions based on the state of a given tool as they encountered it years ago. They hate IE because it doesn’t do sane CSS. They hate Vim because you have to script it in Vimscript. They hate Java because it lacks generics, .NET because it doesn’t run natively on Linux, and Macs because you can’t right-click.[1]
Thing is, none of these things are true today. All of these things were true, once upon a time, but they’ve all been fixed for years. They only keep coming up because people love quick jabs and assume everything they don’t follow hasn’t changed since they last looked at it.
I can’t fault people for having silos of knowledge. Honestly, that just makes sense: if you’re a Java developer, you shouldn’t have to spend time watching what .NET is doing, because you need to spend that time keeping track of what Java is doing. If you wrote off Firefox’s dev tools for Chrome’s years ago, of course it makes sense to spend your learning time focused on just what Chrome’s doing. And if you’re in an all-Linux shop, it really doesn’t begin to matter if PowerShell is or is not the bee’s knees, because you’re never going to use it, and the few times you have to deal with Windows, your stale cmd.exe knowledge will get by just fine. So far, so good.
The problem comes when people get into debates over which of two competing solutions is best. There is an overwhelming tendency to assume that, because technology $X worked in one way when you first evaluated it, then it still works that way today, while $Y, which you follow closely, has evolved considerably. Thus, in debates, people are comparing some kind of Luddite time-locked version of $X against contemporary $Y, pointing out that $Y is demonstrably superior, and calling it a day.
There are many reasons to favor one technology over another. “I had to make a decision five years ago, and the decision was right then, and it hasn’t led me wrong since then, so I’m sticking to it” is a completely fine way to make certain classes of technology decisions. I’m not arguing against that. But you can’t seriously argue for or against something in the general case based on the state it was in years ago.
I was just in a discussion in a forum[2] where someone was comparing the current version Git to an eight-year-old version of Mercurial, and finding that Mercurial was lacking.
I hope to heavens I do not need to explain on this blog that I’m a Mercurial apologist, but I will readily admit that Git 2.5.2 is better in almost every single way than Mercurial 1.4. Thing is, I could say the same about Mercurial 3.5.1 against (roughly) Git 1.7. Git eight years ago wasn’t the Git of today: newly created local branches didn’t automatically try to track remotes of the same name. Git subtrees did not exist. Many widely used flags to git grep and git log did not exist. Git didn’t do automatic garbage collection and packing. And the Mercurial of eight years ago wasn’t the Mercurial of today, either: there were no revsets, no bookmarks, no histedit, and no phases.
If you’re looking to transition, this history is irrelevant; what you care about is the current version of Git versus the current version of Mercurial—just like you should be choosing between the current versions of PostgreSQL and MySQL, not PostgreSQL 9 and MySQL 5.1. And that’s going to be a very different discussion.
I’m not saying you shouldn’t engage when people talk about what tools are best. I am asking you to think about whether you actually have recent, pertinent information to contribute to the discussion. If you used a tool eight years ago, your experience is likely no longer valid. If you used it last month, it probably is. If in doubt, reevaluate your position by trying the tool and seeing if things are still the way you remember them.
And remember: if you don’t have time to reevaluate, then you probably don’t have time to contribute a (useful) opinion, either.
Want to comment on this post? Join the discussion! Email my public inbox.