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

101–110 of 145 posts

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

#101

Post by KirinDave »

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

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.

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

#102

Post by marxama »

whateveracct wrote: post #91
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…

NOTE: I agree with your comment as a whole but I want to give some counterpoints to some things you've said. These counterpoints all do require more "advanced" FP ability, but as FP becomes more popular, these techniques will become less "advanced." > Functional programming does not work well in programs which handle a lot of states. I've rewritten stateful, greedy, backtracking algorithms from Java to Scala. Scala (…

With regards to performance, sometimes taking the penalty of immutability in the small leads to gains in the large. The React wrappers in ClojureScript are a great example of this - since all data is immutable, shouldComponentUpdate is trivially and automatically implemented for you, meaning React not having to diff parts of the virtual DOM that are guaranteed to be identical.

There are other cases where immutability helps, even with regards of performance. At my day job, we use C#, with little focus on immutability. Performance has been a huge problem lately. One of the things we did was to change lots of constructors which initialized empty lists. In most cases, these lists remain empty, so we created a whole bunch of objects unnecessarily, which put a lot of toll on the GC. The "solution" was to initialize them to null instead, which made the code a lot more brittle and cumbersome. Had we used immutable lists instead, we could've shared one single, empty object instead (per type, of course).

We also have lots of copy constructors which we use often - these would be completely unnecessary with immutable data.

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

#103

Post by pmarreck »

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…

The longer time I spent programming, the more at least the functional paradigm (even within non-functional languages) made sense, mostly as a labor-saving device (like all things in programming) resulting in fewer bugs, easier modularity, easier unit testability, etc. etc.

Apparently I'm not alone, here's John Carmack's take on it after "trying it on" for a while in C++, he has some very strongly positive things to say about it: http://www.gamasutra.com/view/news/169296/Indepth_Functional...

You haven't listed the specific disadvantages of FP, one I noticed with a bit of dismay was that the code for a basic quicksort in functional languages looks like this (Elixir in this case: https://gist.github.com/rbishop/c742ab53b12efc162176) and is actually quite beautiful BUT performs fairly horribly. (It is rare for me to find code that looks this good/simple and yet is one of the worst-performing.) The same algorithm is also slow in Haskell (which is where I first saw it).

Some might cite the preponderance of recursion instead of looping as a fault or flaw (since the language implementation needs to then implement TCO in order to not trivially blow the stack... and the programmer needs to be AWARE of how to trigger TCO), but in practice I prefer it because a semantically-infinite-recursing process ends up being a "nicer" paradigm even if in actuality it's implemented underneath with a loop construct.

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

#104

Post by omaranto »

johncolanduoni wrote: post #68
omaranto wrote: post #63

Earlier quoted context omitted.

Saying that Clojure and Scala don't do tail call optimization because of the JVM could be a little misleading. The JVM is a pretty general compilation target, I'm sure you could implement tail call optimization in a compiler targeting the JVM in any of the usual ways. If Clojure and Scala don't do it it must be for some other reason. If I had to guess I'd say it's probably (1) that the developers don't think TCO is t…

You can implement tail recursion optimization on top of the JVM (which is far, far away from a general compilation target BTW), where the distinction is that the function may only call itself. These cases can always be trivially rewritten into loops, and I know at least Scala does this just fine. More generally tail call optimization allows you to avoid pushing a stack frame for any call in tail position. The JVM (or…

I think you're implicitly thinking that a sensible compiler targeting the JVM would compile whatever functions the source language has to JVM methods and call them via the usual JVM method call instruction. That's certainly a good thing to do if you want have simple Java interop and to reuse the JVM's call logic instead of simulating your own calling convention with other instructions.

I was implicitly thinking there's nothing forcing you to use the JVM calling convention. For example your compiler could transform the source to CPS. That probably would generate slow code and interop would be awkward (because normal Java libraries aren't already in CPS).

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

#105

Post by omaranto »

johncolanduoni wrote: post #68
omaranto wrote: post #63

Earlier quoted context omitted.

Saying that Clojure and Scala don't do tail call optimization because of the JVM could be a little misleading. The JVM is a pretty general compilation target, I'm sure you could implement tail call optimization in a compiler targeting the JVM in any of the usual ways. If Clojure and Scala don't do it it must be for some other reason. If I had to guess I'd say it's probably (1) that the developers don't think TCO is t…

You can implement tail recursion optimization on top of the JVM (which is far, far away from a general compilation target BTW), where the distinction is that the function may only call itself. These cases can always be trivially rewritten into loops, and I know at least Scala does this just fine. More generally tail call optimization allows you to avoid pushing a stack frame for any call in tail position. The JVM (or…

An example of a language implementation that does full TCO and targets the JVM: http://sisc-scheme.org/

I couldn't find this right away, but vaguely recall reading SISC transforms to CPS to anable this (and call/cc).

I think Kawa scheme supports two calling conventions: the standard JVM one and a second one for which it can do full TCO. The second one is a bit slower so the default in Kawa is not to do full TCO.

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

#106

Post by kqr »

tome wrote: post #99
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…

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.

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

#107

Post by kazinator »

greggman wrote: post #89
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'm too much of a noob to know what I'm talking about but so far this series of talks has convinced me FP with strong typing brings something new to the table in the same way that say C brings something over assembly and s expressions in lisp bring something over non s expression languages. http://fsharpforfunandprofit.com/ In particular this example convinced me I'm missing out on something http://fsharpforfunandpro…

Well, C brings ... functional programming over assembly, right? Look, calculation with machine words, but without side effects:

   int x = 42;
   int y = x / 2;
   double z = sqrt(x*x + y*y);
   return 1 + z;
We're just binding fresh variables, and nesting expressions that evaluate terms and return results. No assignment anywhere.

Yes, functional programming matters. It lets you add two things together in C without worrying about allocating a destination operand for the result, whose clobbering won't affect anything anywhere else.

This sort of thing in turn makes it a heck of a lot easier to write OS schedulers, drivers, memory managers, codecs, ray tracers, database engines, ...

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

#108

Post by bunderbunder »

m0th87 wrote: post #71

See also Raganwald's Why Why Functional Programming Matters Matters: http://weblog.raganwald.com/2007/03/why-why-functional-progr...

Ironically, his "rules of Monopoly" analogy helped me realize why I haven't completely given up on OOP, especially for non-hobby work.

He holds up the idea that every piece of the game has the rules for what you can do with it tacked on as some sort of horrible mess, but, in the age of code completion, I'm finding that it's used to drive an amazing convenience from a practical perspective: Code completion.

Take Python, which is a language that I'm still learning. If I have an object, but I'm not sure what I can do with it - or, more particularly, I'm not sure of the names for the things I can do with it - I can get a quick reference by hitting '.-tab' to bring up an autocompletion menu, just so long as I'm interacting with a more OO Python library. If I'm trying to work with a more procedural library such as matplotlib, though, I'm SOL and end up having to dive through the documentation. (I can't think of a really great functional library for Python that I use, but the same is true for the more functional-y bits of numpy and pandas.) And matplotlib is a big library, so there's a lot of documentation. Far from being a form of organization, that fabled central store of the rules that the author holds up as an ideal ends up being an awful quagmire to wade through.

Granted, this is dependent on having an editor that does tab completion. And I'm sure it could be done with a functional library, too, but probably only if you're using a statically typed functional language, and I've no idea what a good UX would look like given how functional syntax works.

But still, given the current situation, I think I've realized my main reason for thinking that object-oriented programming also matters: Because right now, when you're working with large and complicated systems, object-oriented programming still offers the more pragmatic, human-friendly user experience.

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

#109

Post by marcosdumay »

pka wrote: post #93
marcosdumay wrote: post #61

Earlier quoted context omitted.

Anything that needs rewriting a memory address without losing time by allocation and garbage collection. Handling IO exceptions and masking them as different errors. Thread, process, or machine coordination in parallel execution.

You don't need unsafePerformIO for any of these. > Anything that needs rewriting a memory address without losing time by allocation and garbage collection. ST gives you mutable references. Or just use IO.

You need it for doing what the OP is talking about.

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

#110

Post by [deleted] »

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…

[deleted]
Post reply on HN