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_.
I think this is _the_ most popular criticism of HTML 5 vs. XML, that I have seen mentioned. Which is telling, quite frankly. It makes me think that the powers that be that pushed HTML 5 really had a different agenda than what they purported to have. We might never know the politics behind it, but I struggle to comprehend the wisdom of a decision to basically overhaul the lingua de franca of the Web because "XML parsing is hard!" then replacing it with HTML 5 and its peculiar "context sensitive grammar" noone ever remembers or bothers to look up, and the other features like custom elements (with the latter, by the way, in the spirit of "let's just ship it and see", they kind of foundered with the sub-classing there -- Apple rightfully refuses to implement some of Custom Elements API because it flies in the face of Liskov's Substitution Principle).
I looked at CSTML, and frankly, it looks like any other improvement that upon first glance may seem like definite improvement, but the trouble with these dialects or ideas is that it's not the format that's hard to incorporate -- even after you prove it is sound (undesirable parsing ambiguities can something show themselves _after_ you wrote a parser to verify the language grammar etc), but pushing for adoption is. XML didn't die only because it was verbose, it died because the people who may have been convinced of some of the featured really disliked by everyone else, refused to budge -- perhaps they thought that repeating the tag's name is a good thing because it forces one to be diligent or whatever * points to some research paper that supposedly proves repeating text improves accuracy *. It's the equivalent of doubling down when opposed. So XML basically became more XML the more criticism piled up, and as it ossified it died. CSTML, as likely much of anything else that aims at replacing SGML/XML/HTML, is like projects -- ideas are cheap, going through with it is hard. Before CSTML is a long path of adoption, and today with HTML 5, it's even more narrow unless Google, for one, suddenly decides it's the best thing since `<parsed-bread>` (closing tag is omissable).
I think some straightforward YAML schema for representing HTML 5, may have more traction because both are existing languages so not much extra tooling would be required. I could for instance write my Web blog in YAML that is unambigously and simply compiled into HTML 5 (without sacrificing a _single feature_ of the latter), so I don't have to actually type HTML (5). Not everyone uses React or JSX or what have you, and Markdown implementations in practice are often lacking for truly rich blog articles. Then again, if you have a blog article with interactice diagrams, sliders and ad-hoc questionnaires, _XML_ (or a YAML representation thereof, for much the same reason as outlined earlier) _is_ IMO a good language _in form_ -- I have used XSLT with good effect to just stick to a domain-specific language for my blog articles, and have a single XSL stylesheet render uniform HTML page linked to a CSS stylesheet that was basically a posterchild for the coveted content-presentation separation in practice.
I agree we shouldn't have thrown the baby out with the bathwater -- and it's not like _strictness_ was not in XML's spirit, so your usual suspects for primitive types -- numbers and booleans, to name a few -- _could_ have been an improvement along the XML's path of evolution. But something tells me that these features only open a door to more features that are needed. The bounds on what constitutes the [sufficient] set of fundamental types, is a hard problem to solve, especially if it cannot be extended through itself (composite/compound types). XML had not anything but strings for attribute type, but that also made it simple and kept it away from the domain of type theory and parsing more than it already had to have parsed. So I am undecided, but I liked the "one good feature of HTML 5" part of your comment, so I took your bait ;-)
XHTML, as has been _repeatedly_ mentioned by multiple people -- a thing that comes again and again -- at least was _strict_ in that your malformed document told you _early_ (or, rather, a compliant XML user agent did, like your Web browser), where with HTML it's your users that find out, except they have no clue what's going on -- they know even less about HTML 5 parser than the author does, staring at something that should have been a list item but becomes a table cell element or some such.
If HTML 5 is indeed not even used directly, that makes the argument for the _stricter_ format like XML-based XHTML even more attractive -- machines do much better with strict bounds than humans do, so if humans aren't writing HTML, then it feels like we've been sold on the wrong premise, even if retrospectively.
Every time XML comes up, I feel obligated to share my opinion (I too wrote XML a the turn of the millennium and have seen it become and still witness on occasion it being excommunicated).
XML is verbose and therefore uglier than it ought to be. I think most of the haters hate it for that alone -- there's not much else to hate because you don't have to deal with the rest, it's not really imposed on you unless you really have to deal with someone else's XML application.
What do I mean? Well, the brackets thing and the necessity to repeat name of every element twice, in correct (LIFO, last in first out) order, isn't great, admittedly.
What XML has that the dev-bro alternatives that have flooded the void XML left since, haven't gotten and thus see being reinvented, are: namespaces, attributes and interop using the former two. Sure you can write JSON and YAML (the latter deservingly being incredibly hard to parse correctly -- they tried to design a better XML but failed IMO) -- but these suck as meta-languages because there's not much "meta" there. JSON, for example, allows you create properties and has a few types (kind of more than XML, really) but it leaves semantics up to you and namespaces are up to you to re-invent, poorly. If you think I am stretching the argument, see if you can represent an HTML document (no, not Markdown) with a JSON file.
YAML is a similar story, albeit with a few cool things like aliases. I think it's a better attempt to give the world a better XML, but the jury is still out on that one.
The killer thing with XML, for better and for worse, was plethora of tools to work with it. I wrote a fair share of XSLT documents to transform data, back when there was momentum in XHTML, for example. XSLT barely supports JSON and it's not pretty. XPath cannot natively understand YAML -- unless you convert it to XML which I guess re-animates XML as some sort of Frankenstein's monster. And even if it were a [pretty] monster, dealing with intermediate representation for the kind of purpose, is a can of worms all of its own.
Ironically nobody seems to hate HTML 5, seemingly. Or React basically turned it into a greasy cogwheel nobody needs to look at. Because if you look at it, it's in my opinion an abomination even compared to XML (unpopular opinion) -- the parser is quirky and behaviour is defined by the standard per element type (i.e. some elements need a closing tag and some do not, and what happens if you forget a closing tag is element-specific; care to remember the set of rules to ensure your document renders to your liking?). It has no namespaces but it has "custom elements" which require a dash in the name as poor' man's namespaces and you can't omit one, and now we have a Web of `x-spinner` and `x-carousel` because it turns out everyone rightfully wanted default namespace but didn't get one. Anyway, it's all plumbing, right -- the idea of _writing_ HTML has largely come and gone us by. And I am digressing.
In our shop, I wasn't one of those who knew Docker in and out, got just enough into it I could containerise applications we needed to have containerised, which was of a modest scope -- no crazy networking setup that required bleeding edge or anything like that. Anyway, after only a few months into Docker, organisation announced migration to Podman across the board. Initial impressions were soured by, ironically, poor out-of-the-box installation experience _on Red Hat Enterprise Linux_ (which we run everywhere where Linux is used) -- getting `podman` to do much of anything useful in the "rootless" mode matched the typical anecdotal evidence requiring a bunch of incancations you may or may not understand fully, as RHEL itself wasn't ready for the package, apparently. That was in 2024 though, and it rapidly got better after that. These days I have all but forgotten we used to use `docker` but use `podman` instead, but then again I have had to learn plenty enough about at least the latter -- enough I am able to navigate problems better than earlier (what with UID/GID mapping, for example -- which too had to be done manually occasionally when we first transitioned).
There is however, the LLMs that pull their fair share of documentation, or rather, replacing it. Not opening that can of worms here, but heck am I glad I can query `$AI` about occasional Podman "burst pipe", instead of hitting Google and looking for [that one e-mail message from a guy who had exactly the same issue, solved it _and_ had the wherewithal to post the solution](https://xkcd.com/979/).
We never got into use of `docker compose`, not in any capacity to speak of, and these days we use Kubernetes and OKD/Openshift for things that Docker -- in my understanding -- solves with swarm and composition. It works well enough, I almost don't find it worthwhile to mention that it does :)
These were my thoughts more or less, but how many Chens does the world's largest software company need to at least maintain the now "legacy" code before they find a way not to need them any longer. Maybe they're betting on large language models having trained on the cumulative output of experts like Chen, but I think that's fit for contingency situations -- maintaining existing code and making sure it doesn't break the bottom-line -- but for all the praise of AI I have my doubts Microsoft are crazy enough to just leave it to AI to develop Windows containing hundreds of thousands of SLOC of the kind only Chen can effectively debug.
As for 25 year olds -- I am sure there will always be those around, people have been pretty consistently varied in their pursuits, but it going to be so niche they'll be like COBOL/FORTRAN developers hired by the banks today -- far and in between and paid so handsomely they can pick and choose consultancy any day of the week anywhere in the world. So I guess good for them, but again -- can Microsoft depend on that form of provision of labour they still need (and will need for a few years ahead at least)?
> Writing few characters more has never been an issue, at best it's annoying.
I don't think the implication is that writing is the issue. In my experience it's the _reading_ that is an issue. I don't mind writing verbose code -- I don't enjoy it but I'd understand the rationalisation in a team of developers that prefer that -- not as much as I mind _reading_ verbose code myself. It feels like you hit the brakes and the accelerator interchangeably. Which proves the point the law is trying to make, for my part.
It's a great idea but I've lately adopted the habit of just looking at the code and noting SLOC count. I am bewildered how people today add code like there's no tomorrow, I suppose the advocates would quote "literate programming" and onboarding and what not, but I think reality is showing the code gets the better of us and we're absolutely squeezed by the volume of code that kind of works and kind of doesn't, exhibits issues (including vulnerabilities) and at the end of the day just rots looking at the next kid taking over. And I am not loving it anymore.
20K SLOC for a site widget? There's nothing great about that. But sure -- I guess it works. Everything can be ignored because "it works", but in my experience the gears are bound to start flying sooner or later and someone needs to look under the hood -- whether it's under the hood of Townsquare or something that has long replaced it. And it better be service-able.
The fact that Raymond Chen is debugging these kind of issues, tells me Microsoft is short on staff that has his particular set of skills, handing him the hairiest issues from the annals of Windows. The new hires are probably all about .NET and JavaScript and what have you -- whatever Microsoft is about these days. I doubt it's C/C++. Chen is probably on standby and is paid handsomely as a de-facto VIP consultant. He is a legend, but he's becoming somewhat of a vintage developer.
Damn, tough reading about the 1 week deadline for finding work, then getting one after telling them you're jailed and them taking the chance on you.
I also found the article written so well (I suppose we don't encounter native English speakers in the blogosphere as much as we think we do), that it was a joy to read, if I can say so considering the subject matter.
If the kind of proxying isn't illegal, in my opinion it should be -- saying it's bordering on circumvention of fundamental assumptions about Internet routing and IP address leasing (and ownership), would be a sorry understatement compared to what Bright Data has managed to package into a product payment:
> you are allowing Bright Data to occasionally use your device’s free resources and _IP address to download public web data from the internet_. (emphasis mine)
I think the misleading part -- to the end-user -- is the "download public web data" part. If the data is public why can't Bright Data download it themselves? Well, because the other end doesn't want them to, apparently. The product is make you help Bright Data circumvent the undesired properties of the "public" data providers, on behalf of someone who happens to have the cash but as of yet is at the short end of the Internet stick (for all the right reasons, I'd say).
This is absolutely deplorable, but knowing the directions this is heading, I am neither surprised nor concerned, frankly. People have long voted with their wallet -- it's not the privacy-conscious Joe the Hacker that is being proxied through here, it's our parents and millions of people who just want entertainment at the end of the working day, including _parents_ of small children.
Day by day the dark Internet theory sounds more plausible, and frankly I am all there for it. The Internet will collapse into a feudal internetwork where any routing will need hop-by-hop key, so real people (and agents, frankly) can maintain a measure of trust that right now is being actively circumvented.
The point is that MCP solves a problem that doesn't _really_ exist. While consuming context, which is still at a premium. Claiming that services wouldn't be accessible to agents without MCP is at best misleading -- they certainly do [have access] through exactly what article sheds light on -- command-line tools, including but not limited to, input and output of said tool(s). Also, from a purely technical standpoint, MCP is "non-compositional" compared to command-line tools, and those who don't value composition are IMO doomed to discover so at their own peril, sooner or later.
And to be blunt, a) you're investment bias'ed and b) whether you're selling the product (MCP) to a gazillion companies doesn't exactly disprove a).
Just look at Microsoft -- they've buried more technology than most, and there's little correlation between usefulness and how deeply buried it is, and some would claim that the correlation is _inverse_. Organisational factors are what drive them, just as I suspect they are now driving OpenAI's insistence on MCP. I understand it's hard to see that from inside.
I've been using the em-dash for years, having started doing so well before the dawn of LLMs -- needless to say the fact it is used as a telltale sign of LLM writing, doesn't gladden me one bit. Also because I value concise writing through picking correct grammatical elements -- like the em-dash.
I feel like your sentiment mirrors my thoughts exactly on this.
Since this isn't the Reddit comment section (I hear people here prefer a bit more elaboration and argumentative nuance with their $BEVERAGE), I feel compelled to add some of my own personal experience.
I don't think Windows can be fixed anymore. I think the choices Microsoft have been doing for _decades_ now, with only the _mechanisms_ coming and going, have become endemic to Windows, a part of its identity. Copilot, for example, is just another gadget Microsoft simply cannot not put in. In '95 is was Clippy, but the deliveries never stop, and frankly I feel like an old man that finally decided to kick a bad habit because I truly see now all the empty talk from Microsoft I've heard countless amount of times before, wrapped in different packaging, and that Windows is like it is _by design_ and that it's bad for my health (in a different way than Linux can ever be, I feel).
Ever since Windows '95 the addition of slop has been accelerating, admittedly Microsoft _were_ much different then, but it's the _curve_ I am referring to, not that they were always _as bad_. Frankly, the "churn" is insane now, I think it's one or the other adage I can't recall where "available operating system" fills "available resources" and Microsoft are there to prove it.
The problem is also they are experimenting on their users to no end. I don't mind being part of the "user experiment" for "user experience" but how many decades do they need to arrive at the same fundamental conclusions -- that people prefer less bloat, and fewer interruptions in their face? Occam's Razor tells me it's rather that Microsoft is pretending to care but their agenda is their own alone (surprise).
Just the other day I had to spend 2 hours trying to "fix" some very-background OneDrive update because I suppose I am sucker enough to use OneDrive -- one of the least liked of Microsoft products I've had the misfortune to use -- with Windows using my laptop as a BitCoin farm, wasting cycles in some infinite loop produced by what evokes comparisons to those monkeys with typewriters. Half a dozen Powershell commands and 3-4 reboots later the `wsappx.exe` process finally was healthy enough to idle. These things happen constantly to people everywhere and there's little Microsoft can or wants to do anything about. It's a cost they're willing their users to pay.
To stop rambling, one of these days -- summer vacation perhaps -- I will remove the blasted thing finally (after decades of using both Windows and Linux) and grit my teeth through Linux, which I have tried avoiding only because I am on a Thinkpad and there's always another tweak that's needed for the whole thing to work as well as Windows does on a _good_ day. To be clear, I prefer Linux by and large, it's just that I want to avoid spending weekends configuring sleep, power states, Trackpoint, full-disk encryption, the docking station, etc.
The fact I am going to do it anyway, just to rid myself of the Windows experience that's just been getting worse and worse, says it all really.
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.