An Apology to COBOL: Maybe Old Technology Isn’t the Real Problem | Hacker News Reader

An Apology to COBOL: Maybe Old Technology Isn’t the Real Problem

govtech.com

160 pointsrbanffy171 comments

I can’t wait until the Kubernetes/container/Microservice beasts we are building today become legacy in 20 years. Fixing a COBOL application will probably look simple in comparison.

Even more than the efficiency penalties, it's the drastic increase in complexity that makes me want to stay far, far away from microservice architectures.

Like all legacy tech. Wrap it in a box of tests don't touch it and just manage the risk down over 20 years. Just like migrating away from a mainframe.

Am I doing myself a disservice by actively avoiding shops that want to go down the k8s road?

Asking in interviews questions like “how many namespaces are you managing or expecting to manage” and often times teams are talking about a single microservice and bringing in k8s “just in case”

To which I’ve oft said “good luck in your endeavors”

K8s solves a specific set of problems that mid- to large-sized companies face. If the company is big enough to have multiple K8s experts then it can be successful

> Am I doing myself a disservice by actively avoiding shops that want to go down the k8s road?

From the resume-driven-development angle, probably. I do the same though.

If you prefer to work in a sane environment though, wise choice.

k8s sits on a list of things that I hope to avoid long enough before I can retire.

I felt largely the same way, but now our company has enough microservices that without something like k8s it's hard to actually sufficiently test anything well. Sure, we have test setups for any one service, and tests for that service with some other services mocked, but there's really no way to spin up a real full dev or QA environment with all the services interacting without herculean effort, and keeping it up to date would be non-trivial.

I still haven't done anything with k8s, but I suspect it's the solution to this problem, even if it would take that same herculean effort to finally get everything moved to using it (we don't even run containers, we run our own application delivery system that has some similarities without the process isolation, because we've been doing so since before Docker existed).

> I felt largely the same way, but now our company has enough microservices that without something like k8s it's hard to actually sufficiently test anything well.

That feels like a self-inflicted wound that will now only get worse with k8s.

> That feels like a self-inflicted wound

What's the alternative? It's not like we're some web property with an application, it's an ISP, and we sell internet services, and we've been around long enough that we still offer traditional ISP services (many for free) such as email, hosting, VPN service, etc, as well as telecom services. These often need to communicate with each other in some way, as well as many back-end services we've written to serve our staff.

Microservices come with problems, but honestly I can't see a large monolithic app (or even a few of them) being much better development wise, even if it might have been easier to test and set up a development environment.

As someone who has also tried to avoid it but now failed: it is not all bad, but it is immature, opionated in weird ways and make some normally simple problems very hard. The advantages is that it in return makes some hard problems trivial.

So far I would not say it is worth it for most people. I also hate how much the community just runs random shit from the internet without any strategy for security patches or digital signatures.

Hey no worries just pay for yet another product to analyse your images!

Fixing up the docker images will give you some variety outside deciphering cut and paste garbage cryptic mess in helm charts.

Well designed microservices drastically reduce complexity and mental overhead of working with a system.

The problem is companies with poorly designed monoliths hit complexity problems more quickly and often. If software architecture is not a core competency, solutions architecture is probably not either, and poorly designed microservices are a completely different beast. A distributed monolith is inherently more difficult to maintain and operate.

But why would the same people that poorly designed the monolith be able to design the intrinsically more complex microservice architecture better?

We have to keep in mind that not all software systems are designed by savants, and even ones that are might be constrained by business needs from rearchitecting them when they need it

That's what I was trying to articulate in the end.

Microservices are generally less complex.They can appear more complicated because companies who are choosing to transition usually do so after a problem. These problems are often due to poor monolith design.

Teams that design poor monoliths typically have neither a software or solutions architecture proficiency

My simple rule is: if you can’t write a decent library you won’t be able to write a well designed microservice. Microservices have all the challenges of library design plus quite a few more.

> microservices drastically reduce complexity and mental overhead of working with a system

If you only need to understand and maintain one of them, sure.

That would be extremely rare though. You have to understand the entire system and all the interaction between all the parts. At which point the 10x complexity of excessive microservices will kill you.

>You have to understand the entire system and all the interaction between all the parts.

Maybe if you're CTO. Never seen that in case of individual contributors.

I've been that IC. You can easily find cases where a feature implementation involves a vertical slice of the whole stack, just like you would in a monorepo. Do that enough times with enough different features and you end up touching most things. If you don't have organizational blockers to velocity, and you treat every task as a chance to learn something new about the architecture (as you should!), you don't need all that long to develop a sense of what's where and how the pieces fit together.

You're not likely ever going to be at the same level of detail on everything all at once, and there can still be fuzzy parts - third party partners in particular can be difficult, especially if the org is not good at making known who's the SME for what - but you absolutely can build an understanding of the architecture as a whole, and that makes you able to dive in and work on just about anything without needing much spinup time.

(Granted this assumes good technical and architectural leadership early on that has specified standards for interservice communication, intraservice code design, what layers exist and how they interoperate, etc. That said, Wild West microservices might still be less painful to work on than a Wild West monolith - I don't actually know, but I could come up with arguments either way.)

Depends where you are. That’s not going to happen at Big N size environments.

In such environments, I wouldn't expect it to be particularly useful or necessary, either - it's not a good use of effort to deeply understand foo-service if I can just ask somebody on the Foo team, or read their schema and docs, and get what I need much faster that way.

I'm thinking more from the perspective of a small team supporting a large operation, because those are the kinds of situations where I've spent a lot of my career. FAANG scale would be a novel experience for me, as I suspect it would for most.

In that scenario I’d be a lot more hesitant to do true “microservices” because IME it’s a good way to complicate interactions and development without achieving much.

That's fair. In the specific case I have in mind, load was very bursty and scaling was a major concern; we were always looking to minimize both latency impact on revenue and infra cost impact on profit. Having the critical path live in its own heavily optimized services made demand scaling very easy and very fast; I don't think we could have done as well with less separation, and once you've already got the necessary infra and practices in place, it becomes very natural to apply them to the other problems you have to solve.

Not to say you can't get in trouble that way, for sure. It's its own kind of tradeoff, not least in that you need more ops support than a simpler infrastructure would require, and you need someone with the architectural vision and authority to ensure things don't get out of hand. It's definitely not where I'd want to start with anything, and you need a strong team to make it work, but I can say from experience that it can work amazingly well. Like, about twenty people supporting about $2B ARR well.

The truth is that even for very large companies there's always push and pull between service separation and ops burden. If you're thinking about it you're already in a better place than many.

Putting on my business hat, the shift to microservices needs to happen top down and involves organizational structure as well. Each service should have a clear team which owns it and a single threaded owner for the team.

Any higher than senior engineer better understand the whole ecosystem at a reasonably sized company.

(Sure if you're google sized, nobody will understand or even know the entire system. But nearly every company on earth is smaller than that.)

As long as the network protocols stay in the mainstream, the implementation tech stacks of remote services will become “ancient” and “icky” without callers really noticing. I suspect they will stay around much longer as people program around them without comprehending what horrors lay inside.

I wish we could treat services as black boxes like this, but who can run services these days without keeping on top of dependency, security, and platform updates? The inevitable deprecation of some of these means surgery will soon be required to keep a service running and secure.

I’m not on either side of the k8s debate, but I suspect it will be a lot less than 20 years as the ecosystem is moving faster now.

I'd predict 3 years. Mesos looked promising 5 years ago, today its going to the Attic.

I get the impression some of these things are going into the Linux kernel, one way or the other. When we hit 20% someone will do a Lite version.

This is why I'm mainly focusing on the application side of things; container technology is 'just' the runtime. I'm making sure my stuff is sane, that it runs on anything. Others can worry about containerization / the runtime.

But I'm getting the feeling that a lot of people worry a lot about the runtime. They break up their applications into microservices not to solve a problem, but because they believe it's the best thing to do because $reason. But you shouldn't do that until you're actually running into an issue and have exhausted the other, simpler options.

I mean I wouldn't mind having or experiencing an actual scaling problem directly, but so far I've never seen it. I've seen a LOT more organizational and technical problems stemming from intentionally building a microservices architecture though.

But building just the one codebase is dull.

$reason = Make the microservices independent of each other, so you can rewrite and replace them without much trouble when they're getting old.

This is just modularisation though. You can modularise without microservices. Microservices solve a scaling problem, not a design flexibility problem.

Micro services often solve _an organizational scaling_ problem, and are less frequently deployed for _performance scaling_.

a monorepo also solves that same organisational scaling problem, but without introducing the artificial problem of basic function calls having to traverse the network, and having to keep tons of different services online and talking to each other.

Since servers are ephemeral, any function call of note will need to traverse the network in some way anyway.

that's true, but there's traversing 2 links for a simple client<->server<->database setup, or traversing dozens or even hundreds of links for a microservice architecture, adding tons of fragility for no unique benefit.

Well, there are legitimate benefits, it's just that few organizations are poised to understand/utilize them.

Yeah, but it turns out people can’t actually write software right (or won’t) and this sort of network boundary is the only way to force them to write modular code, without the monolith collapsing into a tangled mess.

It’s really annoying.

yes one of the biggest problems in software development is that most developers are bad at their jobs.

the solution, however, would be to hire a small number of really good developers and have code reviews run through them - hopefully teaching the more average developers how to code better in the process.

It’s so simple. You just need to devise the world’s first 100% predictive interview process

I wish it were easy. The most important things to do are usually pretty hard, or they'd be done already.

The flip side to that is that you end up with a dozen services built with different technologies/languages and you spend all your time upgrading them or replacing them instead of building new features.

At least one of them will be guaranteed to be built with some technology/language (probably Scala or Elixir) that one of your engineers (who's since left) was interested in for a few weeks.

For most applications this is correct. Especially those that a homogeneous like a CRUD productivity app, etc.

But when you are building systems it becomes slightly more complicated. Especially those that require that the data science team write their code in Python / PyTorch and the application team write their code in Typescript.

The three most common $reasons I see are: 1) They believe it will help them attract engineering talent, assuming many want to work in a micro services architecture. 2) They believe it will impress investors that they use micro services or be be a red flag to tell investors that their architecture is a monolith. 3) They believe their company will be HUGE one day and that it is therefore wise to prepare for scale now.

But as you can see in the comments in this thread. The coolness of micro services seems to be slowly fading. Feels a bit like the state of noSQL in 2014.

It’s completely insane and unfortunately many are wasting time trying to fix it instead of focusing on real problems that weren’t created for the hell of it.

Strongly disagree - COBOL apps are strongly tied to their obsolete hardware. On the other hand, containerized applications are "portable" - can run on everything that runs Linux.

COBOL can and does run on x86 Linux. I suppose you could probably even put it in a container.

From Big Blue itself, COBOL on a Kubernetes cluster!

https://github.com/IBM/kubernetes-cobol

That fantastic and terrifying at the same time. The complexity of Kubernetes and when you open the container: Bam, Cobol.

It can, but do you really believe is this what those apps are working on, or even that they could work without major rewrite? They are strongly tied to their mainframe environments.

As someone who has worked on migration project from redhat 6 to redhat 7, I strongly disagree.

The article speculates that the hardware is “no more” than 16 years old. Obsolete, but newer than the original code, meaning that it not that strongly tied to the hardware.

I've had to deal with the opposite problem, where we had a monolithic application running on infrastructure that hadn't changed in half a decade (except to keep increasing the size of the EC2 instances because the OOM killer kept sniping processes)

Too much monolith ends with abstraction inversion, which is a Bad Thing.

> ...in 20 years

Refactor that estimate by an order of magnitude.

Most are already legacy next year. (Sadly I'm in that situation too, migrating off an expensive AWS cluster to a single Jenkins machine...)

I mag au Schpätzlä!

I think people tend to under estimate how primitive COBOL is. For example, COBOL does not have variables. Instead, COBOL programs have a raw memory buffer called working storage with named character offsets called records. Both working storage and records can be treated as a raw memory array and it was a common practice to do so. In an analysis of a 5 million line COBOL code base, about 60% of the programs used this feature.

You are also somewhat describing C, in one manner of speaking. Yes, C helps you with syntactic approaches to manage stack and locals, but a large amount of written C operates exactly as you describe for a wide, wide variety of useful reasons from embedded to DSP to OS development to performance-sensitive code (when needed).

Most assembly language architectures operate the same way. There are strong arguments for the mechanical symmetry and sympathy this provides. Even Erlang or Haskell or JavaScript eventually operate in such an environment, where “variables” are memory offsets parsed a certain way, because that is the inescapable operating model of a modern computer processor. That being hidden from high-level programmers does not make it primitive; it makes it useful, increasingly arcane, valuable knowledge in the right hands. Until one understands this thoroughly, as in knowing when a C union would be useful, as one example, there is always more to learn to improve even high-level programming.

Primitive is not the right word to use here. Low-level, perhaps, but the antonym of high-level is very rarely “primitive,” depending on what you’re doing. Yours is an interesting take given the article’s context.

Yes. A lot of COBOL compilers are designed to interoperate with C using a struct and unions as an overlay for working storage. It works, but it's not a convenient way or natural way to program in C.

That depends on how long your memory is regarding C. Working that way was natural and idiomatic C, once upon a time. It reflects the computer, remember.

To be clear, it's one struct consisting of char arrays and unions of char arrays.

Yes. I was aware when I said that. C predates POSIX-like application development and grew into being useful in that role. Particularly in the sciences a lot of that COBOL arena influence went into C programs and it worked just fine. Still does. One way of looking at modern data science approaches like NumPy is reinventing array sorcery like that without the sharp edges of bare pointers, which definitely makes calculation accessible to more people (with less error). That doesn’t indict alternative approaches, however. Again, right hands, right job.

Hiding the computer from the programmer is not automatically better in the general case. It’s better in many, usually in industry. That’s a subtle distinction and fully understanding it will command a salary differential going forward, for a few reasons. Not understanding it is how you get a $500k AWS bill for Spark to process a few billion records that fit in RAM on a laptop.

Primitive is the right word if expensive, error prone human programmers spend most of their time doing work that compilers are much better at.

The difference is that COBOL was intended to be coded by very low skill people.

I’m familiar with one system that was initiated in the mid 1970s with 15 million lines of COBOL. The vast majority is cut and paste dreck that does god knows what.

There’s lots of bad C code, but in many ways the cobol stuff is the equivalent of some crazy collection of interlinked excel files.

About the same age as UNIX.

That's definitely the case with C as well, which is why no one but a complete lunatic would write random business software in C.

It is very primitive. In some ways, it's more primitive than command.com. But, it does math on fixed-decimal numbers that is almost completely unlike IEEE floating point, but it does it in a way that makes accountants happy. If you have money and a ledger, COBOL does what you want.

Is that because it has a runtime decimal library that’s implemented a certain way, or because it has a native data type that uses the processor’s BCD registers?

I’m curious to know if these COBOL programs actually depend on IBM mainframes because of that.

It depends on hardware support. I’m not aware of anything that has it besides mainframes, but if it’s not there, software emulation is used.

Using IEEE floats for money often has... amusing results.

x86 has had BCD support since before I was born. And, as far as I know, when compiling for a platform that's missing a fundamental datatype, it's usually the compiler that adds the missing type as a runtime.

See for example this, a software float for crappy ARM processors.

https://github.com/gcc-mirror/gcc/blob/16e2427f50c208dfe07d0...

I was more so wondering, if a COBOL compiler (given how low level the language is) makes a lot of assumptions about the platform. Even assumptions about potential quirks.

I’m no COBOL expert, but the way a COBOL program sees the machine is very different from what a C program does. I never saw anything resembling assumptions about native data types or anything similarly low level.

And I never imagined an x86 could deal with decimal floats.

> https://mudongliang.github.io/x86/html/file_module_x86_id_82...

Just for your reference about x86 and BCD.

I’m impressed now.

That's how I learned about COBOL's behavior. I was on a consulting gig with some COBOL programmers that had been sent to a learn-java-in-21-days course. When I arrived I found they had used float for money, because they didn't know any better. We eventually switched over to BigDecimal, but not until the staff were convinced by continuing problems with the results. Now I just talk about Muller's Recurrence

https://scipython.com/blog/mullers-recurrence/

https://latkin.org/blog/2014/11/22/mullers-recurrence-roundo...

And show people https://0.30000000000000004.com/

Also see https://stackoverflow.com/questions/30215023/how-cobol-handl...

I think the culture within COBOL is equally backwards. As someone else said, it’s targeted at people who’s main skill isn’t software engineering, but understanding of business logic.

I was once spoke to a consultant who in a past life fixed big COBOL projects. He said that one of the common technological and organisational challenges he faced was getting people to use ‘malloc’. Apparently there are COBOL programs that just SEGFAULT when the input reaches a certain size, and some developer has to change an array allocation size. COBOL developers would be hostile to the idea of dynamic memory allocation, and he’d have to explain that the rest of the world had been doing that for the last 30 years.

I remember having a "malloc" moment moving from fortran to c. "You mean ... I can just ask for more memory?!"

Interestingly, since Fortran 90, using dynamical allocation is much more developer-friendly than in C (I know, low bar).

Fortran’s allocatable variables can’t leak memory, can’t be used after being deallocated, and can’t be deallocated twice. Bounds checking is also trivial and all decent compilers have a flag to do it automatically.

The only problem is that the rest of the language is developer unfriendly, plus you have old school FORTRAN programmers who think it is perfectly acceptable and modern to use statically allocated arrays on the stack just because they aren't COMMON blocks.

Fair enough. The language has quite a bit of bagage and some habits are hard to break.

That said, it is not unpleasant to use for numerical codes, when you’re not working with people stuck in 1977 (so, no common blocks, everything in modules, decent array syntax, etc). It fits its niche quite well, with Python for everything else.

Interestingly the language doesn’t define stack/heap allocated so sometimes there’s a compiler flag to put «stack arrays» on the heap, since implementations are free to choose anyway.

You can do that in Fortran, too, since 1990ish. Out of curiosity, when did you last write Fortran code?

This was F77. Never had the joy of F90

The SEGFAULT is even a bigger problem than the resizing.

Some COBOL dev came in and proclaimed they could do a websites just like anybody else. I asked what they did when input became too big. ”Oh well. The transaction will dump a bit, and then the duty operator will find some dev to look at it and increase the buffer” was the response.

The whole security aspect of the buffer overflow was completely alien to them. The idea that a random internetizen would try to attack the site was unthinkable, let alone they might come from another country. A botnet? of internet connected stuff? That happens only on TV. Besides, with 4 billion IP adresses, the chance an attacker found us was minuscule.

Lucky for me they tried to sell that theory to the infosec team, then got shouted at for half a hour.

The language is fine: It's the ecosystem that's not.

Nobody in the top 50 CS programs worldwide teaches COBOL. Most of the COBOL programs run on mainframe where it's at least a few k$ to even get a look at the documentation or hardware. So nobody bothers with it.

And most (older) programs don't folow modern conventions either. Custom application specific databases? Check. Lost source code/incomplete? Check. No version control? Check.

And most folks running these programs are in orgs that are chronically underfunded anyways.

Well, and the COBOL is also likely running in an ecosystem with similar skill shortages. AS/400, or z/OS, MPE, etc. Things like file transfer, message queues, backups, batch jobs, os specific file formats,and so on won't be in COBOL. They will be in various different proprietary setups.

I'm really curious how the hiring for jobs on legacy mainframes works.

My Dad was the consultant IBM hired to fix issues in system/32/34/36 and AS\400 software for customers in Australia. He had a title related to RPG, but I don't know what it was. Growing up we had a (functioning) system/36 and later an AS\400 in the shed. He's never stopped developing, still works as a .Net developer, but hasn't been able to get through the recruiter filter for RPG and cobol jobs, possibly because he hasn't worked with recent generations of these tools, even as he is getting hired for .Net jobs on major systems.

"He had a title related to RPG, but I don't know what it was."

That's pretty neat. RPG is apparently the default high level language used on IBM midrange systems (AS/400).

I looked at a beginners tutorial here: https://www.ibm.com/support/pages/coding-rpg-iv-beginners-tu...

It seems very similar to other procedural languages, and one of the examples shows a very easy FFI interface to call out to C. They make a wrapper for printf.

>Custom application specific databases

Not doing COBOL but am working with an ancient application supporting business operations and this is my hell. Also, the databases are likely ancient, outdated, and poorly documented (at least according to my PTSD).

"Oh it uses an oracle db? What version? 10? FML - you know that versioncan legally drink in Canada, and the EOL for that product is going to have a bar mitzvah in a couple years, right?"

At least with IBM the documentation is freely available, but you're pretty SOL if you encounter non-IBM platform. Some have docs, some don't, but finding IBM is at least reasonably easy.

Doesn't matter: the industry has moved-on.

They had to make it open decades ago. Now it's too late.

I don't think that is really accurate; nothing processes transactions like an IBM mainframe. To draw a crude automotive analogy, no matter how much you soup up a truck, it is never going to be a locomotive. It is simply a different scale of machine.

Are there actual objective benchmarks for things like this? Everything you actually see out of IBM is so bad (blockchain 5G AI cloud nonsense) and Moore's law exists, so it's hard to believe this stuff is that good as opposed to just having a really good moat.

I am surprised how many government/bank systems run on 50s-70s code; it makes you wonder if we kept in practice writing those kinds of things since then.

IBM is a shell of what it used to be. I don't know if what the grandparent is saying is true, honestly i highly doubt it, but its unfair to compare old ibm with its current incantation of marketing fluff and bad high priced consultants.

> Are there actual objective benchmarks for things like this?

Probably not, but they are machines designed for throughput, with a multitude of intelligent peripherals that pipe data in and out of the CPU, which will be running at close to 100% speed all the time. The CPUs themselves are quite impressive (they present at Hot Chips regularly) and each cluster of 4 sockets share almost a gigabyte of L4 cache. Everything is also constantly checked, audited, logged for security and reliability.

I wouldn’t be surprised if these machines thoroughly smoked a rack of souped up x86s at a similar budget in transaction processing applications.

Problem is, it's a machine that's from one and one vendor only.

You can buy a truck anywhere and run it on almost any road. The locomotive has to be from the one locomotive company and good luck running it outside of (really expensive) tracks.

Not even close. Mainframes can hot swap stuff while running jobs.

So can distributed systems? All you need is a queue in the right place or some other kind of data store? It’s relatively easy to decouple data models from processing, you just have to consider failure scenarios? I mean, the distributed non-mainframe way of doing things is you just use more units of hardware to make up for deficiencies? I imagine the hardest thing to port is well, the equivalent to “if we scale up this machine and buy lots of RAM, our data fits in RAM and we can run this code that much faster,” but even then, can mainframes really handle that much more data by virtue of being mainframes with all their legacy?

The way I’ve heard it described, it’s not the features of a mainframe that sell it now, those are commodity. Instead it’s the existing code that ties companies to mainframes - they don’t want to rewrite logic they likely don’t actually understand the details of if it’s already been tuned and tweaked to work for their business? To that end the future of mainframes is probably virtualization of hardware and improved static analysis tools to better support codebases we don’t understand because they’re decades old, etc.?

You are right in the sense that a modern mainframe is reminiscent of a cluster of specialised computers connected through multiple ridiculously fast interconnects. The difference is that IBM offers the software you’ll need to manage the environment.

Aren't we facing the exact same problem, but now rehashed in the cloud?

A lot of companies are running applications that rely heavily on AWS managed services. If you're tied to DynamoDB or Athena, you're in no better position than being tied to IBM mainframes.

That's absolutely true. Though with one small exception - most mainframes I hear about don't seem to be hosted in the cloud yet. I imagine cloud hosting of mainframe workloads is possible if and when moving to virtualization becomes an easy, supported service (if it isn't already, of course) and is perhaps just as cost effective but with different security features and deployment models available due to operating in the cloud? For example, it might make on-site maintenance a thing of the past or lead to new managed services? I'm absolutely not going to say that the cloud alone leads to cost savings, it probably doesn't. For true cost savings in the cloud you often need to re-architect the app and change business and IT processes to match what the cloud can offer, I'd think. Besides possible security benefits, if a workload takes hours to run, the cloud could allow you to parallelize the workload and run jobs as test cases, maybe?

Google didn't have money for an always up, 100% reliable mainframe. So they built fault tolerance on top of off commodity hardware.

Fast forward years later, why would they pay the mainframe tax and lock themselves to a single provider?

Are there other non-IBM companies that have a lot of active mainframes? I was under the impression that the vast majority of mainframes in use were System Z or its kin, but maybe I'm just falling for marketing.

COBOL exists beyond mainframes; usually in that case the alternative would be a Unix server (or something approximating one; I've seen COBOL-on-CentOS in the wild).

But yeah, as far as mainframes go, at least here in the US, IBM - and specifically AS/400 - is pretty much the only game left in town.

I have a couple of Vendor supplied programs that run on MicroFocus COBOL in a Linux environment.

The product line supports IBM mainframes and a few other platforms, so I assume it's easier to target the mainframe first and then the other platforms.

> Are there other non-IBM companies that have a lot of active mainframes? I was under the impression that the vast majority of mainframes in use were System Z or its kin, but maybe I'm just falling for marketing.

I think Unisys is still around...

https://www.unisys.com/offerings/clearpath-forward/clearpath...

https://en.wikipedia.org/wiki/OS_2200

https://www.unisys.com/news/News%20Release/New-Unisys-High-E...

There's significant amount of COBOL running outside of mainframes, mostly with MicroFocus offerings and combined with various other presently less-known technologies.

Then there's a bunch of mainframe stuff still running around on IBM clones (especially in Japan, afaik). Unisys is still up, and there are still active Burroughs Large Systems deployments (now under ClearPath name, I think?) and few other niche systems.

Sounds like a pretty solid moat around the business model.

Top CS programs are not about learning any specific language.

Correct, but they'll have students coding in a real environment as a side effect of submitting assignments.

And nobody does that on mainframes or using COBOL.

Database will be DB2, VSAM, or ISAM files. At worst, this is no worse than the seat-of-the-pants noSQL, YAML garbage that underlies many "modern" apps.

Or IMS - a pre SQL database.

Or Object Star.

Or M204.

These can be done better than a seat of the pants noSQL database, but sometimes people also got creative in the past too.

I've seen all of those databases being used in legacy government departments.

A few years ago my country's and other Latin American import and export system still partially run using an MS Dos app. I wouldn't be surprised if they would still be using it now.

At least MS-DOS is pretty well documented.

Maybe COBOL needs a Racket-type implementation that can be hacked upon to make it cool again.

Have you tried COBOL ON COGS?

http://www.coboloncogs.org/INDEX.HTM

COBOL on wheelchair: https://github.com/azac/cobol-on-wheelchair

Coming from a C#/Java background, discovering Smalltalk was an eye-opening experience regarding supposed "legacy" programming languages. I would argue it's a more expressive language with simpler syntax (I dare say the simplest) and has had language features for decades that Java and C# have only recently added. That's how I learned newer isn't always better.

This bit of the article struck a chord with me: "The issue is institutional knowledge — when the people who wrote an application 20 years ago leave, the remaining people often don’t know the application with anything close to the same intimacy."

Code readability, testing practices, and the types of patterns employed (or really the types of anti-patterns avoided) are more important than the language used if you expect anyone to be able to maintain a system over time. These are like embedding artifacts of institutional knowledge in your code to guide future maintainers. The choice of language alone doesn't carry any institutional knowledge.

> Code readability, testing practices, and the types of patterns employed (or really the types of anti-patterns avoided) are more important than the language used

This is very true, but also a bit of a fallacy - in particular for unexperienced developers.

Saying it in the way you did can create the impression that the choice of the language is not important as long as the mentioned properties are taken care of. But it does not mention that these things are not independent of each other. The choice of language has a huge impact on readability, testing and patterns (all else being equal).

I would phrase it the other way around: because code readability, testing practices, etc. are so relevant, it is important to choose a language that makes these things as easy and productive as possible.

I think much more than language syntax and features, it was impressive until ~5-10 years ago just how advanced IDEs for Smalltalk and Lisps were compared to any other language. There has been a massive catch up in recent years, though I think many dynamic languages are still behind on their IDE support compared to these ancient technologies.

Edit and continue still aren't as good as those IDEs are capable of.

Then there is the whole stack REPL development experience, which probably Powershell + .NET + COM/UWP on Windows is the closest we get today.

For a little while UNIX seemed a couple of interesting ideas when compared against MS-DOS/Windows 3.x and Amiga OS, then I discovered Xerox PARC research, and the world of Lisp Machines, Mesa XDE, Mesa/Cedar, Smalltalk.

Or if you want a closer example, RAD development tools for the desktop versus what SPA still aren't able to offer on the Web.

> are more important than the language used

Yes, many organizations have made the mistake to switch language in hope of solving their problem with a messy code base when it was their own bad practices that where at fault all along and then consequently just repeating bad practices in another language.

It is not the language that is the limitation, it is the programmer.

> “COBOL doesn’t present any security problems because it doesn’t really talk to any resources,” Malik said. “It just says ‘read’ or ‘write.’”

Well, in a world where "talking to resources" is most of what we want software to do, that doesn't sound great, frankly. You can see how that would cause problems with people who are trying to use a website to interface with an unemployment system written in COBOL, which is the example the article leads off with.

Thank you. That line made my head turn as well. All IO is just saying "read" and "write." And all systems that do any real world work are doing network IO.

> “COBOL doesn’t present any security problems because it doesn’t really talk to any resources,” Malik said. “It just says ‘read’ or ‘write.’”

Can someone knowledgeable of COBOL expand on this? It sounds... not quite right, like it's missing some surrounding context. I feel like plenty of C's common security problems could be boiled down to "just reads and writes".

I could be wrong here so others can correct my errors as required.

My take of that comment is COBOL is very popular on mainframe systems and those mainframe system work around the concept of transactional batch processing.

Processing is done in batches and the batches are control bay a transaction manager (i.e. CICS for example).

In that model a COBOL program is just a step in the processing and is fully controlled the transaction manager.

So in that sense it does just read and write data as one step in a much bigger batch of steps.

As such the security is handled by the transaction manager layer.

COBOL on System/Z doesnt even know how to do file I/O, you set up the I/O in the JCL job that loads the COBOL application.

That's just the default way of handling I/O on MVS descendants, but it's not the only one - pretty sure you can allocate and configure new "file open records", but it would make your program less portable ;) and there's rarely a need.

The very concept of files is alien. You have datasets that look like card stacks or tapes. You don’t expect files and directories on machines that predate disks.

I see two problems with such a claim. First, a practical one: COBOL programs can call external functions[0]. Second, a theoretical one: Even if a given program does not call external functions, they often read data written by other programs and write data read by other programs. The security implications seem obvious; a bug in a COBOL program can cause undesirable consequences outside of the program.

[0]: https://www.ibm.com/docs/en/zos/2.1.0?topic=cbcc-calling-bet...

I don't know anything about cobol, but its not uncommon to try and sandbox a c program (e.g. with seccomp) so it can do a limited number of things such as read and write from a few file descriptors, with the hope that if its compromised, there is nothing interesting to do if you don't have the rights to make any system calls, etc.

Of course there will always be security flaws, anyone who says otherwise is probably trying to sell you something, but reducing attack surface is a good risk mitigation strategy if done correctly.

COBOL lives on modern technology: https://gnucobol.sourceforge.io/

Free as well! Take it for a spin.

Issue with COBOL is not COBOL, it's stretching its use ad absurdum. It's not C or lisp.. whenever you try to make something convoluted.. the language will fight you and it will end up in spaghetti mess (never written cobol, but I've seen enough pages to see). Added bonus, years of code generators on top of old sources.. not pleasant.

This is probably a dumb question, but what language an early COBOL compiler was written? Is that assembly? How the language runtime was connected to the I/O? Was there even an operating system? COBOL and mainframe seems so arcane to me that I'm not sure where to start understanding the whole stack.

At least there's little chance of suffering ageism as a career COBOL technician.

Sorry to disapoint you. My friend who works in recruiting told me, that one company wouldn't accept perfectly skilled candidate, because he was around the same age as their current COBOL developer. They argumented, that they don't want both of them die around the same time.

Not really sure that's agism.

It is at least according to the law, i.e. that you don’t discriminate against protected classes, regardless of why.

No, you can discriminate on any basis if there's a "reasonable factor" unrelated to that basis. Models and actors, for example, are selected by age, race and sex quite routinely.

Eh, that’s not how it’s written I believe? Not that it really applies here, but you can (and have to) discriminate against a protected class if it is a core part of the job requirement that excludes them and there is no reasonable workaround. For instance, if there are no accessible robotic exoskeletons around, discriminating against someone unable to lift 50 lbs because of a physical disability if the job requires someone to lift 50 lbs all day is perfectly legal. If you’re hiring someone to act as a 20 year old, you can discriminate against people because of their inability to look 20 all day long, etc.

The problem is such as this case where the company seems to think that people aged the same die at the same time? Which doesn’t seem to have any plausible basis in fact or a reasonable job requirement.

>>The problem is such as this case where the company seems to think that people aged the same die at the same time? Which doesn’t seem to have any plausible basis in fact or a reasonable job requirement.<<

Wouldn't an actuarial table suffice?

It would suffice to show that it isn’t true that everyone at the same age dies at the same time, if that is what you meant?

As opposed to them quitting at the same time? What kind of rationale I'd that.

That almost sounds like an "old programmer" joke. Are you sure he wasn't pulling your leg?

I'm almost certain that your mate was telling a joke. People don't usually die on the job, they retire before that.

You won’t suffer a respectable salary, either. COBOL doesn’t pay well, even as it’s increasing in importance.

You'll be paid enough to be comfortable, not rich, even more so when you consider that most COBOL jobs are not in Silicon Valley.

Money can't buy everything nor can it be the salve for all indignities.

Okay, but it sounds like COBOL is indignity and low pay, yes?

If I’m going to go and make less money as a deliberate life choice, it’ll either be something overtly charitable or it’ll be doing something fun, like in the arts. It won’t be boring work for someone else to profit off of.

Case in point, the governor of New Jersey asked for volunteers.

The US Military is a force comprised of volunteers, and yet they get paid.

The article quotes Marianne Bellotti quite a bit, and I recommend her newish book "Kill It With Fire"

Well, people still use Lisp, Fortran, BASIC, and C.

According to the TIOBE Index, C (1972) is the most popular programming language in April 2021 (followed by Java, Python, C++, C#, Visual Basic, JavaScript and, uh, Assembly Language. Fortran was at #20.)

So COBOL is in good company. ;-)

Current C is not 72's C, not even ANSI C.

My job is writing code in ANSI C89 so cant say that's true everywhere.

Ansi C is fine, but anything before TCPL 2E it's out of question.

Curent object-oriented COBOL 2014 isn't Admiral Hopper's system programming language for writing missile defense systems in in the 1960s either. Your argument doesn't hold.

COBOL was never "Admiral Hopper's system programming language for writing missile defense systems in in the 1960s either."

It was always designed for business type applications.

Back in the 1960s assembly language was used for writing the missile defense systems and other systems programming [later C and Ada, etc became prevalent].

Having spent some part of my career rewriting COBOL into Java (1.4, so, you know, not cutting edge) I don't really have much good to say about COBOL but I have found the coverage of COBOL so weird in the media.

As you very rightly pointed out, no one ever goes, "The networking stack in your smartphone is written in C, a nearly 50 year old programming language" but governments underfund their IT infrastructure and then go, "Welp, nothing we could do, COBOL is sooooo old."

The amount of mismanagement that gets deflected away by pointing at COBOL and tapping into the largely justified distaste the development community has for COBOL is a real convenient out for the people responsible for that mismanagement.

I don't know who originally said it, but does the old adage, "code is harder to read than it is to write" apply here? Is COBOL more difficult to read than C?

COBOL's a lot simpler in that the words are (should be) more expressive, but as it's less powerful than C it's less terse and there's a lot more reading to do. So the ability to understand a program isn't necessarily better in COBOL than in C.

OK, but in C I have functions to open, read, and write sockets. Do I have them in COBOL?

This matters, because with C I can connect my existing C software to a web server, which lets me tie ancient software into the modern infrastructure. I suspect that's harder to do with COBOL...

Well, C only “has” these things because they are in a library (which, by the way, doesn’t even have to be written in C).

Yes, you even do have objects for that matter.

Latest Cobol revision is from 2014 and you even have Visual Cobol, https://www.microfocus.com/en-us/products/visual-cobol/featu...

C is certainly still popular, but it probably wouldn't be if there wasn't so much infrastructure built in the last 50 years that keeps it in demand.

What's really interesting to me is that SQL and ML were created in 1973 and 1974 respectively. And yes, those languages have evolved over time, and yes, they have some warts and telltale signs of age... but overall they still are considered very high level languages, and are still incredibly popular in their own right.

For a recent project, I chose F# (an ML descendant) and SQL, not because I had to integrate with legacy software written in those languages, but because they're still great languages.

A note to remind that latest revision is from 2014 and there are even graphical enviroments,

https://www.microfocus.com/en-us/products/visual-cobol/featu...

That's Microfocus VisualCOBOL, IBM Enterprise COBOL had a release in 2019: https://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=c...

2014 is the year of ISO standard.

Reply on news.ycombinator.com