> If Vizo never licensed the software to you under the GPL [...]

That may be true.

> [...] you can't say they violated the GPL.

That does not necessarily follow.

If they used GPL-licensed code in their product, they may be obligated to provide the source code to that product's consumer.

No, you really don't have to. Partially complete software can have a lot of value too.

Anyone can fork it and quickly add the i18n (or just translate into a different language) for their own purposes. People will likely want to contribute i18n. People may fix or improve things for you.

Of course, it's entirely up to you - but I've appreciated half-complete software countless times before.

I have the same disagreement. TypeScript with its structural and pseudo-dependent typing, somewhat-functionally disposed language primitives (e.g. first-class functions as values, currying) and standard library interfaces (filter, reduce, flatMap et al), and ecosystem make propagating information using values extremely ergonomic.

Embracing a functional style in TypeScript is probably the most productive I've felt in any mainstream programming language. It's a shame that the language was defiled with try/catch, classes and other unnecessary cruft so third party libraries are still an annoying boundary you have to worry about, but oh well.

The language is so well-suited for this that you can even model side effects as values, do away with try/catch, if/else and mutation a la Haskell, if you want[1].

[1] https://effect.website/

It is unique and looks cool.

When it comes to providing an enjoyable blog post reading experience, it really does creep into the "fuck off" territory for me, though.

Even better is "" since it's not really adding anything

Coffee is my de facto morning beverage.

`for` loops are a superfluous language feature if your collections have `map` for transformations and `forEach` for producing side effects

It's quite nice for the following reasons:

- Image previews (for file management with dired/dirvish)

- PDF viewing

- In-buffer images (e.g. profile pictures in git log with Magit)

- Browsing simple HTML pages (e.g. API docs)

There's probably more I've yet to discover.

M-X calc and/or imaxima with embedded Gnuplot generated plots.

You only need that much protein if you're trying to build muscle. The amount needed for a generally healthy diet is much lower.

There is no generally healthy diet that doesn't include building muscle.

If that's something you care about, then don't define your CI build in terms of GitHub Actions steps. Instead, call your build that takes care of using whichever version of Node you want in CI.

I actually completely agree with both the article and your point that your code should directly communicate your intent.

The angle I'd approach it from is this: recording whether an email is verified as a boolean is actually misguided - that is, the intent is wrong.

The actual things of interest are the email entity and the verification event. If you record both, 'is_verified' is trivial to derive.

However, consider if you now must implement the rule that "emails are verified only if a verification took place within the last 6 months." Recording verifications as events handles this trivially, whilst this doesn't work with booleans.

Some other examples - what is the rate of verifications per unit of time? How many verification emails do we have to send out?

Flipping a boolean when the first of these events occurs without storing the event itself works in special cases, but not in general. Storing a boolean is overly rigid, throws away the underlying information of interest, and overloads the model with unrelated fields (imagine storing say 7 or 8 different kinds of events linked to some model).

> that is, the intent is wrong. The actual things of interest are the email entity and the verification event.

Or, your assumption about the intent is wrong. Many (most?) times, the intent is precisely whether an email is verified. That's all. And that's OK if that's all the project needs.

> Storing a boolean is overly rigid, throws away the underlying information of interest, and overloads the model with unrelated fields

Also, storing a boolean can most accurately reflect intent, avoid hoarding unnecessary and unneeded information, and maximize the model's conceptual clarity.