4 ms·

I do believe that learning many programming languages is overrated Learn concepts, obtain foundational computer science knowledge, write complex projects not

I do believe that learning many programming languages is overrated Learn concepts, obtain foundational computer science knowledge, write complex projects not just get familiar with somebody's interpretations that they implemented as a language. Languages that I used besides my job language barely gave me anything, in most cases they made me appreciate more for sane environment (package managers, IDEs, debuggers, strong standard library) edit. just to be clear: I don't see value in learning C#+Java+PHP, but C#+Erlang? yea I do see value in learning Rust after C but still - concepts are more important, you don't have to learn langs in order to be familiar with concepts Learn software engineering - it's broad as hell and you can easily do that using one language

wildrhythms 4y ago
When I was in undergrad our professor had us learn Java, but also Lisp and Prolog, and that was very valuable to my growth as an aspiring (and now thankfully employed) programmer :)
- tester756 4y ago
  Don't get me wrong, I'm not saying that there's no value in programming languages I'm saying that programming languages aren't they only way to get familiar with concepts
  - green_on_black 4y ago
    I agree, but certain concepts exist strongly at the language level. Like functional programming, Haskell for example: the power of static typechecking along with good type inference, or functional/immutable patterns, or programs as data (IO monad). Or Prolog and logic-based declarative programming. Or any GC'd language. Or a Lisp and its metaprogramming. I daresay these ideas would be very difficult to see the practical use of, or "impractical" beauty of, without touching the languages.
  - RHSeeger 4y ago
    Nobody said they're the only way. But they _are_ a very good way, for a variety of reasons (which have already been discussed here).
chrisseaton 4y ago
> Learn concepts, obtain foundational computer science knowledge Well yeah learning a wide variety of languages is a good way to do that. People write new languages because they want to implement new concepts.
- tester756 4y ago
  >Well yeah learning a wide variety of languages is a good way to do that. Well, depends what concepts are you talking about. Computer science is huge as hell, concepts that you may learn from programming languages are just subset. There's a lot of interesting and hard stuff that does not touch those (I'm not focusing on some domain-specific-languages that nobody know about)
  - BlargMcLarg 4y ago
    And god forbid if you want to learn things outside CS, too. Like you know, most people.
  - chrisseaton 4y ago
    But learning languages is a great way to learn many concepts. Obviously it doesn’t teach you everything - nobody claimed that. Want to learn concurrency? Try a concurrent language. Parallelism? Learn a parallel language. Data flow? Learn a data flow language. Pattern matching? Learn a language with pattern matching. Etc for a thousand useful subjects to learn. These are great ways to learn so many software engineering concepts. Use other techniques to learn other things sure.
    - hardware2win 4y ago
      Are you actually learning X when your lang has strong and easy to use primitives for that, so you dont have to understand how does it work? eg async await You are just learning tool like Excel
      - chrisseaton 4y ago
sandreas 4y ago
+1. I once wrote an article exactly describing this[1]... but I think that learning concepts involves learning different languages because the concepts are not implemented the same way in every language and seeing different implementations helps understanding the nuances and differences a lot. [1]: https://pilabor.com/blog/2021/05/learn-concepts-not-frameworks/ https://pilabor.com/blog/2021/05/learn-concepts-not-framewor...
deltasevennine 4y ago
>but still - concepts are more important, you don't have to learn langs in order to be familiar with concepts You kinda do. Concepts are often exclusive to languages. And often concepts can't be internalized without practice of that lang. Your own examples in your edit literally contradict what you say as you chose langs with extremely divergent concepts. C# and Erlang, Rust and C. You missed haskell and lisp.
- tester756 4y ago
  >Your own examples in your edit literally contradict what you say as you chose langs with extremely divergent concepts. C# and Erlang, Rust and C. You missed haskell and lisp. How so? You can learn and understand concepts implemented in Rust without learning Rust
  - deltasevennine 4y ago
    Concepts aren't just "learned" by reading about it. True learning requires internalization. Internalization requires practice. Practice requires the concepts to be applied. Application requires real world tools. Usage of tools requires one to learn about the tools. If the only tool available is rust, then one must learn rust to truly learn the concepts related to it.
    - ttfkam 4y ago
      100% agree. And the Rust compiler is a great way to internalize those lessons since it shows what you got wrong, where you missed an ownership assignment, and often telling you how to fix the problem in plain English. It's as close as I've found to an actual teacher while writing code. When the compiler stops yelling at you all the time, you'll get your feedback that you've actually learned those lessons.
xigoi 4y ago
How are you supposed to learn concepts like higher-order functions if you only know C, for example?
- hardware2win 4y ago
  If mathematicans did it, then why we, computer people wouldnt?
  - rosetremiere 4y ago
    In my opinion, having it baked it into a language you use allows a sort of internalization of the concept by practice/use. You don't just get the idea, but get a feel for it.
- wiseowise 4y ago
  Read about them?
  - xigoi 4y ago
    What is that good for if you can't use them for anything?
    - wiseowise 4y ago
      What is that good for in other language if your day job is in C?
      - xigoi 4y ago
        You know, there are programmers that don't code only as their job, or don't even have a (programming) job.
- scns 4y ago
  The book Functional C by Hartel & Muller. https://www.semanticscholar.org/paper/Functional-C-Hartel-Muller/31acb7abaf3a1962b27be9faa2322038d1ac9ed7 https://www.semanticscholar.org/paper/Functional-C-Hartel-Mu...
barrkel 4y ago
Concepts can often be simulated in many languages, but only clumsily, and the lack of ergonomic affordances in syntax, control flow and type systems can lead one to believe that a different paradigm doesn't work very well - it can be hard to see the wood for the trees. It's hard to write a declarative querying library in C. SQL is not an ideal language, but as a way of expressing intent rather than a physical query plan, it's a long way away from C. It's hard to appreciate the power of interactive debugger REPLs like binding.pry or JS's debugger without experiencing them. A C++ debugger, even a Java debugger, is a pale imitation, and it's not easy to simulate the experience without building a dynamic language inside the static language. If all you've ever known is statically typed languages, you can suffer from a myopic parochialism with respect to dynamic typing. IMO the most popular statically typed languages only work well because they have runtime polymorphism holes in their type systems. More powerful statically typed programming languages tend to grow ever more esoteric typing constructs to enable static types to follow dynamic control and data flow - there's an inherent tension there and if language complexity isn't carefully managed, it becomes harder to express intent and error messages get more vague and cryptic. Algebraic data types and pattern matching tends to be under-appreciated if one is schooled in object-oriented languages. Object orientation has a big hammer for switching control flow based on data values, dynamic dispatch, and architectures tend to leverage dynamic dispatch where they would be much better off with switch statements. If the set of variants is known up front, you're probably much better off with sum types and pattern matching than with interfaces, abstract classes and virtual methods.
- adra 4y ago
  It's interesting you bring up REPLs. I never in 20 years working have ever worked with one. I switched jobs and a few people are coco in love with them. This probably more than anything else comes down the programmer style. I had to use Jupiter notebook to help my wife learn programming Python and it was horrific. I could never imagine that real work was done in this way, but I know many good programmers that swear by it. I suppose that when I need something like a REPL, I tend to use my debugger instead.
  - P5fRxh5kUvp2th 4y ago
larve 4y ago
This is pretty much the point of the article. I have a few reasons to work in (not just learn) close languages. The languages might use roughly similar concepts and syntax and solve similar problems (think, C++, C#, PHP, Java, Go), yet their community, practices, tooling, frameworks are wildly different. If as a C++ developer in 2005 you never experienced how smooth debugging and profiling could be in Java, how fast things could compile, how easy it was to drop a jar and deploy to your server farm, you were missing out. Similarly, if as a Go developer you don’t know how quickly you can install WordPress, write a 200 line PHP plugin, and get an entire business off the ground, you are missing out. Most transformational for me was to be a Common Lisp developer, and find the language that allowed the ideas and concepts in my brain to be turned into prototype at the speed of thought. It’s a challenging language to use in the real world, but it really brought the point home that a language is just a vessel for ideas.
Aperocky 4y ago
It's overrated in a sense that it isn't that much of a chore, learning a new language is easy if you're already good at software engineering.
FpUser 4y ago
I agree that it is way more valuable to know / being able to invent concepts, algorithms, architectures. That is what interests me most when I design software products for my clients and for my own company. Languages for me are just tools, like screwdrivers. I use / used many and do not get hung up. And no I do not learn languages just for the fuck of it. Only if I see some positive ROI.
Syzygies 4y ago
My name is Dave, and I'm an addict. Charlie Watts wasn't just into jazz, he was into all music. George Harrison understood that jazz could deepen him as a musician, but found Indian music. If one wants to write a language that is truly original, that might actually influence the future, not just smearing around familiar weightings for features found useful "in the trades", then one wants to have some grasp of languages representative of every language in use. Then, only proceed with a compelling vision of what's missing. For the rest of us, being a language junkie can be a problem. Without being judgmental, it is possible for a person to be too promiscuous. Same with languages. I wish I could just stick to Haskell and get work done.

wildrhythms 4y ago

When I was in undergrad our professor had us learn Java, but also Lisp and Prolog, and that was very valuable to my growth as an aspiring (and now thankfully employed) programmer :)

tester756 4y ago
Don't get me wrong, I'm not saying that there's no value in programming languages I'm saying that programming languages aren't they only way to get familiar with concepts
- green_on_black 4y ago
  I agree, but certain concepts exist strongly at the language level. Like functional programming, Haskell for example: the power of static typechecking along with good type inference, or functional/immutable patterns, or programs as data (IO monad). Or Prolog and logic-based declarative programming. Or any GC'd language. Or a Lisp and its metaprogramming. I daresay these ideas would be very difficult to see the practical use of, or "impractical" beauty of, without touching the languages.
- RHSeeger 4y ago
  Nobody said they're the only way. But they _are_ a very good way, for a variety of reasons (which have already been discussed here).

chrisseaton 4y ago

> Learn concepts, obtain foundational computer science knowledge Well yeah learning a wide variety of languages is a good way to do that. People write new languages because they want to implement new concepts.

tester756 4y ago
>Well yeah learning a wide variety of languages is a good way to do that. Well, depends what concepts are you talking about. Computer science is huge as hell, concepts that you may learn from programming languages are just subset. There's a lot of interesting and hard stuff that does not touch those (I'm not focusing on some domain-specific-languages that nobody know about)
- BlargMcLarg 4y ago
  And god forbid if you want to learn things outside CS, too. Like you know, most people.
- chrisseaton 4y ago
  But learning languages is a great way to learn many concepts. Obviously it doesn’t teach you everything - nobody claimed that. Want to learn concurrency? Try a concurrent language. Parallelism? Learn a parallel language. Data flow? Learn a data flow language. Pattern matching? Learn a language with pattern matching. Etc for a thousand useful subjects to learn. These are great ways to learn so many software engineering concepts. Use other techniques to learn other things sure.
  - hardware2win 4y ago
    Are you actually learning X when your lang has strong and easy to use primitives for that, so you dont have to understand how does it work? eg async await You are just learning tool like Excel
    - chrisseaton 4y ago

sandreas 4y ago

+1. I once wrote an article exactly describing this[1]... but I think that learning concepts involves learning different languages because the concepts are not implemented the same way in every language and seeing different implementations helps understanding the nuances and differences a lot. [1]: https://pilabor.com/blog/2021/05/learn-concepts-not-frameworks/ https://pilabor.com/blog/2021/05/learn-concepts-not-framewor...

deltasevennine 4y ago

>but still - concepts are more important, you don't have to learn langs in order to be familiar with concepts You kinda do. Concepts are often exclusive to languages. And often concepts can't be internalized without practice of that lang. Your own examples in your edit literally contradict what you say as you chose langs with extremely divergent concepts. C# and Erlang, Rust and C. You missed haskell and lisp.

tester756 4y ago
>Your own examples in your edit literally contradict what you say as you chose langs with extremely divergent concepts. C# and Erlang, Rust and C. You missed haskell and lisp. How so? You can learn and understand concepts implemented in Rust without learning Rust
- deltasevennine 4y ago
  Concepts aren't just "learned" by reading about it. True learning requires internalization. Internalization requires practice. Practice requires the concepts to be applied. Application requires real world tools. Usage of tools requires one to learn about the tools. If the only tool available is rust, then one must learn rust to truly learn the concepts related to it.
  - ttfkam 4y ago
    100% agree. And the Rust compiler is a great way to internalize those lessons since it shows what you got wrong, where you missed an ownership assignment, and often telling you how to fix the problem in plain English. It's as close as I've found to an actual teacher while writing code. When the compiler stops yelling at you all the time, you'll get your feedback that you've actually learned those lessons.

xigoi 4y ago

How are you supposed to learn concepts like higher-order functions if you only know C, for example?

hardware2win 4y ago
If mathematicans did it, then why we, computer people wouldnt?
- rosetremiere 4y ago
  In my opinion, having it baked it into a language you use allows a sort of internalization of the concept by practice/use. You don't just get the idea, but get a feel for it.
wiseowise 4y ago
Read about them?
- xigoi 4y ago
  What is that good for if you can't use them for anything?
  - wiseowise 4y ago
    What is that good for in other language if your day job is in C?
    - xigoi 4y ago
      You know, there are programmers that don't code only as their job, or don't even have a (programming) job.
scns 4y ago
The book Functional C by Hartel & Muller. https://www.semanticscholar.org/paper/Functional-C-Hartel-Muller/31acb7abaf3a1962b27be9faa2322038d1ac9ed7 https://www.semanticscholar.org/paper/Functional-C-Hartel-Mu...

barrkel 4y ago

Concepts can often be simulated in many languages, but only clumsily, and the lack of ergonomic affordances in syntax, control flow and type systems can lead one to believe that a different paradigm doesn't work very well - it can be hard to see the wood for the trees. It's hard to write a declarative querying library in C. SQL is not an ideal language, but as a way of expressing intent rather than a physical query plan, it's a long way away from C. It's hard to appreciate the power of interactive debugger REPLs like binding.pry or JS's debugger without experiencing them. A C++ debugger, even a Java debugger, is a pale imitation, and it's not easy to simulate the experience without building a dynamic language inside the static language. If all you've ever known is statically typed languages, you can suffer from a myopic parochialism with respect to dynamic typing. IMO the most popular statically typed languages only work well because they have runtime polymorphism holes in their type systems. More powerful statically typed programming languages tend to grow ever more esoteric typing constructs to enable static types to follow dynamic control and data flow - there's an inherent tension there and if language complexity isn't carefully managed, it becomes harder to express intent and error messages get more vague and cryptic. Algebraic data types and pattern matching tends to be under-appreciated if one is schooled in object-oriented languages. Object orientation has a big hammer for switching control flow based on data values, dynamic dispatch, and architectures tend to leverage dynamic dispatch where they would be much better off with switch statements. If the set of variants is known up front, you're probably much better off with sum types and pattern matching than with interfaces, abstract classes and virtual methods.

adra 4y ago
It's interesting you bring up REPLs. I never in 20 years working have ever worked with one. I switched jobs and a few people are coco in love with them. This probably more than anything else comes down the programmer style. I had to use Jupiter notebook to help my wife learn programming Python and it was horrific. I could never imagine that real work was done in this way, but I know many good programmers that swear by it. I suppose that when I need something like a REPL, I tend to use my debugger instead.
- P5fRxh5kUvp2th 4y ago

larve 4y ago

This is pretty much the point of the article. I have a few reasons to work in (not just learn) close languages. The languages might use roughly similar concepts and syntax and solve similar problems (think, C++, C#, PHP, Java, Go), yet their community, practices, tooling, frameworks are wildly different. If as a C++ developer in 2005 you never experienced how smooth debugging and profiling could be in Java, how fast things could compile, how easy it was to drop a jar and deploy to your server farm, you were missing out. Similarly, if as a Go developer you don’t know how quickly you can install WordPress, write a 200 line PHP plugin, and get an entire business off the ground, you are missing out. Most transformational for me was to be a Common Lisp developer, and find the language that allowed the ideas and concepts in my brain to be turned into prototype at the speed of thought. It’s a challenging language to use in the real world, but it really brought the point home that a language is just a vessel for ideas.

Aperocky 4y ago

It's overrated in a sense that it isn't that much of a chore, learning a new language is easy if you're already good at software engineering.

FpUser 4y ago

I agree that it is way more valuable to know / being able to invent concepts, algorithms, architectures. That is what interests me most when I design software products for my clients and for my own company. Languages for me are just tools, like screwdrivers. I use / used many and do not get hung up. And no I do not learn languages just for the fuck of it. Only if I see some positive ROI.

Syzygies 4y ago

My name is Dave, and I'm an addict. Charlie Watts wasn't just into jazz, he was into all music. George Harrison understood that jazz could deepen him as a musician, but found Indian music. If one wants to write a language that is truly original, that might actually influence the future, not just smearing around familiar weightings for features found useful "in the trades", then one wants to have some grasp of languages representative of every language in use. Then, only proceed with a compelling vision of what's missing. For the rest of us, being a language junkie can be a problem. Without being judgmental, it is possible for a person to be too promiscuous. Same with languages. I wish I could just stick to Haskell and get work done.