6 ms·

I think people tend to under estimate how primitive COBOL is. For example, COBOL does not have variables. Instead, COBOL programs have a raw memory buffer cal

I think people tend to under estimate how primitive COBOL is. For example, COBOL does not have variables. Instead, COBOL programs have a raw memory buffer called working storage with named character offsets called records. Both working storage and records can be treated as a raw memory array and it was a common practice to do so. In an analysis of a 5 million line COBOL code base, about 60% of the programs used this feature.

ydr45 6y ago
You are also somewhat describing C, in one manner of speaking. Yes, C helps you with syntactic approaches to manage stack and locals, but a large amount of written C operates exactly as you describe for a wide, wide variety of useful reasons from embedded to DSP to OS development to performance-sensitive code (when needed). Most assembly language architectures operate the same way. There are strong arguments for the mechanical symmetry and sympathy this provides. Even Erlang or Haskell or JavaScript eventually operate in such an environment, where “variables” are memory offsets parsed a certain way, because that is the inescapable operating model of a modern computer processor. That being hidden from high-level programmers does not make it primitive; it makes it useful, increasingly arcane, valuable knowledge in the right hands. Until one understands this thoroughly, as in knowing when a C union would be useful, as one example, there is always more to learn to improve even high-level programming. Primitive is not the right word to use here. Low-level, perhaps, but the antonym of high-level is very rarely “primitive,” depending on what you’re doing. Yours is an interesting take given the article’s context.
- GartzenDeHaes 6y ago
  Yes. A lot of COBOL compilers are designed to interoperate with C using a struct and unions as an overlay for working storage. It works, but it's not a convenient way or natural way to program in C.
  - ydr45 6y ago
    That depends on how long your memory is regarding C. Working that way was natural and idiomatic C, once upon a time. It reflects the computer, remember.
    - GartzenDeHaes 6y ago
      To be clear, it's one struct consisting of char arrays and unions of char arrays.
      - ydr45 6y ago
        Yes. I was aware when I said that. C predates POSIX-like application development and grew into being useful in that role. Particularly in the sciences a lot of that COBOL arena influence went into C programs and it worked just fine. Still does. One way of looking at modern data science approaches like NumPy is reinventing array sorcery like that without the sharp edges of bare pointers, which definitely makes calculation accessible to more people (with less error). That doesn’t indict alternative approaches, however. Again, right hands, right job. Hiding the computer from the programmer is not automatically better in the general case. It’s better in many, usually in industry. That’s a subtle distinction and fully understanding it will command a salary differential going forward, for a few reasons. Not understanding it is how you get a $500k AWS bill for Spark to process a few billion records that fit in RAM on a laptop.
- woah 6y ago
  Primitive is the right word if expensive, error prone human programmers spend most of their time doing work that compilers are much better at.
- Spooky23 6y ago
  The difference is that COBOL was intended to be coded by very low skill people. I’m familiar with one system that was initiated in the mid 1970s with 15 million lines of COBOL. The vast majority is cut and paste dreck that does god knows what. There’s lots of bad C code, but in many ways the cobol stuff is the equivalent of some crazy collection of interlinked excel files.
  - pjmlp 6y ago
    About the same age as UNIX.
- TheCoelacanth 6y ago
  That's definitely the case with C as well, which is why no one but a complete lunatic would write random business software in C.
cratermoon 6y ago
It is very primitive. In some ways, it's more primitive than command.com. But, it does math on fixed-decimal numbers that is almost completely unlike IEEE floating point, but it does it in a way that makes accountants happy. If you have money and a ledger, COBOL does what you want.
- sonthonax 6y ago
  Is that because it has a runtime decimal library that’s implemented a certain way, or because it has a native data type that uses the processor’s BCD registers? I’m curious to know if these COBOL programs actually depend on IBM mainframes because of that.
  - rbanffy 6y ago
    It depends on hardware support. I’m not aware of anything that has it besides mainframes, but if it’s not there, software emulation is used. Using IEEE floats for money often has... amusing results.
    - sonthonax 6y ago
      x86 has had BCD support since before I was born. And, as far as I know, when compiling for a platform that's missing a fundamental datatype, it's usually the compiler that adds the missing type as a runtime. See for example this, a software float for crappy ARM processors. https://github.com/gcc-mirror/gcc/blob/16e2427f50c208dfe07d07f18009969502c25dc8/libgcc/config/arm/ieee754-sf.S https://github.com/gcc-mirror/gcc/blob/16e2427f50c208dfe07d0... I was more so wondering, if a COBOL compiler (given how low level the language is) makes a lot of assumptions about the platform. Even assumptions about potential quirks.
      - rbanffy 6y ago
        I’m no COBOL expert, but the way a COBOL program sees the machine is very different from what a C program does. I never saw anything resembling assumptions about native data types or anything similarly low level. And I never imagined an x86 could deal with decimal floats.
sonthonax 6y ago
I think the culture within COBOL is equally backwards. As someone else said, it’s targeted at people who’s main skill isn’t software engineering, but understanding of business logic. I was once spoke to a consultant who in a past life fixed big COBOL projects. He said that one of the common technological and organisational challenges he faced was getting people to use ‘malloc’. Apparently there are COBOL programs that just SEGFAULT when the input reaches a certain size, and some developer has to change an array allocation size. COBOL developers would be hostile to the idea of dynamic memory allocation, and he’d have to explain that the rest of the world had been doing that for the last 30 years.
- kitd 6y ago
  I remember having a "malloc" moment moving from fortran to c. "You mean ... I can just ask for more memory?!"
  - kergonath 6y ago
    Interestingly, since Fortran 90, using dynamical allocation is much more developer-friendly than in C (I know, low bar). Fortran’s allocatable variables can’t leak memory, can’t be used after being deallocated, and can’t be deallocated twice. Bounds checking is also trivial and all decent compilers have a flag to do it automatically.
    - necheffa 6y ago
      The only problem is that the rest of the language is developer unfriendly, plus you have old school FORTRAN programmers who think it is perfectly acceptable and modern to use statically allocated arrays on the stack just because they aren't COMMON blocks.
      - kergonath 6y ago
        Fair enough. The language has quite a bit of bagage and some habits are hard to break. That said, it is not unpleasant to use for numerical codes, when you’re not working with people stuck in 1977 (so, no common blocks, everything in modules, decent array syntax, etc). It fits its niche quite well, with Python for everything else.

ydr45 6y ago

You are also somewhat describing C, in one manner of speaking. Yes, C helps you with syntactic approaches to manage stack and locals, but a large amount of written C operates exactly as you describe for a wide, wide variety of useful reasons from embedded to DSP to OS development to performance-sensitive code (when needed). Most assembly language architectures operate the same way. There are strong arguments for the mechanical symmetry and sympathy this provides. Even Erlang or Haskell or JavaScript eventually operate in such an environment, where “variables” are memory offsets parsed a certain way, because that is the inescapable operating model of a modern computer processor. That being hidden from high-level programmers does not make it primitive; it makes it useful, increasingly arcane, valuable knowledge in the right hands. Until one understands this thoroughly, as in knowing when a C union would be useful, as one example, there is always more to learn to improve even high-level programming. Primitive is not the right word to use here. Low-level, perhaps, but the antonym of high-level is very rarely “primitive,” depending on what you’re doing. Yours is an interesting take given the article’s context.

GartzenDeHaes 6y ago
Yes. A lot of COBOL compilers are designed to interoperate with C using a struct and unions as an overlay for working storage. It works, but it's not a convenient way or natural way to program in C.
- ydr45 6y ago
  That depends on how long your memory is regarding C. Working that way was natural and idiomatic C, once upon a time. It reflects the computer, remember.
  - GartzenDeHaes 6y ago
    To be clear, it's one struct consisting of char arrays and unions of char arrays.
    - ydr45 6y ago
      Yes. I was aware when I said that. C predates POSIX-like application development and grew into being useful in that role. Particularly in the sciences a lot of that COBOL arena influence went into C programs and it worked just fine. Still does. One way of looking at modern data science approaches like NumPy is reinventing array sorcery like that without the sharp edges of bare pointers, which definitely makes calculation accessible to more people (with less error). That doesn’t indict alternative approaches, however. Again, right hands, right job. Hiding the computer from the programmer is not automatically better in the general case. It’s better in many, usually in industry. That’s a subtle distinction and fully understanding it will command a salary differential going forward, for a few reasons. Not understanding it is how you get a $500k AWS bill for Spark to process a few billion records that fit in RAM on a laptop.
woah 6y ago
Primitive is the right word if expensive, error prone human programmers spend most of their time doing work that compilers are much better at.
Spooky23 6y ago
The difference is that COBOL was intended to be coded by very low skill people. I’m familiar with one system that was initiated in the mid 1970s with 15 million lines of COBOL. The vast majority is cut and paste dreck that does god knows what. There’s lots of bad C code, but in many ways the cobol stuff is the equivalent of some crazy collection of interlinked excel files.
- pjmlp 6y ago
  About the same age as UNIX.
TheCoelacanth 6y ago
That's definitely the case with C as well, which is why no one but a complete lunatic would write random business software in C.

cratermoon 6y ago

It is very primitive. In some ways, it's more primitive than command.com. But, it does math on fixed-decimal numbers that is almost completely unlike IEEE floating point, but it does it in a way that makes accountants happy. If you have money and a ledger, COBOL does what you want.

sonthonax 6y ago
Is that because it has a runtime decimal library that’s implemented a certain way, or because it has a native data type that uses the processor’s BCD registers? I’m curious to know if these COBOL programs actually depend on IBM mainframes because of that.
- rbanffy 6y ago
  It depends on hardware support. I’m not aware of anything that has it besides mainframes, but if it’s not there, software emulation is used. Using IEEE floats for money often has... amusing results.
  - sonthonax 6y ago
    x86 has had BCD support since before I was born. And, as far as I know, when compiling for a platform that's missing a fundamental datatype, it's usually the compiler that adds the missing type as a runtime. See for example this, a software float for crappy ARM processors. https://github.com/gcc-mirror/gcc/blob/16e2427f50c208dfe07d07f18009969502c25dc8/libgcc/config/arm/ieee754-sf.S https://github.com/gcc-mirror/gcc/blob/16e2427f50c208dfe07d0... I was more so wondering, if a COBOL compiler (given how low level the language is) makes a lot of assumptions about the platform. Even assumptions about potential quirks.
    - rbanffy 6y ago
      I’m no COBOL expert, but the way a COBOL program sees the machine is very different from what a C program does. I never saw anything resembling assumptions about native data types or anything similarly low level. And I never imagined an x86 could deal with decimal floats.

sonthonax 6y ago

I think the culture within COBOL is equally backwards. As someone else said, it’s targeted at people who’s main skill isn’t software engineering, but understanding of business logic. I was once spoke to a consultant who in a past life fixed big COBOL projects. He said that one of the common technological and organisational challenges he faced was getting people to use ‘malloc’. Apparently there are COBOL programs that just SEGFAULT when the input reaches a certain size, and some developer has to change an array allocation size. COBOL developers would be hostile to the idea of dynamic memory allocation, and he’d have to explain that the rest of the world had been doing that for the last 30 years.

kitd 6y ago
I remember having a "malloc" moment moving from fortran to c. "You mean ... I can just ask for more memory?!"
- kergonath 6y ago
  Interestingly, since Fortran 90, using dynamical allocation is much more developer-friendly than in C (I know, low bar). Fortran’s allocatable variables can’t leak memory, can’t be used after being deallocated, and can’t be deallocated twice. Bounds checking is also trivial and all decent compilers have a flag to do it automatically.
  - necheffa 6y ago
    The only problem is that the rest of the language is developer unfriendly, plus you have old school FORTRAN programmers who think it is perfectly acceptable and modern to use statically allocated arrays on the stack just because they aren't COMMON blocks.
    - kergonath 6y ago
      Fair enough. The language has quite a bit of bagage and some habits are hard to break. That said, it is not unpleasant to use for numerical codes, when you’re not working with people stuck in 1977 (so, no common blocks, everything in modules, decent array syntax, etc). It fits its niche quite well, with Python for everything else.