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

SQL is the most WTF notation/language I've ever seen... How the hell did someone start from the beauty of relational algebra and end up with the this misordered confusing and verbose abomination that we've all standardized upon?!

...even Mongo's JSON-based query language has more elegance to it. SQL seems designed on purpose to be annoying to write, hard to read, and never look like anything, not the math logic, not any query operations that could ever be executed. I may be superficially similar to English, but English is horrible, why would you model a notation after that?!

Everytime I see someone yelling that Haskell or Lisp syntax is weird and unintuitive I think they need to have their face bashed into a printout of a complex SQL query!



I suspect you're asking more figuratively, but I saw this PDF from Stonebraker on the developer of databases and query languages that literally answers your question[0].

I've always done data heavy work, but as a recently hired data engineer, I'm really diving deeply into this layer that previously I had taken for granted. In doing so, I find SQL highly expressive and beautiful for data work; much moreso than Python, my other primary language.

Which languages do you feel manipulate data beautifully?

[0] - https://people.cs.umass.edu/~yanlei/courses/CS691LL-f06/pape...


They all suck. C#'s Linq seems cool but I don't live in that ecosystem. Also Cypher fro graph DBs or better still Gremlin are nice and more elegant.

But I'd just want to write code like:

    (employees * addresses)[employee.name, address.city.name]
    | filter{address.city.name = "London"}
...that would match rel algebra notation nicely, and extend to complex cases more like:

    ( employees e *{e.id = a.employee_id} addresses a )
    | filter{a.city.name = "London"}
    | [e.name, a.city.name]
...you can replace operators with words of course. Or you could represent this as a JSON structure, even better imo. But the point would be to have a notation highlighting the idea of a "product", of restricting and specializing that product or specifying how it's made, and of indexing into its fields. The way I see it in my mind is like taking "a (maybe generalized) cartesian product" of different things, then filtering this, then zooming on each dot/point/object and filtering its fields etc. And obviously focusing on piping/chaining stuff.

Maybe the notation I suggest is not a good one, but I'd care more about making the concepts obvious and readable and composable.


hah. famous last words. SQL is beautiful. I allows non-developers to actually work with data in ways more flexible and extensible that most notations/languages out there.


Who? I've done so many "can you write a query that gives me all the foo bars where so an so" for managers, cs people, or even data analysts, that it makes my skin crawl. Sometime they know how to load that data into Excel and do their magic there, but with SQL, anything that's more complicated than a simple select from a single table, forget about it.


I have designed/given internal SQL classes to business analysts, product managers and similar.

From simple selects using some common functions and basic types, to filtering, to aggregations and grouping and finally joins. That gets them about 80% there for the kind of information they want ad-hoc.

Only with joins did the people really struggle for some time.

In my opinion the distinguishing factor wasn't the language, but the peoples willingness to learn and ability to apply it in practice on a somewhat regular basis.


IME, third line support staff for a start.




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

Search: