8 ms·

> His prediction was based on the trends he was seeing at the time. But it wasn't even AI. Instead he made this prediction because he saw the rise of no-code to

> His prediction was based on the trends he was seeing at the time. But it wasn't even AI. Instead he made this prediction because he saw the rise of no-code tools replacing software developers because managers could finally cut out the pesky "translators", i.e. software developers. It might sound really crazy and stupid today, but when SQL came out, it's advertised as one of "program-generating" languages and was supposed to reduce the need to code. https://en.wikipedia.org/wiki/Fourth-generation_programming_language https://en.wikipedia.org/wiki/Fourth-generation_programming_... (I mean, in some sense it's true because it's much less code than writing our own database...)

matwood 4y ago
SQL was also meant to give a wider range of people access to data. The “business analyst” comes to mind. And, I think SQL was successful. What it didn’t do was reduce the need for programmers, because the new SQL users always wanted more data to answer more complex questions.
- raincole 4y ago
  I didn't mean SQL wan's a success. I meant, as the commenter above me said, a higher-level tool doesn't necessarily replace the lower-level ones, or reduce the need of them.
  - gregjor 4y ago
    Relational databases replaced a whole raft of vendor-supplied databases and custom-built solutions. It was a new tool for software developers, not a replacement.
    - thrown123098 4y ago
      A good chuckle of my career has been breaking outncustom tools out or a database because the database can't scale. IA is the new Excel.
- roundandround 4y ago
  I don't actually agree. SQL did replace the need for programmers, especially for complex questions. We sabotaged its interfaces to existing GUIs for mundane questions and made CRUD a limitless profession. The funny/sad part about computer science is that people don't want to understand the costs of customization and sales/management/marketing forever want it as a differentiator. SQL could have eliminated us from the flow of many niches as easily as the spreadsheet did from business operations. I think why it didn't has more to do with market timing.
  - marcosdumay 4y ago
    SQL was too much ahead of its time, but we are indeed slowly adopting the "avoid operational specifications, use high-level languages, make your language fit the problem instead of the opposite" philosophy of the 4th generation languages.
gregjor 4y ago
My career predates relational/SQL databases so I can confirm what you wrote. When Oracle came out the buzz was that a whole bunch of programmers would go away because managers and executives could write queries in a “natural” English-like language. That never happened. SQL is hard to master, but it’s the easy part of understanding the relational model and any particular schema. Instead Oracle and the other RDBMSs that followed created more jobs for programmers and database analysts and admins.
- 411111111111111 4y ago
  Mine doesn't predate it but it's very confusing for me to read this opinion. From my point of view, it totally did happen? Can you imagine how many programmers the company would've needed to get all the data a business analyst casually queries per day? What you're looking at is the quantity of people actually employed in the industry, not how many SQL made obsolete. The industry just grew so much that it didn't become an issue.
  - lozenge 4y ago
    The industry grew because the desire for data analysis grew, which is because the technology's ability to meet the desire grew. This can repeat itself a couple more times.
    - ben_w 4y ago
      Cotton gins and the Jevons effect. Give what even pessimistic AI alignment people are saying, I think you're correct that there are a few more repeats possible before AGI. (Whether the pessimists are correct that all of them will happen before the 30s, I cannot say).
  - gregjor 4y ago
    A few things happened. Relational databases enabled more new development, larger databases, interoperability, all of which needed programmers. With more flexibility in the database companies could collect, store, and use more data. And that data had to get into the DBMS somehow: more code. Setting up and managing databases required DBAs, a role often filled by programmers in smaller companies, and still filled by programmers today. And only larger companies had business analysts. In smaller companies programmers or maybe technically-proficient managers did that work. Anyone who had devoted their career solely to building bespoke database systems had to pivot or walk in the late ‘80s, but very few programmers only did that — it was part of the larger application development. If you were good enough to write robust database code pre-Oracle you had plenty of options. In the ‘80s when RDBMSs started to take over I worked in enterprise logistics. Oracle created jobs at the places I worked, and no programmers had to leave because we got a better tool. I’ve worked in large and small organizations for 40+ years. I’ve never worked with a manager or analyst who could write SQL more complex than “SELECT * FROM orders WHERE total > 10000.” I’m sure they exist, but not in career-threatening numbers.
actionfromafar 4y ago
It was very true, and one of the most success DSLs ever invented. And many people coded SQL who never would have touched other languages with a ten foot pole. It’s just that, with more powerful tools we can create more advanced and intricate things, so it never ends… I not exactly welcome but rather anticipate, a near future were instead of reinventing every kind of pattern and library in terms of cloud and infrastructure management, we will see the same meta-management of different AI engines and services…
rukuu001 4y ago
Funny - also COBOL was intended for the 'business' community to write their own programs. Even funnier - we've already lived through the great 'software development adoption' by business and hardly noticed, except some of us got work out of it. A lot of small businesses (legal practices and accountancies were particular suspects) grabbed MS Access with both hands and went wild in the 90s/early 2000s. Timesheets and other HR functions were popular applications.
- noodlesUK 4y ago
  I’m quite sad there isn’t anything like access these days. I feel like I see fairly clever solutions for things being built in excel, but they can’t scale very well to multiple users. For a lot of processes something like Access would be great for bridging the gap.
  - ghaff 4y ago
    My oversimplified observation is that, Adobe products at the high-end notwithstanding, MS Office basically crystallized what was a mainstream office productivity suite now that companies weren't buying one-off products. Rather than buying a low-end/midrange desktop publishing program, they made it work with Word. Rather than using a low-end database (of which there were many), the made do with Excel.
canadianfella 4y ago
[dead]
wruza 4y ago
But it is true, just in a different area than predicted. I hear all the time that scientists and analysts, while being non-programmers, do write various queries without asking a programmer to do it… I am a programmer and not even sure how much time it would take to implement their regular joins with windowing, aggregates etc in a record-based file format. Can I even do that? SQL was a typical failure in this regard. It was seen as a savior but at the same time was designed for at least math-versed people. The prediction was right, its scope was wrong. Since then we failed many times and as I see it, we tend to diverge from this idea more and more. And the reason is there’s no one controlling our stacks vertically, so it takes more jobs than it could to make an app.
RyEgswuCsn 4y ago
I think it used to be that one needs to write dedicated programs to go through large amount of data --- you need to know a programming language, all its toolchains, and the all the proper algorithms for doing the query __out-of-memory__ --- certainly above your ordinary analysts' paygrade. With SQL you need none of those.
- jackcviers3 4y ago
  This. And if you look at the level of algorithms knowledge needed today to read the least amount of data from a set, it succeeded.

matwood 4y ago

SQL was also meant to give a wider range of people access to data. The “business analyst” comes to mind. And, I think SQL was successful. What it didn’t do was reduce the need for programmers, because the new SQL users always wanted more data to answer more complex questions.

raincole 4y ago
I didn't mean SQL wan's a success. I meant, as the commenter above me said, a higher-level tool doesn't necessarily replace the lower-level ones, or reduce the need of them.
- gregjor 4y ago
  Relational databases replaced a whole raft of vendor-supplied databases and custom-built solutions. It was a new tool for software developers, not a replacement.
  - thrown123098 4y ago
    A good chuckle of my career has been breaking outncustom tools out or a database because the database can't scale. IA is the new Excel.
roundandround 4y ago
I don't actually agree. SQL did replace the need for programmers, especially for complex questions. We sabotaged its interfaces to existing GUIs for mundane questions and made CRUD a limitless profession. The funny/sad part about computer science is that people don't want to understand the costs of customization and sales/management/marketing forever want it as a differentiator. SQL could have eliminated us from the flow of many niches as easily as the spreadsheet did from business operations. I think why it didn't has more to do with market timing.
- marcosdumay 4y ago
  SQL was too much ahead of its time, but we are indeed slowly adopting the "avoid operational specifications, use high-level languages, make your language fit the problem instead of the opposite" philosophy of the 4th generation languages.

gregjor 4y ago

My career predates relational/SQL databases so I can confirm what you wrote. When Oracle came out the buzz was that a whole bunch of programmers would go away because managers and executives could write queries in a “natural” English-like language. That never happened. SQL is hard to master, but it’s the easy part of understanding the relational model and any particular schema. Instead Oracle and the other RDBMSs that followed created more jobs for programmers and database analysts and admins.

411111111111111 4y ago
Mine doesn't predate it but it's very confusing for me to read this opinion. From my point of view, it totally did happen? Can you imagine how many programmers the company would've needed to get all the data a business analyst casually queries per day? What you're looking at is the quantity of people actually employed in the industry, not how many SQL made obsolete. The industry just grew so much that it didn't become an issue.
- lozenge 4y ago
  The industry grew because the desire for data analysis grew, which is because the technology's ability to meet the desire grew. This can repeat itself a couple more times.
  - ben_w 4y ago
    Cotton gins and the Jevons effect. Give what even pessimistic AI alignment people are saying, I think you're correct that there are a few more repeats possible before AGI. (Whether the pessimists are correct that all of them will happen before the 30s, I cannot say).
- gregjor 4y ago
  A few things happened. Relational databases enabled more new development, larger databases, interoperability, all of which needed programmers. With more flexibility in the database companies could collect, store, and use more data. And that data had to get into the DBMS somehow: more code. Setting up and managing databases required DBAs, a role often filled by programmers in smaller companies, and still filled by programmers today. And only larger companies had business analysts. In smaller companies programmers or maybe technically-proficient managers did that work. Anyone who had devoted their career solely to building bespoke database systems had to pivot or walk in the late ‘80s, but very few programmers only did that — it was part of the larger application development. If you were good enough to write robust database code pre-Oracle you had plenty of options. In the ‘80s when RDBMSs started to take over I worked in enterprise logistics. Oracle created jobs at the places I worked, and no programmers had to leave because we got a better tool. I’ve worked in large and small organizations for 40+ years. I’ve never worked with a manager or analyst who could write SQL more complex than “SELECT * FROM orders WHERE total > 10000.” I’m sure they exist, but not in career-threatening numbers.

actionfromafar 4y ago

It was very true, and one of the most success DSLs ever invented. And many people coded SQL who never would have touched other languages with a ten foot pole. It’s just that, with more powerful tools we can create more advanced and intricate things, so it never ends… I not exactly welcome but rather anticipate, a near future were instead of reinventing every kind of pattern and library in terms of cloud and infrastructure management, we will see the same meta-management of different AI engines and services…

rukuu001 4y ago

Funny - also COBOL was intended for the 'business' community to write their own programs. Even funnier - we've already lived through the great 'software development adoption' by business and hardly noticed, except some of us got work out of it. A lot of small businesses (legal practices and accountancies were particular suspects) grabbed MS Access with both hands and went wild in the 90s/early 2000s. Timesheets and other HR functions were popular applications.

noodlesUK 4y ago
I’m quite sad there isn’t anything like access these days. I feel like I see fairly clever solutions for things being built in excel, but they can’t scale very well to multiple users. For a lot of processes something like Access would be great for bridging the gap.
- ghaff 4y ago
  My oversimplified observation is that, Adobe products at the high-end notwithstanding, MS Office basically crystallized what was a mainstream office productivity suite now that companies weren't buying one-off products. Rather than buying a low-end/midrange desktop publishing program, they made it work with Word. Rather than using a low-end database (of which there were many), the made do with Excel.

canadianfella 4y ago

[dead]

wruza 4y ago

But it is true, just in a different area than predicted. I hear all the time that scientists and analysts, while being non-programmers, do write various queries without asking a programmer to do it… I am a programmer and not even sure how much time it would take to implement their regular joins with windowing, aggregates etc in a record-based file format. Can I even do that? SQL was a typical failure in this regard. It was seen as a savior but at the same time was designed for at least math-versed people. The prediction was right, its scope was wrong. Since then we failed many times and as I see it, we tend to diverge from this idea more and more. And the reason is there’s no one controlling our stacks vertically, so it takes more jobs than it could to make an app.

RyEgswuCsn 4y ago

I think it used to be that one needs to write dedicated programs to go through large amount of data --- you need to know a programming language, all its toolchains, and the all the proper algorithms for doing the query __out-of-memory__ --- certainly above your ordinary analysts' paygrade. With SQL you need none of those.

jackcviers3 4y ago
This. And if you look at the level of algorithms knowledge needed today to read the least amount of data from a set, it succeeded.