|Perl: the Markov chain saw|
Re^2: [OT] Why I don't use Mysql for new projectsby moritz (Cardinal)
|on Jul 10, 2008 at 14:50 UTC||Need Help??|
You say that MySQL has solved problems but you won't count it because it's not the default?
No, I say that solutions of these problems aren't as valuable as they could be if they were default.
Discovering glitches and then finding that they have already been solved but that I didn't know about these solutions, always leaves that nasty feeling that I'll come across more of those.
Sane defaults are important. Very much so. The Postgres 8.2 manual has about 1700 pages (A4), I'd expect mysql to have about as much documentation. You can be sure that I won't read them all before starting to use my db engine. If the defaults can easily hurt me, I'm lost.
The reason it's not the default is that people expect to be able to upgrade from older versions without having to change their code. I think this is a fair expectation.
Yes and no. Backwards compatibility is valuable, but it shouldn't be the first ruling principle. When our notion changes of what is sane and what not, we sometimes have to break something. Perl does that from time to time as well.
If you really care about compatibility, you can define a set of options that can be activated with a special variable or flag, some kind of a compatibility level.
Update: consider an analogy: if you had the choice between two programming languages, one being perl, and the other being strictperl, that is perl with use strict; use warnings; enabled by default - which one would you use? I'd stick with perl for my old scripts that aren't strict safe, and chose the strictperl version for everything that I newly write.