Here We Go Again: Why Is It Difficult for Developers to Learn Another Prog Lang?
conf.researchr.org
conf.researchr.org
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.
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)
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 every single turn. (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.
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.
> 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).
[0] https://www.sciencedirect.com/science/article/pii/S088761851...
[1] https://insights.stackoverflow.com/survey/2019#technology
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.
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.
[0] https://www.youtube.com/user/TheChemlife/videos
[1] https://en.wikipedia.org/wiki/Map%E2%80%93territory_relation
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.
[1] http://www.oilshell.org/blog/2020/01/simplest-explanation.ht...
Also the spaces are required between the {} and commands in Bash which is another brainclunk to deal with.
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.
Instead, it's programming FrameworkDuJour(tm) in Javascript.
And the half-life of that is measured in months. So, the longer someone can drag their heels on learning FrameworkDuJour(tm), the better off they are.
You can know Javascript cold and still be useless at web programming.
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.
And that's completely fine. It's definitely a choice.
What I'm saying is that it's not difficult to learn. It's a cognizant choice that learning isn't worth the effort.
Or you can do a deep not-crap job in a context you've actually invested time and experience in.
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.
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.
But that's mostly just branding. They're essentially different frameworks.
... 6th Edition - ECMAScript 2015 7th Edition - ECMAScript 2016 8th Edition - ECMAScript 2017 9th Edition - ECMAScript 2018 10th Edition - ECMAScript 2019 ...
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.