Observations

Turned out all the delays were caused by two things:
- reading the files in parallel, as opposed to sequential (don't ask, will investigate)
- parallel output to stdout, instead of linearising the output. That was obviously my mistake, have to group the data, not mix them.

Now it's still 3 times faster than FP version. Got a suspicion that in JVM method dispatch is much heavier than plain if/else. It should be. But it's the staple of FP, never use booleans or ifs, but dispatch by the type. So, well... have to investigate.

So, I just bumped into this problem being mentioned. "For performance", bounds are not being checked by c programmers, who mostly don't care about any cases except the ones they like.

But well, what's the point in these checkings?

I know three cases.

1. We know during compile time the size of the vector we need, and we should not accept the smaller ones; we should rather not accept the larger ones, but mostly we don't care. This is the case for tuples. It's not an array. If someone wants to pass into the code an array pretending to be a tuple, this fact should be checked at the border. Ok, yes, there are no tuples in C or C++. Well, bad luck, and say hi to the three morons interesting people that provided you with such a language.

2. We don't specify the size, but we have some constraints, like the height of one matrix should be equal to the width of another; or maybe that a vector must contain not less than so many members. Ok, why not have it all in a specialized class? Once the class is instantiated (optionally, with all the checks), there's no way the sizes will change, right? So we don't have to check the bounds.

3. A loose collection of ancient libraries with loose, frequently unknown, requirements. I guess these libraries should be wrapped and hidden from the eyes of a modern human. It's like a slaughterhouse, hardly any modern city dweller wants to see what's going on there.

I think I got it where all this bs about passing around numerical ids of entities instead of entity references (maybe lazy) come from. It's like 'error code'. It comes from the ancient c programming, where we just could not allocate a string for a readable piece of text, or for the data that may need some efforts to instantiate or allocate.

In short. It's stupid to pass around "ids" in a program.

(10x polycode
source

#define COLORS \
    X(Cred, "red") \
    X(Cblue, "blue") \
    X(Cgreen, "green")