Viability of unpopular programming languages(johndcook.com)
johndcook.com
Viability of unpopular programming languages
https://www.johndcook.com/blog/2018/04/17/unpopular-languages/
99 comments
You 100% live in a bubble.
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.
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.
Maybe you live in a bubble too. That's just a guess but a majority of windows programs may be made in C#
On the contrary, I also regularly work in depth with JavaScript, TypeScript, Python, Golang, Java, Scala, Rust, C#, Perl, assembly, and more, in no particular order, and I routinely work as a sysadmin, network administrator, and operations. I may live in a bubble but I'd say it's of adequate breadth to judge the relevative scales of many ecosystems.
That's quite the repertoire, so you mind if I ask what your role/position is?
This is not as uncommon. For example here where I live (Colombia) we are used to be "the guy that know all about computers". As developer, not only I use a lot of programming languages and tools, but also do stuff like:
- 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...
- 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...
He is the main developer on the Linux Window Manager I use
https://github.com/swaywm/sway
I don't really have a particular role, I just work on a bunch of different stuff as needs demand. I think officially it's just a generic software engineer title.
Programmer.
As a programmer you should be versatile.
As a programmer you should be versatile.
>but a majority of windows programs may be made in C#
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.
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.
Airbus and Boeing both use Ada for their avionics.
I don't know about Boeing but Airbus uses C in addition to Ada. IIRC they made significant use of Caveat and are now supporting Frama-C.
Specifically, unless my knowledge is out of date, they use a subset of C known as MISRA-C that is easier to analyze using static analysis.
I'm also a C dev, Hi OP.
>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.
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.
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.
I'm not sure I agree with your point about COBOL developers, though I do agree with your larger point about C. The reason that COBOL developers get big bucks today is because so few of them remain. During the late-80s and the '90s, there were massive layoffs that decimated the COBOL job market. The developers earning big bucks today doing COBOL doing today are the ones that survived those layoffs, not your "typical" COBOL developer. I would wager that the median COBOL developer either transitioned into management, out of the industry or is working in a completely different language today.
The reason that COBOL developers get big bucks today is because so few of them remain. During the late-80s and the '90s, there were massive layoffs that decimated the COBOL job market.
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.
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.
I think you might be underestimating the unwillingness of older people to relocate or travel long distances for a 'job opportunity'. These are also people who probably tend not to live in bigger cities as much.
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.
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.
[deleted]
> if false
After the Freudian slip I think this is the first time I come across a Boolean slip.
After the Freudian slip I think this is the first time I come across a Boolean slip.
Yes, my main point here was maintenance is important and the number of people who know old languages usually shrinks, making it a very good job market as you point out.
What are “big bucks” these days in the context of FAANG? I think you have to get to 450k+, or is that still too low?
> 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.
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.
This cuts both ways though. Sure, if you learn Java you'll be likely to find employment.
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.
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.
Hi! Developer working in C here. I'm neither a kernel dev nor an embedded dev.
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.
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.
> Maybe I live in a bubble but this list just seems divorced from (my) reality.
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.
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.
Yep, any emerging physical technology most likely had low level developers behind it. The low level guys are the ons who make it compatible with the high level stuff too.
> So what is this list implying - that JS developers should get with the times and learn C?
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.
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.
> Without details on how this list is compiled, I think it's pretty useless.
"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...
"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...
Thanks for that. OK, that indeed confirms the list's uselessness.
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.
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.
Popularity is too ambiguous, current popularity even more so. Any index can be considered a popularity index.
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.
[1] http://pypl.github.io/PYPL.html
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.
[1] http://pypl.github.io/PYPL.html
Supporting this view from the linked post: "A few of the more obscure languages that TIOBE ranks higher than Haskell are Scratch, D, ABAP, Apex, and PL/I."
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...
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...
The index is clearly not credible:
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...
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...
I have my doubts about it as well. They incorrectly ranked Crystal higher than it should have been because there is this phenomenon known as "crystal programming" which clashes with the Crystal programming language[1]. To their credit, they fixed it when I emailed them about it, but who knows what other misrankings exist.
1 - https://meanings.crystalsandjewelry.com/how-to-program-cryst...
1 - https://meanings.crystalsandjewelry.com/how-to-program-cryst...
[deleted]
software_development.web != software_development
There is a severe lack of evidence in this post for the author's assertion that "Common Lisp, Erlang, and F# would all be safer bets" than a nebulous "several more popular languages" - his entire argument seems to be that Common List and Erlang have been around since the '80s, and F# shares resources with C#.
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.
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.
I think the author's point about F# stands w.r.t it being a .NET language. Many services and products have officially supported .NET libraries and SDKs, which means that if you use F# you can leverage that support.
I think the author is making an implicit and questionable assumption: namely that the top end of the S curve doesn’t dip back down again. But that’s not true. Standards change, use cases change, operating systems change, and unless there’s a lot of work going into maintaining those libraries - or building new ones - the existing libraries slowly become less useful. Yeah, they provide a base, but then you’ll have to work around a quirky bug because you’re using it in a way the original author never intended, or other libraries you need to solve this problem don’t exist, or...
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.)
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.)
To me it comes down to usage: if given a problem X you are likely to chose language Y to solve it, then Y is viable. That sentence probably sounds super obvious, ok. The important point is realizing that the critical question there is: Am I likely to chose language Y? And realizing that the answer doesn't depend on popularity. For a general-purpose language popularity is probably a big factor, but for other languages that shine in solving particular problems it might not be very relevant. The question, as I say, is: is there any scenario where I would chose this language over other alternatives? If the answer is yes, then I'd say the language is viable.
Popularity to a certain extent is a prerequisite for viability. Given problem X, and given that language Y is the most suitable language to solve problem X, how likely are you to chose language Y to solve it? If you are unaware of language Y's existence? If you have heard of Y on a internet forum but have seen zero lines of language Y code? If you have written 10 lines of language Y but you are the only dev at your company to have done so, and all other code at your company is written in Z?
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.
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.
Just because something is unpopular doesn't mean that there is a reason for it. It is actually surprising how few users you need to have a viable programming language.
Especially if you can compile the language to an executable or something distributable.
Or you can compile to another language, like writing web apps in OCaml using BuckleScript or using other language libraries via FFIs https://realworldocaml.org/v1/en/html/foreign-function-inter...
Many proxies suffer from a set of problems relating to specificity, applicability, and how much you can infer from quantitative data.
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.
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.
I wouldn't go so far as to say that widely used is the same as popular. That implies an overall positive attitude towards the widely available thing.
We all know that there are things that we use regularly but wish we didn't.
We all know that there are things that we use regularly but wish we didn't.
Funnily enough, the index update this month is: "April Headline: Perl is having a hard time"
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."
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 fewer users a language has the longer it'll take to hire someone, which means there'll potentially be a long wait for what your team can deliver. If you're a startup a long wait before delivering means you'll run out of money and shut down. If you have a choice, factor hiring team members very highly in your tech stack choices.
No, just hire a "programmer". It really doesn't take long to get up to speed in a new language and can make it more fun, adding to motivation. 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?
>No, just hire a "programmer". It really doesn't take long to get up to speed in a new language and can make it more fun, adding to motivation.
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.
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.
> 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.
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.
Exactly, it's a classic rhetoric device to destroy an argument by extending it so much that it sounds silly and addressing the silly proposition instead.
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.
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.
> Exactly, it's a classic rhetoric device to destroy an argument by extending it so much that it sounds silly and addressing the silly proposition instead.
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.
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.
> C and C++ devs can be hired for Rust positions
In my experience, this is very untrue. Knowing C++ does not make learning Rust any easier than knowing Java.
In my experience, this is very untrue. Knowing C++ does not make learning Rust any easier than knowing Java.
I find it does, at the very least familiarity with RAII concepts and smart pointers will make the whole borrow checking business seem very familiar.
The domain is more important, I think; i.e. you can hire a web dev to work with almost any language/framework, but you may not hire a Django dev for a statistics heavy project written in Python.
Yeah, that's true. For that statistics project I'd look at their academic background. If there's not much math in what they studied I wouldn't consider them.
[deleted]
The language itself is (usually) the easy part. If you need a senior frontend engineer, JavaScript knowledge is table stakes. You need someone who can collaborate with product and design, and work with the engineering team on platform and implementation decisions. If you need a senior backend engineer you need someone who's really familiar with server side APIs, database behavior, and data model patterns who can advise the product team on what is reasonably possible and what is practically impossible. And these are just the baselines; we're not talking about emergencies, outages, modern software development (continuous integration, testing, deployment, etc.), or "intangibles" like attitude.
Basically that's why hiring engineers is so hard. There are 1000 variables and really they're all important.
Basically that's why hiring engineers is so hard. There are 1000 variables and really they're all important.
> The fewer users a language has the longer it'll take to hire someone, which means there'll potentially be a long wait for what your team can deliver.
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.
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.
> The fewer users a language has the longer it'll take to hire someone
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.
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.
It actually seems like it ought to be easier to find a good programmer when you're hiring for one of the more obscure languages like F#, OCaml, Erlang, Clojure, etc.
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 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).
Some of these languages might come with some inherent advantages that give you an edge over the competition (like memory safety in rust). If the founders are well versed with a new technology like this than that would give them the edge.
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.
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.
Some of these languages might come with some inherent advantages that give you an edge over the competition in certain situations. So, use those languages in those situations.
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.
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.
I've been working in Erlang* for almost 7 years. We mostly hire smart people and give them an Erlang book and help them get settled. I think only one or two hires used Erlang before they worked here, everyone else learned it on the job, myself included. It might be easier to onboard people if our stack was more usual, but Erlang is a perfect fit for our application.
* And to work on all the surrounding bits, of course also C and PHP and Perl and even python if it comes up.
* And to work on all the surrounding bits, of course also C and PHP and Perl and even python if it comes up.
[deleted]
> Haskell has better public relations than all these languages.
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.
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.
The excellent tooling, documentation and package repository for Haskell is invalidated because of a rant about js?
On the official wiki
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.
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.
no, but these things probably aren't the only things that go into 'public relations'
Haskell has excellent tooling, documentation, and package repositories? When the hell did that happen?
I've found that many confuse the question "is it a viable programming language?" with "does it stand a chance to be top-10 popular?". The second proposition is much harder than the first, and many language will need mass appeal to get to the top-10 ; which is not necessarily without consequence on the language itself.
Very Surprised that Pl/1 ranks above Haskel
This analysis is misguided because many of those languages are DSLs, e.g. ABAP, Apex, F#. No one using them has the option of using a general purpose language (and they are well-paid enough not to care). Whereas Perl 6 is in direct competition with general purpose languages. And it really is time to give up on flogging that dead horse.
F# is very much a general purpose language. The tooling and infrastructure allows one to do nearly everything that can be done in C# in F# as well, and if one needs to use C# for something that is not really an issue because the languages are fully compatible.
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.
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.
F# to me would be a nice upgrade from powershell for ops/infrastructure code, due to terseness, a strong type system, and some similar syntactic concepts between both languages. many times i want to go 100% F# but due to the issues integrating f# i end up either having to write a lot of powershell, or shoe-horning C# classes and end up with two languages.. dont know what the fix is..
What are some of the issues you encounter in integrating F# with your ops/infra processes?
Thanks Phillip for responding,
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.
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.
Don’t get me wrong, coming from an OCaml background I am a fan of F#. But I don’t see it going mainstream anytime soon, and I don’t think that that matters at all to anyone who uses it.
That's okay, but that's not what DSL means as far as I'm aware. Which is why you got the comments about F# being general purpose.
I agree with uryga here. F# is not a DSL. There might be confusion, because a lot of F# people like to write DSLs in F#. But it's a full on language like any other. Except for the syntax it's not even that different from C#. Just a little better in terms of little extras it offers.
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.
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.
I think you got downvoted because although your comment is plausible enough in isolation, it does not have anything to do with the thread it is attached to (even though you yourself are the originator of the thread).
ADDED. You don't seem to share my preference for conversations that stay focused on one topic. Over and out.
ADDED. You don't seem to share my preference for conversations that stay focused on one topic. Over and out.
There’s nothing to say a DSL can’t be a full language. Just that it is designed for and generally used in a specific domain. I don’t think MS ever intended or claimed F# would be the new C# - it is very clearly aimed at a particular niche. And there’s nothing wrong with that! Nor would any F# user see their language as a rival or competitor to C# or Python or Java or anything else.
If F# is a domain specific language, which domain is it specific to?
Hint: Functional programming isn't a domain.
Hint: Functional programming isn't a domain.
How F# is not a general purpose language?
It’s not used as such, at least I’ve never seen it used like that. You would typically see it used by quants in an otherwise C# shop.
AFAIK there's no special provisions in the language for quant trading to categorize it into DSL. More along the lines of Lisp being touted as "AI language" in 1980s, while it's really a general purpose programming language.
And how can you not use C# in that case? I understand you might not want to but...
Sorry, the horse does not agree it's dead.
Just chiming in to say that F# is not a DSL - it's a fully-fledged programming language. Not in use nearly as much as C#/Java/etc., but it's not a special-purpose language.
"Rumours of my demise are greatly exaggerated." -- Mark Twain, who may or may not have been writing about Perl, Perl6, and other languages that are no longer hip.
"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.