Elm Europe
2 HN recommenders · recommended in 7 months, 2018–2023
47:52 · 31K views · Jul 18, 2018
Elm creator Evan Czaplicki's 2018 Elm Europe talk on how to define success for an open source project and language community. It argues against judging projects by GitHub activity and touches on community expectations.
Cited in debates over Elm's direction and open source health, with some praising its points about metrics and others finding its tone toward unhappy users hard to watch.
8 comments from Hacker News
Agreed; I think it's important to realize that a naive bias for action/productivity is not always the best thing. It's imperative to cultivate a good sense of what is worth doing, otherwise one will just produce a lot that will be irrelevant at best or garbage at worst. There are many "productive" people, but a question worth asking is how many of those actions result in lasting value, however you choose to qualify that. A lot of competent and productive people leave lasting negative value, due to misdirected efforts. For some definitions, spending a weekend building sand castles with kids might have more lasting value than working on a coding project. Don't let more visible metrics of productivity (eg: number of Github projects, HN points, etc.) cloud your judgement. If you want to step back and think about this matter (one productive use of the weekend ;-)), I really like the talk by Evan Czaplicki (Elm creator/designer) on "What is success?" which might provide some food for thought [1]. To clarify, doing only things that are worth doing doesn't imply holding back from producing/practicing because you're not yet good enough. I was referring more to the direction than the quantum in that direction. See what Ira Glass said about taste and practice [2]. [1]: this video [2]: [LINK]
Interesting observation by Aaron Swartz. That could happen because the barrier to entry for adding to a text blurb is much lower than that for contributing to a code base — maybe because we practice the former for a decade in school. For code, ease of access (edit ability) is non-obvious and therefore, an important axis along which to evaluate open source projects. So, funnily enough, I agree with you because the data you quoted for Wikipedia is much less likely to apply to code :-) Btw, I recently came across a talk by Evan Czaplicki (creator of Elm lang) on “What is success?” for an open source project like Elm, and he raises some interesting points about how measuring projects by Github activity is strongly biased by a model of how the larger Javascript community works: this video
Why is the pace of releases an important metric for using a programming language? Focus on code quality, and maintenance simplicity. If anything, being able to use the same version for x years and having it be consistently better than any JS library/framework I used, means that the work done is of high quality. Maybe you should watch Evan's talks from various Elm conferences ( search on youtube, for example this video ) He addresses that concern that some people have, and why it has the pace it has. As I understand it, it's better to do things right and take as long as it needs, rather than hurry and ship fancy things just to ship them. Elm is perfectly production ready as is, and beats any JS stack for me. Both in code quality and maintenance cost.
> This is FUD. For any normal web app you don't need that functionality, just use the built in "ports" concept to interface with JS stuff. The change was handled extremely poorly. I only knew one team using Elm in production at the time. They went from being huge proponents of Elm to recommending against it after the 0.18/0.19 changes and drama upended a lot of their work. There may have been a "right" way to do things under the new version, but breaking major functionality in a minor release without warning is a sign that you don't really care about your users. Changes like this require discussion, warning, and long transition periods. It was bad enough that they got it wrong, but then Evan doubled down by dedicating the opening of his next conference talk to mocking the users who were unhappy about the changes: this video The part where he mocks a commenter for asking "Is Evan killing Elm's momentum?" is weirdly prescient, given that these events ultimately did mark the slowdown of the Elm community. Elm development came to a near halt about a year later. > And it being open source means nothing stops you from forking it and adding your own native modules. Reason no one has done it is it's no need, and doing thinga that way would break the promises the compiler makes about no runtime bugs. I disagree. Maintaining an in-house fork of a compiler just to accomplish what could be done with past versions isn't a reasonable suggestion. The reason people weren't maintaining in-house
> You're saying a codebase of 5% JavaScript demands more JavaScript experience than a codebase of 100% JavaScript. A codebase of 100% Javascript does not usually mean 100% written by the app developer. If you are coding in react for some basic app, like some basic crud with react using existing backend with Firebase, it almost only require you to learn the some basics of react and Javascript syntax, and fill in the template. You can also use other modules by just follow their documentation when you need some extra functionality. However in Elm Ports we are required to pass async messages for everything which is much harder. I am OK with the boilerplate for the JSON encoder and stuff, but I have to wrap around my head for how to write a port for lots of basic web APIs. Port is hard even for people that familiar with Javascript. There are plenty of experienced Javascript programmers willing to dive into the source code of Elm to write native modules to avoid ports even. [LINK] In addition, even the 5% of Javascript will eventually leads to the full Javascript stack, where Elm, without an official recommend JS stack, feels more like additional choice as a part of the JS fatigue. Beginners ends up looking up on browserfy/gulp/webpack etc and figuring out a way to integrate Elm in. > Seems like the argument is Elm isn't ideal if you're not a programmer I program daily for machine learning, and I have used many programming languages. But Javascript is not the language that I want t