Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Functional Programming For The Rest of Us

defmacro.org

Post reply on HN
Print view View original

21–30 of 69 posts

Re: Functional Programming For The Rest of Us

#21

Post by calpaterson »

spacemanaki wrote: post #14
dustingetz wrote: post #10

i wrote this article off about when it makes incorrect comparisons between immutable values and final variables. someone who read it, is the rest of the article worth reading, or even accurate? there's certainly a need for articles like this, targetting an audience of java devs, if only they were correct. I haven't found much.

Yes, it's worth reading and it's basically accurate, although I'm not sure the accuracy is really as important as the general big picture, since there aren't that many examples. Is there something specific that you can point out where the article is actually incorrect ? There are only a few paragraphs in the beginning that mention final variables (and those only use Java primitives). I agree that there's a distinctio…

To be fair the the grandparent, the difference between immutable data structures and final variables in imperative languages is large and fundamental. If the author is (and I don't know, because I haven't read the article recently) making this analogy then it is going to be extremely confusing for some people.

Re: Functional Programming For The Rest of Us

#22

Post by ImprovedSilence »

rauljara wrote: post #9

Kudos to the piece for being well written, readable, and clear. But I'm worried about a "for the rest of us" that starts off with first Plato and then lambda calculus. The problem with "the rest of us" is that these concepts aren't inherently neat. Disclaimer: I'm not one of "rest of us". I'm learning Haskell, just because I enjoy having to think in a new way. A lot of FP explanations start off with immutability. Aft…

I think by "rest of us", he meant nerdy, curious programmers. And not academic PHD mathematicians.

I don't know your background, maybe you are deep in the academic world, but if not, it's likely you are the "rest of us" he is addressing.

Re: Functional Programming For The Rest of Us

#23

Post by evincarofautumn »

gtani wrote: post #18
chousuke wrote: post #7

Earlier quoted context omitted.

I think the "if it compiles, it works" has to do with Haskell's type system being much more expressive than most static languages, and that most of your code will be declarative and pure. Purity helps because your program will necessarily be composed of small, self-contained modules (usually functions) that have no implicit dependencies. The type system helps because you can encode a lot of the code's intent in type…

not the most powerful system imaginable for that purpose had to ask, what is more powerful, agda/coq/other?

A full dependent type system is nominally “the most powerful system imaginable”, but it’s also hopelessly problematic. You can’t be sure that type inference or type checking will halt in the general case, although you can infer some value-dependent types (see “Dependent Type Inference with Interpolants” by Unno & Kobayashi).

In practice this means you need manifest type signatures, otherwise the type of a function would be “lol iunno ¯\(°_o)/¯”. Then again, Haskell requires signatures in some cases, such as for Rank-N types, or when you run up against the Dread Monomorphism Restriction. So yeah, Agda and Coq are awesome, but most useful as what they’re designed to be—proof assistants—rather than general-purpose languages.

tl;dr: A constrained system such as Haskell’s, with extensions for aspects of dependent typing, is more practical than actual dependent typing.

Re: Functional Programming For The Rest of Us

#24

Post by spacemanaki »

calpaterson wrote: post #21
spacemanaki wrote: post #14

Earlier quoted context omitted.

Yes, it's worth reading and it's basically accurate, although I'm not sure the accuracy is really as important as the general big picture, since there aren't that many examples. Is there something specific that you can point out where the article is actually incorrect ? There are only a few paragraphs in the beginning that mention final variables (and those only use Java primitives). I agree that there's a distinctio…

To be fair the the grandparent, the difference between immutable data structures and final variables in imperative languages is large and fundamental. If the author is (and I don't know, because I haven't read the article recently) making this analogy then it is going to be extremely confusing for some people.

The article doesn't make this analogy, that was my point. It doesn't really delve into immutable data structures at all, and just discusses FP in broad strokes. This isn't really a bad thing, since I don't think it was meant to be a deeply technical article.

Re: Functional Programming For The Rest of Us

#25

Post by bmj »

fahad-sheikh wrote: post #13

I found this article very useful, and helpful in de-mystifying the world of functional programming. Are there other articles that cover functional programming theory in plain words like this?

I'll add an additional question to this one: are there any good sources of small, "real world" app examples available? I realize I could look at, say, the HN codebase, but I'm curious if there are smaller examples available, too.

Re: Functional Programming For The Rest of Us

#26

Post by evincarofautumn »

A great read. Just a couple of things that jumped out at me:

“In functional languages automatic analysis of functions and finding good candidates for concurrent execution is as trivial as automatic inlining!”

It isn’t exactly trivial. If you can evaluate anything concurrently, then you still have to figure out what’s worth the overhead of spinning up a thread to run concurrently. And many operations are inherently sequential even if they aren’t imperative or side-effectful—parsing, for example. Still, the gist is that concurrency is easiest in a pure language and a functional style, and I have no bones to pick with that.

“…infinite data structures, something that's much more complicated in a strict language.”

Infinite structures are still pretty easy to construct in strict languages. For example, you can use ranges of the sort in D’s std.range library, as described in Alexandrescu’s “Iterators Must Go!” talk.

Re: Functional Programming For The Rest of Us

#27

Post by sharmajai »

tomp wrote: post #16
rauljara wrote: post #9

Kudos to the piece for being well written, readable, and clear. But I'm worried about a "for the rest of us" that starts off with first Plato and then lambda calculus. The problem with "the rest of us" is that these concepts aren't inherently neat. Disclaimer: I'm not one of "rest of us". I'm learning Haskell, just because I enjoy having to think in a new way. A lot of FP explanations start off with immutability. Aft…

This article is another one of those that confuses functional programming with pure programming (which is, I believe, by definition also functional). You can do a lot of functional programming in a language where values are mutable. I use it all the time in python: the map and filter functions, list comprehensions, zip, ... For me, functional programming means having first-class functions that can be passed to/from o…

You can do a lot of functional programming in a language where values are mutable.

Sure you can do whatever you want, but if the language does not support things like tail call optimization, non-imperative function definition, writing code in functional style turns out to be a lot slower (due to non-tail-optimized function call overhead) and less safe (due to potential side effects in function definition) than if you are writing it in a functional language with explicit support for these facilities.

Re: Functional Programming For The Rest of Us

#28

Post by jiggy2011 »

Good article , cleared a few things up for me.

One thing I am still a bit hazy on though. He mentions that continuations could be used in the context of a web app to maintain state between HTTP requests.

I'm not quite clear how this would actually work. Lets say you have something like this (in psuedocode):

Let's say we have a counter we want to increment on each request.

doHTTPRequest(requestVars)

{

  renderPage(requestVars)
  pause()

  return requestVars + 1
}

doHTTPRequest(doHTTPRequest)

Is that approximately how this works?

In which case, how would it work for doing more than 2 requests in a row?

Re: Functional Programming For The Rest of Us

#29

Post by JadeNB »

sharmajai wrote: post #27
tomp wrote: post #16

Earlier quoted context omitted.

This article is another one of those that confuses functional programming with pure programming (which is, I believe, by definition also functional). You can do a lot of functional programming in a language where values are mutable. I use it all the time in python: the map and filter functions, list comprehensions, zip, ... For me, functional programming means having first-class functions that can be passed to/from o…

You can do a lot of functional programming in a language where values are mutable. Sure you can do whatever you want, but if the language does not support things like tail call optimization, non-imperative function definition, writing code in functional style turns out to be a lot slower (due to non-tail-optimized function call overhead) and less safe (due to potential side effects in function definition) than if you…

That's true, but this functionality is perfectly compatible with mutability.

Various flavours of Lisp have been in the forefront (CMA: among 'popular' languages) in making this functionality available, but I don't know of any (CMA: 'popular') pure flavour of Lisp. (Maybe Clojure --but its preference for 'immutable by default' is quite different from not having mutable values at all!)

Re: Functional Programming For The Rest of Us

#30

Post by Periodic »

jiggy2011 wrote: post #28

Good article , cleared a few things up for me. One thing I am still a bit hazy on though. He mentions that continuations could be used in the context of a web app to maintain state between HTTP requests. I'm not quite clear how this would actually work. Lets say you have something like this (in psuedocode): Let's say we have a counter we want to increment on each request. doHTTPRequest(requestVars) { renderPage(reque…

Node.js is built around a lot of continuations, if I recall. It's very common in event driven computing.

I believe the basic way to do it is that the function that processes the original request both returns the output and the continuation, then the next time the user connects it would use the continuation instead of the original function.

    function doHTTPRequest(requestVars, renderPage)
    {
         (content, renderNextPage) = renderPage(requestVars);

        return (content, function (newRequestVars) {
            renderNextPage(newRequestVars);
        });
    }
It's a little awkward, and maybe not the best example of CPS. But basically what happens is the request gets handled and returns the output and something to do next. Then you return your output and some additional computation that will get executed later, in this case a function that renders a different page. This is computation that hasn't been evaluated, but which can be passed around to evaluate later. Note that this whole function could be replaced by renderPage, but I wanted to make things more explicit. A good language would let you write

    doHTTPRequest = renderPage;
Also, when your config would probably specify that it should call renderPage and so that function would get passed around or held by your controller/dispatcher until the actual doHTTPRequest is called.
Post reply on HN