Hacker Newsnew | past | comments | ask | show | jobs | submit | danpalmer's commentslogin

> It's reasonable to assume that if AI drop-in-replaced all those knowledge workers, AI companies could credibly charge somewhere in that order of magnitude, because that's what the market is already bearing

This assumes you don't change the market, but at the scale of (checks notes...) "all knowledge work", that just doesn't hold.

For example if you put 1bn people out of work, you now need some sort of safety net to bail out much of that workforce, a truly unprecedented change. You also lose tens of trillions of dollars of tax revenue.

One solution might be to recoup that cost and lost tax revenue from businesses by raising corporation tax. If corporation tax went from low tens of percent to high tens of percent, would those businesses be able to afford all that AI? No. Same order of magnitude? I doubt it.

There are many possible futures there, but the simplification made in the parent comment is completely unrealistic. The article is right in calling out the valuations as crazy.


The changes that AI technology bring are unprecedented, it’s hard to predict what the impact of widespread adoption will look like. Probably collapse of price as a decentralized mechanism of ressource allocation, and a deep inevitable paradigm shift in economics and politics. It’s as if the actual value of those companies can’t be reliably pinned on any currency amount!

It's a tech bro thing. Altman does it too, and I've worked with people in the past who do it.

I read it as "I'll take literally any conscience for myself no matter how minor, at any cost for you no matter how big".


why take the least charitable possible reading D; i've always read and intended it as inviting informality. i also don't find it harder to read at all (most people don't know some find it harder to read: i didn't)

I didn't take it any particular way besides maybe a hint of informality. Regardless it definitely threw off my reading in an unpleasant way. Anecdata point for the poster maybe. I would read again.

it's an internet thing. people were typing lowercase on IRC in the 90s.

there is a very big difference between starting an ephemeral instant message without capitalization, and lacking capitalization throughout a more "persistent" long-term medium

It's not derived from that. Most people don't use IRC anymore and there are basically no open chat platforms left. Most people now use phones to chat, where the keyboard automatically changes case for you after finishing a sentence.

So typing in all lowercase is a choice. I think it's a way to signal "I don't follow norms". It signals membership in a group.


I actually think of it as a tumblr thing. Like my first thought whenI see it is that the person who wrote this runs in queer or activist circles.

Not my read on OP, but “tech bro” is not my first thought associated with the style


Sure, but installing a chess program is child/teen level general ability, and playing chess well is highly trained expert level ability. Which one are we sold AI as being?

I think we are being sold AI as expert only when given tools (although that is not emphasized). The (quasi?) miracle of AI right now is that you can get an agent to accomplish the task of a team of intelligent but not exceptional humans at speeds far exceeding what the human could do. Which makes it “cheap” to throw (effectively) dozens of teams at a problem for the equivalent of hundreds of man hours.

That may not be the AI of sci fi fantasy but it’s still a game changing reality.


> The reason ... is because the cost of one bug is many, many orders of magnitude higher than software. Both in dollar cost and in schedule cost (it takes months ... and if you messed up and need to spin a fix, it costs tens of millions of dollars, not counting any design engineering cost).

Aren't you just describing waterfall? That's still very prevalent in software engineering, and pretty much any other type of engineering – civil, chemical, building, architecture, drug discovery.

It's typically true that software can fail faster and cheaper, but it's also true that the costs are still vastly higher to fix later in the process.


No. Silicon is on another level. Which is why the EDA verification is an industry on its own.

Sure, there are some software that have similar "can't have bugs" requirements. I imagine the computers on Moon missions also had that kind of high bar. I wouldn't use NASA requirements as a proof for how LLMs should be used.


We've had technology beating humans on memory for millennia, and we've had technology beating humans on computation for many decades now.

The tricky thing with LLMs is describing what they actually do. They are too clearly beating humans on some things, but what exactly? Memory – already done, they're bad at basic computation (all LLMs just write code for actual computation/calculation). And as you say, they do badly at more abstract concepts.


What do you mean, there's a screenshot link right there in the docs: https://docs.rs/crate/relm4/assets/screenshots /s


Setting aside incentives – because I think that's very fair to push back on, we should strive for better craft...

I find Blow in particular a bit naive when it comes to the complexity of modern non-game software. Games are very complex, but Blow puts them on a pedestal separate from other software, as if a web backend can't be as complex. He calls software slow while simultaneously ignoring most of the functionality.

He's essentially never had to deal with distributed systems, or anything that allows multiple users to use the same system, with all the performance and anti-abuse issues that come with that.

His opinions about game development are insightful, and his thoughts on craft can be quite inspiring, but I think he could benefit from a stint on a (good) big tech server team to see some of the things he's currently missing.


Heh heh heh. In actuality, Jon Blow has plenty of experience with distributed and multi-user systems. I worked closely with him while we were developing TinyMUCK 2.x, and the MUF programming language, a stack-based, simplified Forth.

In fact, Jon played a crucial role in the invention of the first MUF worm. We had just finished an extension to MUF that permitted triggering programs wherever a text string was expected. This gave a great flexibility and functionality to run MUF programs passively, by third parties, all kinds of new ways.

Unfortunately this also gave rise to a "worm" type of MUF that replicated itself whenever it was triggered passively. We went a little crazy when this was discovered, but it was all part and parcel of a multi-user game system, where there were permissions to consider, and multiple read/write/execute access to objects that should be owned by their respective player characters.

Jon Blow also inspired a lot of my exploits as I tested other systems of MUD programmability. In that time, TinyMUSH was also experimenting with a language that was more akin to scripting, and boy was it vulnerable. TinyMOO was also coming out, with a rather revolutionary programming paradigm. So in the mid-1990s, just in the insular TinyMU* world, there were at least 3 branches of programmable MUDs being actively developed.

Hopefully Jon could recall my greatest contribution to the corpus of early MUF programs. On Atlantis MUCK, I programmed a simulation of Conway's Game of Life. Of course, there was no animation possible and there was no multithreaded execution possible, either. So my program was given a starting board of Life, and then computed each frame in sequence, output it into the text stream of the game, and terminated after N iterations. Meanwhile, the entire game server locked up, because it could only run one MUF program at a time. Everyone else's commands and input would be held until my MUF program finished running.

This was a real issue, of course, and Jon and I worked to mitigate the problems caused. I think, ultimately, we just limited the number of iterations or the number of instructions that could be executed by any one MUF program at a time.

But Jon and I collaborated on a tutorial for player-programmers, and he helped us find and extinguish many bugs. And these were very complex systems, with 64 or even 256 simultaneous players.

Perhaps Jon has forgotten some of those lessons, but perhaps not.


Fair enough! That's some good experience and should address some of what I've heard from him, but perhaps he has forgotten.

That said, and this is coming from someone who (sadly) missed the era of computing you're describing, I think there's still a difference between dealing with a 64-256 player multiplayer system, and scaling a server application across dozens? thousands? of machines, across the world.

My limited research suggests that MUDs run almost exclusively on a single machine (?), or even just having a small number in one location drastically simplifies the problem space.


It's hard because you have to constantly make "sub-optimal" decisions. If you optimise for things you can measure, or at least see right now, you get a low performing team of high performers, or you get a collection of local maxima. Optimising for a global maximum requires making decisions that have unclear pay-off, that are harder to justify. Another problem is that one of these decisions that was actually wrong, vs one that hasn't paid off yet, look the same.

I suspect executives very much get it, but realise that there's no obviously good answer here.


Part of me wonders whether trying to optimise at all is the problem.

The worst managers I've had were optimisers (and had the worst teams), and the best managers with the best teams weren't optimisers.

The best ones didn't care about metrics at all, but would work to get their teams the tools and/or conditions they wanted to do a good job. Of course it probably only works with a certain level of talent and alignment in the team


There's also the executive's incentives, and "I'll be gone, you'll be gone": the payoff for that is very long, and it will be hard for them to take credit, and their own tenure might not be as long as that team's.


There's one caveat to this – I think it's good to have bias to other people's actions early on in a new role. Taking on little projects that are already understood, taking on cleanups, things other people aren't volunteering for, is all a great way to find where some of the bodies are buried, understand how the team works, and prove yourself as a team player.


Which British businesses provide this sort of infrastructure?

I ask this as a Brit who ran stuff on a few UK providers, and ultimately moved to a cloud platform because of the combination of terrible service and lack of features. The landscape may have changed, but in my experience it was bleak circa 2020.


There's a now dead comment giving a few options. One of those options was the main driver for my previous company moving fully to GCP, they were atrocious and caused a major security incident for us. They also regularly took days to action urgent fixes.

I'm not saying the UK doesn't have data centres, but it's easy to do a crap job of running one. In my experience there's a level of competence that is missing from UK operations. Hetzner and OVH are noticeably better, but still not quite at the level of the main cloud providers.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: