4 ms·

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

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.
- klibertp 8y ago
  You're moving goalposts a bit here, I think. Or maybe it's my fault, I should have defined 'in-depth' more precisely. Anyway, I specifically mentioned knowing "some facts about the implementation" instead of "knowing the implementation inside-out". The same is true for tools, libraries, and frameworks - there is no need to remember every function/method signature and every class name in a library - as long as you know the most important parts and can quickly and accurately find the relevant documentation for the rest. To me, 'knowing in depth' (as a language user) means that no matter the question, you know where to 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. It's exactly as you say: > Really learning what you can safely ignore in whatever context is the most important part So, to sum it up: if you can do both these things, then, to me, you have in-depth knowledge about the language (or actually any other field). The next step - ie. actually knowing all the answers by heart - is mostly useless for language users and only matters for (and is best left to) language implementers/advocates/nerds. > A language like Java has a giant and evolving standard library plus multiple compilers etc. And that’s ignoring any simply popular libraries etc. Java stdlib is only "huge" in comparison with C, where stdlib is non-existent. The popular libraries may be ported from other languages or even directly called via FFI. And if the library is really good, it will be ported to other languages, too, which means you'll have an easier time using these languages in the future. Even without all that, though, if you know more-or-less what's where and can quickly search for the details - you're good. It's not that easy to learn this - you need to remember the structure of the docs at least - but it's much easier than actually learning and remembering all of the stdlib, etc.
gubbrora 8y ago
Languages change. In depth knowledge comes with an ongoing cost. For this reason I think it may be rational to only learn what will be used in the near future and spend the saved time on more timeless knowledge.
- klibertp 8y ago
  > on more timeless knowledge Like interpreter and compiler architectures, type systems kinds and their meaning, ways of specifying the semantics formally, and also the structure of novel kinds of abstractions proposed by researchers in some experimental languages. If you learn all of that today, the next time you'd need to learn anything new about a mainstream PL would be in 10 years, if not twice that. Example: many modern languages only recently started supporting some of the Algol-68 features. That's 50 years to get a lambda into the language...

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.

klibertp 8y ago
You're moving goalposts a bit here, I think. Or maybe it's my fault, I should have defined 'in-depth' more precisely. Anyway, I specifically mentioned knowing "some facts about the implementation" instead of "knowing the implementation inside-out". The same is true for tools, libraries, and frameworks - there is no need to remember every function/method signature and every class name in a library - as long as you know the most important parts and can quickly and accurately find the relevant documentation for the rest. To me, 'knowing in depth' (as a language user) means that no matter the question, you know where to 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. It's exactly as you say: > Really learning what you can safely ignore in whatever context is the most important part So, to sum it up: if you can do both these things, then, to me, you have in-depth knowledge about the language (or actually any other field). The next step - ie. actually knowing all the answers by heart - is mostly useless for language users and only matters for (and is best left to) language implementers/advocates/nerds. > A language like Java has a giant and evolving standard library plus multiple compilers etc. And that’s ignoring any simply popular libraries etc. Java stdlib is only "huge" in comparison with C, where stdlib is non-existent. The popular libraries may be ported from other languages or even directly called via FFI. And if the library is really good, it will be ported to other languages, too, which means you'll have an easier time using these languages in the future. Even without all that, though, if you know more-or-less what's where and can quickly search for the details - you're good. It's not that easy to learn this - you need to remember the structure of the docs at least - but it's much easier than actually learning and remembering all of the stdlib, etc.

gubbrora 8y ago

Languages change. In depth knowledge comes with an ongoing cost. For this reason I think it may be rational to only learn what will be used in the near future and spend the saved time on more timeless knowledge.

klibertp 8y ago
> on more timeless knowledge Like interpreter and compiler architectures, type systems kinds and their meaning, ways of specifying the semantics formally, and also the structure of novel kinds of abstractions proposed by researchers in some experimental languages. If you learn all of that today, the next time you'd need to learn anything new about a mainstream PL would be in 10 years, if not twice that. Example: many modern languages only recently started supporting some of the Algol-68 features. That's 50 years to get a lambda into the language...