Mike Izbicki

Taking that one step further, a monoid homomorphism is a function that transforms one monoid into another while preserving that essential structure (homo-morph: same-shape), so that map-then-reduce is the same as reduce-then-map. Being able to swap the two might be a useful optimization if one is more expensive than the other, for example. e.g. `e^(a+b) = e^a*e^b` turns addition into multiplication. Fourier transforms turn convolution (expensive, complicated) into multiplication (cheap, simple), if you know what that is.

In some other contexts, it's useful to talk about transforming your problem while preserving its essential structure. e.g. in engineering a Fourier transform is a common isomorphism (invertible homomorphism) which lets you transform your problem into an easier one in the frequency domain, solve it, and then pull that solution back into the normal domain. But to understand what's going on with preserving structures, you need to first understand what structures are even present in your problems in the first place, and what it means to preserve them.

This stuff isn't strictly necessary to understand to get real work done, but without it, you get lots of engineers that feel like the techniques they learn in e.g. a differential equations class are essentially random magic tricks with no scaffold for them to organize the ideas.

Another useful purpose of these concepts is to have the vocabulary to ask questions: A semigroup is a monoid without a unit. Given a…

The author addresses the potential benefits of immutability and laziness in a note on cover trees[0]. Last time I checked, this is still the world's fastest NN algorithm.

Haskell could shine in numerical computing. I think the key is polymorphism: a vector is a matrix is a tensor is a number, and they can all be multiplied in the same way, once you define what multiply is.

Poor support is more about the lack of haskell coders doing ML. It's hard to compete without the numbers that other platforms enjoy.

[0] https://izbicki.me/blog/fast-nearest-neighbor-queries-in-haskell.html

despite all the theoretical work, it's not physically possible to bias a coin to any notable degree. Unlike a die you can't weight one of the faces, you can bend the coin but it takes about a 90 degree bend in a coin to be able to say that a coin is biased with statistical confidence. Or in other words, if the coin appears reasonably flat, it's fair enough that you won't notice.

https://izbicki.me/blog/how-to-create-an-unfair-coin-and-prove-it-with-math.html

I get the idea as shorthand for a binary outcome, but the way you make a coin fair is to flip it.

If haskell is that much harder, it should benefit from better tooling that much more. I think there really is a big difference in the priorities. I've never played around with GHC, so I have no idea how hard tooling is, but I know some good old humans are at least able to contribute (https://izbicki.me/blog/error-messages-in-ghc-vs-g%2B%2B.html).

edit: It looks like the error message changes may have been reverted (https://phabricator.haskell.org/rGHC92c924e07dfef327509555c27a5478d9851ec9fa) :( Sad that they reverted it instead of fixed it.