this sounds exciting, but I wonder. How closely linked is Elmish to Elm?
In theory Elm is just such a fascinating project... if it was not held back by the people developing it.
In theory Elm is just such a fascinating project... if it was not held back by the people developing it.
* Elmish (F#) repo - https://github.com/elmish/elmish
* The Elmish Book (... remarkably good) - https://zaid-ajaj.github.io/the-elmish-book/#/
* Fable compiler - https://fable.io/
The F# community is very friendly (sub-communities as well), and there are plenty of good opportunities to contribute OSS work across any skill level.
Phosphor isn't hiring right now, but we will begin a search for FE/interface engineers soon. oliver@phosphor.co for anyone interested.
PureScript may be worth a look, it’s got several features that were rejected by Elm devs: typeclasses, ability to publish modules that use FFI to JS, runs server-side, etc.
He wants to run his own project his own way.
There's a small but dedicated residue of people who just can't stand being told "no" and go around crapping on the kid whenever they get a chance.
I get it. You don't like Evan's project management style. Move on already.
- - - -
The fact of the matter is that he's a person who took his thesis, made it into a product, and got traction in the real world. People have used Elm to make things. Things that go.
How many of us can say the same?
And that's before you get to all the fascinating and as yet still-too-obscure things that the OP talks about. Things that are in part a little more widely known and understood thanks to Elm project.
I remember when the Elm team first decided to lock down the Elm compiler, so that only the team in charge had special privileged access to modify it. I thought, "wow, this looks like a bunch of people who don't want to collaborate, who want to take their ball and tell others how to play with it, really putting the 'dictator' in BDFL." and you know what? that's fine. I don't harbor anything against them as people. But that left a permanently bad taste in my mouth and I'm unlikely to ever trust that group or a project they're managing.
You're entitled to your opinion, of course, and you articulated it well. But again I see it as another example of someone not liking being told "no", no?
Obviously Elm is his passion project, that's fine. But nobody who locks down their compiler on a supposedly "open source" project can actually seriously expect others to engage with that in good faith.
Furthermore, the absolute state of just trying to modify Elm to be more fit for purpose is horrendous. Every time I see a parallel implementation or a fork, the author has to bend over backward with platitudes to placate the Elm masses and ensure them that this project isn't trying to "split the community," which is a nonsense idea to start with imo.
It feels cultish, on top of a project that is actively hostile to people who want to use it any way other than how the BDFL has mandated its usage. If you want to say the problem is with the users, that's fine, but that's exactly the attitude keeping me from ever engaging. I personally think the problem is with the people who want such fine control over their technology and community, as opposed to understanding that they can really only shepherd their implementation. That's about as far as their reach rightfully extends.
EDIT: also, the fact that they aggressively lock down their compiler and have such hostility to anyone working in parallel is imo the definition of "holding it back"
My complaint isn't that you or anyone doesn't engage with Elm, that's your prerogative, of course.
My problem is that a small segment of people do engage with it whenever it comes up to smear the project in general or Evan in particular for nothing worse than wanting to run his own project his own way.
He's not an ogre? I mean here he is, look, he semms nice enough to me? "The Economics of Programming Languages" by Evan Czaplicki (Strange Loop 2023) https://www.youtube.com/watch?v=XZ3w_jec1v8
What I usually see are warnings about what happened to the project and how it is run, mostly targeted to the unaware. This is a sign of respect to people's time before they waste it on something that might disappoint them when they get to know the details.
Look, I get it, I'm still sore about Google Feed Reader, 'member that?
But enough is enough. It's old news. Get over it. Etc.
It's like if every time someone mentioned Caddy server there was someone bringing up that time Matt Holt put that header in and pissed off a bunch of people. Life goes on. We forgive and let things go.
It's high time for folks to forgive Evan for his mistakes. I mean, he's very young still, eh? Cut the guy some slack already?
When I propose a tool to my CTO I couldn't care less about the project's leadership personal choices.
Mature engineers think in terms of ROI, dependability, bus factor, predictability, funding, mind-share, hiring ease, license, etc.
But it would be naive and unprofessional of me to handwave technical issues with the tools. And ALL tools have hard edges and undesirable characteristics.
And putting a header in a HTTP server is not proportional as restricting who can change the source code of a compiler.
Matt Holt is awesome btw. And so is Elm author.
I love the ELM Architecture. Why is there a problem if it is implemented in another language?
I'd think any functional language could implement the ELM Architecture, and thus be 'native', or more integrated into that particular languages ecosystem, and this would offer benefits beyond trying to integrate ELM into each individual ecosystem.
And doing this re-implementation, would in no way be a comment on the ELM founder.
Also, Doesn't Linus say "NO", quite a bit with Linux? Why jump on the ELM guy for doing same thing.
That's not what Elm does. They lock down the compiler so only Elm devs can modify internals, which would be equivalent to Linus trying to prevent people from modifying the kernel.
They really don't like people forking their repo, which would be equivalent to Linus getting mad at people making derivative kernels (because it would "split the community.")
It's not just a matter of saying "no," it's trying to control what devs do to an UNREASONABLE degree.
He is free to manage his project in whatever way he sees fit. And the public is free to criticize that management.
But that doesn't change the fact that calling it "character assassination" is hyperbolic.
As I go through rewrites and greenfield projects and so forth, I begin to realize that for any particular technology you are not simply having a relationship with a static list of pros and cons, but you're also having a living relationship with the team behind the work.
In other words, a bet on TypeScript is also a bet on the TypeScript team, and in my experience the TS team is very fast at their work. This makes me more forgiving of bugs. Similarly, a bet on Terraform is also a bet on Hashicorp.
Here we have someone recommending a choice of F# over Elm because betting on the leadership is allegedly not good. This is not character assassination. The commentator is not criticizing Evan on irrelevant private affairs and by extension saying that you shouldn't use Elm. Evan has created a company and is advocating for his product; he is a public figure and is being criticized on the grounds of project management.
Evan recently gave a talk about it on strange loop. https://www.youtube.com/watch?v=XZ3w_jec1v8
I would love Elm to be in a position where I could advocate for it at work (aside from it being a "neat hobby"). However, the simple fact is that the way Elm is run has lead to disillusionment among advocates of the first hour. And there is nothing to indicate that this will change.
And if the guy has inspired a new generation to create something to his own achievement, kudos to him. As far as I'm concerned Elm is not the enemy, JavaScript is the enemy.