We tried that in 90’s RAD environments like Foxpro and others. If it fits the problem, they were great! If not, it’s even worse than with an ORM.
They rarely fit today since they were all (or mostly) local-first or even local-only. Scaling was either not possible or pretty difficult.
Well that would explain it, plenty of Polestars around; I guess I knew somewhere in my mind that they owned Volvo/Polestar now but I totally forgot when writing that
https://www.bike-ev.com/news/cars/byds-270-europe-sales-surg...
But these numbers don't split out only EVs. So assuming these numbers are correct, BYD would be below even Geeley which seems... odd. It's probably availability bias, but I see BYD cars every day and that's not true for Geely.
The segmented type site that lets you see a bunch of different options reminded me of Posy's YouTube video where he investigates a bunch of weird options for these: https://youtu.be/RTB5XhjbgZA?si=y7npP6KfXlOGNoHZ
So I guess it really is true that nothing actually gets removed -- except the one that wasn't actually controlled by WhatWG or W3C.
Is there still a real-world use case for XHTML/"XML syntax for HTML", or is this just exhibit A that no standard can actually be removed from browsers?
Re: XSLT, back in the everything-is-XML days I desperately wanted to like XSLT, it seemed so useful (I was that annoying co-worker telling everyone it's supposed to be pronounced "exalt"). But it was such a disaster to actually write or read and no real debugging was possible, I had to use a LOT of conditional bgcolor=red to figure anything out. It didn't take very long to come to the conclusion that XPath was the only useful part.
One person's front-running is another's reference implementation.
Although, yes, CSS is getting more complex because everything on the web is. What's the last standard feature to really be taken away after actually existing in the wild for a while? XHTML and Flash (effectively a standard if not in reality)?
Sure, if by SaaS you mean hooking together software that is essentially websites. Major industrial software that costs thousands per seat like Ansys or Dassault are not getting replaced by something that "AI" can cobble together.
The parts of SAP that's composable workflow stuff? Doubt it, because the types of ABAP workflows in SAP that might be "malleable" are the sort of stuff that often legally requires correctness and reproducibility - kinda the exact opposite of a good LLM use-case.
And as much as I'd like to actually own my software, SaaS is preferable for major corporations for lots of legal and accounting reasons like easier revenue recognition. They're going to keep pushing it because it makes all the parts of being a software company that don't include writing the actual software easier.
Oddly, my bank has no problem with non-US IPs, but my City's municipal payments site doesn't. I always think it's broken for a moment before realizing I have my VPN turned on.
I think the only thing here that I don't agree with is that internal users are just users. Yes, they may be more technical - or likely other programmers, but they're busy too. Often they're building their own thing and don't have the time or ability to deal with your API churning.
If at all possible, take your time and dog-food your API before opening it up to others. Once it's opened, you're stuck and need to respect the "never break userspace" contract.
Pretty much everyone speaks English too, it's the official language of the company. Though we all try to be respectful; if I can't understand them then they tell me again in English. I try to respond as much as possible in German and switch to English if needed - there's also heavy use of deepl on my side which seems to be a lot more idiomatic than Google, MS, or Apple translate.
This is more like people arguing over "proper" English, the point of language is to communicate ideas. I work for a German company and my German is not great but if I can make myself understood, that's all that's needed. Likewise, the point of an API is to allow programs, systems, and people to interoperate. If it accomplishes that goal, it's fine and not worth fighting over.
If my API is supposed to rely on content-type, how many different representations do I need? JSON is a given anymore, and maybe XML, but why not plain text, why not PDF? My job isn't an academic paper, good enough to get the job done is going to have to be good enough.
I'm brand new to MCP and agents but was able to read the extra docs to get VSCode set up with Mastra. Then what? I only figured out the "start Mastra Course" because of their tweet where they show someone typing that into co-pilot.
There really needs to be more hand holding to get someone to the point where the course actually starts. From there I've been able to follow along alright, but it was a real battle to get to this point.
I've climbed this mountain of madness trying to calculate working hours elapsed before. It was easily the project I messed up on more than any other in my career. I'm glad I did it, I'm glad I learned a lot, and I hope to never have to work on something like that again. I'd rather spend the rest of my career untangling double & triple encoded character set problems.
The biggest problem is that if even programmers - who know this is hard, and has a lot of corner cases - mess it up, expect your requirements to be very very wrong with regards to special cases.
Come up with a list of example cases and ask what the expected output should be; but not just the corner cases, the normal examples too. There's a good chance even basic requirements regarding timezone conversions have not been thought about, or are wrong. Like the earlier post said, humans really only think in local time and for short periods in the future or past. Any conversion whatsoever can end up being pretty unintuitive (even if it's right).
If it has to do with scheduling, BE EXPLICIT. Show both (or more) local times and dates and let the user pick a time for either location. Maps with pins can be a very helpful UI affordance
https://www.enforcementtracker.com/statistics