Live data from Hacker News

Functional Programming using JavaScript

scott.sauyet.com

61–70 of 88 posts

Re: Functional Programming using JavaScript

#61
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.

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

Or you know, stick to JS, because it's of course adorable that you can do functional programming in a functional language (we could do that since the 60s), but having access to the most prevalent language in the web and being employable is even better.

Re: Functional Programming using JavaScript

#62

finally, a slide deck that uses `history.replaceState` instead of `history.pushState`. no more having to hit "back" 90 times to exit the deck. how the latter ever became a pattern is beyond me. [EDIT] it probably became a pattern because of browsers that didnt implement the history API, so all hashchange events were pushed onto the history stack.

Making each slide its own navigation event isn't bad, the problem is that browsers somehow still don't let you jump back to the previous website, not sub-page.

What are you defining as a website? A domain? If I have a:

* myname.com/about.html

* myname.com/projects.html

Would you want to jump out of myname.com entirely when you press back? If not, how do you differentiate that from slides with myname.com/slide1, myname.com/slide2?

Re: Functional Programming using JavaScript

#63
post #58

Earlier quoted context omitted.

I hate to be this guy, but learning FP techniques that aren't available in my day to day language isn't terribly exciting. I want to see a short term benefit, so JS or Java focused articles and books are golden for me.

The issue is that if you're going to be doing FP, you'll want to use a language in which it's not just possible , but natural and happens without an uphill battle. Similarly, if you're just trying to learn the concepts, you're going to have a lot of noise distracting you if you use a language like JS, etc in which FP concepts are quite unnatural to express.

>The issue is that if you're going to be doing FP, you'll want to use a language in which it's not just possible, but natural and happens without an uphill battle.

Most FP paradigms are natural and quite easy in JS.

And learning Haskell can also be described as an "uphill battle".

Re: Functional Programming using JavaScript

#64
post #6

Earlier quoted context omitted.

It's a fantastic book for getting your mind used to the functional way of thinking. I'd also recommend JavaScript Allonge on the same topic. https://leanpub.com/javascript-allonge

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.

Re: Functional Programming using JavaScript

#65

Earlier quoted context omitted.

Making each slide its own navigation event isn't bad, the problem is that browsers somehow still don't let you jump back to the previous website, not sub-page.

how do you imagine this would work?

Collapsing entries on the same page in the back button right-click menu.

Re: Functional Programming using JavaScript

#66
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.

While I love and use Haskell a lot I would recommend Purescript [0] over Haskell or Ocaml.

Even if the only reason (hint: it's not) were that Purescript uses familiar tooling such as NPM, node, CommonJS modules, bower, etc and would allow users to focus on learning functional programming faster.

For those that wasn't more than the examples, there is the wonderfully comprehensive, practical, and just plain fun Purescript book[1].

0: http://www.purescript.org/

1: https://leanpub.com/purescript/read

Re: Functional Programming using JavaScript

#67
post #63

Earlier quoted context omitted.

The issue is that if you're going to be doing FP, you'll want to use a language in which it's not just possible , but natural and happens without an uphill battle. Similarly, if you're just trying to learn the concepts, you're going to have a lot of noise distracting you if you use a language like JS, etc in which FP concepts are quite unnatural to express.

> The issue is that if you're going to be doing FP, you'll want to use a language in which it's not just possible, but natural and happens without an uphill battle. Most FP paradigms are natural and quite easy in JS. And learning Haskell can also be described as an "uphill battle".

I think he was referring to Java

Re: Functional Programming using JavaScript

#69
post #20

I dislike these expositions on the "differences" between object-oriented and functional programming. The two concepts are not directly commensurable, and one can have objects with referentially transparent methods, to be used in a declarative style.

Agreed. Everything about this slideshow seemed like the author was slightly off the mark about what functional programming is and why it's useful.

Re: Functional Programming using JavaScript

#70
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…

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 imperative computation... just with all of the arbitrary details automatically selected to be coherent and optimal.

You can even pretty easily embed OO in FP languages (though it gets a little hairy sometimes) since as soon as you can simulate open recursion somehow you can get late-binding as you like. See Oleg's O'Haskell papers for this kind of nonsense.

[0] In this regard, even Haskell is impure since it allows for non-terminating computation which can be seen as an impurity since you cannot expect to just evaluate `let x = x in x` repeatedly and get anywhere meaningful. Other languages like Coq, Agda, Idris are terminating (thus not Turing Complete) and therefore truly pure.

Post reply on HN