John Backus, one of the pioneers of functional programming, said “Functional programming makes it easy to do hard things, but functional programming makes it very difficult to do easy things.”
Ask HN: When is pure functional programming beneficial?
41–50 of 86 posts
Re: Ask HN: When is pure functional programming beneficial?
#42Systems where you need to prove correctness at least informally. It’s much easier to prove correctness of a functional program than imperative one.
Depends on your definition of "correctness". In MISRA, JSF, and similar areas, memory usage (including stack!) is part of the correctness. If you overflow the stack because of recursion, it doesn't matter how "correct" the rest of the program was, it's still broken. And the same for time. Some programs require proving that you meet the timing constraints. Recursion does not make that easier. (Neither does a language…
Unstructured recursion is incredibly tricky to reason about in terms of stack/heap use and termination, IMO quite a bit moreso than imperative structures. To me, it reproduces most of the same problems of gotos.
There are techniques of factoring out recursion (e.g. "recursion schemes") that can help eliminate these problems, but some things are just easier to reason about imperatively.
Re: Ask HN: When is pure functional programming beneficial?
#43Can be useful for running untrusted code. You can bound your pure functional programs in time and space.
Re: Ask HN: When is pure functional programming beneficial?
#44Earlier quoted context omitted.
Not necessarily. For an easy counter example, build a Sierpiński triangle. Easy to unit test. Easier to build using imperative code than functional. (This goes for a ton of fractals, honestly.)
> Easier to build using imperative code than functional. I am a bit confused about this. The following code is pure and I can't think of an easier way to do it imperatively: function triangle(n) { if (n (p[i - 1] ?? 0) + (p[i] ?? 0)) }
I was actually mildly curious if anyone would call me on having picked an easy fractal to do with the recursion. :) When I wrote the post, I was thinking of the Koch curve. Not sure why I mixed it up in name with the other.
I was definitely leaning on some of the abstractions that you get in the likes of turtle geometry to show how this works. Many of the programs you can write using those primitives are very interesting, and far more unwieldy in any other paradigm.
At large, I view it as the difficulty of forcing Cartesian coordinates. For a large number of problems, things get far easier to state in polar coordinates. Such that your choice of abstraction and representation matters. A lot.
Re: Ask HN: When is pure functional programming beneficial?
#45Functional is the way to go up until you have a problem that you need e.g. TLA+ to solve.
In other words, is your program a calculator or a robot?
Re: Ask HN: When is pure functional programming beneficial?
#46Recommended (free) reading: Professor Frisby's mostly adequate guide to functional programming
https://mostly-adequate.gitbook.io/mostly-adequate-guide/
See discussion: https://news.ycombinator.com/item?id=22654135
Re: Ask HN: When is pure functional programming beneficial?
#47I like pure FP languages for writing UIs. In particular I like languages where you can't have any undefined behavior. I like modeling the state of a page/form/component/whatever as a bunch of constructors on a custom type, each containing exactly the data you need to render the page/form/component/whatever in that given state. I guess this isn't so specific to UIs but it's where I have the most experience. Modeling something as a state machine is cool and good.
Re: Ask HN: When is pure functional programming beneficial?
#48I 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 personal…
> 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...
Re: Ask HN: When is pure functional programming beneficial?
#49IMO pure FP is nice because _compositionality_ is nice. If my problem has lots of simple data structures that represent mathematical objects, then usually I find that most of things I want to do with them can be succinctly modeled with pure function compositions. When my problem gets more complex, including but not limited to state, monads can restore that compositionality in a way that works with the rest of my pure code.
This property is true to varying degrees outside of pure FP too. For example in Rust I find that expression-orientation makes programs fairly easy to compose, modulo thinking about ownership.
Re: Ask HN: When is pure functional programming beneficial?
#50Earlier quoted context omitted.
> Easier to build using imperative code than functional. I am a bit confused about this. The following code is pure and I can't think of an easier way to do it imperatively: function triangle(n) { if (n (p[i - 1] ?? 0) + (p[i] ?? 0)) }
I was actually mildly curious if anyone would call me on having picked an easy fractal to do with the recursion. :) When I wrote the post, I was thinking of the Koch curve. Not sure why I mixed it up in name with the other. I was definitely leaning on some of the abstractions that you get in the likes of turtle geometry to show how this works. Many of the programs you can write using those primitives are very interes…
Another "pure functional" approach to drawing these things is to write a shader program which takes the (x,y) coordinates and returns the pixel values. Here is a parameterized Koch curve done as a shader