Live data from Hacker News

Code is run more than read (2023)

olano.dev

51–60 of 110 posts

Re: Code is run more than read (2023)

#51
post #40

Earlier quoted context omitted.

Right but what I'm getting at is that there can be tradeoffs that might make designing for maintainability mean optimizing for something less important to the end user. Do you optimize an engine for how easy it is to replace a filter once or twice a year (most likely done by someone the average car-owner is already paying to change their oil for them), or do you optimize it for getting better gas mileage over every s…

Only TCO matters, that is the efficiency you actually optimize for, ie dollar per mile[1]not miles per gallon. If the car is going to need to be in shop for days needing you to have a replacement rental because the model is difficult to service and the cost of service itself is not cheap , that can easily outweigh any marginal mpg gain . Similarly because it is expensive and time consuming you may likely skip service…

I'm just gonna copy and paste a response to another similar comment:

The point that I am making (obviously, I think) is that tradeoffs exist, even if you don't think the right decision was made, your full view into the trade space is likely incomplete, or prioritizes something different than the engineers.

Putting some random number of hypothetical mpg improvement was clearly a mistake, but I assumed people here would be able to get the point I was trying to make, instead of getting riled up about the relationship (or lack thereof) of oil filters and fuel efficiency.

Re: Code is run more than read (2023)

#52
post #47

Earlier quoted context omitted.

What if there's an efficiency in engine design by placing the filter in the middle that leads to a +2mpg improvement for the driver? Or that it fails, on average, 22k miles later into it's life? Not all hard-to-repair-yourself designs are malicious...

We don't have magic oil filters which last even 22k miles. You should be replacing them every 6 months / 6k miles, or 12 months / 12k miles depending on your risk tolerance (some people suggest even half my short interval). Anyone who actually drives their car regularly will be doing an oil change at least twice a year. If an oil change takes more than 30 minutes of actual labour time of an inexperienced mechanic, it…

I'm just gonna copy and paste a response to another similar comment: The point that I am making (obviously, I think) is that tradeoffs exist, even if you don't think the right decision was made, your full view into the trade space is likely incomplete, or prioritizes something different than the engineers.

Putting some random number of hypothetical mpg improvement was clearly a mistake, but I assumed people here would be able to get the point I was trying to make, instead of getting riled up about the relationship (or lack thereof) of oil filters and fuel efficiency.

Re: Code is run more than read (2023)

#53

I've worked at some of the "top tier" finance firms over the years. It is absolutely astounding how much of them run on code that is: - very reliable aka it almost never breaks/fails - written in ways that makes you wonder what series of events led to such awful code For example: - A deployment system that used python to read and respond to raw HTTP requests. If you triggered a deployment, you had to leave the webpag…

This is getting to be possibly the most irritating thing I've seen on Hacker News since registering here. Every thread about a limitation of LLMs being immediately rebuked with "humans do that too."

It's a continuous object lesson in missing the point. A similar thing happened a few hours ago when an article was posted about a researcher who posted a fake paper about a fake disease to a pre-print server that LLMs picked up via RAG, telling people with vague symptoms that they had this non-existent disease. Lo and behold, commenters go in immediately saying "I'd be fooled too because I trust pre-print medical research." Except the article itself was intentionally ridiculous, opening by telling you it was fake, using obviously fake names, fictional characters from popular television. The only reason it fooled humans on Hacker News is because they don't bother reading the articles and respond only to headlines.

It's just like your code examples. Humans fail because we're lazy. Just like all animals, we have a strong instinct to preserve energy and expend effort only when provoked by fear, desire, or external coercion. The easiest possible code to write that seems to work on a single happy path using stupid workarounds is deemed good enough and allowed through. If your true purpose on a web discussion board is to bloviate and prove how smart you are rather than learn anything, why bother actually reading anything? The faster you comment, the better chance you have of getting noticed and upvoted anyway.

Humans are not actually stupid. We can write great code. We can read an obviously fake paper and understand that it's fake. We know how hierarchy of evidence and trust works if we bother to try. We're just incredibly lazy. LLMs are not lazy. Unlike animals, they have no idea how much energy they're using and don't care. Their human slaves will move heaven and earth and reallocate entire sectors of their national economies and land use policies to feed them as much as they will ever need. LLMs, however, do have far more concrete cognitive limitations brought about by the way they are trained without any grounding in hierarchy of evidence or the factual accuracy of the text the ingest. We've erected quite a bit of ingenious scaffolding with various forms of augmented context, input pre-processing, post-training model fine tuning, and whatever the heck else these brilliant human engineers are doing to create the latest generation of state of the art agents, but the models underneath still have this limitation.

Do we need more? Can the scaffolding alone compensate sufficiently to produce true genius at the level of a human who is actually motivated and trying? I have no idea. Maybe, maybe not, but it's really irritating that we can't even discuss the topic because it immediately drops into the tarpit of "well, you too." It's the discourse of toddlers. Can't we do better than this?

Re: Code is run more than read (2023)

#54

I've worked at some of the "top tier" finance firms over the years. It is absolutely astounding how much of them run on code that is: - very reliable aka it almost never breaks/fails - written in ways that makes you wonder what series of events led to such awful code For example: - A deployment system that used python to read and respond to raw HTTP requests. If you triggered a deployment, you had to leave the webpag…

[deleted]

Re: Code is run more than read (2023)

#55

Earlier quoted context omitted.

This is like saying you can get a 10% improvement in battery life by changing where you position the RAM on your motherboard. There is just no universe in which placing an oil filter in one location or another is going to make such a difference. You'd have to mount it completely outside the engine, say sitting as a cylinder on top of the hood, and even there you are not going to get a 2mpg improvement.

Sorry we're talking about a hypothetical car engine, and as an analogy to software development. I'm not an expert in designing car engines like you, but acting like this example being not fully realistic is some kind of "gotcha" for the point I'm making is really frustrating. The point that I am making (obviously, I think) is that tradeoffs exist, even if you don't think the right decision was made, your full view in…

No, the point is that the GP statement missed the point. Say we hear about a company laying off 10% of workers, and someone says "What if they needed to lay off those workers in order to meet their HIPAA obligations and protect user privacy?" Now clearly that would be an argument that is either bad faith, or just spectacularly uninformed. We do not then go on to discuss the relative importance of HIPAA compliance versus employment. The reason companies lay off workers is because of a decline in market demand or efforts at cost cutting. That is the reason. It's not to help the environment. It's not to protect customer data. It's not because this is the year of the Pig. Anyone who makes those arguments should get responded to in a way to clearly points out it is a specious argument.

The reason why automakers place serviceable parts in bad locations is due to either incompetence (If you are, say, Bentley) or malicious design (almost everyone else) -- e.g. they do not prioritize serviceability. Car makers really hate that ordinary people can repair their own vehicles. There were proposals in the 1960s to try to lock shut the hood so that car owners wouldn't be able to open it and service the cars on their own. Hyundai just announced that they will not allow car owners to retract their own parking brakes when they want to replace brake pads. You need a login with a website and prove that you are a professional mechanic before you can retract your own parking brakes. This is done, ostensibly, for "cyber security" reasons. But the real reason is that Hyundai does not want people to be able to service their own cars, they want you to take the car to a dealer. They also are not fans of independent mechanics, they would prefer if everyone that touched the car had a business relationship with Hyundai and was under contract with them. The fact that you can work on your car is an endless source of pain for manufacturers, and when they repeatedly make it hard to work on your car, or try to lock down parts so that you can't pull an old seat heater from the junkyard and use it to replace your own failed seat heater -- that is all part of the war on independent repair.

So what should be discussed is the environment of hostility to serviceability, everything from insisting that transmission oil is "lifetime" to forcing you to pay money to the manufacturer if you want to read the data from your sensors, or making it extremely hard to do simple things like changing a headlight or replacing a battery. All of that is part of the same issue, which is hostility to end user repair. It has nothing to do with improving gas mileage, or ending world hunger, or celebrating the Year of the Pig. These are all equally specious arguments.

Re: Code is run more than read (2023)

#56

I've worked at some of the "top tier" finance firms over the years. It is absolutely astounding how much of them run on code that is: - very reliable aka it almost never breaks/fails - written in ways that makes you wonder what series of events led to such awful code For example: - A deployment system that used python to read and respond to raw HTTP requests. If you triggered a deployment, you had to leave the webpag…

> LLMs write shitty code

LLMs regurgitate shitty code. They learned it entirely from people.

Re: Code is run more than read (2023)

#57
post #42

Earlier quoted context omitted.

Define "modern". I have a 2017 Civic and I've had to replace the battery a couple of times. There's a holding bar that needs to be removed before the battery can be taken out, but other than that the only real problem is the weight of the thing.

The Ford Maverick (2022+) requires removing the air intake to remove the car battery. This is fairly common across many new car models.

In general it looks like these kinds of changes are trying to make it harder for people to do this kind of basic maintenance themselves. Force you to go to the dealer.

Re: Code is run more than read (2023)

#58

Earlier quoted context omitted.

Sorry we're talking about a hypothetical car engine, and as an analogy to software development. I'm not an expert in designing car engines like you, but acting like this example being not fully realistic is some kind of "gotcha" for the point I'm making is really frustrating. The point that I am making (obviously, I think) is that tradeoffs exist, even if you don't think the right decision was made, your full view in…

No, the point is that the GP statement missed the point. Say we hear about a company laying off 10% of workers, and someone says "What if they needed to lay off those workers in order to meet their HIPAA obligations and protect user privacy?" Now clearly that would be an argument that is either bad faith, or just spectacularly uninformed. We do not then go on to discuss the relative importance of HIPAA compliance ver…

ok, glad you seem to have everything figure out so definitively

Re: Code is run more than read (2023)

#59

And cars are driven more than worked on, but putting the oil filter inaccessibly in the middle of the engine block is still an unforgiveable sin.

Try replacing the battery. Seems accessible enough at first, but ingenious engineering has made batteries the modern rubik's cube of auto maintenance.

I have a 2009 Citroen and the battery is secured with a bolt that is under the battery compartment and to access it you need to go under the car with a very long wrench, who engineered it is a psycho

Re: Code is run more than read (2023)

#60

Earlier quoted context omitted.

This is like saying you can get a 10% improvement in battery life by changing where you position the RAM on your motherboard. There is just no universe in which placing an oil filter in one location or another is going to make such a difference. You'd have to mount it completely outside the engine, say sitting as a cylinder on top of the hood, and even there you are not going to get a 2mpg improvement.

Sorry we're talking about a hypothetical car engine, and as an analogy to software development. I'm not an expert in designing car engines like you, but acting like this example being not fully realistic is some kind of "gotcha" for the point I'm making is really frustrating. The point that I am making (obviously, I think) is that tradeoffs exist, even if you don't think the right decision was made, your full view in…

You made a "well actually" comment in which you demonstrated your lack of knowledge on the topic, _and_ stated a truism which didn't apply to the thing you were replying to.

Yes, I'm sure most people on this website have ran into seemingly bad design choices which made sense once they knew more context. But that doesn't mean that all bad design choices are like this.

Specifically dumb oil filter placement is an example of such a case where the _only_ legitimate justification is design cost saving for the manufacturer (re-using an existing design meant for a different car).

You can maybe argue that saving on design costs (and I guess also re-tooling costs) is a saving that gets passed onto the consumer. But that consumer is unlikely to feel like they're saving much money when cars depreciate faster than ice cubes in the desert, and when their oil change is 2+ times more expensive every 6 months. Really that cost savings will only really benefit the manufacturer (well, at least until they tarnish their reputation).

Post reply on HN