Elm changed my mind about unpopular languages

It's all good. :)

> what looks like the constant dismissal of any concerns about any of these issues any time they're brought up.

I remember earnest (and exhausting) discussions of these topics from back in like 2014, when it was unclear what the best way to scale Elm's development would be. We tried different approaches, but the outcomes weren't great.

We're actually still experimenting with this. For example, Evan wanted to put a community member in charge of the debugger, so he did...about a year ago. That experiment hasn't been fruitful (the debugger has not had a substantial release in that period), so we're trying handing it off to someone else. We'll see if that works better based on what we've learned from the previous attempt.

It's easy to say someone else should have taken it over sooner, but at the time there wasn't anyone else who understood the internals well enough to manage it, while also being interested in taking it over. Now there is.

Relatedly, I get that some bosses want to see a higher bus number on the compiler, but functioning teams of compiler authors don't just drop out of the sky. It's a rare specialization, and even among the few people who have the training to do major work on a compiler like Elm's, most are academically oriented and didn't go through a pH.D program so they could performance optimize Haskell code, make nice error messages even nicer, or find ways to remove language features rather than adding that cool new one they read about in a paper.

There's also communication. Evan used to give lots of updates about his progress on upcoming releases, and the main effect was to delay the release. He'd announce some progress and it would instantaneously become a Q&A - at best. Often people would pressure him to give up on whatever the latest impediment was and ship something sooner. If he didn't respond to those responses to his progress update, people would complain that he was unresponsive. So doing public updates strictly increased complaint volume, which of course also takes a toll on Evan, being a human and all.

> But not having an idea of what the roadmap or timeline looks like is a big deal.

The two options here are:

1) Be honest

2) Try to trick bosses

There isn't a world where Elm stakes out a roadmap and a release timeline and then hits it. Elm is trying to do a bunch of things differently than how they've been done before, which means each release is in some ways experimental, and also that each release changes substantially based on lessons learned from the previous release.

So yeah, it'd be possible to make up a bunch of "oh yeah, Feature A is gonna come out in April, and then B will land in July" but anyone could look back a year or two later and realize that the stated roadmap had barely any relationship to what actually happened. (People would complain about that too - that Evan wasn't sticking to the roadmap he'd laid out.)

We know from past releases that this is how it's gone (in my hubris, I told my editor at Manning I predicted Elm 0.19 would be out last summer) so there's no way to publish an official roadmap without knowingly misleading people.

If anyone considers it a red flag that there's no official timeline, well - that's because such a timeline wouldn't mean anything anyway. Evan's approach is to be open and honest about this. [0]

This is how we've ended up with a community of people who largely don't think it's a big deal: process of elimination. Everyone who considered it a deal breaker is still using JavaScript.

I don't know how helpful that all is, but maybe it sheds some light on the history of some of these things. :)

[0] https://github.com/elm-lang/projects/blob/master/roadmap.md

Python is not statically typed. Mypy adds a layer of static typing on top of Python.

The beauty of strong static typing–you don't need to get the types right immediately. Just get an initial design out the door and iterate towards better designs as you go. The compiler helps you tremendously for refactoring, and managed deprecations let you change types gradually over time.

* Technical failure in a professional setting can lead to loss of your source of income and therefore, in the worst case scenario: loss of access to food, shelter, comfort and other basic life necessities. Failure at a personal project has no such comparable consequences. Techniques to minimize failure are quite literally a matter of survival in a professional context; they are often an afterthought in a personal project. Fault prevention and tolerance are often the most difficult characteristics to achieve in any sufficiently complex software system, and their prioritization or lack thereof has an enormous impact on virtually every aspect of working on such a system.

* In a professional setting, you often have little choice of who you work with. Therefore the technical choices you make in a professional setting must take into account the possibility that the next person who works on your project may be someone who does not understand, like, or care about the way you do things, and that the way they interact with your work may have significant negative repercussions for both you and the project. This is often a tedious, difficult, and time-consuming task that requires different techniques and approaches than one would use when working on a personal project. Conversely, in a professional setting you will also inherit the work of others which may be done in ways you don't understand, like, or care about, with few or no options to change those ways, and you must develop and adopt technical strategies to deal with this as well.

* Documentation, readability, and testing take much more precedence in a professional setting since they serve as guardrails for the long-term integrity of your work as it gets passed on to others to maintain and expand.

* Working with others also requires agreement, and usually mutual compromise, on basic standards, conventions, and processes that can significantly affect your daily workflow and may greatly differ from how you would work on a personal project.

* The end goal of personal projects is usually personal enjoyment, satisfaction, and learning. The end goal of the vast majority of professional projects is to generate revenue, or otherwise serve some need that your employer deems sufficiently important to fulfill by compensating you. The intersection of techniques that are personally appealing to you and the ones that will generate value for your employer may be very small or nonexistent much of the time.

* Your employer may not care about letting technical debt pile up indefinitely as long as you can keep cranking out new features and meeting deadlines, code quality be damned. Alternatively, your employer may impose onerous processes to ensure code quality and integrity that aren't really necessary or effective, and which may even be counterproductive. In fact, there's a good chance your employer will understand very little about what you do at all and make demands that are incongruent with technical realities, which you must deal with, sometimes by performing pointless tasks solely to appease them.

* Personal projects are usually started from scratch, and often dropped or 'completed' once they reach a certain level of complexity, due to the increased level of difficulty brought on by said complexity. Rarely does one have the luxury of dropping projects on a whim for such reasons in a professional context. In general, working in a professional context often involves dealing with a lot more annoying complexity and thorny problems that simply cannot be ignored. Even successful, enjoyable professional projects may become boring after a while since their success will draw continued investment by the employer, oftentimes in areas that are uninteresting or largely irrelevant to the aspects that were originally exciting.

They are rewriting the web version. Don’t know how big/popular that one is.