Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Thanks for the mentions of IMS and QUEL – I didn't know about them.

I guess the main point I disagree with you here is about "dynamic ecosystem filled with competition". I totally agree that SQL won the battle of dominance, and that's the main reason why SQL stays popular and not so much competitors even emerge (sorry, MongoDB query language is a joke).

Take QWERTY as an example. It's been proven countless times that it is suboptimal layout. It was designed with suboptimal trade-offs and with different goal in mind (minimize jamming of a typewriter). But it got it success and become dominant because of commercial success of typewriters with this keyboard layout. The rest is a pure network effect.

So when I read your comments on SQL I hear something like "QWERTY is objectively the best layout, because nobody managed to dethrone it in a highly competitive settings, and because I type 800+ chars per minute with it". So that's true that SQL is dominant, but is it objectively the best we can do? I don't think so.

Also, what's your experience with EdgeQL? I know it's a layer on top of existing SQL, but I had incredibly positive experience with it (after 20+ years with SQL). And I can totally see it as a standard for data query by itself. I would love to have something serverless like EdgeQLIte, in fact.



First of all you might want to refresh your memory on the QWERTY layout. As it happens, in grad school a group of us bought into the Dvorak myth, and spent several months retraining on Dvorak. We didn't see great results. And then by chance one of us ran across https://reason.com/1996/06/01/typing-errors/ and we realized that, based on research we had not known existed, there was in fact every reason to believe that QWERTY is superior in practice to Dvorak.

And this brings us to the subject of network effects. It is easy to see, and experience, that network effects are real. And certainly they contribute to why existing networks dominate, and alternate ones struggle. However, on multiple lines of evidence, network effects are far smaller than people suppose. In fact they scale as O(n log(n)), see http://www.dtc.umn.edu/~odlyzko/doc/metcalfe.pdf for multiple lines of evidence supporting that estimate. This is a big barrier to getting modest adoption. But if a better technology gets there, it isn't a barrier to dethroning the leader. And so, despite network effects clearly favoring Perl at the dawn of the web, Perl got overtaken by PHP got overtaken by node.js got overtaken by Python. Lock-in to popularity is clearly less of a factor than it may seem. (And none of those technologies actually went away. It is likely that more people program in Perl today than in 1998.)

And there are no shortage of potential competitors out there. The number of query tools that I have had to learn and use is a testament to that. And, just in case I needed more evidence, you bring up another. As it happens, I have not used EdgeQL. After reading a bit about it, I'm not sure why I'd want to. But if it gains any popularity, then some day I'm sure I'll have to.

But looking at it, I'm reminded of a fact about programming languages. The perfect is the enemy of the good. Different people have different notions of what perfection looks like. And therefore attempts to create a perfect system inevitably splinter into a million fragments, none of which can gather the critical mass to overcome network effects. Look at the history of Lisp to see this in operation.

And yet the best ideas do tend to emerge. Back when I first learned JavaScript, closures were a weird feature that books didn't even want to try to explain because programmers wouldn't understand them. (JavaScript has them because it was created by a Lisp hacker.) Today they are considered standard, and even languages like Java have been forced to add them.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: