3 ms·

> Engineering is about trade-off and if for a given project with a given team F# is the best choice - given the information available - please go for it. What

by trimbo 5y ago

> Engineering is about trade-off and if for a given project with a given team F# is the best choice - given the information available - please go for it. What objective measure can someone use to determine whether F# is the best choice?

Kototama 5y ago
Pure data-driven decisions would not be possible here, I'm afraid, because there are not enough studies about which language/framework is the more productive in a given situation (and doing such a study is super tricky, because the competences of the participants can very greatly). What is possible however is to first analyze the core attributes of the techs which are relevant for the project and team such as: good supported libraries for the problem, support for immutable data-structure, expressiveness of the type system, experience of the team with the tech etc. You can then decide which tech fits better the environment. If still undecided you can try to build a prototype on a short period (at the risk on giving up on technologies which are hard to learn but could be rewarding on the long term).
- foobiekr 5y ago
  I don’t think it matters what language people think is most productive. What really matters is what language you can hire for. In the end you have to have people to do the work. I used to be a very big fan of a certain functional language, and invested serious time and effort into projects in that language, but hindsight tells me every single time it was a mistake. It was a mistake because if you cannot hire people to do the work then the project dies when it needs to grow. People used to do very big projects in COBOL, which most hacker news readers have never even seen, and as someone who did some COBOL, I can confirm that it was absolutely terrible, but the projects got done and by and large with less tech stack Jenga or superfluous trash that infests so many projects today. COBOL died when the majority of people moved on, not because st80, pascal, ada and C were better, but because the industry switched to platforms where the dominant languages were day one different: pascal and C. Mac, Windows, the Unix workstations. Maybe those platforms used other languages because they were better. Certainly I can’t imagine the Mac built with COBOL, FORTRAN, bcpl (worked for amiga, somewhat), etc. but the dynamic of leaders is different from the dynamic of followers.
  - Kototama 5y ago
    I see two thinks to distinguish in your discourse. First the hiring pool. I don't see any consensus here. If you take Haskell for example there are so many talented devs knowing the language without opportunity to use it professionally that they will rush on the first job offer. Now if you take Clojure it may be different. There may be enough positions occupied to make it hard to hire. I don't know, so I'm speculating. In general a good dev should be able to pick up a new language in a few months and in my opinion the potential hiring problem may be exaggerated? Your second point is about platforms. A FP language hosted on a popular platform has a lot to gain. That's the Clojure story. Rich Hickey tried different solutions / languages before but only Clojure was successful enough. Because it's tied to the JVM. But... nowadays most popular FP languages are hosted on a popular platform (JS/Web, JVM, .Net) so if a FP language builts a community that is big enough (no need to be big like Python) it will be sustainable. Last comment: if you think about sustainability on the very long term, such as COBOL projects, then choosing the default language of the platform (JavaScript for the web, Java for the JVM etc) may be wise (because the platform is more likely to die after the other languages). The truth is that most software project don't have such a long life so it should be only one criteria among other for the choice. So to conclude given a good choice for a platform (BEAM for distributed systems for example) I think languages do matter, because they offer different trade-offs (less state bugs with FP languages for example).
  - closeparen 5y ago
    >What really matters is what language you can hire for The whole mental framework of hiring for a language comes, I think, from HR/business people assuming that programming languages are like natural languages and that language experience is a central, fixed component of a candidate's identity. In large parts of the industry we simply don't believe this at all, interviews are about algorithms / problem solving and experience filters at senior levels are about business problem domains. Getting up to speed in whatever language is just part of onboarding.
AnimalMuppet 5y ago
At least part of the answer is, "more than one team member knows F#". It can't be just one person's pet language; a significant number (half?) of the team needs to be comfortable working in that language.
- xupybd 5y ago
  It can't be a small wart on the project either. If there is one small section that is inconsistent with the rest it's going to be a pain point. I love F#, but don't think it's ideal if it's shoe horned into a C# project. You then have this boundary layer you have to maintain.

by trimbo 5y ago

Kototama 5y ago

Pure data-driven decisions would not be possible here, I'm afraid, because there are not enough studies about which language/framework is the more productive in a given situation (and doing such a study is super tricky, because the competences of the participants can very greatly). What is possible however is to first analyze the core attributes of the techs which are relevant for the project and team such as: good supported libraries for the problem, support for immutable data-structure, expressiveness of the type system, experience of the team with the tech etc. You can then decide which tech fits better the environment. If still undecided you can try to build a prototype on a short period (at the risk on giving up on technologies which are hard to learn but could be rewarding on the long term).

foobiekr 5y ago
I don’t think it matters what language people think is most productive. What really matters is what language you can hire for. In the end you have to have people to do the work. I used to be a very big fan of a certain functional language, and invested serious time and effort into projects in that language, but hindsight tells me every single time it was a mistake. It was a mistake because if you cannot hire people to do the work then the project dies when it needs to grow. People used to do very big projects in COBOL, which most hacker news readers have never even seen, and as someone who did some COBOL, I can confirm that it was absolutely terrible, but the projects got done and by and large with less tech stack Jenga or superfluous trash that infests so many projects today. COBOL died when the majority of people moved on, not because st80, pascal, ada and C were better, but because the industry switched to platforms where the dominant languages were day one different: pascal and C. Mac, Windows, the Unix workstations. Maybe those platforms used other languages because they were better. Certainly I can’t imagine the Mac built with COBOL, FORTRAN, bcpl (worked for amiga, somewhat), etc. but the dynamic of leaders is different from the dynamic of followers.
- Kototama 5y ago
  I see two thinks to distinguish in your discourse. First the hiring pool. I don't see any consensus here. If you take Haskell for example there are so many talented devs knowing the language without opportunity to use it professionally that they will rush on the first job offer. Now if you take Clojure it may be different. There may be enough positions occupied to make it hard to hire. I don't know, so I'm speculating. In general a good dev should be able to pick up a new language in a few months and in my opinion the potential hiring problem may be exaggerated? Your second point is about platforms. A FP language hosted on a popular platform has a lot to gain. That's the Clojure story. Rich Hickey tried different solutions / languages before but only Clojure was successful enough. Because it's tied to the JVM. But... nowadays most popular FP languages are hosted on a popular platform (JS/Web, JVM, .Net) so if a FP language builts a community that is big enough (no need to be big like Python) it will be sustainable. Last comment: if you think about sustainability on the very long term, such as COBOL projects, then choosing the default language of the platform (JavaScript for the web, Java for the JVM etc) may be wise (because the platform is more likely to die after the other languages). The truth is that most software project don't have such a long life so it should be only one criteria among other for the choice. So to conclude given a good choice for a platform (BEAM for distributed systems for example) I think languages do matter, because they offer different trade-offs (less state bugs with FP languages for example).
- closeparen 5y ago
  >What really matters is what language you can hire for The whole mental framework of hiring for a language comes, I think, from HR/business people assuming that programming languages are like natural languages and that language experience is a central, fixed component of a candidate's identity. In large parts of the industry we simply don't believe this at all, interviews are about algorithms / problem solving and experience filters at senior levels are about business problem domains. Getting up to speed in whatever language is just part of onboarding.

AnimalMuppet 5y ago

At least part of the answer is, "more than one team member knows F#". It can't be just one person's pet language; a significant number (half?) of the team needs to be comfortable working in that language.

xupybd 5y ago
It can't be a small wart on the project either. If there is one small section that is inconsistent with the rest it's going to be a pain point. I love F#, but don't think it's ideal if it's shoe horned into a C# project. You then have this boundary layer you have to maintain.