3 ms·

Ask HN: Choosing between a programming language you like and one you don't

Scenario: You're building a software product and you can choose the programming language to build the product. You can choose a programming language from two options: Option 1. A language you like and you're fairly sure you'll enjoy using. You'd be happy to build and maintain the code as it grows in this language. However, this language lacks some of the completeness of libraries and documentation compared with other languages. Option 2. A language you don't particularly like but it has wide-ranging libraries, extensive documentation and many prior examples/tutorials that will help you out when you inevitably get stuck. Despite that, you don't particularly enjoy writing in this language. Given that ultimately you want to successfully launch a product, is option 2 the only choice? Or is there a case for choosing option 1?

taylodl 8y ago
The real question is how are you basing your liking a language? You don't like having wide-ranging libraries, extensive documentation and many prior examples/tutorials that will help you out when you inevitably get stuck? Are you a glutton for punishment? :) All snark aside, the only sound business case for going with option (1) is if the language is typically only used by high-caliber developers so that when recruiting help it sets the bar for ensuring you're getting good help. Clojure comes to mind as an example of such a language. Too bad it has wide-ranging libraries, extensive documentation and many prior examples/tutorials! ;) Hope that helps.
- _bxg1 8y ago
  Another factor would be accounting for newness- if a language has a better foundation than other languages and just hasn't been around long enough to have developed those "wide-ranging libraries, extensive documentation and many prior examples/tutorials", it could still be a good long-term investment. Rust comes to mind, and to an extent Clojure (at least if you exclude the Java ecosystem).
mindcrime 8y ago
I see this as a continuum, not a binary dichotomy. I mean, quantify how much language A is short on, say libraries, compared to language B. Surely A has some libraries, and surely there is something that B does not have a library for, no? Similar notions apply to the other dimensions. So I don't think there's an easy answer to this. You might just have to define some baselines that represent minimum criteria a language must meet in order to be selected, and then satisfice[1] with anything that passes those baseline measures. For example, maybe you say "anything that doesn't at least have a library for making HTTP requests is out". Or maybe it's "anything that doesn't have an easy to use C FFI is out", or whatever. [1]: https://en.wikipedia.org/wiki/Satisficing https://en.wikipedia.org/wiki/Satisficing
_bxg1 8y ago
As others have noted, putting these into two opposing buckets removes a lot from the equation. That said, I would tend towards #2 for a professional project and #1 for a hobby project. I've definitely made things for fun in a less practical language, just because I knew I would get more enjoyment out of describing things that way than from having a bulletproof end result.

taylodl 8y ago

The real question is how are you basing your liking a language? You don't like having wide-ranging libraries, extensive documentation and many prior examples/tutorials that will help you out when you inevitably get stuck? Are you a glutton for punishment? :) All snark aside, the only sound business case for going with option (1) is if the language is typically only used by high-caliber developers so that when recruiting help it sets the bar for ensuring you're getting good help. Clojure comes to mind as an example of such a language. Too bad it has wide-ranging libraries, extensive documentation and many prior examples/tutorials! ;) Hope that helps.

_bxg1 8y ago
Another factor would be accounting for newness- if a language has a better foundation than other languages and just hasn't been around long enough to have developed those "wide-ranging libraries, extensive documentation and many prior examples/tutorials", it could still be a good long-term investment. Rust comes to mind, and to an extent Clojure (at least if you exclude the Java ecosystem).

mindcrime 8y ago

I see this as a continuum, not a binary dichotomy. I mean, quantify how much language A is short on, say libraries, compared to language B. Surely A has some libraries, and surely there is something that B does not have a library for, no? Similar notions apply to the other dimensions. So I don't think there's an easy answer to this. You might just have to define some baselines that represent minimum criteria a language must meet in order to be selected, and then satisfice[1] with anything that passes those baseline measures. For example, maybe you say "anything that doesn't at least have a library for making HTTP requests is out". Or maybe it's "anything that doesn't have an easy to use C FFI is out", or whatever. [1]: https://en.wikipedia.org/wiki/Satisficing https://en.wikipedia.org/wiki/Satisficing

_bxg1 8y ago

As others have noted, putting these into two opposing buckets removes a lot from the equation. That said, I would tend towards #2 for a professional project and #1 for a hobby project. I've definitely made things for fun in a less practical language, just because I knew I would get more enjoyment out of describing things that way than from having a bulletproof end result.