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

131–140 of 148 posts

Re: The peril of laziness lost

#131

Post by theshrike79 »

simianwords wrote: post #33
vsgherzi wrote: post #29

Earlier quoted context omitted.

Disregarding the fact that Bryan operates oxide a company that has multiple investors and customers (id say this proves valuable knowledge) the crazier fact is that people think html is useless knowledge. React USES html. Understanding html is core to understanding react. React does not in anyway devalue html in the same way that driving automatic devalues driving manual

Go to Facebook.com and right click view source and tell me html is not being devalued. No person who wants to write aesthetic html would write that stuff.

Tbh this is like looking at any binary's assembly code and complaining it's "unasthetic".

Whatever blob of HTML the browser is offered is just the end result of multiple "compilation" steps. Nobody has spent a single iota of time thinking about whether it's pretty.

Just like opening any binary produces inelegant assembler.

Re: The peril of laziness lost

#132

Post by theshrike79 »

rakel_rakel wrote: post #31
simianwords wrote: post #7

This is a person clearly grieving that his hard earned knowledge in his field is now not that valuable. It is * exactly * the same as a person who spent years perfecting hand written HTML, just to face the wrath of React.

https://xkcd.com/1053/ I recommend you go look at some of his talks on Youtube, his best five talks are probably all in my all time top-ten list!

The content of his talks is very good, but his habit of SHOUTING all the time just grates my brain the wrong way. I can literally see the veins in his neck bulging as he screams out his presentation.

Re: The peril of laziness lost

#133

Post by eru »

CJefferson wrote: post #74
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…

Yes, I've found tests are the one thing I need to write. I then also need to be sure to keep 'git diff'ing the tests, to make sure claude doesn't decide to 'fix' the tests when it's code doesn't work. When I am rigourous about the tests, Claude has done an amazing job implementing some tricky algorithms from some difficult academic papers, saving me time overall, but it does require more babysitting than I would like…

You might want to look into property based testing, eg python-hypothesis, if you use that language. It's great, and even finds minimal counter-examples.

Re: The peril of laziness lost

#134

Post by eru »

senko wrote: post #124
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…

The “red/green TDD” (ie. actual tdd) and mutation testing (which LLMs can help with) are good ways to keep those tests under control. Not gonna help with the test code quality, but at least the tests are going to be relevant.

If you start with the failing tests, you can use them plus the spec to give to review to another agent (human or silicon).

It's a bit like pre-registering your study in medicine.

Re: The peril of laziness lost

#135

Post by michaelbuckbee »

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…

Two things:

1. Tests have always been both about the function of the application, but also the communication of what should be occurring to the larger team or yourself six months down the road.

With automated software development the communication with the LLM itself is a much larger part of it so I feel like it's "ok" to have lots of easy tests that are less about rigor and more about "yes this is how this should work"

2. Ideally we're going to get to the point where the tooling allows for adversarial agents with one writing code and one writing tests. Even for now just popping open a separate terminal window and generating+running tests in it from your main coding terminal is helpful.

Re: The peril of laziness lost

#136

Post by red_admiral »

> 37K LoC per day across 5 projects

I remember the days when we talked about mythical man-months and why LoC was not a good metric to measure programmer output. And then Ken Thompson said [1]

> One of my most productive days was throwing away 1000 lines of code.

Or the famous -2K LoC story:

> Bill Atkinson, the author of Quickdraw [...] had completely rewritten the region engine using a simpler, more general algorithm which, after some tweaking, made region operations almost six times faster. As a by-product, the rewrite also saved around 2,000 lines of code [...] it was time to fill out the management form for the first time. When he got to the lines of code part, he thought about it for a second, and then wrote in the number: -2000. [2]

[1] disputed: https://skeptics.stackexchange.com/questions/43800/did-the-c...

[2] https://www.folklore.org/Negative_2000_Lines_Of_Code.html

Re: The peril of laziness lost

#138

Post by juanre »

Should we be talking about LLMs' taste and proclivities? Because these can also be prompted. You can put your Claude or Codex in the mind of someone who remembers Larry Wall and his three virtues, and it will do a fantastic job at uncovering the lacking abstractions and poor quality _in someone else's code_.

The jury is still out in my mind. Can I use these tools to create software that does not suck? Will the speed at which code can be created and modified lead to a change in our ideas of what good code looks like?

Last week I had a good idea for a change in architecture in my software that will make it much more powerful. I set a team of 12 agents on it, mostly unsupervised, with a pretty weak org structure. After a day and a half, and way too many tokens spent, they managed to build the entirely wrong thing. All tests passed.

The next few days have been spent with a much simpler structure: two teams, each of two agents, one coding (Codex is better at it these days) and one reviewing and keeping things aligned with the docs (Claude). This may have worked, I am still not sure.

My best guess right now of how good software development will look like with these tools: the effort/tokens spent on reviewing needs to be commensurate with the effort spent on coding.

Re: The peril of laziness lost

#139

Post by jpfr »

hackable_sand wrote: post #78
badlucklottery wrote: post #4

Earlier quoted context omitted.

>WET - Write Everything Twice I've always heard this as the "Rule of three": https://en.wikipedia.org/wiki/Rule_of_three_(computer_progra...

Antymony with DRY

Probably the second rewrite is really tight with good abstractions and little repetition.

So no, the end result can still be DRY.

Re: The peril of laziness lost

#140

Post by skydhash »

HarHarVeryFunny wrote: post #81
wcarss wrote: post #58

Earlier quoted context omitted.

I agree with what you're saying about writing something twice or even three times to really understand it but I think you might have misunderstood the WET idea: as I understand it, it's meant in opposition to DRY, in the sense of "allow a second copy of the same code", and then when you need a third copy, start to consider introducing an abstraction, rather than religiously avoiding repeated code.

Personally, even for a prototype, I'd be using functions immediately as soon as I saw (or anticipated) I needed to do same thing twice - mainly so that if I want to change it later there is one place to change, not many. It's the same for production code of course, but when prototyping the code structure may be quite fluid and you want to keep making changes easy, not have to remember to update multiple copies of the…

The danger with people that claims to follow DRY is that they don’t check first that they are repeating yourself. As soon as they’re encounter similarity, they assume equality and rush to abstract it. But if one knows the domain enough to know that some logic is the same, not just similar, then no need to write it twice first.
Post reply on HN