IMO, most of the difficulty comes due to developers having full-time jobs programming in languages they already know. Learning a new language takes a few weeks of focused effort, then a few months of practice using the language almost exclusively to really solidify it.
That's almost never possible while employed: most employers aren't paying their developers to spend weeks-months to learn a new language they aren't already using. It's only in extreme cases where a business decides to change for some reason that they'll pay for the training and require devs to take the time to learn & practice. It does happen (my employer did this, swapped the backend from Java to Go, and paid every dev, even non-backend devs, to take training) but it's rare and expensive so there needs to be a very good reason for it.
Many developers (if not most, I have no real data) don't program much outside work, and even if they do they'll keep going back to work and reinforcing the existing language's style in their minds.
It takes time and effort. Maybe not a whole ton of time, especially if the languages are of similar paradigm (OO, functional, procedural, etc), but that's time and effort many wouldn't want to put in on their own.
Interesting. I think there are more factors at play here. Learning a new language has a definite "cognitive cost". One issue is the perception of banality/drudgery i.e. lack of excitement/motivation involved in learning a language which is not too different (computation modelwise) from what you already know. As an example, having worked with C/C++ for a long time i just cannot summon the motivation to learn Python/JS etc. They are "boring". The constant comparison of features/syntactic sugar soon becomes tiresome. And subconsciously you feel that the effort/payoff ratio is not worth it until external circumstances force a change (eg. a new project requiring the language).
I think it is better to be fluent in one or two languages so that you can focus on the problem without bothering about other incidental complexities. The only time where the effort in learning a new language is worth it is when you learn a new model of computation/thinking that expands your mind (eg. Erlang, Haskell, Mozart/Oz)
I think there is a fallacy that people can pick up a new language in short time. If you know C, you will write C code in the new language for a while. It takes quite a while to pick up the new concepts. Good documentation geared towards experienced developers would be very helpful.
Learning Rust is a good example. Sure, you can learn the borrow checker and other stuff fairly easily. Patterns are fine. Error checking was a bit more iffy before "?".
And then you try to build a doubly linked list and the language fights you at everysingleturn. (for good reason, but it fights you nonetheless).
Nobody expects that. That's the kind of thing that languages often aren't good at documenting.
Personally I see this a lot in normal interview style questions. They are geared towards an imperative approach, find this thing in a 2d matrix based on some way of manipulating the indexes is a common example. If you try a functional approach it is possible but often times akward or super dense looking code much like the double linked list example above.
I feel like this comes from the fact that while languages are extremely easy to bend into a shape that fits the problem and take a long time to learn so it's often easier for programmers to put out a bad solution instead trying to get the problem and the language to meet in the middle.
This line from the abstract is the key takeaway for me:
> The interviews revealed that programmers make failed attempts to relate a new programming language with what they already know.
This is the map-territory problem. Folks think that they know the territory (computation) because they know a map (one particular language). I find it telling that some programmers explicitly used cheat sheets to literally map their understanding from one map of the territory to another.
Folks are too quick to think that something is alien just because they do not understand it. A moment's reflection will assure us that every programming language ever used by people has also been invented by people. The feeling of alienation that folks have upon encountering a new language is entirely only a feeling, although understandably perhaps fear of the unknown is the most fundamental fear [0].
I personally know about a half-dozen languages for my daily work, and I suspect that that is also the case for most other programmers; I am not the sort of person that learns new languages for no reason. But the paper only shows small slices of each investigated programmer's thought processes, because it only shows one or two old languages for each new language being learned. I wonder to what degree there are common languages that are used perhaps as linguafranca (e.g. that two-thirds of us know JS and two-fifths know Python [1]) or for the ambient semantics of computation (e.g. that most programs are written with C's behavior in mind).
The interviews revealed that programmers make failed attempts to relate a new programming language with what they already know.
I've seen this a lot in shell code while working on Oil [1]. For example, ${array} means ${array[0]} in bash and ksh-derived shells. That is, if you don't put an index on array, it evaluates to the first element in an array.
This is a weird semantic that basically no other language has. And it's been true for decades, and is documented. But people still report bugs about it on the bash mailing list (I saw on a few days ago).
I got rid of this behavior in Oil for exactly that reason, along with fixing tons of other warts, while remaining compatible. You can opt back in with 'shopt --set compat_array'.
Another issue is using (a; b) to mean grouping when { a; b; } is technically more correct. () starts a subshell in addition to doing grouping. You wouldn't really know unless you mutate a variable in the group -- it will show up in one case but not the other.
The wart where ; is required before } and not ) doesn't help.
---
So shell is full of surprises, and Oil is meant to be more comfortable for programmers coming from say Python, JS, or Ruby. People bring those expectations to shell, and they get frustrated with it.
> A moment's reflection will assure us that every programming language ever used by people has also been invented by people.
Not at all. We produce chemicals by splicing the code to produce them into bacteria, culturing the bacteria, and harvesting the chemical. This is obviously an application of programming, and just as obviously uses a language not invented by people. We use it anyway, mostly by application of copy-and-paste.
Okay, so the contention is that humans did not invent the design of DNA, and thus we did not invent programming with DNA. However, we invented animal husbandry several millennia before finding the structure of DNA, and we invented the concept of genetics to discuss and manipulate traits a century before we isolated DNA's low-level structure. Even today, knowing how DNA works, we usually program at the level of genes; see e.g. [0] where a Youtuber is doing genetic manipulation and programming.
This is the same sort of map-territory situation [1] as in my original post. The RNA World [2] is the territory, and genetics is our map.
I switched from C++ to Java at one point in my career (fortunately long in the past). I remember sweating after several hours of trying to put my head in the different environment, coming home shaking and exhausted.
After 2 weeks it got better, and I think I got pretty good at it.
The good news: switching back to C++ took only a few days, no sweating. It was 2 days before I remembered about header files, and thought "What the hell? Oh yeah" but that was about it.
The only talent developers who I have encountered who have learning another programming language are those who don't want to learn it.
JavaScript being a great example. I know a lot of developers who would rather spend hours picking about the language itself, rather than just learning how to use it.
This is mainly older developers, in my experience, who have seen "the hot new thing" many times in their career, so they no longer want to put in the effort to learn something new - instead choosing to explain why it's a fad.
frameworks have been beaten to death, but it's bigger than that, the whole language morphs almost every year. Just a table of contents from Wikipedia article:
You can't even _name the language_ you are programming in without some mind-bending mental gymnastics. Even the names of the standards have off-by-one with their year. Do I program in ES6 or ECMAScript2015? ES6 is certainly not the same as just general colloquial "Javascript". I've recently worked with people who program professionally in Javascript and even React, and have not heard of ES6, and pump out apps and features that are completely incompatible with ES6, let alone later standards (and those are standards! not just some random library)
And even frameworks themselves morph every year too, React with function components looks nothing like React a couple of years ago, and linters will barf at half the React methods that have been deprecated from just a couple of years ago, it's insane.
This is sooo true. By staying on the back-end for a few years, I managed to avoid front-end JavaScript long enough to watch Angular come and go.
Unfortunately, React has had quite a bit more staying power and I ended up having to pick up some proficiency with it. That said, the ecosystem evolves enough that no two projects ever seem to use the same tooling.
> It's a cognizant choice that learning isn't worth the effort.
They're very often not wrong. If you're trying to optimize for learning new concepts instead of new implementations (particularly when said implementations are ephemeral), then the right choice is usually to ignore the latest stuff unless it becomes an absolute necessity to adopt it.
And most 'cutting edge' frameworks can be picked up in around a week or two once you have experience anyway. I remember it taking me about 4 working days to get the hang of RoR (with ~2 yrs of professional experience).
Most developers would be better served spending their time learning soft skills around productivity, networking/politicking, communication, writing, and otherwise living well-balanced lives with the rest of their time. Hell even doing Leetcode is probably a better use of time than picking up the latest framework.
That's all you got? Developer should just be sophisticated and experienced in every new thing immediately?
We can all get by and pick up anything well enough to do a functional job, and we can all apply some bits of general experience in any language or other domain.
But you confuse that with an actually good job?
I submit that you just outed youself as never having done an actually good job.
What you call "AngularJS" used to be referred to as just "Angular". Then Angular v2 and later were so different that Angular v1.x became known as AngularJS.
But that's mostly just branding. They're essentially different frameworks.
It is very easy to become jaded about the continuous onslaught of new technologies. However the flaws in JavaScript are right there, in your face as soon as you start using it.
That's almost never possible while employed: most employers aren't paying their developers to spend weeks-months to learn a new language they aren't already using. It's only in extreme cases where a business decides to change for some reason that they'll pay for the training and require devs to take the time to learn & practice. It does happen (my employer did this, swapped the backend from Java to Go, and paid every dev, even non-backend devs, to take training) but it's rare and expensive so there needs to be a very good reason for it.
Many developers (if not most, I have no real data) don't program much outside work, and even if they do they'll keep going back to work and reinforcing the existing language's style in their minds.
It takes time and effort. Maybe not a whole ton of time, especially if the languages are of similar paradigm (OO, functional, procedural, etc), but that's time and effort many wouldn't want to put in on their own.