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

141–145 of 145 posts

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

#141

Post by kazinator »

pka wrote: post #22
jlouis wrote: post #11

Earlier quoted context omitted.

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.

ST monad is not state; it's a convoluted way of threading a value through a chain of functions. State means we put the value into the same memory location (or CPU register, or piece of tape or whatever).

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

#142

Post by kazinator »

willtim wrote: post #135
kazinator wrote: post #129

Earlier quoted context omitted.

Why, all of them, in a Lisp machine. Probably zero of them, in any non-Lisp machine. Lisp is a fairly nuts-and-bolts language suitable for device drivers, depending on what you include in it. The The basic Lisp evaluation model is close to machine language: Lisp values readily map to words (32 bit, 64 bit, whatever) stored in registers, and pushed onto a conventional stack during function calling. Lisp compilers can…

Nice write up. I'm not sure "Lispified" assembly language really counts as functional programming though. It suggests a layering approach that I suggested originally. Of course, Lisps ubiquitous linked-list and dynamic types are issues for efficient compilation that are not shared by every functional language. The Mirage project is having a lot of success writing a lot of low-level code in OCaml.

Why would you slavishly try to stick to a functional approach when making device drivers in Lisp (or anything else).

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

#143

Post by samuell »

michaelfeathers wrote: post #49
jlouis wrote: post #11

Earlier quoted context omitted.

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…

The key insight is that immutability is not an end in itself, it's a tool to give us referential transparency. If a language can allow mutability in an area of code without allowing side effects to escape from it we can have all of the reasoning advantage that FP gives us at a level above the mutations. We can also have the performance we want.

> If a language can allow mutability in an area of code without allowing side effects to escape from it we can have all of the reasoning advantage that FP gives us at a level above the mutations. We can also have the performance we want.

As far as I see and can tell from experience, this exactly the power of the black-box processes of Flow-based Programming (FBP), communicating only via message passing (on buffered channels) [1].

FBP processes can be compared to "functions", but are free to change state etc. The "only communicate via message passing" means funny side-effects are effectively contained to the process itself.

Furthermore, I would argue that FBP, via its specification of keeping the network connectivity separate from the process implementation, makes FBP programs so extremely much more composable than most typical FP programs, which often allow references to other functions be hard-coded inside function code.

It is like making the call graph of an FP program declaratively configured by a list of processes and connections:

Processes: A (ports out1, out2) B (ports in1, out1) C (ports in1, out1)

Connections: A.out1 -> B.in1 A.out2 -> C.in1

etc.

I wrote a little text processing app in this style some time ago (The network connectivity scheme can be seen here: https://github.com/rdfio/rdf2smw/blob/master/main.go#L100-L1... ) and was amazed by the clarity and composability that emerged, even though I just used my own little experimental subset of full FBP ( http://flowbase.org ). As far as I can tell, this helped me going from first line of code to finished app go extremely fast ... app written in 2 days without ever really getting stuck in any strange bug due to bad code organization, which use to happen all the time otherwise.

[1] https://en.wikipedia.org/wiki/Flow-based_programming

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

#144

Post by samuell »

samuell wrote: post #143
michaelfeathers wrote: post #49

Earlier quoted context omitted.

The key insight is that immutability is not an end in itself, it's a tool to give us referential transparency. If a language can allow mutability in an area of code without allowing side effects to escape from it we can have all of the reasoning advantage that FP gives us at a level above the mutations. We can also have the performance we want.

> If a language can allow mutability in an area of code without allowing side effects to escape from it we can have all of the reasoning advantage that FP gives us at a level above the mutations. We can also have the performance we want. As far as I see and can tell from experience, this exactly the power of the black-box processes of Flow-based Programming (FBP), communicating only via message passing (on buffered c…

Ouch, didn't see that the formatting got lost before editing was frozen ... should be:

Processes:

A (ports out1, out2)

B (ports in1, out1)

C (ports in1, out1)

Connections:

A.out1 -> B.in1

A.out2 -> C.in1

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

#145

Post by pka »

kazinator wrote: post #141
pka wrote: post #22

Earlier quoted context omitted.

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

ST monad is not state; it's a convoluted way of threading a value through a chain of functions. State means we put the value into the same memory location (or CPU register, or piece of tape or whatever).

ST is exactly that. You probably mean the State monad.
Post reply on HN