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

41–50 of 145 posts

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

#41

Post by the_af »

Lewton wrote: post #15
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…

That's one of the reasons I loved the "programming languages" course on coursera[0]. The course went through 3 languages, ML, Racket and Ruby giving 2 weeks to each language. And then spent time contrasting the weaknesses and strengths of the different languages and their paradigms. [0] https://www.coursera.org/learn/programming-languages (Starts up again on the 9th of January :) )

Seconded! Programming Languages is wonderful. Easily the best I've taken in Coursera (and better than Odersky's courses).

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

#42

Post by adwn »

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…

> when the C programmer has written the first working version, the FP programmer has tried 5 different solutions.

... none of which are necessarily faster than the other 4 solutions. It's not just the architecture of your code that influences performance, it's also – sometimes even more so – the underlying details of your implementation, like arrays vs. pointer-based data structures; Athas' comment describes this pretty well.

As a consequence, this statement:

> it is always a property of the architecture or system, not of the programming language

is wrong, simply because your programming language will heavily influence a lot of your productivity vs. performance tradeoffs.

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

#44

Post by mgr86 »

inputcoffee wrote: post #43

Does someone have a better scanned version of this? The format is not great on this, but it looks really interesting.

I am not sure if this is better. But here is a scanned copy of the original journal article. I put it on google drive. Do you have a preferred PDF host?

https://drive.google.com/file/d/0B8_iX4Icv1BmQkh3TWtqTXY5ajQ...

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

#45

Post by inputcoffee »

mgr86 wrote: post #44
inputcoffee wrote: post #43

Does someone have a better scanned version of this? The format is not great on this, but it looks really interesting.

I am not sure if this is better . But here is a scanned copy of the original journal article. I put it on google drive. Do you have a preferred PDF host? https://drive.google.com/file/d/0B8_iX4Icv1BmQkh3TWtqTXY5ajQ...

Thank you, this does read better (thicker font, better resolution) on my screen.

I was fine with the post-script but for some reason it seemed thin and there was a slight blur.

I just use my browser to read the PDF (usually chrome, sometimes Firefox or IE or even Opera).

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

#46

Post by KirinDave »

cousin_it wrote: post #17

The top link on /r/haskell right now [1] is someone complaining that their program runs out of space due to a subtle interaction between laziness and IO. I think it's safe to say that we have tried laziness as the default and have learned that it's the wrong default, because it plays havoc with space and with IO. [1] https://www.reddit.com/r/haskell/comments/5h6emf/haskell_run...

I'm not sure why we keep pretending Haskell is supposed to work well. It's half prorgramming environment, half research environment. This shows in MANY ways. And don't get me wrong, the Haskell team tries, but ...

There really isn't a serious attempt to build an industry-friendly programming language with functional features and laziness as a default. You'd make many different decisions than Haskell:

- No more language extensions, you'd fix the feature set.

- Better transparency on memory growth and GCs in tooling

- It'd be easier not to generate a ton of garbage, so the GC could be designed such that very large working sets could be handled with low latency.

- You wouldn't structure IO the way the have. Modern programs have demands for many, many side effects and threading an IO monad through every place they can touch is common practice, but not useful. A reduced power version of IO that would let developers push events to an IO-enabled functional reactor would be in the stdlib.

- Monad Transformers would almost certainly not be included, preferring: http://lambda-the-ultimate.org/node/4786

We shouldn't hold Haskell as the perfect expression of functional and lazy programming. It was never meant to be and it shows. It's just the tool we have right now to go to bat with.

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

#47

Post by KirinDave »

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…

> In order to be able to use a programming language or paradigm well, it is especially useful to know what its weaknesses are. Functional programming does not work well in programs which handle a lot of states. It does not work well in programs which have high requirements for performance or memory. It does not work well for programs which have to do low-level stuff.

By the same token, whenever this conversation comes up a series of vague and poorly-formed criticisms come up saying, "You can't do low level things" without defining what on earth that means. Or, perhaps worse, conflating the idea that you must have Haskell in all its massive (and perhaps fairly: a bit bloated) confusion of ideas. People can and do write high performance code in functional style and with functional tools. People even do it with laziness as a core abstraction.

The main gate to functional languages participating in, say, the Linux kernel is NOT that they are "too slow" or that "laziness makes them too confusing". It's that the Linux kernel is written entirely around the unique weirdness and expectations of C, and only languages based on or descendant to C do well there.

It's difficult to treat the core question, "What are the disadvantages of functional programming" in the same way that it's difficult to answer, "What are the weaknesses of OO programming." Both use terms that encompass a very wide variety of approaches and decisions, but the way we evaluate them as bottom-up, on a case-by case language for each individual language.

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

#48

Post by lmm »

executesorder66 wrote: post #16
lmm wrote: post #12

Earlier quoted context omitted.

Konqueror supports it in the sense that it will embed the appropriate KPart, just as it would for e.g. PDF. How "native" you consider that is an open question.

Thanks. By native I meant it renders without plugins or any configuration by the user, on a default install of the browser.

The line between plugin and not is pretty blurry for Konqueror - even its HTML renderer is a plugin in a sense.

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

#49

Post by michaelfeathers »

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…

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.

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

#50

Post by gengstrand »

bad_user wrote: post #40
Athas wrote: post #35

Earlier quoted context omitted.

> As for performance and memory usage: it is always a property of the architecture or system, not of the programming language. Dropping to a low-level language, such as C, usually doesn't buy you too much these days. What is more important is that most C compilers in use have vastly more time invested into optimizing routines than the typical FP compiler. Apart from that, you can easily mange the same kind of data in…

And it's not just about linked lists vs arrays, but also about the actual call stack. FP code tends to be heavy on recursive algorithms, which means you need mutually tail recursive functions. And laziness. Somebody mentioned the State monad and the IO type. Well, these are lazy abstractions with a memory-safe bind/flatMap operation that makes them tick. Well, the problem with these abstractions is that they'll requi…

It appears that your claim "Scala or Clojure that don't have real tail recursion because of the JVM" is in error.

http://stackoverflow.com/questions/1677419/does-scala-suppor...

http://clojure.org/reference/special_forms#recur

Post reply on HN