4 ms·

No, it wasn't. Non-programmers didn't program in COBOL. Non-programmers generally lacked access to IDEs (even basic TSO workflows), compilers, and computer time

No, it wasn't. Non-programmers didn't program in COBOL. Non-programmers generally lacked access to IDEs (even basic TSO workflows), compilers, and computer time, let alone JCL and data sets. COBOL was intended for business cases for which FORTRAN was ill-suited, and COBOL shops generally didn't need science/math implementations. Even PL/1 and RPG required a degree of programming skill.

jacquesm 7y ago
Actually, yes it was, in a way. COBOL was intended to do away with programmers and to allow their managers to interact with the computer directly. Programmers of the day worked with machine language and generally took forever to deliver bits and pieces of functionality due to the low level nature of their tools. The idea behind COBOL was that the compiler would take a high level specification (the 'source code') which any competent person should be able to put together rather than that this specification had to be handed to the programmers. Of course, the end result was that we ended up with just one layer of abstraction and programmers were in more demand than ever before because of their increased productivity, and the 'managers' ended up being programmers themselves. This then led to the schism between 'systems' programmers (those that understood assembly) and 'applications' programmers, those that only worked in high level languages. When I started working professionally in IT this division was still quite visible.
- masonic 7y ago
  I'm guessing that you never worked in a COBOL shop.
  - jacquesm 7y ago
    Your guess is wrong.
- K0SM0S 7y ago
  “When I started working professionally in IT this division [the schism between 'systems' programmers and 'applications' programmers] was still quite visible.” I think you nailed a rather fundamental trait (spectrum) in programmers that carries on, morphing along with times. From systems to business logic, or from the 'container' (pun not intended) to the 'content', and dare I generalize: from a strictly technical eye to a strictly goal/business mindset (again, this is a spectrum, everything in-between exists, all flavors contribute to make a world). The cliche would be your low-level C/Rust guy versus some frontend Flash/Js person; but this is oversimplifyling (C person might be very goal-driven with a business approach; Js person might be a performance expert). Reality speaks more of an engineer's world view so to speak: from "bottom -> up" (those that assemble elementary pieces, that need to crack the puzzle by understanding each component, like Lego) to "top -> down" (those that rather manipulate large abstract/complex entities as 'black boxes' and rather work on their structure, the graph, dimensions, and shift behavior thusly with surgical cost-effective changes). Oh just my 2cts I'm probably rambling. I just know that these two extremes on the spectrum are what we battle with for every decision we make, if we are aware enough of both sides. (Is that a blessing or a curse?.. you tell me!) I think it's why, deep down, we still (and might always) search for 'the next C' (cue Rust, Go, D, depends on use-cases I suppose), or why some people are almost principled advocates of the WebAssembly paradigm in complement or replacement of the Js ecosystem. These are the technical people of the spectrum. The high-level engineers are more about pushing for interoperability, available skill pool, maintainability. It's just that 'programming' as a skill now pertains to three dozen very different jobs so the general line is much fuzzier than in the 1950-60-70's; but I think it's a product of human intelligence, whether how we think or how we build our tools, our machines. Historical parallels, yadi yada. The mainframe situation, I think, is even more telling. Every programmer under the Sun has thought of ways to replace COBOL, and there are decent candidates. But the business side of us, of above, of reality, has mainframes still running on COBOL. Because as a 'black box', it works; the benefits of a rewrite have not yet justified their cost. I know a solid team usually requires at least 1 of each 'sides' of the spectrum, keeps everyone else honest (as engineers in a problem space).
  - thanatropism 7y ago
    Then there are mathematicians and quants, like me: breastfed on Matlab, weaned on Python, claim a much deeper understanding of algorithms and code factoring techniques than front-end jockeys, but still shudders at memory management (other than by preallocating matrices/numpy arrays), devops and other practices that are all in a day's work for "man's man programmers". Granted, we're precisely what PL authors had in mind from time to time (eg with SQL): nonprogrammers who can write domain code. But because our training goes into proving big-O complexity, etc. front-end jockeys look at us as if we're capital-P programmers.
- AdieuToLogic 7y ago
  > COBOL was intended to do away with programmers and to allow their managers to interact with the computer directly. This is incorrect. COBOL has as its definition “COmmon Business Oriented Language.” It can be argued that COBOL was the first compiler widely used, but to say it was meant to “do away with programmers” is to ignore that application programmers were the intended beneficiaries of no longer having to work strictly in machine code.
quietbritishjim 7y ago
> Non-programmers didn't program in COBOL. This doesn't contradict the parent comment. They claimed that COBOL was intended to be used by non-programmers, not that it necessarily succeeded. (It's also possible that it succeeded by its original intention but appeared to fail as the definition of "programmer" changed i.e. if it originally meant someone who understood assembler but it later came to mean someone who spent their time writing programs. I could imagine this being the case, as someone who writes javascript today (or even VBA for Excel!) isn't really comparable to someone who wrote code in the 1950s, but both might be called "programmers".) Having said all that, for what little it's worth, in a software history course I was taught that COBOL was intended to be written by programmers (in the full-time professional sense) but be readable by managers. I imagine that it did not even succeed at that.
DonaldFisk 7y ago
An operating system, MULTICS, was written in PL/1.

jacquesm 7y ago

Actually, yes it was, in a way. COBOL was intended to do away with programmers and to allow their managers to interact with the computer directly. Programmers of the day worked with machine language and generally took forever to deliver bits and pieces of functionality due to the low level nature of their tools. The idea behind COBOL was that the compiler would take a high level specification (the 'source code') which any competent person should be able to put together rather than that this specification had to be handed to the programmers. Of course, the end result was that we ended up with just one layer of abstraction and programmers were in more demand than ever before because of their increased productivity, and the 'managers' ended up being programmers themselves. This then led to the schism between 'systems' programmers (those that understood assembly) and 'applications' programmers, those that only worked in high level languages. When I started working professionally in IT this division was still quite visible.

masonic 7y ago
I'm guessing that you never worked in a COBOL shop.
- jacquesm 7y ago
  Your guess is wrong.
K0SM0S 7y ago
“When I started working professionally in IT this division [the schism between 'systems' programmers and 'applications' programmers] was still quite visible.” I think you nailed a rather fundamental trait (spectrum) in programmers that carries on, morphing along with times. From systems to business logic, or from the 'container' (pun not intended) to the 'content', and dare I generalize: from a strictly technical eye to a strictly goal/business mindset (again, this is a spectrum, everything in-between exists, all flavors contribute to make a world). The cliche would be your low-level C/Rust guy versus some frontend Flash/Js person; but this is oversimplifyling (C person might be very goal-driven with a business approach; Js person might be a performance expert). Reality speaks more of an engineer's world view so to speak: from "bottom -> up" (those that assemble elementary pieces, that need to crack the puzzle by understanding each component, like Lego) to "top -> down" (those that rather manipulate large abstract/complex entities as 'black boxes' and rather work on their structure, the graph, dimensions, and shift behavior thusly with surgical cost-effective changes). Oh just my 2cts I'm probably rambling. I just know that these two extremes on the spectrum are what we battle with for every decision we make, if we are aware enough of both sides. (Is that a blessing or a curse?.. you tell me!) I think it's why, deep down, we still (and might always) search for 'the next C' (cue Rust, Go, D, depends on use-cases I suppose), or why some people are almost principled advocates of the WebAssembly paradigm in complement or replacement of the Js ecosystem. These are the technical people of the spectrum. The high-level engineers are more about pushing for interoperability, available skill pool, maintainability. It's just that 'programming' as a skill now pertains to three dozen very different jobs so the general line is much fuzzier than in the 1950-60-70's; but I think it's a product of human intelligence, whether how we think or how we build our tools, our machines. Historical parallels, yadi yada. The mainframe situation, I think, is even more telling. Every programmer under the Sun has thought of ways to replace COBOL, and there are decent candidates. But the business side of us, of above, of reality, has mainframes still running on COBOL. Because as a 'black box', it works; the benefits of a rewrite have not yet justified their cost. I know a solid team usually requires at least 1 of each 'sides' of the spectrum, keeps everyone else honest (as engineers in a problem space).
- thanatropism 7y ago
  Then there are mathematicians and quants, like me: breastfed on Matlab, weaned on Python, claim a much deeper understanding of algorithms and code factoring techniques than front-end jockeys, but still shudders at memory management (other than by preallocating matrices/numpy arrays), devops and other practices that are all in a day's work for "man's man programmers". Granted, we're precisely what PL authors had in mind from time to time (eg with SQL): nonprogrammers who can write domain code. But because our training goes into proving big-O complexity, etc. front-end jockeys look at us as if we're capital-P programmers.
AdieuToLogic 7y ago
> COBOL was intended to do away with programmers and to allow their managers to interact with the computer directly. This is incorrect. COBOL has as its definition “COmmon Business Oriented Language.” It can be argued that COBOL was the first compiler widely used, but to say it was meant to “do away with programmers” is to ignore that application programmers were the intended beneficiaries of no longer having to work strictly in machine code.

quietbritishjim 7y ago

> Non-programmers didn't program in COBOL. This doesn't contradict the parent comment. They claimed that COBOL was intended to be used by non-programmers, not that it necessarily succeeded. (It's also possible that it succeeded by its original intention but appeared to fail as the definition of "programmer" changed i.e. if it originally meant someone who understood assembler but it later came to mean someone who spent their time writing programs. I could imagine this being the case, as someone who writes javascript today (or even VBA for Excel!) isn't really comparable to someone who wrote code in the 1950s, but both might be called "programmers".) Having said all that, for what little it's worth, in a software history course I was taught that COBOL was intended to be written by programmers (in the full-time professional sense) but be readable by managers. I imagine that it did not even succeed at that.

DonaldFisk 7y ago

An operating system, MULTICS, was written in PL/1.