The alternative to this seemingly bitter approach is handing over the trust they built to some unknown person who can do whatever they want with the data in a lot of PostgreSQL databases around the world. I think I prefer the bitterness here over blind trust.

Sometimes it generates ambiguous situations, where two solutions are both equally valid.

For example

equation: 5 - _ = _ available numbers: 3 and 2

The beauty of verifying with a changing bit of information (which is basically what is happining now) is that you only prove ownership once and the proof can't be stolen by someone who doesn't own the domain but received your proof.

Maybe I didn't understand correctly how it works. But if I understand it correctly that is actually rather dangerous. Supplying the proof to an untrustworthy party should not allow them to re-use this proof for other services.

  function rotateLine(position) {
    if (position < halfabet) {
      context.rotate((-90 \* Math.PI) / 180);
    } else if (position > halfabet) {
      context.rotate((90 \* Math.PI) / 180);
    } else if (position === halfabet) {
      context.rotate((180 \* Math.PI) / 180);
    }
  }

The latest version seems to have abandoned the typing of the initial input, which makes the types a little simpler.

My point however is that the types you point our here are actually not particularly complex. They are just long, with lot's of inputs for the generics (and the syntax may be confusing). The types in the original article are much more complicated, with conditional type inference etc.

I don't know ramda, but I assume this is only part of the type definition of compose and this is just the longest part of it. I think compose is written in such a way that it can accept a many conversion functions as you want and this is just the longest variant that is encoded in the types.