15 ms·

Since starting my career, the tech stack I use has changed numerous times. Technologies have come, gone, evolved. But except for a brief period in 2010 where

by swalsh 4y ago

Since starting my career, the tech stack I use has changed numerous times. Technologies have come, gone, evolved. But except for a brief period in 2010 where we thought we could kill it, SQL is the one technology that has stayed around. It might be the only TECHNICAL knowledge I learned in the first year of my career that is still relavent. You're probably not making the wrong decision if you decide to build on top of SQL.

matwood 4y ago
> It might be the only TECHNICAL knowledge I learned in the first year of my career that is still relavent. Agree. IIRC, I wrote my first SQL is 1996 and wrote some today. While not perfect, it’s amazing at what it does. I suggest reading Joe Celko to really up your SQL skills.
- johnthescott 4y ago
  yep. and i wrote my first quel in 1984 at BLI. and sql still won the war.
quickthrower2 4y ago
The problem I see here is building SQL on top of the cloud, which is like building SQL on top of a database where the tables are always changing - not just adding columns but the meaning of the columns and rows, or even the existence of the table. I think this is a good idea, but the cloud doesn't seem to care too much about backwards compatibility. If you use MySQL/PostgreSQL/SQL Server, you can be fairly sure in 20 years time your SQL will still work :-). The need for this library is more an indictment on "the cloud" than anything. I am mostly an Azure user so AWS/Google might be better but man it changes it's UI and CLI interfaces alot - way too much.
rsync 4y ago
"Since starting my career, the tech stack I use has changed numerous times. Technologies have come, gone, evolved. But except for a brief period in 2010 where we thought we could kill it, SQL is the one technology that has stayed around." Ethernet comes to mind when I think of technologies that just can't be killed ...
papito 4y ago
SQL is a technology that engineers should know in an out, and while in early 2000's you could not move an inch without knowing it, I find that the new generation of devs really considers database calls a freebie - hidden behind abstractions and ORMs. It's just a line of code, right? This leads to highly non-performant software since, unless we have bent the laws of physics in the last 15 years, your data access layer is the most expensive one. But we are crushing LeetCode, yeah?
sleiben 4y ago
Reminds me of Git.
- TremendousJudge 4y ago
  SQL is at least 30 years older than Git. Git has yet to prove its longevity in the same way.
  - nightski 4y ago
    That statement will be true forever. It doesn’t tell you much.
    - TremendousJudge 4y ago
      Let me restate in relative terms then. SQL is over twice as old as Git. When Git was originally released, SQL had been around for longer than Git has been today. Git has had a pretty good track record, but it's not comparable yet in terms of age or even in terms of mass adoption -- plenty of orgs don't use Git to manage their code.
- shepherdjerred 4y ago
  Git is surprisingly only 17 years old while SQL is 48 years. Not that you’re wrong, it’s just interesting how comparatively newer it is
  - marcosdumay 4y ago
    Also, git had major competition for almost half of that time where it was not clear at all what software people would settle on (or even if they they would actually settle down). SQL was nearly undisputed its entire life. It quickly killed every previous architecture, and everything that came after it made a point on being compatible.
    - TremendousJudge 4y ago
that_guy_iain 4y ago
Honestly, mines has mostly stayed the same. I've played with various techs but I mostly work the same underlying tech. Some items get added but very rarely does something get replaced or removed. The tech gets improved and new features added . The last time I can remember something getting replaced is vargrant for docker. And honestly, I think that's a mistake for many companies. Before that it was git for svn. The only way I can see tech coming and going is you're always an early adoptor and need to replace things that failed. If you build on stable tech, that stuff stays around for decades even if it was terrible in the first place. A good example is PHP. It was terrible at first still around and improving year on year.
- arjvik 4y ago
  Why do you think Vagrant->Docker was a mistake?
  - that_guy_iain 4y ago
    Most companies have a large amount of devs on macbooks. Docker on the macbook has historically been painful. Mainly due to the filesystem. Whereas, vagrant doesn't really have that problem. I've been using Linux for so long that I haven't really experienced the pain myself. But I have gotten to enjoy the smugness of them all complaininga about their performance while mines is super snappy. Then if you look at the toolchain surounding vagrant such as packer. It looks really nice. Docker doesn't seem so nice. In fact, I still use packer to build my docker container images because I like the setup nicer. With Docker it's all about the production env. I see the benefits for prod but for dev when you're literally not using the same docker setup as you would in prod it makes no real sense to me.
    - robertlagrant 4y ago
      Docker was painful on Mac, but quite a while ago. I don't have any problems these days.
      - that_guy_iain 4y ago
tiffanyh 4y ago
Declarative vs Imperative Language. A huge benefit of SQL is that it's a declarative language (you describe what the output should be); whereas with imperative languages like C/Python/Ruby you have to describe how to generate the output with specific instructions and procedures.
- jooz 4y ago
  I consider SQL imperative. You say exactly how to do what you want, not what do you want. If we take as example a table with a single row: In imperative (SQL): INSERT INTO TABLE1 (name, wage) VALUES ('John','50k'); Then one day John gets a raise: UPDATE TABLE TABLE1 SET wage = '60k' where name = 'John' In declarative (pseudo code in yaml): - table: TABLE1 - name: John wage: 50k Then one day John gets a raise: - table: TABLE1 - name: John wage: 60k
  - tiffanyh 4y ago
    You’re describing to the RDBMS what you wanted added to the database. The SQL/RDBMS takes care of how that’s done. In C, you’d have to program how the data should be stored (data structure) and written to disk.
    - OJFord 4y ago
      > In C, you’d have to program how the data should be stored (data structure) and written to disk. Just like declaring the columns you're specifying values for and then the values for them? If SQL was declarative, you wouldn't have an error on duplicate CREATE, there would be no CREATE OR REPLACE, and changing column types would not be an error. It would just 'table x should be like this, make it so'. (Actual queries/projections I would say are declarative, just the nomenclature pretends they're not. (Select from join all sounds very imperative, but really you're just describing what you want, and have no say over how it's retrieved.))
  - zmmmmm 4y ago
    It's sort of a weird hybrid monster really, some times it's the worst of both worlds. You state what you want, yes - but you are forced to articulate it as a specific set of table navigations / logistics through the relational model, as if you were writing the implementation. Then, however, the database then may choose ignore those and do something else to resolve the data you asked for if it wants, if it can prove the outcome is equivalent. For example I want all the ice creams bought by John. Even though the schema knows the foreign key relationship between "user" and "purchase" I have to tell it back to the database engine in my query. But even after doing that there's no requirement the database will actually implement the steps I was forced so ungraciously to specify. It may "optimise" them away and do something else.
irrational 4y ago
I’ve been using HTML since the mid 1990s. That is probably the oldest technology that I still use on a regular basis. SQL would be a close second (or maybe third - I probably started learning sql around 2001 and I can’t remember when JavaScript came out. Surely before that.)
- jrm4 4y ago
  As above has noted, Both HTML and SQL are effectively declarative, hence their staying power.
  - randomdata 4y ago
    XHTML looked like it would totally usurp HTML at one point but then we went back to HTML with avengence when everyone jumped on the HTML5 hype train. Postgres used QUEL instead of SQL for the first decade of its life. There were several competing languages in the relational database space at one time, but SQL eventually won, no doubt thanks to Oracle and IBM's utter dominance in the space a few decades ago. Declarative doesn't mean staying power. Reaching ubiquity through luck and random chance seems to be what achieves staying power. Javascript likely fits this category too. Browser developers 30 years from now will no doubt still be using Javascript.
  - irrational 4y ago
    And JavaScripts staying power is backwards compatibility for billions of web pages, don't want to introduce another language to the browser because it would cost a lot of money for developers to build the engine and would increase the security attack surface, and all the browsers would have to add a new engine around the same time so developers would be willing to use it.
    - jrm4 4y ago
      Sure, I don't disagree that Javascript also has some staying power. But I suppose if you look at the web programming stack and its history (which helps explain how stupid and nonsensical it is) I'll bet that in the long run HTML and SQL stick around longer as a part, even when they're perhaps not very "good?" As in, a good bit of the energy around Javascript is "dealing with its extreme shortcomings directly in a way that implies possible replacement?" Like, transpiling feels different from layering on top. And people transpile Javascript, but layer on top of HTML? Something like that.
rubyist5eva 4y ago
I feel my abilities as a developer really took off when I took the time to really learn SQL and take advantage of the features that my database offers. For example, learning to use window functions felt like that galaxy brain meme where you become one with the universe. Being able to take 50 lines of ruby code (manual (anti-)joins and aggregates, result partitioning, etc...) and replace it with a couple lines of sql that is much faster and less buggy is a life changing experience. The only other time I had such a dramatic shift in the way that I look at building applications is when I learned Scala (functional programming).
- johnthescott 4y ago
  > replace it with a couple lines of sql that is much faster and less buggy is a life changing experience. you have snatched the pea.
  - meken 4y ago
    I googled this expression but didn’t find anything. What does it mean?
    - yCombLinks 4y ago
      Pretty sure it's a reference to https://www.youtube.com/watch?v=9selPW2lL-M https://www.youtube.com/watch?v=9selPW2lL-M
      - johnthescott 4y ago
        correct. sql moves the mind from pondering scalars to groking sets.
munificent 4y ago
I'm sure this will ruffle some feathres, but the technical skill that has been the most persistently valuable across the past 25 years of my career is object-oriented programming and design. It's not the only paradigm I use, but being able to organize large programs in terms of OOP has been incredibly valuable and hugely productive for me across several languages and domains.
- Jweb_Guru 4y ago
  Everyone has a different experience! Object oriented programming and design have had approximately no impact on my own career, while SQL knowledge has been indispensable. I don't think they're really in competition.
- avgcorrection 4y ago
  Just a slow-to-die 90’s fad in the end.
  - kwhitefoot 4y ago
    OOP is considerably older than '90s. Turbo Pascal 5.5 had objects in 1989 and was far from the first. Anyway structs plus FP is no less object oriented. You just don't have to write the methods in the same code module. See NIM Method Call Syntax for example: https://nim-lang.org/docs/tut2.html#object-oriented-programming-method-call-syntax https://nim-lang.org/docs/tut2.html#object-oriented-programm... Yes, I know NIM is not purely functional. Use F# instead to get a bit closer to purity, it also does OOP quite nicely as does pretty much any functional language that has closures. OOP is a tool just as Git is a tool. See also: https://medium.com/extreme-programming/oop-vs-fp-182475457a01 https://medium.com/extreme-programming/oop-vs-fp-182475457a0...
    - avgcorrection 4y ago
      > OOP is considerably older than '90s. Fad means popular (in a deragetory way). 90’s was its popularity heyday. > See NIM Method Call Syntax for example: https://nim-lang.org/docs/tut2.html#object-oriented-programm https://nim-lang.org/docs/tut2.html#object-oriented-programm... So oop is when you `obj.methodName(args)` instead of `methodName(obj, args)`? Well if that’s all it is about then I can get behind it... > OOP is a tool just as Git is a tool. An iron maiden is just a tool. Don’t be hatin’ it’s just a tool what has it done to you?
strbean 4y ago
> except for a brief period in 2010 where we thought we could kill it Unfortunately, we never actually tried to kill SQL. We tried to kill relational databases, with the death of SQL as a side effect. This proved to be a stupid idea - non-relational data stores have value of course, but so do relational databases. SQL, as you point out, is 48 years old. It shows. The ergonomics are awful. It uses natural-language inspired syntax that has fallen completely out of favor (with good reason imho). The ordering of fields and tables precludes the use of autocomplete. It uses orthogonal syntax for identical constructions, i.e. INSERT ... (col1, col2, ...) VALUES (val1, val2, ...) vs. UPDATE ... col1=val1, col2=val2, ... And worst of all, it comes with such a woefully inadequate standard that half of the universally supported features are expressed in a completely different fashion for each vendor. It is very common to argue that its longevity is due to its excellence as a language. I think it's longevity is due to its broad target audience, which includes plenty of people in less technical roles who are high on the org chart. Tech workers are happy to jump on new technology that improves ergonomics (or shiny new toys that are strictly more interesting because they are new). Executives who's primary way of interacting with the tech stack is querying a read only replica are much less open to learning a new language.
- lelanthran 4y ago
  > It uses orthogonal syntax for identical constructions, i.e. Regarding your complaint ... those aren't identical constructions. Insert has to have the syntax it does because it lets you insert multiple rows all with different values in a single statement: INSERT ... (C1, C2) VALUES (v1, v2), (v3, v4), (v5, v6) Update doesn't allow that. The syntax for each of the above makes sense for the specific intention of each statement.
  - aidos 4y ago
    And further, insert … (select …)
  - RussianCow 4y ago
    They could have consolidated the syntax for both, though. No reason you couldn't have this instead: INSERT ... VALUES (C1=v1, C2=v2), (C1=v3, C2=v4), (C1=v5, C2=v6) This would actually be more powerful because it would allow you to arbitrarily omit columns on a per-row basis, which you can't do with SQL today.
api 4y ago
That's not random. SQL is basically math. The syntax is a little old school and arcane (but not terrible) but the principles behind it are set theory and logic.
- randomdata 4y ago
  > That's not random. It's kind of random. There were plenty of competing languages in use until the 90s. Even our beloved Postgres used QUEL for its first decade of life. But Oracle took the dominant lead and its competition either disappeared or started adding SQL support to be compatible with it. Had a different butterfly flapped its wings all those years ago, things could have turned out very different. > SQL is basically math. All programming languages are basically math. > but the principles behind it are set theory Thing is, one of the challenges with SQL is that it doesn't adhere to set theory. This leads to some unintuitive traps that could have been avoided had it carefully stuck to the relational algebra. Such deviation may have been a reasonable tradeoff to help implementations, perhaps, but from a pure language perspective it does make it more terrible than it should have been.

by swalsh 4y ago

matwood 4y ago

> It might be the only TECHNICAL knowledge I learned in the first year of my career that is still relavent. Agree. IIRC, I wrote my first SQL is 1996 and wrote some today. While not perfect, it’s amazing at what it does. I suggest reading Joe Celko to really up your SQL skills.

johnthescott 4y ago
yep. and i wrote my first quel in 1984 at BLI. and sql still won the war.

quickthrower2 4y ago

The problem I see here is building SQL on top of the cloud, which is like building SQL on top of a database where the tables are always changing - not just adding columns but the meaning of the columns and rows, or even the existence of the table. I think this is a good idea, but the cloud doesn't seem to care too much about backwards compatibility. If you use MySQL/PostgreSQL/SQL Server, you can be fairly sure in 20 years time your SQL will still work :-). The need for this library is more an indictment on "the cloud" than anything. I am mostly an Azure user so AWS/Google might be better but man it changes it's UI and CLI interfaces alot - way too much.

rsync 4y ago

"Since starting my career, the tech stack I use has changed numerous times. Technologies have come, gone, evolved. But except for a brief period in 2010 where we thought we could kill it, SQL is the one technology that has stayed around." Ethernet comes to mind when I think of technologies that just can't be killed ...

papito 4y ago

SQL is a technology that engineers should know in an out, and while in early 2000's you could not move an inch without knowing it, I find that the new generation of devs really considers database calls a freebie - hidden behind abstractions and ORMs. It's just a line of code, right? This leads to highly non-performant software since, unless we have bent the laws of physics in the last 15 years, your data access layer is the most expensive one. But we are crushing LeetCode, yeah?

sleiben 4y ago

Reminds me of Git.

TremendousJudge 4y ago
SQL is at least 30 years older than Git. Git has yet to prove its longevity in the same way.
- nightski 4y ago
  That statement will be true forever. It doesn’t tell you much.
  - TremendousJudge 4y ago
    Let me restate in relative terms then. SQL is over twice as old as Git. When Git was originally released, SQL had been around for longer than Git has been today. Git has had a pretty good track record, but it's not comparable yet in terms of age or even in terms of mass adoption -- plenty of orgs don't use Git to manage their code.
shepherdjerred 4y ago
Git is surprisingly only 17 years old while SQL is 48 years. Not that you’re wrong, it’s just interesting how comparatively newer it is
- marcosdumay 4y ago
  Also, git had major competition for almost half of that time where it was not clear at all what software people would settle on (or even if they they would actually settle down). SQL was nearly undisputed its entire life. It quickly killed every previous architecture, and everything that came after it made a point on being compatible.
  - TremendousJudge 4y ago

that_guy_iain 4y ago

Honestly, mines has mostly stayed the same. I've played with various techs but I mostly work the same underlying tech. Some items get added but very rarely does something get replaced or removed. The tech gets improved and new features added . The last time I can remember something getting replaced is vargrant for docker. And honestly, I think that's a mistake for many companies. Before that it was git for svn. The only way I can see tech coming and going is you're always an early adoptor and need to replace things that failed. If you build on stable tech, that stuff stays around for decades even if it was terrible in the first place. A good example is PHP. It was terrible at first still around and improving year on year.

arjvik 4y ago
Why do you think Vagrant->Docker was a mistake?
- that_guy_iain 4y ago
  Most companies have a large amount of devs on macbooks. Docker on the macbook has historically been painful. Mainly due to the filesystem. Whereas, vagrant doesn't really have that problem. I've been using Linux for so long that I haven't really experienced the pain myself. But I have gotten to enjoy the smugness of them all complaininga about their performance while mines is super snappy. Then if you look at the toolchain surounding vagrant such as packer. It looks really nice. Docker doesn't seem so nice. In fact, I still use packer to build my docker container images because I like the setup nicer. With Docker it's all about the production env. I see the benefits for prod but for dev when you're literally not using the same docker setup as you would in prod it makes no real sense to me.
  - robertlagrant 4y ago
    Docker was painful on Mac, but quite a while ago. I don't have any problems these days.
    - that_guy_iain 4y ago

tiffanyh 4y ago

Declarative vs Imperative Language. A huge benefit of SQL is that it's a declarative language (you describe what the output should be); whereas with imperative languages like C/Python/Ruby you have to describe how to generate the output with specific instructions and procedures.

jooz 4y ago
I consider SQL imperative. You say exactly how to do what you want, not what do you want. If we take as example a table with a single row: In imperative (SQL): INSERT INTO TABLE1 (name, wage) VALUES ('John','50k'); Then one day John gets a raise: UPDATE TABLE TABLE1 SET wage = '60k' where name = 'John' In declarative (pseudo code in yaml): - table: TABLE1 - name: John wage: 50k Then one day John gets a raise: - table: TABLE1 - name: John wage: 60k
- tiffanyh 4y ago
  You’re describing to the RDBMS what you wanted added to the database. The SQL/RDBMS takes care of how that’s done. In C, you’d have to program how the data should be stored (data structure) and written to disk.
  - OJFord 4y ago
    > In C, you’d have to program how the data should be stored (data structure) and written to disk. Just like declaring the columns you're specifying values for and then the values for them? If SQL was declarative, you wouldn't have an error on duplicate CREATE, there would be no CREATE OR REPLACE, and changing column types would not be an error. It would just 'table x should be like this, make it so'. (Actual queries/projections I would say are declarative, just the nomenclature pretends they're not. (Select from join all sounds very imperative, but really you're just describing what you want, and have no say over how it's retrieved.))
- zmmmmm 4y ago
  It's sort of a weird hybrid monster really, some times it's the worst of both worlds. You state what you want, yes - but you are forced to articulate it as a specific set of table navigations / logistics through the relational model, as if you were writing the implementation. Then, however, the database then may choose ignore those and do something else to resolve the data you asked for if it wants, if it can prove the outcome is equivalent. For example I want all the ice creams bought by John. Even though the schema knows the foreign key relationship between "user" and "purchase" I have to tell it back to the database engine in my query. But even after doing that there's no requirement the database will actually implement the steps I was forced so ungraciously to specify. It may "optimise" them away and do something else.

irrational 4y ago

I’ve been using HTML since the mid 1990s. That is probably the oldest technology that I still use on a regular basis. SQL would be a close second (or maybe third - I probably started learning sql around 2001 and I can’t remember when JavaScript came out. Surely before that.)

jrm4 4y ago
As above has noted, Both HTML and SQL are effectively declarative, hence their staying power.
- randomdata 4y ago
  XHTML looked like it would totally usurp HTML at one point but then we went back to HTML with avengence when everyone jumped on the HTML5 hype train. Postgres used QUEL instead of SQL for the first decade of its life. There were several competing languages in the relational database space at one time, but SQL eventually won, no doubt thanks to Oracle and IBM's utter dominance in the space a few decades ago. Declarative doesn't mean staying power. Reaching ubiquity through luck and random chance seems to be what achieves staying power. Javascript likely fits this category too. Browser developers 30 years from now will no doubt still be using Javascript.
- irrational 4y ago
  And JavaScripts staying power is backwards compatibility for billions of web pages, don't want to introduce another language to the browser because it would cost a lot of money for developers to build the engine and would increase the security attack surface, and all the browsers would have to add a new engine around the same time so developers would be willing to use it.
  - jrm4 4y ago
    Sure, I don't disagree that Javascript also has some staying power. But I suppose if you look at the web programming stack and its history (which helps explain how stupid and nonsensical it is) I'll bet that in the long run HTML and SQL stick around longer as a part, even when they're perhaps not very "good?" As in, a good bit of the energy around Javascript is "dealing with its extreme shortcomings directly in a way that implies possible replacement?" Like, transpiling feels different from layering on top. And people transpile Javascript, but layer on top of HTML? Something like that.

rubyist5eva 4y ago

I feel my abilities as a developer really took off when I took the time to really learn SQL and take advantage of the features that my database offers. For example, learning to use window functions felt like that galaxy brain meme where you become one with the universe. Being able to take 50 lines of ruby code (manual (anti-)joins and aggregates, result partitioning, etc...) and replace it with a couple lines of sql that is much faster and less buggy is a life changing experience. The only other time I had such a dramatic shift in the way that I look at building applications is when I learned Scala (functional programming).

johnthescott 4y ago
> replace it with a couple lines of sql that is much faster and less buggy is a life changing experience. you have snatched the pea.
- meken 4y ago
  I googled this expression but didn’t find anything. What does it mean?
  - yCombLinks 4y ago
    Pretty sure it's a reference to https://www.youtube.com/watch?v=9selPW2lL-M https://www.youtube.com/watch?v=9selPW2lL-M
    - johnthescott 4y ago
      correct. sql moves the mind from pondering scalars to groking sets.

munificent 4y ago

I'm sure this will ruffle some feathres, but the technical skill that has been the most persistently valuable across the past 25 years of my career is object-oriented programming and design. It's not the only paradigm I use, but being able to organize large programs in terms of OOP has been incredibly valuable and hugely productive for me across several languages and domains.

Jweb_Guru 4y ago
Everyone has a different experience! Object oriented programming and design have had approximately no impact on my own career, while SQL knowledge has been indispensable. I don't think they're really in competition.
avgcorrection 4y ago
Just a slow-to-die 90’s fad in the end.
- kwhitefoot 4y ago
  OOP is considerably older than '90s. Turbo Pascal 5.5 had objects in 1989 and was far from the first. Anyway structs plus FP is no less object oriented. You just don't have to write the methods in the same code module. See NIM Method Call Syntax for example: https://nim-lang.org/docs/tut2.html#object-oriented-programming-method-call-syntax https://nim-lang.org/docs/tut2.html#object-oriented-programm... Yes, I know NIM is not purely functional. Use F# instead to get a bit closer to purity, it also does OOP quite nicely as does pretty much any functional language that has closures. OOP is a tool just as Git is a tool. See also: https://medium.com/extreme-programming/oop-vs-fp-182475457a01 https://medium.com/extreme-programming/oop-vs-fp-182475457a0...
  - avgcorrection 4y ago
    > OOP is considerably older than '90s. Fad means popular (in a deragetory way). 90’s was its popularity heyday. > See NIM Method Call Syntax for example: https://nim-lang.org/docs/tut2.html#object-oriented-programm https://nim-lang.org/docs/tut2.html#object-oriented-programm... So oop is when you `obj.methodName(args)` instead of `methodName(obj, args)`? Well if that’s all it is about then I can get behind it... > OOP is a tool just as Git is a tool. An iron maiden is just a tool. Don’t be hatin’ it’s just a tool what has it done to you?

strbean 4y ago

> except for a brief period in 2010 where we thought we could kill it Unfortunately, we never actually tried to kill SQL. We tried to kill relational databases, with the death of SQL as a side effect. This proved to be a stupid idea - non-relational data stores have value of course, but so do relational databases. SQL, as you point out, is 48 years old. It shows. The ergonomics are awful. It uses natural-language inspired syntax that has fallen completely out of favor (with good reason imho). The ordering of fields and tables precludes the use of autocomplete. It uses orthogonal syntax for identical constructions, i.e. INSERT ... (col1, col2, ...) VALUES (val1, val2, ...) vs. UPDATE ... col1=val1, col2=val2, ... And worst of all, it comes with such a woefully inadequate standard that half of the universally supported features are expressed in a completely different fashion for each vendor. It is very common to argue that its longevity is due to its excellence as a language. I think it's longevity is due to its broad target audience, which includes plenty of people in less technical roles who are high on the org chart. Tech workers are happy to jump on new technology that improves ergonomics (or shiny new toys that are strictly more interesting because they are new). Executives who's primary way of interacting with the tech stack is querying a read only replica are much less open to learning a new language.

lelanthran 4y ago
> It uses orthogonal syntax for identical constructions, i.e. Regarding your complaint ... those aren't identical constructions. Insert has to have the syntax it does because it lets you insert multiple rows all with different values in a single statement: INSERT ... (C1, C2) VALUES (v1, v2), (v3, v4), (v5, v6) Update doesn't allow that. The syntax for each of the above makes sense for the specific intention of each statement.
- aidos 4y ago
  And further, insert … (select …)
- RussianCow 4y ago
  They could have consolidated the syntax for both, though. No reason you couldn't have this instead: INSERT ... VALUES (C1=v1, C2=v2), (C1=v3, C2=v4), (C1=v5, C2=v6) This would actually be more powerful because it would allow you to arbitrarily omit columns on a per-row basis, which you can't do with SQL today.

api 4y ago

That's not random. SQL is basically math. The syntax is a little old school and arcane (but not terrible) but the principles behind it are set theory and logic.

randomdata 4y ago
> That's not random. It's kind of random. There were plenty of competing languages in use until the 90s. Even our beloved Postgres used QUEL for its first decade of life. But Oracle took the dominant lead and its competition either disappeared or started adding SQL support to be compatible with it. Had a different butterfly flapped its wings all those years ago, things could have turned out very different. > SQL is basically math. All programming languages are basically math. > but the principles behind it are set theory Thing is, one of the challenges with SQL is that it doesn't adhere to set theory. This leads to some unintuitive traps that could have been avoided had it carefully stuck to the relational algebra. Such deviation may have been a reasonable tradeoff to help implementations, perhaps, but from a pure language perspective it does make it more terrible than it should have been.