Comment by Animats

> MacOS 8. Not the Linux thing, but Copeland. This was a modernized version of the original MacOS, continuing the tradition of no command line. Not having a command line forces everyone to get their act together about how to install and configure things. Probably would have eased the tradition to mobile. A version was actually shipped to developers, but it had to be covered up to justify the bailout of Next by Apple to get Steve Jobs.

You have things backwards. The Copland project was horribly mismanaged. Anybody at Apple who came up with a new technology got it included in Copland, with no regard to feature creep or stability. There's a leaked build floating around from shortly before the project was cancelled. It's extremely unstable and even using basic desktop functionality causes hangs and crashes. In mid-late 1996, it became clear that Copland would never ship, and Apple decided the best course of action was to license an outside OS. They considered options such as Solaris, Windows NT, and BeOS, but of course ended up buying NeXT. Copland wasn't killed to justify buying NeXT, Apple bought NeXT because Copland was unshippable.

>- XHTML. [...] Would it kill people to have to close their tags properly?

XHTML appeals to the intuition that there should be a Strict Right Way To Do Things ... but you can't use that unforgiving framework for web documents that are widely shared.

The "real world" has 2 types of file formats:

(1) file types where consumers cannot contact/control/punish the authors (open-loop) : HTML, pdf, zip, csv, etc. The common theme is that the data itself is more important that the file format. That's why Adobe Reader will read malformed pdf files written by buggy PDF libraries. And both 7-Zip and Winrar can read malformed zip files with broken headers (because some old buggy Java libraries wrote bad zip files). MS Excel can import malformed csv files. E.g. the Citi bank export to csv wrote a malformed file and it was desirable that MS Excel imported it anyway because the raw data of dollar amounts was more important than the incorrect commas in the csv file -- and -- I have no way of contacting the programmer at Citi to tell them to fix their buggy code that created the bad csv file.

(2) file types where the consumer can control the author (closed-loop): programming language source code like .c, .java, etc or business interchange documents like EDI. There's no need to have a "lenient forgiving" gcc/clang compiler to parse ".c" source code because the "consumer-and-author" will be the same person. I.e. the developer sees the compiler stop at a syntax error so they edit and fix it and try to re-compile. For business interchange formats like EDI, a company like Walmart can tell the vendor to fix their broken EDI files.

XHTML wants to be in group (2) but web surfers can't control all the authors of .html so that's why lenient parsing of HTML "wins". XHTML would work better in a "closed-loop" environment such as a company writing internal documentation for its employees. E.g. an employee handbook can be written in strict XHTML because both the consumers and authors work at the same company. E.g. can't see the vacation policy because the XHTML syntax is wrong?!? Get on the Slack channel and tell the programmer or content author to fix it.

> - XHTML. Have you ever read the parsing rules for HTML 5, where the semantics for bad HTML were formalized? Browsers should just punt at the first error, display an error message, and render the rest of the page in Times Roman. Would it kill people to have to close their tags properly?

Amen. Postel’s Law was wrong:

https://datatracker.ietf.org/doc/html/rfc9413

We stop at the first sign of trouble for almost every other format, we do not need lax parsing for HTML. This has caused a multitude of security vulnerabilities and only makes it more difficult for pretty much everybody.

The attitude towards HTML5 parsing seemed to grow out of this weird contrarianism that everybody who wanted to do better than whatever Internet Explorer did had their head in the clouds and that the role of a standard was just to write down all the bugs.

I was all gung ho on XHTML back in the day until I realized that a single unclosed tag in an ad or another portion of our app that I had no control over would cause the entire page to fail. The user would see nothing except a giant ugly error. And your solution of rendering the rest of the page in Times New Roman isn’t an option. Do you try to maintain any of the HTML semantics or just render plain text? If it’s plain text, that’s useless. If you’re rendering anything with any semantics, then you need to know how to parse it. You’re back where you started.

Granted, I could ensure that my code was valid XHTML, but I’m a hypermeticulous autistic weirdo, and most other people aren’t. As much as XHTML “made sense”, it was completely unworkable in reality, because most people are slobs. Sometimes, worse really is better.

> Would it kill people to have to close their tags properly

It would kill the approachability of the language.

One of the joys of learning HTML when it tended to be hand-written was that if you made a mistake, you'd still see something just with distorted output.

That was a lot more approachable for a lot of people who were put off "real" programming languages because they were overwhelmed by terrible error messages any time they missed a bracket or misspelled something.

If you've learned to program in the last decade or two, you might not even realise just how bad compiler errors tended to be in most languages.

The kind of thing where you could miss a bracket on line 47 but end up with a compiler error complaining about something 20 lines away.

Rust ( in particular ) got everyone to bring up their game with respect to meaningful compiler errors.

But in the days of XHTML? Error messages were arcane, you had to dive in to see what the problem actually was.

Nice list. Some thoughts:

- I think without the move to NeXT, even if Jobs had come back to Apple, they would never have been able to get to the iPhone. iOS was - and still is - a unix-like OS, using unix-like philosophy, and I think that philosophy allowed them to build something game-changing compared to the SOTA in mobile OS technology at the time. So much so, Android follows suit. It doesn't have a command line, and installation is fine, so I'm not sure your line of reasoning holds strongly. One thing I think you might be hinting at though that is a missed trick: macOS today could learn a little from the way iOS and iPadOS is forced to do things and centralise configuration in a single place.

- I think transaction processing operating systems have been reinvented today as "serverless". The load/execute/quit cycle you describe is how you build in AWS Lambdas, GCP Cloud Run Functions or Azure Functions.

- Most of your other ideas (with an exception, see below), died either because of people trying to grab money rather than build cool tech, and arguably the free market decided to vote with its feet - I do wonder when we might next get a major change in hardware architectures again though, it does feel like we've now got "x86" and "ARM" and that's that for the next generation.

- XHTML died because it was too hard for people to get stuff done. The forgiving nature of the HTML specs is a feature, not a bug. We shouldn't expect people to be experts at reading specs to publish on the web, nor should it need special software that gatekeeps the web. It needs to be scrappy, and messy and evolutionary, because it is a technology that serves people - we don't want people to serve the technology.

> Modula. Modula 2 and 3 were reasonably good languages. Oberon was a flop. DEC was into Modula, but Modula went down with DEC.

If you appreciate Modula's design, take a look at Nim[1].

I remember reading the Wikipedia page for Modula-3[2] and thinking "huh, that's just like Nim" in every other section.

[1] https://nim-lang.org

[2] https://en.wikipedia.org/wiki/Modula-3

> Would it kill people to have to close their tags properly?

Probably not, but what would be the benefit of having more pages fail to render? If xhtml had been coupled with some cool features which only worked in xhtml mode, it might have become successful, but on its own it does not provide much value.

> XHTML. Have you ever read the parsing rules for HTML 5, where the semantics for bad HTML were formalized?

I actually have, and its not that bad.

If anything, the worst part is foreign content (svg, mathml) which have different rules more similar to xml but also not the same as xml.

Just as an aside, browsers still support xhtml, just serve with application/xhtml+xml mime type, and it all works including aggressive error checking. This is very much a situation where consumers are voting with their feet not browser vendors forcing a choice.

> - XHTML. Have you ever read the parsing rules for HTML 5, where the semantics for bad HTML were formalized? Browsers should just punt at the first error, display an error message, and render the rest of the page in Times Roman. Would it kill people to have to close their tags properly?

IMO there's a place for XHTML as a generated output format, but I think HTML itself should stay easy to author and lightweight as a markup format. Specifically when it comes to tag omission, if I'm writing text I don't want to see a bunch of `</li>` or `</p>` everywhere. It's visual noise, and I just want a lightweight markup.

+1 Copland

BeOS. I like to daydream about an alternate reality where it was acquired by Sony, and used as the foundation for PlayStation, Sony smartphones, and eventually a viable alternative to Windows on their Vaio line.

Neal Stephenson, https://web.stanford.edu/class/cs81n/command.txt :

> Imagine a crossroads where four competing auto dealerships are situated… (Apple) sold motorized vehicles--expensive but attractively styled cars with their innards hermetically sealed, so that how they worked was something of a mystery.

> (Microsoft) is much, much bigger… the big dealership came out with a full-fledged car: a colossal station wagon (Windows 95). It had all the aesthetic appeal of a Soviet worker housing block, it leaked oil and blew gaskets, and it was an enormous success.

> On the other side of the road… (Be, Inc.) is selling fully operational Batmobiles (the BeOS). They are more beautiful and stylish even than the Euro-sedans, better designed, more technologically advanced, and at least as reliable as anything else on the market--and yet cheaper than the others.

> … and Linux, which is right next door, and which is not a business at all. It's a bunch of RVs, yurts, tepees, and geodesic domes set up in a field and organized by consensus. The people who live there are making tanks.

It would be years before OS X could handle things that wouldn’t cause BeOS to break a sweat, and BeOS still has a bit of a responsiveness edge that OS X still can't seem to match (probably due to the PDF rendering layer).

In addition to Photon, I would say QNX itself (the desktop OS). I ran QNX 6 Neutrino on my PIII 450 back in the day, and the experience was so much more better than every other mainstream OS on the market. The thing that blew me away was how responsive the desktop was while multitasking, something Linux struggled with even decades later.

Similarly, I'm also gutted that the QNX 1.44MB demo floppy didn't survive past the floppy era - they had some really good tech there. Imagine if they pitched it as a rescue/recovery OS for PCs, you could've run it entirely from the UEFI. Or say as an OS for smart TVs and other consumer smart devices.

Somehow I feel C# has become the right successor to Modula-3 ideas, even if has taken 25 years to get there.

GCC nowadays has Modula-2 as official frontend, not sure how much it will get used though.

XHTML, yep I miss it, was quite into it back then.

> IBM MicroChannel. Early minicomputer and microcomputer designers thought "bus", where peripherals can talk to memory and peripherals look like memory to the CPU. Mainframes, though, had "channels", simple processors which connected peripherals to the CPU.

TIL: what microchannel meant by micro and channel.

Also it had OS independent device-class drivers.

And you could stuff a new CPU on a card and pop it right in. Went from a 286+2MB to a 486dx2+32MB.

Word lens team was bought by google, its far better in google translate then the local app ever was. You could repeat the old app with a local LLM now pretty easily but it still won't be as close in quality as using google translate

> word lens

I don't know if you know it, that's a feature of Google Lens

CICS is still going strong as part of ZOS. There are industries where green screen, mainframe terminal apps still rule and CICS is driving them.

I love this mismatched list of grievances and I find myself agreeing with most of them. XHTML and proper CPU hypervisors in particular.

People being too lazy to close the <br /> tag was apparently a gateway drug into absolute mayhem. Modern HTML is a cesspool. I would hate to have to write a parser that's tolerant enough to deal with all the garbage people throw at it. Is that part of the reason why we have so few browsers?

CICS and HATS are perhaps the most annoying pieces of technology I’ve ever encountered.

The reason XHTML failed is because the spec required it to be sent with a new MIME type (application/xml+xhtml I believe) which no webserver did out of the box. Everything defaulted to text/html, which all browsers would interpret as HTML, and given the mismatching doctype, would interpret as tag soup (quirks mode/lenient).

Meanwhile, local files with the doctype would be treated as XHTML, so people assumed the doctype was all you needed. So everyone who tried to use XHTML didn't realize that it would go back to being read as HTML when they upload it to their webserver/return it from PHP/etc. Then, when something went wrong/worked differently than expected, the author would blame XHTML.

Edit: I see that I'm getting downvoted here; if any of this is factually incorrect I would like to be educated please.