4 ms·

When Grace Hopper was programming your choices involved Assembly, FORTRAN and COBOL. Yes, we still have to write code, but 10 lines of Python / Ruby / Lisp / e

by tl 17y ago

When Grace Hopper was programming your choices involved Assembly, FORTRAN and COBOL. Yes, we still have to write code, but 10 lines of Python / Ruby / Lisp / etc... do the work of 100 lines for FORTRAN or 1000 lines of Assembly. I'll call that an "improved process."

CamperBob 17y ago
No, that's an incremental improvement. All we're doing is writing fewer lines of the same damned procedural code. We didn't replace our horse and buggy with a car, we put some Tri-Flow on the bearings and meth in the feed bag and called it a day.
- DougBTX 17y ago
  Does filling in an Excel worksheet count as programming? Many people do it every day without writing procedural code, but I would wager that it is.
- philwelch 17y ago
  If you're writing FORTRAN/COBOL style procedural code in high level languages, then (as the kids say) you're doing it wrong. You tell the computer what you want it to do. The computer does it. You can tell it at as high or low a level as you want (within reason). The computer requires a precise formulation of what you want it to do before it can do anything. Can you see a way out of this?
  - CamperBob 17y ago
    It's true that the computer requires a precise formulation of what you want it to do, but I'd submit that current programming methods are very far from the so-called minimum description length limit, where we'd be telling the computer nothing but what we want it to do. A framework for encapsulating different problem domains would help, as there are far fewer problem domains than there are programs. If anyone seriously thinks that traditional procedural languages (even the more concise ones ones like Python and Ruby) are going to scale for another fifty years, they're on glue. We can't go on like this.
    - philwelch 17y ago
      We have frameworks for encapsulating different problem domains--they're called frameworks, libraries, DSL's, sometimes full-fledged languages of their own. Sometimes they are called operating systems: if you want to tell the computer "play chess with me" it's a simple matter of opening a chess program.

by tl 17y ago

CamperBob 17y ago

No, that's an incremental improvement. All we're doing is writing fewer lines of the same damned procedural code. We didn't replace our horse and buggy with a car, we put some Tri-Flow on the bearings and meth in the feed bag and called it a day.

DougBTX 17y ago
Does filling in an Excel worksheet count as programming? Many people do it every day without writing procedural code, but I would wager that it is.
philwelch 17y ago
If you're writing FORTRAN/COBOL style procedural code in high level languages, then (as the kids say) you're doing it wrong. You tell the computer what you want it to do. The computer does it. You can tell it at as high or low a level as you want (within reason). The computer requires a precise formulation of what you want it to do before it can do anything. Can you see a way out of this?
- CamperBob 17y ago
  It's true that the computer requires a precise formulation of what you want it to do, but I'd submit that current programming methods are very far from the so-called minimum description length limit, where we'd be telling the computer nothing but what we want it to do. A framework for encapsulating different problem domains would help, as there are far fewer problem domains than there are programs. If anyone seriously thinks that traditional procedural languages (even the more concise ones ones like Python and Ruby) are going to scale for another fifty years, they're on glue. We can't go on like this.
  - philwelch 17y ago
    We have frameworks for encapsulating different problem domains--they're called frameworks, libraries, DSL's, sometimes full-fledged languages of their own. Sometimes they are called operating systems: if you want to tell the computer "play chess with me" it's a simple matter of opening a chess program.