Viability of unpopular programming languages
johndcook.com
johndcook.com
"The index can be used to check whether your programming skills are still up to date"
C is #2. Javascript, for better or worse the most important language for web dev, is #8. So what is this list implying - that JS developers should get with the times and learn C?
Without details on how this list is compiled, I think it's pretty useless. Even the most cursory search of any job site will show orders of magnitudes more jobs for "unpopular" languages like JS, ruby and golang than for C. I'm not even sure what C is used for these days beyond kernel/driver development or embedded systems. I think I've met precisely one C developer in the last 10 years.
Maybe I live in a bubble but this list just seems divorced from (my) reality.
Are you a web developer?
Yes, C# and Javascript are all the ads I see for developer jobs, if I'm looking at web developer jobs.
But doing a search in my area for C/C++ developers and plenty of jobs vacancies come back.
Plenty for Java too, one for Python (from my cursory look, the Python position I saw was the highest paid too, by a good margin).
The whole world doesn't use javascript, some of us want nothing to do with it / avoid it like the plague.
I would agree though, if you just want to play a numbers game it's probably safest to learn JS, C# or Java nowadays if all you care about is getting employed.
If you learn Java and also Scala and Clojure, and some Haskell and R just to round out your experience, then you will find a much higher paying job regardless of what language you end up doing, because you'll not only be better at programming in a "standard" job but you'll become eligible for more niche, higher-paying positions.
I meet hundreds every day, and nary any web developers. I'm working in an embedded shop though, so YMMV on personal experience here.
I learned some JS in school but haven't needed it since. Except writing some extensions, which was easy enough to learn in an afternoon if you know C-like languages. (I used TypeScript to be fair, much easier for me, why anyone would use pure JS is beyond me).
I'm not sure TIOBE is useful for anything either. But a lot of legacy programs in C need maintenance. A lot of government software, flight control systems, banking systems etc. are probably still in large parts C.
Just look at the salaries of COBOL developers (where is that on TIOBE again?), and you'll see that maintenance is big business. And that language is as ANCIENT as ALLCAPS.
Looking as C is still at the heart of almost everything, I think maintenance work will still be a big consideration for the next 50 years. It might not be sexy or what you want to do though.
This if false, I work at a company that still employees several hundred cobol developers onshore, and many hundreds more offshore. This is down from > 1,000 several years aog. Cobol pay is mediocre, here it's around $75k at the 10 year mark. Plus they're subject to being RIF'ed and any time (reduction in force, layed off).
The idea that there's a shortage is false too. In the local market there are several hundred if not thousands of cobol developers who have been laid off over the past couple of decades. Most probably left the field entirely.
I see no reason to believe this local experience is not typical of the US in general.
They've seen countless jobs come & go, but they choose to live where they are for long-standing reasons which are often harder to let go of the older they get. They've moved away from the hustle and bustle and are happy with their choice.
I have personally met older people with higher end skills (that would command a six figure salary in certain cities) choosing to work as janitors at a local institution instead of chasing that dollar, because they love their town and lifestyle and the cost of living is low.
Edit: Forgot to add, I also know a guy over 70 who flies all over the place doing COBOL work and is making bank doing it.
After the Freudian slip I think this is the first time I come across a Boolean slip.
"Since there are many questions about the way the TIOBE index is assembled, a special page is devoted to its definition."
https://www.tiobe.com/tiobe-index/programming-languages-defi...
TL;DR: It counts all the hits on N search engines for any language with its own wikipedia page.
Obviously that will bias towards older languages with a large cumulative number of mentions. I don't see it as useful for evaluating the current popularity of languages.
TIOBE is more like a long term impact kind of index. It's good enough if you want to understand familiarity with the language or penetration of the language. If you want to know which languages people hear about currently, check out PYPL index [1]. And of course job market is an index of languages used today. More insight can be extracted from combining metrics, like adoption speed index.
Drive down the road and look around. There are sensors and devices on poles everywhere. Your car iteself, elevators, automatic doors, etc. Think of all the devices that you encounter in a day. There's an entire world of software out there that has absolutely nothing to do with web technologies.
https://www.tiobe.com/tiobe-index/visual-basic-dotnet/
There is no way that in reality visual basic is surging up the charts and more popular than most other languages, instead I would guess they are attributing some .Net results to VB instead of C#.
for comparison, this is the google trends chart of visual basic: https://trends.google.com/trends/explore?date=all&q=visual%2...
My current job is network programming on the core product of my employer. It's "legacy" in the sense that it's been around a long time but it's actively developed and continually extended to meet rapidly evolving customer needs.
I also wrote C in my previous job doing non-flight software for a space mission, analyzing telemetry, processing image data, automated planning of camera targeting, etc. Much other work was done in scripting languages, and when those weren't performant enough for the task then I wrote C libraries to do the heavy lifting for them to interface with.
You don't live in a bubble. There are whole segments of the software industry where you'll never see C developers, and there are many companies where you C could (should?) be used but isn't because it's unhip and old. Software development these days is pretty fragmented and there's a tendency for people to think that their experience describes everything, but it's not the case.
First of all, I'm a C developer. Hi!
Second of all, web developers are not the majority they think they are. The internet is huge, sure, but remember it's not just running on web browsers. It's also running on servers which have network interfaces that need drivers and implementations of the IP suite, through firewalls, routers, switches, and load balancers that are all written in C, and running your trendy web app in a hypervisor that's written in C. Your database - be it PostgreSQL, MariaDB, Redis, etc - it's written in C. Your web browser uses C for loads of stuff like sqlite, rendering, etc. The Python and Ruby interpreters are written in C. The .NET CLR is written in C, too.
Beyond the internet, C has an even more pronounced presence. Every microcontroller around you - your fridge, microwave, coffee machine, car, subway train - all written in C. The code on your phone is at least 50% written in C. Your fancy mouse and keyboard? C. Manufacturing robots in factories are coded in C. CNC machines and PNP machines are written in C. 3D printers are programmed in C. Airplanes are programmed in C, and trains and boats too. All spacecraft are programmed in C, from the Curiosity rover to the Rosetta spacecraft (and it's lander) to the international space station.
All of your utilities like grep, ls, git - written in C. So is the code that's decoding the music you're listening to right now, and the YouTube video you watched earlier, and most other multimedia code is C. Your crypto libraries are written in C. Compression algorithms are usually implemented in C. Most font rendering is done in C. Nginx, postfix, openssh - C.
All that being said, TIOBE is probably bullshit. I can't imagine C isn't #1.
As a programmer you should be versatile.
- Fix the computers problems of (End users, customers, the son of the customer, my owm team-mates...)
- Do tech support (that is separate of the above 'cause that are task done when doing programming (?) not as a concret position on the company)
- Build the network infraestructure (not the software!) (put the literal wires, do small land-lord reparations while on that...)
- Build the network infraestructure, but on software
- Mount the security of the company. Sadly, the software side. Nobody let me use actual weapons and tactical gear ....
- Do design, UX and similar stuff because that kind of people not exist here (or is very rare).
That not mean I actually push for this. Some of this task are never paid (and I do 'cause I wanna to be pay for my primary work!).
This are just situations that happened...
If that were true, and I'm not sure it is, it doesn't account for all the much software, since almost everything is a web app now.
1 - https://meanings.crystalsandjewelry.com/how-to-program-cryst...
Presently on said path. You want to program hardware for satellites? Because C is how you program hardware for satellites (etc).
In serious, there seems to be a ton of jobs out there for C(& C++) developers. Funny though— if you search for "software engineer" or "software developer" you're not likely to see them rise to the top of the list. You'll probably have to more specifically search for "hardware" or "embedded" developer and you'll find a ton looking for C/C++, assembly(in various incarnations and sub-specs), and Java ME.
Scratch? If TIOBE is measuring children learning a language in middle school, maybe, but I take it that's not what people ordinarily mean by language use or popularity...
Also, an S-curve does not seem an appropriate representation for the benefits of a larger userbase - diminishing returns are not synonymous with asymptomatically approaching zero returns, and the idea that the first few users are worth negligible amounts seems wildly inaccurate.
My point is that the S curve only remains an “S” through constant ongoing effort by the community, and that’s what makes a language viable _for a domain_.
(I should also point the it that that curve actually represents the viability of a language for a particular problem domain.)
The more popular Y is the easier it is to choose, not because we are pop culture, popularity hounds but because popularity conveys certain benefits. Libraries and infrastructure, documentation and blogs, knowledge in other people on the team. That is why large companies are able to so successfully produce new languages, they are able to pay people to convey those benefits without the chicken and egg problem of natural growth popularity. For an interesting example of this D is almost the same age as C#(2001 vs 2000). D had to grow its user base and tools organically vs C# hitting the ground with thousands of devs working on an in it full time.
Specificity, in that you are attempting to model one specific question with another, which might not even indirectly answer the question. You make an inference on this, and this inference could be quite wrong.
Applicability ... are you or the proxy really measuring what you intend? Is the proxy applicable as a metric?
I won't fisk this post. I will point out that people have been beating on Perl for a long time (all versions), as a "dead horse". It decidedly isn't, from my vantage point in a number of areas.
Cool, it is not. Hip, it is not.
More importantly, dead, it is not.
Perl6 is interesting, I've not done much there yet, though it looks like a great general purpose language.
We all know that there are things that we use regularly but wish we didn't.
Source: https://www.tiobe.com/tiobe-index/
"At the moment there are 2 programming languages in the top 20 that have lost more than 3 positions in 1 year's time: Objective-C and Perl. The reason for the fall of Objective-C is clear. Apple abadoned Objective-C a couple of years ago and replaced it by its successor Swift. Moreover, mobile app development is moving to platform independent languages and frameworks, so even Swift, which is only available on Apple's systems, has a hard time. But what about Perl? Till 2005 it was the most dominating scripting language in the world. In 2008 we said in an interview with Dr. Dobb's Journal that Perl would go extinct based on the trend we saw in the TIOBE index at that time. After this a religious war started with Perl diehards who claimed that this won't happen and that the TIOBE index was being gamed. Stevan Little gave a ground-breaking talk in 2013 called "Perl is not dead, it is a dead end" indicating that once software engineers leave the Perl language they will never come back. Personally I think that the fork of Perl 6 (and its delays for decades) together with the unclear future of what was going to happen to the language was the main reason for engineers to look for alternatives such as Python and Ruby. And still today the Perl community hasn't defined a clear future, and as a consequence, it is slowly fading away."
The problem is that it needs some serious backing for a prog language project in order to become a contender in this game. It is far more than a weekend project (+the founders seeking to apply this knowledge should be well versed in the subject matter)
It might be that the end of 'moores law' will make such factors more important to the success of a project, more competition and a smaller margin will lead people to look for other differentiators, so to speak.
Every programming domain has its yak-shaving aspects. Use whichever language and libraries that minimize the yak shaving, so that you can get on with what you're really trying to do.
It doesn't take long to learn the absolute minimum of many languages, but that might just give someone just enough knowledge to be dangerous, not useful. I would not, for instance, assume that my knowledge of javascript more or less prepares me to write banking software in COBOL or drivers in C, even if javascript and C share a lot of common syntax.
> In any other profession job adverts don't specify the exact make and model of tools being used so why is it always required with programming?
Because "programming" is not the profession. Programming specific applications in specific languages that meet specific business needs is the profession - and the necessity for domain knowledge beyond the bare minimum required to produce correct syntax is always more important than the language itself.
I can't help but feel you are agreeing with the parent poster.
In your examples you changed the domain. The parent was talking about the shift in language being the least important factor.
It's not entirely true but as a web dev I have written a web app in x86 assembler and cgi-bin without too much trouble. It took longer but I never really felt stuck.
There are some languages which are very interchangeable where someone from a similar family will be able to get up to speed quickly. e.g. C# developers can be hired for F#/Java/Scala/Kotlin/... positions. They're all GC'd, statically typed and don't require much familiarity with computer architecture.
C and C++ devs can be hired for Rust positions, it's both non GC and requires some understanding of what you're doing with your memory, even if Rust is taking your footguns away.
Sure, I wouldn't hire a JavaScript developer to do C, because they can do a lot of damage there. But I'd consider a C dev for a JavaScript position, even though I'd have to ask them why they want to do that to themselves.
Levels of abstraction might be a better "metric".
ASM < C/C++ < ADA, Rust < C#, F#, Java, Scala, Kotlin < Python, JavaScript, Perl < DSLs < GUIs
It's easy to move up in the abstraction layers. It's harder to move down, because you have to think about things you haven't thought about before.
In my experience, this is very untrue. Knowing C++ does not make learning Rust any easier than knowing Java.
That's not what I was attempting to do.
> Sure, I wouldn't hire a JavaScript developer to do C, because they can do a lot of damage there. But I'd consider a C dev for a JavaScript position, even though I'd have to ask them why they want to do that to themselves.
But it's a problem either way. A C developer likely is going to want Javascript to work like C, and they're going to hate that it doesn't, and they're going to write bad Javascript as a result. And understanding modern Javascript means understanding the DOM and how to efficiently interact with it, and the whole horrible mess that is NPM, and compile-to-js languages.
My argument is that outside of a textbook, the domain and the language seem to be inseparable, or at least very tightly coupled. Abstraction is one dimension (and I'm not entirely sure it's true that it's easy to move up, since abstractions carry their own debt) but it's likely not one that really matters to a business.
Basically that's why hiring engineers is so hard. There are 1000 variables and really they're all important.
In practice that only seems to be true for rapidly growing companies.
I've got a list of 30-40 F# devs I could hire in my city. On the other side of the equation my dev team only adds 1-2 new devs/year.
In practice we typically take less than a week to fill an opening.
The total number of available programmers may be less, but most of them are probably going to at least be decent (they were self-motivated to learn a non-mainstream language, after all). If you're trying to find a great Java developer (in which case what you're really looking for a great developer who is willing to code in Java for money), you're going to waste a lot more time sifting through legions of incompetent code monkeys to find somebody good (one good screening filter: if Java is the only programming language they know -> reject).
The number of available devs to hire is $JOBS - $DEVS. Eg, there are lots of Ruby devs, but also lots of Ruby jobs, so you're competing for the few Ruby devs who are on the market.
OTOH, there are a small but enthusiastic number of developers using Elixir, Haskell, Rust, etc and wishing they could get a full-time job in it, because there are (currently) even fewer jobs with those languages.
You need to factor in not only "how many devs know this language?" but also "how much demand is there for jobs using this language?" If a ton of devs know Language X but most of them hate it, you're not going to have an easy time hiring them.
* And to work on all the surrounding bits, of course also C and PHP and Perl and even python if it comes up.
Haskell has had a rant about JavaScript on its official wiki for a few years(the wording changed to a less offensive one eventually), so the bar is pretty low here.
Actually - it's not the rant - it's the superiority complex. The fact that someone thought it would be a good idea to drop filth on another language there and nobody protested says a thing or two about the community.
I mean, it literally said "JavaScript sucks ...".
I see this condescending attitude a lot among people who do functional programming.
Case in point: The only library that currently implements the Maybe monad as specified by Fantasy Land is called "Sanctuary.js" - as in "Refuge from unsafe JavaScript".
Why the smugness? It surely doesn't help.
Implying there ever will be.
True, there are some things that are best done in C# like WPF, but that is not a sufficient handicap to truncate F# from the population of general purpose languages.
The only thing vs. C# which I think it lacks is support of unsafe pointer arithmetic. Which I've never really used in C# either.
ADDED. You don't seem to share my preference for conversations that stay focused on one topic. Over and out.
Hint: Functional programming isn't a domain.
I actually don't see any issues with F#, it's more:
- The ubiquity of powershell and the ISE. powershell is installed on every server, and to step outside that means deploying a new compiler/runtime and its dependencies to production servers.
- Doing operational tasks is easier with powershell (in the short term) because the existing cmdlets for managing servers are provided with the language. An example would be bulk updating 500k users in AD (with complicated logic that compares data between 4 or 5 other systems)
- Using the Add-Type cmdlet to include F# libraries into Powershell requires a few manual steps that might break over time: https://tahirhassan.blogspot.com.au/2014/06/embedding-f-in-p...
- Awareness/ecosystem - powershell feels like its being used to solve all 'server related' operational problems at the moment, and that F# is used for apps. i dont think my team mates would appreciate me solving a problem in F# unless everyone was happy about the choice of language beforehand.. Same goes for them if they wanted use python, rust, prolog. etc.