Hacker News Reader

Comment by paulddraper | Hacker News Reader

> SQL is bad, for two reasons:

> 1. The syntax is bad.

In this context, "bad" means "hard for a computer to parse." And this statement is 100% true.

Though from a human perspective, the syntax is relatively fluent.

Which would would you (as a human) prefer for writing raw ad-hoc queries? SQL or MongoDB? For me, it's no contest the former.

> 2. Type checking is absent.

PostgreSQL complains at me if my types are wrong.

E.g. if I try to sum two strings.

View on HN

How is SQL hard for a computer to parse? SQLite can parse its flavour of SQL using a plain old LALR grammar and that covers a lot of SQL.

And even if it was, how does having an ORM generate the SQL behind your back change anything for the computer that still has to parse SQL?

I suspect what is really meant is that it is time consuming to write a parser that encompasses all of its syntax, not that it is performance intensive or is high on the Chomsky hierarchy.

But, at least for SQLite, the parser is autogenerated from a plain grammar.

It's not so much the parsing... it's the validation against an underlying data source. I can write `SELECT A, B from Foo` and it's "valid SQL" but that doesn't mean the underlying Foo table exists, or that the columns are there. Beyond this, that doesn't mean it understands that A should map to an Int32 or that B should be a UTF-8 byte array in the outer language I'm working with.

Personally, I'm fine with the likes of type mappers like what Dapper in C# does, or serde_postgres offers in Rust. For that matter template string processors in JS/Node/Deno are also really nice. Yeah, you need to understand the underlying data source, but that's often far easier than massive amounts of boilerplate.

I'm not sure about SQLite, but try looking for "PostgreSQL parser".

It's far from simple.

It's hard to compose (you could call it metaprogramming maybe, since you're writing SQL programs with a program), too.

You know the problem: take this query but with this extra table joined and this other condition in the WHERE clause.

Solutions exist, but they mostly are married to ORMs, thus the frustration. But I'm confident that "either raw paleolithic SQL or clunky ORMs" is a false dichotomy (and I've written a thing in PHP over a decade ago to scratch my own itch and compose SQL, so I just know for a fact how false it is).

The author mentions prql as an alternative to sql in the post. I personally find prql much more fluent than sql.

Reply on news.ycombinator.com