What Elm and Haskell are teaching mainstream JS [video](begriffs.com)

102 pointsby begriffs11 tahun yang lalu31 comments

What Elm and Haskell are teaching mainstream JS [video]

http://begriffs.com/posts/2015-11-30-functional-front-end-coding.html

31 comments

estebanrules11 tahun yang lalu

Elm is definitely a very interesting language. I would recommend the following if anyone is interested in seriously learning it:

https://pragmaticstudio.com/elm

danneu11 tahun yang lalu

And for Redux, the creator (Dan Abramov) recently released a bunch of tutorial videos for free on egghead.io:

https://egghead.io/lessons/javascript-redux-the-single-immut...

DarkTree11 tahun yang lalu

As a year-deep front end developer, I have recently taken a strong interest in functional programming principles and am trying to learn their use-cases.

Does anyone have ideas for small projects I can complete that will really drive home the importance/benefits of functional programming?

danneu11 tahun yang lalu

The main benefit of Elm and Redux is the simplicity of their core abstraction: that your app is just a reducing function over a stream of events from the outside world including game ticks, mouse clicks, <input> field changes, etc.

For example, a counter that increments per click:

    initApp = { counter: 0 };
    stepApp = (action, oldApp) => oldApp.counter + 1;
    viewApp = (app) => `<p>Clicks so far: ${app.counter}</p>`;

    currentApp = reduce(stepApp, initApp, mouseClicks);
    currentHtml = map(viewApp, currentApp);

This makes it really easy to inspect, test, and reason about what's actually happening and why since every change to your app had to be caused by an event that triggered a step from oldApp to newApp. Redux and I think Elm come with a debugger that even prints out `{action}, {oldState}, {newState}`. Makes it really easy to get a reading on things.

Though it's possibly hard to appreciate this until you've battled it out in the trenches with an abstraction that isn't so simple, especially on a large, complex app.

I personally found Redux (w/ React) immediately accessible and think it's a good place to start, especially if you're already coming from React or you want to reap the benefits without leaving Javascript. I'd feel really comfortable using Redux on any team project that was already using React and some other Flux'y implementation.

I've also been learning Elm this past week though it's taking me far longer to become productive since there are fewer resources and I have no ML experience. I've managed to create a simple Spreeder.com-style speed-reader (https://www.danneu.com/elm-speed-reader/), and if you look at the source code (https://github.com/danneu/elm-speed-reader/blob/master/Machi...), you can see that it's not much different from the counter-app example I pitched above where the `update` function reduces across a stream of actions including button clicks and the tick. (Disclaimer: I'm an Elm noob)

alphanumeric011 tahun yang lalu

I agree, this is one of Elm's main draws. PureScript has a library for this style of FRP (https://github.com/bodil/purescript-signal). From the documentation, Elm signals are like a process network (https://en.wikipedia.org/wiki/Kahn_process_networks).

In my experience I've been able to model any conceivable interactions with a website using this model.

eddd11 tahun yang lalu

Elm tutorial walks you through simple "mario bross" game. It is quite fun. http://elm-lang.org/examples/mario

1971genocide11 tahun yang lalu

Read "Learn you a good haskell" - and practice the exercises in that book.

It helped me a lot to understand the practical side of functional programming.

For a book that maximizes the utility of functional programming in your everyday life I would recommend "functional javascript" by the famous author of underscore.js

hepta11 tahun yang lalu

Curiously, the biggest benefits (of typed functional languages) for me are revealed with larger codebases or spiked code that I have to revisit some weeks later.

imakesnowflakes11 tahun yang lalu

> that will really drive home the importance/benefits of functional programming..

From my experience with Haskell, on a practical level, I think it really comes down to a guarantee that you will not be able to mess the code up beyond a certain extant.

I am not really sure if it should be attributed to the type system or to functional programming in general. A functional programming language require a really good type system, because you need it maintain sanity with you have to chain together functions a lot more than you do in an imperative language. So I think it has to be a mix of both.

coolsunglasses11 tahun yang lalu

Having done Clojure for a living before Haskell, it's the type system, explicit effects, laziness, overall good design, and FP. In that order.

But the "FP" part is only tangentially the point unless you take FP to mean "pure functional programming", ie, just a lambda calculus.

Having the ability to write "map" and "filter" in your programming language doesn't really do much for you in practice. Believing otherwise is why people thought FP users were nuts for a long time.

SpaceCadetJones11 tahun yang lalu

Not a project, but maybe check out the book JavaScript Allonge which I believe is free to read online

nine_k11 tahun yang lalu

Directly available as https://github.com/raganwald/javascript-allonge

crimsonalucard11 tahun yang lalu

http://www.purescript.org/

Worth mentioning when talking about this topic. Purescript is a Haskell like language that was designed for the frontend. I'm surprised as it seems like the presenter doesn't even know about purescript.

mikemcgowan11 tahun yang lalu

PureScript is mentioned on one of his slides.

VeejayRampay11 tahun yang lalu

Reading the site's description of the video, it's more like "how languages like Haskell and Elm are informing the design of Javascript libraries like Redux". So it's not so much Elm and Haskell TEACHING "mainstream" JS (whatever that is) but one library merely taking hints from other programming domains that are relevant to the particular use case it's trying to cover.

albemuth11 tahun yang lalu

On a podcast interview, the author of Redux mentions learning about Elm until later, so it's more like "some libraries have converged on similar design principles".

joshuacc11 tahun yang lalu

So, that's sort of true, but sort of not. Dan (author of Redux) has said that he read the Elm Architecture document before creating Redux, and didn't fully understand it. But he believes that it did influence the design of Redux.

> JAMISON: So had you played with or heard of ELM beforehand or did you just realize the parallels afterwards?

> DAN: Yeah. There's been this, I'm feeling guilty about it because I had this Twitter exchange with Evan. Evan was a bit uncomfortable with me not mentioning Elm as much as he thought I should. I felt that yeah, he's probably right because I read about Elm a few times before actually creating Redux. I'm not sure if… when you get inspired by something but don't fully understand it and later you kind of reproduce it but you don't really get this connection and you only get it later. So I think that's kind of what happened because I distinctly remember reading about ELM architecture but I was thrown out by the syntax, so I didn't fully understand what's going on there. Later after some initial iterations of Redux, Andrew Clark actually showed me how it's similar to Elm if we changed some things. We did change them.

> Yes, I have not actually played with Elm yet. I've seen other people playing with it. I've seen some demos but I have not actually played with it myself. I really want to but I'm stuck in maintaining and GitHub issues and I can't find the time. I don't know. Maybe I'm just afraid it's going to be so awesome that I'll just try the JavaScript development.

Source: https://devchat.tv/js-jabber/179-jsj-redux-and-react-with-da...

sedachv11 tahun yang lalu

Some developers are taking a really "creative" interpretation of the lessons of functional programming. I am currently dealing with a codebase (CoffeeScript) full of:

    _.reduce some_array, (result_array, object) ->
      ...
      result_array.push xyz
      ...
      return result_array
    , []

1515511 tahun yang lalu

In a lot of languages, stdlibs, what have you, map is implemented in terms of a reduce like this.

In a non-lazy language, this kind of a reduce is usually necessary when you want to omit an item efficiently from the resultant array - map does not offer a way to do this.

sedachv11 tahun yang lalu

Did you miss the explicit side-effects in the code above? This isn't like a map/filter in terms of fold, it is a very stupid way of writing a 'for' loop.

marrs11 tahun yang lalu

It's nice that JS devs are continuing to discover functional programming techniques, but it irks me a little that this is considered to be some sort of new development. JS has always attracted SICP-inspired programmers because of its strong resemblance to Scheme.

Doug Crockford popularised prototypical inheritance and function programming techniques in JS on his blog nearly 10 years ago.

KnockoutJS has been around for a similar amount of time and data flow was a big part of its design. React and Elm are evolutions of design that has been a part of front-end dev for a long time.

jahewson11 tahun yang lalu

First class functions are only one aspect of functional programming. Immutaility is a core feature which has only recently seen popular adoption in JS, with projects such as immutable.js. Out of the box JS doesn't offer the data structures necessary to code naturally in a Scheme-like manner.

Couple this with the new concept of Virtual DOM as pioneered in React and you get purely functional UI on the web, a radical departure from the status quo of just a few years ago. Defintely a new development for JS. Indeed, React Native suggests that this could be an important development for UI in general.

kyllo11 tahun yang lalu

Exactly. Vanilla JS (and JQuery and friends) have the semantics of mutating a tree (the DOM) in-place. A key differentiator of these functional libraries is the immutable data structure semantics.

rprospero11 tahun yang lalu

As a recovering schemer, I often heard how Javascript is very closely related to Scheme, but I've never really seen the resemblance. Granted, both languages possess:

* Dynamic Typing * Garbage Collection * First Class Functions

However, Python also meets those requirements. Now, looking at it from the Scheme perspective, Python is missing

* Tail Recursion * Macros * Continuations * Concise Language Spec

However, Javascript is also missing those same factors (though I might be wrong about the tail recursion). Yet, I rarely hear of Python described as an infix version of Scheme, yet I often hear that remark about Javascript.

I really want to like Javascript and I already do like Scheme, so I have a vested interest in seeing the connection, but I'm still missing something. What's the strong resemblance between Scheme and Javascript?

zipfle11 tahun yang lalu

JavaScript's scoping is much friendlier for creating closures than Python's:

    def why_is_scoping_hard():
        n = 4
        def print_n():
            print n
        def modify_n(new_value):
            n = new_value
            print n
        return [print_n, modify_n]

    >>> print_n, modify_n = why_is_scoping_hard()
    >>> print_n()
    4
    >>> modify_n(7)
    7
    >>> print_n()
    4

When you assign to a variable it is automatically created in the local scope, shadowing a variable with the same name from an outer scope. If you don't assign to it, you get the value from the outer scope. If you try to print it, but then assign to it later, the print call raises an error.

sophacles11 tahun yang lalu

Note - in python3 variable shadowing is much more controllable - in your example having modify_n look like:

    def modify_n(new_value):
       nonlocal n

(and of course the print x -> print(x) changes), will result in 4,7,7

thinkpad2011 tahun yang lalu

First-class functions (esp. anonymous functions) see relatively little use in python, due to the hobbled syntax. For example, you can't use `print` in a lambda, raise exceptions, or define any variables. In JavaScript, using an anonymous function is no different than any other function, and not surprisingly they are ubiquitous. I'd wager that this is the primary reason that JavaScript is compared to LISP so much more often than Python is. There's also the fact that JavaScript functions are all variadic, which also is similar to LISP. Also Python encourages OOP much more than JavaScript. So yeah the "look and feel" of python is quite a bit different from JS and from scheme as well.

davexunit11 tahun yang lalu

Lexical scope and first-class functions are about as far as the similarities go. JavaScript has nothing on Scheme.

agumonkey11 tahun yang lalu

Doesn't have to have anything `on`, simply coming from is enough.

numlocked11 tahun yang lalu

ECMAScript 6+ has tail call recursion optimization, but prior versions do not.

anentropic11 tahun yang lalu

maybe more an 'inspiration' than related in concrete ways...

Scheme gets mentioned re Javascript because: https://brendaneich.com/tag/history/