7ML7W Elm Day 3 The Elm Architecture
[Interior, Geckoboard's main office].
Appreciative murmurs of more intimate atmosphere and more readily available snacks.
Paul introduced the session and reminded us why we decided to learn Elm without the book i.e. the book does not do a very good job of explaining and also key parts of the language that it covers have dramatically changed in recent versions of the language.
We began by discussing the interview with Evan Czaplicki, the creator of Elm, that appeared in the book.
Paul: On CSS and HTML, the author is says they are annoyed but then not much more said
Mark: Clearly the author has an academic background, but they are also very explicit that usability of the language is important to them.
Tom: Focus is on Functional GUI's, this is unusual for functional programming languages.
Mark: Smalltalk is exemplar of OO language but could also be viewed as functional and it is GUI focussed.
Leo: Functional Reactive Programming predates Elm, is Elm an implementation?
Mark: Not anymore because it has switched away from Signals.
Tom: It's contemporaneous with React and has a similar idea, i.e. a declarative user interface (i.e. template generates an immutable data structure and the framework/language work out the mechanics of how to update DOM) and an update method to update model. This is what Redux took.
Paul: React is the main functional approach so the question remains about why Elm didn't take off in the same way.
We took a look at the Clock example
Tom: What is different about the Clock and why do we need subscriptions for it.
James: In button example, HTML Msg, when we press a button the Msg is emitted and Elm sends it to update for you. This is a special case.
Now we are on a 'grown up' program, rather than a
Html.beginnerProgram, and have an init function (which returns a
model and command), and a subscriptions function
Subscriptions are dependent on the model, so that they can be changed depending on state.
James: Why do these messages always take constructors...
Tom: This makes it easy to distinguish the different types of message in the update function.
James: Could choose to implement in another way which gives more control to the programmer.
We get the clock running
Leo suggests changing the subscription to update every millisecond, like so
subscriptions model = Time.every Time.millisecond Tick
And there are general murmurs of appreciation as the second hand moves smoothly round instead of ticking.
Tom: I am a bit lost on the concepts
Joel: Elm runtime emits Msg and calls the update function, which
updates your model, and then Elm makes sure your subscriptions and view
are kept in sync.
There are various things that can trigger the Elm runtime to emit a
Msg.
-
A user interacts with your GUI e.g. the user presses a button, and these events are set in your template
-
Something else happens (time passes, a websocket sends information etc.) and the events you are listening for are set in your subscriptions
-
The programmer wants something to happen which is not purely functional (e.g. IO) and so triggers a Cmd for the Elm runtime to deal with.
Tom: Important to note all Cmd's are queuing things up to be done by Elm runtime later, rather doing right now.
We look at this in the reply and see that this is indeed the case, with Cmd's essentially just generating a data structure defining what can be done later.
> WebSocket.send "http://localhost" "foo"
{ type = "leaf", home = "WebSocket", value = Send "http://localhost"
"foo" } : Platform.Cmd.Cmd msg
James: Could you write Html.program in Elm
Joel: I don't think so because you don't appear to have access to how functions are wired up to the Elm runtime.
Dmitry: Can you call arbitrary Javascript?
Ali: Yes, but since arbitrary Javascript is not purely functional this has to be via the Elm runtime (make Cmd)
An interlude of messing with reversing a text field on every keyboard press to see whether the order of events is deterministic.
Leo: How are more complex elm programs written. Can you set up a component with it's own update loop.
James: I think you can, but not entirely sure.
Ali: It is not at all obvious how to build components in Elm which seems disappointing.
James demo'd the version of Snake implemented in Elm that Joel built.
Leo was suitably disappointed by the mouse move checks (Cmd's not subscriptions).
Paul: Error messages are really good.
James: We didn't get stuck on them.
Mark: We had compiler errors but no behaviour we couldn't explain.
Tom: Type system really hasn't got in the way.
Mark: Is that because we have Haskell people in the room?
Leo: I really like Elm, but Facebook co-opted into React.
Paul: Ergonomics as good but also downfall.
Tom: It is not just psychological, being able to adopt bit by bit. React has lots of the architectural advantages without having to change everything. It is not just a matter of worse is better.
Charlie: Being in the meeting room, rather than out in the wider office is an improvement, we should do this next time too.
Paul: Do we want to continue with the book onto Elixir?
General agreement that we are interested in learning about Elixir.
Tom: There were two problems, firstly badly written and second the language had significantly changed. The second of these is no fault of author, the first is no fault of the book and the chapters have different authors.
We agree to continue with the book for Elixir.
Tuzz rounds the evening off with a ceremonial wheeling of the table.
Thanks to @tuzz for organising, @tomstuart and @charlieegan3 for providing bread and dips, @jcoglan for driving and to Geckoboard and @leocassarani for hosting.
Finally thanks to Paul for agreeing to organise the next meeting.