Hacker Newsnew | past | comments | ask | show | jobs | submit | pc86's commentslogin

> California subsidizes the majority of states for example.

California doesn't pay taxes though, people in California do.

Not trying to be pedantic but this is a common framing that is, at its core, completely incorrect. States don't subsidize states because taxes aren't earmarked based on what state they came out of, it's all just government reallocation of wealth by one means or another.

Even if you were to accept this framing, California's net contribution does not cover the shortfall from 26 states, so the statement would be wrong even if it wasn't deceptive.


The point is that taxes can be allocated to things you do not directly benefit from.

I am aware of the fact that states do not subsidize states, but actually drilling down to the taxpayer level makes the argument even stronger. As long as there are regional differences in benefits from federal funding, you get the same effect.

The farming states benefit disproportionately from farm subsidies. Oil producing states benefit disproportionately from oil subsidies. And states near DC benefit disproportionately from federal bureaucracies.


> It would be interesting to understand what people with down syndrome feel about this.

Would it?

> Would they all want what makes them unique turned off?

Having a disability doesn't make you unique, it makes you disabled. There is a difference.

> 99% of people with Down syndrome were happy with their lives; 97% liked who they are; 96% liked how they looked; 99% expressed love for their families; 97% liked their brothers and sisters; 86% felt they could make friends easily.

Survey their parents, who are almost certainly their full-time caregivers, if they are "happy their child has Down syndrome."


If the kinds survive long enough to outlive their parents as many do now, ask them again how happy they are once their home life transitions into an institutional one.

Yeah thats why all new expecting parents (here in Switzerland at least) have blood checks for exactly this and there is a reason its done before crossing the legal limit for abortion.

Respect to every single parent who does their best for their kids, but raising kids these days in western society is very hard and taxing even in best case scenario.


> - No trust that they won't nerf the tool/model behind the feature

To the contrary, they've proven again and again and again they'll absolutely do that the first chance they get.


You can lessen your dependence on the specific details of how /loop, code routines, etc. work by asking the LLM to do simpler tasks, and instead, having a proper workflow engine be in charge of the workflow aspects.

For example, this demo (https://github.com/barnum-circus/barnum/tree/master/demos/co...) converts a folder of files from JS to TS. It's something an LLM could (probably) do a decent job of, but 1. not necessarily reliably, and 2. you can write a much more complicated workflow (e.g. retry logic, timeout logic, adding additional checks like "don't use as casts", etc), 3. you can be much more token efficient, and 4. you can be LLM agnostic.

So, IMO, in the presence of tools like that, you shouldn't bother using /loop, code routines, etc.


One thing my team lead is working on is using Claude to 'generate' integration tests/add new tests to e2e runs.

Straight up asking Claude to run the tests, or to generate a test, could result in potential inconsistencies between runs or between tests, between models, and so on, so instead he created a tool which defines a test, inputs and outputs and some details. Now we have a system where we have a directory full of markdown files describing a test suite, parameters, test cases, error cases, etc., and Claude generates the usage of the tool instead.

This means that whatever variation Claude, or any other LLM, might have run-to-run or drift over time, it all still has to be funneled through a strictly defined filter to ensure we're doing the same things the same way over time.


I'm looking at implementing https://github.com/coleam00/Archon as a means to solve this. You can build arbitrary workflows custom to your codebase. Looks to bring a bit of much-needed determinism.

What kind of system/area (or product) are you working on?

>You can lessen your dependence on the specific details of how /loop, code routines, etc. work by asking the LLM to do simpler tasks, and instead, having a proper workflow engine be in charge of the workflow aspects.

Or, you know, by writing the code yourself?



"You can lessen your dependence on a specific LLM implementation by not using LLMs" is certainly a take but it doesn't really address the root issue of models getting nerfed to save resources after they've gained wide adoption.

A simple task ("convert this file from JS to TS, here are the types of all imported things") is much more likely to continue to work with a nerfed model compared to a complicated task ("convert this repo to TS, make sure to run tsc afterward and fix all errors"). The former is a subtask of the latter!

Taking a moment to create a workflow where these steps are separated (or rather, having an LLM build this workflow) and the LLMs are asked to just do minor leaf tasks increases your resilience to nerfed models.


MT3 really is a fantastic profile.

Both variants are great but I'm particularly fond of the PBT version. The slightly rough/matte texture that doesn't wear away easily and exaggerated dome shapes are sublime to use.

If you need to be an attorney to figure out if you're allowed to take a picture of something, we've already jumped the shark.

Not what he asked.

I mean maybe if you take a super pedantic, weaponized autism type of interpretation of the very first question, sure.

I agree with you generally but taken to the extreme this argument very easily goes to "precedents I agree with should be venerated because they're precedents and precedents I disagree with are wrong" silliness.

"Precedent is often crap" isn't really the basis for any cohesive judicial philosophy or legal thought process.

I'm not aware of any precedent anywhere that approaches "ALPRs violate 4A" territory, it's when other stuff happens that's beyond simply "$lp_id was seen by $camera on $datetime" that I've seen courts start to talk about reasonableness and privacy.


Cameras like Flock which fingerprint the driver and non-registration vehicle information (e.g. light brightness, damage, driving style, etc.) to generate a best-guess as to the driver of the car absolutely does.

Cool, what does that have to do with anything?

Oppressor and activist may sometimes use the same tools.

The activist needs to first go to where the people are.


Lots of 4,000 year old complaints about copper, I would imagine.

If you look at the top of this page you'll see an article with data.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: