[sherburt3]

Strongly disagree, complete newbies can get up and running with SQL very quickly and it's expressive enough that experienced people can do things that no ORM would ever hope of being able to do. One criticism I have though is that whoever thought "SELECT" should come before "FROM" should be fired.

[Mutjake]

I sort of feel the same…but on the other hand if you consider ”delete from” exists also, it’s not completely unsensible to consider you first tell what operation you’re about to perform to the data. Would be nice to start with the source entity name for sure. Dunno what ”select 1” would look like, I guess the from foo would be optional.

Random saturday ramblings, sorry about that :-D

[williamdclt]

DELETE FROM is even worse. Accidentally/mindlessly press cmd+enter before you wrote the WHERE? Poof, data gone. Make it FROM … DELETE!

I also wish we needed to explicitly take locks. In PostgreSQL at least (I think other dialects/engines too), figuring out what operation will take what lock and potentially mean downtime is left as an exercise to the reader. Force me to write WITH EXCLUSIVE TABLE LOCK when I add a non nullable column with a default!

[ndriscoll]

If you're going to run commands that modify data directly on the cli, do it in a transaction so you can roll back. Also, start with `--` to make it a comment. Once you have the correct query and someone's checked your work, go back to the beginning of the line and remove the `--` so you can run it. It's also a good idea to write a select * or count first to check that things make sense, and then start your transaction, go up and modify your select into a delete/update, check affected rows looks good again, maybe do another select or two to check that data looks like you expect, commit.

[Izkata]

Fun fact: if you still have a MySQL (MyISAM) database, the transaction commands return success but don't actually function, so you can't roll back.

[Mutjake]

Well, to be fair ”from foo delete” would do the same I suppose :-D Unless there’d be an explicit end to the statement to designate you really want to delete everything. Which might not be a bad idea. Or make ”where …” mandatory and bring in ”delete_all” or ”delete everything from foo” as a syntactic guardrail. This is equally implementable, whichever the order of ”delete” and ”from” would be.

[Izkata]

The MySQL client has an --i-am-a-dummy flag that won't let you run a DELETE (or UPDATE, I think) without a WHERE.

[bbqq]

the Google SQL variant has where required for deletes. on my first encounter of it I was just like "huh, neat", you can always use 1=1 as the predicate if needed.

[antisthenes]

If you don't SELECT first before running the DELETE query, you shouldn't be anywhere near an IT job, let alone a production database.

[williamdclt]

Good tools prevent mistakes from happening rather than blaming the user for using it wrong

[alexvoda]

And yet I agree with both. SQL is at the same time easy to get started, incredibly powerful and yet also a complete disaster. Just like JavaScript but with standards you have to pay to read and implementers take their sweet time to implement. ORMs (with the possible exception of JOOQ, whose open source version is unfortunately also very limited) are hopelessly limited and have been a drag on the development of the field ever since.

[swasheck]

i think “disaster” is hyperbole. my brain thinks in concert with sql so it feels natural, though i will concede that the parsing/syntax order differences was an odd choice.

programmers and language users all have a mental translation layers that they use to go from conceptual->concrete using the syntax and idioms of their language of choice.

javascript doesn’t make sense in a lot of ways. calling it a disaster is hyperbole. go doesn’t make sense in a lot of ways. it’s not a disaster. unfamiliarity or disagreement with choices does not necessarily mean it’s a disaster

the only language with which i’m familiar that is a complete, unmitigated disaster is the english language, but i suppose that’s outside of the scope of this conversation

[runlaszlorun]

> the only language with which i’m familiar that is a complete, unmitigated disaster is the english language

Out of curiosity, are you a native speaker of english or did you learn it as a second language?

I’m a native speaker and feel sorry for anyone who has to learn all its irregularities, etc. But the few times I’ve mentioned this to anyone who had to learn as a second language, they’d correct me and tell it was easy. Which baffled me.

Obviously as a native speaker, I’m in no place to judge it.

[rqmedes]

SQL syntax seems how humans communicate to me. Can you pass me that cup from the cupboard

[alexvoda]

SQL syntax is only on the surface level similar to natural language. Besides, if we actually considered similarity to English to be an important criteria for a programming language, we would all still be using Cobol.

[lIIllIIllIIllII]

this totally depends on which language the human speaks. Chinese grammar is kind of like backwards English grammar.

[swasheck]

native english speaker. learned german (fluent) and italian (conversational). english is an insane amalgamation which may be why it’s become near lingua franca

[lukaseder]

> (with the possible exception of JOOQ, whose open source version is unfortunately also very limited)

How is it "very" limited?

[rileymat2]

It just occurred to me, do you have wide denormalized table queries where tables represent entities more than relations?

I think if so that might explain the difference in query structure.

[sherburt3]

Yeah I maintain several BI reports and the codebase is about 20 years old, so multiple teams have taken creative liberties with the naming conventions for tables. Without intellisense I'd probably have gone insane by now.

[rileymat2]

I like it starting with the desired output columns, often when I work with a db quite a bit and have common naming conventions that’s all I need to know.

Even writing queries I think in terms of outputs then build the query from there.

I am blanking about the advantages of starting with from, people clearly share your view, but I have no idea why.

Maybe it comes from my C++ background where return type comes first, then function name, then inputs.

[arzig]

Ability to tab complete columns in an interactive settings.

If I’m in psql I can tab complete columns in the where clause but not in the select because I haven’t actually given any information about what I’m selecting from yet.

[rileymat2]

This feels like a tradeoff we make where a convenience while writing once harms long term readability?

But that is a valid usecase!

[duped]

Imagine if methods on your C++ classes had to be called like method(object) instead of object.method(). While it's a meaningless syntactic difference, the latter makes autocomplete in an IDE possible.

[rileymat2]

Sure, in that very small example, if you don't care internal about visibility.

But method(object1, object2, object3, object4) is different than object.method().

[duped]

I don't think visibility is important, since you want autocomplete to work both in public and private methods. It would be a crappy IDE experience if you couldn't autocomplete on private methods within other private methods.

And sure, multimethods are too complex for naive autocompletion. But it's useful for people to have tooling that can say "given an input tell me what outputs are possible" because that's how we write code.

[exabrial]

Completely agree with everything you said

Reminds me of reading music actually… many first time noob’s, mostly out of frustration, realize how sub optimal staff notation is and seek to write something better. In the end it’s ‘Good enough’ and accept it’s flaws because no rewrite has proven to be a 10x better solution.

[iamwil]

SQL seems to be the QWERTY of the data query world. It's far too entrenched.

[arrowsmith]

... unless you're playing guitar, in which case tab notation works way better ;)

[dizhn]

More like Tab + already knowing the song.:)