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!?
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.
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.
@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.
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.
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/
![[#2024MAMA] ROSÉ (로제), Bruno Mars - APT. | Mnet 241122 방송](http://i.ytimg.com/vi/dgGqD28J6aQ/mqdefault.jpg)
Still one of my favorite elm talks, I love the walkthrough
Of all the dozens of Elm videos on TH-cam, this is probably the most useful one I've watched. Kudos, Evan! Elm is rad! :-)
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!
I'm glad he made this video. I've been wondering when to start splitting my files "just because" and now I don't feel bad for having a few long files.
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.
God... that sounds like a nightmare. What kind of massive enterprise are you guys building?
Which type systems are better than Elm's? 🤔
@@virzenvirzen1490 Haskell, Purescript, Idris...?
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!?
The most irritating thing is not showing the slides when he's presenting code. Maybe it was some technical limitation.
Much love thank you ♥️
This is fantastic! Why does this not have more likes? And the dry nerd humor is awesome :) . Enjoyed this very much. Great job Evan!
This is a really good video! I like this data-structure first approach to thinking of a problem.
If we ever encounter Aliens I would send Evan as a representative of humans to meet them.
Such a great talk and huge point (data structure first).
7:30 - Grow Files until finding data structure to split on
10:30 - what are all possible ways to represent this.
Amazing, solid and practical advice.
Evan looks just like a slim Jeff Goldbloom with those glasses.
He also has a similar way of speaking
I can't see the slides
Good talk, bad camera
If the compiler is so programmer friendly, the guy who wrote the compiler MUST be a forgetful but mindful person.
Evan is a ProgLang Rock Star. (And quite rightly too.)
I’m surprised ML-type languages don't catch on better, what's not to like here? I also really like Yeti, an ML for the JVM :)
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.
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.
@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.
Why does whoever edits these not just keep focus on the sides!?
Is it really important to show us Evan typing? We want to see the actually text!
Add typeclasses
MONAD!
Thank you for sharing, but I'm afraid the video editing is terrible. It is impossible to see the code or anything Evan is typing.
We had technical issues and did our best to make it as readable as possible, thank you for your understanding.
Thank you for sharing, despite the problems :)
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.
Perhaps a better format would be to switch off the house lights and use a small stage light for the speaker alone
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.
I'm off now earning shitloads of money with the Evan's idea of fruits.com!
Green grocers AND PHP coders HATE HIM! Click to learn this simple trick invented by an ordinary functional programmer...
Great talk. Bad title.
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?
Cout970 it’s more applying the “good parts” of oop. We don’t want mutability, data mixed with functions (ie objects), or side effects.
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/
I was thinking exactly the same thing! Its like you started with FP and worked his way back to OOP without realising
No.
Almost the same just simpler and in JS/TS - gitlab.com/peryl/peryl
@@jgt_ I like Elm, but it is really not simpler language, definitely not. Just compare adoption of Elm and JS/TS. :)
@@jgt_ Can you prove the Elm is simpler language than TS please? :)
@ go investigate for yourself, you might learn something cool!
@@Hexagonaal Can you prove the Elm is simpler language than TS please? I said it is not! So put your argument on the table or shut up!
@ Yeah, I think I can see why nobody is responding to you anymore. Good luck!