Why Functional Programming Matters (1984) [pdf] • Hacker News Board

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

#21

Post by bogomipz » Thu, Dec 08, 2016, 1:41 PM UTC

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…

>"It does not work well in programs which have high requirements for performance or memory"

Can you elaborate on why this is?

I see the parent post mentioned "lazy evaluation." Can you say why this is relevant to discussions on resource utilization and performance?

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

#22

Post by pka » Thu, Dec 08, 2016, 1:51 PM UTC

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…

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

You can do that in a pure language as well (i.e. ST monad.) Purity shouldn't be given up lightly.

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

#23

Post by nilved » Thu, Dec 08, 2016, 2:06 PM UTC

ahallock wrote: post #13

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

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

#24

Post by century19 » Thu, Dec 08, 2016, 2:07 PM UTC

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 does not work well in programs which handle a lot of states

Apache Spark is written in Scala. It can handle extremely large amounts of state across large clusters of machines. Is the argument here that Scala is not purely functional? Or what am I missing?

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

#25

Post by kqr » Thu, Dec 08, 2016, 2:13 PM UTC

ahallock wrote: post #13

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 does not work well in programs which handle a lot of states From what I understand, isn't this what functional programming excels at?

Handling "a lot of states" (rather, a large state space) is a hard problem in any paradigm.

Pure languages make this complexity apparent, and thus gives the programmer a true sense of how hard it is to do right. This makes it seem "harder" than in impure languages.

Impure languages let you get away with handwaving the state space, which – to be fair – is often enough. But when it isn't, you pay dearly for it after the fact.

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

#26

Post by fbreduc » Thu, Dec 08, 2016, 2:16 PM UTC

cousin_it wrote: post #20

tome wrote: post #19

Earlier quoted context omitted.

No, that's not laziness per se, that's "lazy IO", something somewhat different. EDIT: It's not even a lazy IO problem since no lazy IO functions are used there.

The problem is laziness. Lazy IO just makes it happen with files, which is more noticeable. In regular lazy code it happens with memory instead (space leaks).

these are not problems, only small details that you have to be careful of..not a large tradeoff to pay

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

#27

Post by kqr » Thu, Dec 08, 2016, 2:17 PM UTC

bogomipz wrote: post #21

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…

>"It does not work well in programs which have high requirements for performance or memory" Can you elaborate on why this is? I see the parent post mentioned "lazy evaluation." Can you say why this is relevant to discussions on resource utilization and performance?

Higher levels of abstraction are harder to translate to efficeint machine code.

Non-strict (what you call "lazy") evaluation can make it more difficult to predict when resources are needed. In strict languages, the resources needed to evaluate f() are needed exactly at the point where you typed "f()".

With non-strict evaluation, those resources may be needed then, later, or not at all! If those resources happen to be needed when a) they are no longer available, or b) at the same time as a bunch of other computations need resources, you have problems.

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

#28

Post by GrumpyNl » Thu, Dec 08, 2016, 2:20 PM UTC

You can program functional in almost any language. Its more a mindset. I can not emphasize this enough, keep it simple.

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

#29

Post by paulddraper » Thu, Dec 08, 2016, 2:21 PM UTC

century19 wrote: post #24

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 does not work well in programs which handle a lot of states Apache Spark is written in Scala. It can handle extremely large amounts of state across large clusters of machines. Is the argument here that Scala is not purely functional? Or what am I missing?

By "lots of state" I don't think he meant "lots of data", but rather data that get changed a lot: Q&A forum, CRUD application, etc.

Functional paradigms can still be used (e.g. HackerNews, though let's be honest...I love it but it's not the most challenging feature set). But FP isn't as natural of a fit as the problems chosen to introduce it.

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

#30

Post by century19 » Thu, Dec 08, 2016, 2:25 PM UTC

paulddraper wrote: post #29

century19 wrote: post #24

Earlier quoted context omitted.

-- Functional programming does not work well in programs which handle a lot of states Apache Spark is written in Scala. It can handle extremely large amounts of state across large clusters of machines. Is the argument here that Scala is not purely functional? Or what am I missing?

By "lots of state" I don't think he meant "lots of data", but rather data that get changed a lot: Q&A forum, CRUD application, etc. Functional paradigms can still be used (e.g. HackerNews, though let's be honest...I love it but it's not the most challenging feature set). But FP isn't as natural of a fit as the problems chosen to introduce it.

Not saying your wrong about what he meant, but Spark can also keep state across the Cluster, not just data. Check out the "UpdateStateByKey Operation" in the following page.

http://spark.apache.org/docs/latest/streaming-programming-gu...