5 ms·
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 wo
by sherburt3 3y ago
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.
- alexvoda 3y agoAnd 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 3y agoi 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 3y ago> 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 3y agoSQL syntax seems how humans communicate to me. Can you pass me that cup from the cupboard
- alexvoda 3y agoSQL 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 3y agothis totally depends on which language the human speaks. Chinese grammar is kind of like backwards English grammar.
- swasheck 3y agonative english speaker. learned german (fluent) and italian (conversational). english is an insane amalgamation which may be why it’s become near lingua franca
- lukaseder 3y ago> (with the possible exception of JOOQ, whose open source version is unfortunately also very limited) How is it "very" limited?
- Mutjake 3y agoI 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 3y agoDELETE 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!
- Mutjake 3y agoWell, 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.
- ndriscoll 3y ago
- rileymat2 3y agoI 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 3y agoAbility 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 3y agoThis feels like a tradeoff we make where a convenience while writing once harms long term readability? But that is a valid usecase!
- duped 3y agoImagine 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 3y agoSure, 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 3y agoI 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 3y agoCompletely 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.
- arrowsmith 3y ago... unless you're playing guitar, in which case tab notation works way better ;)
- dizhn 3y agoMore like Tab + already knowing the song.:)
- iamwil 3y agoSQL seems to be the QWERTY of the data query world. It's far too entrenched.
- rileymat2 3y agoIt 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 3y agoYeah 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.