4 ms·

The spaghetti code in COBOL comes from the very tight coupling between concerns: the model, view and controller are generally all in the same. You'll have embed

The spaghetti code in COBOL comes from the very tight coupling between concerns: the model, view and controller are generally all in the same. You'll have embedded database queries, right next to form layout, right next to your actual code. While the language itself may be ANSI, the interfaces people use to actually display and store data are vendor specific. The closest analogy would be if you had some crazy late-90s Perl that relied on custom database and terminal drivers. There's not much of a bandaid you can put on this to "modernize it" other than a rewrite.

tablespoon 4y ago
> The spaghetti code in COBOL comes from the very tight coupling between concerns I thought the spaghetti code in COBOL came from liberal use of GOTOs (e.g. following the execution path of the code is like following the path of a single spaghetti noodle in a plate of spaghetti).
- ok123456 4y ago
  There's architectural spaghetti and there are lower levels of spaghetti. COBOL introduced alternatives to unconditional jumps in the 60s. You can convert unconditional jumps to different control flow structures through static analysis. Plusfort does this for FORTRAN pretty well. I'm sure there's an equivalent tool for COBOL somewhere. The problem isn't merely converting goto to PERFORM-TIMES. It's that deep in that loop you're also doing raw database operations, writing stuff to a IBM 3270 terminal, and triggering a batch job to the program monitor.
  - tablespoon 4y ago
    > There's architectural spaghetti and there are lower levels of spaghetti.... > The problem isn't merely converting goto to PERFORM-TIMES. It's that deep in that loop you're also doing raw database operations, writing stuff to a IBM 3270 terminal, and triggering a batch job to the program monitor. I'm not saying that's not a problem, just that it feels like it could be an anachronism to use "spaghetti code" to refer to that in the context of a COBOL program.

tablespoon 4y ago

> The spaghetti code in COBOL comes from the very tight coupling between concerns I thought the spaghetti code in COBOL came from liberal use of GOTOs (e.g. following the execution path of the code is like following the path of a single spaghetti noodle in a plate of spaghetti).

ok123456 4y ago
There's architectural spaghetti and there are lower levels of spaghetti. COBOL introduced alternatives to unconditional jumps in the 60s. You can convert unconditional jumps to different control flow structures through static analysis. Plusfort does this for FORTRAN pretty well. I'm sure there's an equivalent tool for COBOL somewhere. The problem isn't merely converting goto to PERFORM-TIMES. It's that deep in that loop you're also doing raw database operations, writing stuff to a IBM 3270 terminal, and triggering a batch job to the program monitor.
- tablespoon 4y ago
  > There's architectural spaghetti and there are lower levels of spaghetti.... > The problem isn't merely converting goto to PERFORM-TIMES. It's that deep in that loop you're also doing raw database operations, writing stuff to a IBM 3270 terminal, and triggering a batch job to the program monitor. I'm not saying that's not a problem, just that it feels like it could be an anachronism to use "spaghetti code" to refer to that in the context of a COBOL program.