Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: When is pure functional programming beneficial?

news.ycombinator.com

Post reply on HN
Print view View original

51–60 of 86 posts

Re: Ask HN: When is pure functional programming beneficial?

#51

Post by friend_and_foe »

I've been diving into Haskell recently and FP in general and although I lack the deep CS knowledge I find what you said to be nice: everything is atomic.

I personally do a lot of complex math and so I'm using it for programs that are doing a lot of math. I still haven't got my chops enough to do a lot of procedural and external stuff with it yet, I find a higher level language is much easier for that stuff, but when doing math I find that it's much less easy to make mistakes that make it into your production code with Haskell.

Re: Ask HN: When is pure functional programming beneficial?

#52

Post by myaccountonhn »

prewett wrote: post #48
myaccountonhn wrote: post #25

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 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 programmin…

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/ [1] https://en.wikipedia.org/wiki/Functional_reactive_programmin...

Re: Ask HN: When is pure functional programming beneficial?

#53

Post by taeric »

PaulHoule wrote: post #50
taeric wrote: post #44

Earlier quoted context omitted.

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 https://www.shadertoy.com/view/XdcGzH

Sadly, that page isn't loading for me. :( Mistake on my end?

I'm going to guess that the shader version is a bit larger than the naive turtle version. Not that it isn't doable, but is tough evidence to hold for the benefits of the expressive power of functional code. :D

Re: Ask HN: When is pure functional programming beneficial?

#54

Post by agentultra »

I work full-time as a Haskell programmer, I stream myself building various Haskell projects once a week at https://twitch.tv/agentultra, I maintain a couple of Haskell libraries, and I occasionally do other things too.

I've been a professional programmer for a little more than twenty years and have been using Haskell to this degree for about the last 4 or so. A good chunk of my career was dedicated to Python and C. I've done work in C++ and Javascript. Dabbled in Common Lisp in my spare time. Which is to say, I've ran the gamut of functional, imperative, object-oriented, etc.

I got started in OCaml first by taking the Inria course. I later tried Haskell by taking the University of Glasgow course. I often thought of myself as preferring FP but I always worked in languages with escape hatches where I could retreat to familiar territory. It was easy to rationalize this as, "using the right tool for the job." However thanks to some smart people in my life I decided to dip my toes in languages that were FP-first (OCaml) and later FP-only (Haskell).

> Is there a threshold after which Haskell's purely functional paradigm shines the most?

I think you just have to jump in the pool and go for it. There's no threshold. You can write scripts, programs, whole systems in Haskell. There's no point where, "it becomes worth it."

I'm certain at this point that you can write a relational database engine that is comparable in performance and features as any other in the market in Haskell. You can write video games in it. You can write short helper scripts and tools. Word editors, websites, compilers, etc.

The threshold is how willing you are to leave behind what you're already familiar with and learn a new way of programming that will make you feel like a complete beginner again for a while. Are you willing to re-learn programming over again? I don't know why this is surprising to people but if you started with a C-like language and picked up other C-like languages along the way, picking up Haskell isn't going to be as easy: there's nothing familiar you can use in your C-like knowledge that will be useful for a long while.

I've been doing it for a while now and there are benefits to it which is why I still program in Haskell and got a job writing code in Haskell. You likely already have a good deal of the tools needed to reason about how to design programs in a pure FP language: sets and high-school level algebra. You have notions built into the type system in Haskell like equality, relations, and constraints. Once you start jogging your brain on how to think this way you can design most of your program in types. And when you do it this way, there tends to be only one or a couple of ways to implement a program that satisfies those types... it's almost a mechanical process of filling in the holes.

From a practical perspective of a former Python programmer, I don't have to write a good deal of unit tests I would usually start with when building a Python program. Armed with a well-thought out handful of types the compiler will reject any program that isn't correct by construction which allows me to focus more of my efforts on things that are more important to me: is the logic correct, etc. I'm not testing, "are these things equal," "does this throw an expected error," "is this actually a valid function," etc.

Another weird thing that happens when you learn to program in Haskell is that control flow is kind of... represented in data types. Since Haskell is expression-oriented and execution is carried out by evaluation we get neat features like whole program analysis of all code branches. If I add a new constructor to a sum type, I get instance feedback on all the places where I need to now handle that case. This is super useful.

However... it can be a challenge getting to this place where you're comfortable with it. I had a hard time when I started a small Haskell project early on to make a simple web app. I was so used to logging being a single import away that having to learn all these new concepts in Haskell like, "monad transformers," just to add logging to my app seemed like a bunch of busy work for something that was, "solved," in my mind. The key to getting through moments like that is to forget your past experiences and just open your mind to being a beginner again.

It becomes useful later on when you realize that composition is so incredibly useful. You start to miss it when you go back to procedural languages and there are no guarantees and nothing composes.

Re: Ask HN: When is pure functional programming beneficial?

#55

Post by EdSharkey »

Imperative shell, (ever-expanding-through-relentless-refactoring) functional core seems to work pretty well for practical applications. Modern Java gets the job done in that regard.

What I don't like is the concentration level required for functional productions over equivalent imperative routines. I have found it difficult to impress upon junior developers the testing advantages of functional programming and in refactoring pairing sessions with them, they quickly lose the thread and go all doe eyed.

I feel like the current functional programming paradigms favor terseness that completely obliterates the thought process that led to the production. So, even if junior has the aha moment when we reach the end of the production, and understands what we just achieved there in 6 lines of dense code, they'd be at a loss to retrace it themselves in the future because the thought processes of each operator in the production require too much simulation space in the head.

That, and libraries like RxJS that layer in concepts of time and observables and higher-order observables with sneaky completion states that only stretch the mind further because the true semantics of the program are coupled with under-documented quirky edge cases of the operators. Running into one of those while pairing with junior is not exactly confidence building.

Long-form programming with named pure functions might help, but then I suppose you can lose the terseness and can get lost in a sea of 1-line named functions.

Re: Ask HN: When is pure functional programming beneficial?

#57

Post by PaulHoule »

taeric wrote: post #53
PaulHoule wrote: post #50

Earlier quoted context omitted.

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 https://www.shadertoy.com/view/XdcGzH

Sadly, that page isn't loading for me. :( Mistake on my end? I'm going to guess that the shader version is a bit larger than the naive turtle version. Not that it isn't doable, but is tough evidence to hold for the benefits of the expressive power of functional code. :D

It is 74 lines of basically C code on a page that runs the shader with WebGL. On my iPad it renders at 60 fps with a parameter that changes. It’s really neat.

It doesn’t look like “functional code” but it really is since the shader returns a pixel color for x and y. I bet there is some squarish kind of fractal that could be code golfed with but manipulation.

Re: Ask HN: When is pure functional programming beneficial?

#58

Post by japhyr »

myaccountonhn wrote: post #25

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 personal…

> 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?

Re: Ask HN: When is pure functional programming beneficial?

#59

Post by toast0 »

PaulHoule wrote: post #19
taeric wrote: post #14

Earlier 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.)

It burns me up that Fibonacci numbers are used so frequently as an example of functional programming because it is a clear case of malpractice, particularly because it performs terribly without memoization. Even in the 1980s CS profs were trying to tell us how BASIC sucks but efficient Fibonacci is so easy to code up in BASIC. (I'd really be impressed with a system that could figure out the closed form based on the d…

I don't see why you can't write the closed form in a functional language as well. This only works for 1 == 71 the approximation of Sqrt5 isn't good enough; you need to do more symbolic math so you can eliminate that term.

  -module('fib').
  -export([go/1]).


  go(N) when N  throw(badarg);
  go(N) ->
        Sqrt5 = math:sqrt(5),
        round(1.0 / Sqrt5 * math:pow((1 + Sqrt5) / 2.0, N) - 1.0 / Sqrt5 * math:pow((1 - Sqrt5) / 2.0, N)).

  rp(lists:map(fun fib:go/1, lists:seq(1, 71))).
  [1,1,2,3,5,8,13,21,34,55,89,144,233,377,610,987,1597,2584,
 4181,6765,10946,17711,28657,46368,75025,121393,196418,
 317811,514229,832040,1346269,2178309,3524578,5702887,
 9227465,14930352,24157817,39088169,63245986,102334155,
 165580141,267914296,433494437,701408733,1134903170,
 1836311903,2971215073,4807526976,7778742049,12586269025,
 20365011074,32951280099,53316291173,86267571272,
 139583862445,225851433717,365435296162,591286729879,
 956722026041,1548008755920,2504730781961,4052739537881,
 6557470319842,10610209857723,17167680177565,27777890035288,
 44945570212853,72723460248141,117669030460994,
 190392490709135,308061521170130]
( 190392490709135 + 117669030460994 /= 308061521170130 )

Re: Ask HN: When is pure functional programming beneficial?

#60

Post by solumunus »

japhyr wrote: post #58
myaccountonhn wrote: post #25

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 personal…

> 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?

Read what you’ve quoted. They say the ecosystem is lacking, not that the issue is inherent in FP.
Post reply on HN