Hi, I’ve been working at Prezi for about a year now, I designed and currently develop the Elm Programming Language. So that is my primary focus right now, getting it ready for industrial users, fun users, everyone.
2. So let’s start right into it, what’s Elm?
Elm is a programming language for frontend programming and it really came out of a frustration with HTML and CSS and sort of grew into a full language for dealing with graphics dealing with interactivity in a better way, at a very high level, that is what it's all about. And it does this through using concepts from functional programming, using a concept called functional reactive programming to really make these things easy and simpler than they would be otherwise.
Werner: what is the leading paradigm in Elm, is it functional, it is functional reactive or why is it functional, let’s start out with that.
So it comes from this sort of background of Haskell inspiration or OCaml inspiration of ML-family languages where you have a statically typed functional language, so maps and folds and other elements of functional programming and I think of that sort of a separate entity from functional reactive programming. Functional reactive programming is a controversial term depending who you ask but the key part there is talking about events and talking about interactions and I see that as largely separate from whether it’s functional or imperative, there are lessons to be learned there that you can use in any language.
3. Does the functional nature lend itself well to sort frontend development?
So this is something that has been really exciting, so a lot of functional languages have a sort of struggled at the point when someone says: “So how do I use this?”, so that was something that really got me passionate about working on Elm, because I saw how you could start to do graphics with it and the key observation when it came to drawing things on screen was that there was a correspondence between HTML and CSS and functions, so you can think of a DOM node as an element, as a value and CSS as transformations of that, so functions that you apply to it, and when you start think of this way, you very quickly have a functional language, you are applying attributes to these things and you can compose them, you can have higher order versions of them, and so you get this very nice modularization that I think you are missing when you don’t have this kind of functional style for graphics.
Elm is a pure language, so immutability is a big concept there, in the same way it would be in Clojure, ClojureScript or in Scala to a certain extent, and so what’s going on there is many people sort of struggle with Haskell I think because it can be hard to deal with... state can be somewhat confusing in that setting when everything is pure and so what FRP, I found, really helps with, is making that very clear so the kind of state you want to carry, usually is dealt with by functional reactive programming and you don’t need to go into the strategies that are often used in other pure languages, though you can and in some cases it’s really valuable to do that, so I don’t want to say that one is bad, but in Elm you have two separate ways to deal with this and the primary one is functional reactive programming.
5. I don’t want to put words in your mouth but are you basically saying that monads suck?
I’m not saying that, I’m saying that they have a PR problem and so this is something that we talk a lot in the Elm community, is how do we sort of introduce these concepts without the sort of theoretical baggage and sort of like emotional baggage that comes with it right, like at this point in time some people hear the word “monad” and kind of check out and so, what we are trying to do on Elm is sort of present these ideas in a way that’s immediately accessible and you know: “Ok, that's what I use it for”. So one recently I’ve thinking about that in Elm is this idea of explicit effect, so rather than saying we do things monadically or whatever, instead you think of it as I model my effects as data, so I have this thing that I can run later and I pass that to the runtime to do something with.
And this is actually key to the Elm debugger which came out recently because rather than having an effect immediately, like in JavaScript you have these side effects, we go with explicit effects where it’s data, and what that means is the runtime can perform or not perform those actions and can do them in a way where you are more in control of the order things. And that to do things like explicit effects, the general pattern you use is monadic, but by the time you get to thinking about what the general pattern is, you’ve already been using it, when you frame it in this way, so something I think about a lot is how do we frame this in a way that is going to be accessible and it’s going to be nice for people to use, but still grounded in good theory that’s helpful and nice.
So what I mean is, so in Haskell when you use the IO Monad what you are really doing is saying: “I’m creating a data structure that says perform this and then there is a callback that I’ll do next and then perform that there is a callback that I’ll do next”. So when you actually create that in your Haskell code you don’t run it, it doesn’t run until you give it to main and the runtime says: “Thank you” and it goes through that data structure which you’ve built and does all the effects. And so when I say explicit effects I mean really modeling what you are going to do and then handing them off to the runtime to do that stuff. So in Elm that would be event based, so someone clicks something and you’ve build up an effect to perform and give that to the runtime. Does that kind of clarify, this is a new idea I’ve been playing with it, I don’t know if it’s fully formed yet, but …
Ok, so the sort of basic concept of functional reactive programming is the idea that some values change over time, so it’s not just that we have a value X or a value 4 that is always 4, it’s 4 forever, you have mouse position which as the mouse moves, the value of that changes, and from there FRP means a lot of different things. So in Elm how this works is it's all event based, so as the user does something that propagates through your program and updates the minimal pieces necessarily to get the result out. But so what is the reactive part, like I got to say naming is contentious in FRP and so no matter what version of FRP you are looking at, someone is going to tell you that is not really FRP.
So there is a concept of continuous, I’m not sure if I, this idea of values that changed over time I call that a signal, so it’s something that is changing, and so early on there was this distinction of we have continuous signals and we have discreet signals and Elm opts for they are always defined but they change discretely, so they can always be event driven.
And so there is controversy around that, there is controversy about sort of what is the role of FRP in general, so when you use FRP in Elm it is really a way to get a window into the world, so you can see the keyboard or see the mouse, it’s not about structuring code as much, it’s about “I want to look at the world and react to it” and in something like Reactive Extensions it’s more about “This is how I want to structure my code internally”, and the key distinction there is whether or not your FRP is monadic or not, so in Elm it is applicative and in Reactive Extensions, basically in any imperative version of reactive programming or functional reactive programming it’s going to be monadic, and the key distinction there is whether or not you can collapse signals together into one and whether or not you allow that has really big implications on how you end up writing code, the kinds of things you can and you can’t do, the kinds of problems you end up with.
And I’d say largely the functional part is sort of a historical part of it because it did come out of Haskell and a lot the research was in Haskell and in Racket and Scheme, and more recently you start to see this influence in imperative languages, so that is where the F comes from, but I don’t think it’s fundamental to the idea.
Werner: So it’s more about the reactive programming and the 'functional' is sort of incidental.
Well I think the word functional is important for different reasons, but yes, and I think the reason that came out of the functional background was because you do have more people who care about immutability, so when you’re in a setting where you say “Is this value forever?”, you have to think harder before you figure out how to model change over time. So one way to think of FRP is really as a way to say: “How can I introduce the minimal amount of power to be able to talk about how things change over time”. So one way to do it is just to have mutability, but that’s an extremely like permissive way to talk about change over time, because anyone, anywhere can change it at any moment and you will lose this locality, so it gives you the expressiveness but it gives you so much more that you start being hurt by it, so FRP kind of comes from that and I think that is kind of key to why it exists, but again it doesn’t mean that is not useful in an imperative language.
So this is part of why Elm is applicative rather than monadic, so part of how Elm is defined is such that you never get a cycle, and so when an event propagates through you have a guarantee that each node in your, I call it a signal graph, sort of how you update the screen, each node is only going to hear about it once, so you know that you are not going to get a loop back. And in a more permissive version you can make your own little self loop [that just loops]. But yes, so I’m not sure if that’s an issue in monadic FRP. I assume one could make that if they wanted but I’m not sure.
9. Elm lives in the browser, so it compiles to JavaScript?
Yes, so Elm early on I would say compiles to HTML, CSS and JavaScript, so the goal really is to find a better way to do GUI programming in general from graphics to computation. So it’s not just a drop-in replacement for JavaScript, it really aims to also cover how we think about graphics and interactions as well. That’s not that say you can’t just use the part that compiles JavaScript, so one thing that I’d like to focus on a bit more, no promises on timeline, is getting integrated with Node in such a way that you could write a parser in Elm let’s say, and then just use that code from JavaScript, so from that perspective, really just using it as a language for computation, but the goal is bigger than compile to JS language.
Werner: The goal is to write a full frontend essentially, it’s a one stop shop.
Well I don’t want to say one stop shop but the goal is to think about GUIs in a new way right, and to only address that computationally misses the fact that DOM or Canvas is not necessarily the right way to go about dealing with graphics and callbacks, aren’t necessarily the right way to be dealing with interaction, so not one stop shop but sort of vision of what GUI could be.
So that actually was done by a good friend of mine Prezi, and so we got this question when we announce that Elm and Prezi were joining forces, someone on Hacker News was like: “You can't debug it, there is no debugger, what’s the point?”, and so Laszlo really took this seriously and said not only what would a debugger look like but how can we knock this out of the park, what would be like the ideal debugger for this. So he drew inspiration from some of Bret Victor’s talk on sort of learning about programming, was the name of this post, about how you can visualize a program over time and so how you could rewind and change values and sort of see how that changes the progression of the program. And the reason that was, so this idea has been around for a long time, but for some reason it just doesn’t happened and what Laszlo figured out is that it hasn’t happened because you need to start with language design to get to a point where it’s tractable to even start approaching this problem.
So the way FRP and Elm is phrased it actually becomes very, very simple to keep track of events that have happened, so to store previous things in the world you just have to keep track of what the user did, and because you are in this pure setting where things are immutable, it’s very easy to rewind or replay because you are not sort of scrubbing through the stack or the heap and messing things up. So at the end of the day you are able to sort of have this, because FRP is in charge of controlling time and events, so the runtime is aware of anything that happens and keeps track of that easily. So the cool example, the fun example is seeing how Mario’s path changes, but the aim really is for sort of frontend developers doing more typical stuff where you have a menu that drops down that has a menu that drops down, that has a menu that drops down, and in that third menu there is a bug, and in your normal debugging workflow you set a breakpoint and you manually go through that, and it’s no, it’s still broken and then you change something you manually go through that, and so what the time traveling debugger is really about, is recording that sequence of events and being able to just replay it without manually saying “Go back through, go back through”.
Werner: So are there any restrictions in that debugger; I assume that any sort of I/O that goes beyond the user is problematic.
So this is why I mentioned explicit effects earlier, so because Elm is pure you are not getting any side effects as the program happens, so in a typical language you might make HTTP requests just arbitrary, so in going through time you may let’s say for example you are writing to a file right, so you open the file and then you start writing it and then [let's say] you are trashing that file, and so because you have this idea of explicit effects in Elm, you are building up that effect that you want to perform and giving it to the runtime. Now that means that it doesn’t get run until the runtime says: “Yes, I’d like to do that”, so when you go into the debug mode, the time travel mode, it essentially records that the first time through and does the action, but when you are going back it just says: “No, I’m not going to do that this time”. And so one question we got about how this works is like let’s say you want to read a file or make an HTTP request, so you are going to send out this effect request and that is going to come back as an input, the result of it. And so what is happening, is you record all the inputs so that just gets recorded, so as you go back through you see that same event each time because you’ve recorded all the inputs and when you get new effects out of the bottom, you just ignore them all because you are in debug mode, you don’t want repeat calls to the server.
Werner: So you drop the output of the events, but you know that incoming event... that is how you replay. Ok I see it.
And so that relies on key design choices that make it hard to replicate in other places, so the fact that you have purity or these explicit effects is vital. The fact that you have functional reactive programming specifically applicative functional reactive programming means that this is a lot easier to do, and so when you start saying: “Well I allow side effects sometimes” that is when you start scrubbing that file and messing things up or when you have the monadic FRP where you can change the structure of your graph, that is where it becomes hard to figure out where you should place values when you are going back and forth. So when I saw Laszlo present this, my reaction was “I didn’t know that was possible”, but it really did come from these sort of design choices that I didn’t, I wasn’t looking ahead and saying: “Yes, this is how you do time travel”, but yes, that’s been really cool to see how that has worked out.
So my full time role is to be working on the compiler, the tooling, the community around Elm and getting it ready to be an industrial-grade language. So Elm is still quite young, it was released the first time publicly in 2012, so for a language that is not a lot of time and so my goals really are how can we add the features, get the support of the community, get the learning resources out there where Elm in industry is a practical thing. And what’s been great about being at Prezi is that I have sort of institutional support, not just in terms of time to work on things but also people to ask about what’s going on so like I’ll be inspired by stuff Prezi is working on, so there is a recent release of Elm that makes it easy to embed in HTML and JavaScript, and that was inspired by some really cool ideas coming out of Prezi and there is always like I really get stuck on naming things so I’ll be like: “Ok, here is the regular expression library” and being in the Prezi offices I can always just ask: “Hey, is this a stupid name?” and they’ll respond: “Yes”, and it’s very quick to get that out of the way, so that’s been really great.
I know most of the community from the mailing list, that’s sort of the core of people who got everything started and those guys are from all over. So a lot of Europeans, a lot of people from the east coast, New York, Boston, San Francisco as well and we are now starting to try to do more events, so I’m trying to set more things up, juggling compiler stuff and all this, but we had a workshop here and had people from all over Europe come in and give talks which is really cool, with that is actually where Laszlo showed the debugger and it was just [very impressive]. But in terms of where they are coming and what kind of things they want to do, we do get a decent amount of people who are already familiar with Haskell or some sort of typed functional language, so certainly some sections of the users are people who want to program on the web but want to do it right, want to do it in a way that they feel good about, and what I’ve been focusing on at Prezi is sort of winning over the people who program web stuff everyday and that is increasingly becoming a voice in the Elm community of people who are saying: “I’ve built this, I’m using this and I have this question about such and such”. So I’d say growing into sort of broader acceptance in the web dev world, so within Prezi we are prototyping and sort of figuring out where it’s nice to use Elm and where it’s a really good fit and I think that the larger Elm community is focusing on the same kind of things picking problems that Elm is a really great fit for and I’m starting to hear more from people looking to hire Elm people, a little here and there which has been really cool.
I think the major things are going to be around libraries and tooling and community stuff, because when I think of sort of core language ]design choices like syntax, I don’t think there's a lot that I want to add, I don’t think that you know lambdas are just going to change. But in terms of the core FRP stuff I think that it’s pretty solid as well, I don’t foresee any big changes but there still are libraries that I think can be improved. So for instance the HTTP library I’d like to improve that one, but typically the kind of development in those libraries happens where we get some inspiration of like how to do this in a better way and we do an overhaul that is just one shot, so when you upgrade your version it’s typically not going to be like everything is broken now, there is some specific things that we’ve tried to address and make fundamentally better, so it’s not about like, it’s not a whimsical thing, it’s just we want to get a solid foundation and sometimes there I think there are still a few libraries that all have tweaks like that.
Werner: These are some of the projects that you are going to work on, I think other rendering support and things like that.
Yes, I got stuck on that point, so the kinds of things in terms of new stuff for the language, one thing we’d like to do is start to allow, perhaps like to do is, allow different rendering backends so React and Om have made a splash recently about sort of this diffing mechanism and Elm does diffing but sort of the realization that came out of talking with these guys is that lot’s of clever people are working on rendering, and there are a lot of different approaches to doing it and Elm shouldn’t force you into one approach like I personally like the approach Elm uses because I designed it, that is the one I wanted, but having a way to talk about HTML elements or do something in the style of Or or React or work with D3 or work with WebGL, these sort of backends should be available and I don’t want the compiler to be the bottleneck, I want people to be able to release that experiment and see what they come up with. And I think another thing will be sort of building larger and larger things, but yes, that is kind of the 2, 3, 4 month view of things.
14. We have a lot to look forward to, and so where can we go to check out Elm?
The main site is http://elm-lang.org/ and that is where you are going to have sort of all the examples, a lot of learning resources and links to community, so if you want to ask questions, Elm-discuss as a great place and hopefully the examples will get you from no knowledge to pretty solid understanding, but we work hard to make the resources friendly.
Werner: And we also have some of your talks on InfoQ obviously and this interview and we'll all look at Elm and thank you Evan!
Thank you!
Community comments