3 ms·

Everything you say is optimizing for the short-term. When it comes to total cost of development, I think FP wins out even if you have to fill ecosystem gaps. B

Everything you say is optimizing for the short-term. When it comes to total cost of development, I think FP wins out even if you have to fill ecosystem gaps. But if you can't afford for ANY time to not be spent directly on the business, don't do FP. Sounds like a pretty brutal way to work. FP has _throughput_ benefits, but may come with _latency_ hiccups while your team climbs the learning curve (which may include writing libraries.) If you have frequent deadlines (or treat 2 week sprints as deadlines), then FP won't jive..and you probably have bigger pain points in your company than PL choice lol.

PragmaticPulp 5y ago
> When it comes to total cost of development, I think FP wins out even if you have to fill ecosystem gaps. This is the core point I was disagreeing with: In my experience (yes, I have used Elm and I enjoy various functional languages), this payoff never comes. There's always something more that needs attention, needs another developer, needs to be refactored because we forgot a use case, and so on. And also in my experience, by the time you've invested the years of effort required to fill in gaps in the public package ecosystem, it's time to move on to the next niche language trend. I'd rather invest our time and energy in mainstream languages that have staying power, where we're not obligated to carry large parts of the open-source ecosystem by ourselves.
- whateveracct 5y ago
  Years, plural?? Maybe Elm is just way less mature, but I was on a team that shipped Haskell software with millions of users in about a year of dev time..and this included huge investments in many missing libraries..all on top of using GHCJS which required investments to the toolchain itself (Elm is definitely more mature now than GHCJS was at the time.) But that was Haskell I guess. It's obviously not a "niche language trend" by now, so it was pretty clear it had staying power. Definitely has paid off for me personally. My side projects move a lot faster and more stably now that I cut my teeth in production Haskell. A real free 10xer to my skills personally. And I gained the skills by getting my employer to finance my learning lmao.
- KronisLV 5y ago
  > And also in my experience, by the time you've invested the years of effort required to fill in gaps in the public package ecosystem, it's time to move on to the next niche language trend. This probably depends on the complexity of what you need to do, as well as how well you want to do it. I've seen people writing their own packages and pieces of systems in months, to typically pretty underwhelming results. However when writing code with tests, proper documentation, getting started guides etc., then what you're saying does sound way more plausible, especially if scope creep of any sorts is also present. Would you care to comment on what sorts of systems take years to properly develop, though? Because in my experience that could be applicable to very few software projects out there.
vlunkr 5y ago
> I think FP wins out even if you have to fill ecosystem gaps. What proof of this is there though? People have made the same claims about lots of things: FP, OOP, statically typed languages, dynamically typed languages, LISP variants, etc. The fact is, any of these solutions can work, and you can also write terrible code with any of them.
koonsolo 5y ago
Geniune question: Can you name any complex software that is written in pure functions? This is not a "discussion" question, but a "fill my blind spot" question. I always read how good FP is, and how much better it handles all the complexity. Yet I never see it win from software written with state. Is there any big and/or complex sofware written in FP that I am overlooking?
- whateveracct 5y ago
  Various classical optimization problems are just pure functions. The sorts of things used all over the place in industry (supply chain ops for instance) If you want real production software, Starbucks Rewards is/was powered entirely by pure Haskell code and made big bucks Software having complex state actually makes Haskell even better than the competition. Because most state has nuanced rules about its state transitions. Haskell definitely has more of a learning curve when it comes to dealing with state, but that curve will guide you towards a ceiling mainstream languages can't even approximate.
- gen220 5y ago
  Many banks and hedge funds are semi famously using FP (whether that’s OCaml, Haskell, or Scala). JP Morgan has a big Haskell corner. Jane St is the company I most associate with with OCaml. Jet.com is largely built with F#. In business domains with strict audit requirements, it’s a peace of mind thing, to know that “side effects” (aka persistence and the mutation of persisted data) are constrained to a tiny and highly testable corner of your code base. For OSS, the examples that spring to mind for me are RabbitMQ (Erlang) and Pandoc (Haskell).

PragmaticPulp 5y ago

> When it comes to total cost of development, I think FP wins out even if you have to fill ecosystem gaps. This is the core point I was disagreeing with: In my experience (yes, I have used Elm and I enjoy various functional languages), this payoff never comes. There's always something more that needs attention, needs another developer, needs to be refactored because we forgot a use case, and so on. And also in my experience, by the time you've invested the years of effort required to fill in gaps in the public package ecosystem, it's time to move on to the next niche language trend. I'd rather invest our time and energy in mainstream languages that have staying power, where we're not obligated to carry large parts of the open-source ecosystem by ourselves.

whateveracct 5y ago
Years, plural?? Maybe Elm is just way less mature, but I was on a team that shipped Haskell software with millions of users in about a year of dev time..and this included huge investments in many missing libraries..all on top of using GHCJS which required investments to the toolchain itself (Elm is definitely more mature now than GHCJS was at the time.) But that was Haskell I guess. It's obviously not a "niche language trend" by now, so it was pretty clear it had staying power. Definitely has paid off for me personally. My side projects move a lot faster and more stably now that I cut my teeth in production Haskell. A real free 10xer to my skills personally. And I gained the skills by getting my employer to finance my learning lmao.
KronisLV 5y ago
> And also in my experience, by the time you've invested the years of effort required to fill in gaps in the public package ecosystem, it's time to move on to the next niche language trend. This probably depends on the complexity of what you need to do, as well as how well you want to do it. I've seen people writing their own packages and pieces of systems in months, to typically pretty underwhelming results. However when writing code with tests, proper documentation, getting started guides etc., then what you're saying does sound way more plausible, especially if scope creep of any sorts is also present. Would you care to comment on what sorts of systems take years to properly develop, though? Because in my experience that could be applicable to very few software projects out there.

vlunkr 5y ago

> I think FP wins out even if you have to fill ecosystem gaps. What proof of this is there though? People have made the same claims about lots of things: FP, OOP, statically typed languages, dynamically typed languages, LISP variants, etc. The fact is, any of these solutions can work, and you can also write terrible code with any of them.

koonsolo 5y ago

Geniune question: Can you name any complex software that is written in pure functions? This is not a "discussion" question, but a "fill my blind spot" question. I always read how good FP is, and how much better it handles all the complexity. Yet I never see it win from software written with state. Is there any big and/or complex sofware written in FP that I am overlooking?

whateveracct 5y ago
Various classical optimization problems are just pure functions. The sorts of things used all over the place in industry (supply chain ops for instance) If you want real production software, Starbucks Rewards is/was powered entirely by pure Haskell code and made big bucks Software having complex state actually makes Haskell even better than the competition. Because most state has nuanced rules about its state transitions. Haskell definitely has more of a learning curve when it comes to dealing with state, but that curve will guide you towards a ceiling mainstream languages can't even approximate.
gen220 5y ago
Many banks and hedge funds are semi famously using FP (whether that’s OCaml, Haskell, or Scala). JP Morgan has a big Haskell corner. Jane St is the company I most associate with with OCaml. Jet.com is largely built with F#. In business domains with strict audit requirements, it’s a peace of mind thing, to know that “side effects” (aka persistence and the mutation of persisted data) are constrained to a tiny and highly testable corner of your code base. For OSS, the examples that spring to mind for me are RabbitMQ (Erlang) and Pandoc (Haskell).