[HN Gopher] Why COBOL Isn't the Problem
___________________________________________________________________
Why COBOL Isn't the Problem
Author : fanf2
Score : 8 points
Date : 2024-09-01 20:42 UTC (2 hours ago)
(HTM) web link (lucid.co)
(TXT) w3m dump (lucid.co)
| FrankWilhoit wrote:
| The problem is that the business processes (A) are not
| understood, (B) are not deterministic, (C) are too complicated to
| implement in maintainable code (in any language). Everything
| flows from the effort to conceal these facts. That is the reason
| for the market dominance of IBM, and Oracle, and Microsoft: they
| are effective as _partners in concealment_.
| mac3n wrote:
| Note that NJ called for _volunteers_ - in other words, free. The
| problem is that they just won't pay for maintenance
| karmakaze wrote:
| The post misses the advantages of other languages, specifically
| to make this easier:
|
| > Once you know how to program, learning programming languages is
| easy. Understanding existing programs is hard. Maintaining
| existing programs (in the form of what we call refactoring) is
| the most difficult part, by far.
|
| Static typing, with generics etc means that you can use more
| proven libraries that are well-understood and not custom/special
| in each instance.
|
| Immutable data-structures means you can reason about the function
| being applied without hidden side-effects, accelerating
| understanding of a new system and limiting unintended
| consequences, etc.
|
| I worked about a decade in the 90's at a company providing code
| generation and source analysis tools to _(banking, insurance,
| telco, etc)_ companies that used Cobol. The language can do
| everything _(I 've made Windows and OS/2 GUI programs with it)_,
| as can any Turing complete language, but it's not the best. The
| most I could say about it is that it's like Golang, where you're
| sort of steered away from over-complicating a program, but with
| Cobol you still don't have the tools to really simplify it
| either.
|
| People who don't choose and use better tools are _not_ part of
| the solution.
| LkpPo wrote:
| So what tools do you recommend?
| karmakaze wrote:
| When I worked at the company (now defunct), I had a several
| product suites to recommend, mostly based on metaprogramming
| and reuse of source components. Now I don't have any skin in
| the game, and leave it to those 'in the thick of it' to
| decide.
| LkpPo wrote:
| As you compare with Golang, I expected an option that goes
| beyond the banking domain.
| jmclnx wrote:
| >The New Jersey nightmare
|
| I remember seeing articles that showed this specific issue was
| not COBOL itself, but the WEB front end(s) to that system. Seems
| they blamed COBOL for clicks.
|
| > The real problem is, and always has been, the fact that the
| failed systems hadn't been maintained properly.
|
| This is like Cyber Security on modern systems, cheap is always
| the way to go. Two different problems, same root cause.
| Management will always do it on the cheap.
|
| All and all a very good article.
| alexwasserman wrote:
| With old systems the catches always seem to be knowing the deep
| hidden why's to the encoded business rules and all the bugs, not
| just the high level goals and basic code.
|
| Older systems have tons and tons of business logic encoded in
| them to handle edge cases and those functions will be in odd
| places, and then downstream systems have tons of logic in them to
| handle (and expect) bugs that your original system has.
|
| Saying "let's rewrite a System that does X" is fine, but you also
| need to know all the arcane business rules and weird bugs in the
| system that aren't nicely spelled out in docs, or requirements,
| or some config file, but are nested deep deep inside in the app,
| hidden in unexpected places. The complex interactions of these
| functions generates the complexity, not just "Cobol". 50 years of
| rushed additions of weird rules to handle years past incidents or
| business logic changes.
|
| Especially with old finance, insurance, and other systems that
| have this sort of longevity the original people who knew the
| why's have long since left. Any attempts to optimize, fix rules,
| fix bugs etc will produce a beautiful new clean system that's
| performant and simple and doesn't work at all.
| bdw5204 wrote:
| The specific problem with COBOL is that COBOL is both a language
| that was badly designed on the day it was created and that there
| is a stigma against programmers who have worked with it. This
| stigma is also a problem for other languages such as Visual Basic
| and PHP and it can make it harder to find programmers willing to
| work in those languages. Nobody wants to be "unemployable"
| because they worked in a stigmatized programming language even
| though the idea of stigmatizing programming languages is
| objectively idiotic.
|
| This wouldn't be a problem if organizations that are still using
| COBOL code would pay high salaries for COBOL programmers because
| there are people who are only writing code for the money who'd be
| happy to work with a terrible programming language if it makes
| them money. But they generally also want to pay antiquated
| salaries from decades ago for COBOL jobs if they even offer a
| salary at all. Because they would have migrated their system off
| of COBOL decades ago if they actually cared about properly
| maintaining it!
___________________________________________________________________
(page generated 2024-09-01 23:01 UTC)