> The problem isn't this weird gaslighting attempt that we just haven't let Claude in our hearts and souls yet which you seem to have determined is inevitable (spoiler alert, it is not),
I don't believe it's inevitable and in fact, I'm thoroughly against the use of tools like Claude.
My reference to "different stages of acceptance" was only to indicate that people have embraced these things to varying degrees, and it that it seems to be this difference which is causing conflict in discussions like this. (I doubt I will ever fully accept it. A lot needs to change for that to happen).
I didn't really have the "five stages of grief" in mind when I wrote it.
Agreed. The way to address it though, is through calm analysis and reason. The emotional language from both groups is not helping.
If there's one problem with Claude et al, it's that it's all happened way too quickly for people to keep up. We're all at different stages of acceptance and I think that's what we're seeing manifest in the various discussions.
> As a long-time open-source maintainer, I find all the second-guessing and armchair psychoanalysis here (not just in this comment, all over HN) about Tridge's motivations, state of mind, and so on incredibly off-putting.
Much of the language from both groups is incredibly off-putting, frankly. Tridge in his blog post describes people as "foaming at the mouth"?!
The rhetoric around this has gotten way too emotional from both groups.
Ferrari have long worked with third-party coachbuilders such as Pininfarina. I'm not sure how much autonomy Ive had over the final design, but if it's anything like the relationship with Pininfarina, etc. the design would have been a collaboration.
> Well, that and the fact that after the 48K beeper the 128K was never going to sound less than incredible
Some of the stuff people do with the 48k beeper is incredible though. Tim Follin's tunes for example are basically treating the beeper like a 1-bit DAC, with amazing results. https://www.youtube.com/watch?v=T42WuUpBuHE
I think there's a gap in the market for a much simpler type of git service. All I need is a remote host to which I can push projects for others to see. I don't particularly want pull requests, actions or anything like that.
Maybe a way of facilitating "releases" with compiled binary assets (built locally and uploaded).
Forks can be handled by people cloning the repository and uploading a new project.
If I remember correctly, it runs as a commodity and patches the socket library. Interestingly, the socket library was not re-entrant (unusual for Amiga libraries) so I had to patch the Exec OpenLibrary() function to monitor the loading of new copies of the socket library. But it's been a long time so memories are hazy.
It'll be interesting to see if it is still compiles and runs for modern AmigaOS, if any active Amiga programmers are around to see.
I agree. Dealing with different endianness has never been an issue so long as you're aware of where the boundaries are. A call to htons() or ntohs() (or the 32bit equivalents) was the solution. I would hope all modern languages have similar helper functions/macros.
> Farting around with Amigas in 2026 means actively choosing to make things harder for the sake of making things harder. Making that choice and still outsourcing the bulk of the craft and creative process is like claiming to be a passionate hobby cook while serving professionally catered dinners and pretending they're your own concoctions.
People wanting to explore the use of generative AI for vintage computers is happening not just for graphics but for code too.
I think in the case of code though, it's still interesting because I don't believe there's been any success yet. I hear of people having success with Claude in contemporary settings but it seems to fare less well when working for older computing platforms. There's a reason for that of course and it's worth exploring.
However, it will cease to be interesting as soon as the first person manages to create something substantial. At the point, the scene should probably shun it for the reasons stated in the quote.
I no longer drink in pubs but in my neck of the woods, the pubs that specialised in cask ale often had lined glasses.
The problem was that many people insisted on the glass being filled to the brim, because they felt they were being short changed. So it solved one problem but created another.
Yes, there are a few tools that do this. Looking at /bin and the softlinks that are there, the various xz tools do it (unxz, lzcat, etc.). Also, vim. vimdiff and view are just softlinks to vim.
The only difference is that those tools have chosen easy to remember names rather than embedding the arguments as metadata in the filename.
As a generalisation of the idea though, the blog post is neat.
I don't believe it's inevitable and in fact, I'm thoroughly against the use of tools like Claude.
My reference to "different stages of acceptance" was only to indicate that people have embraced these things to varying degrees, and it that it seems to be this difference which is causing conflict in discussions like this. (I doubt I will ever fully accept it. A lot needs to change for that to happen).
I didn't really have the "five stages of grief" in mind when I wrote it.