Live data from Hacker News

A portentous reunion

bcantrill.dtrace.org

41–49 of 49 posts

Re: A portentous reunion

#41
post #25

Yeah I mean people are talking about 'the eternal Sloptember' but the other side of that is - you know how everyone is nostalgic for 90s/early 2000s websites and all the silliness and creativity? Well that is happening now in programs and apps. Any fool can make a terribly-architected game/app to scratch his itch. Most of them are bad, and most won't last, but there's also a lot of fun.

Nobody criticizes people making AI slop for their own amusement. Nobody said anything for DALL-E generated random stuff. Similarly nobody cared about people's GeoCities pages.

People care about when AI is forced in production workloads with very little care. Those productions could be the government, insurance and healthcare systems. Getting prosecuted or denied for treatment by a black box is what makes them angry. People care when their bosses brag about and threaten them with layoffs.

Re: A portentous reunion

#42

Earlier quoted context omitted.

I'm curious whether you have any insights into why high quality LLM-assisted (or enabled?) projects seem so relatively rare? Instead it seems like the preponderant contribution is a deluge of low quality slop. You didn't share yours and Adam's prompts in the post, so I'm left wondering how much of the success of this project is attributable to your collective ability and experience (both with this particular project…

There exist a great many people in the world who think that the only important thing is having a good enough idea, and everything else is almost valueless by comparison. You've probably met them, people who say things like "I just need someone to code it, can you sign this NDA, what do you mean you want to be paid, it's just coding?" They exist in other formats too - blogs in the vein of "for exposure" cover the same…

Right, but most of them don't already work as software engineers, at least it hasn't been my experience of my colleagues. However, companies that are aggressively adopting AI coding tools aren't (at least nobody has shown it) getting better by any metric. So, what gives? Why, generally, isn't this kind of success story common?

Re: A portentous reunion

#43
post #41
post #25

Yeah I mean people are talking about 'the eternal Sloptember' but the other side of that is - you know how everyone is nostalgic for 90s/early 2000s websites and all the silliness and creativity? Well that is happening now in programs and apps. Any fool can make a terribly-architected game/app to scratch his itch. Most of them are bad, and most won't last, but there's also a lot of fun.

Nobody criticizes people making AI slop for their own amusement. Nobody said anything for DALL-E generated random stuff. Similarly nobody cared about people's GeoCities pages. People care about when AI is forced in production workloads with very little care. Those productions could be the government, insurance and healthcare systems. Getting prosecuted or denied for treatment by a black box is what makes them angry.…

I wasn't criticizing any of these arguments.

Re: A portentous reunion

#44

Earlier quoted context omitted.

> Why use Claude then? I don't understand this question in response to the quote preceding it. He just explained why Claude was useful in this instance.

It isn’t clear from all the quoatage but it was meant to follow my own thoughts on the progression of the piece. (1) There is concern for the future because of AI (2) so anyway we used AI for fun and giggles... No wait, stop. Why enable the training and the development for such a non-essential little thing? If AI is so concerning? Apparently because the concern is not evenly distributed.

Thank you for the explanation. I understand what you meant now.

Re: A portentous reunion

#45
post #17

Earlier quoted context omitted.

AI is absurdly, massively centralized though. You don't own it. You can't own it. Access can be removed at any time. This situation may not persist but it's not like traditional pillars of society have demonstrated any incentive or even a perception of obligation to act in the public interest lately.

Local LLMs are getting pretty darn good.

True, but presumably they weren't trained locally.

Re: A portentous reunion

#46

Earlier quoted context omitted.

There exist a great many people in the world who think that the only important thing is having a good enough idea, and everything else is almost valueless by comparison. You've probably met them, people who say things like "I just need someone to code it, can you sign this NDA, what do you mean you want to be paid, it's just coding?" They exist in other formats too - blogs in the vein of "for exposure" cover the same…

Right, but most of them don't already work as software engineers, at least it hasn't been my experience of my colleagues. However, companies that are aggressively adopting AI coding tools aren't (at least nobody has shown it) getting better by any metric. So, what gives? Why, generally, isn't this kind of success story common?

Because most tasks aren't "refresh this code from 10-20 years ago"?

If you needed an old piece of code at $WORK, you probably already paid the tax of refreshing it or replacing it.

This sort of task is similar in nature to something like "I have a 25yo unmaintained Linux driver, let's refresh it for modern Linux" - a great demonstration of the efficacy of these tools if you have the right-shaped task, but not a task that comes up repeatedly in most people's days.

Re: A portentous reunion

#47

Earlier quoted context omitted.

Right, but most of them don't already work as software engineers, at least it hasn't been my experience of my colleagues. However, companies that are aggressively adopting AI coding tools aren't (at least nobody has shown it) getting better by any metric. So, what gives? Why, generally, isn't this kind of success story common?

Because most tasks aren't "refresh this code from 10-20 years ago"? If you needed an old piece of code at $WORK, you probably already paid the tax of refreshing it or replacing it. This sort of task is similar in nature to something like "I have a 25yo unmaintained Linux driver, let's refresh it for modern Linux" - a great demonstration of the efficacy of these tools if you have the right-shaped task, but not a task…

That's a good point, this does seem qualitatively different. Like dialect translation. In that case the specification is really precise, it's just the old code. Building something new or adding functionality to existing software the spec is almost guaranteed to be more vague.

EDIT: this specificity seems important for language models but the harder I think about it the less sure I am that it's the right intuition..

Re: A portentous reunion

#48
post #9

I feel like the last 30 years are significantly less distinctive than the prior 30 (actually 70+) years. The 20s, 30s, 40s, 50s, 60s, 70s and 80s all had iconic and partitioned cultures that are instantly recognizable. I feel like that started to fade a bit in the 90s (what I call the Pottery Barn decade). The 2000s have felt more "alive" to me than the 90s but they're also significantly more post-modern and less dis…

While partitioning these cultural attitudes and artifacts by decades is a useful heuristic, I often feel like the actual cutoff point is around mid-decade. The late '80s feels closer the the early '90s than it does the early '80s.

Re: A portentous reunion

#49

Earlier quoted context omitted.

Because most tasks aren't "refresh this code from 10-20 years ago"? If you needed an old piece of code at $WORK, you probably already paid the tax of refreshing it or replacing it. This sort of task is similar in nature to something like "I have a 25yo unmaintained Linux driver, let's refresh it for modern Linux" - a great demonstration of the efficacy of these tools if you have the right-shaped task, but not a task…

That's a good point, this does seem qualitatively different. Like dialect translation. In that case the specification is really precise, it's just the old code. Building something new or adding functionality to existing software the spec is almost guaranteed to be more vague. EDIT: this specificity seems important for language models but the harder I think about it the less sure I am that it's the right intuition..

My intuition is that what makes them well suited is that the transformations on the input desired are well-defined and frequent tasks - e.g. any other software that migrated from, say, SDL1 to SDL2, or had to move from gcc 3 to 4, or Sun cc to gcc, had to have these transformations in their source history.

IOW, "there is probably very little stopping you except time from having written Coccinelle patches to mechanically do most of these transformations".

Post reply on HN