Why Functional Programming Matters (1984) [pdf]

Re:Why Functional Programming Matters (1984) [pdf] by AnimalMuppet on Thursday December 08, 2016 @03:28PM (#13133970)

I know that FP has tools for that. But if the problem is primarily managing mutable state, isn't a tools that lets you directly see what you're doing a better fit?

Are the FP tools as efficient as the direct, C-style approach? For an OS, that matters.

Are the FP tools as easy to reason about correctly (especially in a section you're not familiar with)? For an OS that's worked on by thousands of people, that matters.

In this context, what is "ST"? And, what are the larger problems with monad transformers?

[ Parent | on HN ]

Re:Why Functional Programming Matters (1984) [pdf] by KirinDave on Thursday December 08, 2016 @04:28PM (#13134464)

What's most frustrating about these conversations is what I've noted in another thread: people feel really comfortable talking about what FP can and can't do without even acquainting themselves with 10+ year old techniques in the field.

I'm sorry, I decline to continue this conversation further.

[ Parent | on HN ]

Re:Why Functional Programming Matters (1984) [pdf] by pjmlp on Friday December 09, 2016 @12:36AM (#13136894)

How do you think Xerox PARC, Genera and TI managed to write Lisp based OSes?

[ Parent | on HN ]

Re:Why Functional Programming Matters (1984) [pdf] by lispm on Friday December 09, 2016 @02:36AM (#13137315)

By using all the imperative, procedural and object-oriented features of Lisp.

In many ways the early MIT Lisp Machine morphed into a Flavors Machine in the early 80s.

Remember, Lisp is a multi-paradigm language.

[ Parent | on HN ]

Re:Why Functional Programming Matters (1984) [pdf] by pjmlp on Friday December 09, 2016 @04:43AM (#13137744)

But that is the thing, none of the successful FP languages in the industry are pure FP, rather multi-paradigm, even if functional first.

[ Parent | on HN ]