3 ms·

> Personally I think programming language is about a compromise between performance and convenience. That's one dimension, but what about popularity, maintaina

by Zababa 5y ago

> Personally I think programming language is about a compromise between performance and convenience. That's one dimension, but what about popularity, maintainability, being able to hire, productivity, being able to tackle precise problems, etc.

fiddlerwoaroof 5y ago
I think concern about “ability to hire” is a bit overblown: I’ve worked at a couple places now that have taken the “hire people that know what they’re doing and they’ll figure out the language” approach, and it’s generally successful for most business applications: this is true even when the team is using unusual languages like Clojure.
- xfer 5y ago
  The problem is really about tooling, you also need people who can fix bugs/port to new arch in the compiler and related tools. For a very popular language you can always find the right people for this task or even offload this task like they do with oracle.
dgb23 5y ago
Those are layman’s concerns. Programmers love to learn new things and are typically good at it. If a given tech has merit and some unique advantages. Edit: I didn’t read the comment right. Productivity and being able to solve precise problems are essentially why you’re choosing a technology in the first place?
- Zababa 5y ago
  > Those are layman’s concerns. Programmers love to learn new things and are typically good at it. If a given tech has merit and some unique advantages. I don't think that's true, I believe most programmers are either dark matter developers [1] or people doing Java (or equivalent) all their life for a software service company. There is nothing wrong with that, but that would explain why less popular languages and ecosystem still have lots of stuff. For example, Rust has ~60k crates on crates.io, while Maven Central has ~400k packages. I believe Java is used by more than 10 times the number of people that use Rust. But the people writing the libraries in the first place are usually the people that are open to trying out new languages. [1]: https://www.hanselman.com/blog/dark-matter-developers-the-unseen-99 https://www.hanselman.com/blog/dark-matter-developers-the-un...
gridspy 5y ago
I concur, though most of the traits you mention are not problem-specific. When putting a language into "your toolbox" you indeed SHOULD focus on "popularity, maintainability, being able to hire." However, when picking which of the languages you have learnt to apply to a given problem you need to know their relative strengths. Most of the strengths you mention help you pick the "best in class" language. But only the problem can tell you which subset of langauges you are picking from. Sometimes the best possible tool for your problem is going to be unpopular.

by Zababa 5y ago

fiddlerwoaroof 5y ago

I think concern about “ability to hire” is a bit overblown: I’ve worked at a couple places now that have taken the “hire people that know what they’re doing and they’ll figure out the language” approach, and it’s generally successful for most business applications: this is true even when the team is using unusual languages like Clojure.

xfer 5y ago
The problem is really about tooling, you also need people who can fix bugs/port to new arch in the compiler and related tools. For a very popular language you can always find the right people for this task or even offload this task like they do with oracle.

dgb23 5y ago

Those are layman’s concerns. Programmers love to learn new things and are typically good at it. If a given tech has merit and some unique advantages. Edit: I didn’t read the comment right. Productivity and being able to solve precise problems are essentially why you’re choosing a technology in the first place?

Zababa 5y ago
> Those are layman’s concerns. Programmers love to learn new things and are typically good at it. If a given tech has merit and some unique advantages. I don't think that's true, I believe most programmers are either dark matter developers [1] or people doing Java (or equivalent) all their life for a software service company. There is nothing wrong with that, but that would explain why less popular languages and ecosystem still have lots of stuff. For example, Rust has ~60k crates on crates.io, while Maven Central has ~400k packages. I believe Java is used by more than 10 times the number of people that use Rust. But the people writing the libraries in the first place are usually the people that are open to trying out new languages. [1]: https://www.hanselman.com/blog/dark-matter-developers-the-unseen-99 https://www.hanselman.com/blog/dark-matter-developers-the-un...

gridspy 5y ago

I concur, though most of the traits you mention are not problem-specific. When putting a language into "your toolbox" you indeed SHOULD focus on "popularity, maintainability, being able to hire." However, when picking which of the languages you have learnt to apply to a given problem you need to know their relative strengths. Most of the strengths you mention help you pick the "best in class" language. But only the problem can tell you which subset of langauges you are picking from. Sometimes the best possible tool for your problem is going to be unpopular.