> The real issue is we don’t commit people to psychiatric care when they’re clearly a problem in our society.
Where do you draw that line though? Are you really okay with committing people, i.e. imprisoning and medicating people, because society seems to find those people inconvenient?
Personally I've never understood any justification for committing a person without their consent. The line between being committed and being extra judicially imprisoned seems indistinguishable to me.
> Where do you draw that line though? Are you really okay with committing people, i.e. imprisoning [...] people, because society seems to find those people inconvenient?
Well, that's what prison is, for some value of "inconvenient".
The problem is that at some point, if someone refuses to abide by laws/social norms, and can't be coerced via fines, etc., then the only options the state, and society has are either imprisonment, or allowing those people to ignore laws/social norms. Clearly some social norms (e.g. serious crimes) we aren't okay with ignoring, so it's really just a question of what the threshold is where we do something vs. allowing people to disregard said laws/norms.
> Personally I've never understood any justification for committing a person without their consent. The line between being committed and being extra judicially imprisoned seems indistinguishable to me.
Presumably the process to commit someone can involve the judiciary, so it wouldn't be extra-judicial.
Part of the surge of mass incarceration was that people who would have been hospitalized in an earlier time now get warehoused in a place that isn’t equipped to treat them.
What scares me about deinstitutionalization is that there are ways that people can ‘exit’ as in: move to the suburbs, drive instead of take public transportation, order a private taxi for your burrito instead of go to a restaurant. If public spaces can’t protect themselves we’ll have nothing but private spaces.
Had you considered using something like XML as the transport format rather than JSON? If the UX is similar to zod it wouldn't matter what the underlying data format is, and XML is meant to support schemas unlike JSON.
JSON Schema is a schema built on JSON and it’s already being used. Using XML would mean converting the XML into JSON schema to define the response from the LLM.
That said, JSON is “language neutral” but also super convenient for JavaScript developers and typically more convenient for most people than XML.
Because most of the world uses JSON and has rich tooling for JSONSchemas, notable many LLM providers allow JSONSchemas to be part of the request when trying to get structured output
LLM providers allow sending any string of text though, right? In my experience the LLM understands XML really well, though obviously that doesn't negate them from understanding JSONSchema.
Why does that matter though? MCP is meant for LLMs not humans, and for something like this lib it seems the human side if the API is based on JavaScript not JSON.
They aren’t requiring it though - they are just noting it on your profile. That seems like a very reasonable approach that lets the reader decide how much it matters.
Try telling that to: Discord, Microsoft, Facebook, Paypal, Google, or most any major US based service.
Your account will get pre-locked due to "reputational quality" immediately. Usually, they then demand photo ID, phone number or app, or some other onerous process.
If you need a VPN but dont want this "bad quality VPN smell", what you're looking for is a "residential IP VPN". Those look and smell like a Comcast IP, but are VPNs.
Oh I know, I run into this frequently. I was on a work trip not long ago and had my Uber and Lyft accounts locked because (a) I use then infrequently and (b) I always have a VPN on when traveling.
If only we as an industry hadn't abandoned REST APIs none of this would be necessary.
We've known for decades that its useful for APIs to be self documented and for responses to use schemas to define the shape of the data.
XML can be verbose and I understand why people preferred JSON for ease use. Had we stuck with REST for the last 20 years we'd be way ahead on that front, though, both in syntax and tooling.
> Had we stuck with REST for the last 20 years we'd be way ahead on that front
We are where we are because there (sadly) hasn't been a reasonable business case to advance REST API documentation beyond the point of badly-documented OpenAPI schemas where the main utility is in generating type-safe API wrappers across different programming languages.
With MCP, there is at least a name to a new movement to build self-describing APIs, as with the advent of LLMs there is now enough of a utility for it. All other pushes into that direction have died out ~10 years ago.
Correct me if I'm wrong, but I thought OpenAPI was itself an attempt to wedge REST concepts back on top of mostly RPC-based APIs. I.e. add documentation and a standard set of schemas on top of JSON APIs (mostly).
I do think the problem is from business concerns, though, and are a clear predictor that MCP will fail. Coming out of the dotcom bubble those left standing wanted to build moats and walls, not APIs that any third party could easily discover and use. The need for REST only shows up when a new player makes a move to effectively gobble up the role of being the gate keeper to the internet. With scale other companies will follow, but begrudgingly and only for a short while.
Sadly not. One of the constraints of REST is that the API be completely self-descriptive. If you need out-of-band information like an API spec, then it's basically not RESTful by definition.
I'm using a REST API to read your comment and submit my response — I didn't need to reference external HN API docs. The interface here is fully self-describing.
I agree, but don't quite follow how your comment fits in here.
In a REST approach, I'd expect an LLM to need some kind of initial entry point, much like needing the initial URL for the HN home page. From there the LLM should be able to parse and discover possible actions, call those actions, and understand the response only by parsing the results and any schemas provided.
LLMs work great with REST so that's always still an option. MCPs have that nice third party plug and play experience but that doesn't mean we all have to build them.
I make tons of little REST APIs for my agents to use and in the AGENTS.md there's just a list of API entry points with descriptions on what they offer. Agents drive them with `curl` and it all works great.
We never really implemented REST APIs. We had a bunch of REST-ish APIs.
Anyway - the REST movement served it's purpose - it killed SOAP and forced everyone back to simpler HTTP APIs without tons of over-engineered XML layers so it did well.
I don't think animal products are all that expensive tbh. Chicken, milk, yogurt, eggs are all really cheap if you consider the protien content.
Completely unbeatable value especially factoring in time and convenience and heartiness is picking up a rotisserie chicken and a bag of frozen veggies.
Liver is also very affordable and extremely nutritious.
Of the four animal products you list there, only one is meat, and its a cheap meat...
Meat is not all that expensive for protein and comparatively quick and easy to cook, agreed, but the cheapest option is still veg.
Liver, and offal in general, is much underrated for both taste and health. A lot of people in the UK just do not eat it and its becoming hard to find (liver the common, but other things are not).
At least in my area, good quality meat isn't any more expensive than good quality produce. By "good meat" I mean at least pasture raised, and by "good produce" I mean at least organic.
I didnt vote one way or another but its odd to compare the cost of meat to the cost of produce. Far different calorie density and nutritional profile.
Maybe your point is that you spend about as much on meat as you do on produce, but that depends on your specific diet since they are not equivalent food groups.
The prior comments were discussing the cost of healthy meals.
Calories aren't a good measure of anything beyond burning your food. Unless your body works similar to a steam engine, it really doesn't matter how much energy you can put into water by setting your food on fire.
My point was simply that I spend roughly the cost of quality meat in my area is on par with or cheaper than quality produce given what I need to put into a meal to feel full and satiated. My point isn't that I eat only meat, I don't know the last time I had a meal that didn't also include vegetables or bread, for example. I was only calling out that one doesn't need to stick to vegetables for a reasonably priced healthy meal, at least where I live.
Also, no offense to anyone, but hearing that you should eat lentils and beans as the main for a healthy meal is as appealing as hearing you should eat only cardboard for a healthy meal.
The challenge with regulation is that its the result of those in charge of a power imbalance being able to decide what is "good" PR "bad."
Yes, some regulations will result in outcomes most might want and others may result in outcomes most don't want. In both cases, though, everyone not in power has to accept that they gave up some level of free will in hopes that those in charge will always wield that power well.
There's a lot of history behind WhatWG that revolves around XML.
WhatWG is focused on maintaining specs that browsers intend to implement and maintain. When Chrome, Firefox, and Safari agree to remove XSLT that effectively decides for WhatWG's removal of the spec.
I wouldn't put too much weight behind who originally proposed the removal. It's a pretty small world when it comes to web specifications, the discussions likely started between vendors before one decided to propose it.
The issue is you can’t say to put little weight who originally proposed the removal if the other poster is putting all the weight on Google, who didn’t even initially propose it
I wouldn't put weight on the initial proposer either way. As best I've been able to keep up with the topic, google has been the party leading the charge arguing for the removal. I thought they were also the first to announce their decision, though maybe my timing is off there.
By browser vendors, you mean? Yes it seems like they were in agreement and many here seem to think that was largely driven by google though that's speculation.
Users and web developers seemed much less on board though[1][2], enough that Google referenced that in their announcement.
Yes, that's what I mean. In this comment tree, you've said:
> google has been the party leading the charge arguing for the removal.
and
> many here seem to think that was largely driven by google though that's speculation
I'm saying that I don't see any evidence that this was "driven by google". All the evidence I see is that Google, Mozilla, and Apple were all pretty immediately in agreement that removing XSLT was the move they all wanted to make.
You're telling us that we shouldn't think too hard about the fact that a Mozilla staffer opened the request for removal, and that we should notice that Google "led the charge". It would be interesting if somebody could back that up with something besides vibes, because I don't even see how there was a charge to lead. Among the groups that agreed, that agreement appears to have been quick and unanimous.
In the github issues I have followed, including those linked above, I primarily saw Google engineers arguing for removing XSLT from the spec. I'm not saying they are the sole architects of the spec removal, and I'm not claiming to have seen all related discussions.
I am sharing my view, though, that Google engineers have been the majority share of browser engineer comments I've seen arguing for removing XSLT.
Given that you have experience working on libxslt, why do you think they should have removed the spec entirely rather than improving the current implementation or moving towards modern XSLT 3?
Vendoring dependencies is how I remember doing it for web projects pre-NPM. Find an open source, well tested library and copy the source into your project.
You have to manually update for any releases you care about, but that is also an incentive to keep dependency count low.
Where do you draw that line though? Are you really okay with committing people, i.e. imprisoning and medicating people, because society seems to find those people inconvenient?
Personally I've never understood any justification for committing a person without their consent. The line between being committed and being extra judicially imprisoned seems indistinguishable to me.
reply