"Code is the Easy Part" by Evan Czaplicki
elm-conf2 HN recommenders · recommended in 2 months, 2016–2020
talk · intermediate · 2016–2020 on HN
Evan Czaplicki, creator of Elm, gives an elm-conf 2016 talk on the non-code side of building a language. It covers the philosophy behind Elm's development approach, including batching work and the priorities of different language communities.
HN points people to it to understand Elm's design philosophy, such as favoring simplicity over type classes, when they question its choices.
Up next
16 mo on HNHow Python was Shaped by leaky Internals, Armin Ronacher, Flask framework
Видео с мероприятий {speach!
15 HN recommender · 2017–2025
12 mo on HNWhy Isn't Functional Programming the Norm? – Richard Feldman
Metosin
12 HN recommender · 2019–2025
11 mo on HNMaybe Not - Rich Hickey
ClojureTV
14 HN recommender · 2018–2025
10 mo on HNConway's Game Of Life in APL
Dyalog
11 HN recommender · 2010–2024
9 mo on HNLecture 1A | MIT 6.001 Structure and Interpretation, 1986
MIT OpenCourseWare
11 HN recommender · 2012–2024
10 mo on HNCrockford on JavaScript - Volume 1: The Early Years
YUI Library
10 HN recommender · 2013–2022
10 mo on HNGrowing a Language, by Guy Steele
Bill Pugh
11 HN recommender · 2014–2026
10 mo on HNEffective Programs - 10 Years of Clojure - Rich Hickey
ClojureTV
10 HN recommender · 2017–2026
9 mo on HNBrian Goetz - Stewardship: the Sobering Parts
ClojureTV
10 HN recommender · 2014–2025
10 mo on HNJavaScript: The Good Parts
Google TechTalks
11 HN recommender · 2009–2020
9 mo on HNIdeas about a new programming language for games.
Jonathan Blow
7 HN recommender · 2014–2025
8 mo on HN"Propositions as Types" by Philip Wadler
Strange Loop Conference
9 HN recommender · 2015–2026
4 comments from Hacker News
Every time I hear about procrastination it reminds me about great talk by Evan Czaplicki and his approach to Elm development, actually it can be good thing ( ▶ this video see 19:15 Batching Work).
Here's how I see his point. He came to Elm expecting a Haskell for the web. Elm has the completely opposite philosophy of keeping things simple, even if it means extra boilerplate. I can understand OP's frustration, but if he watched a few of Evan's talks (like this one ▶ this video ), he would realise his expectations about Elm are wrong. Also, he forgot that Elm (just like any other open source project) doesn't owe him anything. That's why many people take an issue with his tone. In summary, Elm's target audience are JavaScript developers. It's developers who want their apps to be more robust and easier to refactor than in plain JavaScript. Sure, type classes are useful but they also increase complexity. Evan wants to see if there's a better solution and the Elm community generally accepts that.
This mirrors my experience quite perfectly. To add another aspect: The over-management of GitHub issues is, in my experience, borderline pathological. On dozens of occasions (no exaggeration), I've experienced the following: - I notice some bug, or some missing functionality. - After dozens of searches I finally find a relevant Github issue. It's difficult to find because it's closed, in a project with a different, former name to the current version of the package, and part of a now-defunct GH organisation. - The only comment on the issue was Evan saying the issue is being folded into some meta issue bundling "issues concerning <some broad concept>". He closes the issue and adds a line into the meta issue. - Any discussion of individual items on the meta-issue is blocked - Work on that collection of issues is not going to happen "right now" because "it's so much more efficient to work on sets of related issues". - 14 months or so later, some work is done on <general concept>. The issue is closed (& locked) - My original issue obviously persists Evan seems to consider open issues as accusations or personal failures, or otherwise I can't understand why this is happening. When some recent version broke the existing support for WebSockets, the issue was immediately closed (making it, again, invisible to people experiencing this problem and searching with default options). The most constant output of Elm leadership are long-winded essays explaining how, specifically, you're stupid
I don't think the response was as simple as "No, you can't have that because I don't want to". Reading the discussion about removal of this feature on Github there seems to be a few more points made that the author alludes to: link Also, It's worth noting that Elm does have a BDFL. Evan makes the call and, as I'm sure a lot of python folks would agree, that setup means that the language is going to remain consistent, clean and well defined. This might be frustrating, but is part of keeping a strong design philosophy that directs the language. In that context, is it really a valid criticism? Evan actually addresses this issue directly by talking about the different communities with different aims. He says that having these different communities with different design decisions makes the whole scene a lot stronger[1]: > if you go back a year so on the mailing list you'll see a lot of people talking about type classes "when are we going to have this in Elm?", "we need this", "this is the most important thing", and a language came out that had different priorities and all the people who wanted that kind of feature started using that language and so now that's not to say one of the communities is making a better choice than the other, it just means we can all experiment with a different philosophy and way of thinking and do well." [1] ▶ this video