Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The peril of laziness lost

bcantrill.dtrace.org

Post reply on HN
Print view View original

61–70 of 148 posts

Re: The peril of laziness lost

#61

Post by lovich »

ChosenEnd wrote: post #42
dijit wrote: post #36

Earlier quoted context omitted.

I think we put too much negative emphasis on people who aren’t as gifted intellectually. In reality, the world works because of human automotons, honest people doing honest work; living their life in hopefully a comforting, complete and wholesome way, quietly contributing their piece to society. There is no shame in this, yet we act as though there is.

Human automatons? Why would you have mercy for automatons? Just call them cattle, we might feel more compassion towards them if we don't think of them as machinelike.

I don’t know why you’re being downvoted. Using that sort of terminology already shows you don’t care about them more than the sort of energy someone has saying they would never consider keying _their_ car.

People don’t need to be exceptional to have intrinsic value.

Re: The peril of laziness lost

#62

Post by analog31 »

dijit wrote: post #36
quantummagic wrote: post #25

Earlier quoted context omitted.

Where my fellow ninety-percenters at?

I think we put too much negative emphasis on people who aren’t as gifted intellectually. In reality, the world works because of human automotons, honest people doing honest work; living their life in hopefully a comforting, complete and wholesome way, quietly contributing their piece to society. There is no shame in this, yet we act as though there is.

I'm not blaming you here, but I think "automatons" may be inaccurate. A lot of the jobs that seem menial would be utterly bollixed if done by an automaton. The people continually handle the edge cases and tiny discrepancies between formal procedures and how things actually work. Consider the many stories of people experience AI bots when they try to get vendor support for products. "Please let me talk to a real person."

Many of those people, probably including most bureaucrats, are working on systems that have already been automated to the fullest extent possible. This is one of the reasons why bureaucracies seem chaotic and inefficient -- the stuff that works is happening automatically and is invisible. You only see the exceptions.

The automation can be improved, but it's a laborious process and fraught with the risks associated with the software crisis. You never know when a project is going to fall into the abyss and never emerge, and the best models of project failure are stochastic.

Re: The peril of laziness lost

#63

Post by fao_ »

lotsofpulp wrote: post #43
fao_ wrote: post #8

Earlier quoted context omitted.

Yeah! It's not like code quality matters in terms of negative value or lives lost, right?! https://en.wikipedia.org/wiki/Horizon_IT_scandal Furthermore, > As for the artifact that Tan was building with such frenetic energy, I was broadly ignoring it. Polish software engineer Gregorein, however, took it apart, and the results are at once predictable, hilarious and instructive: A single load of Tan’s "newsletter-blog-t…

The Horizon IT scandal was not caused by poor code quality, the scandal was the corrupt employees of the UK government/Post Office. Poor quality code might have caused the error, but the failure to investigate the errors and sweep them under the rug was made by humans.

> Poor quality code might have caused the error, but the failure to investigate the errors and sweep them under the rug was made by humans.

That's not quite correct.

The root set of errors were made by the accounting software. The branch sets of errors were made by humans taking Horizon IT's word for it that there was no fault in the code, and instead blaming the workers for the differences in the balance sheets.

If there were no errors in the accounting software (i.e. it had been properly designed and tested), then none of that would have happened.

Nobody blames THERAC-25 on the human operator.

Re: The peril of laziness lost

#65

Post by gpm »

colechristensen wrote: post #46
btrettel wrote: post #24

Similar to bragging about LOC, I have noticed in my own field of computational fluid dynamics that some vibe coders brag about how large or rigorous their test suites are. The problem is that whenever I look more closely into the tests, the tests are not outstanding and less rigorous than my own manually created tests. There often are big gaps in vibe coded tests. I don't care if you have 1 million tests. 1 million e…

It's a struggle to get LLMs to generate tests that aren't entirely stupid. Like grepping source code for a string. or assert(1==1, true) You have to have a curated list of every kind of test not to write or you get hundreds of pointless-at-best tests.

> have a curated list of every kind of test not to write

I've seen a lot of people interact with LLMs like this and I'm skeptical.

It's not how you'd "teach" a human (effectively). Teaching (humans) with positive examples is generally much more effective than with negative examples. You'd show them examples of good tests to write, discuss the properties you want, etc...

I try to interact with LLMs the same way. I certainly wouldn't say I've solved "how to interact with LLMs" but it seems to at least mostly work - though I haven't done any (pseudo-)scientific comparison testing or anything.

I'm curious if anyone else has opinions on what the best approach is here? Especially if backed up by actual data.

Re: The peril of laziness lost

#66

Post by raincole »

suzzer99 wrote: post #3

> Generally, though, most of us need to think about using more abstraction rather than less. Maybe this was true when Programming Perl was written, but I see the opposite much more often now. I'm a big fan of WET - Write Everything Twice (stolen from comments here), then the third time think about maybe creating a new abstraction.

I agree. It's crazy how many layers of abstraction have been created since 1991 (when Programming Perl was published.)

Re: The peril of laziness lost

#67

Post by 0xBA5ED »

simianwords wrote: post #11
lapcat wrote: post #10

Earlier quoted context omitted.

> This is a person clearly grieving that his hard earned knowledge in his field is now not that valuable. He's co-founder and CTO of his own company, so I think he's doing fine in his field.

It doesn't change the fact that much of what (I think) he prides in himself in is getting commoditised.

I would seriously consider if you've developed an imaginary caricature in your mind that you apply to people you don't know. Further, I would consider if any living person actually lives up to it.

Re: The peril of laziness lost

#68

Post by flir »

8note wrote: post #15
fao_ wrote: post #8

Earlier quoted context omitted.

Yeah! It's not like code quality matters in terms of negative value or lives lost, right?! https://en.wikipedia.org/wiki/Horizon_IT_scandal Furthermore, > As for the artifact that Tan was building with such frenetic energy, I was broadly ignoring it. Polish software engineer Gregorein, however, took it apart, and the results are at once predictable, hilarious and instructive: A single load of Tan’s "newsletter-blog-t…

> included multiple test harnesses (!) ive seen plenty of real code written by real people with multiple test harnesses and multiple mocking libraries. its still kinda irrelevant to whether the code does anything useful; only a descriptor of the funding model

If I'm reading this correctly ("a single homepage load of http://garryslist.org downloads 6.42 MB across 169 requests"), the test harnesses were being downloaded by end users. They weren't being installed as devDependencies.

Re: The peril of laziness lost

#69

Post by love2read »

glitchc wrote: post #59

Hard disagree with the initial assumption: Abstractions do not make a system simpler. Note: I would have added usually but I really do mean always.

the thing about abstractions is that nothing implies that they aren’t leaky abstractions, which may be worse than no abstraction for future bug hunters

Re: The peril of laziness lost

#70

Post by btrettel »

colechristensen wrote: post #46
btrettel wrote: post #24

Similar to bragging about LOC, I have noticed in my own field of computational fluid dynamics that some vibe coders brag about how large or rigorous their test suites are. The problem is that whenever I look more closely into the tests, the tests are not outstanding and less rigorous than my own manually created tests. There often are big gaps in vibe coded tests. I don't care if you have 1 million tests. 1 million e…

It's a struggle to get LLMs to generate tests that aren't entirely stupid. Like grepping source code for a string. or assert(1==1, true) You have to have a curated list of every kind of test not to write or you get hundreds of pointless-at-best tests.

What I've observed in computational fluid dynamics is that LLMs seem to grab common validation cases used often in the literature, regardless of the relevance to the problem at hand. "Lid-driven cavity" cases were used by the two vibe coded simulators I commented on at r/cfd, for instance. I never liked the lid-driven cavity problem because it rarely ever resembles an actual use case. A way better validation case would be an experiment on the same type of problem the user intends to solve. I think the lid-driven cavity problem is often picked in the literature because the geometry is easy to set up, not because it's relevant or particularly challenging. I don't know if this problem is due to vibe coders not actually having a particular use case in mind or LLMs overemphasizing what's common.

LLMs seem to also avoid checking the math of the simulator. In CFD, this is called verification. The comparisons are almost exclusively against experiments (validation), but it's possible for a model to be implemented incorrectly and for calibration of the model to hide that fact. It's common to check the order-of-accuracy of the numerical scheme to test whether it was implemented correctly, but I haven't seen any vibe coders do that. (LLMs definitely know about that procedure as I've asked multiple LLMs about it before. It's not an obscure procedure.)

Post reply on HN