Why is it difficult for developers to learn another programming language? [pdf](nischalshrestha.me)
nischalshrestha.me
Why is it difficult for developers to learn another programming language? [pdf]
http://nischalshrestha.me/docs/cross_language_interference.pdf
60 comments
My biggest problem learning a second language is that it's so much less useful than the first.
Ten years ago I learned C# and since then I've dabbled in other languages like Haskell or Lisp which were a little fun, but I keep getting drawn back to learning more about my stack. There's still decades of knowledge I lack about Azure/Entity Framework/Asp.Net/Xamarin/Sql Server/WPF/C# CMS/C# CRMS/C# e-commerce/Roslyn the opensource compiler/Blazor/Typescript/React/CSS. (Not to mention all of the useful soft skills, like sales/ marketing/negotiation/management)
And I'd rather be able to build out a desktop app, a web app, or a mobile app than be able to build out a web app in js-node/C#-mvc/ruby-rails/python-django.
Basically when I learn I want to be able build I couldn't before (like a mobile app) or get better at building(learn how to better optimize t-sql queries). And when I've spent time learning new languages I felt like it wasn't as useful at delivering on these two goals.
Ten years ago I learned C# and since then I've dabbled in other languages like Haskell or Lisp which were a little fun, but I keep getting drawn back to learning more about my stack. There's still decades of knowledge I lack about Azure/Entity Framework/Asp.Net/Xamarin/Sql Server/WPF/C# CMS/C# CRMS/C# e-commerce/Roslyn the opensource compiler/Blazor/Typescript/React/CSS. (Not to mention all of the useful soft skills, like sales/ marketing/negotiation/management)
And I'd rather be able to build out a desktop app, a web app, or a mobile app than be able to build out a web app in js-node/C#-mvc/ruby-rails/python-django.
Basically when I learn I want to be able build I couldn't before (like a mobile app) or get better at building(learn how to better optimize t-sql queries). And when I've spent time learning new languages I felt like it wasn't as useful at delivering on these two goals.
When I first learned Python, I found it hard understanding how another language could offer more.
What I found was learning other languages provided value in the form of insight which changed how I wrote my primary language.
JavaScript taught me about the value of concurrency, C# taught me the value of types and DI, TypeScript showed me the complexity of C# wasn't necessary, Go taught me that I code too much and say too little.
What I found was learning other languages provided value in the form of insight which changed how I wrote my primary language.
JavaScript taught me about the value of concurrency, C# taught me the value of types and DI, TypeScript showed me the complexity of C# wasn't necessary, Go taught me that I code too much and say too little.
I 100% agree. The first language I learned in highschool was VB6. I only went to VB .NET when VB6 stopped working.
I next learned PHP because it gave me superpowers on the web that VB couldn't. When Ruby on Rails became popular, then Node, I dabbled in learning those but I just couldn't get excited about them because it didn't give me any more capability than PHP already did.
I generally only tackle learning new things if it provides me immediate value to do so.
I next learned PHP because it gave me superpowers on the web that VB couldn't. When Ruby on Rails became popular, then Node, I dabbled in learning those but I just couldn't get excited about them because it didn't give me any more capability than PHP already did.
I generally only tackle learning new things if it provides me immediate value to do so.
> I generally only tackle learning new things if it provides me immediate value to do so.
In general I agree with you, but I think this is taking it a bit too far. My journey was similar, except PHP was my starting language and I was doing frontend (so HTML+CSS+JS) at the same time.
But, now I'm doing Clojure full-time. But not until I spent 2-3 years on-off learning it. It wasn't until 1.5 year ago I actually sat down and started writing things in Clojure.
But if I had the "only if it provides me immediate value" mindset, I would never have learned Clojure. It's not until now I'm more productive than I ever been, but that required a bit of uphill fighting.
But I'm so glad I stuck with it, now I can't imagine programming in something else. Which has ruined me a bit, but I'm happy with that.
In general I agree with you, but I think this is taking it a bit too far. My journey was similar, except PHP was my starting language and I was doing frontend (so HTML+CSS+JS) at the same time.
But, now I'm doing Clojure full-time. But not until I spent 2-3 years on-off learning it. It wasn't until 1.5 year ago I actually sat down and started writing things in Clojure.
But if I had the "only if it provides me immediate value" mindset, I would never have learned Clojure. It's not until now I'm more productive than I ever been, but that required a bit of uphill fighting.
But I'm so glad I stuck with it, now I can't imagine programming in something else. Which has ruined me a bit, but I'm happy with that.
I definitely understand your reasoning, but personally I don't see how I would be more productive by switching languages. Maybe I just don't know what I'm missing, but I feel pretty dang productive with my current stack. And I'm working on a long term project for 90% of my time, so even if I could be more productive, I don't think I could justify re-writing 40k LoC.
I also don't really get emotional over the language choice... I'd ditch PHP in a second if it made sense to, but IMO a good architecture can enable development speed FAR better than a good language can. The language choice mostly just comes down to syntax preferences.
To each their own.
I also don't really get emotional over the language choice... I'd ditch PHP in a second if it made sense to, but IMO a good architecture can enable development speed FAR better than a good language can. The language choice mostly just comes down to syntax preferences.
To each their own.
> , I don't think I could justify re-writing 40k LoC.
Absolutely, I agree with that as well! I would not rewrite something to a different languages unless there is a damn good reason for it. I'm not a person who generally rewrite stuff "for fun", so I think you're spot on here.
And I agree with you on the architecture/language comment as well, it's way more important. But I do think that the common practices of a language either helps/slows you down as well, so doing the same thing in two different languages can be implemented in different speeds.
> The language choice mostly just comes down to syntax preferences
Here is where I kind of disagree, but not fully. Yes, Java and C# are basically the same, in the end. Details are different, but mostly the same. Same goes for all languages in the Algol-group of languages, which C, JavaScript, Java, Python and more belongs to.
Then we have the Lisp-family of languages. They are very similar, within the group, but compared Lisp-like languages with Algol-like languages, the differences become way larger. Add languages like Erlang, which are way different, and you get some more differences.
So yeah, most of the language choices people do today, mostly come down to things around the language (ecosystem etc) rather than the language itself, because most people limit their choice to Algol-like languages.
In the end, I could not care less about the language you use, I'm not trying to force anyone to use what I find most productive. We all have preferences that speaks for us. But I wish someone tried to get me to dive into Lisp/Clojure earlier, and I think there are others who will feel the same, but again, I don't really care what others use.
Absolutely, I agree with that as well! I would not rewrite something to a different languages unless there is a damn good reason for it. I'm not a person who generally rewrite stuff "for fun", so I think you're spot on here.
And I agree with you on the architecture/language comment as well, it's way more important. But I do think that the common practices of a language either helps/slows you down as well, so doing the same thing in two different languages can be implemented in different speeds.
> The language choice mostly just comes down to syntax preferences
Here is where I kind of disagree, but not fully. Yes, Java and C# are basically the same, in the end. Details are different, but mostly the same. Same goes for all languages in the Algol-group of languages, which C, JavaScript, Java, Python and more belongs to.
Then we have the Lisp-family of languages. They are very similar, within the group, but compared Lisp-like languages with Algol-like languages, the differences become way larger. Add languages like Erlang, which are way different, and you get some more differences.
So yeah, most of the language choices people do today, mostly come down to things around the language (ecosystem etc) rather than the language itself, because most people limit their choice to Algol-like languages.
In the end, I could not care less about the language you use, I'm not trying to force anyone to use what I find most productive. We all have preferences that speaks for us. But I wish someone tried to get me to dive into Lisp/Clojure earlier, and I think there are others who will feel the same, but again, I don't really care what others use.
It's such a nice language I feel calm writing it
Maybe look at F# for something .net compatible. Personally its use in some contexts, particularly those using the F# type providers has served me well.
I also prefer to use FSX scripts over CSX in contexts where that is useful. I find my deeper knowledge of the .net infrastructure easier to leverage than having to learn powershell but FSX syntax also cleaner for scripting.
I also prefer to use FSX scripts over CSX in contexts where that is useful. I find my deeper knowledge of the .net infrastructure easier to leverage than having to learn powershell but FSX syntax also cleaner for scripting.
I've used f#. Type providers were really cool. And I like how terse it is but I feel like the gap is narrowing, and I couldn't ever use it on a real project. I'd feel guilty building a project for a client that is supportable by a tenth the number of developers without very good reason.
I'm generally an FP advocate but F# on the CLR has always been an uphill battle in terms of development of the language (especially lately) and providing a compelling case to outsiders to spend resources on F# over C#.
Does most of what you listed matter? Yeah - I know, it matters to make money(!). But it all looks really similar to me. If, instead, a new language taught you more about recursion or typing or a different way to view program structure, isn't that more valuable than learning the latest JS framework? or Azure? What does Azure really offer from a learning perspective? You know, I use TypeScript a lot, but it has taught me absolutely nothing fundamental, and has not made really made me better at anything other than Typescript. Playing around with something like Haskell made me think about some pretty fundamental structural and domain modelling questions, which I feel, although perhaps cannot prove, has been much more valuable.
I've spent a couple of weeks on Haskell and a couple of weeks on domain driven design and I felt like the latter made a larger impact on how I saw using code to model the domain.
> My biggest problem learning a second language is that it's so much less useful than the first.
Your IDE should work with you to make it more useful. For sure your knowledge of another language isn't going to be as great as your first language, but I've personally always relied on tooling around that language to tell me where I'm wrong, then I can go find out why it is that my IDE is complaining and I'll then decide whether the IDEs error makes sense or not.
Your IDE should work with you to make it more useful. For sure your knowledge of another language isn't going to be as great as your first language, but I've personally always relied on tooling around that language to tell me where I'm wrong, then I can go find out why it is that my IDE is complaining and I'll then decide whether the IDEs error makes sense or not.
You can also build your own .NET frameworks like ASP.NET or Entity Framework using reflection and expressions. All the tools that these frameworks use to analyze the structure of your code and dynamically compile new code are part of .NET. It's not as DSL friendly as something like Racket, but you can generally get your own DSL based on class, expression, and attribute analysis up and running if you put some time in. The .NET rabbit hole goes quite deep.
Hard to know if it's universal or just all the language designers being influenced by the same stuff.
Definitely both, in any software you take user expectations into consideration. Also all programming language designers are humans most of who know English, this gives a shared cultural context.
Well, there’s some of both. Languages all influence each other, and most of them are “inspired” by a specific parent or two - “D is Better C,” etc. But there are also a handful of core CS ideas and computer hardware characteristics that derive a lot of what computers can do and how to do it well, and that stuff shows up as pretty universal across many languages.
[deleted]
That's because you haven't stepped outside of the box. Most of the programming languages you learn are derived from Algol. So JAVA, C, C++, python, javascript are all essentially permutations of the same thing.
There's other families of languages like Prolog, ML and lisp that are drastically different and I have found that many people find these languages hard to learn.
There's other families of languages like Prolog, ML and lisp that are drastically different and I have found that many people find these languages hard to learn.
While you might be right, I've seen the same comments about people who did a thorough functional programming class and then having to learn another functional programming language later on.
Moreover, you don't know if the parent also did functional programming.
But I think your remark is a fair one, I think it's about wrapping your head around programming paradigms that are quite far from each other.
Moreover, you don't know if the parent also did functional programming.
But I think your remark is a fair one, I think it's about wrapping your head around programming paradigms that are quite far from each other.
Here's Peter Norvig's advice about different paradigms:
Learn at least a half dozen programming languages. Include one language that emphasizes class abstractions (like Java or C++), one that emphasizes functional abstraction (like Lisp or ML or Haskell), one that supports syntactic abstraction (like Lisp), one that supports declarative specifications (like Prolog or C++ templates), and one that emphasizes parallelism (like Clojure or Go).
(https://norvig.com/21-days.html)
Learn at least a half dozen programming languages. Include one language that emphasizes class abstractions (like Java or C++), one that emphasizes functional abstraction (like Lisp or ML or Haskell), one that supports syntactic abstraction (like Lisp), one that supports declarative specifications (like Prolog or C++ templates), and one that emphasizes parallelism (like Clojure or Go).
(https://norvig.com/21-days.html)
I wasn't just talking about functional. Prolog is a different paradigm all together.
This could probably be extrapolated further to say all programming on von Neumann architecture is fundamentally similar.
Actually no it can't. That be like extrapolating all expressions of language are fundamentally similar.
Is it? My personal experience makes me think that it isn’t. I’ve programmed professionally in eight languages if you count significant line changes, ten if you count any change. At this point changing editors is harder than changing programming languages.
Your first language is hard because you're learning a ton of things all at once, only one of which is the language itself.
Your second language is hard because it's not the first, even though it's probably pretty similar. But the differences will catch you out. A second language challenges the mental models you built up with the first language -- you have to tear some of your understanding down and come up with a more generalized perspective.
Languages similar to the first two become easier to pick up after this point, because you're mostly looking for a handful of differences, not a total paradigm shift. But languages that are sufficiently different, like C and Haskell, require a lot more of the ground-up type of work you thought you'd left behind by now.
It gets easier and easier as you cover more of the conceptual landscape. But I'd be willing to bet that many developers haven't had to journey far from home.
Your second language is hard because it's not the first, even though it's probably pretty similar. But the differences will catch you out. A second language challenges the mental models you built up with the first language -- you have to tear some of your understanding down and come up with a more generalized perspective.
Languages similar to the first two become easier to pick up after this point, because you're mostly looking for a handful of differences, not a total paradigm shift. But languages that are sufficiently different, like C and Haskell, require a lot more of the ground-up type of work you thought you'd left behind by now.
It gets easier and easier as you cover more of the conceptual landscape. But I'd be willing to bet that many developers haven't had to journey far from home.
I’d agree that similar languages are easier to learn, but once you’ve learned how to learn a programming language, new ones are easier, even if they’re dissimilar from your prior languages.
For the record, my professional work includes languages as dissimilar as PHP, Java, and Common Lisp, while my hobby hour work includes Rust and Haskell. That’s a pretty wide range of the language space that exists today, IMO.
For the record, my professional work includes languages as dissimilar as PHP, Java, and Common Lisp, while my hobby hour work includes Rust and Haskell. That’s a pretty wide range of the language space that exists today, IMO.
My language gamut is similar to yours -- I don't disagree. I usually find it straightforward to pick up something new too. But there are still languages I know are going to take a lot more time for me to grok, like Coq. (I tried Coq a few years ago, and even though I already knew a fair bit of Haskell, the differences were enough to completely throw me off.)
I agree with you. I think there are some problems with the study. For example "Does cross language interference occur?" Not only does it occur, but that's literally how you learn a new language. You make assumptions based on the languages you know. You write code. You notice that it doesn't work the way you expect. You try to understand what is different. It's by far the fastest way to learn a language rather than a problem.
The learning strategies of successful language learners show this: Learning on their own, Just in time learning, Relating new language to old langue. I would say that the "Language interferences" are just a product of the learning method. Putting yourself in the deep end and trying to swim always results in a little water in you lungs ;-)
The fact that it is challenging does not imply that it isn't desired. In fact there is a whole branch of skill acquisition theory called "desirable difficulties". While I think their theories of what would make the process better are interesting, I don't actually agree with their conclusion - that we should proceed as if their theories are correct.
The learning strategies of successful language learners show this: Learning on their own, Just in time learning, Relating new language to old langue. I would say that the "Language interferences" are just a product of the learning method. Putting yourself in the deep end and trying to swim always results in a little water in you lungs ;-)
The fact that it is challenging does not imply that it isn't desired. In fact there is a whole branch of skill acquisition theory called "desirable difficulties". While I think their theories of what would make the process better are interesting, I don't actually agree with their conclusion - that we should proceed as if their theories are correct.
It's easy to learn new languages, hard/slow to learn the ecosystem...
We should get better at creating mixed-ecosystems and cross-language libraries... the JVM was a step in the right direction but most new development completely forgot about that!
We should get better at creating mixed-ecosystems and cross-language libraries... the JVM was a step in the right direction but most new development completely forgot about that!
Agreed. There is also another problem: For example, I know that I can code with C# but I do not know what is the traditional workflow for designing a micro-service in .NET
You just do not know how to "Do things in the right way"
You just do not know how to "Do things in the right way"
Well Microsoft was facing an existential threat so invested in its own universal runtime.
As for languages designed after Java, many of them are responding against it. They don't want users to require slow startup costs, for example.
As for languages designed after Java, many of them are responding against it. They don't want users to require slow startup costs, for example.
The pure language features itself, is not hard to learn. This is just the tip of the iceberg.
It’s all the frameworks, and their undocumented features, that sometimes doesn’t make sense, but it’s the way it is done, which is what makes learning new languages hard to master.
It’s all the frameworks, and their undocumented features, that sometimes doesn’t make sense, but it’s the way it is done, which is what makes learning new languages hard to master.
On top of that there is also understanding the philosophy of a language. Learning python as my 3rd productive language was 3 full-time weeks, "Doing things the pythonic way" took years.
That is also why getting into frameworks is a bit hard for people who are used to do things without frameworks. Like people who stick with JQuery and find Angular hard, because you have to do stuff "Angular way". You can write a lot of javascript and switch to typescript but "Angular way" is yet another thing to learn.
I can write python and understand the code, know some quirks but for large code base I would probably be lost because I don't know "python ways".
I can write python and understand the code, know some quirks but for large code base I would probably be lost because I don't know "python ways".
This comment could not be upvoted enough. There is a massive productivity level difference between someone who has mastered their expertise in a language's ecosystem and someone who is just coming to the language but able to understand the "linguistics"/syntax quickly (usually because they carry some similarity to an already known PL).
This is not even considering all the little "gotchas" each language will have. Although, Stackoverflow et al. help ease this a bit.
This is not even considering all the little "gotchas" each language will have. Although, Stackoverflow et al. help ease this a bit.
I think the title should have been: When it's difficult to learn a new language, why is that?
Some paths are easier than others so it really depends on the new language and where someone is coming from. I started with PHP/JS on a self taught basis. Then I started to develop interest in other languages. Python was a no-brainer, C++ looked quirky but okay, in Java most thing looks familiar. But functional languages get me. Rust is another beast, but totally looks tamable.
Haven't finished the article yet, but it has some great insights.
Some paths are easier than others so it really depends on the new language and where someone is coming from. I started with PHP/JS on a self taught basis. Then I started to develop interest in other languages. Python was a no-brainer, C++ looked quirky but okay, in Java most thing looks familiar. But functional languages get me. Rust is another beast, but totally looks tamable.
Haven't finished the article yet, but it has some great insights.
My anecdotal data appears to point to the opposite. My first language (JS) involved learning:
- What is even programming? What is a function? an argument? What is state? What are types? - JS itself - How browsers work - JQuery (do people still use that?) - NodeJs - How backends work - How databases work
Then, the subsequent language, Java, was only different in patterns, paradigms, keywords, and frameworks (at least, at the amateur level I was going at). Args were still args, strings were strings, sure we had classes instead of functions here and there, but for a beginner it was close enough. Java, the second language, was far easier to learn. And so forth, with each language becoming progressively simpler.
- What is even programming? What is a function? an argument? What is state? What are types? - JS itself - How browsers work - JQuery (do people still use that?) - NodeJs - How backends work - How databases work
Then, the subsequent language, Java, was only different in patterns, paradigms, keywords, and frameworks (at least, at the amateur level I was going at). Args were still args, strings were strings, sure we had classes instead of functions here and there, but for a beginner it was close enough. Java, the second language, was far easier to learn. And so forth, with each language becoming progressively simpler.
JS is a really horrible language to learn from the perspective of a teacher.
So many concepts dumped on you all at once. Before you even know what a function is, you have the entire DOM API dumped on you and is available in the global scope.
If you try to learn OOP in it, you have the choice of trying to grapple with the leaky ES6 class keyword or you get prototypal inheritance and `this` will come up.
That said, from a learner's perspective it's great: you have the entire DOM available to you instead of having to learn how to take the car of the cdr of a list and wondering how that has anything to do with building the next Airbnb/Uber of this world...
At least with Python/Ruby they commit hard to terseness / fluent interfaces so you have less syntactic noise to deal with, and Haskell commits hard on equational reasoning so you can pick up computation if you've come from a mathsy background. Or Scheme which is as close as you can get to "no syntax" as you can (IMO)
So many concepts dumped on you all at once. Before you even know what a function is, you have the entire DOM API dumped on you and is available in the global scope.
If you try to learn OOP in it, you have the choice of trying to grapple with the leaky ES6 class keyword or you get prototypal inheritance and `this` will come up.
That said, from a learner's perspective it's great: you have the entire DOM available to you instead of having to learn how to take the car of the cdr of a list and wondering how that has anything to do with building the next Airbnb/Uber of this world...
At least with Python/Ruby they commit hard to terseness / fluent interfaces so you have less syntactic noise to deal with, and Haskell commits hard on equational reasoning so you can pick up computation if you've come from a mathsy background. Or Scheme which is as close as you can get to "no syntax" as you can (IMO)
I used to teach programming with JS. It was not really a blocker for me at any level. When we hit some quirks I stopped to explain why this is and how it's different in other languages.
Maybe because I like JS made me enjoy teaching it as well :)
Maybe because I like JS made me enjoy teaching it as well :)
I actually quite like JS, but I almost feel bad for people who discover it as their first foray into programming.
I mean it's great because it makes programming more accessible to non devs. But man is it unfortunate that JS was the language that ended up being the language of the web.
The browser is the ultimate interactive development environment. You can literally play with the page in situ. Akin to CAD and Excel (...or Emacs[0])
[0]https://www.gnu.org/gnu/rms-lisp.html
I mean it's great because it makes programming more accessible to non devs. But man is it unfortunate that JS was the language that ended up being the language of the web.
The browser is the ultimate interactive development environment. You can literally play with the page in situ. Akin to CAD and Excel (...or Emacs[0])
[0]https://www.gnu.org/gnu/rms-lisp.html
Don't feel bad, my first language I've ever written programs in was C-64 basic :)
I don't know what would have been a better choice, but JS is not bad for a browser language. It had a rough childhood, but turned out to be a decent adult.
I still remember VB Script supported in old IE, but then there was JS and I just focused on that. It really made no difference to me since I was able to build cool stuff I wanted to. That brought me joy of creation and that's what mattered, not "that's not OOP like god set in stone".
Whatever enables people to be more involved in programming, I consider it as a good thing.
I don't know what would have been a better choice, but JS is not bad for a browser language. It had a rough childhood, but turned out to be a decent adult.
I still remember VB Script supported in old IE, but then there was JS and I just focused on that. It really made no difference to me since I was able to build cool stuff I wanted to. That brought me joy of creation and that's what mattered, not "that's not OOP like god set in stone".
Whatever enables people to be more involved in programming, I consider it as a good thing.
Ha fun!
I've had the order switched. I'd argue that you had an easier time. Why? Chrome Dev tools and loosely typed (avoids some beginner questions that'll have easy answers when you have a bit more experience). Also, NodeJS encourages exploring the commandline, Eclipse doesn't.
I've had the order switched. I'd argue that you had an easier time. Why? Chrome Dev tools and loosely typed (avoids some beginner questions that'll have easy answers when you have a bit more experience). Also, NodeJS encourages exploring the commandline, Eclipse doesn't.
Can we just call "cross-language interference" an "accent"?
When I code VBA macros, I pile up all of the "End If" and other compiler noise in column 80, with comments.
Because I'd really rather be coding Python.
When I code VBA macros, I pile up all of the "End If" and other compiler noise in column 80, with comments.
Because I'd really rather be coding Python.
Title is a little misleading as it seems to imply that programmers find it difficult to learn another language. But there is no such implication in the study. The study really seems to be about specific language features that can contribute to making it harder/easier to pick up.
What i struggle the most when coming to a new language is the tooling that comes with it.
And how do I structure my code in this new language. Sure some things are universal, but some things are just hard to find out.
The js ecosystem is an especially tough example for this.
My CS college program made me take a programming language fundamentals class. I still remember it. The class was one of the most difficult classes. We had to learn 4 programming language paradigms: imperative, declarative, object-oriented, and functional. In each paradigm, we learned to write programs in a chosen language.
I find the experience very useful for my software career. It helps me learn new programming languages quickly. When I see functional operators, I remember Haskell.
I'd recommend to master one language in different paradigms. It pays dividends.
https://en.wikipedia.org/wiki/Comparison_of_programming_para...
I find the experience very useful for my software career. It helps me learn new programming languages quickly. When I see functional operators, I remember Haskell.
I'd recommend to master one language in different paradigms. It pays dividends.
https://en.wikipedia.org/wiki/Comparison_of_programming_para...
I had a class that was even more intense, CSC324H at the University of Toronto. We learned Scheme emphasizing on higher-order functions, ML emphasizing on static typing, Haskell emphasizing on lazy evaluation, and Prolog emphasizing on {Horn clauses, unification, backtracking}. All in the span of a 12-week semester.
Circumstances and expectations might be different. When starting on your first language, was different than the second, and different from your third, etc.
Your first language, you know you don't know much. So you try out and play with it. If you're unlucky, you get stuck, don't get the books, software or help that would make you proceed (ie. machine code for C64), so would need something else or give up altogether. For some experiences, you just need to know the right people, be in the right circumstances.
On your second language, you probably already seen program listings in several languages already. You expect to get up and running after a few hours. This might happen if the paradigms are the same. For a completely different paradigm, you could need to grind it over time or start over as a beginner in that paradigm again.
Also, for many, learning new languages, frameworks etc. are not the fun part anymore, so get less emphasis on playfulness and spending time with it. When preference is on being productive, one might miss many big opportunities.
Your first language, you know you don't know much. So you try out and play with it. If you're unlucky, you get stuck, don't get the books, software or help that would make you proceed (ie. machine code for C64), so would need something else or give up altogether. For some experiences, you just need to know the right people, be in the right circumstances.
On your second language, you probably already seen program listings in several languages already. You expect to get up and running after a few hours. This might happen if the paradigms are the same. For a completely different paradigm, you could need to grind it over time or start over as a beginner in that paradigm again.
Also, for many, learning new languages, frameworks etc. are not the fun part anymore, so get less emphasis on playfulness and spending time with it. When preference is on being productive, one might miss many big opportunities.
I think this depends a lot on the developer.
Some Devs I work with want to dabble with many tools and solve problems by picking (or creating) a new tool rather than learning how to solve problem with existing tool. They learn, and are talking about (and trying to get team to adopt) other languages all the time.
Personally, I want to totally master a small number of tools. (perhaps just my inability to master many). So, it's not that I find it hard to learn new lang. It's I'm unwilling to waste effort on it unless there is advantage. And to overcome the mastery I have attained after 25 years of Python that advantage has to be large. [btw Past langs include VisualBasic, Pascal, PHP, C, C++, and PERL. But only PERL did I use long enough for mastery]
Neither is obviously better/correct. Like I said, it depends on how the developer best works.
Some Devs I work with want to dabble with many tools and solve problems by picking (or creating) a new tool rather than learning how to solve problem with existing tool. They learn, and are talking about (and trying to get team to adopt) other languages all the time.
Personally, I want to totally master a small number of tools. (perhaps just my inability to master many). So, it's not that I find it hard to learn new lang. It's I'm unwilling to waste effort on it unless there is advantage. And to overcome the mastery I have attained after 25 years of Python that advantage has to be large. [btw Past langs include VisualBasic, Pascal, PHP, C, C++, and PERL. But only PERL did I use long enough for mastery]
Neither is obviously better/correct. Like I said, it depends on how the developer best works.
My anecdotal evidence is exactly opposite to the paper. I would expect the title of the paper to appear as a headline trotted out in some mass media publication with the article written by a journo that dabbled in BASIC in high school and decided that programming and software development wasn't for him. Maybe I've forgotten what it is like to not be able to program, in the same way I don't understand how to not swim, or how to not ride a bike, or how to not read and write, but learning a new language, learning it well, to be facile in the language and the standard APIs that come with the language (ignoring the tens of thousands of obscure little npm packages in javascript for instance) is not a huge amount of work.
What is really important when learning a new language is just forget any idioms you learned the last time! Know how computers work, and have a general knowledge about memory management, data structures, algorithms and clean code, but try to understand the new language's idioms. You will have an easier time and make less mistakes.
For example, there are typical mistakes when a C or Java programmer uses Python for the first time, I can tell somebody's history just by looking at what idioms they try to force on Python which shouldn't.
Example for C programmer writing Python:
For example, there are typical mistakes when a C or Java programmer uses Python for the first time, I can tell somebody's history just by looking at what idioms they try to force on Python which shouldn't.
Example for C programmer writing Python:
for i in range(len(mylist)):
print(mylist[i])
Not really true, it gets easier the more languages you learn.
I do know of developers who spent their whole working lives using only one language and they are very good at that one language. (I am thinking of MUMPS and the developers I met when working in the medical s/w field)
Should we just learn one language and do we gain by knowing many and why are there so many languages that do the same thing?
If there were to be one language what would it look like?
https://en.wikipedia.org/wiki/MUMPS
I write JavaScript and python daily. I'm fairly fluent in many languages including C++.
The only language/platform I'm having difficulty with is Swift and MacOS (Cocoa)! It's a pile of ancient junk and 5 versions of a new language with absolutely turd documentation from the platform and a gigantic pile of "meh works for me". It feels like trying to run in moving sands with your eyes closed and your hands tied.
I'm only saying this to make a point: sometimes it's not the developer having a hard time as much as the ecosystem making it a living hell.
The only language/platform I'm having difficulty with is Swift and MacOS (Cocoa)! It's a pile of ancient junk and 5 versions of a new language with absolutely turd documentation from the platform and a gigantic pile of "meh works for me". It feels like trying to run in moving sands with your eyes closed and your hands tied.
I'm only saying this to make a point: sometimes it's not the developer having a hard time as much as the ecosystem making it a living hell.
In terms of your career, it's better to become an expert at one language than a jack of all trades. I can quickly move from language to language, but make the most money as a consultant for languages in which I'm an expert.
I also think many developers use a single language for work and don't have much time after work to learn another one.
I also think many developers use a single language for work and don't have much time after work to learn another one.
It isn't in my experience. A list of languages I have used professionally: C, C++, Java, C#, Javascript, Typescript, Assembler (PowerPC), SQL, ... And for fun: Basic, Pascal, Haskell, Lisp, Scheme, Idris, Assembler (Z80 and I86), ... Only Haskell was hard to learn (but most definitely worth it).
In my opinion it is all down to muscle memory. When you don't even need to think about whether this class will behave one way or another, you just know that if you type it this way it will work without a doubt.
I mostly get stuck on the function, func, fun, void, def, etc.
Most other stuff is very similar.
Most other stuff is very similar.
Edit: after reading the paper I understand the emphasis is on conceptual mistakes people make when coming from one language into another - you assume things work like A and make mistakes when B works differently under the hood and you don’t realize it until banging your head against it for a while.
That experience does ring true, but I stand by my original comment, this is mostly only an issue for language #2, and with each language it gets easier as you begin to think more in universal terms and have fewer assumptions and gaps where you’ve been accustomed to something that “just works” in the environment you’re most familiar with.