elm: A delightful language for reliable webapps
CC Attribution 3.0 Germany:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Chapelle, Godefroid
The talk will present the Elm language and ecosystem. Elm is a strongly typed, immutable, functional language that compiles to Javascript. It does compete with modern JS frameworks to build client-side UI.
 So this is a talk about Elm, as the title says. And no, it's the moment where it breaks. I've exercised five times. Okay, so maybe that's where we'll do it. Okay, cool. So what does day say about it? When I mean day, it's mainly the creator. So as you can read, the delightful language for reliable web apps, generate JavaScripts with great performance and no runtime exceptions. And that's maybe a very important part. I think the wording is pretty delightful as well. And this is a recurring theme in the Elm communities using nice language towards each other. Why did I look at Elm? Actually, it started among the Plone community. I heard the men and rock that have been using for nicks for a long time, and speaking of functional again and again, then I saw this Elm functional stuff pop up somewhere on my radar, and I was okay, that must be interesting, but functional. Ooh, that's so frightening, I won't look at it. And then again, the men and I think it was the men in that time. He mentioned that he was using it, and I thought, okay, this is now a sign that I should look deeper. Then there's some relationship with the Zoop community as well. The main sponsor today of Elm is a company called Norriding that has the same type of relationship to the language as Zoop Corporation, Digital Creation's head with Python a long time ago. They host the Elm creator, and they pay him full-time or half-time, or I don't know what to develop the language. And I thought, hmm, that's another hint. That's again interesting. Then I watched some more talks and got more interested and found out that they actually have also a BDFL, and where the B part is the most important. Even Kamklassak, sorry, his name is hard to pronounce, Saplinsky, he insists a lot about empathy, and what he means by this is empathy at all levels, empathy for the users, empathy for the developers, empathy towards the creator of the language as well, and so the B part is very important. And in another talk was mentioned, okay, we have with the Elm the same Python paradox that was mentioned by Paul Graham a long time ago, if you remember. A famous blog post where he explained that the Python developers were actually interesting people because they had looked out of the box and that it was a good advice to just go to Python 15 years ago to get people that look out of the box. And they were mentioning the same, that since they had published the fact that they were using Elm, they had so many people that would apply for jobs because there are a lot of people that would like to use Elm in a job, but could not. And so all those stuffs lined up and I thought, okay, I really need this time I have to look at it. My name is Godfra, you can find me on GitHub and on Twitter. Goals of that talk. I will try to explain things that are not that obvious. I'll do my best. I will explain all some things of Elm. There are so pitfalls, there are no silver bullets as we all know. Most of us have gray hair, so we don't need to be convinced anymore. And you'll get some reference later, for later. I will try to avoid to get into very detailed syntax to try to start to speak of functional programming concepts like monowheats and occurring and whatever, that's not the goal at all. And actually it's supposedly useless in Elm. The goal is to avoid all that jargon. Very few codes, at least so that I'll show some so that you can have a vague idea of the syntax, but not much more. So what is Elm? And then let's see some codes. Explain the Elm architecture quite deeply because that's the interesting part in my opinion. And go quite quickly about all some things very quickly, how I use Elm at work, caveats. Let's go. So what is Elm? Functional language, as I already mentioned. Very important, it's statically typed, which means that it has nothing to do with the current pattern or JavaScripts, the compiler will hold your back. And it has type inference, in other words, we don't have to annotate for typing everywhere. Obviously it's recommended for documentation, but there are a lot of places where you can avoid it. I click too quickly. All data is immutable. That's very important. The more I've been in IT, the more I've become wary of mutable state. I think build out was the stuff that taught me first, that being able to get rid of a clone installation, check out build out again, run everything and start from scratch. In other words, without any state was so good. And from that I understood more and more why we don't want data to change under our feet. And stop me if anything, if I'm speaking too quickly. All functions are pure. No side effects. So this is really important when you have inputs, whatever inputs you have, the outputs are guaranteed to be always the same. We all know that if we have a method that's calling a web service, we might have an issue there. The data that might come back might not be the same. That's what a monitor stuff, something that could be called a web side effect. And in Elm, we don't have null undefined or exceptions, which could be pretty hard to manage in JavaScript as we all know. Let's compare JavaScript in Elm because Elm is a functional language that compiles to JavaScript, which is something very important that I forgot to mention. So if we are in JavaScript, we have, I don't know how many tools to use, NPM for packages, Webpack to assemble the application, React for the nice uniflow of data, Redux to keep your state inside, and then TypeScript flow, whatever. I don't want to know actually. Any in Elm? Okay, thank you. Everything is built in, so one tool, you got it all. And by the way, if it's not clear, if you use JavaScript, you will need to take care of the dependencies of all those tools and be hopeful that they work together properly. So just for the people that are still a bit skeptical, I guess that some of you know that Redux took some of its ideas actually from Elm from its model of unidirectional flow view update model. Short side notes. When we speak of functional, and I said we want a statically type, we want stuff that's unbreakable. And what do I mean by unbreakable? This is something we all know. We have seen, I don't know how many times, and this is obviously broken. This is questionable, but at least it's not broken. The business analyst and the developer should speak to avoid this type of mistakes, but at least it's not broken. And it could actually be something that's desired, if you're describing, I don't know, which painting or I don't know. Functional style. So JavaScript and Python praise themselves to have some functional constructs and show you could use them. Like we used to say, I can do object oriented style in C. And yes, you can. We all know what happened. First, you have compromises, and second, under loads and under stress, the developer immediately stops the good practices, and so we lose the discipline and the functional programming practices in JS. When you have a functional language, actually the compiler won't let you do something else, which is quite nice. Okay, let's go. I will show you a very, very basic plus minus counter. So first, Elm is modular like we have in Python, like we really like. And as you can see, it can also declare what it exposes. Can import from other modules. And then here are the four types, four things, let's say this way that we need to describe when we do an Elm application. In this case, it's a counter, so let's use an integer as my model, and the initial value will be zero. Then what can I do with this application? I can increment or decrement and see how nice this sort of typing is because this will be covered. Those increment and decrement are actually types, and they are validated by the compiler. Then when I get one of those messages, what should I do? This is very, very complex. And finally, some of you that will use the model to display, to turn into HTML, and where you can declare which messages will be sent. And outside, the fact that you need to get used to the syntax, I think that people that have done HTML should be quite at ease with this syntax. Finally, I'm initializing the program, beginner program in this case, no side effects at all. With the, and there's a mistake here in the slide, model should be equal to init model and not model. Model equals init model, view equal view, update equal update. And that's all I need to give to Elm to make it work. We have defined a model, we have defined messages, and we wrote two functions, update and view. Let's hope that this switch will work. And imagine this is crazy. Thank you for your applause. So, again, stuff that's not showing up here. As I said, an initial state is passed to the program. The view, how to turn the state into HTML, into a UI. And update, which is the function that knows how to react, I said it, to messages. View takes a model in, it's a function, it's a pure function. It spits out HTML, actually a description of HTML that the Elm runtime will manage. New HTML, it's always, because data is immutable, we are not fiddling ourselves with an existing model. This is HTML that is pure new values. And that's it. So that's quite easy to understand, in my opinion. Update. And we get the message, because this is the hint that will come from the runtime, and we get the model. Based on the message and the model, we get a new model. Once again, this is, the old data are immutable, so this is a copy. It's not the same model that we are fiddling with. Let's try to show this with a bit more detail. So, let's say that I clicked in the browser, the browser emits an event. That's taken care of by the Elm runtime. And it will sense, and actually not send, it will call update function with the message that was fired, and the model. Update will return the new model. New model, I insist. And then the runtime passes the model to the view function, the function that we defined. And the view function can then define which order HTML will look, and which messages should be wired in, let's say this way. And then again, the Elm runtime will turn that into DOM. So we never touch DOM ourselves. And obviously, they have a virtual DOM like React, like Angular, and so on. And maybe something less obvious is that because the language is totally controlled, the virtual DOM can be much more optimized because they control the data in data out, which means that they can really choose the best constructs in JS and make its very low memory and very performance. Any questions until here? Oops. So that's very fine. I showed something with no effects, but obviously we want to speak to APIs. We want to store data. We want to send messages through sockets and so on. So this is what we've seen until now, except there's something new. When we are not in a beginner program that I showed just before, so that you can play and get used to this Elm architecture basics, then we get an update function that actually returns not only a model, but also a command. And a command is actually a declaration of a side effect that you want the Elm runtime to apply for you. So you don't call the server yourself. And if it makes you laugh, it's actually like when you ask the OS to write a file. You don't open the file descriptor yourself and so on. No, no, no. You just send some data and you hope that the OS will do it properly. In some cases, it doesn't happen. It's the same here. So you describe what you want to do. And the loop goes on. Okay. Later, the runtime will emit the command and take care of it. And this is totally asynchronous. You have no control on that aspect, which is quite important in a UI actually, because in a lot of cases, we have UI that are asynchronous because we want quick reaction while complex stuff is happening in the back end. In the background, I mean. And so once the command has done an effect, messages will be produced. They come back into the runtime. New events later, which produce an event. So the server has finally answered to your query. And so now you will have an error or success. But anyway, that comes again later. And this is again asynchronous. So you get a new message that you have defined yourself from the command. And we are back to what we've seen until now, which is, okay, there was a new message. The message is passed by the runtime to the update function. And we can go on. So with this, you have seen all you need to know about the Elm architecture. There are no more concepts. Obviously, you will want to learn a nice, you need to learn all the nice functional structure. In some case, we are lost because we don't know how to do a loop or to do proper conditionals and stuff like that. But at the architecture level, this is all you need to know to do an Elm application. So once again, because repetition is so nice. Update function in that case, which is the one you will use because you will want side effects, obviously. The update function gets messages from the runtime, gets modeled, the current state of the application. It will, you make your own computation. You create the new model. And if needed, new commands that you pass to the runtime. Any question until now? So let's go. You have, sorry. Could you show the curve again? I got... Your problem. So this one does not have comments, right? Because it does not have side effects. So you see the message type that's describing the increment and decrement. You have the update function, which will return models. So I think the key here is that that expression model plus one is computing a new model and returning it. Exactly. Other questions? Yep. Best pair programming buddy ever. So having been into dynamic languages for so long, I am used to guess what's inside the variable to guess a type. And so on. To protect myself with, I don't know how many tests, or rather to not protect myself with as many tests for the missing values and so on. And so I will show a few scenarios. Nice hands and a bit worse scenarios. How the compiler can actually help you once it has more knowledge about the code than just interpreting it. And dynamic typing like we have in Python or JS. So... Oh yeah. I do this. That's better. So this is the proper code. So let's imagine I had a typo. So this is the type of hertz that you will get. So this is obviously a basic one. But if you... What I like is how precise it is, how much information you get. The hints are pretty cool. Actually, no. Oh, if I did not fix the other one, that won't work. So this is one of the really nice stuff about Elm. It's the fact that when you branch over values, it will never allow you to miss one of them. So I've had to reset message inside my message type. Now the branching does not take care of it anymore. It won't compile. It will absolutely insist that I decide what should happen if... So I could decide to do nothing, obviously, but at least I have to decide to do nothing. Right? It's still not a silver bullet because if I do something... Oops, what's going on here? Oh, thank you. This compiles even though it does nothing. I added a new message. I did not change the HTML, so thank you. There's a new message. It won't ever be emitted because no events can actually produce this. I would need to wire it inside the HTML for it to be emitted somewhere. That's the role of the compiler guy. He is the body programming. Thank you. What did I do again? Sure, sure, sure. What is he expecting? Text risk. So, who can guess with me? Thank you. Okay. So this sort of workflow we just saw is very interesting. It's the fact, okay, now I have a new feature. I add one or two more messages. And then I will change the render compiler again and again and again until it works. Because it will find all the places where I should have taken care of that missing type, missing branch. Let's see this way. Oh, there's one thing I forgot to show. So this is a basic code. This is some code of the only code I have in production. And let's introduce a mistake there as well. That's not easy. That's not quite. So here you get into less pleasant error messages. It's still quite precise and you still get a lot of information. But that might be a bit more frightening. That's what I call worse scenarios. Once your application gets a bit more complex, you will have a lot of issues with the typing, as usual. Which is why we always don't cast in Java. This way we don't need to fiddle with type anymore. Right? So it's the same type of problem we get here. What I found out eventually is that quite often by reading the documentation, once you have the syntax in brain, you can go quite quickly to understanding what's wrong with your types. And so this takes some more habits. So that's why I call it a worse scenario. Excuse me. I'm going to add a browser. Yep. So you have the... Yep. It's all JavaScript. So you don't see the HTML. Yep. So if you want to fine tune the last bits of pixels, that will need some time. There's, as I said, no silver bullets. Sure. Yep. Did you... I still have some time to... So... So what's nice, what else do we have? That's quite nice. Because Elm knows about types and knows a lot about the APIs that you describe in your modules, you won't be allowed to choose yourself the package version when you publish to the package repository. And it will actually... Oops. One more slide. This is not a show-up. So the major, minor version will be changed by itself. So if you do not touch the API, it will generate itself the version numbers. So in other words, when you look at the version number as of a package, if it's only a minor change, you know that outside semantics, you can actually update to the latest minor version and this is enforced by the compiler itself and by the Elm package manager. Sorry for the missing slide. And another one. Oh my God. This is not missing. So how do you do? You just... And you saw me do it. And here's the answer to your question. So you saw me doing Elm make with Elm. And you get JS files that you can or make work by themselves or that you can include into an existing application. So you can mix much Elm application inside React, inside any BlownPage template or whatever. It does not need to control the whole page. It will control the element that you ask kids to control. You can also, if you want, because as I said, you might have this need of make React and Elm live together. So you have some helpers to make it work with Webpack. And I've heard crazy companies that actually had Elm around React, around Elm. So... And it seems it's really manageable. I did not do it myself, but the Elm community claims that it's better to really migrate your application incrementally rather than start from scratch because there's too much to learn. Because... Thank you. And so as I said, you can use the Elm Webpack loader. I did not say it was written there. If you need to integrate your Elm files into your application. How do I use Elm at work? Well, I wish I would use it more first, until now. But this is really the important answer, gradually. It's quite a change because a lot of our reflexes have to go away. Like we always speak of components and objects. This is gone. The basic piece of reuse is function. And you have much less that you can hide in a function. You can still use types. And you are actually encouraged to do it. But that's for instance, one step that you have to make to learn Elm. And so the idea to say, okay, I start from scratch is quite not a good idea. And I found it when I tried to do PlonReact like PlonElm. There's too much to learn. I got to some points, but I think it's actually a much better way of doing small part of an application to get used to the architecture. And the code I showed you in the worst scenario is actually in production for more than almost one and a half years now. And I've never heard about it. And I did something very small somewhere on its Plon widget somewhere. And it works and does the job. And I haven't heard about it. When the new version of Elm came out, migrating it was quite quick and easy. Because they do not add hundreds of features rather than get rid of features. Trying to make it simpler and simpler. Those are the two slides I knew were missing. So let's skip them. Because I don't know why they show on my machine and not on the screen. And I had no time to dig what's happening. Kivyats. Elm is not a general purpose language. So you will use it to do UI and nothing else until now. A lot of people would like to do something else with it. It's really optimized for doing UI. A lot of the patterns are built with that idea. And actually does a general purpose language actually exist. When we want performance in Python, what do we do? We go to see. Or we go to rest if we are very fancy. But do we keep Python? Maybe not. And so just keep in mind that's one tool more in your toolbox. No fiddling with the DOM. If you start to fiddle yourself with the DOM, you are fighting with the Elm runtime that does it for you. And so you'll have issues. So if you need to fiddle with the DOM somewhere, you should rather do it in JavaScript. And then use the proper way to interact between JavaScript and Elm. Because obviously they have a story that I won't explain because that would get us too far. But it's a story that's really nice in the sense that it guarantees that as long as you are in the Elm runtime, in the Elm world, all promises are fulfilled. So there's no null or undefined that it can come and enter from JavaScript into Elm. They do what's needed to avoid this to happen. And the widget I'm mentioning in Blown is actually a widget that interacts with JS code. So that's not that hard. And it works. I just said this, so I don't need to repeat. That's the worst case yet. When you get back and suddenly you find out that, oh, shit, I forgot to test for none or for nil or for undefined or whatever. It gets on your nerves because it's so nice to have the compiler do it for you. That I've said it's, I don't know how many times, and it's worth repeating again. So there are things that you still cannot do because it's still a young language. It's a young community. So if you need some very exotic web API, you might need to go through JavaScript because the Elm runtime does not pack them properly to make it easy. So that's one reason. Broken runtime, try, try, try. Noverding had the first runtime ever something like 3, 4 months ago, and it was due to Chrome extension that was actually fiddling with the DOM behind their back. So it was not even their code, right? And they have, I think, more than 150,000 lines in production or something. It's quite big. And those mistakes, what I mean by this is, okay, I forgot a branch. And not smothering your code properly because once you use this type of strongly typed language, and I could not go into this, you can really design a lot of your application with the types, actually. And which means that you have much less unit tests needed because the compiler does the unit test for you. As you saw, refactoring is awesome. Actually, during that project I mentioned, the small widget I have for Plone, I had made one of those mistakes, a semantic mistake. And I personally exercised the fact that yes, just changing my model and following the compiler until the end, the stuff was working again and the semantic mistake was gone. So just following the compiler errors until there were none. That was good enough. I did not need to change anything else than just change one of the types and follow the stuff to the end. And this is really awesome, really, really awesome. And that makes it clear that if you are a team, it's much easier for someone to dive into this type of code. I will go quickly over those because the slides will be published. If you listen to some of those talks, what you'll find out is that those people think very, very, very deep. It's not like impulsive stuff like I usually do. It's stuff that's thought really deeply. And I think it's really, really interesting. Which also means that the sort of impatience I have when I want a new release now won't happen because they want to think deep before they make a new release. So that's another caveat. In some cases, the fixes are slow to come. And I really want to thank Mario Rodjic. He made those slides for another presentation. I tuned them very few and he was nice enough to allow me to use them for that talk. That's it. Thank you. Yeah, thanks for that introduction. You mentioned about mapping Elm to other concepts. So say I would want to rewrite an existing component like a pattern slip or a mockup component into Elm. Would that be a natural fit or would it be troublesome? If you want to redo a component, you'll be in trouble. You should rather decide to replace that part of your application that uses that component. And hopefully you should start with a simple one, right? And totally get rid of it. The reasoning of Evan is to say that usually you start with something that seems similar and pretty soon your two versions of the supposedly same component are diverging for UI reasons. And so they say just use functions. Just do views. And if you have slight difference, do two subviews. Let's say this way. Do two helper functions that will show the two variations. And don't try to add a myriad of options like we do usually. And then we get to two to the power of n cases that we should test for our component. And that's obviously not tested. Actually, I can't. Other can. I can't. Does that answer your question? It's so true that you start to gain annoy by other languages when you start working with Elm. And I'm more and more annoyed with Python and I'm trying to load annoyance with mypy. But I don't know what I should use on the back end. What do you use on the back end? On the back end, I'm still doing Python until now because I thought I would not be capable of all that stuff. That was interesting to see that I was actually. What was a really strange experience last month is that I found a bug in the M compiler, not in the compiler itself, in one of the part of the tools, had never seen a Haskell and had less than three hours managed to send a pull request with a fix to that. Because the syntax is quite similar. Reading through the docs of Haskell and so on. So I think my next step will be digging into Haskell further because I was so overwhelmed. I had never seen a single line of those three hours included installing the compiler, understanding the slight difference and all that stuff, three hours. Okay, I'm an old monkey but I was still surprised. I was still really surprised. So I think that if we get rid of all the jargon, there's a lot that could be done in Haskell. That will be my next step. But I've not done. I mean, I just fixed a few lines. Yeah, Matt. When you set the messages, you had increment and decrement and then you just added reset in. Is that just how you define messages or is there implicit declaration happening behind the scenes? That was actually a type. And those are all types, right? And actually what I did not show and that's missing in this presentation is that you can also include some values into those messages. So it could be a reset with a value actually. I could put an input field there with the value and the reset could actually hold the value. Does that answer your question? Yeah, that's what I wanted to know. Okay. Can you show? Oh, sorry. I'm going to ask a question. Sorry. Can you? No, I can't show. Dylan needs it. Okay. But I can show it to you later. Yeah, it's working. That's usual. Can I detect? It does not detect. So I would let Dylan... While you're setting that up, are there... I love seeing eye candy. So is there a full UI example available to... Just go to Novrating and you see the type of application they use. I did not explain what they do. They teach English to classes. So it's an application used by teachers for their students. Actually, I'm quite young students. And so I would not use it to build a website part today. I think it would need some time. But their application to teach language has a very fine use. So just use the application for findings. Any way it would be fun to look at it. Yeah, that's... It's purely in. They don't have anything that animates them. Okay. And then secondly, as far as... Is it a good fit for using as the front end to a back end such as blown or any other kind of thing that can provide an API? So I think so. I really think so. When the experiments I did with speaking to the blown Everest API worked well. As I said, the issue was that I was trying to make a too big application at the... In the first step. So getting the data in and out was fine and then the stuff did work. And that's actually how they use it. So it's meant like this. That's one of the caveats that's not mentioned in the code in the talk is the fact that you have to write JSON decoders because JSON comes with all that dynamicity that's... And don't... Does not want. So you have to write it. And that can be tedious at the beginning, but the community has come with a tool that's doing most of the... How do you call it? You give JSON and it will produce some element for you and you can fiddle with it instead of running it all yourself. Yes, running it from the database data type. Exactly. Okay.
 So this is a talk about Elm, as the title says.  And no, it's the moment where it breaks.  I've exercised five times.  Okay, so maybe that's where we'll do it.  Okay, cool.  So what does day say about it?  When I mean day, it's mainly the creator.  So as you can read, the delightful language for reliable web apps,  generate JavaScripts with great performance and no runtime exceptions.  And that's maybe a very important part.  I think the wording is pretty delightful as well.  And this is a recurring theme in the Elm communities using nice language towards each other.  Why did I look at Elm?  Actually, it started among the Plone community.  I heard the men and rock that have been using for nicks for a long time,  and speaking of functional again and again,  then I saw this Elm functional stuff pop up somewhere on my radar,  and I was okay, that must be interesting, but functional.  Ooh, that's so frightening, I won't look at it.  And then again, the men and I think it was the men in that time.  He mentioned that he was using it, and I thought,  okay, this is now a sign that I should look deeper.  Then there's some relationship with the Zoop community as well.  The main sponsor today of Elm is a company called Norriding  that has the same type of relationship to the language as Zoop Corporation,  Digital Creation's head with Python a long time ago.  They host the Elm creator, and they pay him full-time or half-time,  or I don't know what to develop the language.  And I thought, hmm, that's another hint.  That's again interesting.  Then I watched some more talks and got more interested  and found out that they actually have also a BDFL,  and where the B part is the most important.  Even Kamklassak, sorry, his name is hard to pronounce, Saplinsky,  he insists a lot about empathy,  and what he means by this is empathy at all levels,  empathy for the users, empathy for the developers,  empathy towards the creator of the language as well,  and so the B part is very important.  And in another talk was mentioned, okay,  we have with the Elm the same Python paradox  that was mentioned by Paul Graham a long time ago, if you remember.  A famous blog post where he explained that the Python developers  were actually interesting people because they had looked out of the box  and that it was a good advice to just go to Python 15 years ago  to get people that look out of the box.  And they were mentioning the same,  that since they had published the fact that they were using Elm,  they had so many people that would apply for jobs  because there are a lot of people that would like to use Elm in a job,  but could not.  And so all those stuffs lined up and I thought,  okay, I really need this time I have to look at it.  My name is Godfra, you can find me on GitHub and on Twitter.  Goals of that talk.  I will try to explain things that are not that obvious.  I'll do my best.  I will explain all some things of Elm.  There are so pitfalls, there are no silver bullets as we all know.  Most of us have gray hair, so we don't need to be convinced anymore.  And you'll get some reference later, for later.  I will try to avoid to get into very detailed syntax  to try to start to speak of functional programming concepts  like monowheats and occurring and whatever,  that's not the goal at all.  And actually it's supposedly useless in Elm.  The goal is to avoid all that jargon.  Very few codes, at least so that I'll show some so that you can have  a vague idea of the syntax, but not much more.  So what is Elm?  And then let's see some codes.  Explain the Elm architecture quite deeply  because that's the interesting part in my opinion.  And go quite quickly about all some things very quickly,  how I use Elm at work, caveats.  Let's go. So what is Elm?  Functional language, as I already mentioned.  Very important, it's statically typed,  which means that it has nothing to do with the current pattern  or JavaScripts, the compiler will hold your back.  And it has type inference, in other words,  we don't have to annotate for typing everywhere.  Obviously it's recommended for documentation,  but there are a lot of places where you can avoid it.  I click too quickly. All data is immutable.  That's very important.  The more I've been in IT, the more I've become wary of mutable state.  I think build out was the stuff that taught me first,  that being able to get rid of a clone installation,  check out build out again, run everything and start from scratch.  In other words, without any state was so good.  And from that I understood more and more why we don't want data  to change under our feet.  And stop me if anything, if I'm speaking too quickly.  All functions are pure. No side effects.  So this is really important when you have inputs,  whatever inputs you have, the outputs are guaranteed to be always the same.  We all know that if we have a method that's calling a web service,  we might have an issue there.  The data that might come back might not be the same.  That's what a monitor stuff, something that could be called a web side effect.  And in Elm, we don't have null undefined or exceptions,  which could be pretty hard to manage in JavaScript as we all know.  Let's compare JavaScript in Elm because Elm is a functional language  that compiles to JavaScript, which is something very important that I forgot to mention.  So if we are in JavaScript, we have, I don't know how many tools to use,  NPM for packages, Webpack to assemble the application,  React for the nice uniflow of data, Redux to keep your state inside,  and then TypeScript flow, whatever.  I don't want to know actually.  Any in Elm? Okay, thank you.  Everything is built in, so one tool, you got it all.  And by the way, if it's not clear, if you use JavaScript,  you will need to take care of the dependencies of all those tools  and be hopeful that they work together properly.  So just for the people that are still a bit skeptical,  I guess that some of you know that Redux took some of its ideas actually from Elm  from its model of unidirectional flow view update model.  Short side notes.  When we speak of functional, and I said we want a statically type,  we want stuff that's unbreakable.  And what do I mean by unbreakable?  This is something we all know.  We have seen, I don't know how many times, and this is obviously broken.  This is questionable, but at least it's not broken.  The business analyst and the developer should speak to avoid this type of mistakes,  but at least it's not broken.  And it could actually be something that's desired,  if you're describing, I don't know, which painting or I don't know.  Functional style.  So JavaScript and Python praise themselves to have some functional constructs  and show you could use them.  Like we used to say, I can do object oriented style in C.  And yes, you can.  We all know what happened.  First, you have compromises, and second, under loads and under stress,  the developer immediately stops the good practices,  and so we lose the discipline and the functional programming practices in JS.  When you have a functional language,  actually the compiler won't let you do something else, which is quite nice.  Okay, let's go.  I will show you a very, very basic plus minus counter.  So first, Elm is modular like we have in Python, like we really like.  And as you can see, it can also declare what it exposes.  Can import from other modules.  And then here are the four types, four things,  let's say this way that we need to describe when we do an Elm application.  In this case, it's a counter, so let's use an integer as my model,  and the initial value will be zero.  Then what can I do with this application?  I can increment or decrement and see how nice this sort of typing is  because this will be covered.  Those increment and decrement are actually types, and they are validated by the compiler.  Then when I get one of those messages, what should I do?  This is very, very complex.  And finally, some of you that will use the model to display, to turn into HTML,  and where you can declare which messages will be sent.  And outside, the fact that you need to get used to the syntax,  I think that people that have done HTML should be quite at ease with this syntax.  Finally, I'm initializing the program, beginner program in this case,  no side effects at all.  With the, and there's a mistake here in the slide, model should be equal to init model and not model.  Model equals init model, view equal view, update equal update.  And that's all I need to give to Elm to make it work.  We have defined a model, we have defined messages, and we wrote two functions, update and view.  Let's hope that this switch will work.  And imagine this is crazy.  Thank you for your applause.  So, again, stuff that's not showing up here.  As I said, an initial state is passed to the program.  The view, how to turn the state into HTML, into a UI.  And update, which is the function that knows how to react, I said it, to messages.  View takes a model in, it's a function, it's a pure function.  It spits out HTML, actually a description of HTML that the Elm runtime will manage.  New HTML, it's always, because data is immutable, we are not fiddling ourselves with an existing model.  This is HTML that is pure new values.  And that's it.  So that's quite easy to understand, in my opinion.  Update.  And we get the message, because this is the hint that will come from the runtime, and we get the model.  Based on the message and the model, we get a new model.  Once again, this is, the old data are immutable, so this is a copy.  It's not the same model that we are fiddling with.  Let's try to show this with a bit more detail.  So, let's say that I clicked in the browser, the browser emits an event.  That's taken care of by the Elm runtime.  And it will sense, and actually not send, it will call update function with the message that was fired, and the model.  Update will return the new model.  New model, I insist.  And then the runtime passes the model to the view function, the function that we defined.  And the view function can then define which order HTML will look, and which messages should be wired in, let's say this way.  And then again, the Elm runtime will turn that into DOM.  So we never touch DOM ourselves.  And obviously, they have a virtual DOM like React, like Angular, and so on.  And maybe something less obvious is that because the language is totally controlled,  the virtual DOM can be much more optimized because they control the data in data out,  which means that they can really choose the best constructs in JS and make its very low memory and very performance.  Any questions until here?  Oops.  So that's very fine.  I showed something with no effects, but obviously we want to speak to APIs.  We want to store data.  We want to send messages through sockets and so on.  So this is what we've seen until now, except there's something new.  When we are not in a beginner program that I showed just before, so that you can play and get used to this Elm architecture basics,  then we get an update function that actually returns not only a model, but also a command.  And a command is actually a declaration of a side effect that you want the Elm runtime to apply for you.  So you don't call the server yourself.  And if it makes you laugh, it's actually like when you ask the OS to write a file.  You don't open the file descriptor yourself and so on.  No, no, no.  You just send some data and you hope that the OS will do it properly.  In some cases, it doesn't happen.  It's the same here.  So you describe what you want to do.  And the loop goes on.  Okay.  Later, the runtime will emit the command and take care of it.  And this is totally asynchronous.  You have no control on that aspect, which is quite important in a UI actually,  because in a lot of cases, we have UI that are asynchronous because we want quick reaction while complex stuff is happening in the back end.  In the background, I mean.  And so once the command has done an effect, messages will be produced.  They come back into the runtime.  New events later, which produce an event.  So the server has finally answered to your query.  And so now you will have an error or success.  But anyway, that comes again later.  And this is again asynchronous.  So you get a new message that you have defined yourself from the command.  And we are back to what we've seen until now, which is, okay, there was a new message.  The message is passed by the runtime to the update function.  And we can go on.  So with this, you have seen all you need to know about the Elm architecture.  There are no more concepts.  Obviously, you will want to learn a nice, you need to learn all the nice functional structure.  In some case, we are lost because we don't know how to do a loop or to do proper conditionals and stuff like that.  But at the architecture level, this is all you need to know to do an Elm application.  So once again, because repetition is so nice.  Update function in that case, which is the one you will use because you will want side effects, obviously.  The update function gets messages from the runtime, gets modeled, the current state of the application.  It will, you make your own computation.  You create the new model.  And if needed, new commands that you pass to the runtime.  Any question until now?  So let's go.  You have, sorry.  Could you show the curve again?  I got...  Your problem.  So this one does not have comments, right?  Because it does not have side effects.  So you see the message type that's describing the increment and decrement.  You have the update function, which will return models.  So I think the key here is that that expression model plus one is computing a new model and returning it.  Exactly.  Other questions?  Yep.  Best pair programming buddy ever.  So having been into dynamic languages for so long, I am used to guess what's inside the variable to guess a type.  And so on.  To protect myself with, I don't know how many tests, or rather to not protect myself with as many tests for the missing values and so on.  And so I will show a few scenarios.  Nice hands and a bit worse scenarios.  How the compiler can actually help you once it has more knowledge about the code than just interpreting it.  And dynamic typing like we have in Python or JS.  So...  Oh yeah.  I do this.  That's better.  So this is the proper code.  So let's imagine I had a typo.  So this is the type of hertz that you will get.  So this is obviously a basic one.  But if you...  What I like is how precise it is, how much information you get.  The hints are pretty cool.  Actually, no.  Oh, if I did not fix the other one, that won't work.  So this is one of the really nice stuff about Elm.  It's the fact that when you branch over values, it will never allow you to miss one of them.  So I've had to reset message inside my message type.  Now the branching does not take care of it anymore.  It won't compile.  It will absolutely insist that I decide what should happen if...  So I could decide to do nothing, obviously, but at least I have to decide to do nothing.  Right?  It's still not a silver bullet because if I do something...  Oops, what's going on here?  Oh, thank you.  This compiles even though it does nothing.  I added a new message.  I did not change the HTML, so thank you.  There's a new message.  It won't ever be emitted because no events can actually produce this.  I would need to wire it inside the HTML for it to be emitted somewhere.  That's the role of the compiler guy.  He is the body programming.  Thank you.  What did I do again?  Sure, sure, sure.  What is he expecting?  Text risk.  So, who can guess with me?  Thank you.  Okay.  So this sort of workflow we just saw is very interesting.  It's the fact, okay, now I have a new feature.  I add one or two more messages.  And then I will change the render compiler again and again and again until it works.  Because it will find all the places where I should have taken care of that missing type, missing branch.  Let's see this way.  Oh, there's one thing I forgot to show.  So this is a basic code.  This is some code of the only code I have in production.  And let's introduce a mistake there as well.  That's not easy.  That's not quite.  So here you get into less pleasant error messages.  It's still quite precise and you still get a lot of information.  But that might be a bit more frightening.  That's what I call worse scenarios.  Once your application gets a bit more complex, you will have a lot of issues with the typing, as usual.  Which is why we always don't cast in Java.  This way we don't need to fiddle with type anymore.  Right?  So it's the same type of problem we get here.  What I found out eventually is that quite often by reading the documentation, once you have the syntax in brain,  you can go quite quickly to understanding what's wrong with your types.  And so this takes some more habits.  So that's why I call it a worse scenario.  Excuse me.  I'm going to add a browser.  Yep.  So you have the...  Yep.  It's all JavaScript.  So you don't see the HTML.  Yep.  So if you want to fine tune the last bits of pixels, that will need some time.  There's, as I said, no silver bullets.  Sure.  Yep.  Did you...  I still have some time to...  So...  So what's nice, what else do we have?  That's quite nice.  Because Elm knows about types and knows a lot about the APIs that you describe in your modules,  you won't be allowed to choose yourself the package version when you publish to the package repository.  And it will actually...  Oops.  One more slide.  This is not a show-up.  So the major, minor version will be changed by itself.  So if you do not touch the API, it will generate itself the version numbers.  So in other words, when you look at the version number as of a package,  if it's only a minor change, you know that outside semantics,  you can actually update to the latest minor version  and this is enforced by the compiler itself and by the Elm package manager.  Sorry for the missing slide.  And another one.  Oh my God.  This is not missing.  So how do you do?  You just...  And you saw me do it.  And here's the answer to your question.  So you saw me doing Elm make with Elm.  And you get JS files that you can or make work by themselves or that you can include into an existing application.  So you can mix much Elm application inside React, inside any BlownPage template or whatever.  It does not need to control the whole page.  It will control the element that you ask kids to control.  You can also, if you want, because as I said, you might have this need of make React and Elm live together.  So you have some helpers to make it work with Webpack.  And I've heard crazy companies that actually had Elm around React, around Elm.  So...  And it seems it's really manageable.  I did not do it myself, but the Elm community claims that it's better to really migrate your application  incrementally rather than start from scratch because there's too much to learn.  Because...  Thank you.  And so as I said, you can use the Elm Webpack loader.  I did not say it was written there.  If you need to integrate your Elm files into your application.  How do I use Elm at work?  Well, I wish I would use it more first, until now.  But this is really the important answer, gradually.  It's quite a change because a lot of our reflexes have to go away.  Like we always speak of components and objects.  This is gone.  The basic piece of reuse is function.  And you have much less that you can hide in a function.  You can still use types.  And you are actually encouraged to do it.  But that's for instance, one step that you have to make to learn Elm.  And so the idea to say, okay, I start from scratch is quite not a good idea.  And I found it when I tried to do PlonReact like PlonElm.  There's too much to learn.  I got to some points, but I think it's actually a much better way of doing small part of an application  to get used to the architecture.  And the code I showed you in the worst scenario is actually in production for more than almost one and a half years now.  And I've never heard about it.  And I did something very small somewhere on its Plon widget somewhere.  And it works and does the job.  And I haven't heard about it.  When the new version of Elm came out, migrating it was quite quick and easy.  Because they do not add hundreds of features rather than get rid of features.  Trying to make it simpler and simpler.  Those are the two slides I knew were missing.  So let's skip them.  Because I don't know why they show on my machine and not on the screen.  And I had no time to dig what's happening.  Kivyats.  Elm is not a general purpose language.  So you will use it to do UI and nothing else until now.  A lot of people would like to do something else with it.  It's really optimized for doing UI.  A lot of the patterns are built with that idea.  And actually does a general purpose language actually exist.  When we want performance in Python, what do we do?  We go to see.  Or we go to rest if we are very fancy.  But do we keep Python?  Maybe not.  And so just keep in mind that's one tool more in your toolbox.  No fiddling with the DOM.  If you start to fiddle yourself with the DOM,  you are fighting with the Elm runtime that does it for you.  And so you'll have issues.  So if you need to fiddle with the DOM somewhere,  you should rather do it in JavaScript.  And then use the proper way to interact between JavaScript and Elm.  Because obviously they have a story that I won't explain  because that would get us too far.  But it's a story that's really nice in the sense that it guarantees that  as long as you are in the Elm runtime, in the Elm world,  all promises are fulfilled.  So there's no null or undefined that it can come and enter from JavaScript  into Elm.  They do what's needed to avoid this to happen.  And the widget I'm mentioning in Blown is actually a widget that interacts with  JS code.  So that's not that hard.  And it works.  I just said this, so I don't need to repeat.  That's the worst case yet.  When you get back and suddenly you find out that, oh, shit,  I forgot to test for none or for nil or for undefined or whatever.  It gets on your nerves because it's so nice to have the compiler do it for you.  That I've said it's, I don't know how many times,  and it's worth repeating again.  So there are things that you still cannot do because it's still a young language.  It's a young community.  So if you need some very exotic web API, you might need to go through JavaScript  because the Elm runtime does not pack them properly to make it easy.  So that's one reason.  Broken runtime, try, try, try.  Noverding had the first runtime ever something like 3, 4 months ago,  and it was due to Chrome extension that was actually fiddling with the DOM  behind their back.  So it was not even their code, right?  And they have, I think, more than 150,000 lines in production or something.  It's quite big.  And those mistakes, what I mean by this is, okay, I forgot a branch.  And not smothering your code properly because once you use this type of strongly typed language,  and I could not go into this, you can really design a lot of your application with the types,  actually.  And which means that you have much less unit tests needed because the compiler does the unit test for you.  As you saw, refactoring is awesome.  Actually, during that project I mentioned, the small widget I have for Plone,  I had made one of those mistakes, a semantic mistake.  And I personally exercised the fact that yes, just changing my model and following the compiler until the end,  the stuff was working again and the semantic mistake was gone.  So just following the compiler errors until there were none.  That was good enough.  I did not need to change anything else than just change one of the types and follow the stuff to the end.  And this is really awesome, really, really awesome.  And that makes it clear that if you are a team, it's much easier for someone to dive into this type of code.  I will go quickly over those because the slides will be published.  If you listen to some of those talks, what you'll find out is that those people think very, very, very deep.  It's not like impulsive stuff like I usually do.  It's stuff that's thought really deeply.  And I think it's really, really interesting.  Which also means that the sort of impatience I have when I want a new release now won't happen  because they want to think deep before they make a new release.  So that's another caveat.  In some cases, the fixes are slow to come.  And I really want to thank Mario Rodjic.  He made those slides for another presentation.  I tuned them very few and he was nice enough to allow me to use them for that talk.  That's it.  Thank you.  Yeah, thanks for that introduction.  You mentioned about mapping Elm to other concepts.  So say I would want to rewrite an existing component like a pattern slip or a mockup component into Elm.  Would that be a natural fit or would it be troublesome?  If you want to redo a component, you'll be in trouble.  You should rather decide to replace that part of your application that uses that component.  And hopefully you should start with a simple one, right?  And totally get rid of it.  The reasoning of Evan is to say that usually you start with something that seems similar  and pretty soon your two versions of the supposedly same component are diverging for UI reasons.  And so they say just use functions.  Just do views.  And if you have slight difference, do two subviews.  Let's say this way.  Do two helper functions that will show the two variations.  And don't try to add a myriad of options like we do usually.  And then we get to two to the power of n cases that we should test for our component.  And that's obviously not tested.  Actually, I can't.  Other can.  I can't.  Does that answer your question?  It's so true that you start to gain annoy by other languages when you start working with Elm.  And I'm more and more annoyed with Python and I'm trying to load annoyance with mypy.  But I don't know what I should use on the back end.  What do you use on the back end?  On the back end, I'm still doing Python until now because I thought I would not be capable of all that stuff.  That was interesting to see that I was actually.  What was a really strange experience last month is that I found a bug in the M compiler,  not in the compiler itself, in one of the part of the tools, had never seen a Haskell  and had less than three hours managed to send a pull request with a fix to that.  Because the syntax is quite similar.  Reading through the docs of Haskell and so on.  So I think my next step will be digging into Haskell further because I was so overwhelmed.  I had never seen a single line of those three hours included installing the compiler,  understanding the slight difference and all that stuff, three hours.  Okay, I'm an old monkey but I was still surprised.  I was still really surprised.  So I think that if we get rid of all the jargon, there's a lot that could be done in Haskell.  That will be my next step.  But I've not done.  I mean, I just fixed a few lines.  Yeah, Matt.  When you set the messages, you had increment and decrement and then you just added reset in.  Is that just how you define messages or is there implicit declaration happening behind the scenes?  That was actually a type.  And those are all types, right?  And actually what I did not show and that's missing in this presentation is that you can also include some values into those messages.  So it could be a reset with a value actually.  I could put an input field there with the value and the reset could actually hold the value.  Does that answer your question?  Yeah, that's what I wanted to know.  Okay.  Can you show?  Oh, sorry.  I'm going to ask a question.  Sorry.  Can you?  No, I can't show.  Dylan needs it.  Okay.  But I can show it to you later.  Yeah, it's working.  That's usual.  Can I detect?  It does not detect.  So I would let Dylan...  While you're setting that up, are there...  I love seeing eye candy.  So is there a full UI example available to...  Just go to Novrating and you see the type of application they use.  I did not explain what they do.  They teach English to classes.  So it's an application used by teachers for their students.  Actually, I'm quite young students.  And so I would not use it to build a website part today.  I think it would need some time.  But their application to teach language has a very fine use.  So just use the application for findings.  Any way it would be fun to look at it.  Yeah, that's...  It's purely in.  They don't have anything that animates them.  Okay.  And then secondly, as far as...  Is it a good fit for using as the front end to a back end such as blown  or any other kind of thing that can provide an API?  So I think so.  I really think so.  When the experiments I did with speaking to the blown Everest API worked well.  As I said, the issue was that I was trying to make a too big application at the...  In the first step.  So getting the data in and out was fine and then the stuff did work.  And that's actually how they use it.  So it's meant like this.  That's one of the caveats that's not mentioned in the code in the talk is the fact that you  have to write JSON decoders because JSON comes with all that dynamicity that's...  And don't...  Does not want.  So you have to write it.  And that can be tedious at the beginning, but the community has come with a tool that's  doing most of the...  How do you call it?  You give JSON and it will produce some element for you and you can fiddle with it instead  of running it all yourself.  Yes, running it from the database data type.  Exactly.  Okay.
2018_Day3_Introduction_to_Elm_by_Godefroid_Chapell_AGPaUgog5p0_0_467.png 2018_Day3_Introduction_to_Elm_by_Godefroid_Chapell_AGPaUgog5p0_468_515.png 2018_Day3_Introduction_to_Elm_by_Godefroid_Chapell_AGPaUgog5p0_516_1331.png 2018_Day3_Introduction_to_Elm_by_Godefroid_Chapell_AGPaUgog5p0_1332_12575.png 2018_Day3_Introduction_to_Elm_by_Godefroid_Chapell_AGPaUgog5p0_12576_12755.png 2018_Day3_Introduction_to_Elm_by_Godefroid_Chapell_AGPaUgog5p0_12756_12899.png 2018_Day3_Introduction_to_Elm_by_Godefroid_Chapell_AGPaUgog5p0_12900_13463.png 2018_Day3_Introduction_to_Elm_by_Godefroid_Chapell_AGPaUgog5p0_13464_13655.png 2018_Day3_Introduction_to_Elm_by_Godefroid_Chapell_AGPaUgog5p0_13656_13931.png 2018_Day3_Introduction_to_Elm_by_Godefroid_Chapell_AGPaUgog5p0_13932_14255.png 2018_Day3_Introduction_to_Elm_by_Godefroid_Chapell_AGPaUgog5p0_14256_14375.png 2018_Day3_Introduction_to_Elm_by_Godefroid_Chapell_AGPaUgog5p0_14376_14435.png 2018_Day3_Introduction_to_Elm_by_Godefroid_Chapell_AGPaUgog5p0_14436_17003.png 2018_Day3_Introduction_to_Elm_by_Godefroid_Chapell_AGPaUgog5p0_17004_17123.png 2018_Day3_Introduction_to_Elm_by_Godefroid_Chapell_AGPaUgog5p0_17124_17363.png 2018_Day3_Introduction_to_Elm_by_Godefroid_Chapell_AGPaUgog5p0_17364_18227.png 2018_Day3_Introduction_to_Elm_by_Godefroid_Chapell_AGPaUgog5p0_18228_18479.png 2018_Day3_Introduction_to_Elm_by_Godefroid_Chapell_AGPaUgog5p0_18480_18899.png 2018_Day3_Introduction_to_Elm_by_Godefroid_Chapell_AGPaUgog5p0_18900_19091.png 2018_Day3_Introduction_to_Elm_by_Godefroid_Chapell_AGPaUgog5p0_19092_19499.png 2018_Day3_Introduction_to_Elm_by_Godefroid_Chapell_AGPaUgog5p0_19500_26903.png 2018_Day3_Introduction_to_Elm_by_Godefroid_Chapell_AGPaUgog5p0_26904_27839.png 2018_Day3_Introduction_to_Elm_by_Godefroid_Chapell_AGPaUgog5p0_27840_29435.png 2018_Day3_Introduction_to_Elm_by_Godefroid_Chapell_AGPaUgog5p0_29436_36059.png 2018_Day3_Introduction_to_Elm_by_Godefroid_Chapell_AGPaUgog5p0_36060_36299.png 2018_Day3_Introduction_to_Elm_by_Godefroid_Chapell_AGPaUgog5p0_36300_37739.png 2018_Day3_Introduction_to_Elm_by_Godefroid_Chapell_AGPaUgog5p0_37740_39815.png 2018_Day3_Introduction_to_Elm_by_Godefroid_Chapell_AGPaUgog5p0_39816_41831.png 2018_Day3_Introduction_to_Elm_by_Godefroid_Chapell_AGPaUgog5p0_41832_41927.png 2018_Day3_Introduction_to_Elm_by_Godefroid_Chapell_AGPaUgog5p0_41928_42047.png 2018_Day3_Introduction_to_Elm_by_Godefroid_Chapell_AGPaUgog5p0_42048_42203.png 2018_Day3_Introduction_to_Elm_by_Godefroid_Chapell_AGPaUgog5p0_42204_42251.png 2018_Day3_Introduction_to_Elm_by_Godefroid_Chapell_AGPaUgog5p0_42252_42455.png 2018_Day3_Introduction_to_Elm_by_Godefroid_Chapell_AGPaUgog5p0_42456_42707.png 2018_Day3_Introduction_to_Elm_by_Godefroid_Chapell_AGPaUgog5p0_42708_43235.png 2018_Day3_Introduction_to_Elm_by_Godefroid_Chapell_AGPaUgog5p0_43236_43403.png 2018_Day3_Introduction_to_Elm_by_Godefroid_Chapell_AGPaUgog5p0_43404_43583.png 2018_Day3_Introduction_to_Elm_by_Godefroid_Chapell_AGPaUgog5p0_43584_47903.png 2018_Day3_Introduction_to_Elm_by_Godefroid_Chapell_AGPaUgog5p0_47904_48323.png 2018_Day3_Introduction_to_Elm_by_Godefroid_Chapell_AGPaUgog5p0_48324_57695.png 2018_Day3_Introduction_to_Elm_by_Godefroid_Chapell_AGPaUgog5p0_57696_60095.png 2018_Day3_Introduction_to_Elm_by_Godefroid_Chapell_AGPaUgog5p0_60096_61643.png 2018_Day3_Introduction_to_Elm_by_Godefroid_Chapell_AGPaUgog5p0_61644_63767.png 2018_Day3_Introduction_to_Elm_by_Godefroid_Chapell_AGPaUgog5p0_63768_64743.png