undefined | Better HN

0 pointsjoe_the_user1y ago0 comments

It's very familiar to anyone who knows how to read it.

"Anyone who know the system can easily learn it" he said with a sniff.

Yes, the similarity to Prolog lets you draw on a vast pool of Prolog programmers out there.

I mean, I studied a variety of esoteric languages in college and they were interesting (I can't remember if we got to prolog tbh but I know 1st logic pretty well and that's related). When I was thrown into a job with SQL, it's English language syntax made things really easy. I feel confident that knowing SQL wouldn't oppositely make learning Prolog easy (I remember Scala later and not being able to deal with it's opaque verbosity easily).

Basically, SQL syntax makes easy things easy. This gets underestimated a lot, indeed people seem to have contempt for it. I think that's a serious mistake.

0 comments

5 comments · 2 top-level

jyounker1y ago· 3 in thread

> Basically, SQL syntax makes easy things easy. This gets underestimated a lot, indeed people seem to have contempt for it. I think that's a serious mistake.

The flip side of that is SQL makes hard things nearly impossible.

SQL doesn't have facilities for abstraction, and it doesn't compose, and this has consequences that I deal with daily.

The lack of abstract facilities makes it hard to construct complicated queries, it makes it hard to debug them, and it makes it hard refactor them.

Instead of writing more complicated SQL queries, developers lean on the host languages to coordinate SQL calls, using the host language's abstraction facilities to cover for SQL's inadequacies.

joe_the_userOP1y ago

The flip side of that is SQL makes hard things nearly impossible.

What about SQL syntax makes the hard things possible? I get that the actual language SQL is broken in all sorts of ways. But I don't see any reason to replace it with some opaque from get-go.

I mean, what stops you from defining, say adjectives and using those for rough modularity.

Say

    EXPENSIVE(T) means T.price > 0;
    Select name FROM books WHERE EXPENSIVE(books);

Seems understandable.

geocar1y ago

Isn't that just WITH?

    WITH expensive AS (SELECT * FROM books WHERE price > 100)
    SELECT name FROM expensive

jyounker1y ago

Yes, you can extend the language with more syntax. This kind of proves my point.

If there weren't deficiencies then you wouldn't need to define more syntax, and so many work-arounds wouldn't have already been created. The deficiencies in SQL are why each big SQL database ends up creating some procedural-SQL language for use in stored procedures and triggers.

CTEs are close to what you outline above, but even then (as far as I know) you can't name that CTE and use it across multiple statements.

aseipp1y ago

I mean, yes, that's sort of how linguistics works in general? You can't just look at a language with completely different orthography or semantic concepts and expect to be able to reliably map it onto your pre-existing language with no effort. That's sort of the whole reason translation is a generally difficult problem.

I don't really get this kind of complaint in general I'm afraid. Many people can read and write, say, Hangul just fine -- and at the same time we don't expect random English speakers with no familiarity will be able to understand Korean conversations, or any syllabic writing systems in general. Programming language families/classes like logic programming are really no different.

> it's English language syntax made things really easy

That's just called "being familiar with English" more than any inherent property of SQL or English.

j / k navigate · click thread line to collapse