I think a lot of the reason is that, ok, LaTeX is extremely complicated. We all know this. Its partisans tend to believe that this is because typesetting is a hard problem. Typesetting is a hard problem! We know this, too. But I think that a substantial fraction of the complexity of LaTeX is accidental complexity stemming, ultimately, from the inherently loosey-goosey nature of the system.

See, there is no real abstraction in TeX. There are no real mechanisms for encapsulation/information hiding/whatever. It's all just characters that eat characters and turn into other characters. Anything can do anything. Anything can be anything. As a result, the whole "theory" of what a TeX program "is" (like in the sense that Peter Naur used that word?) is conventional.

This means that even to reuse other people's code, you have to imbibe decades of convention that's maybe semi-documented, maybe folkloric, or maybe perfectly sound but requires you to read a 230-page manual. I can only speak for myself, but for me, it's no way to live.

Now, again, TeX-lovers tend to claim that its high degree of loosey-gooseyness is necessary, that it's what makes TeX "powerful." I don't know, that sounds to me like the same old "you can't handle writing assembly" story. Sure I can. I'd just rather not if I can help it.

Maybe it's the PL person in me.

This is NOT the case with modern SQL, as it supports JSON. The typical Postgres use-case would be to produce denormalised views for the specific relationships and/or aggregates in JSON form. LATERAL, the correlated sub-query, is really convenient in avoiding double-counting. The rest of the article deals with object-mapping, which is really a poor man's VIEW. Time and time again, software engineers reinvent the data-access wheel out of ignorance to database capabilities.

As far as I can tell, it's VASTLY more capable than all of these new options. It has full-text search, all sorts of query optimizations, different storage backends in both the browser and server, and more.

This explains why I lose every argument with my wife about things that happened in the past.

Data engineering can be lonely. I like seeing the approach that others are taking, and this article gives me a good idea of the implementation stack.

* What does missing data look like? The empty string, NaN, 0, 1/1-1970, null, nil, NULL, \0?

* What date format will you need to parse? What does 5/5/12 mean?

* How multiline data has been written? Does it use quotation marks, properly escape those inside multiline strings, or maybe it just expects you to count the delimiter and by the way can delimiters occur inside bare strings?

And let me add my own question here:

what is the actual delimiter? Do you support `,`, `;` and `\t`?