6 ms·

It's perfectly possible to know several languages in-depth. It just takes a lot of time and effort. Moreover, it gets easier with time and practice. Knowing N l

It's perfectly possible to know several languages in-depth. It just takes a lot of time and effort. Moreover, it gets easier with time and practice. Knowing N languages makes learning N+1 language just a bit easier. For me the turning point was around N == 10, since when learning a new language - and yes, in-depth, including idioms, stdlib, some external libraries, maybe some framework (if needed), and also some facts about the implementation and its inner workings[1] - takes a week at most, and for simpler cases a weekend is enough. OTOH, it took around 15 years to get there. I understand that this kind of dedication may not be possible or worth it for everyone. [1] Because there is very, very little unique features to each language. Unless you go to the fringes, you're bound to see the same concepts applied again and again and again, which gets really disheartening after a while. If you don't believe me, try naming any "new" feature which was added to your favorite (EDIT: I meant mainstream - TIOBE top 10 or 20 - lang here!) language recently - and I'll show you that same feature implemented 10 or 20 years ago in another language(s). EDIT: more neutral wording.

deleted 8y ago
[deleted]
chaosite 8y ago
I mean, I basically agree with you, but I like your challenge. What about Rust's borrow checker? I considered it novel, but I'd love to find out it was stolen from somewhere.
- dhash 8y ago
  Rust’s borrow checker was inspired by clean [1], which applied the same semantics to monads to allow in-place updates [1] https://en.m.wikipedia.org/wiki/Clean_(programming_language) https://en.m.wikipedia.org/wiki/Clean_(programming_language)
  - skrebbel 8y ago
    Clean is not a mainstream language.
    - leadingthenet 8y ago
      He didn't claim it would be, though. He just said, for every feature implemented in a top20 lang, you can already find it implemented somewhere else, 10-20 years ago.
      - skrebbel 8y ago
        That holds for every mainstream X. It makes the challenge ridiculous. Here's a challenge: come up with something that people generally think is fundamentally new. Given enough HN commenters, someone will present an example of how something super similar to that thing was already there 20-30 years prior.
        matt_kantor 8y ago
        > That holds for every mainstream X I thought that was exactly the point klibertp was making. The paragraph starts like this: > Because there is very, very little unique features to each language. Unless you go to the fringes, you're bound to see the same concepts applied again and again and again
        klibertp 8y ago
        > That holds for every mainstream X. It makes the challenge ridiculous. But that was the point... :( Or put another way, the major languages only include the "middle of the road", conservative features: mostly safe, uncontroversial, and well-specified and tested (it's all "mostly", "approximately" so, there are obvious exceptions). There is a limited supply of such features, which makes all the major languages have non-trivial amounts of overlap in terms of concepts or implementations. Moreover, even if one language implements a truly unique feature, it gets copied the next day (to where it makes sense), leading to even more similarity between languages. The other part of what I'm saying is that if you research and learn as many unpopular languages as you can today - right now - you'll be covered (in terms of having to learn new features in your job's PL) for at least the next decade without any additional effort.
- klibertp 8y ago
  I think it comes from Clean language or maybe Cyclone or other safe-C dialects. Not 100% sure though - I gave up on Rust some time back due to the churn and still didn't get to go back to it :( - and anyway, at this point the borrow checker is more than 10 years old, so hardly a new feature :D
blub 8y ago
I don't doubt it's possible. What I do doubt, is that it's possible to know several languages in-depth and at the same time be at least very good in a specific domain (webdev & mobile apps are not domains), have good algo and problem-solving skills, have decent to good soft skills, know at least a little bit of PM and also be a good conversation partner and well informed citizen of the world, while also being a good husband/wife/dad and being reasonably competent at some hobby that is hopefully not related to computers. Learning and keeping up to date with the N+1th language takes space from learning the many other interesting things this world has to offer.
- klibertp 8y ago
  Yeah, it's a matter of personal choice. My choice was to forgo any hobbies unless they are somehow useful for programming, ignore most of being "well-informed citizen of the world", ignore the whole mating and breeding business and to focus solely on programming at first, then on programming-related fields that picked up my curiousity. I'm still competent enough in other programming- and work-related areas - at least I've never been told otherwise - but, indeed, half of what you write about is nonexistent in my life. Actually, if there was a monastery for programmers, with ascetic lifestyle and good broadband connection to the Internet, I'd go there in a heartbeat. OTOH, I don't think you'd need to go to such lengths normally. As a programmer, you'll be working for 40 years at least, right? 30 minutes of reading a day will eventually get you to the respectable N (if you choose this particular field), it'll just take longer. The OP said the fact that he learned multiple languages makes him fall behind his peers in coding tasks. I'm saying that he would have no such problems had he learned these languages in-depth and it's perfectly possible to do so. I admitted immediately that the effort needed for this is at least substantial, no disagreement here - I just pointed out that, after that initial effort of consistently learning N languages for 2*N years, the following languages become very easy to pick up. That's it :)
  - Retric 8y ago
    Even then, I don’t think you can ever really learn even one mainstream language in depth. For something as ‘simple’ a C every compiler is slightly different and includes different flags and run on different CPU generations and this stuff is constantly evolving. A language like Java has a giant and evolving standard library plus multiple compilers etc. And that’s ignoring any simply popular libraries etc. Really learning what you can safely ignore in whatever context is the most important part, everything past the basics is domain specific. Having said that, I have read several language specifications which can be useful for general understanding. But, that’s simply the tip of the iceberg.
rb808 8y ago
Define know though. A C++/Java programmer can quickly write some Python code but isn't Pythonic. To me being able to write a program in a language doesn't mean you can write some code in it, you also have to know the paradigm its supposed to be used, as well as the layout styles, build tools, commonly used libraries etc etc. Even learning a new library often takes months alone.
- another-dave 8y ago
  Yes! Exactly. Oftentimes I look for "X for Y developers" style tutorials to try and fasttrack that for myself (e.g. npm ≈ Maven but this is how they differ), but high quality ones can be hard to come by & takes a long time to fully grok a new language
skrebbel 8y ago
Structural typing wasn't around in mainstream languages before Go and TypeScript.
- matt_kantor 8y ago
  I assume you were taking klibertp up on this: > try naming any "new" feature which was added to your favorite (EDIT: I meant mainstream - TIOBE top 10 or 20 - lang here!) language recently - and I'll show you that same feature implemented 10 or 20 years ago in another language(s). This is a fun game and I'll answer for them on this one: OCaml (1996) has structural types.
throwaway34241 8y ago
I think this is true for just learning the language alone. But for the type of productivity the grandparent post is talking about the language ecosystem can be a bigger challenge, at least for me. It wasn't in academia, but I spent a while working on one of the major native front end platforms almost exclusively and had the opportunity to get very familiar with it. And by 'familiar' I don't mean just knowing where to look things up, I mean knowing many of the exact APIs by heart, and having a wide variety of things I could just type in (without much looking things up) even if it involved working with images, network requests, JSON, file IO, string processing, dates/scheduling, collections, serialization, menus, windows, controls, input, drawing, sound, etc. Another big thing was when there are multiple ways do the same thing, having done it both ways and having direct experience of why one choice will likely be more effective in general or for a particular project. This can apply to choosing libraries/frameworks or app architectural decisions. I noticed I missed this level of familiarity quite a lot when I switched to a different ecosystem later. Maybe this is worse for native UI development because of the large API surfaces. But I found needing to consult the documentation again to be a lot slower. Having had that experience has kind of made me wonder about full-stack vs specialization, and optimal-language-for-the job vs standardizing (although of course some languages are totally inappropriate for some jobs). At least in my own experience I found sticking with the same language for a while to have continuing productivity benefits well beyond the 1 week/month period.
- throwaway34241 8y ago
  And for a specific example of the sort of ecosystem stuff I am talking about, to save/load some local data on iOS you have some API options: Core Data SQLite NSArchiver NSKeyedArchiver NSUserDefaults JSON Property lists Protocol buffers stdio NSData memory-mapped files Realm This is without getting into anything too obscure. This list is probably also out of date.
- klibertp 8y ago
  > But for the type of productivity the grandparent post is talking about the language ecosystem can be a bigger challenge, at least for me. My claim was that: > learning a new language - and yes, in-depth, including idioms, stdlib, some external libraries, maybe some framework (if needed), and also some facts about the implementation and its inner workings[1] - takes a week at most I also tried to define "learning in-depth" in another post: > To me, 'knowing in depth' (as a language user) means that no matter the question, you know where to [quickly] search for the answers. There's no need to remember the answers themselves, although it kind of happens naturally with repetition anyway. > On the other hand, it's also important to know which questions are not worth answering. [ie. what to ignore while learning] And I stand by it: I believe that there's no need to memorize too many details to be productive, you just need to be able to quickly and accurately find the relevant details, no matter which details are they. Various docs indexes and viewers, your IDE features, cheatsheets printed on a wall - all of that can help you if you forget a bit of syntax or a signature of a function. There's nothing, other than just reading a book or two, to help you if you don't understand a crucial concept in a language or the architecture of the library/framework. Also, all these concepts are reused all over the place. For example: "Io is a purely-object-oriented language with prototypal inheritance which allows objects to have many parents." Each word here has a meaning, and that meaning is (well, mostly) standard across most programming languages. With this description, if you know all the words, you just learned 3/4 of all there is to Io OO. Another example: "Dylan is a purely-object-oriented language which is class-based, allows multiple inheritance, and also decouples methods from classes by relying on generic functions, which use multiple dispatch - similar to CLOS." This one is longer, but it's still a single sentence, which conveys most (or if you're familiar with CLOS - all) of the characteristics of Dylan's object system. Sure, there are obviously more features in Dylan that you need to know before you start coding... but they are all defined with a single sentence. It takes half an hour to go through them all, and - again, if you know the exact meaning of each word - at this point you know more about the language than a beginner programmer would learn in a year or two. > I mean knowing many of the exact APIs by heart I was like this in the past, so I know what you're talking about. Unfortunately, my epilepsy makes my memory reset significantly from time to time - I can't do it, or at least not for long. It caused a loss of productivity for a bit, but it went back up when I started using well-configured tools. This is why my definitions of "knowing in-depth" above are what they are - I live them, for better or worse. > (without much looking things up) even if it involved working with images, network requests, JSON, file IO, string processing, dates/scheduling, collections, serialization, menus, windows, controls, input, drawing, sound, etc. Yes, that's what tends to happen with repetition - unless your memory is impaired in some way - you just remember things. There's nothing else than repetition that can get you to that point, which also means you "only" need repetition to get there. In other words, it happens naturally with time, provided you consistently work with the given tech stack, and that you use it for the various things you mention. But again: good tooling makes the rote memorization mostly unnecessary, and I really don't see many benefits of keeping all the idiosyncrasies of the whole stack in your head. It's completely different story if you code in Notepad without Internet access, though. Further, all the things you mention are implemented in all general-purpose languages. Moreover, most implementations look really similar. In almost all languages "network requests" are built upon sockets - an OS-level mechanism. Images are more tricky because of decoding/encoding (which is handled almost everywhere by simply linking to libjpeg & co.), but after that they're 3-dimensional int array/vector/list/what-have-you (yes, there are other representations - and yes, they are all implemented across most PLs and have very similar characteristics everywhere). "file IO", too, is based upon OS-provided streams, or a crippled reimplementation thereof. It's the same everywhere. "collections" are almost language-agnostic: the names and interfaces may (slightly) differ, but the underlying data structures are the same everywhere. "input", "windows", "controls", "drawing" are event-based everywhere, and almost all languages have bindings to all the GUI frameworks. You can write GTK+ app in Python just as well as in OCaml or C# (even though GTK itself is C (I think?)) - and you'll get the same names and signatures, even. You'll see for yourself in the decades to come - you're likely to switch the stack at least a few times by the time you retire. You'll see that most divisions in programming are illusions and - quite simply - matters of taste/personal preference, while in reality the differences between the popular languages, stacks, framework and systems are miniscule. > Another big thing was when there are multiple ways do the same thing, having done it both ways and having direct experience of why one choice will likely be more effective in general or for a particular project. This can apply to choosing libraries/frameworks or app architectural decisions. These are mostly language-neutral - the exact same considerations apply when deciding on library/framework or approach in every single language. > I noticed I missed this level of familiarity quite a lot when I switched to a different ecosystem later. Maybe this is worse for native UI development because of the large API surfaces. But I found needing to consult the documentation again to be a lot slower. It could be because of lack of proper helpers in your editor etc., but either way: if you stick with the new stack, you'll learn it naturally with time. You'll forget some of the previous stack (although I'm frequently surprised how I can recall specific quirks in technologies from 20 years ago.), which is also natural. Memory just seems to work this way. It'll take a few months to remember all the relevant details - less if the new tech is similar to something you already know.

deleted 8y ago

[deleted]

chaosite 8y ago

I mean, I basically agree with you, but I like your challenge. What about Rust's borrow checker? I considered it novel, but I'd love to find out it was stolen from somewhere.

dhash 8y ago
Rust’s borrow checker was inspired by clean [1], which applied the same semantics to monads to allow in-place updates [1] https://en.m.wikipedia.org/wiki/Clean_(programming_language) https://en.m.wikipedia.org/wiki/Clean_(programming_language)
- skrebbel 8y ago
  Clean is not a mainstream language.
  - leadingthenet 8y ago
    He didn't claim it would be, though. He just said, for every feature implemented in a top20 lang, you can already find it implemented somewhere else, 10-20 years ago.
    - skrebbel 8y ago
      That holds for every mainstream X. It makes the challenge ridiculous. Here's a challenge: come up with something that people generally think is fundamentally new. Given enough HN commenters, someone will present an example of how something super similar to that thing was already there 20-30 years prior.
      - matt_kantor 8y ago
        > That holds for every mainstream X I thought that was exactly the point klibertp was making. The paragraph starts like this: > Because there is very, very little unique features to each language. Unless you go to the fringes, you're bound to see the same concepts applied again and again and again
      - klibertp 8y ago
        > That holds for every mainstream X. It makes the challenge ridiculous. But that was the point... :( Or put another way, the major languages only include the "middle of the road", conservative features: mostly safe, uncontroversial, and well-specified and tested (it's all "mostly", "approximately" so, there are obvious exceptions). There is a limited supply of such features, which makes all the major languages have non-trivial amounts of overlap in terms of concepts or implementations. Moreover, even if one language implements a truly unique feature, it gets copied the next day (to where it makes sense), leading to even more similarity between languages. The other part of what I'm saying is that if you research and learn as many unpopular languages as you can today - right now - you'll be covered (in terms of having to learn new features in your job's PL) for at least the next decade without any additional effort.
klibertp 8y ago
I think it comes from Clean language or maybe Cyclone or other safe-C dialects. Not 100% sure though - I gave up on Rust some time back due to the churn and still didn't get to go back to it :( - and anyway, at this point the borrow checker is more than 10 years old, so hardly a new feature :D

blub 8y ago

I don't doubt it's possible. What I do doubt, is that it's possible to know several languages in-depth and at the same time be at least very good in a specific domain (webdev & mobile apps are not domains), have good algo and problem-solving skills, have decent to good soft skills, know at least a little bit of PM and also be a good conversation partner and well informed citizen of the world, while also being a good husband/wife/dad and being reasonably competent at some hobby that is hopefully not related to computers. Learning and keeping up to date with the N+1th language takes space from learning the many other interesting things this world has to offer.

klibertp 8y ago
Yeah, it's a matter of personal choice. My choice was to forgo any hobbies unless they are somehow useful for programming, ignore most of being "well-informed citizen of the world", ignore the whole mating and breeding business and to focus solely on programming at first, then on programming-related fields that picked up my curiousity. I'm still competent enough in other programming- and work-related areas - at least I've never been told otherwise - but, indeed, half of what you write about is nonexistent in my life. Actually, if there was a monastery for programmers, with ascetic lifestyle and good broadband connection to the Internet, I'd go there in a heartbeat. OTOH, I don't think you'd need to go to such lengths normally. As a programmer, you'll be working for 40 years at least, right? 30 minutes of reading a day will eventually get you to the respectable N (if you choose this particular field), it'll just take longer. The OP said the fact that he learned multiple languages makes him fall behind his peers in coding tasks. I'm saying that he would have no such problems had he learned these languages in-depth and it's perfectly possible to do so. I admitted immediately that the effort needed for this is at least substantial, no disagreement here - I just pointed out that, after that initial effort of consistently learning N languages for 2*N years, the following languages become very easy to pick up. That's it :)
- Retric 8y ago
  Even then, I don’t think you can ever really learn even one mainstream language in depth. For something as ‘simple’ a C every compiler is slightly different and includes different flags and run on different CPU generations and this stuff is constantly evolving. A language like Java has a giant and evolving standard library plus multiple compilers etc. And that’s ignoring any simply popular libraries etc. Really learning what you can safely ignore in whatever context is the most important part, everything past the basics is domain specific. Having said that, I have read several language specifications which can be useful for general understanding. But, that’s simply the tip of the iceberg.

rb808 8y ago

Define know though. A C++/Java programmer can quickly write some Python code but isn't Pythonic. To me being able to write a program in a language doesn't mean you can write some code in it, you also have to know the paradigm its supposed to be used, as well as the layout styles, build tools, commonly used libraries etc etc. Even learning a new library often takes months alone.

another-dave 8y ago
Yes! Exactly. Oftentimes I look for "X for Y developers" style tutorials to try and fasttrack that for myself (e.g. npm ≈ Maven but this is how they differ), but high quality ones can be hard to come by & takes a long time to fully grok a new language

skrebbel 8y ago

Structural typing wasn't around in mainstream languages before Go and TypeScript.

matt_kantor 8y ago
I assume you were taking klibertp up on this: > try naming any "new" feature which was added to your favorite (EDIT: I meant mainstream - TIOBE top 10 or 20 - lang here!) language recently - and I'll show you that same feature implemented 10 or 20 years ago in another language(s). This is a fun game and I'll answer for them on this one: OCaml (1996) has structural types.

throwaway34241 8y ago

I think this is true for just learning the language alone. But for the type of productivity the grandparent post is talking about the language ecosystem can be a bigger challenge, at least for me. It wasn't in academia, but I spent a while working on one of the major native front end platforms almost exclusively and had the opportunity to get very familiar with it. And by 'familiar' I don't mean just knowing where to look things up, I mean knowing many of the exact APIs by heart, and having a wide variety of things I could just type in (without much looking things up) even if it involved working with images, network requests, JSON, file IO, string processing, dates/scheduling, collections, serialization, menus, windows, controls, input, drawing, sound, etc. Another big thing was when there are multiple ways do the same thing, having done it both ways and having direct experience of why one choice will likely be more effective in general or for a particular project. This can apply to choosing libraries/frameworks or app architectural decisions. I noticed I missed this level of familiarity quite a lot when I switched to a different ecosystem later. Maybe this is worse for native UI development because of the large API surfaces. But I found needing to consult the documentation again to be a lot slower. Having had that experience has kind of made me wonder about full-stack vs specialization, and optimal-language-for-the job vs standardizing (although of course some languages are totally inappropriate for some jobs). At least in my own experience I found sticking with the same language for a while to have continuing productivity benefits well beyond the 1 week/month period.

throwaway34241 8y ago
And for a specific example of the sort of ecosystem stuff I am talking about, to save/load some local data on iOS you have some API options: Core Data SQLite NSArchiver NSKeyedArchiver NSUserDefaults JSON Property lists Protocol buffers stdio NSData memory-mapped files Realm This is without getting into anything too obscure. This list is probably also out of date.
klibertp 8y ago
> But for the type of productivity the grandparent post is talking about the language ecosystem can be a bigger challenge, at least for me. My claim was that: > learning a new language - and yes, in-depth, including idioms, stdlib, some external libraries, maybe some framework (if needed), and also some facts about the implementation and its inner workings[1] - takes a week at most I also tried to define "learning in-depth" in another post: > To me, 'knowing in depth' (as a language user) means that no matter the question, you know where to [quickly] search for the answers. There's no need to remember the answers themselves, although it kind of happens naturally with repetition anyway. > On the other hand, it's also important to know which questions are not worth answering. [ie. what to ignore while learning] And I stand by it: I believe that there's no need to memorize too many details to be productive, you just need to be able to quickly and accurately find the relevant details, no matter which details are they. Various docs indexes and viewers, your IDE features, cheatsheets printed on a wall - all of that can help you if you forget a bit of syntax or a signature of a function. There's nothing, other than just reading a book or two, to help you if you don't understand a crucial concept in a language or the architecture of the library/framework. Also, all these concepts are reused all over the place. For example: "Io is a purely-object-oriented language with prototypal inheritance which allows objects to have many parents." Each word here has a meaning, and that meaning is (well, mostly) standard across most programming languages. With this description, if you know all the words, you just learned 3/4 of all there is to Io OO. Another example: "Dylan is a purely-object-oriented language which is class-based, allows multiple inheritance, and also decouples methods from classes by relying on generic functions, which use multiple dispatch - similar to CLOS." This one is longer, but it's still a single sentence, which conveys most (or if you're familiar with CLOS - all) of the characteristics of Dylan's object system. Sure, there are obviously more features in Dylan that you need to know before you start coding... but they are all defined with a single sentence. It takes half an hour to go through them all, and - again, if you know the exact meaning of each word - at this point you know more about the language than a beginner programmer would learn in a year or two. > I mean knowing many of the exact APIs by heart I was like this in the past, so I know what you're talking about. Unfortunately, my epilepsy makes my memory reset significantly from time to time - I can't do it, or at least not for long. It caused a loss of productivity for a bit, but it went back up when I started using well-configured tools. This is why my definitions of "knowing in-depth" above are what they are - I live them, for better or worse. > (without much looking things up) even if it involved working with images, network requests, JSON, file IO, string processing, dates/scheduling, collections, serialization, menus, windows, controls, input, drawing, sound, etc. Yes, that's what tends to happen with repetition - unless your memory is impaired in some way - you just remember things. There's nothing else than repetition that can get you to that point, which also means you "only" need repetition to get there. In other words, it happens naturally with time, provided you consistently work with the given tech stack, and that you use it for the various things you mention. But again: good tooling makes the rote memorization mostly unnecessary, and I really don't see many benefits of keeping all the idiosyncrasies of the whole stack in your head. It's completely different story if you code in Notepad without Internet access, though. Further, all the things you mention are implemented in all general-purpose languages. Moreover, most implementations look really similar. In almost all languages "network requests" are built upon sockets - an OS-level mechanism. Images are more tricky because of decoding/encoding (which is handled almost everywhere by simply linking to libjpeg & co.), but after that they're 3-dimensional int array/vector/list/what-have-you (yes, there are other representations - and yes, they are all implemented across most PLs and have very similar characteristics everywhere). "file IO", too, is based upon OS-provided streams, or a crippled reimplementation thereof. It's the same everywhere. "collections" are almost language-agnostic: the names and interfaces may (slightly) differ, but the underlying data structures are the same everywhere. "input", "windows", "controls", "drawing" are event-based everywhere, and almost all languages have bindings to all the GUI frameworks. You can write GTK+ app in Python just as well as in OCaml or C# (even though GTK itself is C (I think?)) - and you'll get the same names and signatures, even. You'll see for yourself in the decades to come - you're likely to switch the stack at least a few times by the time you retire. You'll see that most divisions in programming are illusions and - quite simply - matters of taste/personal preference, while in reality the differences between the popular languages, stacks, framework and systems are miniscule. > Another big thing was when there are multiple ways do the same thing, having done it both ways and having direct experience of why one choice will likely be more effective in general or for a particular project. This can apply to choosing libraries/frameworks or app architectural decisions. These are mostly language-neutral - the exact same considerations apply when deciding on library/framework or approach in every single language. > I noticed I missed this level of familiarity quite a lot when I switched to a different ecosystem later. Maybe this is worse for native UI development because of the large API surfaces. But I found needing to consult the documentation again to be a lot slower. It could be because of lack of proper helpers in your editor etc., but either way: if you stick with the new stack, you'll learn it naturally with time. You'll forget some of the previous stack (although I'm frequently surprised how I can recall specific quirks in technologies from 20 years ago.), which is also natural. Memory just seems to work this way. It'll take a few months to remember all the relevant details - less if the new tech is similar to something you already know.