4 ms·

Of course I have a preference, but in general you work in teams, and the quality of the code base and standard practices of the group are more defining in how f

by sspiff 13y ago

Of course I have a preference, but in general you work in teams, and the quality of the code base and standard practices of the group are more defining in how fun or productive something is to work on than the choice of language. I know nobody cares if you can write "hello, world" in many languages, but I never stated that or anything like that, did I? Some things take time to learn (systems programming, memory management, ... are things you'll have to wrap your head around when coming from a higher level environment, for instance), but hardly any of them are language specific as far as I can tell. Feel free to point out examples to the contrary, although I feel like if it's hard to learn a general concept in a specific language, that sounds like a language design problem. In many cases being a good programmer in one language means you can learn another language and become a proficient or good programmer in it relatively easily. Some specialization is fine, however, if you really stick to a single language/framework/environment, I think you're staking an awful lot on something that could mostly go away in five years time. For example, I work in the embedded domain. Ten, fifteen years back, microcontrollers were pretty much king. You wrote software close to the metal, without an operating system, and allocated all memory statically. If you stuck to that kind of development, and refused to learn embedded Linux stuff or dynamic memory management, you'd be unable to find a job today (at least in my area, I can't speak for the entire world in this case.)

avar 13y ago
You're right about a lot of this knowledge being transferable, but I think you might also be underestimating just how much useful specialist knowledge you can acquire specific to a particular toolchain, and how much of a step back starting over can be. I happen to have been doing Perl professionally for a while now and I'd say it would take me at least 2 years to get equally up to speed on another toolchain. Sure I can write programs productively in other languages, but with my language of choice I don't have to look up dozens of little things a day, avoid common and less common pitfalls all the time, and generally choose the easier path the first time around because I've been around the block a bunch of times. No matter what toolchain you use productivity at that level is hard to come by, and a lot of it is toolchain-specific. I can competently hack C but someone who's been doing it for 10 years will run laps around me. So while I'm certainly not married for life to the toolchain I'm using I also think that many people underestimate just how much effort it is to truly become completely intimately familiar with some tool, and how much you constantly gain in productivity for having done so.
- Arnor 13y ago
  That's exactly why it's useful to get familiar with multiple toolchains. If you are pretty comfortable with Ruby and move to Python, you'll have a pretty good idea about what pitfalls you'll encounter in a dynamically typed, interpreted language. Of course there's a learning curve, but it's less intense for languages with similar building blocks. The first homework assignment when moving to a new language/stack is to google: "<language/stack/whatever> fucking sucks" and read the first 10 pages or so, you'll get a sense of the pitfalls.
  - avar 13y ago
    I can easily switch between dynamic languages, including Perl, Python and Ruby. What I'm talking about is the level of toolchain familiarity where e.g. you can look at a given piece of code and know exactly which opcodes it'll get compiled to, what algorithms those opcodes will employ, and by extension how everything else in the system works. Now I certainly don't pretend to know all of that with Perl, but once you have that level of intimate knowledge that extends way beyond just the differences between similar languages with similar building blocks you'll reach a level of mastery that you don't want to give up easily. If you accept a job at a new company you might have to start to understand tens of thousands of new lines of code to have a proper understanding of the system you're working with. Similarly the hairy bits of programming language toolchains are tens to hundreds of of thousands of lines of code that you have to understand to truly know how they work. My point is that assuming that you can easily transfer that knowledge on a whim just because you can read the syntax introduction of some new programming language is folly. The toolchain is more complex than most people give it credit for, and mastering it matters.
    - mikegrb 13y ago
      > What I'm talking about is the level of toolchain familiarity where e.g. you can look at a given piece of code and know exactly which opcodes it'll get compiled to, what algorithms those opcodes will employ, and by extension how everything else in the system works. Indeed, and I can say for sure the author of the post has such a low level knowledge of Perl.

by sspiff 13y ago

avar 13y ago

You're right about a lot of this knowledge being transferable, but I think you might also be underestimating just how much useful specialist knowledge you can acquire specific to a particular toolchain, and how much of a step back starting over can be. I happen to have been doing Perl professionally for a while now and I'd say it would take me at least 2 years to get equally up to speed on another toolchain. Sure I can write programs productively in other languages, but with my language of choice I don't have to look up dozens of little things a day, avoid common and less common pitfalls all the time, and generally choose the easier path the first time around because I've been around the block a bunch of times. No matter what toolchain you use productivity at that level is hard to come by, and a lot of it is toolchain-specific. I can competently hack C but someone who's been doing it for 10 years will run laps around me. So while I'm certainly not married for life to the toolchain I'm using I also think that many people underestimate just how much effort it is to truly become completely intimately familiar with some tool, and how much you constantly gain in productivity for having done so.

Arnor 13y ago
That's exactly why it's useful to get familiar with multiple toolchains. If you are pretty comfortable with Ruby and move to Python, you'll have a pretty good idea about what pitfalls you'll encounter in a dynamically typed, interpreted language. Of course there's a learning curve, but it's less intense for languages with similar building blocks. The first homework assignment when moving to a new language/stack is to google: "<language/stack/whatever> fucking sucks" and read the first 10 pages or so, you'll get a sense of the pitfalls.
- avar 13y ago
  I can easily switch between dynamic languages, including Perl, Python and Ruby. What I'm talking about is the level of toolchain familiarity where e.g. you can look at a given piece of code and know exactly which opcodes it'll get compiled to, what algorithms those opcodes will employ, and by extension how everything else in the system works. Now I certainly don't pretend to know all of that with Perl, but once you have that level of intimate knowledge that extends way beyond just the differences between similar languages with similar building blocks you'll reach a level of mastery that you don't want to give up easily. If you accept a job at a new company you might have to start to understand tens of thousands of new lines of code to have a proper understanding of the system you're working with. Similarly the hairy bits of programming language toolchains are tens to hundreds of of thousands of lines of code that you have to understand to truly know how they work. My point is that assuming that you can easily transfer that knowledge on a whim just because you can read the syntax introduction of some new programming language is folly. The toolchain is more complex than most people give it credit for, and mastering it matters.
  - mikegrb 13y ago
    > What I'm talking about is the level of toolchain familiarity where e.g. you can look at a given piece of code and know exactly which opcodes it'll get compiled to, what algorithms those opcodes will employ, and by extension how everything else in the system works. Indeed, and I can say for sure the author of the post has such a low level knowledge of Perl.