The World Depends on 60-Year-Old Code No One Knows Anymore
Вставка
- Опубліковано 4 лип 2024
- (Or hardly anyone knows)
Believe it or not, a 60-year-old programming
language, COBOL, still powers major systems like banking and insurance. To be honest, it’s pretty bada**
#softwarengineering #developers #coding
Timeline
00:00 Introduction
00:24 How COBOL came about
02:25 What made COBOL good?
03:28 and COBOL is still ALIVE today
04:35 how has COBOL survived?
06:37 Who actually works on COBOL now?
08:26 So what next for COBOL? - Наука та технологія
I can program Cobol, but never put it on my resume, because they might make me program Cobol
So how does one get experience working on mainframes and COBOL?
is it that bad??
I hear you! I did a lot FORTRAN along the way, and managers made fun of it when I put that on my resume.
the main problem with working in COBOL is the working environment. Banks are not known for a casual work environment. There seems to be an entire ecosystem of programmers in that sector that mostly don't interact with the rest of us. I bump into it once in a while but it's like a entirely different programming world
@@myhandlehasbeenmishandled I've been told that's after a full internship in Hellco ULC.
I can still program COBOL. Stop making me feel old.
I’m the same… and I’m not even 50!
That makes two of us. Though I am old.
Me to
Sounds like you can earn a lot of money then.
Me too
The quality of this code is likely significantly better than 99% of today's software.
That's great! However, it's important to consider that the amount of software written today is vastly greater than what was written during the COBOL era. Following that percentage and assuming it to be true, we could conclude that the quality of COBOL code, in comparison, wasn't as good as today's software. It's interesting to see how software quality has evolved over time.
yes you really need cobol for your bios
@@FranciscoCarlosCalderon Software quality is at an all-time low.
It was more likely your code was clean and disciplined, that's for sure.
@@FranciscoCarlosCalderonMuch of the software written today is bloatware, as it expands to fill the available storage. We built an antenna control system in 32k bytes that controlled 4 antenna servos, performed space stabilization, satellite orbital calculations, dead reckoning navigation, and space stabilization of 2 shipboard satellite tracking antennas in real time.
An important point is that Cobol uses decimal fixed point arithmetic while all popular languages use binary floating point numbers. Financial people get really upset when the cents don't match exactly what they expect.
The joys of binary coded decimal on the SNAP (program and memory) dumps as well.
Double doesn't have the floating-point precision issue when dealing with math functions afaik
not even quad (128 bit) binary floating point will give you the same results as decimal math. Note that in both cases the results are wrong, just wrong in different ways. The financial industry likes to be wrong in the same way as their old decimal calculators. A few years back the C standard added an option for decimal floating point and several different processors are adding them as well.
Idk, in Russia we had not banks before 1991. We have the biggest fully online bank in the world and it was found only in 2006. So, we are lucky to kot have any COBOL code for banks. And somehow we haven't problems with incorrect counting of our cents.
I don't think that is the real point.
@@paulinchannel3104 I mean Russians are smart. There's a way to remove the floating point errors by doing more operations per transaction, so they most likely must have done that.
I have been coding in COBOL for 42 years - still going. And I can code in IBM Assembler.
What is your educational background or training that got you that job? Are you like an engineer?
The amazing part of the COBOL is the number of years. If by IBM assembler you mean Mainframes that is spectacular in it's own right.
Have been coding since 1969 all on IBM equipment. I programmed 407 accounting machines (plugboard wiring) then 1401, 360, 370, 4300 series, 3090, s/390, series-1
Wrote for BPS, TOS, DOS (and its variants such as VS VSE, VSE/SP, etc) V/M, OS (and its variants MVS, MVS/XA, etc)
Been writing in assembly since 1970. Converted COBOL code from DOS to MVS. Even recreated COBOL code from core dumps because the original COBOL source was lost.
I am sorry for people that never experienced hands-on with a mainframe. Its is truly an experience. I can do things in 16k of memory that NO other language can do. I wrote a COMPLETE accounting system (A/P, A/R, G/L, PAYROLL, INVOICING) in 32k (including the operating system)
I even got COBOL to dynamically call another COBOL program. Something IBM said was impossible. As of 2012 that interface that i wrote in in 1981 was still running!
To me, there is IBM mainframe then the rest of the other machines
Nobody has mentioned FORTRAN, although that was more the realm of science folks ... and what about FORTH, who remembers that one?
Bei mir genau dasselbe. Ich kernte ab 1981 in der Berufsausbildung an einer IBM3033 unter OS/VS 2 COBOL und Assembler und hatte seither praktisch mit keiner anderen Programmiersprache zu tun.@@jaimeduncan6167
Bei mir genau dasselbe. Ich lernte ab 1981 in der Berufsausbildung an einer IBM3033 unter OS/VS 2 COBOL und Assembler und hatte seither praktisch mit keiner anderen Programmiersprache zu tun.
Exactly the same for me. I learnt COBOL and Assembler Language on an IBM3033 under OS/VS 2 during my vocational training in 1981 and have had practically no contact with any other programming language since then.
COBOL is clear and straight-forward. The staying power of the code is mostly due to inertia. It epitomizes the maxim "if it ain't broke, don't fix it".
Isn't it slower than molasses though?
@@SahilP2648 that's why you run it on superfast mainframes 😀
Also: "if it _is_ broken, nobody knows how to fix it, so, it's better not to touch it" (the very definition of programmer's inertia).
@@GwynethLlewelyn or you can just decide to use a better language and convert all the code. Generative AI would be able to help a lot in this.
@@SahilP2648 well, yes, you can do that - if you have a few hundreds of lines of code. But these COBOL behemoths that run banks and insurance companies and whatnot have _millions_ of lines of code. Let's assume that you'd get a generative AI to convert all the code. Would you, as the bank's CIO, trust that brand-new, AI-generated code to replace the old & faithful _mostly_ working code which has been around for half a century - and risk dooming the bank to absolute collapse if nothing works?
Also, who would test & evaluate that code? Other generative AIs? :) You see where the problem is: at some point, you'll have to trust AI providers with your entire business logic, and hope they come up with a "better" solution (in the sense of using brand-new, latest-generation programming languages with extra bells and whistles)
Someone on this very long comment thread pointed out the obvious: you could, for instance, split the code in its modules (all hundreds of thousands of them!), and go through each one of them separately: get a module, convert it to some other modern language using generative AI, thoroughly test the result, deploy it, then move on to the next module - wash, rinse, repeat, until every single line of code has been fully converted. But that's essentially "rewriting the whole code from scratch" without the _main_ advantage that comes from actually rewriting the code, which is to rethink some of the old things that aren't probably not necessary or that can be done more efficiently thanks to contemporary technology, methodologies, and innovations.
How long would _that_ take?
How much would it _cost_? (even assuming a "free" generative AI which would not only convert the code but also provide test suites at each step, for each module, also for free)
And if something goes wrong in that million-line-code-conversion... something which escaped even the best of the best generative AIs and error-checking AIs... who is going to be able to "fix" things?
Generative AIs are not yet the magic wand that turns a multi-million-dollar, high-risk project into something that can be done next-to-free and take a few hours...
Cobol is still used for a reason, there is nothing to match it in efficiency and speed in many important fields. And Cobol do support graphical user interfaces... Simply build a Cobol backend application with an API layer, and call it from a front-end, receive a response and present the data in any way you desire :). When you login to one of the larger banks and perform a transaction for example, several real-time Cobol modules will be running/executed on a mainframe somewhere, and data then sent and presented to you via browser/app... I work as a Cobol/Mainframe developer...
LOL what?
@@glee21012laughing about things you don’t understand is not the flex you think it is.
Yeh! It's amazing how COBOL co-exists with modern languages and arquitectures, it does well the dirty work 😅
Anyone who says "efficient" and "speed" in the same sentence with COBOL doesn't know anything about speed or efficiency. Sorry, that's the truth, it is neither fast nor efficient. It's what was available at the time when financial programmers didn't like FORTRAN. There's a reason why its nickname is CROWBAR.
@@chribm Well, in the reality I see millions of transactions daily, passing through hundreds of Cobol modules on Mainframes... Its extremely fast and efficient ...
Why do you think 70%+ of all the worlds business transactions runs via Cobol on Mainframes? If it wasn't efficient it would never still been used...
Obviously its not the language alone, you also need the infrastructure.
You do not think the biggest banks of the world can afford recruiting people, competent enough to make intelligent decisions related to tech?
There are still quite a few of us COBOL programmers around. It wasn’t that long ago.
I was a Cobol programmer once - not by choice though but a colleague resigned and made the big mistake of mentioning that I knew it on my CV and my boss remembered that.
It is not the language really but IBM mainframes that makes it live so long - IBM developed several families of mainframes starting with the S/360 family and they all are compatible with each other.
From custom CPUs to PowerPC's of the Z series today can in emulation mode and boot the OS and programs written in the 1960's.
The US tax system is written in a combination of IBM mainframe assembler and for Cobol running on a mainframe from 1960.
Today they still doing your tax returns using it on a modern IBM mainframe but the same code.
The same code, another more powerful machine. The most effecient way to upgrade. In the industrial environment the cpu’s inside also the small contollers are all the time ‘old-fasioned’ due stability and minor bugs inside.
I mean if it works, it works. Not everything has to be rewritten in rust
@@moonasha Rust, some great ideas, but makes me want to gouge out my own eyes.
@@johnridout6540 👍👍Same!
As people say, "If it's not broken, don't fix it" or something like that (there are minor variations out there)
*Grace Hopper* developed the first compiler A-0 in 1952 and the first human readable computer language FLOW-MATIC in 1955. She is also referred to as "Grandma COBOL". Grace Hopper is my all time programming hero ♥️
Also known as "Amazing Grace".
Ah, the amazing grace
I watched one of her live lectures while I was serving in the Navy back in the '70s and '80s. Also, Adm. Hopper was one of the few people who would standup to Adm. Rickover. She wouldn't take any of his shit. 😆 Very interesting person. The quickest way to get on her bad side was to say, "That's the way we've always done it."
That person (Hopper) is my hero as well and I don’t much like her to be depicted as.. Mary….
She was fantastic, but the first compiler was not A-0. There is a discussion of the priority of her presentation, or if Autocode was running before she published. In any case outside of USA and political guide discussion A-0 is not considered the first actual implementation of a Compiler. This does not make her less important, after all, Lorentz found the transformations that bear his name before Einstein did, and I have zero evidence that Hopper had any idea of Autocode, in fact we know she published first.
1. COBOL programmers are available to employers who are willing to pay for them.
2. People can still learn COBOL.
3. The reasons ANY old code base survives are a) it works, why change it? and b) when you have millions of lines of legacy code, not only is it sometimes difficult to know what it does, but also WHICH of those lines of code actually ever execute. Dead code can be as much as 2/3 of a codebase. Additionally, not only does old code sometimes lack documentation, but also tests, so risk exists that if you change something HERE, you may break something THERE, without knowing it.
Is it possible to copy the code and run simulations?
About 40 years ago, I read a short article in a computer publication. It was about a programmer who wrote a routine that modified itself during execution. In the comments he wrote "When I first wrote this code, only myself and God, knew how it worked. Now only God knows ".
Two quotes: 1) "I know COBOL and I won't starve" C. Pitts Control Data Corp. circa 1979. 2). "What runs on the mainframe? Civilization." Roberts, International Business Machines circa 1987. Both statements are as applicable today as the were 40 to 50 years, from Shanghai to lower Manhattan and all points in between. Anyone who can code can pickup COBOL in about 1 hour (I did it on the Chicago NW line one afternoon). The institutions you listed didn't even name the largest institutions depending on COBOL. Why COBOL? It still works and doesn't even need recompilation. Book of records usually requires continuous availability and those grand mums and nainai from Chengdu to Mumbai, Joburg, San Palo and Des Moines expect those ATM and credit cards to work 99.999% of the time even after a disaster and that means COBOL running on big iron, even in Wai Guo Qiao Pudong.
Also, in 1959 the department of defense probably owned 99% of all the computers in the world. So if they didn’t do it, nobody would.
Wellllllll not quite 99%... remember, the IRS was also using it (and that was true for most of the Western world). But sure, they would have owned the overwhelming majority of all computers.
Maybe 99% of computers in the USA - the UK government and banks had plenty too, even Universities had them by then.
Also, the DoD has huge administrative functions, between payroll, facility maintenance, etc. The lifeblood of the DoD is money.
Coulda fooled me, when I joined the Army in 90 it sure seemed like everything was still run on handwritten forms! I think there was a computer in the shop office.
"Also, in 1959 the department of defense probably owned 99% of all the computers in the world."
Hardly! Not even close.
Universities were the big owners. And by 1959, it was slowly starting to spread into business overall.
I’m 66 and a retired COBOL programmer. AI should be able to update it now except for COBOL spaghetti code with non-standard magnetic tape processing and hidden calls to special routines. Yes it’s still there unchanged and untouched for 50 years. It sits there waiting to trap some naive AI or person attempting to update it.
AI, you said? Don't give us nasty ideas here, such as telling ChatGPT or some other AI chat bot to make a simple COBOL "Hello world!" program! 😂
Ai couldn't even help me write a simple component test in JavaScript, I doubt it can rewrite entire software
it's still hard for AI to create a program of a memory game without spitting errors every 2 lines
I`m not a programmer, but I imagine such an undertaking would be like opening a compressed can of worms...
LLMs will never be able to write effective programs for the simple reason that it is incapable of reasoning about the "code" -- tokens, really -- that it spits out. It is doing a statistical inference on a copus of code already written by human beings.
Think about that for a moment. There is no dynamic reasoning in statistics. None.
I am always amazed that anyone expects LLMs to do better. They are good for a very limited domain of things. But anything truly creative and constrained by logic and reason? No.
IBM mainframes are the silent workhorses in the economy. They sit there and run year after year.
The z in z/OS truly means zero down time.
All that COBOL code regardless of what any new gen says is truly an investment-much of it made decades ago.
I work in IBM midrange (35 years now). Our systems run a billion dollar enterprise. The only worry we have is the lack of talent.
It was written in the days when people were trying to make computing as simple as possible. The idea was that since it was basically a constrained form of English, even managers would be able to write their own simple queries and so on. Then people brought out things like Easytrieve for manager's reports and eventually they realised managers couldn't learn to program under any circumstances.
I can remember programming schools where they would take in anyone who passed an aptitude test and teach them COBOL in three months and guarantee them a job.
One of the great things about COBOL is the arbitrary precision of numbers, especially in decimal - you could accurately represent numbers like 18 digits and a decimal point and 10 digits ... which made things like financial calculations work so much better than trying to lever them into a LONG or a FLOAT.
Some of the new languages have retreated from the concept of easy and some of the new features of C# and Java are probably only usable by people with degrees in software engineering.
Probably not even by them (points at self)
I Dont See much Developers who have even heard of Software engineering 😂 They followed a Multiple choice learning path and got a certificate, not more.
Yes, it took languages like C# and Java to realize the importance of decimal numbers. Prior to then, I've seen a host of languages all of which only integers and floats. Though, it seems weird, if one had to rewrite an existing Cobol module to Java, that one may discover of which Cobol does quite a bit behind the scenes.
That's very true, COBOL really "cracked" the decimal/number-manipulation issue though it felt extremely verbose in data definitions. My prog. "school" was 6 weeks only, no job guaranteed but I got one, & thankfully got out of COBOL ASAP. Into a different environment which was great for 20 years, then redundancy & my IT career ended. Application development had gone to India. If I'd stuck with COBOL I would have been OK financially, but perhaps driven crazy.
@@marcuswilliams3455 You said "Yes, it took languages like C# and Java to realize the importance of decimal numbers" - I beg to differ on your wording, they perhaps rediscovered the importance of decimal numbers. Otherwise, you're spot on.
COBOL was “old” when I was in college. The biggest issue with cobol systems is how a set of programs will share files. So knowing the language is only the first step. Understanding the dependencies and interactions is the bulk of the problem.
Could you please elaborate through a rudimentary example?
Yeah, I was going to say, I've seen textbooks on it in public libraries. It doesn't really look that hard to learn. Like I could probably learn it in a few weeks.
@@xenopholis47 some people I worked with spent over a year trying to reverse engineer 200 cobol programs used for credit card settlements. There were so Marty reading and wtiting to the same files under different circumstances that they were never sure they got all the interactions.
@@michaellatta yes exactly - VSAM / seq datasets, and not just the COBOL but also JCL (& what disposition each job has the files open under), and anything else the JCL is doing to the data outside COBOL.. (and that's just batch :)
@@johnlacey155there are different operating systems hence different JCL
75, Unisys Cobol programmer for 30 years (with IBM before hand) and still working with it. I have learned C# and Python, which can do things COBOL cannot. But COBOL is easy and reliable.
I got back into programming with the run-up to Y2K, working in two shops making the conversions. We made a lot of money making program conversions but _I expect to really clean up when _*_Y3K_*_ comes around._
and really rake in the cash when we approach Y10K
y2k38 is an actual thing that will happen, better get started
@@meep.472 mostly embedded systems require to be updated hardware wise to support 64-bit memory. Like your router for example. Otherwise, any modern-day PC is going to be fine (way before 2038).
You mean 2048? 2^11? How could this possibly be an issue at this point?
@@keith77mn77 lmao no. All devices use a standard called Unix time which started in 1970 as an integer value increasing once every second. This is a 32 bit value which is set to overflow in 2038, so if any device uses unix time and is not updated to 64 bit by that point it's gonna think it's 1970 again and that can create a lot of issues.
Surprisingly I met a COBOL programmer last year who was in his 30s.
I think a feature of COBOL that is often forgotten, is that it didn't use floating commas for calculations, avoiding 'rounding bugs' and strange (but very expensive) things like that.
No. Misunderstanding.
In English, it's called "floating point". The trouble is exact calculations are very computationally expensive -- they take a lot of CPU power. Years ago, I heard that Bloomberg had special FPGA-based PCI cards to do 100-digit decimal calculations. FTSE just used the floating point hardware in normal CPUs, accepting that they would sometimes lose shares. I don't know what languages they use.
Imagine what you could buy with $800,000 in 1959
Approx 115 houses in the burbs at 7k each 👀😢
Anything you wanted
A Lamborghini Countach was approx $200,000 in the 80s
at that time a house was like $30,000
in 1960 they would have been $5,000 - $10,000
You could have most whatever you wanted and then ... retired comfortably for life
No one knows COBOL? Really?
Really.
I know it a little (college class in 2001).
I saw the thumbnail and thought COBOL.
I learnt it in the late 80’s at college as the main focus of the diploma and never saw a single line in production for the rest of my life.
I do :)
I studied it while I was young. There must be a lot of books about it and it was very simple compared to the nowadays languages.
I learned COBOL in 1981. Like riding a bicycle, never forget it.
Same, I just can't concentrate long enough to be truly effective at it. NetWare saved my bacon back then. I still run 3.12 in Vbox for shits and giggles.
Agreed. I learned COBOL in about 84/85 but was never a professional programmer. I've just picked it up again now and it's amazing how it all (mostly) comes back!
Did it ever occur to you how, at a time when a "smart" phone that is already hopelessly obsolete after 1 or 2 years, any programming language or hardware platform manages to still be in wide spread use after 60 years? That's not something you pull off by "getting it wrong". That's something you accomplish by getting it VERY right. The problem isn't with the platform, or the language... PEBKAC.
Or is it just a case of the huge installed base of effectively so many zillion dollars worth "application/system-design" logic, which isn't easy or often possible to port to modern languages. Especially w/o documentation, & few staff able to help convert etc etc. So it would have been same if written in some other language with comparable scaleability/portability which is similarly ossified.
@@daffyduk77 exactly.
@@daffyduk77 So, you're effectively saying that the skills and capabilities of "modern" programmers are inferior to those of their predecessors. You've also made the case that the modern languages are inferior to "the old stuff" because as you said, it "isn't easy or often possible to port to modern languages".
Also, if a business has existing applications that work and meet their business needs, what's the business case for assuming the costs and risks involved in rewriting something that's already working in a different language, so they can keep doing what they're already doing?
@@BearGFR no, you're getting all defensive about your current generation of IT whizzkids. It's that the pre-existing software can't be reverse-engineered into its underlying logic & business system design & then have that re-applied to the modern technologies. The modern stuff takes a lot more Computer Science expertise than the old stuff did, & doing both s/w reverse-engineering plus re-coding for new is a decidedly non-trivial undertaking. Depends if there's much documentation available regarding the pre-existing software functionality & requirements, or not
Normally any discussion of COBOL mentions Grace Hopper, one of the inventors of the language. There is anecdotal evidence she was also involved with the use of the term "bug" and "debugging". I learned COBOL in 1980 and used it for most of my career.
The term 'bug' was already used in engineering, even Edison used it. Her instance is the first _actual_ living bug that caused an error, and that's why she wrote that journal note. IIRC that journal page is still being preserved.
@@timradde4328 It was a moth, as I recall from what I've read. I wouldn't be surprised if the story has been distorted and different versions can be found in the literature.
It was a moth. Computer memory at the time consisted of a grid of wires with a donut shaped magnet at each intersection. The polarity of the magnet could be reversed so that the bit could be flipped on or off. A moth flew into this wire grid and shorted out a section of it causing a "memory fault."
@@DrunkenUFOPilot Actually, Hopper's meticulously-kept notebook has a page with the actual moth that documents the event. The notebook is in the Smithsonian, so no embellishment.
Actually, that’s also a bit of a myth. Rear Adm. Hopper did not invent COBOL. She was for a brief time on the CODASYL committee, but really not for very long. Some of the syntax of COBOL is based on Flowmatic which she did design.
I'm not from IT but worked at a bank with product management. It's true that the codebase is mostly a black box for most of the employees, and they need to be extra careful with systems updates because any change could stop other processes that relied on it. There's no documentation, and developers most familiar with particular systems are the ones who worked on it longer. It's even weirder that development is outsourced. I assume that the company holding all the knowledge about the systems can name their price. There are stories like the one developer that knew a system left for another job, and was begged to come for a visit from time to time to help fix something.
But on the other hand, a few years ago the accounting system was rebuilt from scratch in SAP. It took 5 years until it was completely switched and the first few months were absolute chaos. A few millions in unreconciled entries were just forgotten about, probably because they just gave up trying to figure them out.
Rewriting an old system might just be too complex, and companies will only do it, if think, if not doing so gets them in legal trouble.
From Cobol to SAP, Wow. Talking about from the frying pan into the fire. It takes about 5 years to write Hello world in SAP, so no surprise there.
But don't go for Python or JavaScript for large critical systems. You can't create quality with testing, you can only improve existing quality with testing. Stick to proven languages with type safety and memory safety like C#, Java or Rust nowadays. (I know, SAP uses Java, that's not the point)
@@mennovanlavieren3885 SAP looks complicated to develop for. But they nailed the corporate pitch (governance, compliance yada yada).
@@mennovanlavieren3885Yes, I was puzzled that Dee compared COBOL (which I assume is an abbreviation for "COmmon Business Operations Language") to Python, when Python is a scripting language, much slower than, say, C or C++ or whatever is the current equivalent. The first two are not only well-tested, but have lots of people who are well-versed in them. (BTW, Javascript is also a scripting language, which was written in 2 weeks.)
SAP SUCKS
I have been programming in COBOL for more than 25 years. It's actually pretty easy to read, and not too difficult to write. I keep hearing how COBOL should be retired, but we keep using it because there is nothing better for our purposes.
Cobol is a language that is mainly used in batch processing to process a lot of data. File in, proces, file out. It is not meant for interactive processes with forms, although it is possible. The main power lies in the predictable calculations, where you have the precision in your hand. Not that other languages don't support BCD notation, but most rely on floating point notation. It is also a true compiler with a strong defined language that produces the same result, no matter what platform it compiles on. Rewriting Cobol applications for heavy file processing in a language like Python is simply... Well, many processes that need to run each day will take more than a day to run in Python. So use the tools where they are the strongest (nothing wrong with Python, but not for this purpose). Cobol, currently, is also object oriented as most other modern languages. Popularity is low because it is mainly focused on financial transactions. Not for games, not for AI, not for stuff you like to develop for PCs and mobile. The financial world is pretty static. So are the programs in Cobol. And execution times are fast. Very fast.
No. Misunderstanding.
Grandma COBOL is a legend. And her first documentation of a computer bug.
This is not quite true - it was a common term by the time she discovered that "bug" - the joke was that the bug was caused by an actual bug. Not that the term bug was derived from this occurrence.
@@zoeherriot Thomas Edison also found a 'bug' -- a squashed insect in a telephone relay which prevented it from working properly. He wasn't the person who invented the first debugging hardware, however -- that would go to whomever invented the first insect screen. That said, we all remember Adm. Hopper's bug.
@@zoeherriotQuite correct, we know that it was a common term because of how she described it: "First actual case of bug being found."
It was the first actual case of a computer bug (error) being caused by a literal bug (insect).
Why would she write that unless errors were already called bugs?
Also heard the Turing machine, Colossus, crashed when a moth shorted out two valves, another anecdotal/legendary beginnings on the term "bug" - that was the 40s before the USA had even built a programmable electronic computer.
@@wolf5370 I've heard that, not sure how apocryphal it is.
Btw, probably want to avoid calling anything "the turing machine", as "Turing Machine" is a specific important concept in computer science.
COBOL is really easy to understand. Nobody wants to learn it only because it is so damn boring. But I am sure with enough financial incentive many people will make an exception and learn it to make bank.
Standard COBOL is easy, old COBOL from 1970’s and earlier can be a dystopian nightmare.
@@raybod1775 not really.
It's boring because it is only for... business. Not exciting for most young programmers who prefer the latest hype and I don't blame them.
@@raybod1775so the problem is not cobol but the spaguetti legacy code. PHP, java or python can be a monstruocity in wrong hands...
@@raybod1775Das gilt für COBOL vor 1968 und undisziplinierte Programmierer. Es ist auf jeden Fall ein gut handhabbares und wirklich mächtiges Werkzeug im Zusammenhang mit Massendaten.
This applies to COBOL before 1968 and undisciplined programmers. In any case, it is an easy-to-use and really powerful tool in connection with mass data.
The fact that it has not only survived, but is still so widely in use, is testament to its utility.
I heard that long ago people were able to make also cars which work until now, construct buildings which last until now, and so on. It's not only about software.
Perhaps "the world has moved on".
"If it is not broken don't fix" is the rule.
just replace it
@@tms2566 🤣
@@tms2566There's WAY too much of it to replace all in one go.
The problem is that the law changes, accounting requirements change, new payment systems are needed, new features are needed, on some level it's ALWAYS broken against current requirements.
@@dlbiggins COBOL code is regularly updated to match new regulation, the language itself has also had several new specs since the 50s, the latest one being from 2023.
One of the biggest benefits of using COBOL is that it does EXACT decimal arithmetic (i.e., not floating point double precision) , which is a huge advantage in financial systems. You can write highly structured code that is really easy to read - almost self documenting. But it's not at all suitable for web development, which is a huge disbenefit for most developers.
Floats should never be used for financial calculations. If necessary, should a language not provide fixed decimal arithmetic types, a whole number type can be utilised instead. Though a little extra work would be needed to display the correct values.
@@stewartkingsley Floats can be used, but not binary floats. Binary floats can't even represent 10 cents properly. IBM Machines of the Power and Z series have had 128 bit decimal floating point hardware for more than 16 years!!!. The precision is more than enough for any practical use.
One drawback to that is you need to make sure that the PIC allows for enough digits. If, for example, you are expecting a number that is 10,000 or more and you have a PIC 9(4) then your variable will roll over unexpectedly. I have accidentally created some infinite loops that way (and wasted a whole box of green bar paper...)
@@myofficegoes65 Yeah I had days like that in my early career 🤣🤣
The insurance company I used to work for relied on COBOL for the backend to its web based customer and employee facing portal. COBOL also handled all the batch processing of creating documents and renewals.
About 40-60% of the banks and CU’s in the U.S. run on IBM midrange computers (IBM-i dating back to the AS/400 and Linux on Power dating back to the RS/6000). The IBM-i’s primarily use a programming language known today as RPG (though they support other languages like C, Java, etc.). All of these have amazing fascinating histories that would make a great video because they are still so pervasive in 2024!
I've used a little COBOL in the past and I can assure you that it's not more difficult than C or Python. Most concepts can be easily mapped to C constructs.
COBOL has evolved a lot since those days, and it has OOP and some versions can do GUI. But from what I can see the ease of use remains.
I just passed my COBOL uni exam today
Congratulations, I got COBOL at uni because of the Y2K (yes I am that old) I hated it but it was pretty easy. If you go into mainframes the cool part is going to be the toolset.
Gratz
You will definitely not run out of opportunities to work. And you can make a fortune doing so!
Congratulations! I am so glad to hear that!
COBOL was the primary language of my college days. I spent a number of years working in it, even on desktop applications. Of course no discussion about COBOL is complete without mention of its mother, Admiral Grace Hopper. A true giant in history.
What a well put together video. Thank you. The knowledge is spot on. Your visual transitions and little comedic interjections have great timing. You have a wonderful speaking voice that is melodic and easy to understand at any volume level, and you're quite pretty. Subscribed. I won't make any requests for tech content topics because I first need to see if you've already covered it in your catalog.
The issue with COBOL is that it is used in Data Processing, not newfangled wiz-bang developments. The problem with Data Processing is not the language(s), but that this endeavor requires extensive Systems Analysis. Regardless of whatever language, large elaborate computing is all about Data and Systems Analysis. What do you actually WANT your ATM to do, for instance.
If python is supposed to be the alternative ... well, I guess COBOL will stay here for a while longer then
Every newly popular language has been slated to replace COBOL: VB, Java, etc. The problem (or better said the advantage) is that the current COBOL programs are very stable and it's hard to take a risk on something new when what you have works fine. For batch processes (which are used extensively in bank transactions and the clearing of stocks/bond transactions), it's hard to find a language that performs better than COBOL and is still comprehensible. I wouldn't write a website in it, but for what it does well, I wouldn't replace it.
@@alexaneals8194 The amount of security issue that we'll have if it's on Python is gonna fun x)
People also forget that cobol standard is still being updated. As a result, it is easier to bring features that prove to be useful to cobol than rewriting everything to a different language just because it supports a new paradigm (the same thing applies to c, c++, Ada or whatever language that supposedly will be replaced)
🤣
I understand Cobol and Python share an abomination I cannot abide. The use of a period to end a block in Cobol is as bad as using indentation to construct logical structures.
Both are idiotic.
Hurrah for COBOL!! I was a COBOL programmer for years 😀
me too, but now I am a python programmer 🙂
I took COBOL at DeVry in the early 2000s. It wasn't enough for me to call myself proficient, but it was easy enough to learn. And, of course, there were more complex aspects to it that we were not taught. That said, if I had reason to pick it back up I don't think it would be difficult to relearn.
Oh, I know COBOL, it was the language I was hired to write code in at my first job. Back in the early 1990's, that was. It's not that complicated, much easier to read than C.
I'm 54 and have been a Java dev ever since Java came around. I also to have some OS390 experience from my early days (PL/1, JCL). I do wonder sometimes if I should learn COBOL so I can spend the rest of my career maintaining old, boring (but important) COBOL programs... possibly getting a better pay than now, and having a less stressful job than now - and not having to chase every new tech trend every few months anymore - which does get harder when you get older.
I was thinking this too :) Am I too old to change? LOL
you probably should! If you are even asking this question, the way you did, then yes you should! Much respect to you!
Until they decide to do tech refresh
@@Krisdomain "They" would have replaced their decades old COBOL stuff a long time ago if they could. There are reasons this code is still running.
@@bellissimo4520 agreed, even large banks don't have that much spare change, let alone technical capability
At 3:19, your Python does not match the COBOL. You don't print the first_number before adding to it.
🤣
Didn’t take long to find the COBOL programmer 🫡🫡🫡
@@codingwithdee Another one here. No need to worry, many of us can PERFORM SAVE_THE_WORD when needed.
It would have been more informative to translate and compare trivial Cobol code doing exact decimal arithmetic into Python. 🙂
Can someone explain this to me? The statements seem to be in the same order. Is there a difference in what "ADD 20 TO FIRST-NUMBER" followed by "DISPLAY FIRST-NUMBER" does in Cobol vs. the Python += and then print()?
@@The_1ntern3t The output in COBOL:
Here is the first Number
8
Let's add 20 to that number.
28
Create a second variable
30
The result is:
58
The output in Python:
here is the first number.
Let's add 20 to that number.
28
create a second number.
30
the result is: 58
In my first job, I had to program in COBOL. It was very easy to learn. In general, old languages are simple and easy to learn; modern languages are the complex ones. The most strange thing for me was data type definitions (and the LEVEL 88 🙂).
BTW, that company developed COBOL software to be used in DOS machines connected to a Novell newtwork, or UNIX machines. COBOL is not necessarily a synonym of "mainframe".
I want to be a retro coder, but I don't find managing memory easy when there's so little RAM. Something to learn, I guess, but I learn slow.
I'm an old COBOL programmer and I love it. You could write code that your supervisor could read using 88-levels. Was writing object oriented code in the 80's.
Most companies I work with are still developing COBOL today. Many of the mainframe systems have developed to support newer technologies, like Web Services, using regular COBOL. The code is compiled so well it is hard to compete with it on the mainframe where every MIP counts. Also these companies have the same code that was written decades ago and it still runs today without a recompile. Third party libraries for COBOL are nearly inexistent. Those trying to change to Java and use third party libraries usually have to recompile once in awhile to allow a newer version of the framework with bug and security fixes. To me that is the wrong direction and the throughput is hard to beat on the mainframe.
Correct, my company has lots of COBOL programmers still and it's far from "old" code. We're running on the newest zOS, current mainframes, most recent version of DB2, etc. We have web interfaces, APIs and everything you'd expect from a current application. While most of our new applications are Java now we're still writing some new COBOL applications for the stuff that absolutely can not ever go down.
As a retired mainframe programmer the server world seemed pretty unorganized and hard to maintain. Lots of folks chasing issues that were just handled by centralized operators.
She just made a video because she is clueless and wanted to spread misinformation.
8:28 it’s not the COBOL language that’s difficult. It’s changing a code base written decades ago when computers had serious limits on memory. There weren’t even dynamically sized arrays, let alone lists and hash tables. Programming in modern COBOL or Fortran, by comparison, is easy - far easier than something like C++. If one tried to replace a section of old COBOL code with Python and still live within the constraints that a 50 year old code based was designed to live in, you’d find it quite a challenge. What if I told you that you had to write a Python module but without using lists or hashes, and only using decimal arithmetic so there was no loss of precision? Oh, and your code has to simulate taking inputs from multiple tape drives and merge the results into a single input stream, then do processing at control breaks? Yeah, have fun with that! The style of programming itself was vastly different back then, and you can just shove new code with a different style into an old system without making the system even harder to maintain.
No. So many misunderstandings. You had to read the COBOL Language Reference a n d the COBOL Programmers Guide. They were a matched set. One useless without the other.
"...have fun with that..." - no fun to be had with COBOL. Maybe seeing the money hit your bank a/c each month is all
I tried to design a little personal organizer / retrocomputing gizmo around a microcontroller I happen to own. It has 16KB RAM. I know a few tricks, but _YEEK!_ XD I ended up realising it would not be fun. The bad part is flash write speed is inherently very slow, so I couldn't just flush data to "disk" whenever I needed space. I thought about hooking a 512KB SRAM to the IO pins and using it as a write-combining cache, but if I'm going to buy parts I might as well buy a microcontroller with 512K RAM to begin with.
@@sspoonless The OP's comparison with Python holds just fine. You need the Python Language Reference and module references *and* tutorials to be getting started with. I learned Python 1.x in 2001, used it until 2004, then didn't use it until well after 3.0 came out. For some things I needed to do and had been doing in a curious little system called Plan 9 From Bell Labs, I found the Python module reference far too big. It was crammed full of things I didn't need and had never heard of to the point of making it painful to find what I did need.
Oh and that microcontroller with 16KB RAM in my other comment runs MicroPython. ;) I was going to put Forth on it, but it would be hard to do what I want with it even in Forth.
You can’t really compare COBOL with “modern” languages like Python, C, etc. COBOL was made for transaction processing in an age where users had forms-based terminals and the typical mainframe had hundreds and even thousands of terminals. COBOL may be old but for transaction processing tasks, it’s still the most appropriate.
Not so. COBOL was made for batch processing. Nobody had terminals except the computer operator in the computer room with ONE teletype terminal. I was there. Were you?
@@bartospivak5755 Well, I only started my IT career in 1968 but I was probably in a different place. All the big insurance companies, banks, government organizations etc., had mainframes with forms-based terminals, hundreds of them. Yes, the computers were essentially batch processing and big jobs had to be run in batch, outside business hours. The terminals were forms-based and when you pressed “enter”, the form was sent and a small batch job was started to handle the transaction. That’s where the “enter” key on your keyboard came from. COBOL (COmmon Business Orientated Language) was made for this type of work.
Assembler, Fortran, COBOL, C , UPG, RPG, SQL, and more. COBOL 40 + years, Assembler 20 years. Still work part time COBOL.
This takes me back! This was one of the first languages I had to learn! Since I never worked in a financial institution, the language faded away in my memory! COBOL is still used today and follows the old adage, "If it ain't broke, don't fix it!" I heard a few years ago, that COBOL Programmers could earn excellent wages for their knowledge of the language since, there are so few out there.
I think *"...had to learn..."* sums it up. No-one would do it other than for money/career. Whereas I *wanted* to check out BASIC (boo, hiss) because you could do fun stuff quickly & easily. 43 years ago, that is
We're not all dead yet. Just because COBOL is old, and those of us who know it are perhaps older; We are still among you. As an aside, I wrote the algorithms that secure your banking pins on the smartcard in C. So those will last a bit longer.
C, not C++ just plain old C, is going to be around about forever. The effort to deploy a modernized universal embedded systems language, Ada, basically failed. There were many reasons, but basically its advantages just weren't advantageous enough. C remains the very best language for embedded critical systems.
Thank youuuuuuu!
A lot of us can program COBOL, but never admit it. The reason it is still around is because it was straightforward did exactly what it was supposed to. No more, no less.
COBOL is in the client server world too. Peoplesoft still uses it...
BTW, my Dad learned COBOL from a certain Commander (later Admiral) Grace Hopper. He was also an assembler programmer...with the War Department, later DOD, then IBM then GEICO.
That's worth a like and a sub! I have led the assessment of alternatives for a large insurance company's mainframe system - once we totaled all the bits up we looking at up to AUD 50M and 18-24 months to convert to a modern system, and at the end of the day we would have the same functionality as the current system. Didn't get off the ground for some reason ... :)
I am retired now but dealt with COBOL for over 40 years along with other languages. If you have good logical thinking COBOL can be your best friend. Even now IBM COBOL can be object-oriented, if that is what you desire. I found structured COBOL programming more to my liking.
My mum had to learn COBAL in three weeks. And was in charge of the programming team, it was all done on punch cards. You even had to check the code prior to running them through the mainframe.
Cobol can be learned in 6 months at a community college then it takes maybe 3 years to get proficient. Companies tend to replace it with object oriented languages, which are far more secure. The difference is that Cobol has an entire process in the stand-alone program (think sequential logic) while OO hides beneath layers of code, some which are written in other languages. Learning some of these OO's requires years of higher education and brilliant people to get a full grasp. Really the only time it makes sense in getting rid of the old language (for most companies) is a total ground-up redesign of the process, an extremely complex process. In the 90's we moved from an NCR computer (think a machine half the size of a refrigerator in a room the size of a living room) to a Unix server (big PC sized). There was one single line of code in each program changed, recompile, and it worked 100%. My co-workers were injured so I did the changes in 1 month. There was a "small" speed advantage. A program that searched the entire database (ran 16 hours) now took 5 to 8 minutes.
"Object Oriented" is just an implementation. There's no reason there can't be an OO Cobol. There are OO Fortran compilers. Most versions aren't, but there certainly are a few.
I like cobol because it is very structured. I would be happy to go back into that language anytime!
COBOL is still the language of choice for business and financial software on an IBM host.
Analyse dumps after an abnormal end (ABEND) and you can resume where processing stopped last time (with some JCL script adaptaion).
Essentials of COBOL are easy to learn. I once taught two newbies the basics in 4 weeks and could focus on designing that automated test algorithm for database access routines, the newbies programmed it.
On another occasion I was forced to do complex backtracking AI in COBOL 74 so it could run on an AS400. Granted, I would have preferred C++ but it worked in COBOL 74, too, with vast arrays.
Fun fact, modern COBOL has been a hybrid object-oriented language for decades now but nobody uses it that way.
Heck, even local variables in sections (sub routines to normies) is not used in most cases. Why, I don't know.
COBOL is not difficult to learn. It's just that it is very limited, so to achieve certain things, you need to write a lot of code. COBOL is most suitable for record processing - read some record (like a credit card transaction) from one of the many input cards, do something with it (like increase saldo here and decrease there). Once you know PERFORM UNTIL and format records, you've 50% there :)
Control breaks was one of the most enduring lessons I got from COBOL. Such a simple and useful concept that if poorly implemented can create havoc.
Fun fact: COBOL-D did not have the perform clause. It was all goto's
@@rty1955 :-)
Exactly, same goes for all "mainframe languages", they are just very feature poor, so you always need to "reinvent the wheel", there are very few libraries compared to modern languages, meaning everything becomes tedious to do.
@@youtubebob123 except Fortran. There's math libraries out there where they write a C-wrapper, instead of porting the lib itself.
As a language, Cobol has many drawbacks such as poor support for recursion, lack of modularization tools, little support for asynchronous programming and no support for modern functional-based programming constructs such as maps.
I agree that it's value is in the huge working code-base, well worth continued support.
Cobol's history can be more correctly traced back to Grace Hopper.
My first job out of college was COBOL programming. That was in 1982. I was living in Las Vegas, and we were developing a Race and Sports Book Package for a casino. Programmed on an NCR VRX mainframe computer. Brings back memories, I'm 68 years old.
Not programming related, but I'm a 71 year old retired EE. Just want to wish you a pleasant retirement! 😊
There is money here. Do the thing no one wants to do. Also, what works, works. We wrongly think things need constant replacing.
I was born in 1960 and started my IT career in 1984 as a Cobol programmer for a bank. Today I program with Python (but no longer for a bank). Can only confirm everything you said. The smartest thing I've heard about COBOL in recent years.
You really got a knack for choosing your languages, haha.
I won't touch Python even if my career depends on it, its so bad...its 10 steps back.
@@TheEVEInspiration a pity so few people agree with you. There is something mystical about Python. I have yet to understand what exactly makes it so popular. Perhaps that's the whole point, really: nobody asks and everybody just assume that there _is_ a reason for its popularity...
I was ten years out of college when COBOL was invented, to give you an idea of my job progression. I regularly build websites using nothing but COBOL.
left college in 1949 and still coding today? Wow! (Cobol first released in 1959)
COBOL natively does business math in a way modern languages do not. The data types and math operations allow for business rounding of results that match what businesses and tax codes expect. Similarly, overflow conditions are also built in. COBOL can be compiled to machine code or very efficient p-code making it extremely fast. COBOL is also very portable, with the same code running on many different operating systems. It's a good language that doesn't change. It allows a developer to become truly proficient without having to chase the latest fad in the ever-rotating array of better mousetraps (new languages) being invented.
Great video! its not COBOL that's difficult but the complexity of the technology surrounding it. And i think saying COBOL is close to Python is a bad idea because we all know python programmers don't want to go deep in understanding how certain things work🤣
I believe that Konrad Zuse is credited with creating the first programmatic language (in the 1940's), and had envisaged/designed what we would now call a compiler for it. This work precedes everyone. And there were probably others, who didn't get their name up in lights. Both ALGOL and FORTRAN existed prior to COBOL, so it's not true to say that a major jump occurred between machine code/assembler and COBOL. Both of these languages were used in a business context, especially ALGOL, and many would say they were better suited even for business use. Also COMTRAN existed prior to COBOL, and there are probably other languages. COBOL was and is great, but it didn't solve the problem of getting away from assembler, it was actually a standardisation exercise. Also I would be surprised if the CODASYL group was formed on the basis of influence from any single individual. I'm not sure that ALGOL and FORTRAN were even the first 3GLs - it appears that these were the first of the widely accepted / implemented 3GLs though. One of our lecturers at uni swore on the bible that it was better to code business apps in assembler, and that it was all a matter of structuring re-usable modules/macros efficiently. I don't agree, but I understood what he was saying.
ALGOL -> Pascal -> C -> C++/Objective-C/C++/Java -> gazillions of programming languages vaguely inspired by it (JavaScript is an obvious one, Go as well, I'd add Rust to the bunch, and - allegedly, according to some obscure sources - even Python!). So... if you learn ALGOL, you learn the basics of pretty much every other general-purpose programming language available today.
If you learn FORTRAN - you've learned FORTRAN 🙂 That's pretty much "it".
Then you have LISP, also from the late 1950s, and still widely used under some of its incarnations.
And, well, COBOL, which is just... COBOL.
@@GwynethLlewelyn wow - nicely done! Yes ALGOL doesn't get the recognition it deserves, as per the lineage you've outlined. Crazy when you think about it really? I believe the ISA for Burroughs large systems, starting with the B5000, was engineered to support ALGOL compilation. And not to mention that MCP itself, the Burroughs OS, was written in ALGOL. (This is the same MCP from the Tron movies). Amazing to think these machines were so far ahead, not to mention that they looked like something from a sci-fi movie. ALGOL was big in the Data General world also (significant in their own right, and in the history of Apple), I managed to purchase a physical ALGOL manual for AOS/VS a number of years ago.
Really enjoyed your video - good work :)
I worked for a big insurance company. We had millions of lines of legacy code written in COBOL. We couldn’t just rewrite the code in modern languages because old code wasn’t well documented and nobody could easily say how the calculation should work. But the code needed to be updated and maintained. While it’s essentially impossible to hire Americans to do that work, many foreign companies - mostly Indian - have stepped up to fill the need. We had so many foreign contractors on site the cafeteria was forced to add a vegetarian section to meet their needs. And for every on site contractor, there were 2-3 contractors back in India working with them. Great people for the most part, I really enjoyed working with them.
We are constantly fed the myth of "AI"-code generation being that great.
So let an AI translate Cobol to whatever, not to python, or bank transactions will take months.
But then suddenly we realize AI's are good for generating kitty-videos, but not for coding complex software.
AI can't code worth a dang. Yes, it can pull-up some examples from it's internet-based training, but other than that it consistently writes code that doesn't even compile.
And half will transfer any amount (or an array or any amount or a class of any amount) will go someone. Magically functions without any argument will still produce some output.
Thumbs up on that. Some company (I forget which, after 25+ years) used Lisp to analyze giant COBOL systems for Y2K issues and fix them. It wasn't "AI", because the point was determinism and explainability, not cleverness and pseudo-imagination. If there was any "AI" involved, it was symbolic logic to handle non-obvious cases, not some big plagiarism bot that says it once saw something like that the someone did for some reason.
When I was in college in the late 70's - early 80's COBOL was on the way out but it was still big. Everyone still took the courses on COBOL programming but even the instructors would say we likely would never program in COBOL. I think they'd be surprised to find out just how many apps written in it are still around and kicking. And I agree with the video that COBOL itself isn't that hard to learn it's all the environmental things you need to know to work with those old systems. If I never hear another word about JCL it'll be too soon. I never did write any COBOL code outside of school but I did have to work with JCL in setting up other applications.
The mention of FORTRAN reminded me that I took a course in IITRAN in high school in the spring of 1966. It really required being able to think through a program on paper. The finished program was written out and sent to a place where it was coded on to punch cards. Each week the program assignment built on the previous week's program. I remember getting the results back the next week saying "error on card 3." So, then I was trouble shooting the previous program while writing the current one. If I remember correctly, the whole series was a payroll program including names, times, deductions, etc. I really enjoyed it, including the trouble shooting. I didn't do anything with computing until the first Apple came out and someone showed me BASIC. I could not believe that I could get immediate feedback!
"Don't use a screwdriver to nail a nail to the wall, user a hammer". Same thing with COBOL. It is a transaction-oriented language. Of course it wasn't designed to do graphics, smartphone apps, or AI stuff. It was designed to handle millions and millions of transactions and records (And this it does very well).
People tend to demonise languages, and honestly I cannot see the point. If you know enough, create your own, if not just pick the one that best suits you.
At the end of the day, it’s only a tool that we have available, and there are many other tools in the toolbox. Each one is made for a purpose, and one thing I learned is that there is no point in me bitchin at the tool or whoever made it.
Cobol isn't that hard, but it has some quirks that you need to get familiar with.
I'm half tempted to skill up on COBOL, but the shops that do it seem quite closed. The problem is that the systems that rely upon COBOL aren't just the COBOL. They are the file formats and hardware and business processes that it is embedded in. It's difficult to rewrite a bit of it to a modern language, without rewriting all of it. Otherwise there would be a cottage industry of boutique consultancies doing piecewise ports of COBOL-based systems to microservices.
I graduated in 1969 with a degree in history. Yet during those college years I learned Fortran, SNOBOL, Penelope. That is how I made my College money. I ended up within Ma Bell, trained in BAL and COBOl in 1970. The business focus was capturing all the transactions in a business and filling those gorgeous databases.
Understanding and codifying the flows and stores of a business was done with COBOL. It was the tool we had. The pyramids were built with big blocks by processes we are still trying to understand.
We are still processing transactions and filling those wonderful databases. That language will be with us. Forever. 😇
My killer skill was JCL. Making a 155, a 165, a 195 all sing - what fun.
I started my career as a Cobol programmer.
If my memory still serve me well, COBOL is the first language that have native currency data type. Back then others language (Fortran) was for scientific. Floating point can't cut it when it come to money.
In college I studied Applied Computer Sciences. In my first year, back in 1997, we had a course on COBOL. During lectures and practical exercises, I didn't really understand it all. When the first exam approached I started studying. All of a sudden I had an epiphany and I understood it all. Like in comic books when a character has an idea a light bulb is drawn above its head💡, it was such a moment. I still remember it to this day, so special that it felt.
Another point that should have been made is that most COBOL programs are much lengthier than almost every other language. A ten thousand line program would probably be only 400 lines in a modern language. The exception would be programs which use database-related intrinsics. I remember a data sorting program that would have been hundreds of lines long but was only 30 or 40 lines in COBOL. It did have its strengths!
You call these things "issues" implying problems. I call it watching the evolution of programming languages.
Almost all of contemporary programming languages come from concepts established in FORTRAN (1957), LISP (1958), ALGOL (1958), COBOL (1959), Simula (1967) and Forth (1970).
Even C (1969) descends from ALGOL through B, BCPL and CPL.
And C is one of most important languages.
COBOL's big deals:
COBOL was designed to be readable by non-programmers, using English-like syntax for business applications.
COBOL introduced robust file handling capabilities, which influenced how later languages dealt with data storage and retrieval.
COBOL's precise decimal arithmetic for financial calculations was an important feature that influenced how other languages handle financial computations.
COBOL's structured approach to defining data, separating it from the procedure division, influenced how some later languages handle data declarations.
There are approximately 23 million professional developers worldwide (according to the IEEE survey). So, around 5-10% of all professional developers have some level of proficiency in COBOL. and this is old data from 2020.
For certain values. I can claim "some proficiency" in that with much effort I can modify an existing COBOL program to give me the output I need, but I wouldn't recommend that anybody hire me to maintain COBOL code.
The English language, is a subset of the COBOL reserved word list! My instructor used to say. IF, one can write English, using ALL of the rules for proper English, you ARE writing in COBOL.
Ich glaube, es sind mittlerweile 400 reservierte Wörter.
I think there are now 400 reserved words.
I started coding in 1980 and soon was a Cobol programmer. I've been coding every sense. I am now a consultant on a project to migrate off a legacy Cobol system. That said, I've had a very good career with it. 🙂
One thing missed in this discussion is that COBOL is designed for business. Other programming languages are designed for science. The difference is that in COBOL, if you want something like up to 1000 dollars, in COBOL you declare it as "PICTURE 999.99". There you go. You want to print a number with commas and three decimal points and a dollar sign? "PICTURE $999,999,999.999"
Look at "DECIMAL" type in SQL servers and notice it isn't integers or floats.
Also, all the non-portable stuff in COBOL was in one section: the environment division. You ported COBOL by modifying some lines there, and you didn't have to touch the rest. It held things like "which file is the 'payroll' file" and "where do you want the compiled code stored."
And the smart programmers abstracted this to use wrapper JCL to fix up @use names to map the real file system files to the logical files defined in the COBOL program.
Nonsense. Just look at what most businesses are using. It's not lame languages like Cobol.
That's an idea from a good 50 years ago, when your choices were COBOL or FORTRAN. The world has changed a lot in those years.
We've long had data structures in both the language, and the database that perfectly represent decimal values. BigDecimal in Java and Ruby. You're also not correct about the Decimal class in various DB backends:
Here's the documentation for Decimal and Numberic for MySQL for instance. Other DBs are similar:
13.1.3 Fixed-Point Types (Exact Value) - DECIMAL, NUMERIC
The DECIMAL and NUMERIC types store exact numeric data values. These types are used when it is important to preserve exact precision, for example with monetary data. In MySQL, NUMERIC is implemented as DECIMAL, so the following remarks about DECIMAL apply equally to NUMERIC.
@@stevesether Yes. We've long had things like Decimal types in languages after SQL incorporated decimal types and languages that interfaced to SQL needed to support them. When did Java add the Decimal type? Was it Java 1.0? NooooOOOoooo.
I'm not sure what you think I said wrong about the decimal classes in various DB backends. My point was that it's an important part of business code that languages tend not to support natively.
Also, FWIW, COBOL is OOP now. Bleh. :-) It's not like COBOL hasn't picked up modern capabilities either. I'm not advocating for using COBOL. I'm pointing out things that should be in your language if you want to use it for business: easy decimal types, and separating code from environment from optimization. These are all things SQL does, for example, which is why it's still widely in use 50 years later. (Along with having mathematical proofs that it's the right choice.)
@@darrennew8211 Your comment just appeared to me to be from someone who's repeating tropes from 50 years ago, and never bothered to update their knowledge base. "COBOL is for business, other languages are for science". I think I heard that 40 years ago. It wasn't even true then, and it's extremely un-true now.
It doesn't matter that Java didn't support BigDecimal in 1.0, since it's easy to add your own class that supports whatever math feature you want. Just create a Money class, and use that for money representation. It's a small amount of code. It should have been in the language from the get-go, but they did wind up adding it officially until 2006, almost 20 years ago.
As far as "optimization" goes, unless you're writing something a game, or some form of scientific computing, nobody uses FP numbers anymore. In my 30 year career the only time I've seen people use FP numbers in business code is when it's been a mistake. They didn't use it as an optimization, they used it because they had no idea that a FP number was imprecise.
As far as decimal, it really is integers in the back end. All it does is keep track of where the mantissa is. It may not look like an integer, but it is.
Wow I remember learning COBOL and PASCAL back in collage. I think had just finished learning punch cards just before they got phased out and C was getting popular.
I enjoyed your episode! I look forward to seeing more.
COBOL is not that bad. You just need to know it was made for a very dumb computer that does not know how to deal with decimals or alpha characters without you telling it what is coming and how to do it. And get familiar with subroutines..... lots and lots of subroutines. My Son is a programmer and could probably be fine with it in a few days. It is VERY helpful if the original programmer was thoughtful enough to make lots of comments.
I, now, code in Python. But, I started in COBOL out of school. Good language.
Which language hurt you with the commas?
But yes, COBOL was my first language for pay, and was tremendous fun.
haha just no
COBOL is also still being used in the airline industry. Not only the airlines themselves but the applications behind the scenes, too.
I became a COBOL programmer in 1975 thanks to IBM’s self-teaching manuals. Then I spent the next 20 years making a living at it. Difficult? No. Verbose? Yep. But its verbosity is one of its advantages. Well written structured COBOL should be self-documenting.
That reminds me IBM created an "AI" specifically trained to translate COBOL code to Java
I've seen it in use. The java code produced was slooooooooowwwwwwwww in comparison.
I know someone who has been coding cobol the last 40 years. Finding a job has never been an issue, especially now so much legacy code written in cobol.
When I got out of the Army in 2010, I went back to school at one of the local colleges and one of the courses I took was PHP. The course I was in was sort of special because the instructor was the guy who handled the PHP for the colleges websites. However he had retired the year before. They paid him a nice bonus to come back and teach a semester of PHP with his replacement in the class. This instructor was in his late 70s and apparently was in that meeting that developed COBOL.
This old guy was incredibly brilliant and probably forgot more programing languages than I could ever learn. Though it was very intimidating because I hadn't worked on HTML or CSS for over a decade by that point (I think it was the 90s when I last dabbled). Anyway in the first class he said that in the next two days (by the next class) we needed a five page website using HTML5.0, CSS with div tags, and the whole thing.
I raised my hand and asked, "When did HTML get a number?" He just chuckled at me and said I had quite a bit of research to do by Wednesday.
In the mid 80's I wrote a program using the REALIA COBOL compiler and the SCREENIO graphics add-on package running under DOS 3.0. It is still running on a daily basis in a production environment today.
Thank you Mrs. Hooper.
Die gute Admiralin der US-Navy hieß Grace HOPPER.
The good admiral of the US Navy was called Grace HOPPER.
COBOL is great. I miss the days when things were purpose-built for specific use cases, including programming languages. Seems like everything's just trying to be all things to all people now. Friends, not everything in life has to be a Swiss Army knife.