7 ms·

The article mentions that COBOL was an easy programming language to learn. Personally, I disagree. As a beginner in a CS course, it was incredibly hard to compr

The article mentions that COBOL was an easy programming language to learn. Personally, I disagree. As a beginner in a CS course, it was incredibly hard to comprehend why a program needs so many sections and why the various lines must start at a particular column. C seemed easy in comparison.

pjmlp 6y ago
When COBOL was invented C did not even exist, it only came to be about 10 years later. The alternatives were Assembly, FORTRAN and ALGOL.
- kyberias 6y ago
  But they have coexisted at the same time haven't they?
  - pjmlp 6y ago
    They have coexisted since early 70s, back when C was invented. However where COBOL rules is on mainframes, which after Assembly have always used PL/I derived systems programming languages (like Unisys, IBM i and z/OS), so on those systems C is just another guest language and hardly anyone cares to use it beyond porting software to their POSIX runtimes.
    - kyberias 6y ago
      Right, that's why I don't understand why you had to bring up the fact that C was invented later. OP didn't claim anything related to that.
      - pjmlp 6y ago
        Because COBOL was seen as productive in the context of 1950's computing environments.
  - protomyth 6y ago
    Unlike Fortran, COBOL really hasn't evolved in the C dominated world. Although C is really dominant on the platforms COBOL lives on.
    - pjmlp 6y ago
      What?!? Cobol has had its last revision in 2014, supports modules, OOP, and even has .NET and JVM backends. MicroFocus and Fujistsu also have frameworks for cloud deployments and writing microservices in Cobol. Almost no one cares about C on mainframes beyond porting some POSIX stuff, or running Aix/Linux on an hypervisor.
      - protomyth 6y ago
        That's basically it, no one cares about C on the mainframe so COBOL doesn't deal with the C competition and C flaws that fuel Go and Rust. COBOL itself has advanced but it doesn't have the same competition.
        pjmlp 6y ago
        They don't care about C because mainframes always had better alternatives for systems programming, via PL/S, PL.8 and NEWP, as the three major surviving ones. Even BLISS and Mesa were better than C.
        protomyth 6y ago
        If I remember correctly OpenVMS was programmed in something else also. It would have been interesting if one of the PC operating systems had decided to use one of those languages. So, no C, no interest in 'I need a C replacement language', enterprise software is boring, so no COBOL replacement. Plus, I know of at least one vendor who did develop something but it is kept in-house. I did expect someone to develop yet another REXX to address this need.
      - skissane 6y ago
        > Almost no one cares about C on mainframes beyond porting some POSIX stuff, or running Aix/Linux on an hypervisor. I think, with Metal C, that's less true than it used to be. My understanding is that, for brand new z/OS components (e.g. Zowe, z/OSMF), IBM prefers Metal C to PL/X. It is also seeing increasing use by mainframe ISVs as a replacement for assembly and PL/X.
fortran77 6y ago
The column requirements are a holdover from the days of punchcards, where column 1 was reserved for JCL commands and some columns were reserved so cards could be numbered and sorted by mechanical means.
- kens 6y ago
  Many of IBM's early mainframes could only read 72 columns from a punch card, which is why Fortran (and I assume COBOL) only used 72 columns. Specifically, the IBM 704 was a 36-bit machine and read punch cards one row at a time, filling two 36-bit words. There was a wiring panel that let you select any 72 columns to read, but obviously using the first 72 columns was most sensible. If you punched sequence numbers in the ignored columns 73-80, you could use an electromechanical card sorter to put the cards back in order if you dropped them.
  - fortran77 6y ago
    > if you dropped them. Or if someone shuffled them (as we used to do in the computer room to people who annoyed us.)
  - praptak 6y ago
    My professor told us of a technique he used to recover from stack drops. Draw a pattern with a felt tip pen across the side of the stack (on the edges of the cards). This way a quick glance can tell you if the stack is out of order and it's also faster to sort manually.

pjmlp 6y ago

When COBOL was invented C did not even exist, it only came to be about 10 years later. The alternatives were Assembly, FORTRAN and ALGOL.

kyberias 6y ago
But they have coexisted at the same time haven't they?
- pjmlp 6y ago
  They have coexisted since early 70s, back when C was invented. However where COBOL rules is on mainframes, which after Assembly have always used PL/I derived systems programming languages (like Unisys, IBM i and z/OS), so on those systems C is just another guest language and hardly anyone cares to use it beyond porting software to their POSIX runtimes.
  - kyberias 6y ago
    Right, that's why I don't understand why you had to bring up the fact that C was invented later. OP didn't claim anything related to that.
    - pjmlp 6y ago
      Because COBOL was seen as productive in the context of 1950's computing environments.
- protomyth 6y ago
  Unlike Fortran, COBOL really hasn't evolved in the C dominated world. Although C is really dominant on the platforms COBOL lives on.
  - pjmlp 6y ago
    What?!? Cobol has had its last revision in 2014, supports modules, OOP, and even has .NET and JVM backends. MicroFocus and Fujistsu also have frameworks for cloud deployments and writing microservices in Cobol. Almost no one cares about C on mainframes beyond porting some POSIX stuff, or running Aix/Linux on an hypervisor.
    - protomyth 6y ago
      That's basically it, no one cares about C on the mainframe so COBOL doesn't deal with the C competition and C flaws that fuel Go and Rust. COBOL itself has advanced but it doesn't have the same competition.
      - pjmlp 6y ago
        They don't care about C because mainframes always had better alternatives for systems programming, via PL/S, PL.8 and NEWP, as the three major surviving ones. Even BLISS and Mesa were better than C.
        protomyth 6y ago
        If I remember correctly OpenVMS was programmed in something else also. It would have been interesting if one of the PC operating systems had decided to use one of those languages. So, no C, no interest in 'I need a C replacement language', enterprise software is boring, so no COBOL replacement. Plus, I know of at least one vendor who did develop something but it is kept in-house. I did expect someone to develop yet another REXX to address this need.
    - skissane 6y ago
      > Almost no one cares about C on mainframes beyond porting some POSIX stuff, or running Aix/Linux on an hypervisor. I think, with Metal C, that's less true than it used to be. My understanding is that, for brand new z/OS components (e.g. Zowe, z/OSMF), IBM prefers Metal C to PL/X. It is also seeing increasing use by mainframe ISVs as a replacement for assembly and PL/X.

fortran77 6y ago

The column requirements are a holdover from the days of punchcards, where column 1 was reserved for JCL commands and some columns were reserved so cards could be numbered and sorted by mechanical means.

kens 6y ago
Many of IBM's early mainframes could only read 72 columns from a punch card, which is why Fortran (and I assume COBOL) only used 72 columns. Specifically, the IBM 704 was a 36-bit machine and read punch cards one row at a time, filling two 36-bit words. There was a wiring panel that let you select any 72 columns to read, but obviously using the first 72 columns was most sensible. If you punched sequence numbers in the ignored columns 73-80, you could use an electromechanical card sorter to put the cards back in order if you dropped them.
- fortran77 6y ago
  > if you dropped them. Or if someone shuffled them (as we used to do in the computer room to people who annoyed us.)
- praptak 6y ago
  My professor told us of a technique he used to recover from stack drops. Draw a pattern with a felt tip pen across the side of the stack (on the edges of the cards). This way a quick glance can tell you if the stack is out of order and it's also faster to sort manually.