Developers Reveal Programming Languages They Love and Loathe, and What Pays Best (zdnet.com) 139
Stack Overflow has released the results of its 2020 survey of nearly 65,000 developers, revealing their favorite and most dreaded programming languages, tools and frameworks. From a news writeup: The survey shows that TypeScript, Microsoft's superset of the widely-used JavaScript programming language, has overtaken Python as the second most beloved programming language behind Rust. This year 86% of respondents say they are keen to use Rust, while 67.1% want to use TypeScript, and 66.7% want to use Python. Stack Overflow attributes TypeScript's rising popularity to Microsoft's embrace of open source software as well as the existence of larger and more complex JavaScript and Node.js codebases.
Rust has been the most loved programming language for five years running, despite few developers having experience with it. This year, just 5.1% developers report having used Rust, compared with the 68% who use JavaScript, which is the most commonly used language. [...] Meanwhile, the top 10 most dreaded programming languages are VBA, Objective-C, Perl, Assembly, C, PHP, Ruby, C++, Java and R.
The report also looks at average salaries of each developer role. In the US, engineering managers attract the highest salary at $152,000 per year, followed by site reliability engineers who earn $140,000 per year. Salaries across the globe for these roles are lower, at $92,000 for an engineering manager and $80,000 for a site reliability engineer. Other high-paying roles with an average salary of at least $115,000 in the US include data scientist and machine learning specialist, DevOps specialist, engineer, back-end developer, embedded application developers, mobile developers, scientist, desktop application developer, and educator.
Rust has been the most loved programming language for five years running, despite few developers having experience with it. This year, just 5.1% developers report having used Rust, compared with the 68% who use JavaScript, which is the most commonly used language. [...] Meanwhile, the top 10 most dreaded programming languages are VBA, Objective-C, Perl, Assembly, C, PHP, Ruby, C++, Java and R.
The report also looks at average salaries of each developer role. In the US, engineering managers attract the highest salary at $152,000 per year, followed by site reliability engineers who earn $140,000 per year. Salaries across the globe for these roles are lower, at $92,000 for an engineering manager and $80,000 for a site reliability engineer. Other high-paying roles with an average salary of at least $115,000 in the US include data scientist and machine learning specialist, DevOps specialist, engineer, back-end developer, embedded application developers, mobile developers, scientist, desktop application developer, and educator.
lowball (Score:2)
No COBOL ??
Re: (Score:3)
COBOL developers aren't likely to be on internet foums, pretty good gig around Chicago area here since so many insurance and financial companies use it, $100K+ for salary and twice that for consulting.
Re:lowball (Score:5, Funny)
"COBOL developers aren't likely to be on internet foums,"
We were gathering in mailbox forums when you still wet your pants.
Re: (Score:2)
That's funny since I'm older than IBM mainframes and Unix.
Re: (Score:2)
No COBOL. People who use that, hate it most, because they get always ripped out of retirement when they have to use it.
Re:lowball (Score:5, Funny)
We're keeping our little cash cow out of the news as much as possible.
Like marrying a pop star diva (Score:5, Insightful)
5% of respondents have actually used Rust.
86% think they'd like it, but haven't actually tried it.
Clearly Rust has a good PR program, but we already knew that.
It just might be that using Rust is like being married to [insert pop star here] - lots of people think they want to, but you just might find she's actually a dimwitted diva with a really annoying superiority complex.
Re:Like marrying a pop star diva (Score:4, Interesting)
Ignoring memory management doesn't make it go away -- now you have two problems. /s
(With apologies to JWZ).
Interesting article [github.io] on someone thinking about removing Garbage Collection from the Rust Language.
Re:Like marrying a pop star diva (Score:5, Informative)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Ignoring memory management doesn't make it go away -- now you have two problems. /s
(With apologies to JWZ).
Very true. Garbage collection is a huge trade-off. A long as memory is not a problem with regards to footprint and performance (use more memory - be slower, that is one effect caches give us), using GC is convenient and absolves the coder from knowing what they are doing in the somewhat complicated area of memory management (well, complicated for low-skill coders that is). But as soon as you leave that space and need that performance or low memory footprint, GC is much more of a problem than a solution. It
Re: (Score:3)
If you would have done the survey 15 years ago, most people would have probably mentioned
Ah yes, the Ruby on Rails fad (Score:3)
Fond memories. Rubies on Rails was so exciting, the hot new thing for a few months. One guy in my Perl users group was really excited about it, so I asked what advantages it had over the Perl we'd been using for years.
I don't think I got an answer.
Mainly the answer I've always gotten an why X better than Perl have been various ways of saying "I don't know regular expressions".
Re: (Score:2)
Funny, "object oriented, but not in a psycho obsessive way" is exactly what I think is best for a general purpose programming language.
> Java doesn't treat numbers as objects
Yeah I don't need a million bits of Object for every 32-bit number, or 64 bit. Personally I much prefer this:
int day = 24* 60 * 60;
To this:
Integer sixty = Integer.Create();
sixty.value = sixty.fromChars("60");
Integer twenty_four = Integer.Create();
twenty_four.value = twenty_four.fromChars("24â);
Integer day = Integer.Create();
day
Re: (Score:2)
That's a point I've brought up many times. I've been a time nerd my entire life and run a public ntp server as part of pool.ntp.org
One must be careful to distinguish between "what time is it in human clock time?" vs "how long has it been?" Don't try calculate how long ago something was based on the human clock time because 1:30AM might be 30 minutes AFTER 2:00AM. Or it might be 30 minutes before.
It's easy enough to measure how long it has been, and you use epoch time for that. Never human clock time. Real
Re: (Score:3, Insightful)
5% of respondents have actually used Rust. 86% think they'd like it, but haven't actually tried it.
Clearly Rust has a good PR program, but we already knew that.
It just might be that using Rust is like being married to [insert pop star here] - lots of people think they want to, but you just might find she's actually a dimwitted diva with a really annoying superiority complex.
That's because devs would like the advantages of borrow-checkers, lifetime-checking, etc, but unfortunately for Rust there is way too much cognitive overhead when reading it. Most Rust looks like line-noise, and is much harder to read than equivalent programs in other languages.
This is why, for five years running, Rust is most loved but still hardly used.
The other thing to keep in mind is that the stackoverflow survey is flawed anyone due to the self-selecting sample. People who love Rust take part in the
Re: (Score:2)
That's because devs would like the advantages of borrow-checkers, lifetime-checking, etc, but unfortunately for Rust there is way too much cognitive overhead when reading it. Most Rust looks like line-noise, and is much harder to read than equivalent programs in other languages.
Interesting. So too much behind-the-scene magic you actually need to be aware of?
Re: (Score:2)
Most Rust looks like line-noise, and is much harder to read than equivalent programs in other languages.
That's irrelevant, people who like Rust want other people to use it. They say, "We should rewrite the kernel in Rust, then it won't have any security bugs." Ignoring that the most common types of bugs are not memory bugs [techrepublic.com].
Re: (Score:3)
Re: (Score:2)
It is probably also that a lot of low-skill coders hope that Rust is the "silver bullet" that will finally make their code not suck.
That never works and cannot work, although the Rust propaganda is pushing this lie hard.
Re: (Score:2)
5% of respondents have actually used Rust. 86% think they'd like it, but haven't actually tried it... It just might be that using Rust is like being married to [insert pop star here] - lots of people think they want to, but you just might find she's actually a dimwitted diva with a really annoying superiority complex.
The only number that would be meaningful for your diva comparison is something about how many people disliked or stopped using Rust. In its absence, your analogy has no relation to the data you quoted.
"68% use javascript" (Score:5, Insightful)
Re:"68% use javascript" (Score:4, Informative)
Re: (Score:2)
I think most developers are web developers these days. Honestly I'm surprised it's only 68%.
Re: (Score:2)
I think most developers are web developers these days.
That seems highly unlikely. The people writing all the tools web developers use probably aren't web developers. Nor are the people writing the operating systems their computers run, or the device drivers and network stacks and security libraries and shells that run on top. Or the firmware in all the network switches and routers and firewalls between their hosting service and their visitor. Or the OS or GUI or all the firmware running internal components in their phones. Or the control software in the microw
Re: (Score:2)
Re:"68% use javascript" (Score:5, Interesting)
Did they only ask web developers?
I'm doing server-side JavaScript now.
I *HATE* JavaScript. I hate everything about it. It's the worst language in the history of programming. The only way to make it worse is to use it server side.
If 20 years ago somebody had told me I'd be doing this, I'd have changed careers.
Re: (Score:3, Interesting)
What's to hate about a language where you can introduce infinity or not-a-number into calculations and not get an exception? Or a language where undefined values compare to defined values without an error? Or a language where adding two arrays neither does concatenation nor vector addition, but rather stringification and then concatenation--wrecking the two original values at the middle? That is, a la
Re: (Score:2)
You've never programmed in AppleScript, I see.
Re: (Score:2)
Dreaded (Score:2)
There are some fun languages in the "dreaded" category, but they're all difficult.
They seem to break down into "difficult to learn", "difficult to use properly", and "difficult to get anything done" categories.
A difficult-to-learn language that's powerful and can be used properly in a straightforward manner is quite an ally.
My sympathies, truly, for those who have to work in "difficult to get anything done" languages.
Re: (Score:2)
So which ones do Perl, PHP and Ruby fall under? It seems it mainly seems to indicate unfashionable to me.
Re: (Score:2)
So which ones do Perl, PHP and Ruby fall under? It seems it mainly seems to indicate unfashionable to me.
For Perl, I would say the only real issue is "difficult to read if written badly". That is for Perl 5. Perl 6 is a "second system effect" failure.
Re:Dreaded (Score:5, Insightful)
Hmm, OP's ID nr is 4333, and I've had people comment on my 5 digit number being low.
Yes I tend to agree. I did a lot of programming in assember in the 1970s when the architectures were simpler. I coded for the Univac 1106, intel 8080, motorola 68000, and a few Modcomp minicomputers back then. There was a feeling of power in being able to get the machine to do what you wanted. I used to say assember was for somebody who liked a stick shift. Learning C after all that assember experience was pretty easy.
But, how would I feel about it all if I was a young guy just starting out? That I don't know. I really do think they should teach some sort of assembler for a very simple architecture in the introductory curriculum for computer science. In my case, I had already learned some Fortran and COBOL but then I took this EE class and that's how I first got exposed to actual machine code. After that, everything else made a lot more sense. In the class we didn't learn assembler for any real machine. The class started with a model that just had an accumulator and a few instructions, then gradually added in new things like index registers and so on. But the concept was what was important. After that, going to a real machine was pretty straightforward.
Re: (Score:2)
I really do think they should teach some sort of assembler for a very simple architecture in the introductory curriculum for computer science.
They do not?
I got my Master of Engineering in Computer Science in 1997, and I had three or four classes that touched on Assembly, including one where we rolled our own, for a basic microprocessor we designed ourselves. That was purely theoretical, but another class's final project included writing a compiler for a simple procedural language to Assembly.
Now, I went t
Re: (Score:2)
I really do think they should teach some sort of assembler for a very simple architecture in the introductory curriculum for computer science.
They do not?
Unfortunately, no. Not even back when I did my CS studies 30 years back, but at least we got to work with a number of languages. These days it is often Java and JavaScript and nothing else. Yes, utterly stupid.
Re: (Score:2)
These days it is often Java and JavaScript and nothing else. Yes, utterly stupid.
Sadly, that is the commercialisation of higher education for you. Businesses want new graduates who can "hit the ground running" (or whatever cliche we're using this week) and new graduates want their academic courses to teach the vocational skills to do so.
Obviously it then turns out that new graduates know almost nothing about real-world development because most of them have never done any before, so they get a crash course over the first few years in industry anyway. And then the ones who didn't learn th
Re: (Score:2)
Indeed. Sure, there are still those students that see what is going on and learn things that are not required in addition (like I did back then and that is why I can code C, several assembler dialects and understand how machine memory is actually used...) but they are a small minority.
Re: (Score:2)
Likewise, I suspect that some of the better CS courses do still teach CS and not just vocational software development, but I fear they too are now in a minority.
Re: (Score:2)
StackOverflow is a Plague (Score:2)
Re: (Score:2)
I miss the days where Google let us remove specific sites from our search results.
Just stick -stackoverflow at the end of your query. I do it all the time with amazon.
Re: (Score:2)
Re: (Score:2)
I miss the days where Google let us remove specific sites from our search results.
It still does. I have -site:wikipedia.org automatically attached to my searches; it's incredible seeing the original sites all those WP articles are stolen from without some half-wit's ill-judged edits.
Re: (Score:2)
My boss and I (Score:4, Interesting)
My boss and I agree to disagree on this one. I like Python. He likes Perl. All our production code is in C. Neither of us have any issue with that. In a past life we had lots of tools written in expect, based on tcl. Which one colleague described as a theoretically-perfect computer science language you can't actually do anything with.
When I mentioned node.js a couple of months ago my boss got apoplectic. I guess he had a bad childhood experience with it or something. I have a similar response to java server pages. Don't ask.
...laura
Re: (Score:3)
My boss and I agree to disagree on this one. I like Python. He likes Perl. All our production code is in C. Neither of us have any issue with that. In a past life we had lots of tools written in expect, based on tcl. Which one colleague described as a theoretically-perfect computer science language you can't actually do anything with.
When I mentioned node.js a couple of months ago my boss got apoplectic. I guess he had a bad childhood experience with it or something. I have a similar response to java server pages. Don't ask.
...laura
Sounds like the makings of a very niche sitcom.
Comment removed (Score:4, Funny)
Re: (Score:2)
C programmers by day, who secretly let their hair down and fight over the best interpreted language by night. Sounds sexy.
Re:My boss and I (Score:5, Interesting)
I would've said C - because, more than any other language, it allows you to "think like a computer". I.e., to know exactly what's being generated by the code you write, without giving up power and efficiency.
But...
I'm currently working on porting a huge reservoir of C code built over decades (by many different hands) on an AIX system over to linux, and am encountering the scourge that is 64-bit linux C coding. For some godforsaken reason, when linux went 64-bit, they decided to make long integers 64 bits by default. 64-bit Windows doesn't do that, and for good reason. There's a ton of sloppily-written 32-bit C code out there that assumes that integers and longs are both 32-bits - or at least the developers didn't think about the possibility that they wouldn't be. (I guess that contradicts my "think like a computer" argument, but still... Most of the time I've used long's in the past was when I was working on 16-bit code and I needed something bigger than 16 - and yes, some of this stuff had its birth in the era of 16-bit machines.
In any case, 64-bit longs cause almost as many problems as pointers being 64 bits. I can understand the bit about pointers. I mean, why else go 64-bit other than to be able to efficiently address a ton of memory. But when there's a perfectly good 8-byte long long integer available, anybody who really needs 64-bit integers wouldn't be left hanging if regular longs were a mere 32 bits. After all, integer and long were always the same size in 32-bit mode, and now long and long long are both 64 bits. Either way, one of them is going to be redundant. But 'bigger is better', I guess - no matter what problems it causes. That's Microsoft's one redeeming quality - they understand that backward compatibility has value, and where possible they try to accommodate it.
Okay, end of rant. Oh wait. Does anybody know of a straightforward way to make the default application build environment on a recent 64-bit linux OS be 32-bit instead of 64-bit. I know about the -m32 compiler flag, but that doesn't always work if you're incorporating library stuff that wants you to run a ./configure script to figure out what the build environment is. Ideally, there would be an environment variable - or something else - that you could set to easily go back and forth between the two default modes. That way, if you're building some downloaded application, you can let it rip in 64-bit mode if you want, but still have the 32-bit default as an option.
32 and 64 bit legacy code (Score:2)
One of the legacy applications I maintain was written for 32 bits and the code is full of 32 bit dependencies. I tried several approaches to porting it to 64 bits and eventually gave up. Our new 64 bit systems require the 32 bit runtime if we want to run this particular application. No business case to rewrite it, though with what I know now I could do a much better job. The fundamental design issue with this application is that it was designed to do something else, then at the last minute it was hacked to
Re: (Score:3)
#define long int32_t
Nobody should be typing bare "int" or "long" these days, use properly sized type names for all new development.
Re: (Score:2)
So that's why longs are 64 bits when pointers are 64 bits on UNIX systems. It's not Linux that did this. It was the standard method, chosen back in the early 90s, from the first 64 bit UNIX systems like DEC OSF/1. DEC di
Re: (Score:2)
I would've said C - because, more than any other language, it allows you to "think like a computer".
But with all the consistency of an analog circuit with low signal:noise ratio.
Seriously dude: You're sitting there with a C++ compiler and only using 10% of its abilities. Add a few C++ idioms to your code and let the compiler take some of the burden from you.
stdint.h (Score:2)
stdint.h is your friend.
https://www.gnu.org/software/l... [gnu.org]
Re: (Score:2)
I would've said C - because, more than any other language, it allows you to "think like a computer".
Well, think like a PDP-11, anyway. The way modern computers work has grown increasingly distant from C's model.
Re: (Score:2)
I like Python. He likes Perl. All our production code is in C.
I'm a long-time Perl and C programmer (among quiet a few others) who also has enough Python to be able to debug/edit it. (once you learn a few languages, it pretty much boils down to syntax idiosyncrasies for other languages -- obviously w/exceptions). From what I can tell, just about anything you do in Perl/Python you can do in the other so learning both isn't really necessary unless required for a task. Perl's been around longer and that's why I learned it first (ie: I'm older), maybe that's true for yo
Re: (Score:2)
I've never understood this. Just use braces if you want, and write something to search and replace them with tabs as a preprocessor step. Yes, tabs. Spaces are for losers.
"Spaces are for losers." - Them's Fighting Words (Score:2)
I've never understood why space vs tabs is such an issue for some people. I still have nightmares where I had an employee who went over other employees' tested and committed code and changed tabs/spaces to their preference (I honestly can't remember which it was) - I can't tell you how many bugs that introduced as well as source miscompares between local and repository code.
Pick what you want to use and live and let live.
Re: (Score:2)
Re: (Score:2)
Sure. I wouldn't put tabs into a spaced project just as I expect anyone contributing code to one of my projects to use tabs. The great thing about (consistent) delimiters is you can change them to whatever you want though. Swapping tabs and spaces is a simple search and replace. If you want a context sensitive delimiter set like braces it's slightly more difficult, but not that bad.
Re: (Score:2)
Re: (Score:2)
Spaces are for losers.
Or for people who use languages with actual smart indentation.
Re: (Score:2)
I have used both Perl and Python for pretty uncomplicated stuff, but I am racking my brain about by which measure(s) Perl is substantially better than Python. Could you give me a hint what drives your boss' opinion?
Re: (Score:2)
Probably it was the first scripting language he had to write code in and you develop a fondness for it.
I'm in the same boat, I first worked with Perl and it just didn't seem worth the bother to move code over the Python.
Re: (Score:2)
Regexp integration is seamless in Perl, but a library in Python. So hacking something small together in Perl is quite a bit faster. That is the only thing I see, I like and use both. And for heavy lifting, Python modules written in C. Python is also a really nice glue-layer, while writing C modules in Perl is somewhat obscure.
Re: (Score:2)
Good answer. Now that you mention it, when I was using Perl regularly for simple tasks, I could just "perl -e" stuff combined with simple bash commands and get stuff done. As I moved to things to more complex tasks, I had to write that in a file to get it right, and the added costs of python were not significant.
Re: (Score:2)
Python: It is built around the idea that "there is only one way to do something" which is the dumbest philosophy for a programming language ever: the entire reason we have general purpose computers is so we can do multiple things with them. This is reflected in every aspect of the language design, for example using spaces as syntactically significant. A decision shared by MUMPS, btw [github.com]. That is something
Re: (Score:2)
Our Perl code is far more profitable than our Python code. The Python code requires more long term maintenance to keep up with current versions and that sometimes means moving to different libraries with associated rewrites. We don't have any old Python code running nearly unmodified yet we have plenty of 20 year old Perl code that is running nearly unmodified (we had to put \@ in quoted strings). The 20 year old Perl code runs on the latest version of Perl 5 (much of it runs unmodified on Perl 6/Raku too
Methodology? (Score:2)
My boss and I agree to disagree on this one. I like Python. He likes Perl. All our production code is in C. Neither
of us have any issue with that. In a past life we had lots of tools written in expect, based on tcl. Which one
colleague described as a theoretically-perfect computer science language you can't actually
do anything with.
When I mentioned node.js a couple of months ago my boss got apoplectic. I guess he had a bad childhood experience with it
or something. I have a similar response to java server pages. Don't ask.
I know that it's the internet, so everyone has strong opinions, but it seemed to me that the "Loved" vs. "Dreaded" numbers added up to near 100% on all of the spot-checks that I did.
I admit that we might dread having to work in languages we don't know, but really, I'm indifferent to all of those that I don't actually know anything about. So I dread ever working in VBA again, but for a solid chunk of the list, I have no opinion. I'm not even sure if I dread python, even though I really hate the whole white
Re: (Score:2)
I like Python. He likes Perl. All our production code is in C.
Well, Perl and Python *are* written in C, so...nothing would change. :)
Is language really that impacting to salary? (Score:2)
I have mixed feelings about seeing these articles posted. I guess on the one side I do find it interesting to hear which languages are trending, it's not something I'll ever likely search for myself. But I tend the question the correlation between a language and a salary. I'm probably over thinking it.
To me, if a relatively new language became really popular, and demand vs the number of developers in the wild makes finding candidates a challenge, I would assume the salary for opening positions using that
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
. As such, the salaries paid are quite high.
[citation needed]. I've looked for these high paying COBOL jobs, I couldn't find them. There are COBOL jobs, but they don't pay very much.
What, no LISP for most dreaded? (Score:2)
Re: (Score:2)
Well, judging from your spelling of "LISP", your comment arrived straight from the 1970s.
maybe the dev environments make LISP ok now
They were actually more than OK in the 1980s already, but most people couldn't afford them. Who knows what you were using, so...
Re: (Score:2)
They were actually more than OK in the 1980s already, but most people couldn't afford them. Who knows what you were using, so...
Pretty much using Emacs(GNU) on a Unix clone on VT220 terminals. At my university the CS department was a part of the math department and we were in the basement so I didn't get the impression people cared that much about it. Admittedly the TA showed me a bunch of Emacs commands that made it suck less but I'd rather code in C. (Since at least you got feedback from the compiler and lint.)
Re: (Score:2)
COBOL-on-the-cob (Score:2)
Here are popular programming languages.
Here are high-paying tech salaries, unconnected to skill in any of those languages.
What was the point again?
Language less important than application (Score:3)
Many of these types of articles tend to compare languages like they're somehow being applied to the same task, and that people should make their language choices based on personal preference rather than have this largely decided for them based on the kind of work they want to do. If someone starting out in the workforce is interested in things like CPU design, toolchain development, kernel development, then regardless of their personal thoughts on TypeScript, they better get comfortable with VHDL/Verilog, C and Assembly. If they want to build websites and they're still using C and Assembly, there may be something more fundamentally wrong than the choice of programming language. I would imagine that the people that don't like R, for example, are probably the same people who either don't like or aren't involved in statistical computing. Most people will have to learn a dozen different languages anyways simply throughout the course of their career. About the only thing this article gets right is people gravitating to workplaces that use languages and frameworks they like - in my experience, this has less to do with personal preference and more to do with not wanting to work for a company that forces you to use the wrong tool for the job. There is nothing more frustrating and demoralizing than having to waste time trying to get something done in a language that is simply a poor fit for the problem - some companies get this, others double down on doing things the same way they always have.
Re: (Score:2)
I don't do it for the money (Score:2)
The one that gits 'er done (Score:2)
I have a CPSC degree, too, but I'm basically a civil engineer, I was involved with heavy construction (replacing water/sewer mains) for 25 years; I designed the GIS database they were stored in, did a lot of web-based report pages where you could query the history of any infrastructure item with text or with a map-click.
I can barely call myself a "developer", I had engineering to do, and when IT's "official systems" failed to meet a need (constantly), I'd have to squeeze in some "stealth IT", my own solutio
Rust (Score:3)
Who are these people saying they love Rust the most despite never having no experience with it (assuming the survey response data is accurate). What is the reasoning here? "I heard it's cool, so I'll just say I love it the most!"
Re: Rust (Score:2)
Too many negatives, woops. Disregard the "no" in "despite never having no experience".
Re: Rust (Score:3)
If it was a good survey, it would give you the option to rank only the ones you report having experience with. Then, the only confound there is lying, but that's always a risk in any survey.
Re: (Score:2)
Bigger Question (Score:2)
Where did Stack Overflow find developers to survey?
math? (Score:5, Insightful)
Love? (Score:2)
Programming languages are cruel mistresses.
Does disliked language = more pay? (Score:2)
Hmm... I like Perl. And you say it's disliked?
Shouldn't I get paid more for a willingness to use a disliked language?
Self-selecting (Score:2)
I use SO frequently; I didn't even know they were having a survey and if I had I doubt I would have filled it in. What's the point of it, really?
It all rather leads one to wonder... (Score:2)
About the skill sets and fundamentals possessed (or rather not possessed) by those who responded to the survey.
That or they’re taking the piss.
Where's Prolog? (Score:3)
Re: (Score:2)
Being a contrarian to generate interesting hypotheses that are underconsidered is a good thing, but I have doubts about your idea here. Ultimately, the high pay comes from high demand compared to the supply of skilled practitioners. But the demand is ultimately driven by businesses who have a reasonable expectation that a certain technology stack will be successful enough for a business purpose. Unless we are talking about a legacy language like COBOL, there is no positive correlation between the expect
Re: (Score:3)
I have come to terms with the ones I get paid to use
Spot on. You may hate PHP, but if it puts food on the table you'll probably suck it up.
Re: (Score:2)
There's nothing wrong with hating programming languages. Even hating all of them.
There is however a massive problem with becoming a programmer anyway. Go find a job doing something you enjoy or you'll find yourself a bitter old fart who spent most their life doing something they hate, for money that can never buy back all the time and happiness it cost you.