It’s COBOL all the way down(increment.com)
increment.com
It’s COBOL all the way down
https://increment.com/programming-languages/cobol-all-the-way-down/
190 comments
Can you point to any accessible versions of this? I’d love to check out an example, sounds really interesting.
Unfourtunately not, it’s part of a very expensive ERP package. But this article has a few screenshots:
https://www.scopesystems.com.au/whats-new-pronto-xi-740-scop...
https://www.scopesystems.com.au/whats-new-pronto-xi-740-scop...
Is this really all the same COBOL application? I'm truly impressed! Is there some kind of GUI toolkit for COBOL or the COBOL in this case only the logic behind the application and the GUI here is another language/framework?
I ask because your parent comment certainly rings true if this is all COBOL!
I ask because your parent comment certainly rings true if this is all COBOL!
Seconded
Don't know if you're referring to this -- but hey everyone, if your company uses PeopleSoft, guess what... :)
What makes COBOL cool compared to, say, JavaScript, which can do everything COBOL can and more (such as pass functions/closures around, etc.)?
The programs are very uniform. There is not multiple ways of doing things (at a presentation level). So you get to use hundreds of thousands of existing apps written over the last N decades in your modern web application.
You just couldn’t write them all over again, there isn’t a team on earth that could, even with infinite money. You’d be talking, I think, more than high double digits, millions of LOC.
JavaScript by comparison .. today it’s React/Angular, but it is very fluid. Not much code will be practically reusable in 5/yr from now.
You just couldn’t write them all over again, there isn’t a team on earth that could, even with infinite money. You’d be talking, I think, more than high double digits, millions of LOC.
JavaScript by comparison .. today it’s React/Angular, but it is very fluid. Not much code will be practically reusable in 5/yr from now.
> There is not multiple ways of doing things (at a presentation level).
Love the insight. Established businesses like banks look for this kind of stability. And upstarts who build from ground up to challenge status quo, they go on to figure out ways to win with es6 and their friends.
Love the insight. Established businesses like banks look for this kind of stability. And upstarts who build from ground up to challenge status quo, they go on to figure out ways to win with es6 and their friends.
Not much code will be practically reusable in 5/yr from now.
Is that really true? If you look at a lot of JS from 5, 10 or even 20 years ago it still works. The main things that stop it working are security changes, which is arguably a good thing. I don't see why many of today's JS libs will stop working in the future unless there's a good reason why they should.
Is that really true? If you look at a lot of JS from 5, 10 or even 20 years ago it still works. The main things that stop it working are security changes, which is arguably a good thing. I don't see why many of today's JS libs will stop working in the future unless there's a good reason why they should.
How does one search and utilize the use hundreds of thousands of existing apps written over the last N decades? Is their a CPAN like tool for COBOL?
I'd guess
1. They are already in place and in use.
or
2. Vendor/consultant is aware of them.
1. They are already in place and in use.
or
2. Vendor/consultant is aware of them.
I see. First rule of COBOL club. Don't talk about COBOL club.
It gives you correct answers to simple questions like this:
> console.log(0.1 * 0.1)
0.010000000000000002I’m not sure I get your joke. Every system, JavaScript, COBOL, C, Java, etc etc etc, has this behavior. Floating point decimals when converted to binary, are a rather rough thing for a system to handle. For example, 0.1 in binary is a repeating number. Basic operations on those binary values are very very fast but not always 100% accurate due to the binary nature of decimals. There are packages which allow for very precise floating point calculations but will cause performance degradation compared to the basic operations. It all depends on what you need.
COBOL uses fixed-point decimal arithmetic, not binary floating-point. You'd declare these variables as PIC V99 and then get a nice neat .10×.10=.01 (or as PIC 99V999 and get 00.100×00.100=00.010, or whatever). This is because it's a Business-Oriented Language, and businesses don't want floating point rounding errors in their finances.
Incidentally, this was actually faster than binary floating-point on the machines for which COBOL was designed, which used EBCDIC and had special circuitry for arithmetic on binary-coded-decimal numbers. You could operate directly on the decimal representation without having to do any conversion for I/O.
Incidentally, this was actually faster than binary floating-point on the machines for which COBOL was designed, which used EBCDIC and had special circuitry for arithmetic on binary-coded-decimal numbers. You could operate directly on the decimal representation without having to do any conversion for I/O.
Nit: the COBOL spec dates to 1960; EBCDIC came later, ~1963. In 1960, character codes were specific to the manufacturer, and sometimes to the machine. IBM had a 6-bit BCD code that was mostly consistent across its line, but Univac had its own which was quite different.
Intel x86 can also work natively with BCD numbers.
https://en.wikipedia.org/wiki/Intel_BCD_opcode
https://en.wikipedia.org/wiki/Intel_BCD_opcode
Very cool. Unfortunately it's no longer supported in Long mode (x86-64). :-(
I used to do a lot of BCD in embedded POS stuff. No one will miss it. You can do anything you can do in BCD with regular integers if you have any understanding of integer arithmetic. Yeah, it is going to take a little more time to convert to/from decimal digits you can display/input but processors these days have fast integer division so that doesn't matter.
A current issue is that a lot of programmers are bad at integer arithmetic. It isn't really taught in school.
A current issue is that a lot of programmers are bad at integer arithmetic. It isn't really taught in school.
I worked in insurance so much time ago, in a COBOL shop (I was doing web-services on top, so I'm not a COBOL programmer myself). A few things come to my mind:
- COBOL has no stack and no dynamic memory allocation. The memory cost of a procedure is known in advance and you cannot leak memory. There is not much room to be smart, and in the long run it's likely a reason for success. You would not want people with a three month training editing 20-yr old C code.
- COBOL procedures are damn CPU-efficient at what they do
- COBOL works in symbiotic relationship with DB2. A lot of things that are complex/tiring to do in COBOL (like e.g. working with strings...) can be done in SQL. And when you have SQL you can do pretty powerful things.
- COBOL procedures do not usually sent SQL queries as strings to the database. They compile down to a procedure that does physical, low-level handling of database tables. If you change a table, you have to recompile all procedures that depend on it (and it may take hours to days....) but again is damn efficient in production.
- mainframes run constantly at a CPU usage of over 90-95%. There is a huge amount of procedures constantly running to maximise the return on the system.
- COBOL has no stack and no dynamic memory allocation. The memory cost of a procedure is known in advance and you cannot leak memory. There is not much room to be smart, and in the long run it's likely a reason for success. You would not want people with a three month training editing 20-yr old C code.
- COBOL procedures are damn CPU-efficient at what they do
- COBOL works in symbiotic relationship with DB2. A lot of things that are complex/tiring to do in COBOL (like e.g. working with strings...) can be done in SQL. And when you have SQL you can do pretty powerful things.
- COBOL procedures do not usually sent SQL queries as strings to the database. They compile down to a procedure that does physical, low-level handling of database tables. If you change a table, you have to recompile all procedures that depend on it (and it may take hours to days....) but again is damn efficient in production.
- mainframes run constantly at a CPU usage of over 90-95%. There is a huge amount of procedures constantly running to maximise the return on the system.
I debugged many a COBOL pragram by running down the stack. In fact, I wrote a COBOL debugger for Sperry/Univac 1100's running HVTIP transactions.
Maybe I remember incorrectly, or they just did not use it because it was a different revision/standard. Obviously COBOL today has everything (there must be reactive COBOL somewhere).
Classic COBOL needs a stack (or something equivalent. A popular choice was to store return addresses of calls near function entry points, distributing the stack through memory) to support the case where a single subroutine is called from more than one place in the program (most, if not all, programs will have those, if only to do I/O)
What it doesn’t need (and didn’t support) is recursion, and without recursion, the maximum depth of the stack can be computed at compile time, so that a program can refuse to run if there isn’t sufficient room for a stack that size. (The first FORTRAN’s were similar in this respect. If you wanted your program to support larger arrays, you recompiled it)
What it doesn’t need (and didn’t support) is recursion, and without recursion, the maximum depth of the stack can be computed at compile time, so that a program can refuse to run if there isn’t sufficient room for a stack that size. (The first FORTRAN’s were similar in this respect. If you wanted your program to support larger arrays, you recompiled it)
> COBOL has no stack...
So no function calls?
So no function calls?
> So no function calls?
No recursive ones. If you forbid (direct or indirect) recursion, then a function's local variables can all be static rather than stack-allocated. Similarly, each function could have a hidden, static "return address" variable (since all parameters are static, it's really just a hidden parameter) that is set behind the scenes when a procedure is invoked and jumped to when it exits.
edit: I was just guessing how you'd do return addresses, but it looks like that is how they used to work. From Wikipedia: "Machines before the mid 1960s—such as the UNIVAC I, the PDP-1, and the IBM 1130—typically use a calling convention which saved the instruction counter in the first memory location of the called subroutine. This allows arbitrarily deep levels of subroutine nesting, but does not support recursive subroutines."
Ancient Fortran also didn't support recursive procedures, and they were only sneaked into Algol 60: https://vanemden.wordpress.com/2014/06/18/how-recursion-got-...
No recursive ones. If you forbid (direct or indirect) recursion, then a function's local variables can all be static rather than stack-allocated. Similarly, each function could have a hidden, static "return address" variable (since all parameters are static, it's really just a hidden parameter) that is set behind the scenes when a procedure is invoked and jumped to when it exits.
edit: I was just guessing how you'd do return addresses, but it looks like that is how they used to work. From Wikipedia: "Machines before the mid 1960s—such as the UNIVAC I, the PDP-1, and the IBM 1130—typically use a calling convention which saved the instruction counter in the first memory location of the called subroutine. This allows arbitrarily deep levels of subroutine nesting, but does not support recursive subroutines."
Ancient Fortran also didn't support recursive procedures, and they were only sneaked into Algol 60: https://vanemden.wordpress.com/2014/06/18/how-recursion-got-...
Although I am not familiar with COBOL I am assuming this means you have to indicate where the control returns to after a function ends
So that's kind of like a coroutine. Taking recursion away seems like an unnecessary limitation, considering how much power main frames have. Resource efficiency is great and all, and certainly there's a benefit to not hammering the stack as often, but that takes away an entire category of definitions you can't express, right?
Maybe someone who writes cobol could chime in on this.
Maybe someone who writes cobol could chime in on this.
> Taking recursion away seems like an unnecessary limitation
Modern Cobol doesn't seem to have this limitation, eg http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/handhel.... When Cobol originally appeared, call stacks weren't standard, Lisp didn't exist yet, and neither Fortran nor Algol supported recursive functions; it made sense at the time.
Modern Cobol doesn't seem to have this limitation, eg http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/handhel.... When Cobol originally appeared, call stacks weren't standard, Lisp didn't exist yet, and neither Fortran nor Algol supported recursive functions; it made sense at the time.
Ohhhhhh, of course!
Gosh, thanks. I sometimes hold historical technology to unfair standards because I'm not thinking about the continuity of it all.
Crazy to think twenty-somethings are out there hacking COBOL!
Gosh, thanks. I sometimes hold historical technology to unfair standards because I'm not thinking about the continuity of it all.
Crazy to think twenty-somethings are out there hacking COBOL!
> how much power
Do not forget that when COBOL was created mainframes were less powerful than today's microcontrollers.
Do not forget that when COBOL was created mainframes were less powerful than today's microcontrollers.
Recursive and iterative functions have the same computational power.
And every computable function can be expressed in Brainfuck. That doesn't mean that some algorithms are a lot more elegantly expressed when your language supports recursion.
Correct. They are called subroutines in COBOL.
I actually appreciate the fact that COBOL, while verbose, lets me scan the source code and get a general understanding of what it does.
Just did a migration from a mainframe to Java microservices. We were lucky to have subject matter experts on hand so we didn't have to delve too much into the COBOL code. Used JHipster Domain Language Studio to quickly go from a Bachman diagram to an entity domain model.
One quirk was that we were not permitted to use a modern UI; we had to emulate an IBM 3270 screen! The client ran out of money for retraining users so we had to do a lift-and-shift of the UI.
Just did a migration from a mainframe to Java microservices. We were lucky to have subject matter experts on hand so we didn't have to delve too much into the COBOL code. Used JHipster Domain Language Studio to quickly go from a Bachman diagram to an entity domain model.
One quirk was that we were not permitted to use a modern UI; we had to emulate an IBM 3270 screen! The client ran out of money for retraining users so we had to do a lift-and-shift of the UI.
You drive the terminal with one microservice per character, obviously.
I'm a young developer who also happened to work in a bank so I did a lot of Cobol in 2017-2018.
Good points of Cobol:
- No boilerplate
- You could understand the use case just by reading the code
- Never seen such a fast processing of millions of records (this was done with VSAM files)
But the most important and a real eye-opener for me:
- Any developer can easily learn how to program in Cobol. You don't need superstars 10x programmers and ever changing frameworks and paradigms. There were grandmothers working as developers in the bank. I've actually never seen such a diversity in IT (not only age but also gender diversity). And you know what, that made it a real nice place to work
Good points of Cobol:
- No boilerplate
- You could understand the use case just by reading the code
- Never seen such a fast processing of millions of records (this was done with VSAM files)
But the most important and a real eye-opener for me:
- Any developer can easily learn how to program in Cobol. You don't need superstars 10x programmers and ever changing frameworks and paradigms. There were grandmothers working as developers in the bank. I've actually never seen such a diversity in IT (not only age but also gender diversity). And you know what, that made it a real nice place to work
I'm also a young developer that works with COBOL, but I work in the insurance sector. The environment you describe is also how it's like here. And I've never worked with such nice and intelligent people!
One thing I really love about this environment is you learn a lot about the business area when working with COBOL, since the business logic is so plainly written in many programs. I don't like using the term "self-documenting code," but COBOL is really close to that.
One thing I really love about this environment is you learn a lot about the business area when working with COBOL, since the business logic is so plainly written in many programs. I don't like using the term "self-documenting code," but COBOL is really close to that.
Speaking as someone who occasionally gets roped into supporting a COBOL application at a large financial institution, I genuinely don't get the "we must replace it because it's old!" mentality. If it's still the best tool for the job then why move away? Just train people up and build tools to work with it on modern systems, just like Micro Focus and COBOL Cowboys (both mentioned in the OP) are already doing. As an added bonus, you can make a lot a money in the process too.
"The guy who wrote it left and nobody knows what it does" is a poor excuse with a self-documenting language like COBOL. How much sense do you think your tangled mess of Java will make in 50 years?
"The guy who wrote it left and nobody knows what it does" is a poor excuse with a self-documenting language like COBOL. How much sense do you think your tangled mess of Java will make in 50 years?
>"we must replace it because it's old!"
My guess as to where that came from:
1. Tech companies stay relevant by reinventing new markets via new languages / frameworks. 2. New programmers can side step the "rookie" condition by adopting a new language thus leveling the playing field for that language / framework (i.e. everyone is a rookie). Plus whatever is new is hot, and everyone wants to know what's hot. 3. Because of this, few are interested in old languages. I was in college in the 1990s and COBOL was pretty much out as far as anything anyone wanted to learn. It was all Windows.
So based on 1-3, the reason "we must replace it because it's old!" mentality is out of necessity. The older the system / language, the harder it will be to find people to work on it. This has inherent risk. Of course these banking systems have decades of business logic, acquisition logic, and government regulations built into them, rewriting it has it's own massive risk.
My guess as to where that came from:
1. Tech companies stay relevant by reinventing new markets via new languages / frameworks. 2. New programmers can side step the "rookie" condition by adopting a new language thus leveling the playing field for that language / framework (i.e. everyone is a rookie). Plus whatever is new is hot, and everyone wants to know what's hot. 3. Because of this, few are interested in old languages. I was in college in the 1990s and COBOL was pretty much out as far as anything anyone wanted to learn. It was all Windows.
So based on 1-3, the reason "we must replace it because it's old!" mentality is out of necessity. The older the system / language, the harder it will be to find people to work on it. This has inherent risk. Of course these banking systems have decades of business logic, acquisition logic, and government regulations built into them, rewriting it has it's own massive risk.
While I generally agree with the "if it ain't broke" sentiment, you have to perform some pretty wild mental gymnastics to end up calling COBOL the "best tool for the job".
Adoption and ease of learning should always be considered when selecting a tech stack for a solution. COBOL's semantics are so foreign to modern programming languages that it makes the language pretty inaccessible.
Also, COBOL's strength is in the generation of reports, but in the end, it's no more expressive for that purpose than any general-purpose programming language coupled with a nice report generation library.
Adoption and ease of learning should always be considered when selecting a tech stack for a solution. COBOL's semantics are so foreign to modern programming languages that it makes the language pretty inaccessible.
Also, COBOL's strength is in the generation of reports, but in the end, it's no more expressive for that purpose than any general-purpose programming language coupled with a nice report generation library.
>While I generally agree with the "if it ain't broke" sentiment, you have to perform some pretty wild mental gymnastics to end up calling COBOL the "best tool for the job".
Do you? Lack of programmers, aside, it was created and evolved exactly for the kinds of jobs its used in.
Do you? Lack of programmers, aside, it was created and evolved exactly for the kinds of jobs its used in.
It is something of a DSL, as the name suggests (Common Business Oriented Language).
I would also disagree with GP that COBOL's semantics are really very foreign. Variable declarations, assignments, expressions, loops, conditionals, etc. are not that different from other imperative languages. More verbose, certainly, but not foreign.
JCL on the other hand....
I would also disagree with GP that COBOL's semantics are really very foreign. Variable declarations, assignments, expressions, loops, conditionals, etc. are not that different from other imperative languages. More verbose, certainly, but not foreign.
JCL on the other hand....
I think the real problem is that it needs to be maintained and nobody wants to do it. So… just start over in a more fashionable language, I guess.
Something I wonder about all the time is why software has to be so fragile. We always put so much work into maintaining things downstream because things break upstream so often it's frustrating.
Something I wonder about all the time is why software has to be so fragile. We always put so much work into maintaining things downstream because things break upstream so often it's frustrating.
After years of struggle, our IT-department recently managed to conclude the migration of all COBOL applications from machines running on Unisys 2200 to Java EE running on GNU/Linux. As a Java developer working with the latter, the final months were wild. The old COBOL greybeards (some 70+, convinced to stay until migration was finalised) certainly didn't go gently into that good night, literally throwing insults at us, leaving meetings, wishing us bad luck etc. We could never be sure they had given us all information about their stuff, out of spite. I hope I don't finish my working years like they did.
This reads like the tale of a junior dev who doesn't even know what s/he doesn't know, and is full of hubris about how they're "finally getting rid of this old crap" that they don't really understand, don't have the decades of domain insight that are built in to it, and don't respect anyone because of the above.
Just sayin', I wonder what the tale from the other side of the table was in this story.
Just sayin', I wonder what the tale from the other side of the table was in this story.
So, how was your IT department treating them at time time?
As valued employees, pairing with the Java devs on code, attending team lunches and other functions, generally integrated with the teams to which they were passing on their life's work?
Because to be honest I'm struggling to believe they were being treated as equal members of a team if they were behaving like that.
As valued employees, pairing with the Java devs on code, attending team lunches and other functions, generally integrated with the teams to which they were passing on their life's work?
Because to be honest I'm struggling to believe they were being treated as equal members of a team if they were behaving like that.
I think the statement "convinced to stay until migration was finalised" already answers your question. I'm sure there would be some that would have wanted to, and been capable of, picking up a different language, but that is not how companies do things. It's replace with the new, even though a lot of business/application knowledge could be retained otherwise.
I think the (governmental) department treated them alright, and they made good money too. They were not the types that liked to blend with the younger devs, even for a cup of coffee. I approached them two years ago and asked if I could work with them for some time to exchange knowledge, but I only got a one line email response "not interested". It's not unlikely that they were annoyed that the applications they had developed over the years, which they kept pointing out were superior, were being phased out.
I did COBOL for two years out of college. It is the most frustrating and terrible language to work in. We weren't using it on a mainframe we were using it to build GUI apps that run on client machines. I would spend days writing code that would take 20 minutes in c#.There were 10k line files with all global variables and you might think it was just bad design and what not but the team was very disciplined and focused on quality. There are no tests, documentation or Google queries to help you. Your job is to dig in an enormous codebase to understand what it does and that is tough. The developer output compared to a modern language is tiny compared to a Java or .NET developer.
> I would spend days writing code that would take 20 minutes
And then weeks debugging the phantom problems caused by the overuse of global variables that COBOL more or less mandates... I feel your pain, brother.
And then weeks debugging the phantom problems caused by the overuse of global variables that COBOL more or less mandates... I feel your pain, brother.
I know it isn't cool, but I often wonder if anyone will come out with a language that isn't meant to be the next C but the next COBOL, RPG, etc. I wonder if anyone has a LLVM backend for z/Architecture and TIMI.
That’s a problem I’ve occasionally considered working on—modern alternatives with tractable, incremental migration paths away from COBOL/RPG/MUMPS—but I hardly know where to begin.
I’m sure for a lot of these companies, due to the sheer size and often mission-critical nature of these systems, the cost analysis still comes down on the side of keeping the COBOL/&c. systems and just using new tooling around them, like static analysers, integrations with frontend frameworks, ways to interoperate with relational databases, and software emulation of mainframes.
An alternative would be not only difficult to build but hard to sell. There’d probably be a lot of money in it if you had a team with the financial runway, technical skills, and market connections to do it, though.
I’m sure for a lot of these companies, due to the sheer size and often mission-critical nature of these systems, the cost analysis still comes down on the side of keeping the COBOL/&c. systems and just using new tooling around them, like static analysers, integrations with frontend frameworks, ways to interoperate with relational databases, and software emulation of mainframes.
An alternative would be not only difficult to build but hard to sell. There’d probably be a lot of money in it if you had a team with the financial runway, technical skills, and market connections to do it, though.
I've thought about it a bit, and I do wonder if defining a VM and compiling the COBOL/RPG/MUMPS to it first then building the language off that. The languages are pretty straight forward and defining a decent high level VM instruction set would probably help with the not only the conversion but provide some assurance that you didn't miss something important.
There is documentation for the MI instructions, but that generates an OPM program and not an ILE program on IBM i. Sadly the TIMI isn't really documented anywhere - as well as ILE.
I have written an RPG3 interpreter with all the Record Level Access operations working on a noDb/flatfile in C#, but lost the source after replacing a hard disk. I have also tried writing a RPG4+ (only free format) compiler for .NET, but it started getting tricky when starting to write the RLA operations because they relied on a database. I have the code still, but it's ugly so I never released it.
Would be a fun project, for sure. Not enough hours in the day.
I have written an RPG3 interpreter with all the Record Level Access operations working on a noDb/flatfile in C#, but lost the source after replacing a hard disk. I have also tried writing a RPG4+ (only free format) compiler for .NET, but it started getting tricky when starting to write the RLA operations because they relied on a database. I have the code still, but it's ugly so I never released it.
Would be a fun project, for sure. Not enough hours in the day.
It would be a nice surprise to come across an article on COBOL that has anything nice to say, much less informative, about the language. One could start with that it's one of a tiny minority of languages based on decimal arithmetic as opposed to binary. This is kind of handy when dealing with money.
There you go: "The Beauty of the COBOL Programming Language" https://devops.com/the-beauty-of-the-cobol-programming-langu...
The "PIC" syntax for variable declaration is an amazing idea that should be more widely copied.
I'm also a fan of COBOL's use of '.' as a statement terminator instead of ';' like the ALGOL languages.
I'm also a fan of COBOL's use of '.' as a statement terminator instead of ';' like the ALGOL languages.
Perl 6 uses rational arithmetic by default (or by defining typed variables), which covers the money use case well. And, of course, we have SQL's DECIMAL type in most backends.
And Common Lisp, although it’s not necessarily “default”. (/ 2 3) works as expected, but 1.7 is a float (unfortunately), and not a rational 17/100. Shame, really.
Nothing unfortunate about that. When you work with rationals, it's very easy to grow incredibly large denominators, at which point all arithmetic operations slow to a crawl. Floats are fast and predictable, which is why they're used for most calculations in CL and other languages.
Except when you hit denormals or underflow.
Or accidentally lose precision ending up with a wrong result.
If I could get a cent for every money transaction done on floats and incorrectly rounded, I'd be a billionaire.
If I could get a cent for every money transaction done on floats and incorrectly rounded, I'd be a billionaire.
17/10
I wrote the Apple Pay DPAN provisioning message tokenizer at a major financial institution in COBOL. Messages came through the payment network backend (BASE24) and our systems are all mainframes. COBOL will never go away until our major financial institutes are obsolete.
I met with manager to, what I thought was, to discuss the project and I brought up that tokenized PANs were our opportunity to transition off the mainframe and that we missed the boat. It fell of deaf ears because our meeting was actually to discuss how I was being reprimanded for using an SSH connection which the company couldn't perform a MITM attack on. It was at that point I knew I could not advance my career there.
I met with manager to, what I thought was, to discuss the project and I brought up that tokenized PANs were our opportunity to transition off the mainframe and that we missed the boat. It fell of deaf ears because our meeting was actually to discuss how I was being reprimanded for using an SSH connection which the company couldn't perform a MITM attack on. It was at that point I knew I could not advance my career there.
You got reprimanded because the company wanted to perform a MITM attack on people? (sorry I got confused on the last line and wanted to be sure)
It sounds like they were having trouble doing their job because their corporate IT decided it was more important to intercept all TLS/SSL traffic on the corporate network than to allow software developers to do their job securely.
They weren't MITM attacking people outside the company, just MITM attacking their own employees.
I feel that pain, quite often (and am slowly losing a war on it at my current employer, sigh). TLS/SSL Interception Proxies are scum that make the internet overall less secure for a weird sense of security by corporate IT departments.
As a software developer, it's my job to make sure that no one is MITM attacking me so that the code I download to incorporate into projects is safe and secure. I can't check if a bad actor is MITM attacking me when my own employer is MITM attacking me.
They weren't MITM attacking people outside the company, just MITM attacking their own employees.
I feel that pain, quite often (and am slowly losing a war on it at my current employer, sigh). TLS/SSL Interception Proxies are scum that make the internet overall less secure for a weird sense of security by corporate IT departments.
As a software developer, it's my job to make sure that no one is MITM attacking me so that the code I download to incorporate into projects is safe and secure. I can't check if a bad actor is MITM attacking me when my own employer is MITM attacking me.
> "It sounds like they were having trouble doing their job because their corporate IT decided it was more important to intercept all TLS/SSL traffic on the corporate network than to allow software developers to do their job securely."
Right, that was what I thought too, this is honestly why I'm turned off from applying to work with more bureaucratic companies (soon to be fresh graduate), I understand the reason for sensitive informations being leaked. But this seriously causes a lot of productivity loss...
I've interned with a small company that needs to SSL into government/companies servers to do work. (I don't do them, just on local company machine for testing etc. Also maybe why they can't let me do live site related stuffs) It'll be a big pain to not be able to SSL remotely and do work.
Right, that was what I thought too, this is honestly why I'm turned off from applying to work with more bureaucratic companies (soon to be fresh graduate), I understand the reason for sensitive informations being leaked. But this seriously causes a lot of productivity loss...
I've interned with a small company that needs to SSL into government/companies servers to do work. (I don't do them, just on local company machine for testing etc. Also maybe why they can't let me do live site related stuffs) It'll be a big pain to not be able to SSL remotely and do work.
In large organizations for compliance purposes it is commonplace for the company to MITM all network traffic internally. This ensures that information which is restricted from leaving particular systems or the company doesn't get exfiltrated. It's kind of a braindead practice, but it's what happened in the early days of SSL being disgusting and now that things are nicer we're stuck with it.
We shouldn't be stuck with it. In a large organization they should already have control of the endpoints. They can absolutely get every domain/VPN-joined machine to directly tattle on user traffic without intercepting anything. It's just that Microsoft's tools (or Red Hat's or Apple's) for that are less sexy to IT people and have less interesting names and hardware purchases involved than things like "Electric Eel Secure Firewall" and "NetShark 3000".
It's the Corporate IT equivalent of the security theater that still gets consumers to buy Norton/McAfee/etc products when Windows Defender and Windows Firewall are more than adequate, free, built-in, but "too quiet" and not enough slot-machine like glowing green "Safe" spinners.
It's the Corporate IT equivalent of the security theater that still gets consumers to buy Norton/McAfee/etc products when Windows Defender and Windows Firewall are more than adequate, free, built-in, but "too quiet" and not enough slot-machine like glowing green "Safe" spinners.
It would guess it wanted to be able to snoop on connections that its developers were making to its production systems. Unusual, but not entirely unreasonable.
I have an uncle who's about to retire after a career as a cobol dev. He tells me that he can teach me the language in two days, show me around the legacy systems of [big company you know] in two months, and then I could have a safe and lucrative career until I retire, too.
I wish he was interested in writing a blog post of war stories.
I wish he was interested in writing a blog post of war stories.
COBOL is easy to learn if you already know how to program. What's a bit harder is learning the mainframe environment it's deployed in. It's not like Unix or DOS at all.
Yes, this exactly. Whenever I tell people I'm a mainframe developer, they always ask how they can learn COBOL. Oh, that's the easy part. The environment is very different and takes a while to get used to, but it's where COBOL thrives.
Today, Commonwealth Bank of Australia (as mentioned in the article) has indeed successfully migrated to SAP Core Banking.
Westpac is in a similar transformation to Oracle Core Banking.
Some European banks, eg Nordea, are slowly moving to Temenos T24, a Swiss java based core banking system.
Danske Bank built their own. It was expensive and, afaik, still has issues.
Temenos T24 core banking software is based on something even older than COBOL called MultiValue. This is a “pre-relational” database (now unironically rebranded “post-relational/NoSQL”). I hear Temenos also has an innovation App Store is putting COBOL on the block chain...
SAP business logic is written in ABAP, a descendant of COBOL.
Oracle Core Banking was originally I-Flex, which was spun out of a Citibank internal IT organization in India - dating back to the 1980s. There’s got to be some COBOL in there somewhere, though they are also committed to making Java the next COBOL.
SAP business logic is written in ABAP, a descendant of COBOL.
Oracle Core Banking was originally I-Flex, which was spun out of a Citibank internal IT organization in India - dating back to the 1980s. There’s got to be some COBOL in there somewhere, though they are also committed to making Java the next COBOL.
You're working in a Pick database? If you're ever in Boston, I owe you a drink.
If I had to bet, I would bet that COBOL code will be around longer than either Oracle or SAP. The companies migrating to Oracle or SAP may be doing the proverbial "jumping from the frying pan into the fire".
I have a friend in NYC who makes a VERY nice living maintaining COBOL on mainframes. It's a niche market, so very few guys around who not only can read and write COBOL but also work on the mainframe.
I pretty much do what he does except with xbase (dbase, foxbase/pro and clipper) on PC's. There are millions of lines of code written in the 90's still happily running.
In fact, the only "tech" I see from the 90's that's pretty much dead and buried is Netware and Vines.
Damn shame too, cause I loved Netware. Ol'well. :)
We're both old farts, compared to most of you guys. He's 64 and I'm 55.
I pretty much do what he does except with xbase (dbase, foxbase/pro and clipper) on PC's. There are millions of lines of code written in the 90's still happily running.
In fact, the only "tech" I see from the 90's that's pretty much dead and buried is Netware and Vines.
Damn shame too, cause I loved Netware. Ol'well. :)
We're both old farts, compared to most of you guys. He's 64 and I'm 55.
Nice. I'm almost 52 and still work on the FoxPro application I started working on in 1987, which was originally in dBase II, then moved to FoxBase+, then to FP DOS and now VFP. Now, 32 years later, it's finally being phased out - to move our data into an application written in RPG :-).
I remember when MS brought out Fox. I was in Toledo at Fox's annual dev's conference (they were based in Toledo). I remember making a bet between a bunch of us [Fox dev's) how long it would take for MS to drop FP. I lost. Was off by a few years.
But I do remember MS pushing Access (which was and probably still is utter trash, compared to FP). And then VB6. I hate VB. I have nothing against the language itself. I'm just still bitter at MS replacing FP with VB.
I am involved in a project that is replacing FP with Python. Now Python I like a lot.
But I do remember MS pushing Access (which was and probably still is utter trash, compared to FP). And then VB6. I hate VB. I have nothing against the language itself. I'm just still bitter at MS replacing FP with VB.
I am involved in a project that is replacing FP with Python. Now Python I like a lot.
I never made it to any of the developer conferences, but I remember the mood on the Fox forum on Compu$erve being very grim when the announcement was made. People joked about jumping out of windows...
I'm no fan of Access or VB, either. I do everything outside the main application in Python, too.
I'm no fan of Access or VB, either. I do everything outside the main application in Python, too.
Are there open source core banking software out there?
Why would there be? In that kind of environment the software is the business.
> billions more being written each year for maintenance and new features
This is funny to me, because the where I'm working right now, they have teams building entirely new projects in COBOL. The reason is that it's a company with a very high average age and incredible secondary benefits for baby boomers (old contracts, young people get ripped off), so they have an army of COBOL developers while there's a shortage for pretty much every other type of dev.
This is funny to me, because the where I'm working right now, they have teams building entirely new projects in COBOL. The reason is that it's a company with a very high average age and incredible secondary benefits for baby boomers (old contracts, young people get ripped off), so they have an army of COBOL developers while there's a shortage for pretty much every other type of dev.
Yeah, but what will they do in 10-15 years? Those people aren’t immortal and newcomers will have to be:
* persuaded to come: tough sell for Cobol
* 99% internally trained cause the pool of Cobol devs is probably similar to that of Elm devs :)
* persuaded to come: tough sell for Cobol
* 99% internally trained cause the pool of Cobol devs is probably similar to that of Elm devs :)
This problem is solvable by basic market dynamics. When everyone knows that a JavaScript "Dev" can make $80k and a cobol one can make $190k, people with learn cobol. It isn't hard. If you can grasp one imperative language, you can grasp any of them.
True, but if the Cobol market is for 10k developers worldwide, not many people will venture there, even for higher pay. Cause if you get fired from your Cobol job and there’s no openings for Cobol devs, your market value just plummeted to $40k as a Junior Javascript dev ;)
And despite what we may think, except for the big tech companies, everyone else doesn’t really hire generalists. You could have 20 years experience as a programmer in 10 different languages, HR still wants a Java programmer with 5 years of Java experience.
And despite what we may think, except for the big tech companies, everyone else doesn’t really hire generalists. You could have 20 years experience as a programmer in 10 different languages, HR still wants a Java programmer with 5 years of Java experience.
Fuck it, I am sick of the churn associated with modern development. Cobol sounds quite appealing right now.
There's no churn, it's great. And there's plenty to learn once you get in, depending on where you go. COBOL requires knowing a good bit about the business itself, so it's hard to get bored with it. At least, I haven't yet and I've been at it for a whopping 2 years.
You could also become an embedded dev. Write software for cars or planes, or train, or nuclear power plants. If you want you can work on the same piece of software using the same tooling for your whole career.
Whats the language of choice for that? C or would Rust be worth learning? Any pointers for how to get started in that field?
(heh pointers)
I was in ECE in college (graduated in 2017) but do full stack software engineering for a bank now. AFAIK it's still C, but I wouldn't be surprised if Rust picked up due to the emphasis on memory safety- dynamic memory allocation and recursion are usually avoided in embedded.
Some of the lessons I got from embedded have carried over to my place of work- I found a repo that used floating point for money and immediately knew why that was a bad idea, because my embedded systems professor had spent an almost an entire lesson explaining why you don't use floating point for money or time.
side note: Said professor (Phil Koopman) was an expert witness in the Toyota unexpected acceleration lawsuit, he has a talk on it that can be found at https://betterembsw.blogspot.com/2014/09/a-case-study-of-toy....
I was in ECE in college (graduated in 2017) but do full stack software engineering for a bank now. AFAIK it's still C, but I wouldn't be surprised if Rust picked up due to the emphasis on memory safety- dynamic memory allocation and recursion are usually avoided in embedded.
Some of the lessons I got from embedded have carried over to my place of work- I found a repo that used floating point for money and immediately knew why that was a bad idea, because my embedded systems professor had spent an almost an entire lesson explaining why you don't use floating point for money or time.
side note: Said professor (Phil Koopman) was an expert witness in the Toyota unexpected acceleration lawsuit, he has a talk on it that can be found at https://betterembsw.blogspot.com/2014/09/a-case-study-of-toy....
It isn't about the language but about the physics process you are controlling. To write software to fly a plane you need to understand how the plane works, same for power plants, saw mills, assembly lines, refineries, pipelines, etc.
Choose the process you want to control and then go work at a place that has that process or a consultant that supplies equipment or services to the owner/operator of the plant. Then you will learn how the process operates and how the software controlling it works, and how it could be improved.
Choose the process you want to control and then go work at a place that has that process or a consultant that supplies equipment or services to the owner/operator of the plant. Then you will learn how the process operates and how the software controlling it works, and how it could be improved.
It's C using compilers from the early 90s. Some shops use C++, again with ancient compilers. There are also some Ada positions.
I feel the same and started working on an mainframe assembly codebase a couple of months ago. I'm very happy.
Is it really better if we replace x million lines of COBOL with x million lines of java or c++? What is the financial language of the future that is easy to write and reduces errors?
It would actually be better if we replaced x million lines of COBOL with x million lines of COBOL. For many reasons:
1. it would run on a modern environment instead of a weird mainframe OS using a weird database
2. it would use modern coding conventions such as local variables and control structures instead of goto
3. it wouldn't be x million lines after you remove all the dead and duplicate code. These are codebases have been developed for 3 decades with the principle "we don't know how any of this old shit works, don't touch anything you don't need to"
But yes, you would also get a lot of advantages from porting everything to a modern programming language with good tooling.
1. it would run on a modern environment instead of a weird mainframe OS using a weird database
2. it would use modern coding conventions such as local variables and control structures instead of goto
3. it wouldn't be x million lines after you remove all the dead and duplicate code. These are codebases have been developed for 3 decades with the principle "we don't know how any of this old shit works, don't touch anything you don't need to"
But yes, you would also get a lot of advantages from porting everything to a modern programming language with good tooling.
I agree with you somewhat there; you mean refactor instead of rewrite and yes, I believe that is a better choice. But the problem is not language related; Joel Spolsky said it with far smaller and more modern codebases, but, as you even indicate within #3, 100000s of changes were done in the code over 30 years by people who did not understand the full system or, often, did not even understand the local parts they are editing fully. A lot of changes in legacy code, but let's not kid ourselves, also in modern code, depend on 'things' the programmer deemed right at that moment. Then after testing (even testing in practice with people's money), now after unittests (or in practice, with people's money), too much of the business logic/functionality depends on bad code. Code that is off-by-one that isn't discovered for decades or at all is not unheard of for instance because that routine is only triggered for a specific insurance policy only 100 people have and for those 100 the bug actually gives back the right answer. It would require deep understanding of all the corner cases and that's why it's often just not rewritten.
We were working, around 2000, on partially porting a Cobol+Fortran insurance system (which was an 'integration' of systems acquired by acquisition over the years) to Java (yes, EJBs..... ..... ..... the sins of my youth...). The work was mostly 20 people working for months on creating all the encoded rules into spreadsheets and, in a much shorter time, us translating those to Java. This particular piece was done because the company wanted to webify that part of the system. I am not sure if the modern versions of 'software mainframes' or modern hardware mainframes would be fast enough to handle web with the old code running?
We were working, around 2000, on partially porting a Cobol+Fortran insurance system (which was an 'integration' of systems acquired by acquisition over the years) to Java (yes, EJBs..... ..... ..... the sins of my youth...). The work was mostly 20 people working for months on creating all the encoded rules into spreadsheets and, in a much shorter time, us translating those to Java. This particular piece was done because the company wanted to webify that part of the system. I am not sure if the modern versions of 'software mainframes' or modern hardware mainframes would be fast enough to handle web with the old code running?
The thing about most old COBOL is that there is very little shared code. There are things called "copybooks" which are snippets that get copied into your program at compile time, but they are not "shared" code. So you have much less chance of affecting anything else when you change a COBOL program. Most are written to perform a single transaction or generate a single report or screen, and are entirely self-contained.
There are modern environments for COBOL, it has even been updated to OO and such.
http://www.fujitsu.com/global/products/software/developer-to...
https://www.microfocus.com/products/visual-cobol
http://www.fujitsu.com/global/products/software/developer-to...
https://www.microfocus.com/products/visual-cobol
The only real advantage is that most people have no COBOL experience, but many have Java or C++ experience. And of course, it _isn't_ better for the business mentioned in the article, because they haven't done it yet.
COBOL is easy enough to pick up for a seasoned Java developer in a week.
The banking processes and environment are not though.
The banking processes and environment are not though.
Your second question is what I would really like answered.
Maybe the x is an order of magnitude smaller or more. I don't truly know, but whenever I see COBOL code it's verbose.
It is a problem to have x million lines of COBOL that no one can support, or even wants to learn to support for less than 200k.
Anyone have thoughts on how to go about learning mainframe programming and COBOL? Honestly seems like a useful skill given its existence everywhere but I don't think very many engineers (myself included) know where to start in learning it.
A number of people, I think in the "COBOL Cowboys" discussion, on HN have pointed out that it's not learning COBOL that's the issue. The language is the easy part. The real problem is learning the mainframe systems and concepts, and especially gaining meaningful experience with them. Emulators are available in some cases but back in the day all this stuff was proprietary, and doesn't follow the familar UNIX-a-like mould of many modern OSes. (It goes without saying they're nothing like Windows, either.)
EDIT: I think this is the COBOL Covboys discussion I referred to above: https://news.ycombinator.com/item?id=14083214
EDIT: I think this is the COBOL Covboys discussion I referred to above: https://news.ycombinator.com/item?id=14083214
There's an emulator called Hercules that can run z/OS, OS/390, or MVS. The hard part is getting a copy of a recent version of the OS. Luckily, z/OS takes backwards compatibility very seriously so an older version won't be THAT different from a newer one for a beginner.
A lot of the big mainframe software companies like CA Technologies, Rocket Software, or BMC hire people with no mainframe experience (often straight out of college) and then train them.
If you're willing to pay for it, IBM offers classes in Dallas, TX for beginners as well. They are not cheap.
Marist College (located in New York, I think) also offers some z/OS certificates and classes. Unfortunately, I don't think they are online. I could be wrong about that though. http://idcp.marist.edu/enterprisesystemseducation/zosprogram...
A lot of the big mainframe software companies like CA Technologies, Rocket Software, or BMC hire people with no mainframe experience (often straight out of college) and then train them.
If you're willing to pay for it, IBM offers classes in Dallas, TX for beginners as well. They are not cheap.
Marist College (located in New York, I think) also offers some z/OS certificates and classes. Unfortunately, I don't think they are online. I could be wrong about that though. http://idcp.marist.edu/enterprisesystemseducation/zosprogram...
Yes. I agree with this.
Having command line and interactive terminal experience and actually programming your environment the more fundamental skill to have on mainframes.
I don't know -- It's been decades since I wrote any COBOL, and at the time I was pretty fresh out of a unix-centric undergrad environment. I was at home in emacs and the shell command line and familiar with unix utilities, but the mainframe was just another planet entirely. None of that experience really translated.
I've actually programmed in COBOL and fundamentally the problem is all this technology is OLD. Crazy OLD. COBOL has more in common with old-school line numbered BASIC than it does almost any other technology.
It will literally take you months to do something in COBOL on the mainframe that would normally take you a week in anything else. Trust me, you take for granted all the conveniences of modern programming environments. COBOL is very much a product of it's time and it's time was decades ago. The success of these old environments rests entirely on extremely well defined (and tedious) processes, not the technology.
No matter how much they pay you, you probably still won't want to do it -- it's just not intellectually stimulating enough and you will constantly be frustrated.
It will literally take you months to do something in COBOL on the mainframe that would normally take you a week in anything else. Trust me, you take for granted all the conveniences of modern programming environments. COBOL is very much a product of it's time and it's time was decades ago. The success of these old environments rests entirely on extremely well defined (and tedious) processes, not the technology.
No matter how much they pay you, you probably still won't want to do it -- it's just not intellectually stimulating enough and you will constantly be frustrated.
>It will literally take you months to do something in COBOL on the mainframe that would normally take you a week in COBOL on anything else.
Fixed that for you.
Fixed that for you.
I disagree. COBOL itself as about as expressive as BASIC and twice as ugly.
The environment is also terrible but separating COBOL from the environment is pointless.
The environment is also terrible but separating COBOL from the environment is pointless.
Is code generation too difficult for COBOL? You'd expect some more modern tools for abstraction and interoperability or something…
Every time one of these articles comes up I check out the salaries these places offer for COBOL work and it's just not competitive. Clearly they have a plenty big talent pool to meet demand. So it doesn't seem worth it to me unless you really want to work in banking.
What's not mentioned is that there is a large outsourced population of COBOL devs. Talking with a former colleague who did COBOL for years, he can't find anything in COBOL that pays well, so he's staying at my last company doing VB.net and batch processing for their ERP system
Start by installing and running the tk4 MVS distribution. There are lots of youtube videos about it. Watch everything you can find in video about mainframes. Read a lot of IBM docs. Start by the ABC's of Z/OS Programming or some older equivalent, since you won't be running the newest system on the emulators anyway.
Maybe you could mostly learn it on the job if they thought you had interest? I actually had an internship in COBOL with zero prior experience. They were hoping to convince some of us kids to give it a shot. In my experience it wasn't hard at all, but I'm not really sure what level I was operating at.
COBOL code base is pale in comparison to modern systems, and mostly self-contained. The number of critical legacy systems written in ancient languages nobody supports anymore is going to increase, and given the reliance on third-party code (libraries, compilers, frameworks, tools etc) the problem will be much more prominent in several decades from now, when all current programmers retire and the institutional memory should kick in.
> The number of critical legacy systems written in ancient languages nobody supports anymore is going to increase, and given the reliance on third-party code (libraries, compilers, frameworks, tools etc) the problem will be much more prominent in several decades from now
You're talking about Javascript?
You're talking about Javascript?
AFAIK Javascript is not used for critical systems which will be in service for decades. Besides James Webb Space Telescope, of course.
I don't know if you are serious, but regardless of that, the James Webb space telescope will stay near the L2 Lagrange point. This is not a stable orbit, and left to its own, the spacecraft will drift away from the desired orbit. That means it needs thrusters to keep itself in place, and it will bring enough fuel for about 10 years of operations. After that it will slowly drift out of L2. Given the distance from earth, there is also no way there ever will be any service missions that the Hubble space telescope relied upon.
So no, James Webb space telescope won't be in operation for decades.
So no, James Webb space telescope won't be in operation for decades.
It was mostly a snark. Yes, you're absolutely right, JWST service life is propellant-limited, not to mention its limited liquid helium supply for the first phase of the mission. And they are not using pure ECMAScript either, it's a heavily customized version.
I tried to search for it, but the "enable JS" is an effective smokescreen. Please be kidding... it's such a random ref I'm genuinely expecting that you are serious.
He's totally serious. [0]
[0] Balzano, V. and Zak, D., “Event-driven James Webb Space Telescope Operations using on-board JavaScripts”, SPIE Conference Proceedings, Vol. 6274, 2006.
[0] Balzano, V. and Zak, D., “Event-driven James Webb Space Telescope Operations using on-board JavaScripts”, SPIE Conference Proceedings, Vol. 6274, 2006.
I have been waiting for high paid Perl maintenance jobs to come up, as I did it for 7 or 8 years. At present I will get better paid for my Python and Django knowledge.
>The language ostensibly self-documents, because it’s so verbose and requires so many explicit declarations about what it’s doing
You know, I just finished a COBOL class at university and this makes sense. One of the main things I hated about cobol was how strict and weird the syntax was. It uses so many full verb identifiers rather than just operands. The language just really feels like it was built to be rock solid.
You know, I just finished a COBOL class at university and this makes sense. One of the main things I hated about cobol was how strict and weird the syntax was. It uses so many full verb identifiers rather than just operands. The language just really feels like it was built to be rock solid.
Few people want to program in COBOL; but businesses still depend on running COBOL code. Reminds me of another language: JavaScript.
The developers who didn't want to code in JavaScript, solved the problem of having to deploy JavaScript by creating other languages that compiled to JavaScript: CoffeeScript, TypeScript, Elm, ClojureScript, etc. And, more recently, by just turning the JavaScript interpreter into a glorified low-level VM, through WASM, so that it can be programmed in any language.
Why hasn't this approach been taken with COBOL?
With such a language in hand, you could take existing codebases (or compiled binaries) and write a decompiler that would convert them to your language of choice, so that the whole project could exist in the new form. Or, more simply, you could just write new modules (and rewrite any modules you have to change) in the new language, leave old modules as COBOL, and then link them together.
The developers who didn't want to code in JavaScript, solved the problem of having to deploy JavaScript by creating other languages that compiled to JavaScript: CoffeeScript, TypeScript, Elm, ClojureScript, etc. And, more recently, by just turning the JavaScript interpreter into a glorified low-level VM, through WASM, so that it can be programmed in any language.
Why hasn't this approach been taken with COBOL?
With such a language in hand, you could take existing codebases (or compiled binaries) and write a decompiler that would convert them to your language of choice, so that the whole project could exist in the new form. Or, more simply, you could just write new modules (and rewrite any modules you have to change) in the new language, leave old modules as COBOL, and then link them together.
This is timely given the terrible problems the TSB bank is having after failing to properly transition from a legacy COBAL system
http://www.bbc.com/news/business-43948889
You mean, transition from a fully working COBOL system that their former parent company is happily using, to a modern one that shows NullPointerException to the end user?
> happily using
Not sure you can say they are 'happily' using the agglomeration of bolt on systems that they have pulled in over the years.
There's remnants of Cheltenham and Gloucester, Halifax, Bank of Scotland, TSB (now spun out), Scottish Widows, Standard Chartered Bank (IIRC) and I think some parts of Abbey National.
Those are just the one I remember and some of those are comprised of a mish mash of prior systems.
Keeping all that going is likely a huge burden. Indeed, they charged TSB £100 million a year just to emulate TSB's part of the system so TSB could just keep using that until their subsequent merger.
Not sure you can say they are 'happily' using the agglomeration of bolt on systems that they have pulled in over the years.
There's remnants of Cheltenham and Gloucester, Halifax, Bank of Scotland, TSB (now spun out), Scottish Widows, Standard Chartered Bank (IIRC) and I think some parts of Abbey National.
Those are just the one I remember and some of those are comprised of a mish mash of prior systems.
Keeping all that going is likely a huge burden. Indeed, they charged TSB £100 million a year just to emulate TSB's part of the system so TSB could just keep using that until their subsequent merger.
Lloyd’s is up, TSB is still down AFAIK. They’re happy alright...
Santander bought Abbey National. Did some of it end up in TSB somehow?
I just looked it up - I got confused as it was Abbey Life not Abbey National.
> He also noted that billions of dollars would likely be needed to implement this kind of migration across multiple agencies.
> You can’t just rewrite the whole thing.
Is it that bad? I guess I'm being crazy thinking I can do it single handedly in 5-10 years for a couple million.
> You can’t just rewrite the whole thing.
Is it that bad? I guess I'm being crazy thinking I can do it single handedly in 5-10 years for a couple million.
> I can do it single handedly
For every 1 programmer working on a Cobol system who would and could rewrite it, there's another 3 who actively resist rewrites to keep their jobs and put bugs in the system to generate overtime-paying after-hours callouts. There's yet another 6 programmers who don't have the aptitude to program but who somehow managed to get into their job and are just productive enough to avoid being terminated. And perhaps they bring one of their kids to work for the day every now and then.
You don't get to do a Cobol rewrite single-handedly when there's 9 others on the team working against it happening.
For every 1 programmer working on a Cobol system who would and could rewrite it, there's another 3 who actively resist rewrites to keep their jobs and put bugs in the system to generate overtime-paying after-hours callouts. There's yet another 6 programmers who don't have the aptitude to program but who somehow managed to get into their job and are just productive enough to avoid being terminated. And perhaps they bring one of their kids to work for the day every now and then.
You don't get to do a Cobol rewrite single-handedly when there's 9 others on the team working against it happening.
I agree.
But that also means the major roadblocks are sociopolitical and not technical (not saying technical challenge is not there, just that it's not the biggest issue).
But that also means the major roadblocks are sociopolitical and not technical (not saying technical challenge is not there, just that it's not the biggest issue).
You have no idea. That code is "it does what it does" - no docs, no specs, no tests. Over the decades, "correct is what the procedure does", because 1. it works in most cases 2. nobody remembers why it was written that way 30 yrs ago, but there must be a reason somewhere.
It's not a job for the faint of heart.
But it runs, and it shows stuff on screen, and it saves stuff in the hard-drive!
I'm not saying I'll do things the conventional way. Once you give up the conventional way, it becomes a different ball-game.
I'm not saying I'll do things the conventional way. Once you give up the conventional way, it becomes a different ball-game.
> and it shows stuff on screen...
And it has complex, undocumented connections to north of a hundred other systems. Screwing up any one of which could have hugely impactful effects on the business (or not, who knows?). So you're going to be coordinating testing with 30-40 teams in diverse parts of the organisation (and externally).
And your couple of million won't pay for the redesign of all those feeds. Hopefully they won't take the testing costs out either or you'll be broke in 2 years.
See, the thing with extracting these old, large systems isn't really the language they're written in, or the hardware they run on. Though those are nasty, ugly problems. It's the coupling. What will almost always defeat you, unless you give the problem the respect it deserves (and often even then) is the coupling.
And it has complex, undocumented connections to north of a hundred other systems. Screwing up any one of which could have hugely impactful effects on the business (or not, who knows?). So you're going to be coordinating testing with 30-40 teams in diverse parts of the organisation (and externally).
And your couple of million won't pay for the redesign of all those feeds. Hopefully they won't take the testing costs out either or you'll be broke in 2 years.
See, the thing with extracting these old, large systems isn't really the language they're written in, or the hardware they run on. Though those are nasty, ugly problems. It's the coupling. What will almost always defeat you, unless you give the problem the respect it deserves (and often even then) is the coupling.
I hadn't thought of coupling, the distributed nature, so you have a point. However we can think of splitting up the system into pieces, and try to localize the update. For example, for a worldwide distributed system keep everything else the same but replace this one mainframe with modern hardware and code so that the rest of the system doesn't get effected. And so one.
As for the couple million, that's for me :) But I guess if you factor in cost of supporting hardware/software/infrastructure, it's really past 5 million (maybe 10 million), just as an estimate.
To elaborate on my 'unconventional way', I'm talking about using all of:
- complete view of the source code,
- runtime behavior on the screen (even recorded with cameras, or even better, display debug hooks)
- runtime storage logging,
- runtime network logging,
- modern inference methods beyond parsing (semantic inference, logic programming, maybe even some statistical analysis).
- But most importantly, automation-first approach (no, we're not doing things by hand. 'The Machine TM' will do the work for us). E.g., I won't be reading the COBOL code line by line. The code, plus the runtime behavior, would be the input to the inference engine, the output would be 'explanations, documentation, etc'.
- and so on
It would be a very challenging project, hence the 5-10 year timeframe. But I'm not convinced it's intractable. And I'm not convinced the cost is in the billions.
As for the couple million, that's for me :) But I guess if you factor in cost of supporting hardware/software/infrastructure, it's really past 5 million (maybe 10 million), just as an estimate.
To elaborate on my 'unconventional way', I'm talking about using all of:
- complete view of the source code,
- runtime behavior on the screen (even recorded with cameras, or even better, display debug hooks)
- runtime storage logging,
- runtime network logging,
- modern inference methods beyond parsing (semantic inference, logic programming, maybe even some statistical analysis).
- But most importantly, automation-first approach (no, we're not doing things by hand. 'The Machine TM' will do the work for us). E.g., I won't be reading the COBOL code line by line. The code, plus the runtime behavior, would be the input to the inference engine, the output would be 'explanations, documentation, etc'.
- and so on
It would be a very challenging project, hence the 5-10 year timeframe. But I'm not convinced it's intractable. And I'm not convinced the cost is in the billions.
Yeah, but how will you figure out the business logic? That comes from regulation, business requirements from 20 years ago, etc. It’s archaeology.
See my response [1] to the other comment.
[1] https://news.ycombinator.com/item?id=16968935
[1] https://news.ycombinator.com/item?id=16968935
This is kind of my thinking too. I would think that you could just boil down the requirements for what the system needs to do and just build that rather than bothering to wade through the COBOL and translating it. I would also think the resulting code would be far smaller than the legacy COBOL, probably by an order of magnitude or more.
Bear in mind that the COBOL system isn't a static target - it will be constantly added to in that 5-10 years.
If COBOL is really as self-documenting as everyone seems to claim, why is it not possible to translate it to some other language and then use that version going forward?
It is possible. I did it early in my career, fresh out of college. It wasn't hard, just tedious.
I think (total speculation) that the root cause of failure in these projects is due to mismanagement and (maybe) the kinds of people who are pulled into the projects. To the latter point, it's really hard to attract great developer talent into such a project, same goes for medical systems and government contracting. There's better money, and way better work environments in other sectors. (Just my 2 cents.)
I think (total speculation) that the root cause of failure in these projects is due to mismanagement and (maybe) the kinds of people who are pulled into the projects. To the latter point, it's really hard to attract great developer talent into such a project, same goes for medical systems and government contracting. There's better money, and way better work environments in other sectors. (Just my 2 cents.)
The puzzle is, when and how will this state of affairs (running legacy technology) change. Is it because C-suite movers and shakers doesn't have skills to bring about change? Or is it that things we take as trusted and agile modern systems and methodologies discussed here in HN happen to be things that the market at large will not bet on for a forseeable future.
Replacement projects for big legacy technology stacks have a track record of costing huge amounts and then not delivering. So keeping them running for as long as possible can be perfectly rational.
I took two semesters of mainframe classes (COBOL, JCL, DB2, etc) as electives, in 2015-16. I wouldn't want to do that full time (though the jobs are there and it's an applicant's market), but it was a great experience.
So much different than all my other CS classes, and gave insight into an important part of IT that isn't really taught anymore.
So much different than all my other CS classes, and gave insight into an important part of IT that isn't really taught anymore.
Neat article. I am quite old but never touched COBOL (they used Java to teach in Uni). There are so many articles about the failures of transitioning on legacy system to a modern one. Like that British bank going over to a Spanish one (TSB?). Does anyone know of success stories? What were their techniques/strategies?
When I hear about the COBOL line count it always makes me think that someone should write a program that eats COBOL as input and spits out Java/C++/LangDuJour as output. Might make a good company. Mind you, it may already exist, or, be impossible because of some aspect of the COBOL language I don't understand.
When I hear about the COBOL line count it always makes me think that someone should write a program that eats COBOL as input and spits out Java/C++/LangDuJour as output. Might make a good company. Mind you, it may already exist, or, be impossible because of some aspect of the COBOL language I don't understand.
Microfocus has a cobol to jvm transpiler.
Issue is that cobol often relies on intricacies of specific mainframes or cobol implementations so it's never quite that simple.
Also a lot of cobol directly interfaces with databases with side effects which makes it ever harder.
Issue is that cobol often relies on intricacies of specific mainframes or cobol implementations so it's never quite that simple.
Also a lot of cobol directly interfaces with databases with side effects which makes it ever harder.
Micro Focus is an interesting company. And apparently very profitable. From a smallish company making tools for mainframe development and consultancy to now owning HP Enterprise and a whole bunch of other companies as well. They're raking it in money wise.
never mind: https://en.wikipedia.org/wiki/GnuCOBOL
And worth noting the real pressure comes about when you move to real time payments. COBOL / mainframes are batch transaction processing systems and generally struggle with real time / event based transactions.
That's what CICS is for, and has been around for quite some time https://en.wikipedia.org/wiki/CICS
I'd take a guess that the recent problems with the TSB migration are down to something like this. (Google it if you haven't heard). They tried to replace lots of ancient systems with a big new one and ... it didn't work.
Root cause on something like this is problematic: management instituted a hard deadline despite signs of serious problems early on, and there seems to have been some monkey patching being applied to live systems as they try to get it working. But a big factor has got to be the huge problem of figuring out what all those old legacy systems actually do.
Root cause on something like this is problematic: management instituted a hard deadline despite signs of serious problems early on, and there seems to have been some monkey patching being applied to live systems as they try to get it working. But a big factor has got to be the huge problem of figuring out what all those old legacy systems actually do.
My company has plenty of Cobol. While I am not on their part of IT, I used to work together with them for integration. I left with very mixed feelings.
Some bad sidess * The language is old, in a bad way. Reading cobol learns you pretty fast why todays practices are better than the multi million spaghetti monster of the past. * IT practices are old. They havent yet embraced lower case. I trieds to tell one of them about UTF-8, but the whole idea that 1 char=1 byte might not be an universal truth was so far out she immediately rejected me as insane. * IT tooling is unique. These guys did CI/CD in the 80ies, but did it with a whole custom stack. They wrote their own source code control, and added an engine wih auto compiles checked in code, rejects code not according to the very strict rules, does some testing, and manages promotion from dev to test to preprod to prod. * The database consists of 12 files (we would call them tables). Each of them has exactly 1 index. You either do a full read or an indexed lookup. There are no more files left, they are used up. Quite a lot of nightly batches exist for looking up data not reachable by the index by doing a full read for each record. See it as a kind of manual join. * Security practices are old. There is no isolation, every application has full access to everything (There is 1 mainframe shared between user data, HR data, payment systems, ...) . If an application crashes, it dumps core. This is considered a feature, as the user can restart without much trouble. The idea that a dump might indicate some kind of exploitable problem is incomprehensible, so it is a continuous fight to keep these guys from connecting cobol straight to the internet.
But even if the technology side is horrible, they provide a lot of business value, especially compared to modern oracle/sap/tata/... 'enterprise class' applications: * The terminal application is quick, even if the learning curve is horrible. You just type as fast as you can. If cobol cant follow, you'll see a pause on the screen, but don't let that slow you down, the mainframe will catch up. * There is no sexism here. The male/female mix is approx 50/50. * These guys know their business. Every edge case of an edge case is known. Compare that with the enterprise applications, where every release proves within a week to be hopelessly unfit for business purposes. We have to throw millions at the new applications just to keep them limping along. * There is no hubris here. No Architect, no Consultants, no expensive management ideas. A recent migration from cobol to oracle OSB+gui actually required us to add 1/3 of personnel to account for the slowdown caused by people . Yeah we all saw it comming, those wo reported problems were not given raises until we got the message. But cobol culture is 'That can't be done', after which the Architects recoil in horror and let them be.
All in all, Im not sure if this post is an argumant for or against Cobol
Some bad sidess * The language is old, in a bad way. Reading cobol learns you pretty fast why todays practices are better than the multi million spaghetti monster of the past. * IT practices are old. They havent yet embraced lower case. I trieds to tell one of them about UTF-8, but the whole idea that 1 char=1 byte might not be an universal truth was so far out she immediately rejected me as insane. * IT tooling is unique. These guys did CI/CD in the 80ies, but did it with a whole custom stack. They wrote their own source code control, and added an engine wih auto compiles checked in code, rejects code not according to the very strict rules, does some testing, and manages promotion from dev to test to preprod to prod. * The database consists of 12 files (we would call them tables). Each of them has exactly 1 index. You either do a full read or an indexed lookup. There are no more files left, they are used up. Quite a lot of nightly batches exist for looking up data not reachable by the index by doing a full read for each record. See it as a kind of manual join. * Security practices are old. There is no isolation, every application has full access to everything (There is 1 mainframe shared between user data, HR data, payment systems, ...) . If an application crashes, it dumps core. This is considered a feature, as the user can restart without much trouble. The idea that a dump might indicate some kind of exploitable problem is incomprehensible, so it is a continuous fight to keep these guys from connecting cobol straight to the internet.
But even if the technology side is horrible, they provide a lot of business value, especially compared to modern oracle/sap/tata/... 'enterprise class' applications: * The terminal application is quick, even if the learning curve is horrible. You just type as fast as you can. If cobol cant follow, you'll see a pause on the screen, but don't let that slow you down, the mainframe will catch up. * There is no sexism here. The male/female mix is approx 50/50. * These guys know their business. Every edge case of an edge case is known. Compare that with the enterprise applications, where every release proves within a week to be hopelessly unfit for business purposes. We have to throw millions at the new applications just to keep them limping along. * There is no hubris here. No Architect, no Consultants, no expensive management ideas. A recent migration from cobol to oracle OSB+gui actually required us to add 1/3 of personnel to account for the slowdown caused by people . Yeah we all saw it comming, those wo reported problems were not given raises until we got the message. But cobol culture is 'That can't be done', after which the Architects recoil in horror and let them be.
All in all, Im not sure if this post is an argumant for or against Cobol
Out of interest what do you see as the benefits of UTF-8 in source files?
It has caused me problems a couple of times, and I don't ever think I have needed anything outside of ASCII for source code, with the exception of entering some foreign names in to a database via a script.
It has caused me problems a couple of times, and I don't ever think I have needed anything outside of ASCII for source code, with the exception of entering some foreign names in to a database via a script.
Sorry, that post got horribly mangled.
I want UTF-8 in the database, not the source files. This is Europe, user data has accents aplenty.
This once ran on a real mainframe, but was then migrated. So it has the common subset of win1252 and some ebcdic variant, minus lowercase. No euro sign on the financial report anywhere ;-)
I want UTF-8 in the database, not the source files. This is Europe, user data has accents aplenty.
This once ran on a real mainframe, but was then migrated. So it has the common subset of win1252 and some ebcdic variant, minus lowercase. No euro sign on the financial report anywhere ;-)
In COBOL, you will have EBCDIC, not ASCII.
Oh dear, that post suffered a lot from lack of time and keyboard. Sorry. Hereunder a reformat/spelling/missing sentence fix. If some mod sees this: Feel free to replace the original with this:
---
My company has plenty of Cobol. While I am not on their part of IT, I used to work together with them for integration. I left with very mixed feelings.
Some bad sides:
-The language is old, in a bad way. Reading cobol learns you pretty fast why todays practices are better than the multi million spaghetti monster of the past.
-IT practices are old. They haven't yet embraced lower case. I tried to tell one of them about UTF-8, but the whole idea that 1 char=1 byte might not be an universal truth was so far out she immediately rejected me as insane.
- IT tooling is unique. These guys did CI/CD in the 80ies, but did it with a whole custom stack. They wrote their own source code control, and added an engine with auto compiles checked in code, rejects code not according to the very strict rules, does some testing, and manages promotion from dev to test to preprod to prod.
- The database consists of 12 files (SQL would call them tables). Each of them has exactly 1 index. You either do a full read or an indexed lookup. There are no more files left, they are used up. Quite a lot of nightly batches exist for looking up data not reachable by the index by doing a full read for each record. See it as a kind of manual join.
- Security practices are old. There is no isolation, every application has full access to everything (There is 1 mainframe shared between user data, HR data, payment systems, ...) . If an application crashes, it dumps core. This is considered a feature, as the user can restart without much trouble. The idea that a dump might indicate some kind of exploitable problem is incomprehensible, so it is a continuous fight to keep these guys from connecting cobol straight to the internet.
But even if the technology side is horrible, they provide a lot of business value, especially compared to modern oracle/sap/tata/... 'enterprise class' applications:
- The terminal application is quick, even if the learning curve is horrible. You just type as fast as you can. If cobol cant follow, you'll see a pause on the screen, but don't let that slow you down, the mainframe will catch up.
- There is no sexism here. The male/female mix is approx 50/50.
- These guys know their business. Every edge case of an edge case is known. Compare that with the enterprise applications, where every release proves within a week to be hopelessly unfit for business purposes. We have to throw millions at some of the new applications just to keep them limping along.
- There is no hubris here. No Architect, no Consultants, no expensive management ideas. Compare that with a recent migration from cobol to oracle OSB+gui: It actually required us to add 1/3 of personnel to account for the slowdown caused by people having to fight the new-and-shiny application . Yeah we all saw it coming, those who reported problems were not given raises until we got the message. But cobol culture is 'That can't be done', after which the Architects recoil in horror and let them be.
All in all, Im not sure if this post is an argument for or against Cobol
---
My company has plenty of Cobol. While I am not on their part of IT, I used to work together with them for integration. I left with very mixed feelings.
Some bad sides:
-The language is old, in a bad way. Reading cobol learns you pretty fast why todays practices are better than the multi million spaghetti monster of the past.
-IT practices are old. They haven't yet embraced lower case. I tried to tell one of them about UTF-8, but the whole idea that 1 char=1 byte might not be an universal truth was so far out she immediately rejected me as insane.
- IT tooling is unique. These guys did CI/CD in the 80ies, but did it with a whole custom stack. They wrote their own source code control, and added an engine with auto compiles checked in code, rejects code not according to the very strict rules, does some testing, and manages promotion from dev to test to preprod to prod.
- The database consists of 12 files (SQL would call them tables). Each of them has exactly 1 index. You either do a full read or an indexed lookup. There are no more files left, they are used up. Quite a lot of nightly batches exist for looking up data not reachable by the index by doing a full read for each record. See it as a kind of manual join.
- Security practices are old. There is no isolation, every application has full access to everything (There is 1 mainframe shared between user data, HR data, payment systems, ...) . If an application crashes, it dumps core. This is considered a feature, as the user can restart without much trouble. The idea that a dump might indicate some kind of exploitable problem is incomprehensible, so it is a continuous fight to keep these guys from connecting cobol straight to the internet.
But even if the technology side is horrible, they provide a lot of business value, especially compared to modern oracle/sap/tata/... 'enterprise class' applications:
- The terminal application is quick, even if the learning curve is horrible. You just type as fast as you can. If cobol cant follow, you'll see a pause on the screen, but don't let that slow you down, the mainframe will catch up.
- There is no sexism here. The male/female mix is approx 50/50.
- These guys know their business. Every edge case of an edge case is known. Compare that with the enterprise applications, where every release proves within a week to be hopelessly unfit for business purposes. We have to throw millions at some of the new applications just to keep them limping along.
- There is no hubris here. No Architect, no Consultants, no expensive management ideas. Compare that with a recent migration from cobol to oracle OSB+gui: It actually required us to add 1/3 of personnel to account for the slowdown caused by people having to fight the new-and-shiny application . Yeah we all saw it coming, those who reported problems were not given raises until we got the message. But cobol culture is 'That can't be done', after which the Architects recoil in horror and let them be.
All in all, Im not sure if this post is an argument for or against Cobol
Weirdly, I submitted the exact same URL 20 hours ago: https://news.ycombinator.com/item?id=16958811
Not complaining, just surprised: I thought that HN deduplicated within a few days or weeks.
Not complaining, just surprised: I thought that HN deduplicated within a few days or weeks.
COBOL maybe alive but from doing a little bit of searching, the pay scale looks like about half of what a senior engineer in a more modern language makes.
I like studying computer programming history and I'd love to become proficient at COBOL and work on old mainframes! Where do I sign up?
I've noticed that people only speak well of COBOL when Grace Murray Hopper's name occurs nearby.
I suspect that this says something about COBOL.
I suspect that this says something about COBOL.
Grace Hopper is a legend not because the tools she invented are great by modern standards, but because she laid the groundwork. She was also one of the earliest to recognize how important computing was going to be and that hand-writing everything in hex was not a great idea. Later she championed even higher-level abstractions. Programming at the start of her career was considered non-creative secretarial work for women to do, which has the dubious distinction of being wrong and sexist at the same time.
When judged by standards of the day COBOL wasn’t bad. It was one of the first examples of a high-level language. People’s experiences with it (and large undocumented spaghetti logic programs) helped inform the next generation of languages.
Later our (ongoing) experiences with the unsafety of C led to Java, C#, and D among others. Further reactions to those are Swift and Rust.
I’d argue we wouldn’t have any of those languages in the same form without COBOL.
When judged by standards of the day COBOL wasn’t bad. It was one of the first examples of a high-level language. People’s experiences with it (and large undocumented spaghetti logic programs) helped inform the next generation of languages.
Later our (ongoing) experiences with the unsafety of C led to Java, C#, and D among others. Further reactions to those are Swift and Rust.
I’d argue we wouldn’t have any of those languages in the same form without COBOL.
>When judged by standards of the day COBOL wasn’t bad. It was one of the first examples of a high-level language.
Compared to LISP?
Compared to LISP?
> COBOL (Common Business Oriented Language)
You can't compare the languages like that, they were created to fill very different roles, and both were very successful at what they did.
You can't compare the languages like that, they were created to fill very different roles, and both were very successful at what they did.
COBOL was designed to read like plain English (a total fantasy, as English is not even close to a formal language) and be usable by non-programmers (a modern contradiction). It was also designed by committee to serve business needs, with almost no input from the academic community (and thus excluding almost every idea they thought was brilliant, revolutionary, or innovative.) Thus it has a fairly toxic pedigree.
Before you know you’re wrong most of the time you have to actually be wrong.
Cobol was first (or close to it) so it had to discover what “wrong” meant in the context of programming languages.
They had no way of knowing back then that having a programming language for non-programmers is a hard problem, close to impossible. Same goes for the natural language bit.
With the benefit of hindisght, yeah, we can make fun of it. It doesn’t make us right, though.
Cobol was first (or close to it) so it had to discover what “wrong” meant in the context of programming languages.
They had no way of knowing back then that having a programming language for non-programmers is a hard problem, close to impossible. Same goes for the natural language bit.
With the benefit of hindisght, yeah, we can make fun of it. It doesn’t make us right, though.
Doesn't make us right about what? You want me to ignore the hindsight I do have just so I can say COBOL wasn't a bad as it was? This seems to be exactly the kind of thing that you shouldn't have to commit yourself to before knowing it is wrong.
>They had no way of knowing back then that having a programming language for non-programmers is a hard problem, close to impossible
They had a very easy way of knowing this. Ask an actual non-programmer to write code. And do this during the design process.
>Cobol was first (or close to it) so it had to discover what “wrong” meant in the context of programming languages.
They had to discover that ignoring all of the existing computer science literature on language design would lead to poor language design? And that employing an untalented design team would lead to a poor spec? Sorry, but I don't buy it. I certainly don't see some grand lesson that anybody learned from it that we didn't already learn from the previous hundred years of research and design.
>They had no way of knowing back then that having a programming language for non-programmers is a hard problem, close to impossible
They had a very easy way of knowing this. Ask an actual non-programmer to write code. And do this during the design process.
>Cobol was first (or close to it) so it had to discover what “wrong” meant in the context of programming languages.
They had to discover that ignoring all of the existing computer science literature on language design would lead to poor language design? And that employing an untalented design team would lead to a poor spec? Sorry, but I don't buy it. I certainly don't see some grand lesson that anybody learned from it that we didn't already learn from the previous hundred years of research and design.
Is the pay stellar? If so, I could do COBOL.
- Generate native windows interfaces with COBOL, to the point where only a few lines of code create a control like a data grid, button or text entry with rich functionality. You’d never know these snappy native apps, with features like visual data validation and asynchronous menus/context popups, are COBOL.
- Render rich web pages with COBOL using a in-house DSL that automatically become somewhat responsive between devices. The presentation information streams over a web socket so it’s snappy and as responsive as the above desktop application
- Perform complex queries and rich data validation. A few lines of code can automatically be linked to grid view that has HEAPS of built-in functionality like export or data side-view (link applications/side panels to the currently selected row), app row highlighting and styling, auto pagination with range expand, column sorting, reorder, filtering, conditional highlight and more.
So yeah, COBOL isn’t dead. It’s actually the coolest damn thing Ive seen in a while. Because it’s pretty high-level we can build whatever we need on top as a runtime and the same apps can run on the web, native desktop, handheld tablet or on an old VT100 over SSH.