5 ms·

I've seen companies that have tried this and failed miserably. While programming languages share a common basis there are significantly different paradigms betw

by ig1 16y ago

I've seen companies that have tried this and failed miserably. While programming languages share a common basis there are significantly different paradigms between say Ruby, C++ and Perl. While a good programmer could probably pick up any of these languages it'll probably take them a few years before their productivity is at the same level as someone of the same ability who has experience in that language.

humblepatience 16y ago
I agree, but its more because of the frameworks and libraries than the language
lukev 16y ago
A few years? Strongly disagree. Months, tops. It's key that you do have people who are already good with the language on the team for them to learn from, but if that's in place, a genuinely good developer is going to be able to pick up on the new paradigm pretty easily.
- LiveTheDream 16y ago
  A few months, agreed. This time drops with each successive language. In addition to learning the language, a developer must learn the ecosystem. Perl and CPAN, Ruby and rubygems, etc.
- ig1 16y ago
  I'm not talking about learning the syntax of the language, but things like design patterns, maintainability and readability. You need to read a lot of code to understand what works well and doesn't and it's language specific. Understanding the Ruby way of doing things is different from understanding Ruby. Understanding when to use meta-templates in C++ is something you only learn by reading a lot of templated code. After a few months you'll probably have only worked on a single code base on a tiny part of a project. You've no-way of understanding the ramifications of your design decisions will have on the project in 2-3 years time. You need to see multiple projects go from design stage to long term maintenance to understand issues such as where bugs get introduced, how code decisions impact maintainability, etc.
  - grammaton 16y ago
    "Understanding the Ruby way of doing things is different from understanding Ruby. Understanding when to use meta-templates in C++ is something you only learn by reading a lot of templated code." Very true - and that's why truly good programmers will promptly take it on themselves to read as much code in a given language as they can get their mits on after having learned it's basic concepts, syntax, and so on. Precisely because every language comes with a sizeable corpus of lore, best practice, idioms, and other such things that are the closest things programming has to an oral tradition.
  - lukev 16y ago
    That's what I'm talking about, too. Design patterns aren't that hard. Maintainability and readability are obvious, if you've got good examples to follow. Sure, it may take a couple years for a developer who's absolutely stuck in the mud. But a good developer already knows multiple languages, already is familiar with multiple paradigms, and is capable of meta-cognition to recognize what the new patterns are, how they are useful, and apply them.
    - ig1 16y ago
      If you think maintainability is obvious I suspect we're talking about different things when we're using that term.
Xurinos 16y ago
I am not convinced this is a good point against hiring someone who lacks depth in your language. It assumes that people already on the team have the same ability as the potential hire. This does not reflect reality. Different people learn at different rates. I have seen new people pick things up very quickly and surpass those who have been programming in that specific language for years. I am one, myself, with my present job. It is true there is a ramp-up time, but it varies with the person. For some people, different paradigms do not present challenges; they are just different approaches to the same problems. It might be easier for people who dabble around in multiple paradigms to adapt to the new language.
- chromatic 16y ago
  It assumes that people already on the team have the same ability as the potential hire. The people on the team have a great advantage over a new hire: they know more about the business and the codebase.
ido 16y ago
It probably depends on how far the language is from the developer's experience. I can imagine it will take a developer only familiar with ruby, python & js quite a while to become productive in assembly language. However, a good developer that knows e.g. python, php & c really well (moreso if he generally know *NIX really well) will probably not take an inordinate amount of time to become productive in perl.
Natsu 16y ago
Are there good programmers who aren't familiar with the standard paradigms? I went out of my way to study functional, OO, logical and assembly programming just so I wouldn't be trapped in an imperative mindset. And I don't really consider myself to be any too great, because I know that there's so much more to learn and I won't live long enough to learn all the things I want to.

by ig1 16y ago

humblepatience 16y ago

I agree, but its more because of the frameworks and libraries than the language

lukev 16y ago

A few years? Strongly disagree. Months, tops. It's key that you do have people who are already good with the language on the team for them to learn from, but if that's in place, a genuinely good developer is going to be able to pick up on the new paradigm pretty easily.

LiveTheDream 16y ago
A few months, agreed. This time drops with each successive language. In addition to learning the language, a developer must learn the ecosystem. Perl and CPAN, Ruby and rubygems, etc.
ig1 16y ago
I'm not talking about learning the syntax of the language, but things like design patterns, maintainability and readability. You need to read a lot of code to understand what works well and doesn't and it's language specific. Understanding the Ruby way of doing things is different from understanding Ruby. Understanding when to use meta-templates in C++ is something you only learn by reading a lot of templated code. After a few months you'll probably have only worked on a single code base on a tiny part of a project. You've no-way of understanding the ramifications of your design decisions will have on the project in 2-3 years time. You need to see multiple projects go from design stage to long term maintenance to understand issues such as where bugs get introduced, how code decisions impact maintainability, etc.
- grammaton 16y ago
  "Understanding the Ruby way of doing things is different from understanding Ruby. Understanding when to use meta-templates in C++ is something you only learn by reading a lot of templated code." Very true - and that's why truly good programmers will promptly take it on themselves to read as much code in a given language as they can get their mits on after having learned it's basic concepts, syntax, and so on. Precisely because every language comes with a sizeable corpus of lore, best practice, idioms, and other such things that are the closest things programming has to an oral tradition.
- lukev 16y ago
  That's what I'm talking about, too. Design patterns aren't that hard. Maintainability and readability are obvious, if you've got good examples to follow. Sure, it may take a couple years for a developer who's absolutely stuck in the mud. But a good developer already knows multiple languages, already is familiar with multiple paradigms, and is capable of meta-cognition to recognize what the new patterns are, how they are useful, and apply them.
  - ig1 16y ago
    If you think maintainability is obvious I suspect we're talking about different things when we're using that term.

Xurinos 16y ago

I am not convinced this is a good point against hiring someone who lacks depth in your language. It assumes that people already on the team have the same ability as the potential hire. This does not reflect reality. Different people learn at different rates. I have seen new people pick things up very quickly and surpass those who have been programming in that specific language for years. I am one, myself, with my present job. It is true there is a ramp-up time, but it varies with the person. For some people, different paradigms do not present challenges; they are just different approaches to the same problems. It might be easier for people who dabble around in multiple paradigms to adapt to the new language.

chromatic 16y ago
It assumes that people already on the team have the same ability as the potential hire. The people on the team have a great advantage over a new hire: they know more about the business and the codebase.

ido 16y ago

It probably depends on how far the language is from the developer's experience. I can imagine it will take a developer only familiar with ruby, python & js quite a while to become productive in assembly language. However, a good developer that knows e.g. python, php & c really well (moreso if he generally know *NIX really well) will probably not take an inordinate amount of time to become productive in perl.

Natsu 16y ago

Are there good programmers who aren't familiar with the standard paradigms? I went out of my way to study functional, OO, logical and assembly programming just so I wouldn't be trapped in an imperative mindset. And I don't really consider myself to be any too great, because I know that there's so much more to learn and I won't live long enough to learn all the things I want to.