This is the first talk by Evan I see, and it’s as good as you might expect. Very insightful far beyond the world of Elm (as are most things with Elm). Thank you, Mr. Czaplicki!
The fact about refactors being cheap is really true: here at work we've made architectures mistakes in an ~60kloc codebase. We're a 3 people team, fixing it took 110 commits, touched 529 files with +9,695 and −11,162 lines. A **4 days** effort with minimal planning, Elm type system isn't the best one out there, but it's sound and make this kind of changes possible even for less experienced teams like the one I'm working in.
It's hard to view the code via a youtube. I'd love it if this presentation was something akin to ConFreaks videos. Show the presenter and the code alongside each other.
Yes! It makes me so mad whenever it cuts away from the slides. Okay great, Evan is gesturing at the slides. Was it really so important to show me that instead of the text of the slide!?
3:40 doesn't this apply to basically every OOP language? i once had to build a javascript frontend for a site where the backend (api) was written in java (maven) and people there wanted to rewrite everything too...
It absolutely does apply; but, I think the reason Evan mentions javascript in particular is that most people who come to elm come from javascript, since that's the (vastly, vastly) predominant language of front-end development.
i think the thing not to like in ML languages is the fact that you have to obey whatever rules/guides/architecture comes with, or is recommended by, the language. and it seems like devs dont really like that kind of restriction im trying to give elm a go but... its really annoying to see myself thinking "i just cant do this" where if it i was coding in ruby or python there would be tons of ways to make it work
sorry for late reply (xD), but for all the others: try F#. It's functional language for dot.net (with .NET 5 running everywhere, from windows, through linux, mac to rasperry pi and even some microcontrollers). You can switch between ML syntax and C like syntax if you really want.
I don't think it is so much a problem with video editing but about the use of a white background and light colors with a projector. If the presenter is using a Mac, you could suggest enabling the system's contrast filter.
It's readable with full screen HD. Not ideal, but readable. Ideally, the projected screen would be simply inserted into the recording, in its pure form. Then there'd be no jarring jump between the pure screen view and the live version.
@11:48 Just because a data structure provides some ordering doesn't mean that you have to use it. The view could still determine the order. Whenever/wherever you want to show the value for a certain thing, you look that thing up in the data structure and get its value. Also, the assumption that specific types are always better than the more generic String type is false. There are always tradeoffs.
Isn't he just applying OOP concepts to ELM? I mean making modules around types, hiding implementation details, minimizing api size, avoiding getters and setters, why not just use OOP in the first place?
but you can have immutability and avoid side effects in OOP. Is there really a big difference from using a method (implicit this) and passing data as an argument?
You can certainly try to avoid side effects and you can code in an immutable way, but it takes discipline and it's just another thing to think about when coding. Life is easier when you don't need to worry about making these mistakes. For data mixed with behaviour (ie method calls on an object), see Mark Seemanns great post comparing OOP in C# and functional programming in F#: blog.ploeh.dk/2014/03/10/solid-the-next-step-is-functional/
