DemocracyFTW

To effectively argue that "Hong Kong is of course part of China because it's right next to it on the map" opens the gates to all kinds of jingoism. Just for the record, to me the Falkland war was a war between two imperialist countries. Contrary to what was popular belief among my peers back in the day, I did not and do not think Argentina has more rights to the Falklands than the UK just because it's "right next to it" and not "thousands of miles away" like the UK.

China is always adamant that this or that region is "a natural part of China". For some reason people have to come to accept the state of affairs regarding Xinjiang, Tibet, the Spratly Islands. If they don't change their minds then there will be no stopping the fascist juggernaut. Mongolia, parts of northern India, Taiwan and Vietnam are to China what Belgium, Poland and so on were to the Germans in 1939.

"Von der Sovietunion lernen heißt siegen lernen."

To say that "HTML is not Turing-complete, therefore CSS as a separate language is required" is not even wrong and I leave it to the readers to fill out the blanks.

To say that "HTML is not Turing-complete, therefore JavaScript as a separate language is required" is more or less correct although to be fair we've seen many, many features such as animation being absorbed by declarative CSS that had to be implemented in imperative JS so in that regard the need for JS has diminished.

I can say with certainty that a full fledged programming language (i.e. Turing-completeness + usability) is absolutely necessary for a viable solution of document production. And while one can and people do produce TeX and HTML output programmatically, this does not obviate the need for a typesetting engine that can tell you where you are and what the circumstances are while typesetting the document. JavaScript has grown many abilities in this direction, but TeX in comparison is, after almost 45 years in development, still lacking and CLUMSY AS HELL for crying out loud.

Nothing is easy, simple or straightforward in TeX. Numbers are difficult, units are difficult, command syntax is difficult, namespaces are difficult (because there are none), variable names are difficult, conditions are difficult (there are like hundreds of specialized \if s), knowing in which column you are is difficult, fonts are difficult, character encoding is difficult, keeping constant line heights is difficult, positioning floats is difficult, the processing model is difficult, the very syntax is difficult.

I've said it before and I will say it again: TeX is a computational typesetting system, but it turns out it's quite bad at dealing with numbers, strings, and conditions, the basic building blocks of computational typesetting.

TeX is an utterly broken system because every single aspect is a convoluted mess.

It does get a lot of praise for its incorporation of the Knuth-Plass line breaking algorithm, and rightly so. However this beast, too, is hard to handle unless you just go with the defaults. It will happily give you overshooting lines because Knuth decided to have a word jutting out the right margin was a better solution than unsightly spaced words or letters. Most printers would disagree and just bite that bullet where necessary.

Yes, TeX will issue a warning in such cases but this is almost insubstantial because TeX keeps warning you about many, many things in the same output stream as its informative messages. That stream is almost impossible to parse for humans and machines alike. To make it even harder TeX's console output is hardwired to wrap at column 80. Even TeX's error messages are a convoluted mess.

/rant

And to come back to your original question, yes, I do have the strong suspicion that the separation of styling (CSS), content (HTML) and programming proper (JS) into three distinct compartments with differing syntaxes is close to the local optimum that we as people in this time and age can and want to deal with. If anything the syntax of JS and CSS could perhaps be unified (CSS is 90% JavaScript's object literal syntax; it adds selectors, allows hyphens in property names, and has quite a few notational amenities on the right hand side; other than that, it's like object notation). One can also imagine to express CSS in HTML which would be a bit clumsy but still somewhat usable. However, to unify markup syntax with imperative syntax is almost sure to fail. JSP (remember those?) and embedded PHP are two examples for how we do not want things to be. JSX looks a bit more viable. Svelte does this very interesting thing where they have a single file define the markup, the styling, and the behavior in a single file with three distinct parts; to me that looks like the future.

I'm the proud owner of the entire 6 vol Computers and Typesetting series (of which the former title is vol A), and have worked through sizable portions of those. I also read mot of the 680 pages of Knuth's Digital Typography monograph. I also owned one LaTeX book at some point. I admire the depth of Knuth's knowledge (typographic and otherwise), the sheer diligence, his quest for quality, all of that. Those lion doodles though, the author's urge to land another witty remark, come up with another finely crafted reference, and how he's prone to hint at stuff instead of writing a proper documentation are not aspects of his work that I enjoy.

Been there, experienced that. Like this one poor guy who dared to ask at the TeX.StackOverflow help desk—"what can I do to get this and that vertical line in my table", only to get lectured by one acolyte, "Oh noes, don't, vertical lines bad, only horizontal lines in tables, proven to be the only way to go". Which totally throws centuries of finely typeset mathematical, astronomical and nautical tables out of the window while not answering the question.

To be fair, there are quite a few people on the TeXSO that go to incredible lengths to give extensive answers—expositions really—to hairy questions ('hairy' being a technical term here which translates to 'daily' in the context of TeX).

TeX being "interleaved with natural language" is not at all at the heart of the problem IMO. Every HTML document does so, too. The real problem lies much deeper. TeX uses recursive rewrites of the code that is the document to achieve what it does, without properly keeping track of where it is and what it does. There is no technical necessity for doing so, but the technique introduces huge complexity costs. On a somewhat related note, TeX's syntax at its very heart is also not trivial to parse short of executing (compiling) a given document (i.e. TeX's syntax itself is Turing-complete). This has been done only because the author got carried away by the coolness factor of it. Already a few years after TeX came out, Leslie Lamport implemented LaTeX on top of TeX to make TeX more approachable to less dedicated / insanely gifted users; he chose to dial back on this very aspect—the inscrutable syntax—and proposed a much more regular syntax as a convention.

I think this is the future really, I've been pining for this to become a thing for so long.

Definitely watch his channel (https://www.youtube.com/results?search_query=held+der+steine top result), also observe he gets quoted quite a bit and has collaborations with other people interested in similar things.

Just as an aside, when you move a newspaper or a magazine from print to only existing as a web page, you certainly have 'dematerialized' it to a degree. However you still need hardware to keep and display the data and energy to move it around and light up the screens. In so far it does not stop being physical. The 'intangible' is somewhat of a red herring. Yes, it is less haptic, but it's still physics, physical all the way down. Other than that, currencies, freedom, equality, education, entertainment—we've been having intangibles all the time, at least from the dawn of human culture onward. Cryptomining does not bring anything genuinely new to the table in this respect. It's not even new in being a fraudulent, volatile scheme that betrays traits of a cult, one that benefits a few and hurts the many.

Came here to say this. Beyond Rust and AssemblyScript, there are quite a few other programming languages that target WASM, meaning that WASM is a good candidate for that holy grail, the unified environment where you can write your stuff in 'any' language and re-use and talk to stuff written in 'any' language without relying on relatively clunky, type-challenged and slow IPC.

Impressive seeing as the AI manages to reproduce the same text for any uploaded image.

Python is considerably more picky in what it allows in which constructs; it does all the numerical typing stuff implicitly (so switching between integer, big int, and float happens most of the time without users even knowing about it), and b/c of backwards compatibility, coercions between numbers and booleans still happen (`True + 1` is still `2` in Python3.9). By extension, this includes empty lists, strings, and dictionaries evaluating to `False` in appropriate contexts.

I believe that in retrospect most of these efforts—coming up with a Just Works arrangement of strategically placed implicit coercions—that so much defined the rise of scripting languages in the 90s are questionable. Subsequently, many millions of USD went into making JavaScript faster than reasonable (on V8) giving its pervasive dynamic nature. Just bolting down types and banning any implicit coercions would have given it similar performance gains with a fraction of effort and a fraction of the resulting complexity. Backward compatibility could have been done with a pragma similar to the existing `'use strict'`.

I guess what I want to say is that strong and loose typing exists on a continuum much like human languages are never just of a single idealized kind.

From a radius of ~300m onward you'll see green lights (= good for people) for all considered parameters. RPM drops from 1.7 to 0.5 for a radius of 3000m.

* [1] https://www.unicode.org/reports/tr11/tr11-39.html

Also, talking about 'glyphs', one has to clearly separate between what Unicode encodes and what a given font uses; in the context of fonts, 'glyphs' are also called 'glyfs' or 'outlines', and any OTF my choose to render any given string with any number of glyfs/outlines, including using a visual ligature to display 'f+i' = fi but doing so by nudging the outlines for f and i closely together.

a.k.a. 'ligatures', as in f+f+i -> U+fb03 'ffi'