eftpotrm

Aside from the other commenter's point about this being a misleading comparison, you didn't need to reinvent the whole XML ecosystem from scratch, it was already there and functional. One of the big claims I've seen for JSON though is that it has array support, which XML doesn't. And which is correct as far as it goes, but also it would have been far from impossible to code up a serializer/deserializer that let you treat a collection of identically typed XML nodes as an array. Heck, for all I know it exists, it's not conceptually difficult.

What makes XSLT inherently unsuitable for an interactive application in your mind? All it does is transform one XML document into another; there's no earthly reason why you can't ornament that XML output in a way that supports interactive JS-driven features, or use XSLT to built fragments of dynamically created pages that get compiled into the final rendered artifact elsewhere.

I'm aware I'm in a minority, but I find it sad that XSLT stalled and is mostly dead in the market. The amount of effort put into replicating most the XML+XPath+XSLT ecosystem we had as open standards 25 years ago using ever-changing libraries with their own host of incompatible limitations, rather than improving what we already had, has been a colossal waste of talent.

Was SOAP a bad system that misunderstood HTTP while being vastly overarchitected for most of its use cases? Yes. Could overuse of XML schemas render your documents unreadable and overcomplex to work with? Of course. Were early XML libraries well designed around the reality of existing programming languages? No. But also was JSON's early implementation of 'you can just eval() it into memory' ever good engineering? No, and by the time you've written a JSON parser that beats that you could've equally produced an equally improved XML system while retaining the much greater functionality it already had.

RIP a good tech killed by committees overembellishing it and engineers failing to recognise what they already had over the high of building something else.

Passed with the support of the current governing party, it should be noted.

BMW tried that with the i3, it wasn't particularly popular. An engine, fuel system and a generator are all relatively complex additions compared to just putting the same cost and vehicle space into more batteries, and the public charging networks are definitely up to the task by now (having been EV-only for almost 5 years now).

I can't help thinking more startups need greybeards around. (Of which, realistically, I'm now one.)

Largest table 100 million rows and they were paying 6 figures for database services annually? I have one now that sits happily enough on an 8yo laptop. I've worked on systems that had similar scale tables chugging along on very average for 20 years ago MSSQL 2000 boxes. There just isn't a need for cloud scale systems and cloud scale bills for that data volume.

The problems they're describing should never have got that far without an experienced hand pointing out they didn't make sense, and if they'd hired that greybeard they'd have spotted it long before.

And yet it happens. A doctor in my family told the story of a patient they were treating in hospital who medically needed to lose weight, and who they found unable to get any reduction until they dropped below _200_ calories a day.

Metabolism is _significantly_ more complex than CI/CO, from experience.

That's it! Thanks :-)

HP did the same when migrating away from the PA RISC architecture.

IIRC as part of their testing they set it up so it would ingest, recompile and output code for the same architecture, and found that it could produce speed improvements due to context awareness.

Nikon aren't doing much better on letting third-party lenses into the ecosystem, sadly - speaking as someone with three Nikon DSLRs and Sigma glass I'm very happy with.

I'm a software engineer not a firefighter, but my understanding is that it's significantly an experience thing. Lithium battery fires clearly aren't trivial to deal with and do burn hotter than petroleum fires, but they're also very much less frequent and firefighters are learning how to handle them.

I'm not sure what the specific issue would be with race tracks. The average road course is very open and a very controlled environment; if you had to deal with a car fire, it's probably among the best places to do so, thanks to lessons learned in the blood of previous generations of drivers and track workers.

Sure, it's a market with massive abuse potential, but we have a world full of them and we regulate to control the abuses. The underlying service is clearly of societal benefit and would clearly be profitable to all parties, so it's worth doing and working out the regulation to make it viable.

That's incredibly short-sighted, not least because the number of fires per vehicle is orders of magnitude higher for combustion vehicles. I'd be astonished if that made actuarial sense if actually investigated.

I've seen and used underground car chargers in multiple European cities. They're definitely viable.

Agreed, but they're not that complex to retrofit to a parking space. I can foresee a future where each space has a port and an account card reader - they'd make the buildings more valuable, the supplier to that space has a basically guaranteed income stream, and the government has an easy emissions reduction. Wins all round, so why wouldn't it happen?

Yes, but it's also a breaking change to a very large legacy codebase. I can't see it ever happening, sadly.