From personal experience: BNP Paribas is one of the biggest bank in the world, top 5 if you exclude Chinese state owned ones, and they pay mainframe related jobs like shit.

Being young, smart and with a whole career ahead, you have no future working has a COBOL developer, no one should spend his life picking up shitty code left by his elders decades ago.

Would you say that to a civil engineer who works on infrastructure maintenance?

Computing is critical infrastructure in many areas of government and business. The solution to all problems cannot be “screw it, we’ll just rewrite in Go with a React frontend.” Some things should be rewritten and some should be maintained.

Funny to me how so many in this thread rag on COBOL, yet when other languages come up it is always 'well this language is good for abc but I wouldn't really do xyz in that one'. COBOL is extremely good at what it was designed for - data processing, and lots of it.

Well, the hardware that COBOL usually runs on is good for that, sure. And its usually (now) running legacy systems that no one wants the risk of reimplementing from the ground up. But is the language itself particularly well-suited to the task? I think that’s less clear. Certainly, I’ve never seen a coherent argument about how the language itself is superior to modern alternatives even for large scale data processing; if it was, it would be popular for greenfield projects in that domain, you’d think.

What modern language doesn’t have either fixed-point or arbitrary-precision decimals (or both) in either the core language or standard library?

I mean, sure, C doesn’t (and I don’t think C++ does), but those aren’t particularly modern languages.

The language combines presentation and storage in a way I've never seen in any other language. Let's say you have an 8 digit variable. You can then specify that the last two digits is represented by a different variable, and thus the second variable will only work on those last two digits.

This is useful when you have formatted fields, where you have a variable that holds an ISO 8601 date, with other variables representing the year, month and day parts.

In a language like Java, you need to create a class that holds this information, with separate methods to manipulate the individual components and formatting the output.

In COBOL you only need a few lines of declarations to do this.

The drawback is that now presentation is tightly associated with the data storage, meaning that changing presentation format can be a lot of work. This is why COBOL programs were so problematic during Y2K.

Even in newer languages like Java, there is lot of work that is mostly application maintenance and adding new features to existing decade old applications. It is not bad work.

Despite producing some of the best engineering talent in the world it seems that French engineer are systematically underpaid.

And the visa issue is way overblown. It's easier than you think for a real engineer with experience.

> In my country and in Sweden it is quite easy to get good and stable job in banking/insurance/consulting business

Yes, that much is true: a stable job in banking/insurance. Mostly maintaining clunky legacy systems. If that's what you aspire to, and aren't passionate about software -- which is perfectly fine! -- I guess learning some COBOL is a reasonable career choice.

This is a completely unfair assessment. Even if you're passionate about something, job stability and good pay are going to be the primary drivers in decisions about jobs. I doubt that most people choose, say, Java jobs because they're passionate about Java, or even software in general, for example.

From what I gather, most people leave the "passion" part of their work to part-time hobby work, allowing them to do both. If it then translates into money, good, but the few successes that have been put on blast have blinded people to the reality that passion != money.

> Even if you're passionate about something, job stability and good pay are going to be the primary drivers in decisions about jobs.

For a lot of people, yes. Not for all. And even then, it's hard to argue that COBOL is cool or interesting. It's just paying the bills, but nothing to get hyped or write gushing articles about. And there are more interesting programming jobs that will also pay the bills, anyway.

Unless there aren't.

Either way, you're judging people simply for taking a different path than you, which is completely unfair.

I didn't mean to judge people and in fact tried not to, though perhaps clumsily. I said it's fair to not be passionate about the job. Often I haven't felt passionate about it either, or even particularly motivated. And do note I have worked in COBOL, so I understand the need. I just don't like the language and I don't want to see people selling the idea that it's "interesting" or a particularly sound business decision to learn it -- like those articles that occasionally get posted to HN.

That's not what you said, though. This is what you said:

> If that's what you aspire to, and aren't passionate about software

Those are completely different sentiments and your original "aren't passionate about software" statement is the statement I took issue with.

This is one of those things that is easy to discuss in theory, but in practice it doesn't work that way, at least not in most cases. And in my experience working with COBOL at a bank: no, the employees weren't passionate about it. In fact, the only passionate employee was an old guru who wrote assembly code for the bank's mainframe.

You could take it to an extreme, and argue that working with malfunctioning computers, using only BASICA.COM for DOS, writing accounting software and getting paid mere cents for it, requires more passion -- after all, who would want to work like this if they didn't feel passionate about it -- but of course it isn't.

It's great to work in challenging or atypical projects, maybe with tools that are not the easiest or more ergonomical, but there's a baseline of comfort below which you're probably not passionate, just masochistic.

I leave my passion for when I log off the VPN.

I love my job, and I leave work at work so it stays that way.

As we build tools to make that plumbing easier for certain use cases, we might move around in the hierarchy to plug different things together, but I don't think anything has fundamentally changed in an alarming way. We're still just moving bits around!

I remember an explanation that Sussman gave for why MIT retired the SICP course, replacing with it a course in which students program robots with Python.

He said (and I'm badly paraphrasing) that one used to be able to scale up your reasoning about how a piece of software works in a similar way to how you do it when looking at a circuit diagram: you have these little components with discrete behaviors and you can simply combine them and be able to predict the result.

Today, however, as programmers (to a greater extent than before) we create systems by cobbling together large, opaque, libraries whose properties are poorly described and require one to essentially "do science" on those black boxes.

And the trade-off is that we're often better off plugging A into B, and hence there's a lot more of that sort of line work in industry.

edit: I should say that I don't much like that sort of work, but it was unwarranted to say it is 'alarming' that the trend has gone this way.

then you force it together with whatever you have at hand, and wrap it all in a thick layer of duct tape. That's exactly like software engineering.

That's an okay salary in absolute terms, but it's not a great one for a software engineering position. Even in a fly-over state.

But taking that job is basically career suicide. After 3-5 years of doing that, you'll be completely unemployable outside of insurance unless you spend time on your own learning useful skills. And if you do that, you're probably starting back down in a junior or mid-level role.

Anyone would be much better off getting an AWS cert and learning to write SQL.

[1]: https://grammarware.net/text/2020/babycobol.pdf [2]: https://slebok.github.io/baby/

It seemed to be more or less as expected - fairly straightforward and apparently easy to learn, but unattractively bureaucratic.

My understanding is that you don't get paid the top money for knowing the language but for being able to understand and maintain/revise the kinds of systems it operates - which is a whole other level of skill and experience, and not something you can just pick up in a few evenings of side projects.

Technically most of Europe don't need convert to EUR, they already use Euros so they're also more likely to need to convert to USD.

What currency? The kroner is with about $.12 so that’s not particularly enticing.

I hate COBAL a lot, and incidentally for many of the same reasons I hate Java.