←back to thread

179 points articsputnik | 2 comments | | HN request time: 0s | source
Show context
serbuvlad ◴[] No.45054479[source]
I think the whole AI vs non. AI debate is a bit besides the point. Engineers are stuck in the old paradigm of "perfect" algorithms.

I think the image you post at the beginning basically sums it up for me: ChatGPT o3/5 Thinking can one-shot 75% of most reasonably sized tasks I give it without breaking a sweat, but struggles with tweaks to get it to 100%. So I make those tweaks myself and I have cut my code writing task in half or one third of the time.

ChatGPT also knows more idioms and useful libraries than I do so I generally end up with cleaner code this way.

Ferrari's are still hand assembled but Ford's assembly line and machines help save up human labor even if the quality of a mass-produced item is less than a hand-crafted one. But if everything was hand-crafted, we would have no computers at all to program.

Programming and writing will become niche and humans will still be used where a quality higher than what AI can produce is needed. But most code will be done by minotaur human-ai teams, where the human has a minimal but necessary contribution to keep the AI on track... I mean, it already is.

replies(16): >>45054579 #>>45054647 #>>45054815 #>>45054948 #>>45054968 #>>45055113 #>>45055151 #>>45055212 #>>45055260 #>>45055308 #>>45055473 #>>45055512 #>>45055563 #>>45058219 #>>45060059 #>>45061019 #
godelski ◴[] No.45060059[source]

  > Engineers are stuck in the old paradigm of "perfect" algorithms.
Reminds me of a misinterpretation of Knuth.

  > Premature optimization is the root of all evil.
He was definitely knocking engineers for wanting to write "perfect" algorithms, but this quote also got bastardized to mean something different from what he said (happens to many clichés). All he said was "grab a fucking profiler before you optimize."

But now, I'm not sure a lot of programmers even know what a profiler is. When was the last time you saw someone profile their code?

Problem is we've taken the idea of "minimum viable product" too far. People are saying "Doesn't have to be perfect, just has to work." I think most people agree. But with the current state of things? I disagree that things even work. We're so far away from the question of optimization. It's bad enough that there are apps that require several gigs to just edit a 30kb document but FFS we're living in a world where Windows Hello crashes Microsoft Outlook. It's not the programs are ugly babies that could be better, they are monstrosities begging to be put to death.

I WISH we could talk about optimization. I WISH our problem was perfectionism. But right now our problem is that everything is a steaming pile of garbage and most people are just shrugging their arms like "it is the way it is". Just because you don't clean up that steaming pile of garbage doesn't mean someone else doesn't. So stop passing the buck.

replies(4): >>45060328 #>>45060535 #>>45060978 #>>45062567 #
mcv ◴[] No.45060978[source]
> When was the last time you saw someone profile their code?

A year ago. I heavily relied on one to optimize a complex data import that took an hour for a million line Excel file. The algorithm translated it to a graph according to a user-specified definition and would update an existing graph in neo4j, keeping the whole thing consistent.

The only other guy who understood the algorithm (a math PhD) thought it was as optimal as it could get. I used the profiler to find all the bottlenecks, which were all DB checks for the existence of nodes, and implemented custom indices to reduce import time from an hour to 3 minutes.

It did introduce a bunch of bugs that I had to fix, but I also discovered some bugs in the original algorithm.

It was one of my best programming experiences ever. Especially the payoff at the end when it went down from an hour to 3 minutes is a dopamine rush like never before. Now I want to optimize more code.

I don't think users cared, though; originally this work would take days by hand, so an hour was already pretty good. Now I made something fiendishly complex look trivial.

replies(1): >>45061795 #
godelski ◴[] No.45061795[source]

  > from an hour to 3 minutes
I sure bet that the users cared. Yeah, starting from a few days an hour feels great but you also get accustomed to it.

  > It did introduce a bunch of bugs that I had to fix, but I also discovered some bugs in the original algorithm.
I find this is extremely common when I profile code. It is just so easy to miss bugs. People get lulled into a false sense of security because tests pass but test just aren't enough. But for some reason when I say "tests aren't enough" people hear "I don't write tests."

Seeing those big improvements and knowing you did more than make it faster is always really rewarding. I hope you do do more optimization :) Just remember Knuth's advice. Because IO is a common problem and Big O isn't going to tell you about that one haha

replies(1): >>45062508 #
1. mcv ◴[] No.45062508[source]
Yeah, I first want to know there's an actual performance issue to fix. That's basically what Knuth said, and that's what I live by.

> People get lulled into a false sense of security because tests pass but test just aren't enough.

Users weren't using a particular feature because they said they didn't understand it. So we explained it, again and again. Turns out that feature was incredibly buggy and basically worked the way we claimed it did, only when it was used in the specific configuration we tested for. Add another node somewhere and weird stuff starts happening.

The tests looked good, and code coverage was great, but the fact that the tests run through all the branches of the code doesn't mean you're really testing for all behaviour. So I added tests for all configurations I could think of. I think that revealed another bug.

So look at the actual behaviour you need to test, not merely the code and branch coverage.

replies(1): >>45070644 #
2. godelski ◴[] No.45070644[source]

  > Yeah, I first want to know there's an actual performance issue to fix.
Honestly, I think profilers and debuggers can really help with this too.

  > So I added tests for all configurations I could think of. 
I think that's the key part. You can only test what you know or expect. So your tests can only be complete if you're omniscient.