Heads up! This post has some claims that lack citations. The power dynamic here is such that I'd rather be dismissed to generally no effect than to put the heat on some developers without a platform who write internet posts that I think are wrong.
Anyway, let me frame up this discussion a bit:
I am a member of the Elm core team. I made a significant outlay of personal effort to reach this level of contribution, so I think it’s reasonable to claim that I understand what it’s like to care about a project and desire for it to succeed.
A lot of the online lobbying directed at us for changes in prioritization is based on the idea that Elm is not successful unless its community is growing faster now than it was some amount of time ago. This commentary rarely explains how the poster personally defines “success” for Elm, so I have to assume that adoption and success are one and the same in their mind.
For Elm, we reject the idea that adoption is success or even a very good reflection of success. Elm seeks to be an exceptionally good programming language and platform for building front-end web applications. It is successful to the degree that it does that. Major, concrete steps toward this goal will not always result in community growth, especially under Elm's long release cycle. That is okay!
As a final thought, here is an illustrative example of my confusion: if we grant that adoption and success are related, then what does it mean to be the most popular and thus most successful project? If Elm were the most-used front-end technology, what prize would the Elm community win?
So. What do y'all think is the cause of this apparent linkage in the mind of The Developer?
I think that if I can better understand why people feel this way then I will be better at explaining how to measure Elm's success to the Elm community.
If you would like to share your thoughts anonymously you can email me at hello@lukewestby.com.
Top comments (16)
I think it's a human default. "Who's the most popular?" was a question of major significance in grade school, and I don't think we outgrow the instinct to give it gravity.
In Elm's case in particular I could see someone interpreting "Let's Be Mainstream" to mean "Let's Be The Most Popular." It's hard to watch the first 60 seconds of the talk and conclude that's what he meant, but if I only knew the title and hadn't watched the talk, I might mistakenly assume "more adoption is better" was the central theme.
I've started reading "Out of the Tar Pit," (OOTTP) by Ben Mosely and Peter Marks. On page 3, there is this quote from Tony Hoare in his Turing Award speech: "... there is one quality that cannot be purchased ... -- and that is reliability. The price of reliability is the pursuit of the utmost simplicity."
The guarantees given by Elm's type system and compiler make the design and construction of reliable code much easier than with many competing frontend languages. By that measure, Elm is successful.
Another point from OOTTP. The authors identify complexity as the main source of trouble in developing software, and they go on to say that the main source of complexity is program state. Then, on page 8, they declare "As a result of the above [arguments] .. the more we can do to limit and manage state, the better. This is what Elm does via the Elm Architecture, and it is one more reason why Elm is such a good tool for building web apps.
NOTE: I have seen reports of use by Elm at Amazon, Ford, and Microsoft. It would be worthwhile to understand why groups at these companies have chosen to use Elm, and to understand what this may mean for the future.
The software industry is continuously growing (estimated to be doubling every 5 years) which has resulted in software being a very fashion driven industry which means that popularity has many prizes associated with it.
Popularity gives a wider ecosystem of packages and training which means that developers don't have to start from scratch when solving problems which has an accumulative effect on reducing the cost of building a wider variety of applications using that tool.
The risk associated with adopting a popular tool is lower for an organization because of the support and training ecosystem around it and the availability of people familiar with the language (external contractors or full time).
This results in jobs across a variety of organizations from small start-ups to large corporations being available using the tool in a wide variety of locations where skills in the tool are valued at the usual market rate.
For someone that is going to invest their limited time in learning a tool, success of that tool is them being able to use that tool in their job without being the one that has to 'champion' it and take on the personal risk of use of the tool being blamed for the failure of a project.
This doesn't mean the tool has to be the most popular, but there is a minimum level of popularity required to maintain this ecosystem and thus maintain the value of the skills that users of the tool have invested their time in learning.
RE this question, let's look at a couple of examples, metrics, etc.
(1) Haskell. As I understand the story, its growth rate was very low for a very long time. That gave those involved in creating the language the time to reflect deeply on the core ideas. The result is a language of uncommon power and expressiveness. One could argue that Elm is going through a somewhat similar albeit more compressed evolution. IMHO that is a good thing.
(2) Javascript. It was developed very quickly and it also became extremely popular quite quickly. That fast design period, however, is at the root of the many attempts to add to and modify Javascript so that it will better meet current needs. But a retrofit, whether it be to a language or house or piece of machinery, will seldom give a better result than a more thought-through initial design. I would argue that sometimes slower is better. (Consider the hare and the tortoise). In our world, fast goes along with popular, but there is a price to be paid for this.
(3) Angular I, II, III, ... [Disclaimer: I've been there]. These frameworks were pumped out quickly, had great initial success and adoption. IMHO the result was not so pretty, and left a lot of folks exhausted as they went from Angular N to Angular N + 1 and then possibly to something else entirely (in my case, Elm). Maybe slower and more thoughtful would have produced a happier result.
(4) Popularity is one metric, but there are others, among which are simplicity, reliability, refactorability, expressiveness, and influence. Relative lack of popularity means that by one metric thing X is "lower ranked." But is that the only metric? Is it the best? Or does it depend, e.g., on what you are trying to do. Different strokes for different folks: it is OK to follow the beat of a different drum.
If nobody uses your project, it's self-evidently a failure. The logical inverse of this axiom is that if everybody uses your project, it's self-evidently a success. This makes intuitive sense, but doesn't automatically follow: popularity might come at the expense of the core goals the project initially set out to achieve. Like Kasey said, there are multiple metrics for success.
Success is linked to both attaining a goal and to higher social status. Popularity is more in the higher social status domain.
The main advantages of popularity is the amount of brainpower that comes with it.
The main advantages this brainpower brings are:
I would like to end by saying that popularity has its costs too. You can move quickly with a small SEALS team, not so with a large army. With larger popularity, change becomes costly. Another huge cost of popularity is the large volume of requests which can induce burnout in a small core team if they are not handled optimally.
I think popularity is one measure of success, but by no means the only one and not necessarily even the most important. For example if I release a product to a small market, and nearly everyone in that market uses it, but in general nobody has heard of it... is that product still not successful?
In Elm's case, it is currently in a limited market. Very few webdevs seem to want to use anything other than component-based frameworks. The influx of new webdevs learn Javascript and naturally transition to one of those. Because it is the vast majority of what they find guidance for. And when something is new to you, you don't want to try something on the fringes and risk it fading into dereliction.
It usually takes a long term project to expose the weaknesses in a particular framework. Anyone can make something neat, live with it for a short while, and make a blog post about how awesome it is... long before they start to get worn out on the maintenance burden from accidental complexity. And when you can find literally hundreds of such posts, how could you believe differently until experiencing the bad parts first hand?
I use Elm. I consider it a really good platform. I recommend it all the time. Any product has some issues, but overall it is the best front end dev experience I've had so far. My users love it too, because we can generally repro and fix things quickly. (As yet, we don't keep bugs on our backlog for more than 1 sprint on our Elm projects. We don't get a lot of them reported, and when we do they are frequently fixed and deployed same day.)
Oh, I love Elm! Anyway, success depends on whether something achieves a goal. So, if Elm's goal is
Then that's totally cool, but how do you know if you're succeeding at it? I'd propose identifying things you can measure which indicate how effectively Elm achieves this goal. Note that popularity does seem like a reasonable metric because we'd expect that if it's exceptionally good at this, then more people would want to use it for this purpose. Given the specific hurdles of Elm (it looks and feels different from the languages most people know), conversions could be a better metric. Eg how many people that try Elm for a week continue using it for their front end projects. Or perhaps twitter sentiment analysis or something.
Anyway, if someone then points at popularity or market share, you can point them to a page saying "this is our goal, this is how we're measuring, these are our numbers over time." And I think that will make total sense to anyone and also help guide your decisions. If you do it, then do be careful about gaming the metrics, b/c success isn't actually excelling at these metrics, it's achieving what the metrics are expected to indicate.
As a single point of data for you: I honestly thought you were talking about the existing email client until you mentioned programming languages.
I was thinking about how popular something is being measured by how many people have it installed on their systems by default, perhaps even without their knowledge.
A lot more headaches :-D