Yeah, this barely scratches the surface of the topic, but learning a new runtime is imo much more difficult than learning a new language. Historically languages were 1:1 with runtimes, but in the past decade we’ve seen an explosion of compilers which piggyback a new language on an existing ecosystem.
From personal experience, I found that the runtime matters much more than the language. When I learned OCaml coming from Clojure, it went pretty quickly despite having absolutely no experience with static type systems, currying, or ML-style syntax. But learning ClojureScript from Clojure (practically the same language!) was an enormous headache to do even basic things because the runtime was extraordinarily complex.
There is a world of difference between “I wrote something successfully” and becoming fluent in all of the above and more, which is what you want when working professionally. And that is by far where the bulk of your learning time will be spent.
I think we sometimes betray ourselves. A classic way to see that is when we call something weird/quirk/odd, when it’s really just different to what we are used to. I think programming languages are often taught and even more often learned the wrong way, where one start out with already known languages and concepts and tries to build a mental map of “equivalents”.
This leads to unidiomatic, quirky looking code and what’s worse is that when a language becomes popular it can lead to many libraries be programmed in a style of other programming languages and a big crowd constantly asks variations of “Why isn’t it like in language X”?
While sometimes that’s a valid question, it can also lead to a situation where all languages follow trends and end up with huge amounts of baggage and every project and developer does things differently depending on from which language they came from and when they switched.
I think it’s bad, because like with all technologies a loss in diversity can reduce innovation and is self-reinforcing, as more people are used to the same thing, think about problems the same way, and use and program tools to do so as well.
It can be very eye-opening to first try a purely functional language, like Scheme or Lisp or something like Smalltalk, even Tcl, and others, because the approach they take is different from what many people are used to. However, when languages are considered the same with just slight “taste” variations of syntax and concepts are ignored, maybe have to be ignored, because the language is approached out of an emergency (the last developer left, the system we use has a bug, etc.) the concepts are skipped and one might never learn to actually think in that language. Something similar happens when one buys a bad book, article or video on a language. It’s usually a lot better to go for official sources, or the language’s designers writing books.
Don’t get me wrong, it’s good to learn from other languages, their mistakes, etc., but considering something “odd” tends to be a hint that either ones understanding isn’t good or that it’s baggage and it can sometimes make one a better developer understanding it. On top of that it is another piece of experience that helps one to choose the right tool.
At least that’s what I tend to see with young languages - young for a programming languages can be one or two decades. When they become very popular that’s great for support, but it tends to be a really harsh time for idiomatic code, libraries, discussions on the future of a language, quality of documentation, etc.
I also think that programmers are way too often “forced” to use a language or think that they are. This leads to the above and hating certain languages. I’d think it’s also not good for the developer not for whoever their customer or employer is.
Maybe it would be better to make sharper distinction of proficiency. Knowing how to program in comparison to being a programmer could maybe be a bit more like knowing how to write, vs being an author and the same should go for programming languages. When there’s a CV with a ton of “I know this language” I’m skeptical. While it can be true for some languages, people and contexts, maybe interests it can also be a strong indication that this persons knows no language well, and doesn’t bother to, and will have troubles once a harder problem that can’t just be searched on Stack Overflow comes up.
Also if I’m a good example, I think one underestimates how quickly one stops at being good at a language, while using another one for a while. I think that’s a large part why old languages feel weird, and I wonder why people would switch to it. If you recently got comfortable with a language and are at a point where you didn’t hit many of its shortcomings or even finally managed to overcome them in your day to day work everything else might be weird.
So in other words: There are a lot more factors to consider when wondering what makes something weird.
I am finding it very hard to program in languages with explicit memory allocation. I’m trying to write a SAT solver in C but it is much more difficult than a language with support for algebraic data types and lists.
It’s not, the tooling and the quirks however..
Yeah, this barely scratches the surface of the topic, but learning a new runtime is imo much more difficult than learning a new language. Historically languages were 1:1 with runtimes, but in the past decade we’ve seen an explosion of compilers which piggyback a new language on an existing ecosystem.
From personal experience, I found that the runtime matters much more than the language. When I learned OCaml coming from Clojure, it went pretty quickly despite having absolutely no experience with static type systems, currying, or ML-style syntax. But learning ClojureScript from Clojure (practically the same language!) was an enormous headache to do even basic things because the runtime was extraordinarily complex.
100%. @hwayne’s The Hard Part of Learning a Language resonates strongly with my experience. Truly learning a language includes stuff like:
There is a world of difference between “I wrote something successfully” and becoming fluent in all of the above and more, which is what you want when working professionally. And that is by far where the bulk of your learning time will be spent.
to have the pdf this link is behind a paywall would be better replaced https://cacm.acm.org/magazines/2022/3/258915-here-we-go-again/fulltext
Updated!
I think we sometimes betray ourselves. A classic way to see that is when we call something weird/quirk/odd, when it’s really just different to what we are used to. I think programming languages are often taught and even more often learned the wrong way, where one start out with already known languages and concepts and tries to build a mental map of “equivalents”.
This leads to unidiomatic, quirky looking code and what’s worse is that when a language becomes popular it can lead to many libraries be programmed in a style of other programming languages and a big crowd constantly asks variations of “Why isn’t it like in language X”?
While sometimes that’s a valid question, it can also lead to a situation where all languages follow trends and end up with huge amounts of baggage and every project and developer does things differently depending on from which language they came from and when they switched.
I think it’s bad, because like with all technologies a loss in diversity can reduce innovation and is self-reinforcing, as more people are used to the same thing, think about problems the same way, and use and program tools to do so as well.
It can be very eye-opening to first try a purely functional language, like Scheme or Lisp or something like Smalltalk, even Tcl, and others, because the approach they take is different from what many people are used to. However, when languages are considered the same with just slight “taste” variations of syntax and concepts are ignored, maybe have to be ignored, because the language is approached out of an emergency (the last developer left, the system we use has a bug, etc.) the concepts are skipped and one might never learn to actually think in that language. Something similar happens when one buys a bad book, article or video on a language. It’s usually a lot better to go for official sources, or the language’s designers writing books.
Don’t get me wrong, it’s good to learn from other languages, their mistakes, etc., but considering something “odd” tends to be a hint that either ones understanding isn’t good or that it’s baggage and it can sometimes make one a better developer understanding it. On top of that it is another piece of experience that helps one to choose the right tool.
At least that’s what I tend to see with young languages - young for a programming languages can be one or two decades. When they become very popular that’s great for support, but it tends to be a really harsh time for idiomatic code, libraries, discussions on the future of a language, quality of documentation, etc.
I also think that programmers are way too often “forced” to use a language or think that they are. This leads to the above and hating certain languages. I’d think it’s also not good for the developer not for whoever their customer or employer is.
Maybe it would be better to make sharper distinction of proficiency. Knowing how to program in comparison to being a programmer could maybe be a bit more like knowing how to write, vs being an author and the same should go for programming languages. When there’s a CV with a ton of “I know this language” I’m skeptical. While it can be true for some languages, people and contexts, maybe interests it can also be a strong indication that this persons knows no language well, and doesn’t bother to, and will have troubles once a harder problem that can’t just be searched on Stack Overflow comes up.
Also if I’m a good example, I think one underestimates how quickly one stops at being good at a language, while using another one for a while. I think that’s a large part why old languages feel weird, and I wonder why people would switch to it. If you recently got comfortable with a language and are at a point where you didn’t hit many of its shortcomings or even finally managed to overcome them in your day to day work everything else might be weird.
So in other words: There are a lot more factors to consider when wondering what makes something weird.
Learning your second language might be hard, but learning a 4th or 5th should be much easier.
Like a lot of other commenter point out, though, runtimes/standard libraries bear much more cognitive load
One of the only Paul Graham essays I truly like “Beating the Averages” has an interesting take on this problem.
Edit: specifically the “The Blub Paradox” part.
I am finding it very hard to program in languages with explicit memory allocation. I’m trying to write a SAT solver in C but it is much more difficult than a language with support for algebraic data types and lists.
My main languages at work are Elixir and Haskell.