4 ms·

Train them. We do it all the time with new hires or old pals for any mainstream or not language. I saw teams do marvels in a quarter in completely new languages

Train them. We do it all the time with new hires or old pals for any mainstream or not language. I saw teams do marvels in a quarter in completely new languages, no matter how far the paradigm. Not claiming COBOL is easy (no idea) but can't be an impossible task. Is probably harder to keep people engaged

smt88 6y ago
From what I understand talking to someone who gets paid enormous amounts of money to occasionally update COBOL systems in heavy industry, working on COBOL is drudgery. It might be difficult to find a substantial number of people who actually want to be trained in COBOL.
- quantified 6y ago
  There are a lot of developers who would like to be paid enormous amounts of money. I wonder if the public sector pays well enough to generate the desire to learn, though. I myself can handle a lot of drudgery for $350k a year.
  - agdtdudhegsjhs 6y ago
    100% the money is the issue.
- p_l 6y ago
  So is Java, and my last stint with Python definitely feels drudge-like too. Offer enough real money and appropriately structured career path (especially one that doesn't lead someone down path of "one language programmer") and you might find a team fast.
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.

smt88 6y ago

From what I understand talking to someone who gets paid enormous amounts of money to occasionally update COBOL systems in heavy industry, working on COBOL is drudgery. It might be difficult to find a substantial number of people who actually want to be trained in COBOL.

quantified 6y ago
There are a lot of developers who would like to be paid enormous amounts of money. I wonder if the public sector pays well enough to generate the desire to learn, though. I myself can handle a lot of drudgery for $350k a year.
- agdtdudhegsjhs 6y ago
  100% the money is the issue.
p_l 6y ago
So is Java, and my last stint with Python definitely feels drudge-like too. Offer enough real money and appropriately structured career path (especially one that doesn't lead someone down path of "one language programmer") and you might find a team fast.

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.