I think people in the LLM space are being far too impatient with the general public and their adoption. And I think they need to start thinking harder about building products that genuinely enrich people's lives. Look at how long home computing took to establish itself with the public, then the internet, and finally social media. None of these trends happened overnight, and some were accelerated by other technological advances (social media-> smartphones).
The adoption of these technologies spurned ton of innovation in these spaces, and I feel like with LLMs its the first time I've seen genuine frustration from the industry directed towards users for not adopting the technology fast enough. This attitude did not exist in the 1980s, it didn't exist in the 90s, and it didn't exist in the 00s/early 10s either.
Do you blame them for getting impatient? They’re burning cash and quickly running to a point of never being able to justify it. The hardware they buy will be replaced with even more expensive hardware before they start to make a profit. It’s not sustainable and the market hasn’t figured that out yet. At least they’re starting to question it.
Whether you like it or not - technology causes compression of life cycles. You have a hit product? Great - I expect you to have crazy high growth rate. That’s the expectation of a world that is so deeply interconnected.
Consumer-ready LLMs have been widely available to the public now nearly 4 years if you start counting at GPT 3.5. There's certainly some compression here but Karpathy does a good job of outlining how silo'd those experiences are: the bulk of the product penetration (based on headcount rather than token usage) is "derpy chatbots" (his words, not mine). Most of the actual token spend is likely done on the STEM side. We're talking about a technology today that currently only has significant penetration with <25M users.
People need to be patient and put in the work to build great products, rather than lament its slower-than-desired (albeit still quite fast) adoption curve.
The problem is you won't be faced with a binary choice of certain death or a single unknown AI cure: You will have a choice between several established protocols AND several unknown AI drugs. You doing a dice roll or do you want to make an educated decision?
"Vibe shift" is all the rage these days but one area where it's most apparent is modern software.
People of Raskin's vintage had a very humanist approach to computing. The mentality was very much an outgrowth of the cultural revolution of the 60s. Computer usage should be joyful rather than toiling. The computer should help you. It should make you feel good about what you create.
That stands in stark contrast today, where things are more hostile. Not just in terms of "Dark patterns", or writing off user needs for the sake of expediency... but even the way we talk about technology today. You need to use X, do Y or you're "not going to make it" / "escape the permanent underclass". It's bleak.
I recently restored a vintage Macintosh SE I picked up at VCF Midwest and despite its limitations that machine was an absolute JOY to use despite its limitations and nearly 40 years of age. This was a machine and software designed by Raskin's contemporaries and it shows.
> but even the way we talk about technology today. You need to use X, do Y or you're "not going to make it" / "escape the permanent underclass". It's bleak.
That's just how people market things these days, preying on desperation and fear of missing out. It's not how normal humans talk, I hope.
Software’s purpose is clearly shifting from “what’s good for the user” to “what’s good for the developer.” Instead of enabling me, software now seeks to lock me in. Instead of making my life easier, software decisions are made based on what makes developers’ jobs easier. Instead of being careful with my data, software now comes with giant legal terms that allow developers to be utterly careless with it. Software is now designed primarily to funnel money to the developer, not to bring joy to the user.
And look at this article’s HN discussion. Many people indignantly defending it. “It’s open source. If you don’t like it deleting your data, don’t use it!”
Computer nerds are a rare breed. We like to be right. And we like to be arrogant. And if we have a solution to a harmful problem… it’s your fault for not being “smart enough” and you suffer your consequences.
Maybe we aren’t so rare. I can think of another group that values enduring hardship over progress making things easier for everyone.
It's been a while (well, 8 months) since I used Claude Code, but what I can say is that I greatly enjoy using the plan mode that comes baked into omp (oh my pi), especially for tasks around firmware development. I recognize that has a very different workflow than webapps though.
While there are cultural forces at work pushing kids to college, you'll never free yourself from them until companies loosen educational requirements in job listings. And you cannot accomplish this with New York Times think-pieces.
Remember how thought leaders in the technology industry pontificated about how the resume would be obsolete once GitHub repositories and LinkedIn profiles became widespread - which they have - and yet to date the vast majority of technology hiring is done with a resume?
You're going to need a change in corporate cultural. And I should stress: corporate culture is a global affair; you cannot simply change the thinking of the typical American and assume that will immediately be reflected by a multinational corporation. Companies deeply value education, and will continue to do so, even if elite wordsmiths decide it's not that important.
I do not hold a college degree and my family carries no college debt, and when reviewing resumes I put very little weight on education, but I recognize I'm an anomaly in this industry.
Oh I'd say its real. Years ago I worked as that senior who divvied up the work to a team of 4 mid-level engineers in that exact fashion (they were mostly Latin American contractors with limited english). We actually shipped some good stuff too!
Unfortunately, looking back, I could easily see Claude replacing 3 out of 4 of those developers. Myself + one other dev + AI would probably would've shipped a bit more a little faster. With that said tokens aren't free so the net cost savings would've been 2 dev salaries maximum.
I'm there now. I have a team of low level engineers in Hyderabad and Bengaluru which can be useful but I have to spend a lot of time writing very detailed specifications and instructions to walk them through what has to be done. There are plenty of instances I can point to where it would have been faster for me to implement the solution myself, by hand, no Claude. Now bring Claude into the mix and I do not really have any use for these engineers at all aside from providing operational support during IST.
We're not too much an AI-friendly company yet, so we don't officially have Claude access, but I can tell with certainty that several of my Indian teammates are using Claude anyway. I'm pretty familiar with the style of code it creates. And the comments are decidedly better English, which is a big giveaway itself.
I feel like PA-RISC actually landed with a handful of useful somewhat-complex instructions. It always struck me as the best architecture from that era, making the correct trade-off of avoided microcode but adopted stuff like completers and shift-and-add operations to minimize instruction count and maximize work done per pipeline.
Yea, there were things like shift and add to do multiplication more efficiently, but they were all one-cycle instructions. It was very regular that way, all designed around a clean pipeline without a stalls or bypassing. But, consequently, it originally didn’t even have integer multiplication or division, just shift and add and a “divide step” that you could repeat/loop. Looking at the instruction set just now, I chuckled at how simple it was. It makes RISC-V look complex.
See: ftp.parisc-linux.org/docs/arch/pa11_acd.pdf
Edit: actually, it did have fixed point multiply via the floating point unit (opcode XMPYU). No fixed point divide, though.
Disagree: The era of " will eat your startup by throwing capital/devs at it" are over. Anthropic, OpenAI et al are under too much competitive pressure to chase every quixotic product idea.
The problem with Oracle is how much utterly and directly depends on them. They still are the authoritative source on "what is Java" and stuff like SAP directly depends on Java and in many cases Oracle Database (the supported alternatives are AFAIK IBM's mainframe stuff and MS SQL, but I only ever saw Oracle whenever I had the misfortune of having to dig into SAP).
If Oracle goes down, a lot of businesses are going to be in a lot of trouble, and there will be a lot of fighting over the scraps.
SAP has largely switched over to their own HANA database for new deployments. Even before that their "AnyDB" database worked with pretty much any backend and is still supported. The reason you see oracle has less to do with what SAP wants and more to do with "It's what the company/engineers have already used/set up in the past".
Regarding Java, SAP has long switched over to openjdk (though oracle java is supported in some cases).
Specifically, they have their own custom fork of openjdk "SapMachine" precisely to be independent from oracle (FYI: if you look at openjdk upstream you will see many core contributors are employed by SAP)
In general, I would say that the actual tech companies that have to interact with oracle's stuff are generally very well equipped to drop them or have already done so. The bigger issue are legacy "consumers" of oracle (e.g. if Pepsi has their data in oracle DB), which often do not have such contingencies.
It's rare for a large company to simply close down. Usually someone buys it out of bankruptcy, and keeps the profitable parts going. Database licensing definitely makes money.
The adoption of these technologies spurned ton of innovation in these spaces, and I feel like with LLMs its the first time I've seen genuine frustration from the industry directed towards users for not adopting the technology fast enough. This attitude did not exist in the 1980s, it didn't exist in the 90s, and it didn't exist in the 00s/early 10s either.
reply