FORTRAN and COBOL Re-enter TIOBE's Ranking of Programming Language Popularity (i-programmer.info) 93
"The TIOBE Index sets out to reflect the relative popularity of computer languages," writes i-Programmer, "so it comes as something of a surprise to see two languages dating from the 1950's in this month's Top 20.
Having broken into the the Top 20 in April 2021 Fortran has continued to rise and has now risen to it's highest ever position at #10... The headline for this month's report by Paul Jansen on the TIOBE index is:
Fortran in the top 10, what is going on?
Jansen's explanation points to the fact that there are more than 1,000 hits on Amazon for "Fortran Programming" while languages such as Kotlin and Rust, barely hit 300 books for the same search query. He also explains that Fortran is still evolving with the new ISO Fortran 2023 definition published less than half a year ago....
The other legacy language that is on the rise in the TIOBE index is COBOL. We noticed it re-enter the Top 20 in January 2024 and, having dropped out in the interim, it is there again this month.
More details from TechRepublic: Along with Fortran holding on to its spot in the rankings, there were a few small changes in the top 10. Go gained 0.61 percentage points year over year, rising from tenth place in May 2023 to eighth this year. C++ rose slightly in popularity year over year, from fourth place to third, while Java (-3.53%) and Visual Basic (-1.8) fell.
Here's how TIOBE ranked the 10 most popular programming languages in May:
Fortran in the top 10, what is going on?
Jansen's explanation points to the fact that there are more than 1,000 hits on Amazon for "Fortran Programming" while languages such as Kotlin and Rust, barely hit 300 books for the same search query. He also explains that Fortran is still evolving with the new ISO Fortran 2023 definition published less than half a year ago....
The other legacy language that is on the rise in the TIOBE index is COBOL. We noticed it re-enter the Top 20 in January 2024 and, having dropped out in the interim, it is there again this month.
More details from TechRepublic: Along with Fortran holding on to its spot in the rankings, there were a few small changes in the top 10. Go gained 0.61 percentage points year over year, rising from tenth place in May 2023 to eighth this year. C++ rose slightly in popularity year over year, from fourth place to third, while Java (-3.53%) and Visual Basic (-1.8) fell.
Here's how TIOBE ranked the 10 most popular programming languages in May:
- Python
- C
- C++
- Java
- C#
- JavaScript
- Visual Basic
- Go
- SQL
- Fortran
On the rival PYPL ranking of programming language popularity, Fortran does not appear anywhere in the top 29.
A note on its page explains that "Worldwide, Python is the most popular language, Rust grew the most in the last 5 years (2.1%) and Java lost the most (-4.0%)." Here's how it ranks the 10 most popular programming languages for May:
- Python (28.98% share)
- Java (15.97% share)
- JavaScript (8.79%)
- C# (6.78% share)
- R (4.76% share)
- PHP (4.55% share)
- TypeScript (3.03% share)
- Swift (2.76% share)
- Rust (2.6% share)
Re:Nope (Score:5, Insightful)
Re: (Score:1)
"Until we can replace them" is useless. And I always find it hilarious when companies end up doing this because they are spending way more in the long run than if they just spent the money to update the damn system a long ass time ago when upgrading wouldn't have been so difficult. Every delay into upgrading off these systems increases the difficulty and cost of the upgrade, while also increasing its current maintenance costs.
Re: (Score:2)
Re:Nope (Score:5, Insightful)
Change for the sake of change is usually pointless for the customer. If I'm a customer, and what I'm paying you for works well for me, why should I reinvent my business process to satisfy you if you can't convince me I will have a real, relevant benefit?
Re: Nope (Score:4, Interesting)
Re: (Score:2)
"It may have its quirks, but people got around it." isn't a valid defense. And Rockstar, ironically, doesn't have rockstar programmers. In fact, their programmers are kinda bad on average.
Re: (Score:3)
Re: (Score:2)
This could become an endless thread.
Let's get started. C++ does not have any quirks. It's the programmers using it, who are to be blamed.
Soundbite reporting again (Score:2)
Let's just pretend to be a clickbait article writer:.
- Start with a preconceived conclusion
- Keep google searching until you find one or two examples holding your conclusion true
- Write a click bait article on it
Seriously, the question could be "What percent of the corporate Java programmers are only programming in Java because they are working on something sold by or related to IBM or Oracle?"
Re: (Score:2)
Same as Java.
And I guess C# and similar users, second and third that, too.
Learning the libraries instead of reinventing the wheel, is what is a bit challenging.
Re: (Score:3)
Oh gawd, had one new guy working on a legacy device; first task was just to add a small feature. He rewrote massive chunks of the code because he didn't like it. And I didn't catch him at this until he was mostly done, 33 commits in all, deadline looming (the days before code reviews were required before committing code). So I had to keep it. He didn't stick around long when there was a batch of layoffs. Leaving me to deal with code that I no longer recognized.
The same guy on the second project he was
Re: (Score:2)
No one ever mentioned changing for change's sake, nor is it related to what I'm talking about. Whether it be for security, reliability, speed, or whatever. Staying frozen for 40+ years on the same software version is never a good thing to do.
Note: the only exception is for weird, or high specialized, hardware with embedded software.
Re: (Score:2)
If a change breaks the business process of the customer, as the OP said, that's change for the sake of change.
Re: (Score:2)
That's all fine and dandy, but no one has suggested any kind of change for change's sake or change that breaks their processes. Do those kinds of upgrades happen? Yes. Do they always happen when upgrading? No. And if a legit upgrade to something like security or reliability breaks your processes, then your processes were shit to begin with and deserve to be broken.
Re: (Score:2)
And if a legit upgrade to something like security or reliability breaks your processes, then your processes were shit to begin with and deserve to be broken.
No, buddy, if you fuck up your customers because you wrote a piece of shit that was insecure to the point that you must break your interfaces to "fix" it, then you're an incompetent idiot who has no business writing software for customers.
But we knew that one already.
Re: (Score:2)
New, sometimes very specific, vulnerabilities pop up that you couldn't possibly have accounted for. If the absolute only fix means your process has to change, tough fucking luck. Deal with it. Your processes aren't some holy things that can't be touched.
Re:Nope (Score:5, Insightful)
Re: (Score:2)
Understanding WHAT it does is the easy part.
Re: Nope (Score:3)
It's remarkably difficult to get a software house to create a replacement. They always insist on making something new.
Re: (Score:2)
These programs are vastly expensive. Every year they must be modified to be updated to new laws, regulations, and tax structures. When I was at a defense contractor in the 80s before the era where every payroll system in America used ADP, the payroll systems were programmed in-house. And it was a somewhat large team that was always busy.
Updating to a new language is difficult. Updating to a new standard of a language is also difficult (I remember a 2 year stint to upgrade C++ compilers at one company).
Re: (Score:2)
Not a valid excuse.
Re: Nope (Score:1)
The replacing will happen when you can't get hardware able to run Cobol. Then panic will start.
Re: Nope (Score:4, Informative)
Every hardware "can run COBOL". ... emulation obviously does not have the speed of a Mainframe that can run several thousand PC VMs/emulations simultaniously.
COBOL is compiled to machine code, just like any other language.
And there are Emulators that can emulate a Mainframe on a PC
Re: (Score:2)
The replacing will happen when you can't get hardware able to run Cobol. Then panic will start.
Rest assured that this will never, ever, happen, while there are computers on planet Earth. Same for FORTRAN. You might eventually need to use an emulator, but it will do the job.
Re: (Score:2)
Why would you need to emulate languages that have excellent compilers on a bunch of current hardware platforms?
Re: (Score:2)
There is no need to, right now, or in foreseeable future. But I wrote "never ever" and I'm not absolutely sure that computers from, say, 50 years in the future will adhere to the architecture principles of today.
Re: (Score:3)
Except that COBOL doesn't need specialized hardware and there are open source compilers for it. Ie, it runs on a PC, PC servers, Raspberry PI, mainframes, midrange business computers, probably even smart watches.
Re: (Score:2)
So, sunk cost then?
Re: (Score:3)
The financial world runs on "antique" software. Banks don't like to lose money so they keep using decades old code for a reason, it works. It's well understood and vetted. Sure move it all to python, what could possibly go wrong?
Re: (Score:1)
Banks migrated to PowerBuilder for the Y2K preparations 25+ years ago. They aren't actually running even older code on any kind of mainframe for modern business functions
Nope (Score:2)
PowerBuilder is middleware. Banks use mainframes as giant transaction engines, with some time-sensitive data handling (calculate daily interest payments for every account in the system ASAP.) I think early versions had a rudimentary database engine, but no bank is going to run their business on that.
Re:Nope (Score:5, Interesting)
None of the big banks run their transactions through anything other than mainframe. All of those transaction applications are written in COBOL. Every credit card transaction is running through a similar setup.
Of course they aren't running those on some mainframe from 1963 either. They are running that on a fairly modern well supported zSeries (likely a bunch of them running in geo lockstep, but whatever.)
Also this idea that the code isn't modern or something is also a big lie. The applications are running on modern COBOL. Possibly a bit of a combination of Java and COBOL. Definitely all the code will be up to COBOL 85, but likely much of it updated to COBOL 2014.
Not a COBOL programmer, but I interface with these guys and their systems a LOT. I also see that their team includes all age groups intern up through "should have retired."
Re: (Score:2)
My first job back in about 2000 was interfacing a Java system to a COBOL database. Not a bank, but another big organisation where data integrity was overwhelmingly important and migration seen as unpalatably risky. New applications were being written in Java but the underlying system was very much staying in COBOL and I don't expect it has changed.
TRWTF for me is that Visual Basic is still a programming top 10.
Re: (Score:2)
I had a few misspent years in the enterprise software world (soul crushing). One of the clients was Chase Manhattan bank. I visited them once for some issue, and walked through their server room. Big machines stretching into the distance. Each with several big and glowing red buttons, all of them daring me to press them...
https://youtu.be/XY5EZi2Qwyw?t... [youtu.be]
Re: (Score:2)
Remember, even Microsoft in it's ineptitude couldn't do calculations correctly in their calculator app. We shan't mention Excel here lest it trigger someone obsessed with accuracy.
Re: (Score:2)
The reality is, the banks don't actually know if the code works, or how it works. I've seen this in the mortgage industry, where nobody knows how the code spits out what it does, so nobody wants to touch it. And the business doesn't know what it _should_ do, so they just assume it works until it does something egregiously wrong. The truth is that legacy bank code fails *all the time* but they don't want to pay to fix it.
Any language, including Python and COBOL, can be used to write solid code. But that can
Re: (Score:2)
For all of its faults, it got the job done and produced software that outliv
Re: (Score:2)
Appears there's no shortage of extensions at least for code studio :)
https://marketplace.visualstud... [visualstudio.com]
Re: (Score:3)
I don't really get why the COBOL talent pool is such a big factor. In every other part of the software world, I expect people to pick up languages as and when they need them. My only COBOL experience is more than 20 years old, interfacing a Java system to a COBOL database, but I don't remember it being particularly challenging. If there's so much money in it, why aren't people picking it up? I guess it's not sexy work, but I'll do surprisingly un-sexy work for enough money.
The Un-prostitute (Score:2)
If you pay me, I will perform un-sex acts.
Re: (Score:2)
The problem is that your application for a job usually goes through an HR department.
I applied for a job that required Smaltalk. I only fool around with it, as I have no real idea for a new hobby project.
HR department did not even forward my application for the job to the relevant people.
A "real programmer" can learn a new language in a day. COBOL might need 3 days, because of its esoteric data structures.
Re: (Score:2)
Okay, so if I'm ever in a position to hire you, I won't. You don't like all that "typing"? Really? So, you prefer to write code that can be entered in the Obfuscated C contest? And utter hell to maintain or enhance?
And if it works - say, a mortgage company (worked at one, once, *shudder*) - why do you need to rewrite it?
Re: (Score:2)
We're in agreement then, I don't want to work for you either! Thankfully, there are plenty of jobs that involve using modern languages and technologies.
Sure, COBOL can do the job. A horse-drawn plow can plow a field. But given a choice, most farmers will choose modern equipment because they are far more efficient.
If a language requires more typing to implement a unit of functionality, that makes the language less efficient to use as a coding language. Efficiency is an important factor in creating good code
Re: (Score:2)
Well, it's a specialized language for specialized purposes. Most popular programming languages are general purpose (C, Java, Python, etc), or for popular purposes like the web (SQL, JavaScript). COBOL and Fortran are specialized; for business or scientific computing. The CPU under the hood may be general pupose or specialized. The advantage of COBOL was part of its original design - managers who aren't programmers can read it and review on it, thus it is verbose.
It has some interesting features. You can
Non-programmer managers (Score:2)
Managers who aren't programmers can read and review COBOL?
Heck, programmers who aren't managers cannot even do that.
Re: (Score:2)
There was a saying once.
I do not recall which computer scientist coined it. But it was like: "
Program code is read 100 times more often than it is written."
So reading code that is close to a natural language does not bother me at all. ,,, typing code is trivial.
And with modern IDEs
Of course there's another possibility (Score:4, Insightful)
And that is that TIOBE and its brethren don't actually measure or tell us anything particularly useful. But I don't expect Jansen to give voice to that.
Re:Of course there's another possibility (Score:5, Interesting)
Maybe they hint at something useful, anyway.
How to interpret those two numbers, of course, likely depends on the language. Swift, for example, is being learned by a lot of newbies because folks are replacing Objective-C code with Swift code, and people are being kind of forced to learn it, which pushes it artificially higher on PYPL, and pushes Objective-C artificially lower. The same is probably true for Typescript, which is #7 on PYPL and #50 on TIOBE.
In other cases, it's a hint that the language is popular among non-programmers. R is #5 on PYPL, #24 on TIOBE. It is mostly used by people for whom programming is a means to an end, rather than their primary job responsibility, e.g. people working in biotech and other non-software firms, so those jobs show up as "bioinformatics engineer" rather than "R engineer".
In still other cases, it's a hint that way more people want to learn the language than can actually get jobs using it, because programmers think it's neat, but not very many companies actually want to pay people to use it. Rust immediately springs to mind.
So I guess they try to tell us something, but it's hard to tell what they're saying without lots of additional context, so folks are unlikely to actually agree with one another about how to interpret them.
What perfectionists don't understand (Score:3, Funny)
In the land of F's, D is king.
Re: (Score:2)
Why is there a TIOBE post only once a month?
They should switch to a weekly story.
More TIOBE! (Score:2)
You, compiling the TIOBE rankings, I want you to explore the space of the office and give me more TIOBE.
As they (at least FORTRAN) should (Score:5, Informative)
There's nothing better than FORTRAN for computations involving large matrices, the libraries it has are excellent and well-tested, and the newer versions provide you with any facility you find in a "modern" language. And it is FAST, so fast that your numpies cry out of envy.
COBOL, well, I don't like it, but I may be biased.
Re: (Score:3)
FORTRAN really works well and lots of new code it still written in it. It really *is* the language of technical computing and very good at it.
COBOL, on the other hand, exists solely due to maintaining legacy code, nearly no one is starting new projects or writing new code in COBOL.
Re: (Score:2)
All I've ever heard done in COBOL was "legacy code maintenance" and that was in the early 90s. The bastard is a tough little motherfucker, I'll die before it is fully dead :)
Re: (Score:2)
Yes, there is so much of it and modern techniques and languages are so poorly suited to the sorts of thing COBOL is good at, it's going to be a very long time before it goes away completely.
I used to know something about it 45+ years ago, but I doubt I could do anything useful now.
Re: As they (at least FORTRAN) should (Score:2)
Re: (Score:2)
If you are in a company that has lots of legacy COBOL, and programmers that can do it: you obviously write in COBOL.
A green hill project, where you not even have a team for, but two or three lead designers or lead architects, you might be able to chose a different language.
I would always go with the language the people are accustomed, too.
Does not make any sense to introduce C#, Python, Java in a team that is hard core main frame COBOL.
Re: As they (at least FORTRAN) should (Score:3)
Don't forget that modern Fortran also is quite good at handling multithreading and is able to do that with large matrices 'under the cover' with no or little effort from the programmer.
Not every compiler, but enough of them.
Add to it that modern Fortran is easy to understand and write as well as making it a lot harder to write code that has security flaws like 'use after free' cases and similar compared to C.
Re: (Score:1)
Don't forget that modern Fortran also is quite good at handling multithreading and is able to do that with large matrices 'under the cover' with no or little effort from the programmer.
Not every compiler, but enough of them.
Add to it that modern Fortran is easy to understand and write as well as making it a lot harder to write code that has security flaws like 'use after free' cases and similar compared to C.
During the last 35 years, about 80% of my work is for clients who want Fortran source code. :)
So many happy memories.
/** barf [ba:rf] 2. "He suggested using FORTRAN, and everybody barfed."
- From The Shogakukan DICTIONARY OF NEW ENGLISH (Second edition) */
Re: (Score:2, Informative)
Python has all of that. Why would I use Fortran?
Last time I was working in Fortran, all the numerical code was provided by a library that was written in C (netlib / lapack). Has that changed significantly?
The last time I saw someone touting the world-beating performance of Fortran, they had a site full of metrics to back it up - except that the site had been updated since they last looked and these days GCC compiling C beats every Fortran compiler on every benchmark by a pretty handy margin, up to an orde
Re: (Score:2)
- AFAICT Maxwell's equations have not changed since 1970, so the code written to solve them will not have changed either.
The US Navy code for managing statistical data, which was originally written in the 1960's for an IBM 360
which I ported to a CDC7600 in 1973 - was still in use in 2013 on a Cray. Its probably still in use - but on a completely different architecture.
No need to rewrite the code -
Re: (Score:2)
Old programmers, never die, too.
They just branch to a different address.
COBOL is nearly immortal (Score:4, Informative)
When I was in school 30 years ago, they offered a non-credit course in COBOL so we could find work between semesters. Non-credit because it was already 'dead'. I am not surprised to find you can still find a need for COBOL programming skills.
Re: (Score:1)
A Year 10,000 joke.
A crypt is opened and the person is revived. "I guess you are wondering why we brought you back. So it says on your LinkedIn profile that you know COBOL...."
Re: (Score:2, Troll)
Re: (Score:2)
Re: (Score:2)
I agree on the point of like it. But javascript have use cases where the backend could do it, but where a javascript function can make it much more userfriendly.
javascript is a ***** to error check, that's why this instance doesn't like it.
Fortran is a language of the 2020s (Score:5, Insightful)
It isn't any more accurate to call Fortran a "language of the 50s" than it is to call C a "language of the 70s". As others have noted, Fortran has evolved significantly over the years, with the most recent revision, Fortran 2023, published just six months ago. It is still a very popular language in engineering and scientific applications.
Re: (Score:3)
If anything, Fortran has a head start. It's had native matrix and vector types/operations, with compilers that map these to SIMD instructions and even parallel processes, since the 90s. Meanwhile, other major languages were looping the loops like it was the PDP-11, with fancy compilers possibly allowing vectorization via extra directives. Fortran was written by scientists for scientists; nature doesn't loop over dimensions when adding velocities — why should the programmer split a vector operation in
Programming on cards is back in style (Score:1)
How else to explain both Fortran and Python on the same list. Pretty sure cobol also had an 80 column limit at some point.
Next python feature: all-caps only and no mathematical operators beyond the basic four. Comparisons to be expressed with .gt. and string comparison with .eq.
Re:Programming on cards is back in style (Score:4, Informative)
Fortran has had a free-form dialect since before you were born, dear.
Re: Programming on cards is back in style (Score:4, Insightful)
The day Python is compiled and not interpreted so that all dependencies are verified before execution that's the day Python becomes good.
Until then Python asserts many of the flaws interpreting Basic had in the 80's.
Spoken with .true. ignorance (Score:2)
How is VBasic on the list and not Perl or bash? (Score:3, Insightful)
Re: (Score:3)
"Internet", Kids these days! A 5-digit U.Id. and your lack of experience is showing. Visual Basic is the closest that general-purpose software has come to drag-n-drop programming: Think of making vector images through a SVG-language text-editor versus through a GUI like Inkscape. That's what Visual Basic did for MS Windows runtime-environment programming.
Just like the other new-kids-on-the-block; CoBOL, ForTran and C, there will be a lot of legacy code.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
MS Excel macros.
The PYPL table has a copy/paste error, forgot C++ (Score:4, Informative)
The PYPL table (2nd one) was copied incorrectly and dropped C++ at 5 (That's why the table ends at #9).
Re: (Score:1)
It is wrong in the first place, as it has "julia" (which is, ostensibly, a FORTRAN replacement that nobody I've heard of uses), but no FORTRAN in the first 30 spots.
Good, but (Score:4, Funny)
Algol 60 and RPG II , when?
Re: Good, but (Score:2)
Rust is still trying to add the features from ALGOL 68.
The Trollbie Index (Score:1)
I'm going to create a popular language called TOIBE just to bleep with the TIOBE index readers.
hammer/nail (Score:2)
I don't understand whoever is saying cobol "is a lot of typing". What?
You "type less" in Python? Not from what I've seen. "Typing" is the wrong metric to analyze...
COBOL is for record processing
it is fit for that purpose.
Re: (Score:2)
Yeah, in one very long definition.
I, on the other hand, left behind at a number of jobs "PERFORM 1000-DUMMY-PARAGRAPH THROUGH 1000-DUMMY-PARAGRAPH-EXIT WHILE (do all the work here).