Manipulating Values Review & Q&A

[00:00:00]
>> Richard Feldman: So to recap the things we've talked about here, first, we talked about strings and how you can combine them. So if we say the letter "d" ++ String.fromInt 6, that will give us the string d6. If we have a let expression, we can say, let x = 5 in x * 2.

[00:00:17]
We can put as many different values that we want inside that let expression. The entire expression evaluates to what comes after in. We saw some stuff with lists, in particular list.map, which is a useful way to transform a list of one item into a list of another items.

[00:00:34]
So we saw how we can use that with numbers, with strings, and even with virtual DOM nodes. Also lists have to have a consistent type which prevents run time exceptions that can otherwise occur. And finally, we saw a partial application. We saw that when we called pluralize passing "leaf" and "leaves".

[00:00:48]
That gives us back a new function, which accepts the final argument that pluralize wants and sort of finishes the job. And as we'll see later, partial application and List.map and things like that can be pretty useful together. Any questions about any of this before we get to the exercises?

[00:01:07]
>> Richard Feldman: Yes.
>> Speaker 2: I have some kind of somewhat related generic questions on some of this stuff. So List.map, I'm just curious that some languages, they'll have a generic map. And in Elm, everything kind of has its own.
>> Richard Feldman: Yes.
>> Speaker 2: I'm just curious what's the difference or decision there?

[00:01:30]
>> Richard Feldman: Some languages will have a generic map, whereas Elm has a special purpose one. So this is really a question of name resolution. So in some languages, you'll have, syntactically, you'll just say the word, map. You won't say List.map or Set.map, or whatever the data structure is. In both cases, they have different implementations under the hood.

[00:01:53]
They may have been arrived at using different amounts of code sharing. But fundamentally, if you're going to have a map function that works on a list, you're gonna have a different map function that works on a set, cuz those are different data structures. In Elm sort of the style is encouraged is to write everything out explicitly and say like this is a List.map.

[00:02:10]
It's gonna work on a list. This is a Set.map. It's gonna work on a set. Whereas in other languages they have different name resolution mechanisms that potentially let you just say map and then maybe you're passing in a sent, maybe you're passing in a list. But it may be even in the same module.

[00:02:25]
But basically the reason for this is is it's sort of a has to do with sort of the design sensibilities around Elm. So, as an example like Haskell's a language where it's a different design set. It's like in Haskell it's encouraged to only use a map and Haskell supports that.

[00:02:41]
Elm's compiler was written in Haskell but Evan decided to go a different direction than that.
>> Speaker 2: So like, under the hood a list, does it actually compile to something in JavaScript that enforces that the types within it are the same?
>> Richard Feldman: No, no-
>> Speaker 2: We said, no, the compiler knows, okay, I have already checked, so it can just be an array under the hood.

[00:03:10]
>> Richard Feldman: So the question was does Elm's compiler actually emit something that verifies in the compiled JavaScript that the contents of the list are all the same? Or, is that only a compile time check? It's only a compile time check. However it does not actually compile to literally a JavaScript array.

[00:03:27]
It compiles to a linked list, an immutable linked list in JavaScript, which is not represented as a plain JavaScript array. So it has different characteristics as far as how expensive it is to add things to the beginning versus the end versus looking something up in the middle. So it's just implementation details that matters from a performance perspective but not from how you actually use it if you're just worried about will things break or not?

[00:03:51]
The compile checks are enough.
>> Speaker 2: So are there any things like that that it compiles to where like newer language features or something are gonna. I'm just kinda curious if browser target is a thing that we would ever want to care about with Elm cuz we would get less, or something?

[00:04:13]
>> Richard Feldman: Browser target is a thing that you would care about within Elm. Sorry, I don't really follow that. [LAUGH]
>> Speaker 2: Like, if it compiled to some newer language feature in JavaScript that was better or something?
>> Richard Feldman: Got it. So right now Elm targets mostly ES3. It compiles to ES3 compatible JavaScript.

[00:04:35]
It doesn't, with the exception of, I think there's request animation frame and some of stuff that's like ES5. But, the question is like sort of in the long term, do you have to worry about Elm compiling to stuff that's not backward compatible, etc. Honestly, I wouldn't worry about that with JavaScript.

[00:04:51]
However, Elm is explicitly designed to compile to WebAssembly someday. WebAssembly's not really ready for it yet. It still needs a garbage collector and some stuff like that. But we’ve been talking with Mozilla folks on several occasions about how that would work. Not only is it designed to be able to compile to WebAssembly, but it’s designed to be able to compile to WebAssembly with all of your existing JavaScript interrupt continuing to work.

[00:05:18]
JavaScript interrupt, not WebAssembly interrupt. So, the idea is that based on the current design, you could, in some release, download a patch release of Elm, where now Elm compiles to WebAssembly and everything's just absurdly faster and smaller. But all of your existing code still works, exactly the same way as it did before, including your JavaScript interrupt.

[00:05:38]
So backwards compatibility is something that Elm takes pretty seriously as far as browsers go. And generally the design is to try and make it as compatible as with as many older browser features as possible, sort of by default. And not to use any newer browser features, unless there's really no other alternative to get that particular thing done.