Hacker News Reader

Comment by sanderjd | Hacker News Reader

> It should be possible for an amateur to quickly write an SQL validator as a starting project

...why? SQL has been wildly paradigm-definingly useful for decades. It has driven hundreds of billions, perhaps trillions, of dollars of value. None of this hinges on the ability for an amateur to be able to write a validator for the language. It just seems like such a non-sequitur to me, such a strange thing to call out as a criticism.

SQL hasn't been wildly successful either because of or despite its syntax, it has been wildly successful because organizing data in the relational model and querying it declaratively is extremely powerful. The syntax is just not the interesting part. Any syntax that meets those criteria would do.

View on HN

I second this emotion SO HARD. Is sql weird? sure. But (IMO) the hard part implementing|using a sql database is _not_ the syntax, it's the storage, query planning, consistency. Don't like SQL? use linq or one of the bazillion DSL libraries that "compile" to sql. SQL databases are so unbelievably extremely useful, and the minor syntax quirks between different DBs are a minor issue compared to the huge amount of commonality that they share.

Also FWIW, I'm not sure that writing a sql validator _is_ all that hard. The grammars for any dialect are readily available and really not so hard to turn into an AST with any of your favorite tools (ANTLR, lex/yacc/bison, any of a million PEG parser generators). In many cases you don't even need to, we do static analysis of spark SQL using their own parser, for postgres can use the parser straight out of libpg.

I guess the OPs point is that if you can validate it easily, you can understand it. I'm certain I could write a lisp parser in 10 minutes, but I don't think that would mean I immediately understand all Clojure code (which is often pretty obtuse). You still need to learn all the underlying concepts and data structures.

Your last paragraph is non sequitur. It is perfectly possible for the syntax to not be the interesting part, and for SQL to have been successful despite bad syntax. The underlying idea is brilliant, so the first syntax that exposed it sufficiently well got baked in as a path dependency, even though the syntax sucks.

The point I was trying to make was just that the syntax was irrelevant; it was neither a major advantage nor hindrance. I think this is the same as your point.

One thing I have experienced is that often times developers are coming from a world of object oriented programming, or just coming from a JavaScript world.

Then often the storage and retrieval of data is an after thought during the development of an application. This is definitely true for CRUD apps. Then maybe the person used a framework to handle database interactions and now after a year or so, it’s not scaling well because the data access was not really given priority during development. So then the problem is the database engine or the syntax instead of proper design and planning.

That’s not to say there are no drawbacks to writing most dialects of SQL. I just believe most of the hate over SQL is coming from a procedural mindset to a relational one.

> It should be possible for an amateur to quickly write an SQL validator as a starting project

I think the point he is trying to make here is the same as the post was making concerning orthogonality. Having a smaller set of special syntax, and therefore an easier validator to write, means easier queries to write for the user. I don’t think he was implying that everyone who makes use of the language should know how to write a lexer for it.

> The syntax is just not the interesting part. Any syntax that meets those criteria would do.

I have to disagree with this. If this was the case we would still be programming everything in BASIC or C because they’re just another imperative programming language and it gets the job done. Having sugar syntax, a consistent language, etc.. all makes it easier for a programmer (or data analyst) to get the job he needs quicker (and therefore reduces cost), makes a program easier to maintain, and so on.

The syntax is not the interesting part for programming languages either. Programming languages now have better semantics - things like runtimes, concurrency, data encapsulation, etc. - in addition to better syntax. SQL is not a programming language, its semantics boil down to the relational model. Don't get me wrong, there is room for improvement in the syntax, I have plenty of gripes with it, I just don't agree that it is a fundamental problem. It's already super useful as it is.

Indeed semantics is what matter but I think for example lack of composability is semantic problem too.

<snarky> Ability to manage persistency and correctness of SQL engines is very usefull while language interface not so much. </snarky>

>It has driven hundreds of billions, perhaps trillions, of dollars of value.

The same can (almost) be said for Javascript. A language with a lot of foibles can still be successful if it is the only realistic mechanism to interact with the system.

No disagreement from me there! Though I personally like SQL more :)

>> It should be possible for an amateur to quickly write an SQL validator as a starting project

> ...why?

I don't know about amateurs, but if the typical intended user of the language does not have a good grasp of what is and is not valid, they will often be reduced to trying one thing after another until they hit upon something that seems to work, with no real understanding of what it does. This is not how robust, correct software is written.

That seems like a completely different point. (Unless I misunderstand what a "SQL validator" is, which is definitely possible.)

I do think this way of utilizing SQL is a problem, but I would lay the blame for it at the feet of a lamentably widespread anti-intellectualism in the field. It is true that the relational model is not trivial and must be learned before SQL makes much sense. But it is not too much to expect from someone who wants to be a practitioner in this field.

I agree that someone who wants to be a practitioner in this field should understand the relational model, but the issue here is that SQL introduces inconsistencies and complications that are not inherent in the relational model, and, to some extent are avoidable. A justifiable emphasis on professionalism does not absolve SQL of these faults and does not render irrelevant attempts to find better language choices.

Sure, I don't disagree. My point is that the perfect is the enemy of the good, and SQL is the good.

Reply on news.ycombinator.com