Very few languages (or programmers!) are able to check that a function doesn't have side effects. In particular, checking that a function doesn't diverge generally requires a proof assistant, like in F* and Lean.

Your definition of functional programming is as valid as any, but it's so strict that even Haskell would be mid-tier in the functional ranking.

Another European example is Finnish which has yes but not no.

No in Finnish is ei, similar to Estonian ei or Swedish nej.

In applied CS, it's common to talk about pure and impure functions instead of Turing machines.

Pure functions are, broadly speaking, equivalent to Turing machines. A pure function may only depend on its inputs (like a Turing machine) and has no outputs besides the return value (like the end state of a Turing machine's tape).

Impure functions cover algorithms that aren't Turing machines. For example, you might have a random number generator rand: 1 → N that outputs different natural numbers on every invocation rand() and is hence impure. Output functions are also impure, e.g., a function write: N → 1 that writes a number into a file can't be a Turing machine, because Turing machines have no concept of files.

Computer programs that consist entirely of pure functions aren't very useful, because they can't interact with the user or reality. The typical approach to solving this is to put the core program logic inside pure functions that interact with impure parts through a limited interface. That way, you can apply CS concepts to the important parts of the program and neatly separate out the impure parts.

Edit: Changed ∅ to 1 (singleton set) in function definitions. A function can't return ∅ and a function taking ∅ can't be called.

The author should look into Koka. As I see it, Koka is at the bleeding edge of effect handling, which is why the async Rust team has taken some nibbles of inspiration from it. Alas, Rust as a whole is far too cemented to overhaul everything for generic effect support, but at least it's been beneficial for async.

I recommend Pyright over Mypy if you don't mind it being owned by Microsoft. It has far fewer bugs, and if you do stumble on one, you don't have to fix it yourself because Microsoft's paid devs will fix it in a couple of working days (at least for the small bugs I've reported).

I do very little coding, but it's because our workplace has an abundance of junior developers, not because I'm pressed for time. My work is essentially just turning emails into technical specifications that others can implement and tutoring juniors when there are problems. Few to no pointless meetings because I insist on using emails or tickets whenever possible.

Agreed. I think operator overloading is a necessary feature in any math-oriented or general-purpose language. Being able to write formulae the same way as they're written in the source paper is a huge boon to readability.

Different applications require different tests, so no measure is going to please everyone. If you're making embedded devices for an airplane, the buyer might ask you to provide a formal proof that the program works. In contrast, web apps tend to simply use end users as testers, since it's cheaper.

I personally don't like the idea, because keeping services entirely disconnected is good for privacy.

Furthermore, I think it's funny that the author used Matrix as an example of a service benefiting from chat federation, when Matrix is about to be deportalled from Libera.Chat due to bad UX and leaking secret channels. If Matrix can't even federate properly with IRC, there's no way they can do it with modern services like Discord.

Another point in favour of databases is simplicity of client-server communication and data models.

Many objects in WoW (not too sure about spells, but most likely them too) work such that the client asks the server for the related DB rows when it sees an object for the first time. So instead of sending code across the wire, which would be a bad idea for many reasons, you instead send structured data that the client interprets.

Of course, you could just bake the spell code into the client at compile-time, but then dataminers will take it apart on day 0. WoW datamining mostly works such that you play the game normally and see what data the server gives you.

In languages with static and convenient type systems, I try to instead encode units as types. With clever C++ templating, you can even get implicit conversions (e.g. second -> hour) and compound types (e.g. meter and second types also generate m/s, m/s^2 and so on).

Similar problems (and more) have been solved long ago by libraries, because the issues aren't specific to music. More importantly, how does utf8 support count as a "horrible edge case" in 2022?