hackrmn

This may be a dumb question, but can't one implement the "N data stacks" in C and thus basically get the principal feature of Goose while staying with C syntax and paying with verbosity?

Comprehensibility does not equal correctness or fitness. As if that wasn't enough, or perhaps in most related manner, an LLM/AI cannot be held responsible for what it produces, by nature, especially considering the fact that a _human_ claims all of it as their own work, or at least take responsibility. Meaning that when a parable of documentation is discovered to be bogus, you can't pin it on AI, you go to the human and ask them why the documentation is wrong, and it's not a good look.

Pretty cool to click the link and find it has been bookmarked for a decade on my end :-)

I am sorry but what does cache locality and CPU core access pattern(s) have to do with the video you linked? Indeed it shows a lot of instances in animation, but the only technicalities it mentions are bare mention of Vulkan (which I assume implies GPU), and I am using the CPU and without any libraries.

I started writing a [CPU-only] 3-D rendering library in C++ recently, after having written the equivalent in C as a proof-of-concept and an experiment. The reason I decided to write it in C++ after C, is not only because I wanted to tap into meta-programming which is facilitated much better with C++, or that I wanted niceties like procedure overloading, but because some things with C or C++ aren't automagically optimised -- like if you want to leverage struct-of-array (SoA) memory layouts because it allows fewer SIMD (AVX in my case) instructions in the rendering pipeline. You do _not_ get that "for free" just writing a single procedure in C++, much less with C. Both languages are layout-sensitive, I mean this is in part what gives you the speed -- optimising with memory layout for cache locality etc. But you have to do it yourself. Meaning that if you need array-of-struct (AoS) or in fact don't know which path the CPU would prefer, there's no other way than roll up your sleeves and one way or another implement both.

The kicker is, in my case I chose C++ because templates allow me to reuse most of the code in the rendering pipeline _regardless_ of whether I go for AoS or SoA layout. I leverage operator overloading to do vector by matrix multiplication which is implemented in both variants. I do have to specify the desired variant during building, but I've profiled and for Intel x86 AVX in my case SoA is something like twice as efficient because I process ("shade") 8 vertices with 4-5 instructions instead of 1 vertex at a time (still shaded with vectorisation -- just "rotated", i.e in the pipeline axis and not vertex buffer axis).

TL;DR; C++ gives you plenty fast by default, but it's not always enough. The difference between 5 and 15 frames per second, well, makes all the difference -- our eyes are only fooled once the frames-per-second rate goes sufficiently up, anything below an acceptable threshold and it's completely different experience. You then either sacrifice resolution or level of detail etc, or decide to squeeze more from the language by helping the compiler.

Your solution seems tangential to the problem brought evident here, with how ICANN and VeriSign are able between themselves, to turn 22,000 or so tangible name registrations into dust, without any retribution or refund. The funny thing is that DNS -- where these names actually reside -- is distributed, but it's not as federated as to prevent the kind of takeover. Worst case, a rogue state can declare their own root name servers with their own fork of all name records including 3LDs for `.name`, show the middle finger to the U.S. and call it a win -- except that real people in the U.S. or otherwise using DNS servers that don't hold the forked data -- will fail to connect to the services expected at those names as specified by the rogue state, and will instead connect somewhere else. Basically like two realities of links pointing different places in each universe. A multiverse of name resolution. Not great at all, except what if the rogue state is larger and thus more power-dominant than the U.S.? The U.S. can pretend they don't care, but they become ostracised through DNS, and that's not going to win favours with the users. In other words if 4 out of 5 people prefer x.y.z. points to my actually useful website except some scammy ad-ridden page, then whoever doesn't point x.y.z. to my website is going to lose users -- unless those behind the scammy x.y.z. alternative pledge to monetarily compensate for every disgruntled user.

Anyway, name resolution needs to be federated because ICANN is apparently compromised as far as doing the right thing goes. A single root model may not work anymore. Maybe blockchain can finally do some good...

And what lesson have you learned?

This points to a more general problem with some of the Internet infrastructure -- since real people don't actually own domain names, much less e-mail addresses (assuming they use e.g. @gmail.com), they're always at the mercy of a third party, which is normally tolerable except that with prevalence of user accounts at various Internet services, for any given person, tied to an e-mail that receives password reset instructions and what not, ultimately ownership of the service account is in the hands of whomever owns the e-mail. Although Google doesn't read your e-mail to order pizza on your behalf and bill, and even if your crypto-savvy brethren encrypt their communication to you, services you more or less depend on do _not_ send you e-mail that only _you_ can open -- regardless of the mail transfer or storage system (read: the e-mail is plaintext).

In light of this particular situation, I think a secret key shared between you and the service, at least, could guarantee that even in the event the e-mail address is stolen (or otherwise taken) from you, the service account remains in your hands.

I know I am not breaking new ground here, but I don't think the Internet is getting healthier for the human, it's at least going to get worse before it may get better. So maybe we need to adjust our assumptions and mitigate accordingly.

What are you referring to with "they released air tools"? I am not sure I am able to interpret your argument in any meaningful way.

I agree regarding metaphors, I myself aggressively utilise analogies with both myself and others, as a "digestive", but I feel like with LLMs we're treading on thin ice as it's not straightforward to classify a particular use case as one scaffolding learning with a metaphor, or just having the opposite effect where your brain "sails" in a faulty sea of "learning" while in reality there's no real work being done, not of the kind the brain needs to do in order to re-order all the synapses and own networks that ends being "knowledge" eventually.

There's been research done (I know, big words -- don't have any links readily available), where it was pointing to the fact that what goes easily in (into the brain) also goes easily out, and conversely, what the brain requires effort and literal calories and energy to understand, stays there longer (investment must be rewarded / recouped somehow).

So while there's no doubt that facilitating learning is a net-positive, at some point it becomes a net-positive, I suppose -- your brain just chucks it out faster because it knows you can re-obtain the same information again since it worked so easily the first time. It doesn't know the difference between easy and hard, all it knows is how much effort it takes and how much reward (hormones) was generated for it all (to cement the habit/result).

For my part, the make-or-break part of these kind of visualisations -- assisting home renovation, and interior and exterior design and architecture in general -- has been lighting and materials, not [only] or in any meaningful part 3-D through VR augmentation. I mean I would surely appreciate a fine piece of hardware like Vision Pro put to use here, so the author is on point, it's just that at some point you want to actually see the relative colorimetry at work -- how your beige couch is going to look in that spot illuminated by a giant window facing south etc. It's not as critical as making the house right, since moving a couch is easier by far, obviously, but there are things like kitchen islands that are more costly, featuring slabs of stone that is neither cheap nor easy to move.

Anyway, I've been using Radiance to help me deal with the above issues, but it's for all practical purposes non-interactive. At some point there's bound to be a e.g. Monte-Carlo physically-based ray-tracer for these use cases, featuring radiometry with visually negligible error compared to reference (i.e. if you were looking at the real thing with your eyeballs), that is _interactive_-capable (at least in the frames-per-second category and not seconds-per-frame). It's probably already out there, but people have different preferences as to the tools they wish to employ. I like Radiance because it's text mode and gives you a lot of quality for all the text editing and tool composition (which frankly is a bit weird, Greg Ward was sure a maverick!), but mileage varies there.

This is the MVP comment.

When you have a carpenter visiting you don't announce they can go into your kids' rooms (for reasons unrelated to the job is) and what not -- the [default] contract is they're there to do a job and their privileges go only as far as the job requires, they normally also ask you first time where your toilet is, although we all agree they can use it. It's a contract, formally and less so, and things work when the contract is abided by. The carpenter also can't say they had the right to the cookie jar on your kitchen counter just because they were working there.

By not implementing such a contract with code, Microsoft has shown negligence. And they have had _decades_, so it's likely a "business decision".

I don't know, I was very happy when I discovered what Radiance can do with what you give it. I hear people get very good looking rendering with Blender, but my brain doesn't work like that (anymore?). Point being that not everything is about games and looking good, we need reliable tools to render synthetic scenes to assess a lot of non-game related things, like quality of lighting in architecture before erecting a skyscraper or buying a house etc. To that end, every bit of knowledge like the author seems be focused on, helps. I absolutely relate to the problem with "faking" things. Even developers of Unreal engine had acknowledged -- all too late, as it is -- that it's _light_ that most affects our perception of "realism". That and materials, which is why they had some sort of field trip to Iceland taking raw photos of rocks they could add to their materials library.

Another problem with looking good is that it's a) subjective (since it has no real or objective reference point, really) and b) it quickly goes stale once something else looks "better". Just look at Doom. It looked good in 1993, everyone would agree on that. It's not realistic, never was realistic and will certainly never be realistic unless you take a particular cocktail of drugs, I guess.

Thanks, I did some learning and it fell more into place.

Is transcription a form of _inference_ though? I mean I see the word being thrown around and I understand what it means (or at least I think I do) in context of LLMs doing the thing that they do -- intelligently predict the next token, but do speech-to-text models do that?

Ok, I admit arguing about Git's merits, best practices, workflows and so on, can be hard online like this, not the least because I have limited amount of time I can invest in this admittedly very interesting to me discussion, so it requires upfront reasoning (in addition to the typing, which is relatively cheap) but I feel obliged to respond.

First, I agree commits shouldn't store broken snapshots -- if that's what you mean -- code that doesn't compile or outright is _known_ (as opposed to omissions that weren't caught otherwise and made it into the commit) to be broken, not run, produce runtime/type-checking errors, miss dependencies/assets etc. Not everyone would agree -- in our shop people routinely commit "stuff" for reasons they don't disclose that also remain unexplained to me (not having any explanations my way), and then more stuff on top of that. At some point they tag one of these commits as "v2.0.0" triggering automation that releases a package, often broken. Then they scramble for "v2.0.1" etc. I find all of it tedious and unnecessary -- my best practices would rather be to run automation that does checking and sufficient filtering for "bullshit code" as early as possible -- at the "pre-commit" stage, so only whatever passes through that ends up being committed in the first place. If it yet runs into regressions or other problems in production, I fix (re-triggering all the checking again) and release a strictly patch version -- unless fixing was impossible without breaking compatibility in which case it may be a minor or even a major version bump. I do tag commits, too, obviously. But in principle every commit is "production", the difference is not every commit makes up a _release_ (implying to the general public / intended audience).

Regarding rebasing -- that depends on what you mean exactly -- there's different ways to rebase -- you can squash, auto-squash and/or apply fix-ups, or you can just transplant stuff -- when you say "you should rebase" and "patch on current master", what do you mean? Github-driven projects often don't permit pushing `master` without a PR, so a rebase upfront would have been necessary if the author for some reason is not on a branch [other than `master`].

"Actual merging" -- do you mean merge commits as opposed to fast-forward merging which doesn't produce an additional commit? If the latter, what does "merge from history" mean, again? You just need to produce a working snapshot, expressing it with a commit with N parents, there's no more to it. It's fixing of the merge conflict that requires you to understand the graph, the resulting commit is just the period at the end of a long sentence, so to speak.

Anyway, I really missed the point you were trying to express with your first paragraph, I am sorry. Do elaborate, please.

Bisecting also _benefits_ from non-linear "actual development" graphs -- apart from commits that don't feature broken code committed haphazardly for "reasons" (some people use Git as backup, that I know for a fact) -- since they don't hide the work (one of the reasons I prefer raw graphs over squash-merged "polished" stuff).

One thing I should mention in any case is that I do find slicing work into atomic commits often very tedious and counter to what Git is supposed to sell (distributed friction-free concurrent versioning). Because my brain doesn't always work in terms of concepts aligned with Git's -- I routinely may start with one feature fix, on some branch, then discover N related issues, fix those because they're in front of my face then and there, end up with an unreadable diff I can't cleanly add in chunks, etc. None of that is facilitated by Git in any more capacity than just being a scalpel. I don't always want to cut down a tree with a scalpel, obviously.

Pijul, an alternative VCS, uses this nice patch theory guaranteeing you can "apply" commits in any order, compositing your changes essentially -- a feature is just some baseline that is added N commits (in any order, like the mathematical `+` operator). That way you don't have to rebase anything because parenthood doesn't break merging -- if you fix a bug with a patch in Pijul, you can store it once and count on it being applicable to any snapshot made later, even if the result isn't visible -- unlike with Git where rebasing some old commit will abort and ask you to fix a conflict because Git cannot continue.

No, boss -- you suck.

See what I did there?

I think you missed the main point of my argument -- you, the game developer, aren't programming the hardware directly or through the kernel -- you are using a common abstraction in a competing set of abstractions that don't require their vendors to beg for crumbs from the likes of NVidia because the dependency only goes the other way -- NVidia publishes an "exokernel driver" that merely exposes the capabilities of the hardware without assumptions about how to best use it. Fundamentally it's not even needed beyond a _specification_ since the hardware is fundamentally exposed through ports and addressable memory mapping(s), but since Nvidia does closed-source and closed-hardware the latter is not going to happen so kernel driver it is. You, the game developer, don't use it directly, you rely on middleware (like Vulkan) and/or middleware on top of that middleware and so on -- until you are left with an API you are comfortable using.

Indeed, Vulkan is the step in the right direction because it largely follows the path I was outlining, but it's still got ways to go because it assumes things and mixes in abstractions of its own, but more importantly because through its mere existence and the way how it is positioned it occupies space where nothing else has room to exist. Point being that Vulkan still requires you to play by someone else's rules of how they thought the API should work, which is detrimental in principle to "exokernels". So this is about exokernels, not about going full retard and programming a 100 billion transistor GPU on your own to draw pixels.

In case I wasn't able to elaborate: Vulkan looks like the part, it's certainly a sign of the people who started with the likes of DirectX have learned about the dead-end model they thought would work and are now finally seeing the "light", and I am arguing that whatever abstracts the GPU should just pretend it's a generic massively parallel computation unit with addressable memory of multiple kinds and places and so on -- without assuming it's for "graphics" (which it is less about today than ever before, what with AI etc).

If you want that, mandate developers use prefixes like `!fixup` and do `git rebase` _on your end_ -- why force upon everyone your ideas especially if it also squashes all development history? This also removes development friction because people can work with Git on their end the way they like without regard to some convention that can be avoided -- save for the "!fixup" thing which can be considered useful metadata.

A linear graph doesn't do any developer in the team except Github (which isn't a developer in this context) any good because they have to pull down the graph at some point and when they have to fix something, although they will be able to track the blame to some commit in the middle of the graph, when they fix it and merge it it has to be squashed again (by hard or soft enforcement), which like I said negates much of the point with Git -- there's no usable history left.

Point being that branches aren't something to avoid, implying that complicated graphs are not to be avoided either, but embraced and knowing how Git works it's not a problem at all (unless your "bush" is accidentally complex in a bad way) -- except that if noone bothers to learn Git, it _becomes_ a problem, solved at the cost of the value that Git provides -- branching (not just ephemeral branching for your local convenience). Exacerbated by Github since everyone pulls from there -- meaning that production-grade code is not a true graph but a linked list, on average.

My observation has been that those who have never learned Git properly -- disregarding for a moment the issue with what "properly" means here -- just don't think they need to, sticking to very simple workflows that produce linear graphs featuring squash-rebased work throughout. Because they don't know Git's fundamental model (including what you'd think was the obligatory piece of information that commits are essentially immutable), they don't venture farther than their confidence suggests, keeping it within the circle so to speak.

The tragedy, if you ask me at least, is rather that they then start imposing the "keep it simple" culture onto everyone else, which frankly turns Git into what SVN and CVS were accomplishing before it, with all the drawbacks of those. This keeps 90% of the team satisfied 90% of the time because there's nothing wrong with strictly linear graphs and the pro's that are asked to produce these, can always squash-merge their intricate local development history before they push to Github (which some Git users also think is part of Git proper).

Something about using Git in the aforementioned way just bugs me strongly. I admit it's a me problem, very likely, but lately I've also had to admit that it's not just that either.

For instance, if I need to fix a bug I use `git blame` to find the commit where I have learned the bug originated. I do a `git checkout -b ... <commit>` to start working on a fix, creating a branch starting at the problematic commit. Already that is head and shoulders above what many people I work with do or know _what_ does (or why would one want to do that).

I do it because it creates a _trail_, certainly more so than just committing on top of `master`, even with a good commit message.

But my practice doesn't produce linear graphs, even as pushed to Github (which we have to use, for better and for worse) and shared with everyone. I then get people coming to me and complaining they can't merge and it becomes obvious they don't understand Git sufficiently to do anything else but `git reset --hard` or worse, `rm -rf * && git pull` and hope for the best.

Not sure where I was going with this, something about why use Git when it's the new SVN with everything SVN had and none of what SVN didn't have...

I last wrote 3-D rendering code using hardware in 2005 or so. It was DirectX 11 or 12, I don't recall. I thought it was quite a mountain to climb. For my part, I grew up _implementing_ rendering pipelines, so I always had this sour taste of needing to learn someone elses (Microsoft, in this case) idea of how to render 3-D scenes -- using their concepts, even if they were industry standard (shaders etc). Meaning that somewhere inside their APIs are fundamental abstracts I _do_ find, well, accepted terms. After all, I am not arguing against using integration in maths as being useful. There's practicalities.

What am I getting at?

Well, if you take the "no graphics API" to its logical conclusion, then we should strive to remove everything that is "graphics" from it altogether. Reading the article linked and the article the former links in turn ("No Graphics API"), there's still an ungodly mix of graphics rendering _specifics_ and I think these too will start rotting "sooner rather than later".

Having grown up on matrix operations and optimisations that often venture into territory where they _lose_ resemblance to outright _graphics_ pipeline they originally modeled, I am of the firm opinion the logical conclusion I am advocating for, is a sensible one.

To explain with an analogy -- I think we should adopt the "exokernel" approach to GPU hardware. That means just exposes the hardware constructs without trying to fit these into any form of a common denominator (between AMD, NVidia and Intel), and have software specific to each glossing over the abstractions.

Before you say "well, that's exactly what DirectX, Metal and even Vulkan, did!", the key difference is not the encapsulation itself, but its form, the "how" of it.

An exokernel, for instance, does not expose or provide a memory manager (referring to use of MMUs), or give you a `malloc`. It simply exposes the paging mechanism, and you take it from there. If you need a high-level API and/or cannot be bothered to page things in your little command line application -- a fair concern -- you rely on middleware, aka "libOS" in the original, MIT's terminology, a library by any other name -- to provide `malloc` so you don't have to cry over the bare-bones exokernel.

The point I am making is that as the exokernel software (and libraries that would complement it) just exposes the GPU hardware, there is more flexibility to how to use it without "cramming round shapes into square holes" -- a bane of graphics programming _and_ especially optimisation there, that has plagued the entire field since 3dfx' days. Library authors can wrangle API design without touching the hardware or working _around_ it, while hardware vendors can tune subsequent chips to generic computing -- it's the way it's going anyway, except that they won't have to coordinate closely with software writers -- the dependency will go strictly one way -- from library to "GPU exokernel" authors to hardware manufacturers, and never the other way around (ideally). Every link in the chain has more flexibility then.

Practically, we're talking about a generic massively parallel processing unit with tons of addressable memory of different latency (system RAM, on-board RAM, on-chip RAM / L0-level stuff) exposed with a zero-cost abstraction layer known as an "exokernel". DirectX / Vulkan etc compatibility implemented strictly in software over the "exokernel". Those who want their retained mode or whatever else that doesn't require them to deal with cache thrashing issues, can use that, while those who like to holistically optimise and/or Unity / Unreal Engine developers proper, can use the exokernel by writing libraries for it, or outright affect the exokernel itself as new hardware is put on the market.

Sorry for the wall of text. This is from someone who started with implementing solid-painted triangle and polygon rasterisation, then Phong and Gourad shading using an Intel 386...

P.S. This isn't AI slop (although you're obviously free to feel it reads like one), I just like to use the em-dash.

I seem to remember to have watched a recent comparison on YT between Second Reality using SB vs GUS, and I did appreciate an audible improvement with the latter, but it may have been a placebo -- I admit you may be right, as sources seem to confirm that the track used 8 channels that minimised if not outright eliminated synthesis differences. I am not an audiophile or audio engineer by any stretch so more informed people will have to chime in here, but what I had going for me then was the fact I never had a Sound Blaster to compare with directly. I think the fact my card died mere months into my purchase, kind of prevented me from forming a more objective opinion on the quality difference between it and SB.

Yeah, it infused my software engineering career and interest in optimisation and 3-D rendering.

P.S. When we invent the time machine, we should go back to load up on actual GUS _and_ spread the word for people to never install it horisontally :-)

I think a fundamental and flawed assumption in your general line of argument boils down to that line:

> Social people will be fine

Thing is, "social" is not only a scale, it's not even a line for scale. It's this multidimensional space of different social preferences and different preferences as to _how_ to socialise, not to mention with whom and for what reason. In short, it's much more complicated than as to permit a "binary" division into the "social" and "other" people, but even if you did, I would wager the division puts it at 50% for either group, meaning you're basically describing a cataclysmic event where 50% of the population suddenly has no access to a fundamental trait of humanity that in known and unknown ways has assured our feeling of happiness and warded off a plethora of conditions of misery and worse that psychology has no names for (and won't ever have names for because that's like classifying different gradations of drinkable water, I imagine).

But yeah, humanity has always had to evolve, it's just that these changes come too fast for our adaptability to adapt to, I believe.

During my teenage years in what is today a post-Soviet country -- to put it in apt context -- I was briefly an absolutely ecstatic owner of a Gravis Ultrasound (Classic, I believe) card. I probably had spent my _annual_ extra income on that card. My period of ecstasy -- playing Epic Pinball, Doom and Second Reality by Future Crew etc -- enjoying the then insane sound quality (funny how that works when your comparison is Sound Blaster's MIDI and the "PC squeaker") lasted only a few months because the card fried a capacitor or something like that, and that was it. That was decades ago and I still think about it not unlike a friend I left behind that I can no longer reach back to, to be perfectly honest. I had the dead-weight on my shelf, that's the last I remember. I was young and probably didn't even think of handing it to an electronics shop for a relatively cheap repair -- a fried capacitor or loose PCB connection is not a fried custom processor, I imagine.

Anyway, good memories, even in the tragedy. I can relate to people who resurrect GUS.

Since others mention similar failings of their card, I remember I too had it installed horisontally in a (Chinese/Taiwanese) mini-tower, it definitely wasn't a desktop chassis, much less an IBM PC. I guess gravity strained it to a breaking point.

Fewer people aren't staring into their phones or talking to them -- makes your social antennas pick up automatically on not wanting to disturb them (lest you draw their ire for not having the social antennas long enough to pick up on the fact they're "busy and don't want to engage with you" like a gymrat with AirPods to signal they're there to pump in peace and quiet listening to their favourite playlist, not talk to strangers). Happened to me already many times just with people scrolling their phone instead of talking and not wanting to talk in particular either, not to me at least. And no -- I am not talking about bothering strangers in the gym etc, I am talking about sitting at the lunch table where half of the people look into their phones -- they aren't actually interested in talking, it turns out.

Our devices have now increased the distance _between_ us -- it's not about _you_ being able to "do X" -- talking to others is not _you_ doing it, it's you _and the other person_ doing it _together_. You can't be doing anything together consentually when the other person is in the habit of talking with their AI, or doomscrolling for that matter.

Right, if what you mean is making the `=""` optional, then it seems even more attractive than types, I admit. You'd have to amend the XML grammar to see if making the `=""` optional introduces problematic (for e.g. the reference parser) ambiguities that weren't there before. From the looks of it / intuitively it doesn't seem to be the case, but with a language that's deployed in a gazillion places such small changes rightfully warrant new major revision, which would be XML 2, I guess. Which would have wide ramifications, I imagine. Which brings me to W3C....

> True however those who control the HTML spec are unlikely to let it go.

Like I said in another comment, I believe XHTML was axed because it stepped on _someone_'s toes. I suspect it had to do with W3C being understaffed and criticised for being too slow at the time -- by most of the industry, and most of it deservingly -- and WHATWG (with Google co-authoring their standards) stepping in as the authority on all things Web, and somewhere between the two XHTML was used as the proverbial fall guy. Speculation, of course -- but a lot of good, useful work was thrown out the window with XHTML. Not the first time it happens, of course, but this was the Web we're talking about, not Adobe's product portfolio.

I've heard the "streaming" argument before, by the way -- it keeps being mentioned (probably because it was one of the official reasons for the transition to HTML 5), but I think it's a "ruse" -- nothing about XHTML in practice prohibits an agent from progressively rendering an XHTML document, and if something really did, in W3C's writing for instance, then all they needed to do is relax that requirement because again -- there's plenty of hierarchical data formats with strict rules that by their very nature don't preclude parsing (or semantic analysis / rendering) done in streaming fashion.

Can you think of a minor syntax error example that you believe should be corrected by the browser, and better than the author would (had the Web browser notified them early -- by aborting rendering as was the case with XML)?

There's a bit of irony with the fact that HTML 4 which _did_ have browser "correct" errors (albeit in non-standardised manner) _was_ what motivated XML in the first place -- it's just that in light of the wildly different correction behaviour between Netscape Navigator, Internet Explorer, etc, they decided on a pragmatic solution -- abort and tell author, like a C/C++ compiler. The latter can also correct syntax errors, strictly speaking -- but you'd be hard pressed to find a programmer that would seriously consider letting the compiler do that. Why HTML should be different?

Say you forgot a `</p>` and then comes a `<li>` -- since `li` elements cannot be children of paragraph elements, I guess the Web browser, in compliance with HTML 5 for example, could mandate that the paragraph ends just before the `<li>`, meaning it behaves as if there _was_ a `</p>` before the former, _and_ also inserts... what, a `<ul>`? Why not `ol`, then? This heuristics is messy, if only because the Web browser doesn't have enough context to _know_ what the author wants, and can't assume a single kind of omission. And HTML 5 simply defines some default behaviour, handwaving the problem, but the truth is no HTML 5 authors -- myself included (I have been writing HTML in one [proto-]form or another since 1994) -- ever remember what those rules _are_.