5 ms·

Nearly 40 years for me; I remember reading about The Last One [1] back in 81. [1] https://en.wikipedia.org/wiki/The_Last_One_(software) https://en.wikipedia.or

Nearly 40 years for me; I remember reading about The Last One [1] back in 81. [1] https://en.wikipedia.org/wiki/The_Last_One_(software) https://en.wikipedia.org/wiki/The_Last_One_(software)

brazzy 7y ago
The pipe dream is far older than that. Around 1960 some people seriously claimed that within about 5 years there would be no more professional programmers because with this new language, everyone could write the software they need themselves, since it was so easy to use. The language was COBOL. Oh, and look, this one still seems to be around: http://www.makeyourownsoftware.com/ http://www.makeyourownsoftware.com/
- yhoiseth 7y ago
  Thanks for sharing—that site is a real gem!
- zokier 7y ago
  > Around 1960 some people seriously claimed that within about 5 years there would be no more professional programmers because with this new language, everyone could write the software they need themselves, since it was so easy to use. Of course that prediction seems quaint now, but I posit that the prediction failed because they greatly underestimated the increase in demand of software as much as overestimated the expressiveness/productivity increase of COBOL (and later systems). Heck, considering what a professional programmers job might have been like in the 50s, its not far fetched at all that such profession indeed has disappeared as modern programmers work at such a different level of abstraction
  - brazzy 7y ago
    Yes, given that back then people were typically working in assembler (with frequently changing platforms, to boot) and writing relatively simple data processing applications, the claim is somewhat understandable. But I think the main thing it failed to take into account is more how hard it is to translate business requirements into complete and unambiguous instructions.
    - goatlover 7y ago
      The even bigger thing is how better tools and abstraction create more demand for code, as more can be done. The entire history of computers has seen software demand increase over time.
  - ksdale 7y ago
    This reminds me of the Jevons paradox from economics. The story is that when steam engines became way more efficient, the demand for coal exploded. Even though each engine used much less energy, the total amount of energy consumed went through the roof.
- reitzensteinm 7y ago
  Oh my god, I was convinced until the end that it was a top notch joke site... then I got to the credit card form.
  - DonHopkins 7y ago
    There used to be an early ARPAnet mailing list called "INFO-COBOL@MC", that was actually for exchanging jokes and copyrighted Dave Barry articles (which was an officially prohibited abuse of the government sponsored ARPAnet). It was a great stealth name because nobody took COBOL seriously, and we would just laugh at people who posted COBOL questions. Here are some old INFO-COBOL messages archived in the MIT-AI HUMOR directory: http://its.svensson.org/HUMOR%3bINFO%20COBOL http://its.svensson.org/HUMOR%3bINFO%20COBOL Then there was The TTY of Geoffrey S. Goodfellow's spin-off, the specialized "DB-LOVERS" mailing list, just for dead baby jokes. https://news.ycombinator.com/item?id=8418591 https://news.ycombinator.com/item?id=8418591 Speaking of COBOL jokes: https://medium.com/@donhopkins/cobol-forever-1a49f7d28a39 https://medium.com/@donhopkins/cobol-forever-1a49f7d28a39
    - reitzensteinm 7y ago
      That's pretty funny, thanks for sharing!
- K0SM0S 7y ago
  To be fair, afaik (second hand account), when COBOL appeared it drove a bunch of non-expert programmers into the field, mostly domain-driven people. It really was a new age of programming. (which then-experts didn't really see in a positive light) Episode of Command Line Heroes by Red Hat about COBOL: https://www.redhat.com/en/command-line-heroes/season-3/the-infrastructure-effect https://www.redhat.com/en/command-line-heroes/season-3/the-i... I think it's a little unfair to characterize COBOL as a failure in that regard. It tremendously increased the accessibility and use of programming and computing in general by way of consequence; it's been instrumental in allowing the programmer population to grow massively. Granted, extraordinary superlative claims never materialize, but the intent, the vision is important ime. Especially in business settings.
mimixco 7y ago
Yes, in the 80's and 90's we called it CASE (Computer Aided Software Engineering). It was just as fascinating then and equally impractical now. Text turns out to be a great, compact way to convey ideas or instructions which is the heart of software development.
- shadowgovt 7y ago
  I don't think text is nearly as compact as people claim it to be. I dabble in graphical programming languages from time-to-time, and one feature they all share is the editing environment for code makes entire categories of syntax error impossible; there is no way in the language's design to pass a string to a function that only accepts a number, for example, because the "blocks just don't fit together." It's a level of integration between the space of all possible arrangements of elements and the set of arrangements that constitute valid programs that I see text-based IDEs approach, but struggle to catch up with. And I suspect part of the challenge is that as a tool for describing programs, sequential text has too much dimensionality; the set of strings of sequential text is much, much larger than the set of valid programs, and it's easy to put text sequences together that aren't valid.
  - bpizzi 7y ago
    > there is no way in the language's design to pass a string to a function that only accepts a number, for example, because the "blocks just don't fit together." Which is easily achieved by the first typed language that comes to hand, no?
    - shadowgovt 7y ago
      Not without an IDE. It's still extremely possible (in all text-based languages I'm familiar with) to write the program with a typecheck error; the typechecker will gleefully catch it for you. At typecheck time. Often (depending on my toolchain) minutes after I've written the offending code and mounds of code depending on it. It's possible, with many languages, to write IDEs that will make this hard, but I've yet to find one that makes it impossible. Certainly not in the same way that, for example, Scratch will simply refuse to let the offending blocks click together. I certainly don't advocate transitioning from text languages to Scratch, but I think there's meat on the bones of asking the question "Why, when I'm editing code in text-based languages, am I even allowed to reference a variable that is demonstrably the wrong type? What benefit is that gaining me?" Because I think the answer in a lot of cases is "No real benefit; editing, typechecking, and compilation have just historically been disjoint concerns with no feedback channel because writing those is hard."

Nearly 40 years for me; I remember reading about The Last One [1] back in 81. [1] https://en.wikipedia.org/wiki/The_Last_One_(software) https://en.wikipedia.org/wiki/The_Last_One_(software)

brazzy 7y ago

The pipe dream is far older than that. Around 1960 some people seriously claimed that within about 5 years there would be no more professional programmers because with this new language, everyone could write the software they need themselves, since it was so easy to use. The language was COBOL. Oh, and look, this one still seems to be around: http://www.makeyourownsoftware.com/ http://www.makeyourownsoftware.com/

yhoiseth 7y ago
Thanks for sharing—that site is a real gem!
zokier 7y ago
> Around 1960 some people seriously claimed that within about 5 years there would be no more professional programmers because with this new language, everyone could write the software they need themselves, since it was so easy to use. Of course that prediction seems quaint now, but I posit that the prediction failed because they greatly underestimated the increase in demand of software as much as overestimated the expressiveness/productivity increase of COBOL (and later systems). Heck, considering what a professional programmers job might have been like in the 50s, its not far fetched at all that such profession indeed has disappeared as modern programmers work at such a different level of abstraction
- brazzy 7y ago
  Yes, given that back then people were typically working in assembler (with frequently changing platforms, to boot) and writing relatively simple data processing applications, the claim is somewhat understandable. But I think the main thing it failed to take into account is more how hard it is to translate business requirements into complete and unambiguous instructions.
  - goatlover 7y ago
    The even bigger thing is how better tools and abstraction create more demand for code, as more can be done. The entire history of computers has seen software demand increase over time.
- ksdale 7y ago
  This reminds me of the Jevons paradox from economics. The story is that when steam engines became way more efficient, the demand for coal exploded. Even though each engine used much less energy, the total amount of energy consumed went through the roof.
reitzensteinm 7y ago
Oh my god, I was convinced until the end that it was a top notch joke site... then I got to the credit card form.
- DonHopkins 7y ago
  There used to be an early ARPAnet mailing list called "INFO-COBOL@MC", that was actually for exchanging jokes and copyrighted Dave Barry articles (which was an officially prohibited abuse of the government sponsored ARPAnet). It was a great stealth name because nobody took COBOL seriously, and we would just laugh at people who posted COBOL questions. Here are some old INFO-COBOL messages archived in the MIT-AI HUMOR directory: http://its.svensson.org/HUMOR%3bINFO%20COBOL http://its.svensson.org/HUMOR%3bINFO%20COBOL Then there was The TTY of Geoffrey S. Goodfellow's spin-off, the specialized "DB-LOVERS" mailing list, just for dead baby jokes. https://news.ycombinator.com/item?id=8418591 https://news.ycombinator.com/item?id=8418591 Speaking of COBOL jokes: https://medium.com/@donhopkins/cobol-forever-1a49f7d28a39 https://medium.com/@donhopkins/cobol-forever-1a49f7d28a39
  - reitzensteinm 7y ago
    That's pretty funny, thanks for sharing!
K0SM0S 7y ago
To be fair, afaik (second hand account), when COBOL appeared it drove a bunch of non-expert programmers into the field, mostly domain-driven people. It really was a new age of programming. (which then-experts didn't really see in a positive light) Episode of Command Line Heroes by Red Hat about COBOL: https://www.redhat.com/en/command-line-heroes/season-3/the-infrastructure-effect https://www.redhat.com/en/command-line-heroes/season-3/the-i... I think it's a little unfair to characterize COBOL as a failure in that regard. It tremendously increased the accessibility and use of programming and computing in general by way of consequence; it's been instrumental in allowing the programmer population to grow massively. Granted, extraordinary superlative claims never materialize, but the intent, the vision is important ime. Especially in business settings.

mimixco 7y ago

Yes, in the 80's and 90's we called it CASE (Computer Aided Software Engineering). It was just as fascinating then and equally impractical now. Text turns out to be a great, compact way to convey ideas or instructions which is the heart of software development.

shadowgovt 7y ago
I don't think text is nearly as compact as people claim it to be. I dabble in graphical programming languages from time-to-time, and one feature they all share is the editing environment for code makes entire categories of syntax error impossible; there is no way in the language's design to pass a string to a function that only accepts a number, for example, because the "blocks just don't fit together." It's a level of integration between the space of all possible arrangements of elements and the set of arrangements that constitute valid programs that I see text-based IDEs approach, but struggle to catch up with. And I suspect part of the challenge is that as a tool for describing programs, sequential text has too much dimensionality; the set of strings of sequential text is much, much larger than the set of valid programs, and it's easy to put text sequences together that aren't valid.
- bpizzi 7y ago
  > there is no way in the language's design to pass a string to a function that only accepts a number, for example, because the "blocks just don't fit together." Which is easily achieved by the first typed language that comes to hand, no?
  - shadowgovt 7y ago
    Not without an IDE. It's still extremely possible (in all text-based languages I'm familiar with) to write the program with a typecheck error; the typechecker will gleefully catch it for you. At typecheck time. Often (depending on my toolchain) minutes after I've written the offending code and mounds of code depending on it. It's possible, with many languages, to write IDEs that will make this hard, but I've yet to find one that makes it impossible. Certainly not in the same way that, for example, Scratch will simply refuse to let the offending blocks click together. I certainly don't advocate transitioning from text languages to Scratch, but I think there's meat on the bones of asking the question "Why, when I'm editing code in text-based languages, am I even allowed to reference a variable that is demonstrably the wrong type? What benefit is that gaining me?" Because I think the answer in a lot of cases is "No real benefit; editing, typechecking, and compilation have just historically been disjoint concerns with no feedback channel because writing those is hard."