jitter_

I'm not here to pick a side. I'm sure all of us can be more friendly to each other.

However, I'm a bit curious about when you say

Suggesting that someone pours over documentation (and laughably source code) to explain patterns (or a lack thereof) in a highly abstracted language is counter-productive.

Isn't that what documentation is for? To learn about whatever's being documented. What would you suggest would be the better way to convey this information?

For source code, I can see your point. Although in my experience source code has the benefit that you can be certain that it doesn't lie. It does exactly what it says. Sometimes this can be a really nice benefit when trying to figure out what's going on. Regardless of the language or environment you are in.

One thing not mentioned by other replies is that the discussion around the story of Last of Us got very polarized when the second game dropped. There was a very loud opposition from part of the fanbase to certain plot points, themes and other decisions made in the story. This made the people who still liked it get very defensive about it.

I see that same controversy continue with the discussion around the show which, typical to reddit, manifests as downvotes, reports and name calling (woke or bigots, depending on side)

In English https://www.presidentti.fi/en/press-release/joint-statement-...

Having followed the language for quite a while, including some of the controversies, I think there's two things you need to be mindful of:

1. The language version starts with 0, i.e. it is being clearly communicated that there is no guarantee of stability

2. The language development is being run by an opinionated BDFL who likes to take his time to think through new features. There's more of novel, well-thought-out ways of doing things, but less support for "I need this for my production use case now"

Neither of those points is inherently bad, but if you plan to adopt Elm in your product or codebase be prepared to rely only on the feature set you get from current version. Expect breaking changes in the future when new version drops.

There's lot to like about the language and it can be a good introduction to functional programming if you are not yet familiar. IMO it is definitely worth spending time on to improve your skillset and to gain new perspectives on programming.

I've always been bothered by the (sometimes massive amount of) hate that I see in the internet towards agile. The experiences from other developers always seem a bit off, like something is not right.

I think your point might be the missing piece. Agile might not mix too well with fixed timeframes or fixed budgets, but rather needs an environment of continuous development where the requirements have room to drive the project within wide enough budgetary boundaries.

This to me feels sort of a natural way to build things. If we need something we build it, otherwise we don't. And those "needs" might pop up at any time, by external (customer requests etc.) or internal (new techical requirements become apparent as the project is being developed) events.

My experiences of agile development have been from companies without deadlines and are generally positive.

under Bayesian reasoning a lot of “fallacies” like sunk cost, slippery slope, etc. are actually powerful heuristics for EV optimization.

Can you elaborate on that?

This really piqued my interest. I feel like logic is easy to apply retrospectively (especially so for spotting fallacies), but trying to catch myself in a fallacy in the present feels like excessive second quessing and overanalyzing. The sort that prevents forward momentum and learning.

Would you by any change have any recommendations on reading on the topic?