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

Why Functional Programming Matters (1984) [pdf]

cse.chalmers.se

Post reply on HN
Print view View original

51–60 of 145 posts

Re: Why Functional Programming Matters (1984) [pdf]

#51

Post by lmm »

cousin_it wrote: post #17

The top link on /r/haskell right now [1] is someone complaining that their program runs out of space due to a subtle interaction between laziness and IO. I think it's safe to say that we have tried laziness as the default and have learned that it's the wrong default, because it plays havoc with space and with IO. [1] https://www.reddit.com/r/haskell/comments/5h6emf/haskell_run...

Sure. I'll be moving to Idris as soon as it matures, since by enforcing totality you gain the advantages of laziness without the problems.

In the meantime Haskell may well be the best option for various circumstances even with that flaw though. (And note that strict evaluation in non-total languages brings its own problems)

Re: Why Functional Programming Matters (1984) [pdf]

#53

Post by johncolanduoni »

KirinDave wrote: post #47
kutkloon7 wrote: post #6

A lot of pleas for functional programming give a long list of convincing examples that work well with functional programming. You can do this with almost any language, and this is also quite deceptional, as this is often done to convince beginners to learn another language; "look at how simple it is to program this contrived example in !". In order to be able to use a programming language or paradigm well, it is espe…

> In order to be able to use a programming language or paradigm well, it is especially useful to know what its weaknesses are. Functional programming does not work well in programs which handle a lot of states. It does not work well in programs which have high requirements for performance or memory. It does not work well for programs which have to do low-level stuff. By the same token, whenever this conversation come…

> The main gate to functional languages participating in, say, the Linux kernel is NOT that they are "too slow" or that "laziness makes them too confusing". It's that the Linux kernel is written entirely around the unique weirdness and expectations of C, and only languages based on or descendant to C do well there.

Sure, but the usual functional style has intrinsic issues that prevent it from being feasible for writing kernels in general. A kernel (especially a microkernel) spends most of its time managing state. You can use a functional language as a metalanguage for an imperative DSL (as the Atom DSL for constant-space programming uses Haskell), but you won't be writing code that looks remotely functional.

Re: Why Functional Programming Matters (1984) [pdf]

#54

Post by johncolanduoni »

jlouis wrote: post #11
kutkloon7 wrote: post #6

A lot of pleas for functional programming give a long list of convincing examples that work well with functional programming. You can do this with almost any language, and this is also quite deceptional, as this is often done to convince beginners to learn another language; "look at how simple it is to program this contrived example in !". In order to be able to use a programming language or paradigm well, it is espe…

Functional programming largely has two schools: Treat "commands" as a separate entity from expressions, and bake "commands" into expressions. The former is largely Haskell, Clean, ... and the latter is exemplified by e.g., Standard ML or OCaml. There are trade-offs between the two, but I definitely belong to the second school: we simply add an imperative subset to our functional language. This means we can exploit an…

> There are trade-offs between the two, but I definitely belong to the second school: we simply add an imperative subset to our functional language. This means we can exploit any efficiency trick an imperative program can do, including low-level stuff. The seasoned FP programmer will then proceed to encapsulate the efficiency trick in a abstract module such that the rest of the program doesn't have to worry about it. Of course, the price to pay for this is that you are losing purity. I think this is a fair trade-off but others disagree.

I think the trade-off is unnecessary. If your language can embed a convenient method for analyzing the imperative state in the way it is typically used (F* is a good example), you can get a similar result by lifting your internally stateful but externally pure code into truly pure functions, even if it wants to do something more complicated than simpler state monads can do conveniently. The compiler can then understand the language's state construction and write the imperative code directly when generating machine code, with little more infrastructure than OCaml needs to allow you to do so anywhere.

This way you get to keep purity without requiring you to lose performance or jump through hoops to keep your pure code downstream of your impure code.

Re: Why Functional Programming Matters (1984) [pdf]

#55

Post by darksaints »

nilved wrote: post #23
ahallock wrote: post #13

Earlier quoted context omitted.

> Functional programming does not work well in programs which handle a lot of states From what I understand, isn't this what functional programming excels at?

Yes. You can model state easily in functional programming languages but the technique is unfamiliar to imperative programmers since it's more explicit. This is a very good thing.

More explicit? Try more convoluted. Ever try to build an event-driven FSM in Haskell? I've seen several try, including myself...the results of which have all been complexity disasters.

Imperative languages in general have poor data structures for representing state (no ADTs!), but nothing is more explicit and straightforward than using mutable data or mutable containers for modeling actual mutable state. That's why languages like Scala exist. Functional without religious paradigm enforcement.

Re: Why Functional Programming Matters (1984) [pdf]

#56

Post by tel »

gengstrand wrote: post #50
bad_user wrote: post #40

Earlier quoted context omitted.

And it's not just about linked lists vs arrays, but also about the actual call stack. FP code tends to be heavy on recursive algorithms, which means you need mutually tail recursive functions. And laziness. Somebody mentioned the State monad and the IO type. Well, these are lazy abstractions with a memory-safe bind/flatMap operation that makes them tick. Well, the problem with these abstractions is that they'll requi…

It appears that your claim "Scala or Clojure that don't have real tail recursion because of the JVM" is in error. http://stackoverflow.com/questions/1677419/does-scala-suppor... http://clojure.org/reference/special_forms#recur

It's not exactly an error. Neither language offers enough tail recursion to handle complex cases though they both offer simple support.

Re: Why Functional Programming Matters (1984) [pdf]

#57

Post by throwawayfp00 »

This essay is as much an apology for Miranda and Haskell style lazy-by-default evaluation as it is for functional programming itself, and it's therefore absurd that in 2016 it's still being posted here, let alone enthusiastically upvoted.

Lazy-by-default evaluation is a bad idea. It makes the design of the compiler orders of magnitude more complicated (see GHC) and in practice results in nasty performance-related bugs (space leaks) that can be catastrophic when encountered in production.

Idris is gaining on Haskell in large part because of its strictness, and the GHC high priests not long ago relented and added a strictness pragma to their compiler in response (which does not actually give you a strict program). And of course they did this without any frank acknowledgement that the choice of default evaluation strategy for Haskell was a colossal mistake. Nor has the Haskell community apologized for its extremely disingenuous past advocacy that sold lazy-by-default evaluation as a powerful optimization, like this paper does, when in practice it's usually the exact opposite.

The Haskell community is extremely cultish, even by the standards of FP.

Re: Why Functional Programming Matters (1984) [pdf]

#58

Post by bad_user »

gengstrand wrote: post #50
bad_user wrote: post #40

Earlier quoted context omitted.

And it's not just about linked lists vs arrays, but also about the actual call stack. FP code tends to be heavy on recursive algorithms, which means you need mutually tail recursive functions. And laziness. Somebody mentioned the State monad and the IO type. Well, these are lazy abstractions with a memory-safe bind/flatMap operation that makes them tick. Well, the problem with these abstractions is that they'll requi…

It appears that your claim "Scala or Clojure that don't have real tail recursion because of the JVM" is in error. http://stackoverflow.com/questions/1677419/does-scala-suppor... http://clojure.org/reference/special_forms#recur

I specifically mentioned mutually tail recursive functions. Self-recursive functions, like what you're describing, are much less useful or interesting.

I say that as a Scala developer that loves Scala and the JVM - the lack of tail calls optimization at the JVM level is a pain in the ass, because in order to work around it you have to effectively build your own call stack.

Re: Why Functional Programming Matters (1984) [pdf]

#59

Post by [deleted] »

throwawayfp00 wrote: post #57

This essay is as much an apology for Miranda and Haskell style lazy-by-default evaluation as it is for functional programming itself, and it's therefore absurd that in 2016 it's still being posted here, let alone enthusiastically upvoted. Lazy-by-default evaluation is a bad idea. It makes the design of the compiler orders of magnitude more complicated (see GHC) and in practice results in nasty performance-related bug…

[deleted]

Re: Why Functional Programming Matters (1984) [pdf]

#60

Post by KirinDave »

johncolanduoni wrote: post #53
KirinDave wrote: post #47

Earlier quoted context omitted.

> In order to be able to use a programming language or paradigm well, it is especially useful to know what its weaknesses are. Functional programming does not work well in programs which handle a lot of states. It does not work well in programs which have high requirements for performance or memory. It does not work well for programs which have to do low-level stuff. By the same token, whenever this conversation come…

> The main gate to functional languages participating in, say, the Linux kernel is NOT that they are "too slow" or that "laziness makes them too confusing". It's that the Linux kernel is written entirely around the unique weirdness and expectations of C, and only languages based on or descendant to C do well there. Sure, but the usual functional style has intrinsic issues that prevent it from being feasible for writi…

> Sure, but the usual functional style has intrinsic issues that prevent it from being feasible for writing kernels in general.

Not really?

> A kernel (especially a microkernel) spends most of its time managing state.

So does every computer program though. The idea that functional languages can't support mutation is a strangely persistent myth even in the face of multiple counter-examples AND 20 years of improvement via research and practical work.

> but you won't be writing code that looks remotely functional.

Many useful & powerful functional abstractions can be written to use constant space, even in Haskell.

Post reply on HN