“What is Success?” by Evan Czaplicki

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

> 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. Wow, that was hard to watch. He takes people being passionate about Elm and discussing potential issues and mocks them. If I was a proponent of Elm that felt uneasy about its direction at the time, this would have made it easy to walk away from.

I believe Elm took some major missteps. Despite doing so many things right with the initial designs (and still one of the best designed front-end experiences) it never grew much beyond the early adopters and it basically remained a fun hobby language. I criticized the basic lack of communication and the infrequent updates in r/elm (I believed these infrequent updates were going to kill the momentum of Elm). I was concerned that it made the language seem stagnant. Immediately, after posting it was clear it was a major concern by others as well. So what did Evan do with that criticism? He spent the opening part of his European talk mocking it [0]. I didn’t take it personally, but it illustrated the kind of mindset Evan has. A good leader would have asked questions about why many feel that way and would have instituted a process for more frequent updates. It became clear to me, outside of being brilliant at designing Elm he is not the person to take it to the next level of adoption. If it’s not moderately adopted it won’t make sense recommending it for any production project, even if it does many things right. To me it feels like (sadly) Elm will just be a hobby project despite what it could have been. [0] ▶ this video

Language, its community and development model is a reflection of its creator and his philosophy. So Without meeting the creator Guido, through language and its community I can see is very humble and care about things besides solving computer science problems. May be this is one of the reasons of success of Python and its community which is open, humble, friendly and inclusive. In my startup we have been using Python as one of the primary development language, and thanks to its community and Guido, we will continue to do so in time to come. I recently watched a talk by creator of Elm language [1] [2] who is trying to create similar community like Python, I will try it besides lisp, since I like the ethos of Python like community and obviously PEP-20 [3]. From my whole team thanks to Guido, and Python community. [1] link [2] ▶ this video [3] link

> 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