> For the record, these large libraries are going great. I’ve built numerous products that simply would not have ever been created without, say, SQL. The cost would simply have been too high. I’ve built others with libraries that the project outgrew, but it was still a big win to start with the library.
We definitely have great libraries out there. But they're the exception rather than the rule. I consider Redis and Sqlite in particular to be quite exemplary.
SQL I'm more ambivalent about. Or rather, SQL the abstract ideal is great, but I'm more ambivalent about implementations like MySQL or PostgreSQL. As I've hopefully made clear already, I consider just raw speedup for an initial implementation of an app as a poor and incomplete metric for the quality of a library. At best it's a good quality for something you can use in prototypes, not the final version you build after you throw the prototype away. (Because we all agree you should throw the prototype away, right? :) For non-prototypes you also have to take into account the total cost of ownership. I think the ever expanding wavefront of "specialization" in roles like DBAs is a sign that MySQL and PostgreSQL are a bad trade for society. People being deployed to fill in for all the numerous gotchas arising from a crappy interface. MySQL and PostgreSQL make things more efficient in the short term, but they make us less resilient in the long term.
> I think the ever expanding wavefront of "specialization" in roles like DBAs is a sign that MySQL and PostgreSQL are a bad trade for society.
That’s a sign of a maturing field. Does the proliferation of medical specialties indicate a problem? I would argue that it simply arises from the amount of specialized knowledge that one can possess and utilize efficiently.
The existence of SQL implementations allows for faster and more maintainable implementations. The set of engineers who could do what SQL allows without it is quite small. If SQL disappeared tomorrow, a thousand equivalent implementations would appear tomorrow because it delivers real value. Hand rolling queries in a general purpose programming language is a very poorly trade off. I’ve seen this sort of stuff before. It’s always a bug farm and every other engineer asks “why the hell didn’t you use SQL”?
Give it enough time and you’ll see “Redis expert” show up as a specialty.
But I don't know enough to have an opinion of medicine. I find it useful in my experience. I wasn't saying the connection between my observation and conclusion is ironclad in all situations. But I do hold the heuristic opinion in the one case I mentioned.
> The set of engineers who could do what SQL allows without it is quite small. If SQL disappeared tomorrow, a thousand equivalent implementations would appear tomorrow because it delivers real value.
How much of this argument is about idealized SQL and how much about MySQL or its equivalents? I was careful to draw a distinction. SQL the language/mindset is incredibly valuable. EF Codd thoroughly deserves his Turing Award.
You don't need to persuade me that MySQL lets us do things faster. What would really persuade me is an argument that it helps us do the right things. I think it makes it easy to scale past our level of competence.
*Shrug*. When I go to the doctor, I love finding someone who does nothing but the one thing I need. Maybe this person is a generally “less useful” doctor, but if I break my ACL I want the surgeon who does nothing but ACLs all day every day to work on mine.
> I think it makes it easy to scale past our level of competence.
This sounds like an amazing win. This is frankly what software is supposed to do.
> Give it enough time and you’ll see “Redis expert” show up as a specialty.
No opinion on what happens to Redis after Antirez left it (http://antirez.com/news/133). But I have high hopes that the versions he created will be fairly timeless and usable even a decade from now.
I wasn’t aware he stepped back. I don’t follow it closely because I don’t use it directly, though I have been very impressed by the way it’s managed to become so ubiquitous so rapidly.
We definitely have great libraries out there. But they're the exception rather than the rule. I consider Redis and Sqlite in particular to be quite exemplary.
SQL I'm more ambivalent about. Or rather, SQL the abstract ideal is great, but I'm more ambivalent about implementations like MySQL or PostgreSQL. As I've hopefully made clear already, I consider just raw speedup for an initial implementation of an app as a poor and incomplete metric for the quality of a library. At best it's a good quality for something you can use in prototypes, not the final version you build after you throw the prototype away. (Because we all agree you should throw the prototype away, right? :) For non-prototypes you also have to take into account the total cost of ownership. I think the ever expanding wavefront of "specialization" in roles like DBAs is a sign that MySQL and PostgreSQL are a bad trade for society. People being deployed to fill in for all the numerous gotchas arising from a crappy interface. MySQL and PostgreSQL make things more efficient in the short term, but they make us less resilient in the long term.