Aristotle was part of the incredible flowering of math and philosophy in Ancient Greece between 600 and 300 BC or so. There was a similar flowering in western Asia between 750 AD and 1050 AD or so. The one doesn't contradict the other. When Western doctors were treating patients in 1400 AD they were working from ibn Sina's (Avicenna's) Canon of Medicine rather than Hippocrates (though ibn Sina owed a lot of Hippocrates). When Colubus was trying to persuade everyone the Earth was small he was arguing mostly about al-Biruni's book on the topic (though al-Biruni owed a huge debt to Eratosthenes). Again, this is more about science than philosophy which in Europe did tend to go directly from the Ancient world to the Renaissance as far as I can tell.
The "rules" of unicode change over time with updates to the unicode standard(s). One big one is the grapheme breaking algorithm, which has been updated over time to support things like the family emoji and other compositions.
A strategy that actually works: read the book through, even if there are many things you do not understand. Do it again and again until you get the majority. Everything you encounter now feels familiar in a sense, and you can go in depth with the literature
If there are parts of the text that resist you after 2--3 re-readings, look up alternate sources which cover the same point.
In particular, I'd recommend finding the first/foundational work (usually cited in the textbook itself), and reading that. One reason that foundational works are foundational is often that they manage to effectively communicate a concept to a large population. That is, not are they theoretically novel and groundbreaking but they are rhetorically competent. Re-tellings by others are often inferior.
(This isn't always the case, but it is often enough that it's a useful tip to keep in mind.)
Otherwise, look to see what other references are included in the text, and try reading the relevant sections of these. Today those are often available via the Internet Archive for check-out, or you can simply download books from Library Genesis / ZLibrary, or articles from those sources or Sci-Hub.
I am a 35-year-old person, and I have spent at least 5 years now trying to figure out how to read for comprehension and retention. There is no simple solution, but I do think people discount "familiarity". The truth is that it is tough, and it is slow.
I also found this helpful: "The single most helpful thing in figuring out what to write down was noticing when my reading was slowing down, which typically meant either there was a particular fact that needed to be moved from short to long term storage, or that I needed to think about something." Here is the source: https://acesounderglass.com/2020/06/10/what-to-write-down-wh...
I agree that the DCOM interface by IBM (20 years ago?) was just as bad... but if the source does not provide any documentation how can you be more clearer if you open it up in another language?
These programs are worth billions for larger airlines according to https://en.wikipedia.org/wiki/Ancillary_revenue When there are billions at stake, it does not strike me as a stretch that the credit card partners would bend the rules to benefit their airline partners.
Not OP, but I would say that we, regular Bash users, don't really write complex programs in Bash, even though it depends on what you call "complex". Some of our programs can be pretty long, and we can do more within Bash than some programmers know (eg. the arrays/associative arrays features, the vast parameter expansion options etc.), so no, we aren't bound to some 100-line-max rule, if that's what you had in mind.
Bash (and other shells) are very good at working with other programs and using the filesystem. It's true you have to know many idioms, but once you're there, you can be quite productive for these kinds of tasks.
For me, anything that I couldn't write without a guide is too complex. Like a function. Or a conditional.
Subjectivity of what is complex is the problem here, which means that regular Bash users regularly write programs that are complex to me. And I'd much rather use something with less footguns, even if the good parts of the shell become less easy.
So true. The shell encourages one to reason about and simplify workflows by leveraging programs that already solve the complex problems. I'm continually amazed at how many lines of code I can replace with a Bash one liner.
One's level of expertise will determine what is "too complex for $SHELL". When that point is reached, it's time to switch to something else, not time to add more features to $SHELL.
(If, when something becomes too complex for $SHELL, you switch to assembly, you might be too much of a $SHELL expert!)
What usually happens in my case is I start off writing a simple program in Bash, then it unexpectedly becomes complicated as I add more and more to it.