[HN Gopher] COBOL has been "dead" for so long, my grandpa wrote ...
___________________________________________________________________
COBOL has been "dead" for so long, my grandpa wrote about it
Author : hardburn
Score : 140 points
Date : 2024-10-01 19:25 UTC (3 hours ago)
(HTM) web link (wumpus-cave.net)
(TXT) w3m dump (wumpus-cave.net)
| cwbriscoe wrote:
| Started my career doing Y2K stuff in 1998 and I still touch COBOL
| here and there today. I have a 10,000 line CICS program that runs
| every 30 seconds that I wrote in 2010. It has never failed since.
| bdjsiqoocwk wrote:
| I don't understand these "never failed" comments. Without
| further context, it's meaningless. If I write a python script
| and never change anything in its environtment or inputs, it
| won't fail either. That's not specific to cobol.
| kibibu wrote:
| I imagine the backwards compatibility story of COBOL is a
| little better than Python's
| _old_dude_ wrote:
| COBOL changes very slowly, once in a decade or two. Python
| does not offer support of a release for more than 3 years and
| a half [1].
|
| [1] https://en.wikipedia.org/wiki/History_of_Python
| yieldcrv wrote:
| But a compute instance or bare metal computer that never
| needs a new release wont have to deal with that in python
| either
|
| Its only new builds on someone else's computer that have
| this modern issue
| 0cf8612b2e1e wrote:
| I could believe there are legacy installations happily
| humming away on Python 2.7 without issue.
| remlov wrote:
| Several years ago I briefly worked at a major
| telecommunications provider with services across the
| southern United States that ran Python 2.4 on their
| production provisioning servers. Worked just fine.
| ang_cire wrote:
| If you're actually patching your python installs, that is by
| no means certain.
| andreasmetsala wrote:
| I don't think those mainframes running COBOL are getting
| patched either.
| ang_cire wrote:
| They absolutely are. Modern COBOL (even 25 year old
| COBOL) isn't running on ancient System360/370/390s or
| something, it's running on modern z/OS mainframes.
| p_l wrote:
| They are patched up regularly. The COBOL code itself
| maybe not, but the runtimes?
| tannhaeuser wrote:
| I understand the context to be that COBOL, as a DSL for batch
| processing, declares its .data and .bss segments, or the
| equivalents on host systems, statically in the DATA DIVISION
| and usually doesn't dynamically allocate memory. This,
| coupled with CPU, memory, and I/O bandwidth reservation from
| a job scheduler on an exclusive hot-swappable partition on a
| host (z/OS aka MVS) plus USVs, redundant disks/disk ports,
| and networks makes "never fail" much more a consequence and
| primary objective of mainframe architectures where COBOL
| workloads are usually run.
| supportengineer wrote:
| That's what I liked about developing Oracle stored procedures
| activated by cron jobs. Ran for 5 years, no maintenance needed.
| lloydatkinson wrote:
| That seems like a low barrier of expectations. I can think of
| several DB's that would run exactly like that.
| mbloom1915 wrote:
| almost all major financial institutions, utilities, gov't
| agencies, etc still rely heavily on COBOL today. If it ain't
| (extremely) broken, don't fix it?
|
| COBOL developers are literally dying out which has made for a
| competitive market for remaining talent. I've heard of some large
| consultants charging over $500/hr to their clients for a COBOL
| developer!
| jeremyjh wrote:
| I think the moat that COBOL developers have is not just their
| knowledge of the language, but knowledge of the mainframe
| programming and operating environment. Its just so alien to
| developers familiar with Windows/Linux, and there is really no
| way to get experience with the environment that I know of,
| other than to be employed doing it.
|
| But yeah that stuff is never going away as far as I can tell.
| Its just too risky to rewrite those core systems and many a
| boondoggle has tried and failed.
| rodgerd wrote:
| About a decade ago I looked into moving some COBOL components
| off-mainframe (either as COBOL-on-Linux or a rewrite into
| Java, which itself is really COBOL Mk II at this point), and
| your point about the operating environment is one of the key
| elements, but not all of it; there's also the fact that the
| first big shift to automation, via mainframe assembler and
| COBOL, is when companies sacked a lot of the folks who knew
| how and why the pre-automation processes worked - that
| knowledge exists in the mainframe code and the heads of the
| people who work(ed) on it, and nowhere else. A rewrite or a
| replatform is very, very hard and risky as a result; the
| system is now defined by how the mainframe runs the
| processes, to a very large degree.
|
| The third is that COBOL is only the tip of the iceberg. As
| soon as I spent time learning about the code I was being
| asked to look at, you get into decades of evolving
| programming practises. Modern COBOL is multithreaded,
| probably uses DB2 and relational datamodels. COBOL from
| thirty years ago is probably single-threaded, only runs right
| on high-clocked single-execution models, cuts down to hand-
| written s390 assembler regularly, and uses VSAM files with
| non-relational data. Older code still will be sharing data
| simply by banging it into memory regions for other code to
| read out of, because that's how you got performance back in
| the day.
|
| Trying to identify how you'd pull a function out of that and
| move it off is somewhere between extremely difficult and
| impossible. It's usually so complicated and expensive it's
| easier to try and hire people who want to apprentice as
| mainframe programmers and keep the current codebase running.
| mschuster91 wrote:
| > A rewrite or a replatform is very, very hard and risky as
| a result; the system is now defined by how the mainframe
| runs the processes, to a very large degree.
|
| And that's why so many neo-banks/fintechs are eating the
| lunch of the established banks left and right, same for
| insurance. The "old guard" is unwilling to pay the costs of
| not just upgrading off of mainframes (aka the rewrite work
| itself)... but of changing their processes. That is where
| the real cost is at:
|
| When you have 213.000 employees like BoA has and everyone
| needs to have at least 10 hours of training and 2 weeks
| until they're familiar with the new system enough to be
| fully productive, that's like 2 million man-hours just for
| training and 16 million hours in lost productivity, so
| assuming $50/h average salary it's around 900 million
| dollars in cost. Unfortunately for the dinosaurs, the
| demands of both the customers and (at least in Europe)
| regulatory agencies especially for real-time financial
| transfers just push the old mainframe stuff to limits,
| while at the same time banks don't want to cede more and
| more of that cake to Paypal and friends that charge quite
| the sum for (effectively) lending money to banks.
|
| In contrast, all the newcomers start with greenfield IT,
| most likely some sort of more-or-less standard SAP. That
| one actually supports running unit and integration tests
| automatically, _drastically_ reducing the chance of fuck-
| ups that might draw in unwanted regulatory attention.
| jeremyjh wrote:
| BOA doesn't train the vast, vast majority of its
| workforce on mainframe systems these days. No one working
| in a branch or call center is looking at green screens
| anymore. The mainframe systems are simply used as back-
| ends connected through web services (yes, even in CICS!)
| or MQ Series and the like to web GUIs.
|
| Source: worked there for many years, and built some of
| those integration systems.
| psunavy03 wrote:
| Migrations are still a thing, with various approaches and
| success rates.
| amelius wrote:
| Can't we just apply a bunch of correctness preserving
| translations towards a modern PL, perhaps aided by an LLM to
| keep the source as human readable as possible, while (I'm
| stressing this) preserving correctness?
| exhilaration wrote:
| IBM offers just such a service under the WatsonX branding,
| it's an LLM to convert COBOL to Java:
| https://www.ibm.com/products/watsonx-code-assistant-z
|
| I work at a company with a large COBOL codebase and this has
| been mentioned in a few presentations about our modernization
| efforts.
| refneb wrote:
| How did that go? My employer is going to try snd evaluate
| watsonx product. Have you had any luck converting
| large/complex COBOL modules ?
| grammie wrote:
| You should take a look at my company. Heirloom Computing.
| Heirloom.cc We have migrated many mainframe application and
| millions of lines of cobol and pl1 into Java and deployed
| it into production on prem and into the cloud.
| russfink wrote:
| But is the conversion maintainable by a human? I've seen
| Fortran to C translators that end up encoding state
| transition machines that are impossible to read.
| Muromec wrote:
| You can't, unless you transform cobol to cobol and run the
| emulator on aws. It will still manage to fail you in some way
| akavi wrote:
| I feel like every time COBOL is mentioned we get these stories
| about crazy high comp for COBOL developers, but anecdotally my
| aunt worked on COBOL projects in the mid 2010s and was paid a
| much more modest 45 $/hr. Good money for small town middle
| America where she lives, but nowhere close to what a decent JS
| dev can get.
| ghosty141 wrote:
| Similar experience with a friend of mine. I feel like these
| high salaries only apply to people who habe worked at one of
| these companies for a looong time.
| adastra22 wrote:
| High salaries are relative. $90k is a high salary for most
| people in the world, even for tech workers outside of
| Silicon Valley.
| IshKebab wrote:
| That seems like a myth to me. I actually looked up COBOL
| salaries and they were a _bit_ higher (like 20%) but definitely
| not enough to make them tempting.
| francisofascii wrote:
| There is typically a big difference between a consultant's
| hourly rate and a full time salary hourly rate.
| psunavy03 wrote:
| In COBOL implementations, it's generally not just knowledge of
| the language that makes you valuable, it's knowledge of the
| implementation at that particular organization. I'm not a COBOL
| dev myself, but I work with them, and part of the challenge is
| that everything is so uber-customized, tightly coupled, and
| there's 40+ years of undocumented business logic buried in the
| code.
|
| It's like the old joke about the engineer being asked for an
| itemized bill: "Chalk mark: $1. Knowing where to put it:
| $4,999."
| the_af wrote:
| COBOL jobs are not particularly well paid in my country.
|
| In any case, they would have to pay well by a large margin to
| justify working on dead boring legacy systems, too.
| Muromec wrote:
| It is very much broken and said institutions don't like it
| bespokedevelopr wrote:
| I work for a major utility and they used to run everything on
| mainframe and cobol but that went away long before I started
| programming. My coworker is nearing retirement, around 30 years
| here, and he started on cobol and worked on transitioning off.
| He has some really fun stories but my point being, the tales of
| cobol prevalence are very exaggerated. Maybe some parts of
| finance are still using it, not my area.
| msla wrote:
| "I don't know what the language of the year 2000 will look like,
| but I know it will be called Fortran." --Tony Hoare
|
| COBOL is alive in that it keeps changing from era to era, to the
| point modern COBOL looks rather little like the 1950s COBOL
| everyone instinctively thinks about when they heard the term.
| It's as if we were still programming in Algol because Java had
| been called Algol-94 or something.
| j0hnyl wrote:
| But are these legacy systems from the 70s, 80s, 90s using
| modern cobol?
| ithkuil wrote:
| When you hear about people being paid $X vs 10x$X to fix some
| cobol; is there a correlation between the age of the cobol
| system?
| HeyLaughingBoy wrote:
| Probably not; just a matter of how desperate they are.
| jcranmer wrote:
| Almost certainly yes. The "legacy systems" are likely running
| on versions of the mainframe with long-term support
| contracts, whose vendors are committed to providing newer
| compilers with support for newer versions of the
| specification as necessary.
| NikolaNovak wrote:
| Depends what you mean; but not necessarily.
|
| I am managing an ERP system implemented / went live in 2016.
| It's working on modern P10 hardware, which was released in
| 2021. The ERP system is continually updated by the vendor and
| customized by the client.
|
| Even for COBOL running on an actual mainframe, which I think
| most HNers would think of 1970s dinosaur, most of the actual
| machines in production would be pretty new. IBM z16 was
| launched in 2022.
|
| So they are "legacy systems" in the sense they're not written
| on a javascript framework which was launched last week,
| running on lambda instances in AWS :). But they are not "OLD"
| systems, as such.
| Animats wrote:
| Nobody writes MULTIPLY A BY B GIVING C ON
| SIZE ERROR STOP RUN.
|
| any more.
| graypegg wrote:
| I mean, if you squint your eyes a bit, that could be SQL! So
| even if it's not COBOL, there's people out there writing in a
| vaguely english business programming language.
| zozbot234 wrote:
| The nice thing about a vaguely English like language is
| that your average LLM is going to do a better job of making
| sense of it. Because it can leverage its learnings from the
| entire training set, not just the code-specific portion of
| it.
| kibwen wrote:
| Not for generating it, because the more it looks like
| prose the more the LLM's output will be influenced by all
| the prose it's ingested.
| crackez wrote:
| I've used o365 copilot to analyze a COBOL app I had
| source code to, and it was great at explaining how the
| code worked. Made writing an interface to it a breeze
| with some sample code and I swear I am not a COBOL
| person, I'm just the Linux guy trying to help a buddy
| out...
|
| It also does a reasonable job of generating working
| COBOL. I had to fix up just a few errors in the data
| definitions as the llm generated badly sized data
| members, but it was pretty smooth. Much smoother than my
| experiences with llm's and Python. What a crap shoot
| Python is with llm's...
| Suppafly wrote:
| seriously sometimes writing SQL feels more like composing a
| google query than programming.
| jl6 wrote:
| A great thing about being a programmer is getting to
| complain about the crappy requirements you have to work
| with. SQL, on the other hand, is not a program - it's a
| precise specification of the result you want, in a format
| that lets the database engine write the "program" for
| you. Thus, writing SQL helps you appreciate the struggle
| to achieve good requirements, and there is a chance you
| will develop empathy for those cursed to write them.
| tannhaeuser wrote:
| So you spotted that? I have no proof or links to share, but
| I've always thought SQL was inspired by, or at least made
| to not look out of place next to COBOL. I recall COBOL
| coding card layout interpreted a flag on punch cards at the
| char column where top-level picture clauses needed to start
| specifically for designating a line as SQL for static
| embedded SQL preprocessing.
| DaiPlusPlus wrote:
| I think it's more that computers at the time didn't _all_
| have lowercase characters. Consider that even C and C++
| supported trigraph /digraph compatibility chars until
| something like last year (and IBM still complained...):
| throw-the-towel wrote:
| And SQL kinda dates from the same era, I wonder if this
| type of language was in vogue 50 years ago?
| Smar wrote:
| > print food if tasty?
|
| Ruby is nice.
| 9659 wrote:
| This was almost true in 2000. It is not true now. Things
| change. Slowly.
| MathMonkeyMan wrote:
| More accurate might be "I don't know what the language of 2000
| will be called, but I know it will look like Fortran."
| TMWNN wrote:
| > "I don't know what the language of the year 2000 will look
| like, but I know it will be called Fortran." --Tony Hoare
|
| Kemeny and Kurtz described Fortran as "old-fashioned" in 1968!
| <https://dtss.dartmouth.edu/sciencearticle/index.html>
| mckn1ght wrote:
| Huh, so it mentions 4GLs... what generation would we consider
| rust/kotlin/swift then?
| stonethrowaway wrote:
| They haven't been around long enough to even be considered in
| the running.
| adamc wrote:
| 4GL was really more a marketing slogan than a true
| generation. The idea was something like "with third
| generation tools, you have to drive the car, making every
| turn yourself, with 4th Gen., you say "Go to the Ritz!".
|
| It wasn't true, although they did make some operations easier
| in tangible ways.
|
| Rust is a wholly different kind of thing -- not easier than,
| say, Java, but lots more control with better guarantees. It's
| more a systems programming language. 4GLs were all
| application-focused.
| skavi wrote:
| third generation: https://en.wikipedia.org/wiki/Third-
| generation_programming_l...
| rodgerd wrote:
| The modern analogue of 4GLs would be the promise of LLMs
| letting you write prompts so you don't have to learn a
| programming language; the promise of the original 4GLs like
| Pearl (not to be confused with perl) and Objectstar was to let
| you have non-programmers writing business logic without being
| COBOL or FORTRAN programmers.
| psunavy03 wrote:
| Ironically, the whole reason COBOL has its weird-ass syntax
| was to let you have non-programmers writing business logic
| without being assembly or C programmers. We can see how well
| that worked.
| jcranmer wrote:
| The idea of programming language generations were based on
| paradigms of programming that never really caught on. The idea,
| roughly, is that 3GL are those languages where you specify
| _how_ something is to be done, 4GL is where you specify _what_
| is to be done instead, and 5GL is you specify the problem and
| the computer does everything for you.
|
| This breaks down with the fact that it's really difficult,
| outside of really constrained spaces, to turn a "what"
| specification into a high-performance implementation, so any
| practical language needs to let you give some degree of control
| in the "how", and as a result, any modern language is somewhere
| uncomfortably between the 3GL and 4GL in the paradigm, not
| fitting entirely well in either category.
| adamc wrote:
| Technologies die very slowly once things of economic value depend
| on them. COBOL probably isn't used from new projects very often,
| but the economics of ditching it aren't very good either. It
| already works. Rewriting things that work is a great way to
| create new problems at great expense, so institutions are
| hesitant.
| throw0101b wrote:
| Bloomberg's _Odd Lots_ podcast had an episode last year, "This
| Is What Happens When Governments Build Software":
|
| * https://www.youtube.com/watch?v=nMtOv6DFn1U
|
| One reason COBOL systems have been around for so long is because
| they encoded business rules that need to be understood if you
| want to try to transfer them to a new system. From the podcast
| (~16m):
|
| > _Like when we 're working in unemployment insurance, again
| during the pandemic, my colleague was talking with the claims
| processors week over week and we're trying to dissect it and
| figure out what's going wrong and clear this backlog and one of
| these guys keeps saying, "Well, I'm not quite sure about that
| answer. I'm the new guy. I'm the new guy." And she finally says,
| "How long have you been here?" And he says, "I've been here 17
| years. The guys who really know how this works have been here 25
| years or more."_
|
| > _So think about. You know, going from doing some simple cool,
| you know, tech app, you know, easy consumer app to trying to
| build or fix or improve upon a system that is so complex that it
| takes 25 years to learn how to process a claim._
|
| > _That 's sort of, I think, what needs to be on the table as
| part of this agenda is not just "can the tech be better?" But can
| we go back and simplify the accumulated like 90 years of policy
| and process that's making that so hard to make?_
|
| Also an observation on how decisions are sometimes made:
|
| > _And I think that there 's a deep seated culture in government
| where the policy people are the important people. They do the
| important stuff and technology, digital is just part of
| implementation, which is not just the bottom of a software
| development waterfall. It's the bottom of a big rigid hierarchy
| in which information and power and insights only flows from the
| top to the bottom._
|
| > _And so it 's problematic in part because the people who are
| doing the tech are really just sort of downstream of everything
| else and the power and ability and willingness to step up and say
| "Hey, we probably shouldn't do those 6,700 requirements, we
| should probably focus on these 200, get that out the door and
| then, you know, add edge cases as as later." There's no
| permission really to say that._
| shadowgovt wrote:
| > ...add edge cases as as later." There's no permission really
| to say that.
|
| I think there would be _some_ value to closing that feedback
| loop to give legislators the signal "You know, what you're
| considering is actually pretty fuzzy conceptually... We're
| discovering while considering how to code it up that you
| probably don't actually have good, clear definitions for all
| the terms in this bill." But the biggest thing to remember
| about government IT is the clientele, which changes the
| approach from commercial / industry software.
|
| _Google_ can optimize for the common case. _Google_ can cut
| the edge cases. _Google_ can change APIs on a whim.
|
| Google's users choose to be Google's users and can go elsewhere
| if they don't like it.
|
| Government citizens don't have that choice. And in general,
| people don't lose access to their food if Google effs up. Or go
| without their legally-deserved unemployment pay. Or go to jail
| because their taxes were mis-calculated.
|
| In the government space, the "edge cases" are _human beings,_
| alike in dignity. The rules and policies end up complicated
| because human beings are complicated. And yeah, it ends up
| being some messy software. Because you can 't just decide to
| _ignore the law_ when it 's inconvenient to plumb the
| information that the client has a child under the age of 18 who
| is not a dependent because they're an emancipated minor, but
| said emancipated minor _does_ have a child of their own, and
| the client is the primary caregiver for _that_ child while
| _her_ parent is in prison... from here to there in the dataset.
| Muromec wrote:
| >Because you can't just decide to ignore the law when it's
| inconvenient to plumb the information that the client has a
| child under the age of 18 who is not a dependent because
| they're an emancipated minor, but said emancipated minor does
| have a child of their own, and the client is the primary
| caregiver for that child while her parent is in prison...
| from here to there in the dataset.
|
| That's all very true, but nobody ever codifies _that_. When
| the data doesn 't fit the constrains of the form that aims to
| handle a reasonable generalilized case, you simply get a
| phone call from a human in the loop. That human has a
| supervisor and you can also go to a court when they write
| your name with E instead of E and try to bullshit you about
| some kind of ASCIEBCDIC nonsense like it's real.
|
| In the end you have one dataset which tells who is a child of
| who, another telling who has custody rights and a third one
| making sense of amounts and recipients of childcase
| subsidies. Maintained by different departments and eventually
| consistent or maybe not.
| spongebobstoes wrote:
| My interpretation is a little different. We agree that humans
| are affected by the edge cases, although I believe that's
| also true at very large companies like Google or Meta.
|
| I don't think it's about avoiding programming 6700 edge
| cases, but more so that when you have an excessive number of
| cases, it's likely an indication that something is being
| missed. that could be due to a bug in software or due to
| unclear definitions in the legislation.
|
| in those cases, rather than attempting to program it exactly,
| it might be better to bring a human into the loop.
|
| and to me, that could be the point of having a tighter
| feedback loop. because otherwise the developers will just do
| their best, which will be buggy or incomplete. because they
| can't not do their job.
| Muromec wrote:
| > There's no permission really to say that.
|
| There is not permission to say that because your requirements
| are often set in a black letter law and you didn't buy a right
| kind of suite to be present where they were decided for the
| last 40 years.
| tombert wrote:
| You know, one of these days I really need to sit down and play
| with some of these "legacy" languages, like Fortran or COBOL or
| Ada or APL; languages that have certainly fallen out of
| popularity but are still used in some critical places.
|
| It does make me wonder about millions and millions of lines of
| Java out there; Java has more or less eaten the enterprise space
| (for better or worse), but is there any reason to think that in
| 30-40 years the only people writing Java will be retirees
| maintaining old banking systems?
| Suppafly wrote:
| >but is there any reason to think that in 30-40 years the only
| people writing Java will be retirees maintaining old banking
| systems?
|
| It feels like we're getting into that space already.
| Muromec wrote:
| Nah not really. People just started replacing COBOL with java
| and employers are wise enough to hire people who are 30-40
| years minimum from retirement.
|
| It can also be upgraded in smaller chunks and finding enough
| developers for the tool is an important metric corporate is
| looking at.
|
| If anything, banks are actively optimizing for developer
| experience to make sure 60% of new hires don't run away in
| the first year. If anything, banks are better at navigating
| those kind of structural risks, they were just slow on
| undertaking such risks exist.
|
| If you have an episode of existential anxiety because of dat
| AI eating mijn job, getting a union job in a bank is a way to
| hedge this particular risk.
| gwd wrote:
| > ...employers are wise enough to hire people who are 30-40
| years minimum from retirement.
|
| Um oh yeah, the reason we're hiring 20-year-olds is because
| we want to ensure we have lifelong support for the new
| system we're writing. Not because they're cheaper, they're
| still idealistic and naive, they'll work long hours for
| foosball tables and stacks, or anything like that...
| Muromec wrote:
| In a place where you can imagine having COBOL, working
| long hours is frown upon and being idealistic beyond
| personal integrity isn't a good quality either. Not
| saying such places aren't cheap, as of course they are.
| Being cheap is their exact point.
| Muromec wrote:
| Cobol is still there not because of cobol itself, but because
| of vendor and platform lock-in. And I guess having monolithic
| codebase/platform.
|
| it's not even esoteric and difficult, just a lot of it without
| much structure visible to you.
| danielmarkbruce wrote:
| This is what people miss about COBOL. It's not like people
| are compiling COBOL and running it on Linux on an x86 box.
| They are running it on legacy operating systems (and
| hardware) which provide a different set of underlying
| services. It's a whole different planet.
| Muromec wrote:
| A different kind of cloud you can say.
| danielmarkbruce wrote:
| ha yes. There is actually a pretty cool product that is
| made by a division of Rocket Software named "AMC", it
| takes a COBOL app running on an IBM system and deploys it
| to a whole set of services on AWS. There are some smart
| dudes at that shop.
| Muromec wrote:
| Doesn't surprise me at all, somebody out there should be
| smart enough to make good money on that and not be very
| loud about it either.
| crackez wrote:
| Negativo friendo.
|
| The mainframe is turning into a middleware layer running on
| Enterprise Linux. We've containerized the mainframe at this
| point, and I mean that directly - eg. Running jcl, multiple
| CICS regions, all in COBOL that originated on z/OS is now
| running in k8s on amd64.
| danielmarkbruce wrote:
| Yup, but the COBOL application doesn't know you've done
| that.
| Muromec wrote:
| There is a major drawback to this approach -- you need to
| have somebody who knows what they are doing. Total deal
| breaker in most of the places that have this problem in
| the first place.
| Mc91 wrote:
| I program an Android app for a Fortune 100 company. Last commit
| where someone edited a Java file was last week.
|
| Most of the new code from the past few years has been in Kotlin
| though.
| Muromec wrote:
| This. Nobody wants to have the COBOL problem again, so the
| developer hiring money follows the programming language
| popularity market (with a certain regulatory approved laf
| ofc)
| adastra22 wrote:
| Fortran is not a legacy language.
| 9659 wrote:
| Ada is an order of magnitude more modern and sophisticated than
| your other examples.
|
| I expect Ada will capture 0.05% of the market for the next 100
| years.
| tombert wrote:
| Fair, I guess the list was "languages that I know were
| popular at one point but I don't know anyone really using
| now".
|
| Ada definitely does seem pretty cool from the little bit I
| have read about it. I'm not sure why it's fallen by the
| wayside in favor of C and its derivatives.
| aidenn0 wrote:
| Ada was mandated by the DoD for a bit. My understanding is
| that, in practice, this involved making a half-hearted
| effort in Ada, failing and then applying for a variance to
| not use Ada.
| actionfromafar wrote:
| Often, I'm sure, but there are large code bases in Ada
| still. It's a shame, it looks like a really great
| language I would love. But it's a chicken and egg
| problem. If only Mozilla had decided on Ada instead of
| Rust! :-)
| 7thaccount wrote:
| Ada is pretty cool, but not sure if any more modern than APL.
| Both are actively maintained and useful in different areas.
| RickJWagner wrote:
| IBM offers a free COBOL plugin for VSCode and a nice tutorial
| with it.
|
| I started programming in COBOL (circa 1990) and took the
| tutorial just for fun earlier this year.
| norir wrote:
| I think of scala in this context. I think that scala is basically
| dead at this point in the way that COBOL was framed in the
| article. Yes, there are still many businesses/services that have
| critical components written in scala but current mindshare has
| cratered for new projects. I only single out scala because I have
| spent a lot of time with it and have seen it go through the hype
| cycle (in 2012-14 it seemed like I was constantly seeing doing $X
| in scala pieces on HN and I almost never see it referenced here
| anymore). It's probably a natural and inevitable phenomenon (and
| a bit of a shame because scala did get some things right that
| other mainstream languages still have not).
| empathy_m wrote:
| Does Twitter still have software in Scala?
| 7thaccount wrote:
| I assume it became less popular when Java became more bearable.
| n_plus_1_acc wrote:
| And kotlin came around with great IDE support, and with good
| features without the complexity of scals
| paulddraper wrote:
| Kotlin made Java bearable.
| WaitWaitWha wrote:
| (Programming) languages take very long to "die". Most often you
| will get a long drawn out tail, and often parts of a language
| gets absorbed into other languages. Only the sages and
| etymologists will know where they have come from.
|
| Old man reminiscence following, skip if you are not bored:
|
| I worked with SNOBOL and I thought it will be a long term
| programming language. I also want to think that I had some tiny,
| minuscule hand in dev of RIPscrip pre-Telegraphix, alas it went
| as the dodo bird.
|
| I think I have forgotten more programming languages than I can
| count on my hands. Yet, I see them in some part every day in
| newer languages, "discovered" by some expert. "What has been will
| be again, what has been done will be done again; there is nothing
| new under the sun."
|
| One language has come to my aid for the last 30-ish years Perl
| has came to my aid many times.
|
| (I tell you a secret - in the deep deep bowels of a a very, very
| large, jungle named company, servers still have tiny Perl scripts
| running some core functions. I discovered this, when there was a
| problem that I had to deep dive into. I a recommendation to
| change to a hard-coded variable. The answer was "it will take two
| weeks". Why? Because no one knew what it will do or could read
| Perl. It was a 30 second job, including sdlc. Think xkcd
| _Dependency_ https://xkcd.com/2347/ )
| snovymgodym wrote:
| As always, these discussions will depend on your definition of
| "dead" and "alive".
|
| If we can call a technology dead once no new business is built on
| it, then I think we can safely call COBOL dead (and the IBM 390x
| aka Z/OS platform along with it, for which "COBOL" is usually a
| proxy).
|
| But if we say that anything still being used in production is not
| dead, then of course COBOL is alive and significantly more alive
| than many other things which are younger than it.
|
| But this shouldn't really be taken as a positive point for COBOL
| or the mainframe ecosystem. It's simply a fact of life that
| organizations tend to stick with the first thing that works, and
| for the types of entities involved in the first wave of
| digitalization (e.g. governments, banks, airlines) that was
| usually an IBM mainframe along with the software that runs on it.
| DaiPlusPlus wrote:
| > we can call a technology dead once no new business is built
| on it
|
| You don't suppose any bank - or other large financial
| institution - might have standardised on Cobol for their core
| business flows/processes? In which case a new business-unit or
| "internal startup" team (e.g. a new category of insurance
| product) might very-well have some part written in Cobol so it
| integrates with the rest of the bank - or at very-least might
| be built-on-top of the org's existing Cobol-running
| infrastructure (i.e. Not written in Cobol, but still runs on
| Z/OS because there's no budget for buying new commodity x86
| racks and the people to manage and run them).
| blastonico wrote:
| Soon after Java was released, when the hype around the language
| was on fire, people used to say that it was going to replace
| COBOL - due to the "build once run everywhere" motto. Java indeed
| gained market share in the finance industry, but COBOL is still
| there.
| FrustratedMonky wrote:
| Is PERL dead yet?
| adastra22 wrote:
| PERL is undead.
| hardburn wrote:
| No
| brightball wrote:
| For what it's worth, I'm still actively looking for a COBOL
| speaker for the 2025 Carolina Code Conference. Been wanting to
| get a COBOL talk for a while, especially with GnuCOBOL's recent
| update.
|
| https://gnucobol.sourceforge.io/
|
| https://carolina.codes
| deenadz wrote:
| COBOL is dead, long live COBOL.
|
| For any cobol devs here, we at https://cobolcopilot.com would
| love to hear from you
| Muromec wrote:
| You need to sell on-prem to those people. No way a single byte
| of that sweet sweet poison is going to ever leave the corporate
| network boundary.
| flatpepsi17 wrote:
| Article starts mentioning 4GL's - a term I have not heard in a
| long, long time.
|
| COBOL's promise was that it was human-like text, so we wouldn't
| need programmers anymore. A lot like "low code" platforms, and
| now LLM generated code.
|
| The problem is that the average person doesn't know how to
| explain & solve a problem in sufficient detail to get a working
| solution. When you get down to breaking down that problem... you
| become a programmer.
|
| The main lesson of COBOL is that it isn't the computer
| interface/language that necessitates a programmer.
| UniverseHacker wrote:
| > we wouldn't need programmers anymore
|
| This blows my mind, since it seems like a fairly low
| level/terse language compared to more modern domain specific
| languages.
|
| But in some sense they were dead right... since (I assume) that
| what "programming" meant at the time was being able to write
| raw machine code by hand on paper, and have it work - something
| few people can or need to do nowadays
| actionfromafar wrote:
| Vision 4GL. Like VB but cross platform and with a horribly
| unstable IDE which would corrupt the source code. (Which was in
| some kind of binary format not amenable to source control.)
| palisade wrote:
| The irony is that we already had a memory safe and stable
| language in Cobol that was easier to read and understand than
| Rust. But, no one wants to use it so it is "dead" but it runs
| everything that made the modern age possible.
|
| RUST:
|
| println!("Enter number: ");
|
| let mut input_string = String::new();
|
| io::stdin().read_line(&mut input_string).unwrap();
|
| let number: i32 = input_string.trim().parse().expect("Please
| enter a valid number.");
|
| let result = if number % 2 == 0 { "EVEN"
|
| } else { "ODD"
|
| };
|
| println!("The number: {}", result);
|
| COBOL:
|
| display 'Enter number: '
|
| accept number
|
| if function mod(number,2) = 0 move 'even' to
| result
|
| else move 'odd' to result
|
| end-if
|
| display 'The number: ',result
| sestep wrote:
| This is a weird take. Sure, plenty of cool/nice things from old
| languages (e.g. variable-sized stack frames in Ada) get lost,
| and some then get rediscovered by future languages, potentially
| wasting effort. And I don't know COBOL, so maybe you're
| actually making a good point.
|
| But I find that hard to believe. Does COBOL really solve all
| the same problems Rust is intended to solve? Is it as
| performant? Can it interface with native code from other
| languages in the same way? Does it have a usable and sane
| package manager built on top of a module system that
| facilitates composability and backward compatibility? Does it
| have a way to describe the shape of data and errors as
| ergonomically as Rust's algebraic data types?
|
| Genuinely curious: as I said, I don't know COBOL. I'd find it
| extremely surprising if the answers to all these questions are
| "yes," though. Just as there are reasons COBOL is still used,
| there are also (good) reasons new languages have been created.
| Muromec wrote:
| Imagine having a shell script being called from a cron job
| that writes data in a bunch of tab separated memory mapped
| files (memory mapping happens when you configure the thing),
| but you have more files than memory. And all the shell
| scripts call and include each other and have global variables
| too.
|
| And that underpins most of the critical infrastructure in
| your country.
| palisade wrote:
| A lot to unpack in this question.
|
| Do they solve all the same problems? No, for example COBOL
| lacks a modern concept of concurrency within a single
| program. COBOL's concurrency features are based on task-level
| parallelism, which involves dividing a program into multiple
| tasks that can be executed concurrently.
|
| Is it performant? Yes. COBOL is highly efficient particularly
| in handling large datasets and complex business logic and its
| compilers are optimized for reliability and speed.
|
| Can it interface with native code? Yes.
|
| Does it have a package manager? No.
|
| Does it describe shape of data? No. Data structures in COBOL
| are defined using fixed-length records.
|
| Note: I'm not a COBOL expert. I did learn it in college,
| though.
| Muromec wrote:
| Shell script is memory safe too, but you don't write anything
| longer than 100 lines in it for a reason.
| palisade wrote:
| When you bank, COBOL (40% of online banks). When you use the
| ATM, COBOL (95% of ATM transactions). When you travel, COBOL
| (96% of airline ticket bookings). Healthcare, COBOL. Social
| Security, COBOL. Point of Sale, COBOL. IRS, COBOL. Pension
| funds? COBOL. Hotel bookings? COBOL. Payroll programs? COBOL.
|
| It is estimated that there is 800 billion lines of COBOL code
| in production systems in daily use. That is a bit more than
| 100 lines.
|
| This was why Y2K genuinely scared everyone and was a very
| real problem. The only reason we can look back at it and
| laugh now is that an army of engineers sat down and rewrote
| it all in the nick of time.
| arcticbull wrote:
| Legacy code yeah, nobody's hitting File > New Project in
| COBOL
|
| It's just that nobody understands how the systems work and
| they're ossified. Those systems are going to be emulated
| until our grandchildren take over because nobody can
| understand them well enough to craft a replacement. Juuuust
| up until an LLM rewrites them for us.
|
| [edit] I mean those airlines systems are so old that they
| don't support special characters on names, passenger names
| are two fixed-length fields (first name, last name) and
| title and middle name just gets appended together.
|
| So you get LASTNAME/FIRSTNAMEMIDDLENAMENTITLE on your
| bookings. And each of those fields is truncated lol.
|
| _and_ of course flight numbers are fixed at 4 digits, so
| we 're running out of those.
|
| Not exactly a great ad.
| palisade wrote:
| Oof, I've got good news and bad news for you.... they
| still are creating new code in it.
|
| Yeah, there are fewer engineers in COBOL which is why it
| pays BIG bucks now. They desperately need someone to
| maintain that massive infrastructure that has been built
| up over 75 years that cannot be replaced easily or
| quickly.
| toast0 wrote:
| "Legacy code" is also known as "the important code that
| makes the business work"
|
| If these new fangled languages are so great, one day they
| can be legacy code too. :P
| Muromec wrote:
| That's not what makes something legacy. Legacy is
| something highly not advisable to change because it's
| both makes the business work and can't be easily changed
| because of complexity, loss of context, high blast radius
| or whatever. It's just there and you have to deal with
| it. If it wasn't complex, opaque and scary to touch it
| would not have been just another piece of something to be
| replaced and updated like the copyright date in the
| footer.
| Muromec wrote:
| I'm a big enjoyer of arcain arts, but I happen to work in a
| place that actually has it and no -- nobody likes COBOL and
| it's not cool in any sense.
| palisade wrote:
| Well, there is a good reason no one likes it. It isn't
| cool, I completely agree. Readable, simple, safe,
| performant and still relevant though? Ya.
| Muromec wrote:
| >Readable, simple, safe, performant and still relevant
| though?
|
| It's performant, you can't take away that.
| hollerith wrote:
| Bizarre comment. No developer who should be allowed anywhere
| near a computer would ever consider choosing COBOL where Rust
| is appropriate and vice versa.
| palisade wrote:
| Well, I said it was ironic that we went out of our way to
| make a newer more complicated to read language that was
| memory safe when we already had a language that was simpler
| and readable that was safe.
|
| I didn't say I wanted to code in it, though. I'd prefer in no
| particular order Kotlin, Python, Go, C++, Rust, Perl, C#,
| Java, Zig, etc. Anything really over COBOL myself. I'm part
| of the problem.
|
| But, if I was hard up for money and wasn't getting nibbles
| for jobs? I could see getting into COBOL because there is a
| lot of money in it and always work available.
|
| My statement stands though, we need to do better when
| designing the syntax of our languages. Cobol is disliked, yet
| simple and readable. What does that say about our new
| languages. How hated are our "new" language remnants going to
| be when few of us are longer around to maintain them 50 - 75
| years from now? And, how easy are they going to be to pick
| up?
|
| Addendum: I guess it won't matter if the singularity comes
| and just writes it all for us, of course. Then it will all
| just be machine code and we won't need these "only human"
| translation layers any longer.
| 7thaccount wrote:
| I don't think the use cases for Cobol (bank software)
| typically overlap with those for Rust (operating
| systems...etc).
|
| It's like saying no gardener should be allowed near a garden
| that would choose a shovel over a pair of shears. Both have a
| place.
| zozbot234 wrote:
| Agreed. It's easy to have memory safety when you don't even
| support heap allocation. Now if OP had said "Java" or "C#"
| instead of "COBOL", they would've had a solid point. But the
| way Rust ensures memory safety without mandating GC while
| still allowing for complex allocation patterns can be said to
| be practically unfeasible for any of the usual "legacy"
| languages, with the notable exception of Ada.
| happyjim wrote:
| Key components of the U.S. Internal Revenue Service tax
| processing code (e.g., the "Individual Master File" or IMF) are
| written in COBOL and IBM Assembly Language.
|
| There is an ongoing effort to refactor as Java. This will
| ultimately take years and cost $100s of millions of dollars.
| There is still a small but shrinking team of graybeards who can
| actually maintain the code, which has to be reprogrammed every
| year to accommodate changes to tax code.
|
| See, e.g., IRS IT Strategic Plan documents, publicly available.
| kayo_20211030 wrote:
| Great story. There's something wicked personal in it, and it's
| very good. I reckon that this bloke's grandfather was an
| interesting bloke - cobol or no.
| sshine wrote:
| I know someone my age (mid-late 30s) who is a COBOL programmer
| for a bank.
|
| He's been that for ~5 years.
|
| I don't think it's going away any time soon.
| gpraghu wrote:
| A touching article! I have enjoyed similar times with my grandpa.
| On the topic of Cobol, I simply don't understand why people hate
| it so much. It has a shallow learning curve like Python, is self-
| documenting enough that one doesn't need to write a bunch of
| text, and is available on every conceivable architecture, with
| great performance. I personally wrote a payroll for an entire
| factory on a B1800 with 128K of memory and a 10MB hard disk! So
| what's to complain? In my mind, Java is deader than Cobol!
| ape4 wrote:
| Its the amount of boiler plate that people hate.
| acdha wrote:
| I think there's something to that but there's also a lot of
| selectivity there. Many of the same people who complained
| about COBOL because it was verbose adopted things like
| enterprise Java, so there's more than a suggestion that this
| might be a less than completely objective assessment.
|
| The bigger problem: COBOL was an open standard but none of
| the implementations were open source for ages (I haven't
| looked at GNU COBOL in years, but I think this is no longer
| the case) so nobody was building new things or experience
| when they had to pay to get started.
| socketcluster wrote:
| It's interesting reading articles from previous generations how
| they make it sound like people seem to remember what everyone in
| the tech industry said as if everyone mattered. I guess there
| weren't many people around in the industry back then.
|
| Nowadays, even if someone is right about something and most
| people are doing it wrong, nobody will care to even discuss it
| unless the person making the statement is one of maybe 3 top
| influencers in that field.
___________________________________________________________________
(page generated 2024-10-01 23:00 UTC)