4 ms·

I've entered a mid-life zen w.r.t. languages. Most important is the people and irreplaceable knowledge they have in their heads, about the tricks, methods, and

I've entered a mid-life zen w.r.t. languages. Most important is the people and irreplaceable knowledge they have in their heads, about the tricks, methods, and environments they've worked in. Languages correlate with that, and so are a semi-useful indicator of past skills. You want a person to write the bootloader for your Mars helicopter? You hire a C programmer most likely, not a C# programmer, but who knows? You want a person to bootstrap your image processing pipelines for your scientists? Maybe Python? Maybe? This area is much more loose. If a valuable tool or method is expressed in (or even only expressible in) a particular language, then so be it. Often, there are many more choices than people believe, and what is right for the person, so long as it serves the organization or need appropriately, is fine by me. A language is a tool. Most languages do pretty much the same thing. Most languages' ecosystems, application adoption, and developers are much more important than the languages' seatbelts and headlights.

qznc 6y ago
I disagree that languages "pretty much the same thing". However, I do agree that language choice is overrated. Other factors, e.g. which one you know better, weigh heavier.
- jvanderbot 6y ago
  OK, over-simplification. Perhaps: Language in-class variance is small (C# ~= Java, C++, C, RUST are close-ish). Cross-class variance is big (JS vs Rust). Therefore, recruiting a programmer from the same problem / language class is more important than the particular language.
derekp7 6y ago
What is also important is the ecosystem that comes along with the language. Modern languages have a wide ranging list of libraries and plugins for them which make certain programming tasks easier. But that also means you have an ever shifting stack that is required to support them. This became apparent to me when trying to get some infrastructure software to play nice with some of the older systems we need to keep around. There were some nice Python based solutions that I had to reject because the dependencies didn't exist for some older RHEL installations we have (yes, we still need to keep a hand full of RHEL 4.x systems around because management doesn't want to tell customers "no we won't support you unless you upgrade to our latest product that works on newer OS releases". So for backup and management solutions, I have to stick with tools that can be easily compiled on the older environments. Another example, one of our architects at work is a strong supporter of Apple, and wanted me to look into Swift. Well at the time you could get Swift for Ubuntu, but couldn't for any version of RHEL (that has finally changed now though). So again, writing my code in plain C was more of a win.
nvader 6y ago
Sounds like a case of Blub Paradox: http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html

qznc 6y ago

I disagree that languages "pretty much the same thing". However, I do agree that language choice is overrated. Other factors, e.g. which one you know better, weigh heavier.

jvanderbot 6y ago
OK, over-simplification. Perhaps: Language in-class variance is small (C# ~= Java, C++, C, RUST are close-ish). Cross-class variance is big (JS vs Rust). Therefore, recruiting a programmer from the same problem / language class is more important than the particular language.

derekp7 6y ago

What is also important is the ecosystem that comes along with the language. Modern languages have a wide ranging list of libraries and plugins for them which make certain programming tasks easier. But that also means you have an ever shifting stack that is required to support them. This became apparent to me when trying to get some infrastructure software to play nice with some of the older systems we need to keep around. There were some nice Python based solutions that I had to reject because the dependencies didn't exist for some older RHEL installations we have (yes, we still need to keep a hand full of RHEL 4.x systems around because management doesn't want to tell customers "no we won't support you unless you upgrade to our latest product that works on newer OS releases". So for backup and management solutions, I have to stick with tools that can be easily compiled on the older environments. Another example, one of our architects at work is a strong supporter of Apple, and wanted me to look into Swift. Well at the time you could get Swift for Ubuntu, but couldn't for any version of RHEL (that has finally changed now though). So again, writing my code in plain C was more of a win.

nvader 6y ago

Sounds like a case of Blub Paradox: http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html