3 ms·

COBOL is really, really bad from the point of view of a developer. It's frustrating, verbose, and tends to produce huge spaghetti code. Good developers - those

by kimi 6y ago

COBOL is really, really bad from the point of view of a developer. It's frustrating, verbose, and tends to produce huge spaghetti code. Good developers - those who like what they do - won't touch it with a stick. People do OCaml, Haskell, Clojure in their spare time and C# and Java at work - but nobody codes COBOL in their spare time. People code in Assembly, sometimes in hand-assembled hexadecimal format, but not COBOL. It's a job, usually a boring one.

arp242 6y ago
I think good developers don't really care so much about which language they work with, but rather care about solving interesting problems. The language is just at tool; being fixated on OCaml or Haskell or whatnot seems like mistaking a tool for a goal. I'd love the opportunity to work one of these applications. It's different from anything I've done before and all other things being equal is certainly seems more interesting than working on the 6162th ride hailing app or some ad-tech meaningless nonsense. It also just so happens to be written in COBOL.
- earthboundkid 6y ago
  There are different kinds of developers. Some like solving problems and wouldn’t be bothered by COBOL. Others are more aesthetically motivated. https://blog.carlmjohnson.net/post/2017/what-kind-of-programmer/ https://blog.carlmjohnson.net/post/2017/what-kind-of-program...
Zenst 6y ago
> COBOL is really, really bad from the point of view of a developer. It's frustrating, verbose, and tends to produce huge spaghetti code. THAT is true of any language, the fact that COBOL has divisions does make it a bit easier. But you can also do very structored code in COBOL and code without using the GOTO verb. However many systems and code born the scars of the time. Fast code really did make a difference and was measurable in cost a lot more upon an expensive mainframe and when your processing near on a million records, very noticable in costs. So GOTO got used a lot, as coding for exception handling using structured programming like JSP (Jackson Structured Programming - the thing in the COBOL days) whilst doable, wasn't the fastest code and equally, not that readable if you didn't know the methodology behind JSP. But over time you don't see the language, you see it from a data perspective and with that, code however laid out becomes easier to manage and by that, anybody else's code will look a bit yuk to you. Indeed it is rare to work on somebody else's code and come away with a warm fuzzy glow.

by kimi 6y ago

arp242 6y ago

I think good developers don't really care so much about which language they work with, but rather care about solving interesting problems. The language is just at tool; being fixated on OCaml or Haskell or whatnot seems like mistaking a tool for a goal. I'd love the opportunity to work one of these applications. It's different from anything I've done before and all other things being equal is certainly seems more interesting than working on the 6162th ride hailing app or some ad-tech meaningless nonsense. It also just so happens to be written in COBOL.

earthboundkid 6y ago
There are different kinds of developers. Some like solving problems and wouldn’t be bothered by COBOL. Others are more aesthetically motivated. https://blog.carlmjohnson.net/post/2017/what-kind-of-programmer/ https://blog.carlmjohnson.net/post/2017/what-kind-of-program...

Zenst 6y ago

> COBOL is really, really bad from the point of view of a developer. It's frustrating, verbose, and tends to produce huge spaghetti code. THAT is true of any language, the fact that COBOL has divisions does make it a bit easier. But you can also do very structored code in COBOL and code without using the GOTO verb. However many systems and code born the scars of the time. Fast code really did make a difference and was measurable in cost a lot more upon an expensive mainframe and when your processing near on a million records, very noticable in costs. So GOTO got used a lot, as coding for exception handling using structured programming like JSP (Jackson Structured Programming - the thing in the COBOL days) whilst doable, wasn't the fastest code and equally, not that readable if you didn't know the methodology behind JSP. But over time you don't see the language, you see it from a data perspective and with that, code however laid out becomes easier to manage and by that, anybody else's code will look a bit yuk to you. Indeed it is rare to work on somebody else's code and come away with a warm fuzzy glow.