5 ms·
Functional Programming is a big tent, too big to be very useful. All good programming provides some proof of correctness, through test coverage, the type system
by haskellandchill 9y ago
Functional Programming is a big tent, too big to be very useful. All good programming provides some proof of correctness, through test coverage, the type system, or a bit of reasoning done to the side (worst case). Ease of reasoning from FP in the large is not very valuable but does eliminate some cognitive overhead. There are no disadvantages to higher order functions and referential transparency except those we impose on ourselves with our choice of hardware. Type systems are where the meat is at, and a good type system clearly states the advantages and disadvantages in its design.
- seanmcdirmid 9y agoHigher-order functions and indirection in general can lead to increased cognitive overhead. Try reading or debugging a deep points free functional expression and it's obvious there are limits.
- darkkindness 9y agoIn my own (limited) experience, I'd much rather debug a nasty pointfree expression than debug a deep nest of loops keeping state in mind. Perhaps it is just different kinds of cognitive overhead.
- seanmcdirmid 9y agoHow would you even go about stepping through a pointsfree expression though? Have Haskell/scala debuggers improved significantly in this regard?
- cgmg 9y agoYou should try the Writer monad, which adds an extra value for logging: http://learnyouahaskell.com/for-a-few-monads-more http://learnyouahaskell.com/for-a-few-monads-more
- darkkindness 9y agoI wasn't aware these debuggers existed. I'll have to check them out. The purpose of writing point-free functions is to encourage thinking about chaining functions together instead of considering what really happens to low-level values. It's like using pipelines. This means that for debugging, "stepping through" wouldn't help you much IMO even if you could do it![0] (A whiteboard might help, though.) I'll try to give an example: if you're looking at an unnecessarily point-free expression like "mapReduce = (. map) . (.) . foldr1", the logic is difficult to read. I'm not an expert in point-free-fu yet, so in that case I'd recommend pointful[1], which deobfuscates that expression to "mapReduce x x0 x2 = foldr1 x (map x0 x2)", a map followed by a fold. So the problem is again reduced to looking how functions are being chained together. For larger examples of point-free expressions I'd try to isolate individual functions as where clauses. [0] As mentioned by cgmg, the Writer monad is useful if you need to know the values going in and out of functions. [1] http://github.com/23Skidoo/pointful http://github.com/23Skidoo/pointful
- seanwilson 9y ago> Ease of reasoning from FP in the large is not very valuable but does eliminate some cognitive overhead. I really wouldn't underestimate this. Formal proofs and verified programs pretty much always involve functional languages at the core because there's just less going on to complicate the proof. Once you start introducing state, manual memory management, unrestricted recursion, pointers, undefined behaviour etc. it becomes much, much harder to write proofs about programs and justify why they're bug free. This also carries across to humans...it's much easier to reason in your own head why a program is correct when the program behaviour is simple.
- haskellandchill 9y agoTrue, but I would want that reasoning to have some representation in the code as well, which doesn't happen if you do a proof to the side.