eeue56

No worries at all! I didn't take offense, it's very easy to forget one or two projects when quite frankly, Elm has managed to spawn or inspire so many!

Derw, a human written Elm fork by me, is largely self-hosted. I took that decision with inspiration from Go: 1) it gave me a large codebase which could be used to assess language features on and 2) it gave me motivation to improve generalized performance rather than focusing on the niche use cases (web-rendering).

Native Welsh speaker here! It has always been a dream of mine to go to Y Wladfa, and share a bond through language with people there.

One fun fact - my dad took some higher-learning Welsh exam as an adult. They had to time the exam to match Patagonia, as they were given the exact same exam to avoid any cheating.

Oh, there were definitely multiple things wrong. Bear in mind that this was 12 years ago, so this is just what I took away with me as an on-going learning. Obviously showing errors to users is an obvious takeaway, but it's a side discussion from affordance.

Results were sent as a CSV file - basically a raw export of the data the server got, not something that was read from the DB. So the operation to save to DB and to send the email were intended to be (almost) parallel operations. The errors weren't shown to users, though there was error handling for other cases that did show the user.

We actually did test. We didn't test in the exact same conditions or environment (i.e with no internet access), as we didn't find out about the no-internet restriction until the last minute. That is covered in this paragraph:

> While this bug was a costly mistake, we learned from it. Whenever we would deploy code-last minute, we'd try to test it more rigorously. If we were running a study without internet access, we'd make sure to test in the same environment. We hadn't accounted for the environment change, partially due to the short notice for the locked-down machine, but also just because we didn't test with the exact same restrictions.

Author here!

Indeed - I have an extended equivalent from CGI-bin that I'm including in the full story in the book, since running things as a script vs as a program has different implications for killing the running process. The patterns you mention here tend to be my preferred way of working - exhaustiveness checking of branches. In modern TypeScript, I enforce that via union-type error handling rather than using exceptions (which are a nightmare when it comes to affordance imo). I'm generally a functional programmer rather than an imperative programmer. But the case mentioned in the blog post was about 12 years ago now, so it didn't have the same options as we currently have.

Author here!

In this case, I think the actual API we used would take a callback for success, and a callback for errors. I just used JS an example for how unnatural it would be to call something that exits the entire script early.

I have a big problem with promises + exceptions generally in JavaScript - much preferring union types to represent errors instead of allowing things to go unchecked. But I left that out as it was kind of a side-note from the point of affordance.

I would do this instead:

  type MyEnum = {
    active: 0;
    inactive: 1;
  }

  const MyEnum: MyEnum = {
    active: 0, 
    inactive: 1,
  }

  const showAge = MyEnum.active;
  const showPets = MyEnum.inactive;

It's slightly more duplication, but a lot more readable (imo) to those unfamiliar to utility types. TypeScript also enforces keeping them in sync.

Sadly missing Convox - particularly I'm looking for examples of things each excel at against each other.