Survey: Programming Language Mentions on Various Sites + Average Salaries (When Available)

For a very imperfect survey of programming languages, went to www.ziprecruiter.com and checked the number of programming language "mentions" in the job listings for various programming languages. These results are very imperfect because the search engine on Zip will match any programming language ( "xyx programmer"), for example, when it is called out in the job description, but it's not actually the job title or main requirement.

Even as very imperfect as this survey is, the results are interesting. I did notice if I run this Zip search for the same language, the results quickly vary (but they remain in the same general ball park):

Mentions and Average Salary on Zip Recruiter

Ordered by Mentions, Descending

I think I will do this for a few different online job sites.

What you you think? Do you have a job search index we should check in a similar way?

Should we try doing this same approach on LinkedIn?

Noticed that if I search for a programming language on LinkedIn, if there are few listings for that language, it will bring up search results which do not even have the search term anywhere in the job listing, so I think using LinkedIn for a similar survey is not useful.

Any other website suggestions to create a similar survey?

Survey Reference:

Of course, we all realize that this is an unscientific, imperfect survey method. However, it does give some general ideas.

For comparison, here is a similar imperfect survey, search on Dice for US jobs:

Mentions and Average Salary on Dice

Ordered by Mentions, Descending

Reference:

Of course, we all realize that this is an unscientific, imperfect survey method. However, it does give some general ideas.

Well, the usual UK sites are:

https://findajob.dwp.gov.uk/ (Government run website)

https://uk.indeed.com/ (Independent recruiter)

https://www.totaljobs.com/ (Independent recruiter)

https://www.jobs.ac.uk/ (Academic network website)

What I find really interesting is that searching the academic (University/College) network for Python finds plenty of jobs, but searching for Ruby on Rails finds none!!! Well, no surprise there I guess!!! What??

Obviously, be aware that some jobs will appear on multiple sites.

Hi @hicksd8

When searching for Ruby On Rails you should only search for “Ruby” as few sites use the term “Ruby on Rails”. They are looking for Ruby developers / programmers.

Also, Indeed is a terrible site to perform a survey like this. Indeed is not specific to tech or programming so if you search for “Rust” you will get industrial listings totally unrelated to computer science and there is no way (that I could find) to filter out the noise.

I know this because I tried to search Indeed yesterday and got so much noise in the results it was basically useless since Indeed is not tech nor computer science specific.

I guess the "bottom line" is that many sites are not very suitable to perform a survey like this due to how their search engine works (or does not work). So far, both Indeed and LinkedIn are not suitable for this kind of survey, I have found.

LinkedIn returns totally irrelevant results (just to provide results) and Indeed is a close second with very noisy results.

Update: When I searched for Ruby at https://www.jobs.ac.uk/ the mentions I saw were from recruiter named "Ruby", haha. When I dug deeper into that site and tech listings a bit deep, I was shocked to see how low the salaries were for academic-related tech jobs.

And of course, the IEEE does a ranking which is an amalgam of eight sources: https://spectrum.ieee.org/top-programming-languages/

The IEEE ranking is cool because we can customize based on how we want to weight various sources, for example, I think GitHub should be weighted higher and Google searches and trends less, so I tried this:

Screen Shot 2021-10-31 at 12.52.28 PM752×684 63.6 KB

although I didn't really want to, I'll come back to our discussion about Fortran. Even if this may actually not be the right thread.

I don't find it particularly meaningful where Fortran is in any index. The initial point was about suitable languages, not popular ones - that's a small but subtle difference. Furthermore, that Fortran is mainly used in scientific computing. Whereby used is meant in the sense of running in production. Scientific coumputing isn't really popular.

Here is a fairly informative article from the Technical University Wien (Austria), especially the last paragraph. Unfortunately it is in german, but meanwhile google can translate pretty well. And it's from 2011, quite a long time ago in IT, but the article also looks to the future.

Facts about Fortran are:

• It is still used in various (supercomputing) areas such as climate modeling, fluid mechanics, astrophysics etc., i.e. mainly numerical mathematics.
• It is still used together with C/C++ for CPU benchmarks (https://www.spec.org/hpc2021).
• It is still taught at many universities.
• The current standard is of 2018.

So Fortran is far from being dead. For new software it will maybe be used less and less, but I don't know that, I haven't investigated that further. For older productive code, however, the use of porting to other, 'more popular' languages ​​should not be in any economic, and certainly not more efficient, in relation to the expenditure. In this case, reengineering into a new standard is likely to be the better alternative, at least that's my point of view.

Compared to high-level languages ​​like C++ or Python, Fortran has a smaller feature set. It was designed for scientists and engineers, not for software developers. Since 2003 it has the ability to interoperate with C/C++ code.

Incidentally, more than 25 years ago, I programmed in Fortran 90 at the institute for fluid mechanics at the Leibniz University of Hannover for several years as Scientific Assistant. Sure, that was a long time ago, but it should only show that I'm not a novice in scientific computing.

I'm mssising scientific language types in the IEEE index btw. That type doesn't fit in any of the selectable choices imho, probably because it isn't popular enough.

This doesn't surprise me at all. (Don't get me going on this; I'm at risk of going off topic now.)

I worked in academia many years ago (1982-86) as a Systems Manager and had to leave due to low salary. I joined an I.T. Consultancy in the real world. To start with, "Re-organisation gives the illusion of progress" describes this environment very well. We used to sway between "each faculty should have it's own computing service" and "computing service should be centralized as it's more efficient" about every 3 years. Secondly, the computing service were the plebs of the academics many of whom were nutters who spent money and deployed human resouces on pet projects. Even many years later I've heard of professors launching 3-year studies into the aerodynamics of the toboggan, and another study into whether ducks actually do like water or not. WTF? When money is being spent like that they cannot afford to pay computing staff decent salaries.

I'll say no more. Let's get back on topic!!

I agree that this is not a topic about academic computing and what goes on in educational institutions.

Further to that point, since I have never drawn a penny salary or contractors pay from any academic organization directly, my experience is in computing is commercial (and some in government) not academic. The exception to this was computing as taught in school or used in educational institutions as a student. However, since I was an engineering student and not a computer science student, my path was told that the engineering side of the house.

The closest I ever came to "academic computing" was working for the National Science Foundation in the Washington, DC metro area for a short contract ages ago. I recall not liking working for that organization, and will avoid commenting on why since it was a long time ago and I would need to review my CV to remember the projects I worked on there!

In a prior life I did some consulting for an oil exploration company. They had Fortran systems used to do the number crunching related to the search for oil. (It’s a fascinating process. You dig a hole and drop a small bomb down it, measuring the seismic readings in strategic areas around the hole. Then you pump water down the hole and do the same thing again. Since water isn’t compressible, the seismic readings — combined with other data — can give an estimate of the amount of oil. I’m obviously simplifying, but as I said, it was fascinating to hear about.) I wouldn’t consider this “scientific” so much as “industrial” research. Still, Fortran certainly isn’t common today.

Regarding the IEEE list, my main disappointment is that it doesn’t include salary data. I typically go to the StackOverflow annual developer survey for that. Yes, the data is self-reported, and yes, there are pros and cons to that approach, but the SO survey is one of the largest that I know of.

My observation is that since college graduates are now taught Python much more than Fortran, is that the majority of programs which might have been written in Fortran years ago, are now written in Python by the "current generation", since Python has a strong scientific computing library, and Python is used heavily in AI, robotics and machine learning (these days).

My guess is there is a lot of legacy Fortran code which of course will not be written in Python just for the sake of rewriting code; because it is always a tough decision to migrate legacy code and to justify the expense.

As I mentioned in an earlier post, I do not know a single person who makes a penny in 2021 writing Fortran code commercially. This does not mean that no one makes a living writing Fortran code; in 2021; but I do not know a single person who does.

However, I know a lot of people who write code in C/C++, Python, Ruby, Javascript, etc; and the PhD students I know and sometimes mentor all use Python these days for their AI, robotics and machine learning projects.

Of course oil-and-gas exploration has a lot of legacy code, including Fortran, since the oil-and-gas industry is very old (very long-in-the-tooth) and therefore has significant prior investments in software (legacy code).

I'm a bit confused as to why this topic is focused on Fortran. Just because I mentioned earlier (in another post) than I do not know a single person who makes a living programming in Fortran in 2021, does not mean we should have a jihad over programming languages and their popularity

For example, I love to program in Ruby and do not like Python very much. That is my personal preference. If someone else loves Python, that is all that matters. My opinion on loving Ruby has little to do with others. A friend of mine is finishing up his PhD in computer science and he must program in Python (according to his professor) and he does not like it at all; but he has zero choice in the matter!

On the other hand, I have a choice so I program in the language I enjoy (Ruby) and turn down projects which I do not enjoy. Recently I turned down a "D Programming" project in Singapore (remote) because I did not like the project even though the company said "name your price". There was no price I wanted for the projects they were doing.

Not everyone has a choice like I do.

Of course oil-and-gas exploration has a lot of legacy code, including Fortran, since the oil-and-gas industry is very old (very long-in-the-tooth) and therefore has significant prior investments in software (legacy code).

Since the topic included salaries in the survey, and since the IEEE survey link I posted didn’t include salaries, and because Fortran happened to be mentioned in the last post I’d read, I decided to point out that languages that seem to be old or “dead” are still in use in some fields. The benefit is that knowledge of those languages can allow for salaries that are significantly higher than an average might show. Sort of like the salaries paid to COBOL programmers during the Y2K panic of the late 90’s.

I'm a bit confused as to why this topic is focused on Fortran.

Meh. I think it was just representative of an older, more entrenched language (read: “legacy”). But we’ve veered way off of “surveys of languages and salaries paid”, definitely. (Not necessarily a bad thing, as the list of surveys was fairly comprehensive already. Now we’re just chatting.)

I have no idea, to be honest, where the term "dead language" comes from. Being "unpopular" or "not trendy" is not "dead" (like dinosaurs, who are dead, but we have birds now, who are direct descendants of dinosaurs).

Programming languages may be old, legacy , very unpopular, not trendy, but generally not "dead" in my view.

I think many people forget that a lot of code has been written over the years and much of this working code was written in a legacy or not popular language (today). This language is not "dead" because the language is still in use (even if the organization wishes it was different).

Many organizations which have been around for a long time run code written decades ago and they are reluctant to pay good money to port working legacy code to something more popular. CFOs do not shout out with glee, "YAY, let's spend a small fortune to port all that code we paid for a decade or two ago to Python because Python leads in 2021!!".

As a real example, for the past year, I have taken a huge legacy accounting application written in AWK, with oddly formatted flat files as the "database" (and countless rounding errors in the math) and ported it to an SQL driven, Ruby (Rails) app which the users can access via a browser (not a terminal in a back room).

The legacy AWK application had been developed over decades and the management actually hated it (they hated it..... really) and there was a very confrontational relationship between the long-time developer (who had been around for decades) and the users. The users had to fight tooth-and-nail to get new features because the code did all the I/O as did legacy apps "way back when". So, adding new features was really difficult and caused tremendous organizational stress. We ported the app to Rails and it is now fully operational in production and everyone loves it. Now, they brainstorm new features and we can add them in a few hours or less with no stress. It has gone from "an app which everyone but the developer hated" to one which "everyone likes, including the developer".

My main point is that there are countless software applications running in organizations globally which are using code which is suboptimal in 2021 for many reasons. Of course, COBOL or Fortran or LISP or Basic (just tossing up names in a pseudo random way) programmers from the past love keeping these applications going (and charging top dollar to do so, if they can), because they are not recent college graduates who want to program in Python or Java or Javascript, Rust, Go, etc. The fact is that, in many cases, these organizations are "held hostage" by legacy IT. I just witnessed this directly, so I am not talking about theory. It not something I read about online or googled. I am talking about a fact ; and also the joy of "freeing a good organization from being held hostage to legacy IT only a developer from the 1970s and 80s could love".

If an organization has been around for decades and has a business model built around this kind of legacy code, it is very hard for them to budget the hundreds of thousands of dollars to port legacy code. It is hard for them to find expertise to help. Also, given the fact that a large percentage of IT (code) migration projects fail, it is natural that organizations are both stuck and somewhat "held hostage" based on legacy code written decades ago.

That is why I find it amusing with, in some related discussions, folks reply "well, some people still use XYZ"....For me, that is really pointless relative to the popularity of certain languages and required development speed and flexibility possible in 2021. Myriad organizations use a lot of code which, if they had to start coding the same apps today, they would do it very differently.

I remember looking at the AWK code of this huge application back in early 2020 and the first thing I noticed was it was very hard to extract the business logic in the code. This was because most of the code was keyboard and screen IO plus file management (for the flat files used as a DB). In modern MVC apps, this IO is done for the developer and there is no need for developers to waste any time coding it. We spend time (and the money of the organization) on the core business logic, not wasting money on developing screen and keyboard IO and putzing around with disk IO or screen IO.

Sure, many people love coding screen and keyboard IO, LOL. But organizations in 2021 are not going to be happy paying for this. They want features quickly and very nice user experiences with a responsive web browser they can access on their phone, tablet or desktop, from anywhere in the world, for the most part.

Anyway, I digress. The bottom line, at least in my cobweb filled mind, is that we should develop code with the future of the organization in mind. Most organizations have young people coming up, either the children of family owned businesses or maybe college grads for more commercial-oriented companies. These people do not want to code with legacy tools and programming languages. They want to code in languages which are current in 2021 and fit into an MVC framework (or a similar HLA) where they do not give a second thought to IO, and focus on the business models, the business logic and adding new capability for the demanding, sophisticated end users of today.

I am not making this up. I just spent a year of my life, coming out of retirement, helping out one such good organization who was "held hostage" due to this exact same "legacy IT" issue; and so that is why I am keen to mention it here.

Of course there are many languages still in use out there in the world. Many of them are just relics of the past and if those same apps were being developed today, they would be developed very different and with different programming languages than those from the 1970s, 80s and even then 1990s.

However, it is truly remarkable that C and C++ still remain at the top of the tree in all surveys and have survived the test of time. So, not all older languages are "legacy" as we see with C/C++. My guess is that C/C++ will be around for a long time while other legacy languages are retired, one migration at a time.

Yes, I agree @Azhrei , we are now "just chatting" and sharing our experiences and ideas. Nothing wrong with that since we have a pretty good lay-of-the-land of the popularity of programming languages in 2021.

Back to you!

For comparison, here is a similar imperfect survey, search on GitHub for repo languages. Here, I searched for the language as a keyword and then looked at the results by repo language (not mentions).

Search for Repos by Language Feature:

Screen Shot 2021-11-02 at 12.01.14 PM911×174 26.6 KB

Languages marked with * were not available as a GitHub language classification and so those results are "mentions" and are included only because the others imperfect surveys had this language. Any results marked * are very inaccurate (mentions, not repo languages) and probably should be ignored.

GitHub Programming Languages by Repos

Ordered by Main Language of Repos, Descending

Reference:

Of course, we all realize that this is an unscientific, imperfect survey method. However, it does give some general ideas.

Also, searching one language repeatedly often returns different results but the results are relatively close.

My definition of “dead” doesn’t jive with yours. I consider a language to be dead if no significant development is taking place using it, especially if there was such development in the past.

I consider BLISS, SNOBOL, and CORAL to be dead languages, for example, even though I’ve written code in each of them (way back in the day!). Some languages live on only in certain environments such as ADA and Modula. I generally don’t work in those environments so I don’t have input on their vibrancy in the overall market. So they are “dead to me”, so to speak.

this has a bunch of highlevel data vis IT staff in some 'key' european locations , pg 15 onwards
Salary_Report_EU-EN_2021_talent.io.pdf (949.8 KB)

Very interesting — thank you for posting!

I'm not surprised in the least by the prevalence of React as a front-end technology, but I'm a little surprised at PHP for the backend (it's kind of a sloppy language, even with the changes in v7 and v8), and even more surprised that Redux was mentioned as a front end technology (as it's essentially a client-side state machine management framework, I'm surprised it was something that employers were specifically looking for to such a degree that it beat out other candidates).

I was impressed to see the daily freelance rates being as high as they were. That bodes well for the freelance market in Europe.

This survey is tied to web development so it's only a small part of a much larger industry, but every piece contributes to the whole.

Where is this perspective coming from?

The reason I ask is that my perspective is coming from a software developers perspective who specializes in business / enterprise transformation.

In software development, we consider code as "dead" only when the code is unused. For example, let's say we had a method called foo and we needed to modify that method. We copied foo to bar and we modified foo to debug and test new features. Later on, after foo was working, bar becomes "dead code" and we schedule this dead code for deletion.

Working code which has been tested and requires no modification and may never change, unless a bug needs to be addressed, is simply "running code" or "working code" or "code". Whatever we call this working code, the fact that is not changing or evolving does not make it "dead".

So, in my mind, from this software developer's perspective, just because a programming language is not changing, evolving, nor being upgraded does not make it "dead".

Hence, we obviously disagree @Azhrei, but why? What software tasks do you do on daily basic regarding coding which creates your perspective?

Thanks. That report is a good addition to our surveys, without a doubt. Thanks for sharing.

Hmmm. This reply is confusing, at least to me. All web developers with experience know that PHP is behind much of the world's server-side tech (like-it-or-not). WordPress and countless other web frameworks used by millions are all PHP based. Commenting on PHP "being kinda sloppy" is tangential to what back-end languages are used in server-side computing.

Candidly speaking, I have over 15 years programming experience in PHP server-side coding, off the top of my head, and my opinion on PHP has little-to-nothing to do with the fact that many web apps are written in PHP. That's just a fact of life. My feeling toward PHP (I am not a huge PHP fan and basically stopped coding in PHP around one-and-a-half years ago in favor of Ruby) if not relevant toward it's popularity as a back-end programming language.

Agree we seem to disagree, based on perspective. You casually say " web development so it's only a small part of a much larger industry", stating directly that web-development is some small fraction of the software development industry in 2021.

I think this is an older perspective which hails from the past where "web development" was basically an HTML task with some JS here-than-there. Back in those days, there were "web masters" and that was a kind of derogatory term for those who wrote HTML.

The world has evolved long past that perspective, and most all businesses create software applications which have enterprise software on the server side, like databases and most of their business logic. They expose that data to their enterprise as an enterprise service via APIs. This is "back end" (web) development and I think most enterprise software is written in this manner in these days, not "a small amount compared to the whole".

Even when I was helping businesses transform to the web way back 20 years ago, every enterprise was asking "how do we expose our data" in a (pardon the buzz words), "software as a service" or SAAS model. This model, I believe, is the dominate software development HLA in 2021, if I am not mistaken (did not make a survey, but did some quick googl'ing )

In other words, it was considered a poor practice as far back as 15 to 20 years ago to build enterprise apps which did not expose data via "the web", which really meant "an API" because "the web" meant only that it was exposed via an URI/URL and had little to do with exposing data to the public.

The same is true with the business transformation project I just recently completed (now in production) for an enterprise accounting system. The back-end software is an SQL database which defines the business "models" and there is significant business logic directly correlated to those models. However, the majority of business logic is in the "controllers" which takes user input and arbitrates between the data, executes the required logic, and prepares the results for presentation. Normally, the "preparation" these days is to serialize the results as a JSON object and present that data to the presentation or "view" logic. The "front-end" developers may write complex business logic that execute in a browser (or a mobile app, or a desktop app); or they might just write some simpler client-side presentation logic.

People who are not experienced full-stack software developers often misunderstand is that the presentation logic is just a swappable, "bolt on" layer so that the business data and logic can be exposed as required so the data is not locked in some "silo" some where. The data might be presented with React, HTML, HTML plus some JS libs, etc) or the data can be presented to the user in a mobile app written in Java or a desktop app written in C++.

The same is true in scientific computing. What is the point of having scientific programming if that data cannot be shared with other scientists who will process the data and perform additional research on it? The HLA is basically the same. Data is stored based on the data models. There is logic to process the data and after processed based on various requirements (driven by the end users), the results are presented in various ways to the user. It might be a "view" or it might be another application which takes the data and fuses/combines/builds new results. Separating out "web development" as a small subset of software development seems as an artifact of many years ago, to be honest.

I'm not trying to be orthogonal nor antagonistic, @Azhrei . I simple do not understand what perspectives you are coming from.

Do you develop software for a living? If so, what kind of projects do you develop on a daily basis?

This LinkedIn graphic from earlier this year is interesting:

Top Programming Languages to Learn for 2022 Jobs?