[HN Gopher] Watsonx: IBM's code assistant for turning COBOL into...
___________________________________________________________________
Watsonx: IBM's code assistant for turning COBOL into Java
Author : Anon84
Score : 65 points
Date : 2023-12-03 16:31 UTC (6 hours ago)
(HTM) web link (www.pcmag.com)
(TXT) w3m dump (www.pcmag.com)
| discmonkey wrote:
| Classic misunderstanding of programming languages. The only thing
| stopping cobol from being "known" is these companies paying for
| it.
| SillyUsername wrote:
| Chicken and egg, companies stop paying, say no devs, devs not
| interested as no companies paying for it. Tell me that COBOL to
| Java porting pays $150K p/a and I'll be happy to take the job,
| at least for a year or 3.
| adra wrote:
| You work that as a contractor easy if you can find them. The
| problem is they're rarely hiring one offs to do this because
| these companies don't have engineering cultures, which is why
| they contract this shit to system integrators of the world
| like IBM, then they outsource the work to shoddy consultancy
| shops to maximize their profits doing basically zero work. If
| everything goes exceptionally bad (which it did at least in
| the case I was involved in), then they hire competent
| contractors to come in and save them from frighteningly large
| law suits. That's the new dev cycle of these legacy
| modernizations.. ahh
| mlhpdx wrote:
| It's more than that. If you spend a couple or more years
| learning to maintain those systems, where else will you work?
| Will you find a co-founder or investor for a COBOL based system
| when you go "entrepreneur"? Maybe, but it better be a damn
| strong niche.
|
| Not moving forward with the software industry is a weird kind
| of conceit that separates these companies from the mainstream
| by far more than money.
| rightbyte wrote:
| It still comes down to paying enough money for someone to do
| it. Pay me twice what I make now and I'll switch to coding
| absurd legacy all-caps COBOL systems in a heart beat.
| Probably less then that too.
| serallak wrote:
| I don't think it'd take two years to learn cobol, it should
| be less than that.
|
| But it will take much more than that to learn the gnarly
| codebase in use in those shops...
|
| And that is a skill that is certainly not transferable.
| exhilaration wrote:
| _I don 't think it'd take two years to learn cobol, it
| should be less than that._
|
| There's a comment in this thread from a former consultant
| that completed a 4 week COBOL bootcamp before being sent to
| a client to write code!
| wombatpm wrote:
| It's not the language, it's the business rules and
| history.
|
| Why is this input file loaded and rechecked 3 times?
| Because 30 years ago a file load failed, breaking end of
| quarter reports. This was the fix: if we can read that
| file three times and it doesn't change then we know it's
| good
| ajross wrote:
| Pretty much exactly. There are wizards at Project Zero doing
| reverse engineering of systems at the hardware microcode level.
| Our own kens shows up every few weeks with transistor level
| explanations of devices whose designers are long since retired.
|
| And we're supposed to believe that no one in the world can
| figure out a batch-processed COBOL accounting system? Please.
| The talent is there, it's just that no one responsible for
| these systems wants to hire at that level. But in extremis they
| will, and the world will survive.
| tw04 wrote:
| Plenty of folks know COBOL - the problem is you need to entice
| someone YOUNG to learn it, which basically means overpaying them.
| If I'm an 18-year-old why would I focus on learning a programming
| language that puts me in a job with 0 chance of advancement? Sure
| I'm irreplaceable to the company, but I've also only got a
| handful of other places I could go if they treat me poorly or
| sunset their mainframe.
| tobyjsullivan wrote:
| I'd be curious to know how we're defining "overpaying" here.
| These companies have effectively accrued 50+ years of technical
| debt (they could have migrated off COBOL decades ago).
| Meanwhile, based on my limited experience with these
| industries, I'd be surprised if they even offer market rates to
| new hires.
| nobodyandproud wrote:
| Let me up the ante. Why do we believe COBOL is yech-debt?
| pixl97 wrote:
| Hell, after seeing both kind of applications (java vs
| cobol) by these bank/financial companies I am of the
| opposite mind.
|
| Those COBOL applications will keep working until the sun
| burns up or inflation makes the numbers so long they no
| longer fit in bounds.
|
| The java applications they write should fill you with
| terror.
| trealira wrote:
| Why do you say the Java applications at banks and
| financial institutions so bad? I'm not trying to
| contradict you or say you're wrong; I just want to know
| why.
|
| Not having ever seen this kind of software, I would
| assume that the existing COBOL applications are good
| simply because all the bad COBOL code was probably
| scrapped decades ago, an example of survivorship bias.
| pixl97 wrote:
| Survivorship bias is bad if you're making a statement
| like "All old houses were good because we still see some
| old houses around".
|
| But if you already have an old house that's working it's
| worth considering survivorship bias if you're building a
| new house to replace it. That new house is much less
| likely to survive that bias filter. Getting the new house
| as good as the old house will likely take you far more
| time and money than you expected.
|
| And the same is with software. For example including
| outside libraries in your application makes the code much
| easier to write. You don't have to reproduce
| functionality. But libraries typically work like kitchen
| sinks. You may not have wanted a garbage disposal, but
| your library came with it and for the next X years your
| application is around you have to make sure that disposal
| doesn't catch fire. From the security side you have to
| make sure there is no code interaction with disposal or
| any of the other 'household' functions its including that
| you're not testing for.
|
| At least in what I do for a living which is in the field
| to code security reviews (I don't do these reviews
| myself, but I work with the teams that do), the amount of
| security issues that get caught in these new applications
| in a multi round process, at least to me is staggering.
| It has to be a multi round process as we see the issues
| being reintroduced we'd call out in previous sessions.
| Quite often in these larger organizations the programming
| teams are so unstable that between our first calls and
| last calls the entire team working on it will have
| rotated out.
| tobyjsullivan wrote:
| If there's a shortage of developers who understand the
| language, then the team cannot properly understand the
| application (as per TFA).
|
| If nobody can understand the application, it cannot be
| modified.
|
| If an application cannot be modified, its value will
| continuously decrease with time.
|
| That decrease in value, as well as the projected cost of
| building a replacement, is tantamount to accruing interest
| on a debt.
|
| They could have reduced that debt by moving to functionally
| equivalent but more commonly taught languages back when
| their team could still understand the system.
|
| It wasn't necessarily wrong for them to accrue this debt -
| after all, banks and these monolithic institutions are
| masters at effectively utilizing debt. However, the
| practice may have become habitual and it looks like they
| might be in pretty deep at this point.
| nobodyandproud wrote:
| Many systems are obscure or niche, but that isn't tech
| debt.
|
| What you're describing is a management and leadership
| failure.
|
| In US tech we have an overabundance of Type A people in
| it for the money, but there are plenty of smart Type Bs
| who just want stability and a life, for a fraction of the
| going SV engineering pay.
|
| You have to wonder why the latter is impossible for
| American companies to achieve.
| rabuse wrote:
| So let the market decide their fate, as their outdated crap
| comes to a halt with no one to maintain it.
| exhilaration wrote:
| The answer is India. Just Google India and COBOL, there's
| tons of schools teaching it. So if Watson doesn't work out
| for you, IBM is happy to sell you offshore consulting
| services the bridge the gap! This is all win-win for IBM --
| you can can keep your $200 million mainframe service contract
| or hire IBM to (kinda? maybe?) move you to something more
| modern.
| rini17 wrote:
| How do you decide which language has better chances for
| advancement anyway? Pick some hot bleeding edge Microsoft tech
| instead and learn it only to get obsolete in few years.
|
| You will have to eventually relearn regardless what you pick.
| And I can't believe having some COBOL in the CV will be an
| issue for anybody.
| Nextgrid wrote:
| The problem isn't knowledge of the programming language. The
| problem is the developer experience not just within the
| language but the runtime environment it's executed in, as well
| as the corporate environment where such systems are used.
|
| The developer experience is terrible, it's a completely
| parallel world that diverged about 25 years ago from what we're
| used to, and it's not particularly good. Furthermore, it's so
| obscenely priced that it will be never used for anything new
| (and forget personal projects), so career-wise it's a dead-end
| and confines you to only ever work in existing legacy
| deployments.
|
| The "corporate experience" for the lack of a better word is
| terrible too. Companies that run this have zero engineering
| culture (if they did they would've finished their migration off
| COBOL long ago) and developer positions have about the same
| amount of respect and political influence as the janitor. There
| are much better options pretty much anywhere else, so the only
| remaining people are too mediocre to get those better
| opportunities, so it's not a good environment to learn from
| either.
|
| Migrating off COBOL (or any legacy system) _is_ possible -
| after all, startups have built similar systems _from scratch_.
| The problem is that this requires a competent engineering team
| and you won 't get that without a good engineering culture and
| embracing engineering as one of the key pillars of your
| business and giving it the resources and respect it deserves.
| jalk wrote:
| There seems to be plenty of cobol transpilers - anybody know why
| they can't use those. Immediate thought was it's just beating on
| the dead Watson horse.
| kjs3 wrote:
| If they worked as effectively as they were touted, they'd have
| cleared out the cobol.
| pixl97 wrote:
| No really, in fact I'd say the opposite.
|
| The issue with COBOL is any old idiot can't write it. If
| someone is touching the COBOL they are going in and making
| minor changes/expansions to an application that is older than
| the average HN user and those changes and expectations are
| well defined.
|
| With Java and/or language of the day your cheapest run of the
| mill contractor given exceptionally poor instructions will
| crank out X LOC per day where X is the required output for
| them to keep their job. Maintaining that code will be some
| other bastards problem.
| kjs3 wrote:
| I have no idea how that's the opposite of what I said.
| Transpilers haven't worked not because of how much or
| little the replacements are paid, or how well they do their
| job, but because there's more to moving from one
| computational ecosystem to another than just the language.
| grammie wrote:
| Correct, language transpilation is the easy bit, ensuring
| that execution and behavoir is the same as on the
| mainframe is tough, but also solved.
| grammie wrote:
| Heirloom Computing, I am CTO, have transpilers for cobol and
| pl/1. code transpilation is the easy part. Create a Grammer
| for the source language, generate the ast, transform the ast
| to the target language ast and generate the code. Now make
| that generated code run and behave the same way as on the
| mainframe and give it all the subsystems that exist on the
| mainframe for transaction, file handling, security etc. This
| is the part that is difficult. Fortunately it's already
| solved and in production with our clients.
|
| So transpilers do work and are in production but our biggest
| competitor is inertia.
| dun44 wrote:
| Regarding IBM's use of technology widely known for hallucinating
| to translate sensitive source code: it sounds weird you think the
| primary objective here is to deliver something that properly
| translates from one language to another. But it is not - the
| primary objective is to get money from customers and investors.
| Delivering something that works is secondary, and honestly,
| optional.
|
| Many things in IT start making a whole lot more sense once you
| reexamine your beliefs about their purpose.
| datadrivenangel wrote:
| Especially for IBM! See IBM Watson for details.
| ProjectArcturis wrote:
| I guess translating COBOL is somewhat less embarrassing than
| Watson being used to predict fantasy football scores.
| elteto wrote:
| These systems have not been running untouched for 60 years.
| Regulatory environments change almost constantly and the code has
| to be updated accordingly. I don't personally know anyone writing
| COBOL but I'm certain there's plenty of people doing it. And to
| change the code you have to know it. So there's really no 60 year
| old code that no one knows anymore.
|
| Also, at this point, if you are running on a dead platform and
| language and you know it, and haven't addressed it, then it's on
| you. I've been seeing these COBOL articles since the 2000s I
| believe.
| kjs3 wrote:
| _I've been seeing these COBOL articles since the 2000s I
| believe._
|
| Since the '80s for me. And certainly the '90s, since these sort
| of zero-content articles were _very_ popular in the runup to
| Y2K: "the _entire world_ is going to end because there are no
| Cobol programmers anywhere in the world! Everyone panic! ".
| It's still bullshit.
| pixl97 wrote:
| I've seen some currently used COBOL that had it's like change
| date in the early 80s in the finance industry, so there some
| rather ancient programs out there. Of course this also means
| that these files have met the needs of the industry that long
| and bug free so why go messing with things that move 100s of
| millions/billions of dollars per day.
| uxp8u61q wrote:
| Even if it's not handling billions of dollars a day... Why
| fix what isn't broken? Software isn't an end into itself,
| it's a tool to solve a business need. If the business need is
| met, there's not anything to fix.
| rafaelmn wrote:
| Because you lose the ability to fix/update it if you don't
| exercise it ? Depends on how much you value the ability to
| change the software.
| kstrauser wrote:
| One reason is that it's harder to execute by the year.
| Mainframes might be fast for some things, but they
| won't/can't scale as well as a gazillion VPS instances.
|
| I bet there are plenty of shops that have software they'd
| love to run on a cheap cloud server, so that they could
| retire their hyperexpensive big iron.
| hn_throwaway_99 wrote:
| The flawed "economic analysis" in this article is so commonly
| brought out, but at this point we should just call it what it is:
| lying.
|
| There is no "shortage of COBOL programmers." Businesses are
| simply choosing what they will pay, and the market is responding
| appropriately. And this is also not just a case of naively
| shouting "duh, just pay them more" for a market that can't bear
| the increase in costs (i.e. some industries can only survive if
| there are available low cost workers - most of us aren't willing
| to pay $40 for a fast food burger, for example. Whether those
| industries _should_ be around if they can only survive on low
| cost labor is another story...) It 's not exactly like the
| financial world is scrounging for money. Businesses can either
| choose to pay their CEOs a hundred million or so, or they can
| choose to spread some of that money to COBOL programmers. The
| choice is theirs, but there is no "shortage".
| nonrandomstring wrote:
| I agree with you on the myth of "a shortage", and respect your
| strongly pro-market argument. Therefore "some industries can
| only survive if there are available low cost workers" suggests
| to me that those industries should simply die. Let more
| efficient industries that return more value to people thrive in
| their place?
| high_5 wrote:
| It makes more sense to invest 100m $ in AI assistant for a year
| and then pay the CEO 120m/year the next one after firing the
| rest of the COBOL devs.
| gopher_space wrote:
| I cut my teeth on financial COBOL back in the 90s and from my
| perspective the article isn't "lying", it's "completely
| divorced from reality". For the past three decades it's been
| cheaper to encapsulate these systems and extend functionality
| by working in a modern language, and so that's what everyone's
| been doing.
|
| The prime issue (imho) is that it's less expensive and better
| for everyone if you rewrite these systems from scratch, but
| that cost is still so prohibitive that it might not make sense
| to keep operating the company.
|
| The second issue is hardware availability, a bizarre omission
| on the author's part. Your org lifespan might entirely,
| predictably depend on how many spares a forward-thinking dev
| bought in the 70's.
|
| The third issue is fintech. Someone _else_ has already raised
| the cash needed to rewrite from scratch, and what you can do
| about it is sell them your client list.
|
| From a personal perspective COBOL is such a pain in the ass to
| work with that I'd need a ruinous salary to be enthusiastic
| about the job.
| mperham wrote:
| We see this same article every year or so. Same song for 20+
| years now.
| mlhpdx wrote:
| I learned COBOL from curiosity (never using it professionally) in
| around 2010. It's simple enough to read and use, but without
| having seen these legacy systems I don't know what I don't know.
|
| This is just one of many examples of organizations squeezing an
| impressive but foolhardy lifespan out of some systems. Some CEO
| or another should have come to the conclusion (sooner) that they
| run a business, not a museum.
| lucidguppy wrote:
| This is a management problem. Lack of long-term planning. People
| knew COBOL was "feature complete" DECADES ago.
|
| "If it ain't broke - don't fix it." does not mean "don't maintain
| the things you own - just let them run until they break - then
| fix them."
| kjs3 wrote:
| I hate to break this to you (large financial here, large COBOL
| installed base) but we're not just sitting around watching it
| run. We have hundreds of COBOL programmers, and they actually
| touch the code. I bet every day even. Crazy, right?
|
| Just because some low-knowledge 'journalist' in a low-content
| rag decorates their ad-delivery with a low-effort 'you should
| have outrage about something' articles doesn't mean you should
| buy into it.
| justahuman74 wrote:
| Curious if you happen to have a ball-park figure on what 2023
| compensation looks like for a COBOL programmer
| ufmace wrote:
| The article title is clickbaity, but the actual point is the
| proposal of using LLMs to translate large amounts of legacy COBOL
| systems to more modern languages like Java. Doesn't seem terribly
| useful to me. I expect you could get a 90% solution faster, but
| the whole challenge with these projects is how to get that last
| bit of correctness, and how to be confident enough in the
| correctness of it to actually use it in Production.
|
| But then all of this has been known for decades. There are plenty
| of well-known techniques for how to do all that. If they haven't
| actually done it by now, it's a management problem, and no AI
| tech is going to fix that.
| matthewdgreen wrote:
| How hard is it to actually learn COBOL? It seems like a fairly
| simple language to pick up, but maybe the idiomatic COBOL used
| in these legacy systems is particularly nasty for some reason.
| the_only_law wrote:
| Learning COBOL is the easy part. My understanding is the hard
| part is becoming familiar with insanely expensive,
| proprietary mainframe platform that's you'll find in most
| COBOL work. I know IBM has some sort of self training
| material, but I'm not sure if it's enough to go from zero to
| qualified. Most work I see in the area seems to want
| established domain experts, not hackers who learn just enough
| to be dangerous.
| briHass wrote:
| Not really much different from today: sure, you can 'learn'
| a new language in a few days, but you won't know the build
| tooling, deployment strategies, environment specifics,
| convention over config, and typical patterns/practices that
| will allow others to understand what you wrote.
| kochbeck wrote:
| It's not that the mainframe is hard to learn. In fact, the
| environment is pretty easy to understand once you get past
| the archaic naming (but let's not kid ourselves: on the
| POSIX side we're still running t[ape]ar[chive] and other
| archaic tools too).
|
| In a way, the ease IS the problem: the runtime environment
| for COBOL (and other stuff on the mainframe) assumes that
| the underlying platform and OS deal with the really hard
| stuff like HA and concurrent data access and resource cost
| management. Which, on the mainframe, they do.
|
| Now, contrast that with doing the same thing in, say, a
| Linux container on AWS. From the stock OS, can you request
| a write that guarantees lockstep execution across multiple
| cores and cross-checks the result? No. Can you request
| multisite replication of the action and verified
| synchronous on-processor execution (not just disk
| replication) at both sites such that your active-active
| multisite instance is always in sync? No. Can you assume
| that anything written will also stream to tape / cold
| storage for an indelible audit record? No. Can you request
| additional resources from the hypervisor that cost more
| money from the application layer and signal the operator
| for expense approval? No. (Did I intentionally choose
| features that DHT technology could replace one day? Yes, I
| did, and thanks for noticing.)
|
| On the mainframe, these aren't just OS built-ins. They're
| hardware built-ins. Competent operators know how to both
| set them up and maintain them such that application
| developers and users never even have to ask for them
| (ideally). Good shops even have all the runtime
| instrumentation out there too--no need for things like New
| Relic or ServiceNow. Does it cost omg so much money?
| Absolutely. Omg you could hire an army for what it costs.
| But it's there and has already been working for decades.
|
| God knows it's not a panacea--if I never open another
| session of the 3270 emulator, it'll be too soon. And a
| little piece of me died inside every time I got dropped to
| the CICS command line. And don't even get me started on the
| EBCDIC codepage.
|
| Folks are like, "But wait, I can do all of that in a POSIX
| environment with these modern tools. And UTF-8 too dude.
| Stop crying." Yup, you sure can. I've done it too. But when
| we're talking about AI lifting and shifting code from the
| mainframe to a POSIX environment, the 10% it can't do for
| you is... all of that. It can't make fundamental
| architectural decisions for you. Because AI doesn't (yet)
| have a way to say, "This is good and that is bad." It has
| no qualitative reasoning, nor anticipatory scenario
| analysis, nor decision making framework based on an
| existing environment. It's still a ways away from even
| being able to say, "If I choose this architecture, it'll
| blow the project budget." And that's a relatively easy,
| computable guardrail.
|
| If you want to see a great example of someone who built a
| whole-body architectural replacement for a big piece of the
| mainframe, check out Fiserv's Finxact platform. In this
| case, they replaced the functionality (but not the
| language) of the MUMPS runtime environment rather than
| COBOL, but the theory is the same. It took them 3 companies
| to get it right. More than $100mm in investment. But now it
| has all the fire-and-forget features that banks expect on
| the mainframe. Throw it a transaction entry, and It Just
| Works(tm).
|
| And Finxact screams on AWS which is the real miracle
| because, if you've only ever worked on general-purpose
| commodity hardware like x86-based Linux machines, you have
| no clue how much faster purpose-built transaction
| processors can be.
|
| You know that GPGPU thing you kids have been doing lately?
| Imagine you'd been working on that since the 1960s and the
| competing technology had access to all the advances you had
| but had zero obligation to service workloads other than the
| ones it was meant for. That's the mainframe. You're trying
| to compete with multiple generations of very carefully
| tuned muscle memory PLUS every other tech advancement that
| wasn't mainframe-specific PLUS it can present modern OSes
| as a slice of itself to make the whole thing more
| approachable (like zLinux) PLUS just in case you get close
| to beating it, it has the financial resources of half the
| banks, brokerages, transportation companies, militaries,
| and governments in the world to finance it. Oh, and there's
| a nearly-two century old company with a moral compass about
| 1% more wholesome than the Devil whose entire existence
| rests on keeping a mortal lock on this segment of systems
| and has received either first- or second-most patents every
| year of any company in the world for decades.
|
| It's possible to beat but harder than people make it out to
| be. It makes so many of the really hard architectural
| problems "easy" (for certain definitions of the word easy
| that do not disallow for "and after I spin up a new
| instance of my app, I want to drink poison on the front
| lawn of IBM HQ while blasting 'This Will End in Tears'
| because the operator console is telling me to buy more MIPs
| but my CIO is asking when we can migrate this 40-year old
| pile of COBOL and HLASM to the cloud").
|
| Mainframes aren't that hard. Nearly everyone who reads HN
| would be more than smart enough to master the environment,
| including the ancient languages and all the whackado OS
| norms like simulating punchcard outputs. But they're also
| smart enough to not want to. THAT is the problem that makes
| elimination of the mainframe intractable. The world needs
| this level of built-in capability, but you have to be a bit
| nuts to want to touch the problem.
|
| I have been to this hill. I can tell you I am not signing
| up to die on it, no matter how valuable it would be if we
| took the hill.
| vbezhenar wrote:
| Language is easy, spaghetti code written without any
| discipline 60 years ago and modified in haste since is hard.
| timbit42 wrote:
| COBOL code I saw in the 80's and 90's wasn't spaghetti
| code. COBOL is pretty structured. If it's not, that would
| be a prior step in porting it to another language.
| rubyfan wrote:
| I don't buy that vintage of code is an indicator of its
| quality.
| JackFr wrote:
| That is not any COBOL I've seen. Straightforward, well
| documented and comprehensively specified and tested.
|
| When we needed changes (this was back office clearing stuff
| for a bank) they wouldn't even talk to us until we specced
| out the changes we wanted in writing and often the specs we
| submitted would come back with requests for clarification.
| This was like the opposite of agile, but I don't recall any
| bugs or defects making it into production.
| SoftTalker wrote:
| Not hard. It's a bit old-fashioned and sort of verbose but
| it's nothing difficult especially if you already know any
| other imperative languages. My first job out of school in the
| early 1990s was with one of the "big" consulting firms. We
| learned COBOL in a four-week boot camp and were then
| dispatched to a client site to write code.
| foobarian wrote:
| Haha that explains a lot :-)
| setr wrote:
| I don't think cobol is that difficult; the problem is that it
| runs on the mainframe, and that's a whole different beast.
| Everything in the mainframe world is both expensive and
| vendor-supplied, so it's difficult to learn outside the
| company, and sufficiently proprietary that you're probably
| not going to transfer it well elsewhere.
|
| The language itself also encourages troublesome patterns,
| like all variables essentially being globally defined and
| untyped, procedure line numbers matter because of things like
| PERFORM A THROUGH B (which will execute all logic found
| between paragraph A and paragraph B)
| jacquesm wrote:
| PERFORM PERFORM UNTIL ...
|
| The reason for that is that originally the 'WITH TEST
| BEFORE' bit wasn't there so what looked like the test was
| done afterwards actually would just exit the loop
| immediately without executing the loop body at all.
|
| So the syntax totally wrong-footed you into believing that
| your loop body would always be executed at least once but
| never did...
| jacquesm wrote:
| COBOL is pretty easy to learn. The problem is that it is so
| full of archaic nonsense (less so with the more recent
| versions) that you will be tearing your hair out and wishing
| for something more modern.
|
| COBOL's main value is in maintaining a pile of legacy
| codebases, mostly in fintech and insurance that are so large
| and so old that rewriting them is an absolute no-go. These
| attempts at cross compiling are a way to get off the old
| toolchain but they - in my opinion - don't really solve the
| problem, instead they add another layer of indirection (code
| generation). But at least you'll be able to run your mangled
| output on the JVM for whatever advantage that gives you.
|
| With some luck you'll be running a hypervisor that manages a
| bunch of containers that run multiple JVM instances each that
| run Java that was generated from some COBOL spaghetti that
| nobody fully understands. If that stops working I hope I will
| be far, far away from the team that has to figure out what
| causes the issue.
|
| It is possible that someone somewhere is doing greenfield
| COBOL development but I would seriously question their
| motivations.
| Nextgrid wrote:
| > that rewriting them is an absolute no-go
|
| Rewriting and expecting 100% feature-parity (and bug-
| parity, since any bugs/inconsistencies are most likely
| relied upon by now) is realistically impossible.
|
| However, new banking/insurance startups proved you can
| build this stuff from scratch using modern tooling, so the
| migration path would be to create your own "competitor" and
| then move your customers onto it.
|
| The problem I see is that companies that still run these
| legacy systems also have a legacy culture fundamentally
| incompatible with what's needed to build and retain a
| competent engineering team. Hell, there's probably also a
| lot of deadweight whose jobs are to make up for the
| shortcomings of the legacy system and who'd have every
| incentive to sabotage the migration/rebuild project.
| jacquesm wrote:
| That happens, but what also happens is that everybody is
| painfully aware of the situation and they do the best
| they can. Just like you or I would.
|
| And of course, if you start a bank today you'd do the
| whole cycle all over again, shiny new tech, that in a
| decade or two is legacy that nobody dares to touch.
| Because stuff like this is usually industry wide: risk
| adversity translates into tech debt in the long term.
|
| I suspect that the only thing that will cure this is for
| technology to stop being such a moving target. Once we
| reach that level we can maybe finally call it
| engineering, accept some responsibility (and liability)
| and professionalize. Until then this is how it will be.
| Cthulhu_ wrote:
| This is the way, however, integrating with legacy systems
| then becomes a challenge; a bank's software is never
| isolated, it has to interface with others, cough up
| reports for the authorities, etc etc etc.
|
| The green field isn't everything.
| lozenge wrote:
| Like in the video.. they are interpreting the COBOL and Java
| code with enough test cases and comparing their behaviour.
| drewcoo wrote:
| > I expect you could get a 90% solution faster, but the whole
| challenge with these projects is how to get that last bit of
| correctness, and how to be confident enough in the correctness
| of it to actually use it in Production.
|
| Is the goal to get working systems or to generate support
| activity? Or to tank the systems and replace them?
|
| > it's a management problem, and no AI tech is going to fix
| that
|
| What if we replace middle managers with LLMs?
| dun44 wrote:
| 90% of middle management could be replaced with simple shell
| scripts; LLM would be a vast overkill.
| IshKebab wrote:
| I'm pretty sure there's already a system to transpile COBOL to
| Java without resorting to LLMs.
| rubyfan wrote:
| Judging by the branding this is just an attempt to capitalize
| on the mindshare around LLM and GPT. Recall about 5-8 years
| ago they tried to sell the notion of huge cost savings
| replacing humans with the jeopardy champion and tech
| executives ate it up for a while.
| grammie wrote:
| Heirloom computing where I am cto does this using transpilers
| with 100% automated transpilation. Using LLMs for an entirely
| deterministic domain borders on the insane. This is just
| marketing bs but we get asked about it and what our plan is
| to counter it all the time. Explaining that using Gen-ai and
| LLMs for what is a well understood compiler/transpiler
| problem that is already solved just seems to be too difficult
| for some people to understand.
| IshKebab wrote:
| In fairness I imagine an LLM could maybe transpile to more
| idiomatic code. For example when you transpile FORTRAN to C
| you get a load of +1s and -1s everywhere to deal with
| FORTRAN's 1-based indexing. An LLM could avoid that.
|
| But I agree, it doesn't make sense to risk bugs just for
| that.
| dun44 wrote:
| You could do it with a trivial C macro instead.
| rubyfan wrote:
| _> If they haven 't actually done it by now, it's a management
| problem, and no AI tech is going to fix that._
|
| This. Further, it's a failure to continue to disincentivize
| roles that will support or port this business critical logic to
| something else. I worked at a large insurer where they slowly
| laid off mainframe talent over the last decade. Those mainframe
| salaries were counter to the narrative they were promoting
| around cloud being the future. Unfortunately in their haste to
| create optics they failed to migrate any of the actual code or
| systems from mainframe to cloud.
| credit_guy wrote:
| > it's a management problem, and no AI tech is going to fix
| that.
|
| There are no absolute "management problems". Something that
| is a management problem when the effort required is 1000 man-
| years, may stop being so when it's only 100 man-days.
| itsoktocry wrote:
| > _If they haven 't actually done it by now, it's a management
| problem_
|
| How could you possibly know that? Do you think businesses have
| so few problems to deal with that moving off of Cobol should
| always be the priority, even if it functions and they are
| managing it?
|
| It's not possible to resolve everything you have to do all at
| once.
| victor106 wrote:
| > Skyla Loomis, IBM's Vice President of IBM Z Software adds,
| "But you have to remember that this is a developer assistant
| tool. It's AI assisted, but it still requires the developer. So
| yes, the developer is involved with the tooling and helping the
| customers select the services." Once the partnership between
| man and machine is established, the AI steps in and says,
| 'Okay, I want to transform this portion of code. The developer
| may still need to perform some minor editing of the code that
| the AI provides, Loomis explains. "It might be 80 or 90 percent
| of what they need, but it still requires a couple of changes.
| It's a productivity enhancement--not a developer replacement
| type of activity."
| koenigdavidmj wrote:
| That seems to be the spot humans are weakest at--reviewing
| something where we think the computer did a good job 90% of
| the time, but quickly noticing when something goes wrong.
| Similar to level 3 self-driving--requiring full attention,
| able to instantly snap into full unassisted driving.
| keep_reading wrote:
| I'll never get tired of these overly confident armchair expert
| comments on HN
| Cthulhu_ wrote:
| AI is just one tech, there's been "language X to Y" converters
| for a long time, including Cobol to Java. To the point where it
| will compile and at least seem to do the same thing, but...
| that's the thing with these codebases, _verifying_ that it does
| the same is the challenge.
|
| I have 0 experience in this field, but I'm willing to take a
| guess that the majority of a Cobol to X developer's work is not
| (re)writing code, but figuring out what the original code does,
| what it's supposed to do, and verify that the new code does the
| same thing. More testing than programming.
| pard68 wrote:
| I work for a company that develops and maintains code that "no
| one knows anymore" which helps run the US banking system. This
| article is ill informed fear mongering and the proposed
| "solution" is a joke.
| rabuse wrote:
| Care to elaborate on this a bit? Some details would've been
| useful rather than just a "no u" comment.
| jacquesm wrote:
| It's spot on. This is such a crazy end run around the real
| issue that it won't solve anything, it replaces COBOL that
| apparently the people that need this don't understand with
| Java that they also won't understand because it will be
| translated from idiomatic COBOL, which has about as much to
| do with Java as it does with Prolog, Visual Basic or C. You'd
| need to be an expert in both Java _and_ COBOL to make soup of
| it.
| pard68 wrote:
| There isn't much to elaborate on. We are not hard up for
| COBOL or RPG devs, I'm sure some municipalities are but they
| are probably hard up for anyone who has the skills to make
| six figures.
|
| COBOL is used still for far more reasons than technical debt,
| there is good reason for the language and I doubt Java is
| even capable of replacing it. Even if an AI could write a
| 100% perfect Java version of COBOL, Java would fall flat on
| its face. COBOL and other languages like it are very
| performant languages, optimized over more than a half
| century.
| buro9 wrote:
| https://www.glassdoor.co.uk/Salaries/cobol-programmer-salary...
|
| If it's so valuable to the industry that they have good people
| who know it, that should surely be reflected in the salary / comp
| for roles... And if that were high, people would learn it, but
| it's not high, it's arguably worse than just learning a little
| JavaScript
| halfdan wrote:
| You're looking at salaries for COBOL programmers in the UK
| which is a small subset of an already small market.
| IshKebab wrote:
| I've checked in America before and came to the same
| conclusion. There's an idea that COBOL programming pays
| vastly more than other languages, but it's just a myth. It
| might pay a little more, but more like 20% more. Certainly
| not enough to warrant a COBOL career.
|
| And I'm sure some consultants can earn vast sums fixing old
| COBOL code, but that's just because they're consultants.
| Consultants always earn vast sums.
| moritzwarhier wrote:
| What prevents future employees from learning this language? Its
| development might have stalled, but as long there is
| documentation, whenever COBOL code breaks, there is are humans
| who can learn to fix the issue. Even when all "COBOL cowboys"
| have died out.
| apstats wrote:
| I feel like this solution was written by someone who hasn't built
| software before. Doing a rewrite for the sake of a rewrite is not
| a good idea.
| high_5 wrote:
| So... Having no COBOL devs left is a better one? What's the
| alternative then?
| apstats wrote:
| Yes - if we need them to people can learn COBOL it's not any
| harder to learn than many other programming languages.
| stonogo wrote:
| There are plenty of COBOL devs; they're just not in the
| American labor market.
| bluedino wrote:
| Not sure what's worse, depending on LLMs, or IBM to fix your
| COBOL project.
| curious_cat_163 wrote:
| I would hazard that depending on LLMs is worse.
| alexwasserman wrote:
| Having had to support and migrate COBOL in a big financial the
| problems weren't really related to the COBOL, but instead were:
|
| 1. The mainframe costs and support. These can be mitigated with
| migration to a platform like Microfocus to emulate it, but be
| careful you don't replace your ultra reliable mainframe with some
| flakey Windows servers.
|
| 2. The embedded business logic. Within the 50-60 years of code
| there's a ton a specific edge cases encoded for long forgotten
| business reasons. These make rewrites really hard as bugs and
| edge cases have long since become features or behaviors dependent
| apps are coded to rely on. It takes a ton of extra analysis work
| to understand what to keep and what to trash.
|
| 3. The cobol apps run in a challenging environment that's also
| not well understood today. All the jobs in JCL, ISPF to manage
| things, and a system like CICS for input/output. It's a huge
| change beyond just writing code in a regular IDE.
| DebtDeflation wrote:
| >The embedded business logic. Within the 50-60 years of code
| there's a ton a specific edge cases encoded for long forgotten
| business reasons.
|
| Honestly, this should be the top comment in the thread.
|
| The issue isn't COBOL being a hard language to learn or to
| translate to Java or not enough programmers or companies not
| being willing to pay people enough to work with it.
|
| The issue is the 50 years worth of business logic, added
| incrementally, over the years, with no documentation, blended
| into the original source, for reasons no one still working
| there remembers, as you stated. It's IF-ELSE statements all the
| way down and no one wants to touch a single one of them for
| fear of breaking something whose conditions might not even
| manifest themselves for months or years with no real way of
| even regression testing it.
| Stratoscope wrote:
| One correction on the article: "watsonx" (yes, with a lowercase
| "w" - ugh) is an umbrella brand for several of IBM's "AI" related
| products.
|
| The actual product name for this one is "watsonx Code Assistant
| for Z", as the author could have found with a simple web search:
|
| https://www.google.com/search?q=watsonx+cobol+java
|
| https://newsroom.ibm.com/2023-08-22-IBM-Unveils-watsonx-Gene...
|
| Disclosure: I work for IBM in "watsonx Orders", an automated
| order taker for restaurant drive-thrus.
| grammie wrote:
| It's a demo but the code that is transformed is trivial in the
| extreme. The whole approach of selecting small pieces is just not
| scalable. One small project i worked in was 22 million lines of
| cobol code, spread over 4000+ programs imagine having to select
| bits of code out of that.
| spindle wrote:
| I believe that practically the whole barrier to getting rid of
| legacy COBOL systems is testing the replacement system. Of course
| it's possible but it's very very expensive ... I don't have
| numbers for how expensive, but I've worked on financial software
| in COBOL on a mainframe, and nothing was the least bit abstruse
| or scary or difficult about it except the worry that our test
| suite might not be comprehensive, no matter how much we worked on
| it (and we worked on the test suite about the same amount as we
| worked on all the rest of the code put together). But at least
| our test suite appeared to cover all the cases that eventuated
| when we ran our COBOL code. How confident would be be that it
| would cover all the cases that eventuated when we ran translated
| code? THAT is the problem (or at least was for us). Nothing at
| all to do with whether translating COBOL can be made easier.
| gumballindie wrote:
| Another marketing piece by IBM aimed at impressing inexperienced
| managers and developers. If they wanted to come up with a tool to
| rewrite Cobol they'd have come up with a standard transpiler.
___________________________________________________________________
(page generated 2023-12-03 23:00 UTC)