Introduction to Elm, v2 Introduction Review & Q&A
Transcript from the "Introduction Review & Q&A" Lesson
>> Richard Feldman: Any questions before we get to the exercise?
>> Student 1: Elm.Main.embed versus Elm.Main.init?
>> Richard Feldman: So back in Elm 0.18, there was an Elm.Main.embed. In 0.19, that changed too. We always say .init and init can take different arguments. So I guess the answer is that it's always in it now, but previously there used to be different variations on that.
>> Student 1: Regarding Elm packages, I've seen some reference to star.dat files on Evan's disk. Is there any relationship with IPVFS or the DAT protocol?
>> Richard Feldman: No, .dat is essentially just a file extension indicating that it's binary data. So those are all just cached files that live in, you never actually interact with .dat files.
[00:00:58] It's just like when the compiler runs, it caches some information in a temporary directory so that the next time it runs it doesn't have to recompute that from scratch. And because it's more compact to store it as binary data than like JSON, it stores them as binary data and it chooses to use the extension .dat for that.
[00:01:15] That's all.
>> Richard Feldman: So you won't actually ever necessarily interact with dot dot files unless you're writing some tooling for Elm maybe. What is the learning curve for Elm when your training new employees? So I would say. [CROSSTALK]
>> Student 1: Or just said learning curve in general for Elm.
>> Richard Feldman: Yeah, well hopefully we'll get an idea of that over the course of today.
[00:01:34] [LAUGH] But so what I would say is that usually people can get productive to the point of just through pair programming and sort of picking stuff up. They can get to the point of being able to write Elm code unsupervised in their first week if you're pairing it and sort of investing and, like, actually teaching them some stuff.
[00:01:54] And not just saying, okay, go read the docs. You're on your own. I found pair programming is really effective for helping people get up to speed. But I would say that they're going to have a lot of questions at first, of course. So if they're modifying existing code, like doing a bug fix, that can be potentially pretty easy depending on what the bug fix is.
[00:02:15] If it's just some business logic. But I would say that it takes longer to of course achieve mastery. And to sort of build your own things from scratch, build new features from scratch to understand how to do things. The compiler helps a lot. That's a recurring theme is that it's a lot harder to do the wrong thing and end up with the wrong output because most of the beginner mistakes you can make will get caught by the compiler.
[00:02:41] So I don't know if I can put a number on and say the learning curve of Elm is this, but hopefully that gives an idea of sort of the considerations.
>> Student 1: [INAUDIBLE]
>> Richard Feldman: All right, yeah.
>> Student 2: I don't think I've seen anything, but is there anything for source maps or any kind of like community thought around source maps?
>> Richard Feldman: Yeah, so I always forget about source maps because like we don't get real text. [LAUGH] So the two things that source maps would be useful for. One is like browser profiling, like flame graphs and stuff. Like having those actually mapped to the the original Elm functions rather than the generated ones.
[00:03:25] It's kind of nice to have. It doesn't really exist yet because it just hasn't really been a high priority project. And the other is, what is it? If you want to do step debugging in the browser, like, if you want to say pause execution and then step step step.
>> Student 1: So what is the process for changing the language itself. And is it like community driven or is it like this Evan guy in a cave somewhere meditating-
>> Richard Feldman: [LAUGH]
>> Student 1: And comes up with the next feature.
>> Richard Feldman: Yeah, so Elm definitely has the BDFL, the Benevolent Dictator for Life model.
[00:04:22] I think, that was Python's term originally. Although I guess now Guido retired, [LAUGH] so they now have a different model. But, yeah, so Elm actually works. Sorry, Evan works on Elm at No Red Ink. We hired him in 2016. So it's not in the cave, it's in an office in Boston.
[00:04:43] [LAUGH] But basically we just pay him to build the language. And so we've made a very direct financial investment in Open-source. Cuz we wanted to give back and for variety of reasons, but basically, yeah, he's sort of like the ultimate decision maker. There is a core team of people who work on different things.
[00:05:01] Obviously there is lots of community input into the decisions, but at the end of the day, it's not like, there's no voting process. So there's no committee for change requests and stuff like that. It's very like, Evan makes the decisions like at the end of the day.