Evan's Presentation at Swedish Meetup

Request Feedback
21

You don’t have to ask, and I’m at a loss as to why everyone thinks you do. If Evan doesn’t like what you’re doing all I can see happening is him asking you (or whomever does it) to either slightly change how you’re communicating it.

22

Regarding some of the comments above…I think those are, in their essence valid concerns, and I’m sorry that you guys, or “we as a community” have had those challenges.

Again, I in no way wish to invalidate the essence of what you guys are saying. Those points are unfortunate indeed.

Nonetheless, many of the things you guys have said (valid as they may be) seem to paint a kind of damning picture of Evan’s leadership and/or Elm as a project, if not fleshed out with more of the context. I imagine you guys are likely fully aware of all the context I’m about to give but I’ll write it anyway for those who might read the thread and not be aware.

I imagine that more than anyone, Evan (the designer of Elm) would like very much to see those issues resolved, or to not have had them at all.

My understanding based on The Hard Parts of Open Source, from five years ago, is that Evan found it difficult to find people who had the required spare time and technical knowledge and shared style of working and who shared the design goals for the project, and who were also willing to endure the difficult challenges of working publicly in an ecosystem where negativity and drama are common. People tend to prioritize their personal interests rather than consider all the interests of all other users of Elm and also people often seem to engage in open source with a sense of entitlement. Also drama is incentivized in forums since that is more exciting and therefore gets more attention. So it’s difficult to find people to do that work in that environment with the required skills and characteristics unpaid. Please correct me if I misrepresented Evan’s presentation (most of the choice of wording/phrasing here is mine, but I tried to convey the essence of, or at least part of the message as I understood it).

What I think is particularly relevant in that presentation is his point that all this takes a psychological toll. In my view, the infinite and relentless demands of this type of project seem like the perfect recipe for burnout and that would take time to heal.

Evan did do a pretty good job of setting expectations 4 years ago where he said in his roadmap:

even in the wildest version of success, I wouldn’t expect the language or core packages to change very much. Maybe two or three years down the line it could reveal something that’d be good to fix up, but I don’t really foresee notable changes right now.

I plan to open source the final results of the broader exploration under the normal BSD-3-Clause that I use, but I am working more like when I was doing my thesis in 2011 and 2012: Put in a lot of serious work in a safe/comfortable work environment with healthy feedback loops, and publish when you are fully ready to present and defend your technical results. The broader exploration still has many difficult open questions that I have not answered for myself (let alone everyone else!) so I expect the remaining work to take a while longer."

Evan also wrote the following in a Nov. 2021 status update

I realize that this working style clashes heavily with the Silicon Valley style of using hype and reckless urgency to achieve GROWTH and DOMINANCE, but I needed to make some changes in my life to keep sane. I appreciate that these changes have implications for people with bosses or consulting clients who want the “corporate open source” style of emphasizing marketing and customer service, so I very much appreciate your patience with my present working style and hope you might find these early results interesting.

So there is an argument to be made that he has been fairly clear about what he is doing, and I think the idea is to create an open source Elm for the backend and actually resolve those issues that have been raised by building a hosting service that could provide the funds to pay a team of qualified people to work on developing/maintaining Elm.

So it seems there is a plan that’s being executed to address the raised issues and its encouraging that he has something that’s far enough along that he’s beginning to speak to small groups about it at this point to get feedback before he releases something to the general public.

8 Likes
23

Some say TypeScript already won in the market of languages to replace JavaScript.

I think elm would have a had a shot if it evolved to isomorphic/full stack general purpose language, maybe 4 years ago.

I don’t think most teams considering TypeScript would be willing to give up on isomorphic requirement.

1 Like
24

Does Elm project accept donations to support maintenance and development? With enough companies and people the project could be financed that way.

See for example Zig language:
https://ziglang.org/zsf/
https://ziglang.org/news/2024-financials/#2024-financial-report-and-fundraiser
https://ziglang.org/news/announcing-donor-bounties/

2 Likes
25

@ThrashAbaddon checkout Where is Elm going; where is Evan going as this question very recently came up in there.

26

That is fantastic that they are open and transparent about the money side of things and publishing this information. Interesting also that they are raising enough money to pay contractors to do some of the work.

4 Likes
27

Thank you for your response. I can sense but not see the exact path through how either a desire for profit or desire / belief that engineers are fungible resources factors into this conversation.

Replaceability of parts and part cheapness does not immediately equate to cheap replacement otherwise it wouldn’t have cost me over $400 to replace a $5 car part all those times. :rofl: New employees must learn the domain, the culture, the codebase, the HR practices, etc. so that learning Elm becomes one of many unavoidable onboarding costs. I believe the Elm decision pays for itself in less than a year so that it would only negatively factor if the business had an already unhealthy / inefficient turnover.

I believe a business making rational grounded decisions to be profitable and stable through fungibility of staffing resources would choose Elm so long as the business makes its profit through the development of a fairly competing software product. I see no issue for the selection of tools like Elm with a company thinking of engineers as costs and I have no issue with being a cog in a machine that provides a valued good or service. On the other hand, we should completely disregard from this conversation businesses that

  • Compete in their market through mergers and acquisitions or anti-competitive monopolistic practices.
  • Only interested in shareholder profits which shifts the focus away from product development towards accounting shell games. Companies will cut into bone and muscle along with the fat for a good quarterly or annual showing at the expense of the long term.
  • Make profit through CFO activity such as investing in other companies / real estate.
  • Etc. etc.

Perhaps the key is that I divide businesses into several broad (and oversimplified :smile:) categories

  • A. Change averse and/or conformist and/or toxic and/or interested only in shareholder profits and/or fail to show evidence of being logical actors.
  • B. Businesses willing to use Elm in its current state because they see the brilliance of the language and the strength of the community.
  • C. Logical, well intentioned businesses that would choose Elm but are, in my opinion, justifiably afraid to due to PR silence from the creator. Businesses that wish to profit but do so through delivery of a valuable product.

I suspect that our difference of opinion may stem from my belief in the existence, size, and importance of group C. I think that group is >= 5% of businesses and I think that is a significant minority worth consideration. I don’t want to waste any of my life lamenting the existence of group A.

However, perhaps I am just naïve to belief in group C.

Analytic philosophers sometimes disambiguate propositions with primes / tick marks and other times use a lowercase letter for a narrower proposition and an uppercase letter for a broader or stronger concept.

So how about this? Elm

  • The language qua compiler and a language specification is one of the most stable languages. Certainly about 10x more stable than TypeScript.
  • The Language considered as an identity traveling through time lacks a stable future because there is scant (not zero, but insufficient) evidence supporting belief in its future existence as it exists today.

Given a lack of transparency on the thinking on the next iteration of Elm I have reason to be worried that language features / capabilities present in 0.19 that Evan or other leaders have openly derided may be removed for the next iteration. For example,

  • There was a comment that Optics (Lenses, Prisms, Traversals, etc.) would be made illegal if they could be made illegal.
  • There has been negative sentiments expressed about Task.
  • Negative sentiments expressed about functions in Msg or even functions as the Msg.

So if start a project today I have to worry that decisions I make based on the state of Elm today may be entirely invalid in six months. Basically, I need a :rainbow: telling me there won’t be another language feature flood and that the next version will have minimal breaking changes.

Also, the language may be stable but the environment in which it runs is not! That is why we want regular updates. For example,

  • A CPU architecture, like M* ARM chips, comes along such that the compiler needs an update to work without emulation.
  • Web Browsers are fickle.
    • If Chrome decides to implement a DOM optimization algorithm that speeds rendering by collapsing unnecessary divs then the Elm virtual DOM implementation blows up. We’ve had to council customers to turn off browser extensions due to this very problem. This is a real problem for us.
    • Or there is a V8 implementation change that poses a problem for emitted Elm code. Recently Firefox reduced its max stack size which forced us to make changes to our code due to algorithms or function signatures that caused a stack overflow. The code worked before. Browser changed. Then it it didn’t.
  • Web standards evolve.

Regular releases assuages any anxiety that Elm can weather environmental changes.

So I absolutely agree that Elm is incredibly stable in small but not stable in the large.

Thank you for this conversation. I appreciate your response.

5 Likes
28

I completely agree, but when you’re looking strictly at the numbers an engineer is labeled as a cost and generally speaking, in the US at least, workers are considered easily replaceable. The reason your car parts cost so much is you’re paying for both the part and presumably labor. If you were running a business you’d be buying those parts in bulk so they’d cost closer to $2-3/piece instead of $5 and you’d hire employees and pay them as low as you can bargain.

This brings to mind Boeing, who went from being an engineering driven company to a profit driven one.

I think we all both agree here! I haven’t yet figured out how to best communicate to a decision maker who falls into group C. Somewhat leading into your point about language stability, roughly 4+ years ago Evan stated (paraphrasing) that “if you like Elm as it is today, it’s what it’ll be for the future”. To those in the C group, to those looking to start a project today, there’s 4+ years of proof that Evan has held to his word.

I could still see someone arguing here, but then we’re getting nit-picky and talking in-person (or at least in real time with voice) might be the only way to resolve the tiny concerns.

This did happen, and the compiler was updated within weeks of the brew developers saying they wouoldn’t be supporting the (at the time) old version of GHC that was required for Elm on Macs in roughly 2 years time. I.e. they gave Evan 2 years to take action and he did within 2 weeks.

They are and do, but they’re also very careful to maintain backwards compatibility. So much so that you can run the following

var obj = { a: 5 };

with(obj) {
  console.log(a);
}

and it’ll run perfectly fine despite no one I know of having used this syntax in the ~15 years I’ve been doing web development. Elm compiles to ES5, meaning it should be fine for decades to come. I’d argue that it’s not web standards that change, but JS frameworks that change. New web standards do come, but it’s relatively slow. There are still dozens of standards that were “the hot new thing” when I started my career that still haven’t been implemented in all browsers.

I’d also say that more generally speaking most companies aren’t needing to adapt to all of the lastest features. There are still companies running Flash, running on Windows XP, running PL/1 mainframes. I can literally look out my window now at a 160+ year old financial company running a PL/1 mainframe that’s in no hurry to update. Up until 5 years ago they were still using IE for their sales team laptops.

I feel like I’ve started to ramble a bit. I think my point is, if I had to sum it up, that Elm meets the needs of most companies in the world that need to build a web site/app. There are outliers, as there always are, but the real holdup isn’t Elm IMO.

4 Likes
29

Lots of new features have been added to the web the last decade. Most of them are completely fine to call from a port in Elm, and I have not felt any urge for “what if this was possible to do in Elm?” Even WebSockets feel completely fine to call from a port, in my opinion. Not much JavaScript code needed, and I typically just have one WebSocket per app.

I also agree that most apps are “fetch data with HTTP and display in a UI” which Elm does very well.

But some features are not really possible via ports, either because they are pure functions and it would be infinitely nicer having synchronous pure functions in Elm too, or because they need integration with the virtual DOM.

  • Intl. Formatting dates, numbers, currencies, etc. in different locales. Sure, it’s possible to implement in Elm anyway, but it’s a lot of code (bundle size) and a lot of locales to maintain.
  • String unicode normalization. Also possible to re-implement in Elm, but big bundle size and yearly maintenance.
  • Regex unicode flag. Unicode again! This time, not possible to re-implement in Elm, without re-creating a whole regex engine. (There are more regex flags, old and new, that are useful too. I know that there’s a “use elm/parser” saying, but I think since elm/regex exists it could just as well all of its useful features.)
  • <dialog> showModal(). The native <dialog> finally has good browser support, and is great for accessibility. It’s just a bummer that using it as a modal requires calling the .showModal() method in JavaScript. I think it’s a missed opportunity for elm/html to simplify that.
  • Prediction: View transitions. Finally a nice way of doing animations?
  • Prediction: Navigation API. Finally a way to stop fighting the browser’s back button?

Imagine having to make these excuses: “I know that site X does this, but sorry…

  • …we can’t make such animation because Elm”
  • …we can’t fix that back button bug because Elm”
  • …we can’t support searching using characters in that language because Elm”

(Where “we can’t” means “we can’t unless [list of potentially deal-breaking caveats]”. Also note that “because Elm” used to be “because browsers” back in the day.)

8 Likes
30

Is copying the dependencies locally and adding the necessary functionalities as kernel functions what you consider to be ‘deal-breaking caveats’?

31

Thank you for your well thought out response! I think we all agree on most (or all) of the larger points with differences coming down to matters of degree.

Point taken and well spotted. I am just being nitpicky here but internal software has a lot more latitude because they can control hardware, operating systems, and software updates. When I said Enterprise I was also thinking of businesses developing products for end users and other businesses. Even obsolete or abandoned platforms (which I am not saying Elm is!!!) can be generally used

  • :green_circle: Very safely when an internally developed ERP or other internal software since you have absolute control. People grumble about the outdated software and it becomes a bit of a unifying joke in the company (different departments may have tension but everyone agrees that DOS software is such a pain in the @$$).
  • :yellow_circle: Fairly safely when the product is the sovereign application / the principal application users use to do their job. In this case the importance of the software is often sufficient to justify the older hardware / software.
  • :red_circle: Problematic when the software is delivered to end users or other businesses AND it is just one of several other applications users need to do their jobs.

You were responding to my ramble so that’s not on you. :rofl:

32

@rupert Thank you for your work on elm-janitor! Both your work on elm-janitor and yosteden’s work on the Zokka compiler alleviate anxiety regarding existing software written in Elm.

In my opinion, if the community does some work and that work is still called Elm and is blessed by Evan then magnificent! It is my firm belief that the name and Evan’s blessing are required to avoid creating Yet Another Functional Language (YAFL).

I am sure someone can point out how the Elm case differs but I look to things like:

  • OCaml (Bucklescript) → ReasonML → Rescript

where the branding, messaging, and goals shifted in ways that I think damage/damaged adoption.

If I am a CTO and my staff engineer comes to me proposing some teams be allowed to use functional language X and I see this very uncertain language progression, then I am going to think to myself

(Sigh) Those functional programmers just cannot get their $hit together. This is clearly a sign they are more interested in perfecting language design than getting real work done and living with a few minor warts here and there so that we can all get on with the business of the business. Figures coming from a bunch of math-y people.

33

For businesses I think this is less of a concern than we might think. Most businesses are slow to change their tools. I’ve found that it’s mostly the extremely young companies that are trying to be on the latest features. Once they get past 7 or so years old they tend to be settled in their ways. I worked for a manufacturer around '06-'10 that was still using DOS to run some of their machines. Not long after that my girlfriend (now wife) worked at an international travel company that was using DOS to manage and book flights. Even as recent as a couple months ago I went to Costco and found they’re still using DOS for their inventory management! The Game of Thrones books are also written on DOS.

There are definitely exceptions, localization being the largest I can think of, but generally speaking I’d argue that idea that we always need to be using the latest is driven more by companies wanting to sell you more than us actually needing that something new.

I definitely see this in my own life. My desktop is mostly 11+ years old, and will never be able to run Windows 11. I did replace a a few parts around 3 years ago because the hard drive broke, but otherwise it runs perfectly fine. My laptop is a little over a year old, I expect it to work for me for around 8+ years. My wife is currently looking to use my 2nd gen Kindle, with the hurdle being that it can no longer connect to the internet because it uses 2G, otherwise it runs perfectly fine.

Maybe I’m an old man at heart, I’m nearly 36 so I’m not yet old in age. Maybe it’s because I spent my early life on a rural farm with amenities closer to that of someone living in the 1960’s than the '90s. Maybe it’s having some of my family living rural, with little access to a major city. I’m not sure where my biases come but, I’m definitely biased towards Evan’s approach of taking things slow, much slower than the pace of Silicon Valley, New York, London, or such.

5 Likes
34

I’ve often felt myself thinking/feeling

(Sigh) Those functional OO programmers just cannot get their $hit together. This is clearly a sign they are more interested in perfecting language design resume building than getting real work done and living with a few minor warts here and there something they didn’t invent themselves so that we can all get on with the business of the business. Figures coming from a bunch of math-y self-focused* people.

*people tend to not like the word selfish, but there’s ways to use it that aren’t negative

2 Likes
35

This is true, it would need to be called a different name. Zokka is already a different name.

36

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.