4 ms·

I wouldn't say there is any threshold where purely functional programming shines less. Fewer regressions and the system being more likely to "just work" makes i

I wouldn't say there is any threshold where purely functional programming shines less. Fewer regressions and the system being more likely to "just work" makes it more fun to develop. So for interactive programs, servers, CLI tools, parsers et.c. purely functional programming is amazing. An elm developer reported that the prototype they wrote in elm ended up with less bugs than the actual production system. I personally experienced building a system and after I had written a few thousand lines, fixed all compiler errors and then it compiled and was just... done. No bugs where found in production. In F#, an experience report came out where 350k lines of C# were rewritten in 30K of F# code. They also went from 3k null checks to 15 lines of null checks (Plus much more). Zero bugs were reported in the newly deployed system.[0] Now with that said, there are exceptions where purely functional programming languages shines less: - Places where the ecosystem is not quite as mature. If you're building a server and have to interact with Cloud services in Haskell, you'll have a bad time. - Any kind of system where you need to do manual memory management, so systems programming, is badly suited for purely functional programming. [0] https://www.youtube.com/watch?v=MGLxyyTF3OM&t=863s https://www.youtube.com/watch?v=MGLxyyTF3OM&t=863s

Rezwoodly 3y ago
F# is one of the best professional experiences in my career writing software. Unfortunately now Im back in a dynamically typed world dealing with null checks and exceptions..
prewett 3y ago
> I wouldn't say there is any threshold where purely functional programming shines less. But what is the set of problems you are usually solving? Any problem set that involves a lot of mutable set is not well-suited for functional programming, in my opinion. And maybe problems where efficiency is important, although I don't know enough to have an opinion on that. Some areas that come to mind are: - systems programming (which you said) - GUI programming - games - large simulations? Maybe if you can reuse the before and after buffers FP would work okay there. GUI's have a surprising amount of state, which is why immediate-mode GUIs haven't really taken off. (Yes, there's Dear ImGUI, but it actually uses the name of the control to store retained-mode state under the hood) It sounds really good when you think about buttons and sliders, but then you come to text editing or list-box selection...
- myaccountonhn 3y ago
  GUI programming is fine in purely functional programming, see for example elm[0], where you have a Model - Update - View paradigm to build frontends. Another example of GUI programming in Pure FP is functional reactive programming[1]. [0] https://elm-lang.org/ https://elm-lang.org/ [1] https://en.wikipedia.org/wiki/Functional_reactive_programming https://en.wikipedia.org/wiki/Functional_reactive_programmin...
- nailer 3y ago
  Functional reactive programming is very popular for graphical user interfaces. Functions handle state perfectly with scopes and closures.
japhyr 3y ago
> Places where the ecosystem is not quite as mature. If you're building a server and have to interact with Cloud services in Haskell, you'll have a bad time. Why does a server that interacts with cloud services not fit well with functional programming?
- solumunus 3y ago
  Read what you’ve quoted. They say the ecosystem is lacking, not that the issue is inherent in FP.
  - japhyr 3y ago
    They wrote about "places where the ecosystem is not quite as mature", and then referenced interacting with cloud services. I read that as alluding to the rapid development and instability of some cloud services. I've written plenty of non-FP code that interacts with less mature systems, and the problems I've always run into have been related to changing APIs and behaviors of the remote systems, not anything inherent to the language or paradigm I'm using. I was wondering what it is about FP that makes it less suitable for unstable environments.
    - myaccountonhn 3y ago
      What I had in mind was that the library ecosystem just isn't mature yet, so the libraries are incomplete or undocumented.
      - quickthrower2 3y ago
        One way around this maybe to just write a terraform-using library in Haskell then leverage all of it’s compatibility across clouds.
massung 3y ago
> In F# ... 350k lines of C# were rewritten in 30K of F# code. Not discounting the rest of your statements (I love FP for all the reasons), but I really despise - and discount - statements like the one above. I feel they are disingenuous: "This large-ish program that grew over time with evolving needs and uses was rewritten at a later date once the requirements and use-cases were fully understood and - amazingly - we were able to greatly simplify the code!" It probably could have been rewritten in BASIC and still resulted in fewer LOC. That's not to discount the null checks, "zero bugs", or other factors. My favorite part of programming in Haskell is that 99% of the time if it compiles it just works, and I can refactor code + add features without concern.
- myaccountonhn 3y ago
  Of course that statement on it's own can be disingenuous, but in this case it's not only related to better understanding requirements. Lower cyclomatic complexity which functional programming lends itself to contribute to the lower LOC. The new code base had even more features than the previous one had implemented. I think it's relevant.

Rezwoodly 3y ago

F# is one of the best professional experiences in my career writing software. Unfortunately now Im back in a dynamically typed world dealing with null checks and exceptions..

prewett 3y ago

> I wouldn't say there is any threshold where purely functional programming shines less. But what is the set of problems you are usually solving? Any problem set that involves a lot of mutable set is not well-suited for functional programming, in my opinion. And maybe problems where efficiency is important, although I don't know enough to have an opinion on that. Some areas that come to mind are: - systems programming (which you said) - GUI programming - games - large simulations? Maybe if you can reuse the before and after buffers FP would work okay there. GUI's have a surprising amount of state, which is why immediate-mode GUIs haven't really taken off. (Yes, there's Dear ImGUI, but it actually uses the name of the control to store retained-mode state under the hood) It sounds really good when you think about buttons and sliders, but then you come to text editing or list-box selection...

myaccountonhn 3y ago
GUI programming is fine in purely functional programming, see for example elm[0], where you have a Model - Update - View paradigm to build frontends. Another example of GUI programming in Pure FP is functional reactive programming[1]. [0] https://elm-lang.org/ https://elm-lang.org/ [1] https://en.wikipedia.org/wiki/Functional_reactive_programming https://en.wikipedia.org/wiki/Functional_reactive_programmin...
nailer 3y ago
Functional reactive programming is very popular for graphical user interfaces. Functions handle state perfectly with scopes and closures.

japhyr 3y ago

> Places where the ecosystem is not quite as mature. If you're building a server and have to interact with Cloud services in Haskell, you'll have a bad time. Why does a server that interacts with cloud services not fit well with functional programming?

solumunus 3y ago
Read what you’ve quoted. They say the ecosystem is lacking, not that the issue is inherent in FP.
- japhyr 3y ago
  They wrote about "places where the ecosystem is not quite as mature", and then referenced interacting with cloud services. I read that as alluding to the rapid development and instability of some cloud services. I've written plenty of non-FP code that interacts with less mature systems, and the problems I've always run into have been related to changing APIs and behaviors of the remote systems, not anything inherent to the language or paradigm I'm using. I was wondering what it is about FP that makes it less suitable for unstable environments.
  - myaccountonhn 3y ago
    What I had in mind was that the library ecosystem just isn't mature yet, so the libraries are incomplete or undocumented.
    - quickthrower2 3y ago
      One way around this maybe to just write a terraform-using library in Haskell then leverage all of it’s compatibility across clouds.

massung 3y ago

> In F# ... 350k lines of C# were rewritten in 30K of F# code. Not discounting the rest of your statements (I love FP for all the reasons), but I really despise - and discount - statements like the one above. I feel they are disingenuous: "This large-ish program that grew over time with evolving needs and uses was rewritten at a later date once the requirements and use-cases were fully understood and - amazingly - we were able to greatly simplify the code!" It probably could have been rewritten in BASIC and still resulted in fewer LOC. That's not to discount the null checks, "zero bugs", or other factors. My favorite part of programming in Haskell is that 99% of the time if it compiles it just works, and I can refactor code + add features without concern.

myaccountonhn 3y ago
Of course that statement on it's own can be disingenuous, but in this case it's not only related to better understanding requirements. Lower cyclomatic complexity which functional programming lends itself to contribute to the lower LOC. The new code base had even more features than the previous one had implemented. I think it's relevant.