I just gave this talk at Lambda Days. It is kind of a follow up to “The Economics of Programming Languages” but I now have a more well-developed idea of how it might look to have a healthy relationship between authors, developers, and businesses when it comes to creating productivity languages:
Curious to hear what people think after watching. Thank you for your patience with me on figuring all this out, and I hope there are some observations in there that you might find interesting.
I really connected with the portion about the differences in how businesses are run. It reminded me of, if I remember right, a podcast I listened to years ago talking about family owned businesses and how most don’t last beyond 5 generations, except in Japan. The difference being that in Japan this led to the average adoption age being something like 26 (there’s a decent chance I’m off by a few years here). I wonder if this podcast was based off the paper mentioned, or possible related work(s).
On the topic of communicating with other parts of the business, this has worked well for me. It’s the 1 time I was able to convince a business to adopt Elm. My initial step was to convince my manager, who hadn’t written code in years, about the financial benefits of a rewrite (possibly a whole separate topic), and how Elm was a key part of this. There were later parts of this process that involved convincing both the CTO and fellow engineers. This required changing from talking about money to talking about the stereo typical things like “FP vs OOP”. I didn’t have to deal with the “is it dead” type question because this was 2019.
Most of the time I haven’t had this kind of success though. The biggest hurdle I’ve hit is who is or isn’t allowed to make significant changes, and the companies restricting this a privileged few. Somewhat relates back to the topic of how companies are run. I’ve had better overall experiences promoting things like Elm at smaller companies that aren’t looking to grow at all costs. The companies that are focused almost entirely on growth were more resistant to these types of discussions.
Possibly coincidentally I also read Backyard Coffee And Jazz In Kyoto, Japan today and between the 2 I have the urge to have my own small business that caters locally. Just need to figure out what that is.
I had some thoughts on the Elephant/Ant analogy, which is an intriguing way to describe things.
West coast tech companies have so much money, power and presence in our lives so elephants are such a force on the internet. A way of explaining that may be that the internet has made the world flatter - as in “The World Is Flat” by Thomas L. Friedman . In a flat cyberspace Ants do not have little spaces to hide in, everything is this big flat plane where being large is an advantage.
But then I wonder? Could that just be a feature of a nascent internet. The internet is maybe getting less flat, more complex and developing its own ecological niches. I would say AI is in a pre-Cambrian explosion right now, but if you think how many new non-AI languages have popped up in the last decade I think that even that is still undergoing its pre-Cambrian explosion.
Just like Ants Elm is productive and efficient and there is an ecological advantage right there. I think it also has traits that could give it longevity - it is ideal for pure domain modelling and therefore giving business logic a clean break from hardware/platform and consequently, potential immortality.
Ants are a very adaptive species, they ought to do well in ecological niches outside of web apps too.
I ran the transcript of the video through Claude and asked it to summarize the case + steel man the case against it. Do with it what you will (including ignore it), but I think the network effects point is particularly apt, and that they’re probably even stronger now with AI/LLM code generation and sites like v0.dev.
Here it is:
Evan Czaplicki argues that programming language adoption faces fundamental challenges that can’t be solved through technical excellence alone. His central thesis is that:
Non-technical business decision-makers are the ultimate gatekeepers of language adoption, not developers or CTOs
Current organizational models for language development (fragmented, in-house efforts) are inefficient and unsustainable
The solution is to create cooperative organizational structures inspired by long-lived Japanese businesses or agricultural cooperatives that:
He believes this approach would create a virtuous cycle where language authors, developers, and businesses all benefit and grow stronger together through cooperation.
The primary barrier to adoption of functional languages like Elm isn’t organizational structure but the fundamental value proposition. Businesses adopt technologies that solve their most pressing problems. JavaScript, Python, and Java dominate because they effectively address the needs of most businesses:
Even with perfect organizational structures, niche languages face an uphill battle against these network effects. The focus should be on expanding the use cases where functional languages demonstrably outperform alternatives.
Cooperative organizational structures sound appealing but encounter significant challenges:
The most successful language ecosystems (Python, Java, JavaScript) have thrived with a mix of corporate backing, foundations, and community contributions—not pure cooperatives. This hybrid approach provides both stability and adaptability.
The Japanese family business model and Danish cooperative examples, while inspiring, may not translate well to software:
Silicon Valley’s model, despite its flaws, has produced remarkable innovation precisely because it embraces change and creative destruction rather than stability and tradition.
OK, now ask Claude to provide a rebuttal to this steel man using Elinor Ostrom’s research on The Commons to address the Cooperative Models Problems.
You can also use the ProSocial processes to provide a rebuttal to point 3.
My understanding of Ostrom’s research was that she showed groups could address market failures/collective action problems (like pastoral societies overgrazing the commons or whatever) through culture, norms and sophisticated governing models. I’m not optimistic about Elm’s governance model (one burned out guy, massive vacuum below that) being particularly suited to meet those challenges.
I don’t think the fundamental problem is organization. I think the fundamental issue is Evan isn’t dealing with reality as it is. Instead he’s engaging in wishful thinking about what he’d like it to be – and shutting down/withdrawing when it’s not.
Like yeah, Elm is awesome and in a “just” world maybe Evan and his descendants would be set for life like a multi-generational Japanese family business , but unfortunately that’s not how it works.
It’s ironic because Evan clearly recognizes the value of being pragmatic (and acknowledges the ultimate business people adopters of languages are very much pragmatic, which I agree with), but is not at all pragmatic when it comes to people adopting Elm. Instead of meeting the market where it is or making incremental improvements, or recognizing the value of network effects in programming languages + doing a token release that advocates/CTOs can use to prove to their business stakeholders that Elm isn’t dead, he’s aiming for a wholesale reinvention of programming language economics. I hope it works, because I love Elm, but I’m not optimistic.
Ouch!
Far from the truth though. I won’t comment on one guys level of burn out as I have absolutely zero information on that, but there is a decent amount going on further “below” and I am certain of that.
AIs are good analysts but they lack the ability to have vision. I do agree with much of what the AI analysis says, it certainly does a thorough job of picking out the weaknesses. Weaknesses that we are pretty much already well aware of.
But it takes vision to move things forward. Elm already is a vision of how to take software engineering somewhere new. As evidenced by the works that have copied it, most often TEA, or tools like elm-review that are so much deeper than typical linters.
There is an inspiring amount of community activity on many projects including the Elm language server, Elm Janitor, Lamdera, Elm Pages, and on and on. Nathan said “governance model” and not the level of contribution / activity and through that lens…
I am about to start a new role as the lead architect for a modernization project with a very intelligent, creative, and open minded engineering manager over me (worked with him before). I will not be advocating for Elm. If Elm had had a token release every year over the last 6 years OR a release every 3 months over the last 2 years then I would plan to make an argument and, yes, it has everything to do with risk. I am spending someone else’s money AND the decision could hurt users. It is healthcare software. If the company ends up in five years having trouble hiring talent or applying modern tools that could benefit users then that will hurt patients. If the company goes out of business then that hurts employees. It isn’t just “evil” capitalists twirling their mustaches.
I have production experience with F#, Scala, Haskell, PureScript, and Elm along with significant hobby experience in OCaml. While I love other functional languages, the only language that I would ever advocate for in an enterprise setting is Elm because Elm would have the lowest risk if it had been actively attended to. I won’t re-iterate Elm’s great attributes. We all know them. It is why people who aren’t currently working in Elm still come here; most probably hoping for some word from Evan.
While I find this phrasing harsh, I must admit I am very discouraged by these talks about the economics of language development when they venture into novel territory. Generally people either innovate in areas where they have expert mastery or, during their novice phase, experience a paradigm shifting / defining observation of something not seen by those entrenched in the problem space. I am not getting the impression that either of those are the case. I heard a lot of interesting theory and history, but not an “a ha!” moment or a clear actionable solution with next steps. What is the solution proposed here? How is any of this made concrete? If there are next steps then what is it that gives us confidence that those steps will be successful in this particular space?
The truth is that these talks reduce my hope that Elm will find its way because it sounds more and more like the future of Elm is tied to or predicated upon Evan’s ability to apply ideas that are somewhat novel in the area of language development. I trust Evan’s judgment on language design above my own and most other people which is why I would never try to actually fork Elm. If I had a go then features would creep in until the language was a disaster because I lack the discipline to prioritize simplicity over power / coolness. However, regarding Evan’s ability to innovate in a non-language design space… 
Yeah - I have also been in architectural roles and passed on the opportunity to advocate for Elm and for similar reasons. You just know it will be shot down. Its sad to hear people being negative though, perhaps that will change when the next release is actually out.
Lamdera is open source and has had releases. elm/virtual-dom just got an update. Other elm/* packages have patches but you have to try quite hard to use them since they are not accepted as PRs.
It should be possible to put all that together and have an Elm compiler and eco-system that is not blocked on Evan. Upstreams patches to the originals and maintains backwards/forwards compatability, eventually dropping to just backwards compatability as new features are added, and ultimately finding its own way. No major rush to get there and see what happens with Elm 0.20.
But yes, some actual new releases might help to win the critics over and re-enable adoption.
Tooling was briefly mentioned (the Jetbrains/Kotkin story)
Has funding the language via tooling only been considered? If not, why?
From my perspective, this route makes more sense to me: businesses can and do invest there, but also people like me who value their time when programming outside of work.
I’m not talking about reinventing the wheel, I’m talking about developing/improving and maintaining IDE plugins.
Also, I have a hunch that a language with deep AI integration could be quite interesting and we can see that a lot of money is already spent on AI tools today (how will we program in 10-20 years?)
Also, due to its guarantees, purely FP seems to have a distinct advantage to explore the AI space IMO.
Goto (re)released the interview that Kris Jenkins did with Evan last year Elm & Open Source: What’s Next? and I found it interesting as I re-listened to it this morning to hear what I view as a progression of research into a product. In the interview Evan mentions speaking with other language builders about what does and doesn’t work for them. Then from this recent talk there’s mention of doing research on various ways to run businesses across cultures.
I think the continuation of research into how to fund a programming language while preventing
which Evan has spoken about before being a significant issue when the financial influence for a language is a corporation, I think that contradicts the following
That Evan is looking to find a way to make it sustainable for him to continue working on projects, including Elm, in a way that isn’t negatively influenced by people who are paying for feature creep.
I do not want to hurt Evan’s feelings, but it is sad but true. Nothing new. Same song for years now.
From the Acadia form:
Acadia is a language for describing database tables and queries. It can store algebraic data types, making it a nice companion to languages like Elm, Haskell, OCaml, etc. It works well with Sqlite and Postgres.
Meanwhile in F# (an OCaml dialect), storing algebraic data types is easy.
I hear you and it is a good point, covered by Evan and supported by all of our experiences, that the people writing the checks are several layers removed from the real value proposition. In end-user software the sales people often prioritize the check writers over the larger user group which leads to spending more time creating BI integrations, dashboards, reports, and management tools for executives than building features and fixing bugs affecting 95% of users.
However, the suits (or Patagonia vest wearers) are not paying for language feature creep because the executives, per Evan’s own argument, don’t even know what a language feature is (see the IT Crowd - Internet Bit)! 
They are paying for stability and risk mitigation.
I watched the talk. First of all: Evan, love you, love your work, but it feels like you’re trying to force a perspective on the world, and it’s preventing you from seeing the world as it is.
I’ve never made a language (well, not a real one), but as foundation software goes, frameworks are probably the next best thing. I was part of the founding core team and one-time lead dev of CakePHP, which is old enough to drink legally in the US, and apparently still gets about 13k daily installs. I was also the lead developer of AngularUI Router, which got around 1.3m weekly installs at peak, and was the architectural backbone of Ionic 1.x. Hopefully that’s enough to persuade you that my observations don’t come out of a vacuum.
There several foregone conclusions in this talk that are maybe not really that foregone.
The final boss of adoption is the non-technical business person.
Is this true in anyone else’s experience? Certainly not mine. If anything, it’s the other way around: technical decisions often constrain business people for years after the fact.
Now obviously, this is extremely off-putting to developers
It is?? Delivering 20% faster and not wasting extra time on tests?! Sign me up! I don’t understand this point at all. Further, as a developer, understanding how to align with business objectives is basic professionalism. If this is supposed to be humor—maybe it’s too dry for me.
I now have a more well-developed idea of how it might look to have a healthy relationship between authors, developers, and businesses when it comes to creating productivity languages
It may be well-developed, but that well-developedness is not articulated in the talk. You get up to the point of describing an idealized end state, abstracted away from the details of how people behave and think in the real world.
A better model for thinking about organizations than ants and elephants is The Starfish and the Spider, which addresses how your Danish dairy farmers managed to avoid the tragedy of the commons: by having a small, tight-knit community with strong shared values. This is the only context in which this approach works.
Other thoughts:
Silicon Valley is not the world. It’s not even most of it. Trillions of dollars in economic activity happen as a result of people doing quiet, boring work, far away from social media. Sometimes even quiet, boring work demands (and supports) its own language. Case in point: Erlang.
How do Python, Ruby, PHP, and friends fit into your paradigm of platform vs. productivity languages? Is there something unique to typed functional languages that prevents them from succeeding in the same way those other languages do, even absent a corporate overlord? That seems like the more pertinent question vs. comparing how brain-damaged Silicon Valley culture compares to some hypothetical alternative.
Traditionally, Open Source projects get widely adopted either by doing something difficult and useful, or by taking a strong position on something that people strongly identify with, or both (I would say Elm checks both boxes)
When they need to scale, Open Source projects are confronted with the reality that the only reason people ever do things is because they want to, and since there’s generally not much money on the table, project leaders have to figure out how to inculcate a value system into lots of other people, so that those people can act in the best interests of the project without micromanagement. This is also known as getting buy-in. Critically, this trade requires project leaders to give up some control over some aspects of the project.
Elm has quite clearly taken an approach so opposite to the above that it is almost the antithesis of it. In fact, one could argue that Elm’s approach to contributions, packaging, etc. make it an Open Source project only in a very narrow technical sense, and not in the conventional sense. THIS IS FOR VERY UNDERSTANDABLE REASONS WHICH I HAVE NO WISH TO REHASH—and I’m sure no one else does either. It still has to be acknowledged as a structural problem compared to how basically all other non-corporate Open Source projects operate.
It sounds like you’re trying to hack around this problem by cargo-culting a form of organization that is some kind of best-of-both-worlds hybrid. The reason you’ve had such a hard time defining and finding examples of it is because it runs counter to how people self-organize in the real world, with rare exceptions.
I believe your fundamental objectives (at least as far as I can infer what they are) can be achieved, but not with how you’ve framed the problem
If you really want to understand the problem, and how to solve it, spend less time studying corporate and political power structures, and more time studying the psychology of value. People who make different decisions from you aren’t less smart, they just operate on different heuristics.
Stability and longevity are laudable goals, but (1) a huge amount of the cost of most language ecosystems is managing the cascade effects of updates—Elm doesn’t really have that problem, and (2) given the current rate of change, assuming that programming languages as we know them will even exist in 5-10 years, let alone 10-20, is continuity bias
I started using Elm a few years ago to teach functional programming at school. Even back then, I was a bit hesitant because of the uncertain future of Elm. Every time I teach Elm, I really enjoy it — I’ve never came across another language that convinces me as much or is as much fun to use and to teach.
At the same time, it’s all the more frustrating that Elm’s usage is being held back by how — or rather if — it’s evolving. Just recently, a student asked me why we’re learning Elm even though it’s no longer being developed. I could explain and he was OK with that, but it’s a pity that I have to explain that. The fact that there’s a dedicated website (https://iselmdead.info) to reassure people that the language isn’t dead isn’t a good sign either.
As much as I understand and respect Evan’s arguments (not knowing him personally), I’ve now reached a point where I actually hope Elm doesn’t get another update — simply because everyone would fear that the next one might take another six years and therefore people are hesitant to use Elm, but out of respect for Evan, they’re reluctant to take over development of Elm themselves.
I wish Evan would either find a solution or hand Elm over to someone else — but unfortunately, I’m not optimistic that this will happen.
I’m placing my hopes on the future of Gren — and if Elm remains without updates, that could increase Gren’s chances.
I’m a little lost here. There’s mention of Evan finding a solution, which is what this talk and others have been about. Then there’s mention of not wanting Elm to update so that other languages have a chance, and that any updates to Elm could cause there to be a decrease in adoption while no updates are also leading to a decrease in adoption.
Hi, maybe I didn’t express myself clearly before — let me try in different words:
I think Elm is a fantastic language, and I find it really unfortunate that its adoption falls short of what I believe it’s capable of — and what it deserves. Evan made many excellent design decisions, and as a teacher who wants to introduce students to functional programming, I deliberately chose Elm because I wanted to use a purely functional language to fully explore both the strengths and the limitations of FP. Elm was by far the best fit for that purpose.
I would love to see Elm reach the level of adoption it truly deserves. But to be chosen as a language people need to trust that it will continue to be maintained and developed over the long term. Unfortunately, that trust just isn’t there right now, and I’m clearly not the only one who feels this way.
Some time ago, there was a discussion where someone argued that it would be pointless to release an update just to signal that the project is alive. At the time, I mostly agreed. But by now, I think it would have been better to at least ship small updates from time to time, just to maintain trust in the language’s future. A good language that evolves slowly is great. A good language that repeatedly raises the question of whether it’s “dead” — whatever that may mean in the context of a programming language — won’t earn people’s trust, and without that trust, it won’t reach its potential.
I would be very happy if Evan were able to find a path forward for Elm’s development, that also provides him with financial support. But unfortunately I’m no longer optimistic.
If I missed something in the talk or the text, I’d be grateful for a pointer.
Of course, I fully understand that Evan doesn’t owe anyone anything. He’s put a huge amount of work into Elm and made the result freely available. He has every right to develop Elm in the way he wants, and no one has the right to make demands or be upset.
Speaking for myself: I’ve invested hundreds of hours into developing teaching materials for Elm and have been checking this forum regularly for years, asking myself the question: Does Elm have a future, or should I start looking for a different language?
I consider myself an optimistic and patient person — but sadly, over time, both my optimism and patience have worn thin.
I’m probably not the only one caught in this dilemma:
On the one hand, Evan has done a fantastic job and I’m truly grateful for it and I have no right to make any demands.
On the other hand, I really wish Elm’s development felt a bit more active, because my own work depends on the trust people have in Elm.
Updates would certainly help Elm gain more traction, but I imagine some people would still be cautious — simply because of the long period without updates or visible activity.
Sorry if I didn’t express that clearly before.
You know, Elm’s philosophy was clear from the very beginning. All these things were communicated long ago. It’s just that it seems to me Evan wants to stay out of that “classic” OSS bubble and try different. He is a visionary and he is presenting those visions. That’s whats on the table. I guess it would be make more sense to be productive on those ones instead of forcing it into a corset it clearly doesn’t fit in.
From my standpoint I just can say that Elm should be a fullstack language and also have different compile targets (native, html, javascript). It seems to me being in the frontend/web only (where there are always new “shiny” things) takes away some big margin of potential adoption. Other than that, a lot of functional languages have failed adoption. Why ?
My question to you is: What exactly makes a language to be trusted on ? And is there a difference in a social context or in a business context, if yes which ?
Yes. I think Elm is not quite the right language for “general purpose”. That said there are things such as elm-posix that make it available as a general purpose tool for writing CLIs, and its also nice to work with in that context.
I feel that Elm is ideal as a mini language that can be embedded into other things. It is simple enough to create a Platform.program and embed it anywhere that NodeJS is running. That also gives you something that you can run in all the major cloud providers. There is an opportunity to grow a cloud ecosystem around Elm, and its even something I have made a few attempts to do.
There is morphir-elm which is a framework for expressing business logic. This is something I feel Elm is also well suited to, although perhaps no need for the framework. As a minimalist language which is also very strict on typing it is ideal for elevating business logic to a higher level abstracted away from the platform. You can force a domain model written in Elm to be pure, simple by defining the types to not allow side effects in their returns.
I also see an opportunity to embed Elm in stream processing code - such as Kafka Streams. Would likely require targetting the JVM rather than attempting to run as Javascript for performance reasons.
There are likely many more situations where Elm could be embedded as a really nice to work with language that helps developers focus on the real business problem and not the platform.
I think vision is what we are going to get, and not pragmatism. Therefore if we want something more practical it becomes up to the rest of us to do it. Unfortunately Elms quite closed development model means that is much harder to do than it could be. Yet still possible.
The way I think of it is like Linux. Linus is the visionary who develops the kernel and that is very tightly controlled. But there are many many distributions. That is what we need - an Elm distribution that takes care of the practicalities of interfacing the vision into what our real world needs are.
Throughout the course of this chapter I have been talking about the ways in which choices made by educators, foundations, governments, and private individuals can affect the potentially revolutionary changes in how children learn. But making good choices is not always easy, in part because past choices can often haunt us. There is a tendency for the first usable, but still primitive, product of a new technology to dig itself in. I have called this phenomenon the QWERTY phenomenon.
The top row of alphabetic keys of the standard typewriter reads QWERTY. For me this symbolizes the way in which technology can all too often serve not as a force for progress but for keeping things stuck. The QWERTY arrangement has no rational explanation, only a historical one. It was introduced in response to a problem in the early days of the typewriter: The keys used to jam. The idea was to minimize the collision problem by separating those keys that followed one another frequently. Just a few years later, general improvements in the technology removed the jamming problem, but QWERTY stuck. Once adopted, it resulted in many millions of typewriters and a method (indeed a full-blown curriculum) for learning typing. The social cost of change (for example, putting the most used keys together on the keyboard) mounted with the vested interest created by the fact that so many fingers now knew how to follow the QWERTY keyboard. QWERTY has stayed on despite the existence of other, more “rational” systems. On the other hand, if you talk to people about the QWERTY arrangement, they will justify it by “objective” criteria. They will tell you that it “optimizes this” or it “minimizes that.” Although these justifications have no rational foundation, they illustrate a process, a social process, of myth construction that allows us to build a justification for primitivity into any system.
He goes on…
Another example occurs even when attempts are made to allow students to learn to program the computer. As we shall see in later chapters, learning to program a computer involves learning a “programming language.” There are many such languages-for example, FORTRAN, PASCAL, BASIC, SMALLTALK, and LISP, and the lesser known language LOGO, which our group has used in most of our experiments with computers and children. A powerful QWERTY phenomenon is to be expected when we choose the language in which children are to learn to program computers. I shall argue in detail that the issue is consequential. A programming language is like a natural, human language in that it favors certain metaphors, images, and ways of thinking. The language used strongly colors the computer culture. It would seem to follow that educators interested in using computers and sensitive to cultural influences would pay particular attention to the choice of language. But nothing of the sort has happened. On the contrary, educators, too timid in technological matters or too ignorant to attempt to influence the languages offered by computer manufacturers, have accepted certain programming languages in much the same way as they accepted the QWERTY keyboard. An informative example is the way in which the programming language BASIC has established itself as the obvious language to use in teaching American children how to program computers. The relevant technical information is this: A very small computer can be made to understand BASIC, while other languages demand more from the computer. Thus, in the early days when computer power was extremely expensive, there was a genuine technical reason for the use of BASIC, particularly in schools where budgets were always tight. Today, and in fact for several years now, the cost of computer memory has fallen to the point where any remaining economic advantages of using BASIC are insignificant. Yet in most high schools, the language remains almost synonymous with programming, despite the existence of other computer languages that are demonstrably easier to learn and are richer in the intellectual benefits that can come from learning them. The situation is paradoxical. The computer revolution has scarcely begun, but is already breeding its own conservatism. Looking more closely at BASIC provides a window on how a conservative social system appropriates and tries to neutralize a potentially revolutionary instrument.
BASIC is to computation what QWERTY is to typing. Many teachers have learned BASIC, many books have been written about it, many computers have been built in such a way that BASIC is “hardwired” into them. In the case of the typewriter, we noted how people invent “rationalizations” to justify the status quo. In the case of BASIC, the phenomenon has gone much further, to the point where it resembles ideology formation.
Complex arguments are invented to justify features of BASIC that were originally included because the primitive technology demanded them or because alternatives were not well enough known at the time the language was designed.
One might ask why the teachers do not notice the difficulty children have in learning BASIC. The answer is simple: Most teachers do not expect high performance from most students, especially in a domain of work that appears to be as “mathematical” and “formal” as programming. Thus the culture’s general perception of mathematics as inaccessible bolsters the maintenance of BASIC, which in turn confirms these perceptions. Moreover, the teachers are not the only people whose assumptions and prejudices feed into the circuit that perpetuates BASIC. There are also the computerists, the people in the computer world who make decisions about what languages their computers will speak. These people, generally engineers, find BASIC quite easy to learn, partly because they are accustomed to learning such very technical systems and partly because BASIC’s sort of simplicity appeals to their system of values. Thus, a particular subculture, one dominated by computer engineers, is influencing the world of education to favor those school students who are most like that subculture. The process is tacit, unintentional: It has never been publicly articulated, let alone evaluated.
~ Mindstorms: Children, Computers, and Powerful Ideas by Seymour A. Papert
I think a similar thing is happening when we talk about the difficulties we’re seeing in the adoption of Elm. The problems weren’t solved back then and I see no reasons for them to be solved now. JavaScript is the new BASIC. And entrepreneurs, instead of teachers, are the forcing functions of a subculture that is influencing the world of software development via a process that is tacit and unintentional.
But that’s when we look at programming in the large and try to make big changes. I think as a small community we need to focus on our small circles of influence. Slowly that circle of influence can increase such that over time it snowballs into something bigger. A good place to start is with new developers and developers who already see the need for the change we seek rather than trying to change the old guard. But we have to give them confidence in the new system if they are going to stand by Elm. I think people are afraid to push Elm because they feel that the Elm ecosystem doesn’t have their back. They’d essentially be out there on their own championing a technology that doesn’t champion itself.