Live data from Hacker News

Functional Programming using JavaScript

scott.sauyet.com

71–80 of 88 posts

Re: Functional Programming using JavaScript

#71
post #12

For those you want to learn the functional programming I'd suggest to immedeately commence looking at Ocaml/Haskell instead to see the real big picture. Because it's of course adorable that you can write map and compose in JS (it's 2014, it can do it everywhere), but FP = many more serious things.

I've been wondering lately, if we skip performance as a consideration (for example lazy evaluation), what is the difference between functional programming and imperative programming without globals, pointers, mutable variables or shared memory? In other words, would an imperative language without side effects (that could do static code analysis) be any different in practice than FP? I'm very serious about this, becau…

Consider one particular case, where we need to read in a gig of data (made of many records), filter out some records, compute some stream of transformed versions of those records, and then write out the rolling average.

This actually sounds pretty nice to write as a shell pipeline (and that's a really good way to do it), but really, it's likely that you'd end up writing some code like

    main() {
      q = queue(5);
      avg = 0;
      while(!eof) {
        r, eof = get_record();
        t = transform(r);
        if(q.size() >= 5){
           avg -= q.pop();
        }
        avg += t;
        q.push(t);
        print  avg/q.size();
      }
    }
or something, but it'd actually be annoying to extract out the logic for handling the rolling average and split it out from the looping code, at least if you want to maintain constant memory use, and if you had to do something similar in a few places, you'd end up duplicating code.

I claim that it's possible to factor that code nicely out in Haskell, and still get the compiler to generate the same machine code as the C loop. This doesn't particularly use first class functions, and more relies on the combo of sufficiently smart compiler and sufficiently strong guarantees about what code will do.

I also take slight offense at calling C-style languages "plain old algebraic style", since it'd be really strange in algebra to say both x=5 and x=6. I would not hesitate to call FP languages where you can substitute equals for equals and such the algebraic languages.

Re: Functional Programming using JavaScript

#72
post #70

Earlier quoted context omitted.

I've been wondering lately, if we skip performance as a consideration (for example lazy evaluation), what is the difference between functional programming and imperative programming without globals, pointers, mutable variables or shared memory? In other words, would an imperative language without side effects (that could do static code analysis) be any different in practice than FP? I'm very serious about this, becau…

Pure FP is very different from imperative languages because it has no notion of temporal order. You can (in truly pure FP) evaluate things in whatever order you choose and stop as soon as you're satisfied. The language cannot care at all [0]. That said, FP often involves the introduction of monads which restore sequencing (along with many other beneficial effects). A monadic FP computation is very similar to a plain…

Thank you, I hadn't considered that FP can evaluate in arbitrary order or simultaneously. That makes sense, because if there are no dependencies between code paths (so no side effects) then there's no reason they can't be executed at the same time. They didn't mention that back in the Scheme course I took in college, and I think something vitally important was lost on us (although in fairness they did emphasize that the code was evaluated, not run sequentially).

Seeing how monads reintroduce temporal dependence is also an astounding insight, and I can't believe that I've never seen them described that way. That means that the monad has more in common with, say, the mutex, than it does with I/O. I've always tried to approach them with metaphors like sockets and utterly failed to grok anything for more than a couple of days.

I'm thinking that if Haskell is an "impure" functional language, then I would like to see a "pure" imperative language. I envision it as similar to Go but multithreaded and basically every function in the language would be its own process, communicating with sockets (so basically a shell with C-style syntax). The overhead could be largely eliminated with a stackless context switcher. It wouldn't be able to achieve the optimization of FP but it might be more approachable to the mainstream and by extension maybe iterate faster and lead to higher productivity. I’d like to see it take the place of OpenCL/CUDA and SIMD because I find them tedious compared to more elegant languages like MATLAB/Octave.

Re: Functional Programming using JavaScript

#73
post #70

Earlier quoted context omitted.

Pure FP is very different from imperative languages because it has no notion of temporal order. You can (in truly pure FP) evaluate things in whatever order you choose and stop as soon as you're satisfied. The language cannot care at all [0]. That said, FP often involves the introduction of monads which restore sequencing (along with many other beneficial effects). A monadic FP computation is very similar to a plain…

Thank you, I hadn't considered that FP can evaluate in arbitrary order or simultaneously. That makes sense, because if there are no dependencies between code paths (so no side effects) then there's no reason they can't be executed at the same time. They didn't mention that back in the Scheme course I took in college, and I think something vitally important was lost on us (although in fairness they did emphasize that…

I'd suggest taking a look at Coq if you want something more pure than Haskell. I'll warn you that this comes with some degree of added sophistication! Coq is not just a programming language but instead a proof system which can be used to verify programs as correct (not just unit tested) and then extract the skeletal, underlying program as OCaml, Haskell, or Scheme code.

http://adam.chlipala.net/cpdt/

True purity actually doesn't look much like Go at all. Instead, it means that every expression literally can be evaluated and replaced with its value in a completely arbitrary order. This massively simplifies the meaning of a language and opens it up to bear much more structure (such as that of a mathematical proof).

Re: Functional Programming using JavaScript

#74
post #12

For those you want to learn the functional programming I'd suggest to immedeately commence looking at Ocaml/Haskell instead to see the real big picture. Because it's of course adorable that you can write map and compose in JS (it's 2014, it can do it everywhere), but FP = many more serious things.

I've been wondering lately, if we skip performance as a consideration (for example lazy evaluation), what is the difference between functional programming and imperative programming without globals, pointers, mutable variables or shared memory? In other words, would an imperative language without side effects (that could do static code analysis) be any different in practice than FP? I'm very serious about this, becau…

> I'm beginning to feel that the real advantages of FP are being obfuscated by unusual syntax.

Or that unusual syntax is precisely motivated by trying to seamlessly and naturally express FP code.

Either that or they were just being intentionally obtuse... come on, man. Which sounds more likely of these two? I'd personally never want to program in a language with the semantics of Haskell, and the syntax of a C-like language.

> With better references and immutable variables, we should be able to split calculations up over several lines and have the compiler figure out how to optimize it into basically FP code.

Or just dive the code up into whatever temporary and intermediate steps that you need with let-in expressions and where-declarations? I mean, why not? If what you want the compiler to process is FP code, then just divide it up like you would divide up FP code. FP /= one liners.

Re: Functional Programming using JavaScript

#75
post #70

Earlier quoted context omitted.

I've been wondering lately, if we skip performance as a consideration (for example lazy evaluation), what is the difference between functional programming and imperative programming without globals, pointers, mutable variables or shared memory? In other words, would an imperative language without side effects (that could do static code analysis) be any different in practice than FP? I'm very serious about this, becau…

Pure FP is very different from imperative languages because it has no notion of temporal order. You can (in truly pure FP) evaluate things in whatever order you choose and stop as soon as you're satisfied. The language cannot care at all [0]. That said, FP often involves the introduction of monads which restore sequencing (along with many other beneficial effects). A monadic FP computation is very similar to a plain…

Idris is Turing Complete. Total functions are opt-in.

Re: Functional Programming using JavaScript

#76
post #36

Earlier quoted context omitted.

Strong agreement. "Adorable" is exactly how I describe it. Even if it's already producing practical advantage in Javascript, it's mostly a cute toy given how it stacks up against "normal" usage. Learn Haskell/OCaml and you'll see how to really take this kind of reasoning many, many orders of magnitude upward. Learn Coq/Agda to see yet another meteoric jump.

While I'm not upset that this has been posted here and has been garnering some attention, this talk wasn't designed for this kind of consumption. I have given this talk to two kinds of audiences: * In a large corporate office with heterogeneous skill-sets among developers, but where almost all had some experience with Javascript. * Javascript Users Groups In each case, the idea was to make the case that FP could offe…

For that audience I agree with dipping toes. I just want to place hedges and guards against making "FP" (whatever that means) out to being better syntax for some kinds of streaming operations when it has much, much more to offer.

Re: Functional Programming using JavaScript

#77
post #75
post #70

Earlier quoted context omitted.

Pure FP is very different from imperative languages because it has no notion of temporal order. You can (in truly pure FP) evaluate things in whatever order you choose and stop as soon as you're satisfied. The language cannot care at all [0]. That said, FP often involves the introduction of monads which restore sequencing (along with many other beneficial effects). A monadic FP computation is very similar to a plain…

Idris is Turing Complete. Total functions are opt-in.

Idris' opt-in totality is a weird beast since those opts are extralinguistic. I really consider it to be a downside when a language is turing complete these days—I'd rather Idris just use a partiality monad.

So, maybe I'm just using the power of wishful thinking with my characterization above.

Re: Functional Programming using JavaScript

#79

Earlier quoted context omitted.

For JS people wanting to learn FP, I'd recommend Allonge first. For FP people wanting to see how they can use JS in and FP manner, Fogus' Functional Javascript is a good book, and it's not a bad second book for the JS crowd.

I'm curious what you think about Clojurescript? leaving aside that it may be harder for teams to move to Clojurescript than to improve their JS codebase. The reason for the question is that Clojurescript supports all the FP idioms of your slides more naturally and also has more FP features.

I've just started learning Clojure, and I haven't spent any time yet on Clojurescript.

Re: Functional Programming using JavaScript

#80

Intrestingly it seems that the functional version he proposed is much faster than the OO version. http://jsperf.com/oop-vs-ramda

Fixed for actually running the tests instead of just parsing:

http://jsperf.com/oop-vs-ramda/3

TL;DR: Ramda is somewhat faster than OO one

Post reply on HN