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

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

#111

Post by jpt4 » Fri, Dec 09, 2016, 1:47 AM UTC

stcredzero wrote: post #81

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.

The key insight is that immutability is not an end in itself, it's a tool to give us referential transparency. How about a programming environment tailored for small simulations or games? I could imagine such an environment maintaining referential transparency without strict immutability. Rather, such a system could provide a kind of "poor-man's" immutability by only allowing pure functions that take state from tick…

Are you familiar with Urbit [0]?

[0] urbit.org

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

#112

Post by pjmlp » Fri, Dec 09, 2016, 5:36 AM UTC

AnimalMuppet wrote: post #94

KirinDave wrote: post #86

Earlier quoted context omitted.

> A kernel spends most of it's time managing mutable state. Why do you think that FP doesn't have tools for this? Do you genuinely think that in 20+ years of research no one has thought of this? Have you investigated it? I don't know. If you think that things like ST aren't suitable please say why (other than the larger problems with monad transformers, of course).

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

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

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

#113

Post by pjmlp » Fri, Dec 09, 2016, 5:37 AM UTC

willtim wrote: post #84

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…

I don't believe many are advocating functional programming as a replacement for hand-crafted C, but it is a good alterative to imperative high-level languages which often make big performance sacrifices but offer only small improvements in reliability and abstraction/composition. I absolutely believe the correct way to build software is with language layers. Ideally using FP or declarative languages where you can. Py…

Why not? Lisp did it before C was even born.

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

#114

Post by pjmlp » Fri, Dec 09, 2016, 5:41 AM UTC

hota_mazi wrote: post #74

mpweiher wrote: post #39

To me, this is the most important part of the text (p2, bottom): "The ways in which one can divide up the original problem dep end directly on the ways in which one can glue solutions together Therefore to increase ones ability to mo dularise a problem conceptually one must provide new kinds of glue in the programming language." Functional programming is great because it provides two (new) kinds of glue: function com…

> Functional programming is great because it provides two (new) kinds of glue: function composition and lazy evaluation. Certainly true for composition but laziness is more the exception than the rule in today's FP languages. And it's getting an increasingly bad reputation to the point that even Haskell is slowly (and reluctantly) being dragged in the strict direction (which it will never fully reach because so much…

Laziness by default is only a property of the Miranda branch of FP languages, not a feature of all FP languages.

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

#115

Post by lispm » Fri, Dec 09, 2016, 7:36 AM UTC

pjmlp wrote: post #112

AnimalMuppet wrote: post #94

Earlier quoted context omitted.

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

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

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.

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

#116

Post by cousin_it » Fri, Dec 09, 2016, 7:59 AM UTC

kqr wrote: post #95

tdb7893 wrote: post #73

Earlier quoted context omitted.

It seems to me that part of the problem he was having is that he didn't really understand how these methods were being implemented internally. I know that all languages inevitably have these problems but how do the amount of leaky abstractions compare in Haskell to other languages?

I don't think Haskell is worse than any other language in that regard. What perhaps sets it apart is how much of its functionality is implemented in third-party libraries, which may be difficult for a beginner to come to grips with. "Why should I download a library to use efficient arrays? Shouldn't they be built in, like in Python?" I can come up with two explanations for this reliance on third-party libraries. 1) H…

> > how do the amount of leaky abstractions compare in Haskell to other languages?

> I don't think Haskell is worse than any other language in that regard.

Many Haskellers are happy about this kind of stuff:

    min = head . sort

which is the very definition of a leaky abstraction. The blame lies with laziness, because it allows code to depend on implementation details of other code in crazy ways: "sort is O(n log n) unless you ask for only the first element, in which case it's O(n). What if you ask for the last element? Uhhh..."

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

#117

Post by tome » Fri, Dec 09, 2016, 8:03 AM UTC

kqr wrote: post #106

tome wrote: post #99

Earlier quoted context omitted.

It might be simpler than that. Array syntax is not built in in Haskell therefore the array implementation needn't be built in.

I'm sure I misunderstand you, because it sounds to me like other languages were designed on the basis of "Wait! How did this array syntax get built into my language? Oh well, now that it's there I guess I might as well build in arrays..." I would guess those languages get built-in array syntax specifically because they have built-in arrays. The arrays come first, the syntax later.

I suspect that typically both arrive at the same time!

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

#118

Post by tome » Fri, Dec 09, 2016, 8:04 AM UTC

cousin_it wrote: post #116

kqr wrote: post #95

Earlier quoted context omitted.

I don't think Haskell is worse than any other language in that regard. What perhaps sets it apart is how much of its functionality is implemented in third-party libraries, which may be difficult for a beginner to come to grips with. "Why should I download a library to use efficient arrays? Shouldn't they be built in, like in Python?" I can come up with two explanations for this reliance on third-party libraries. 1) H…

> > how do the amount of leaky abstractions compare in Haskell to other languages? > I don't think Haskell is worse than any other language in that regard. Many Haskellers are happy about this kind of stuff: min = head . sort which is the very definition of a leaky abstraction. The blame lies with laziness, because it allows code to depend on implementation details of other code in crazy ways: "sort is O(n log n) unl…

Absolutely agreed! 'head . sort' is efficient by accident!

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

#119

Post by dang » Fri, Dec 09, 2016, 8:05 AM UTC

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…

Please don't do the programming language flamewar thing here. There are plenty of other ways to discuss them.

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

#120

Post by pjmlp » Fri, Dec 09, 2016, 9:43 AM UTC

lispm wrote: post #115

pjmlp wrote: post #112

Earlier quoted context omitted.

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

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.

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