"Part of the initial excitement in programming is easy to explain: just the fact that when you tell the computer to do something, it will do it. Unerringly. Forever. Without a complaint.

And that’s interesting in itself.

But blind obedience on its own, while initially fascinating, obviously does not make for a very likeable companion. What makes programming so engaging is that, while you can make the computer do what you want, you have to figure out how."[0]

- [0] https://www.brynmawr.edu/inside/academic-information/departm...

> in coding, L.L.M.s take away the drudgery and leave the human, soulful parts to you.

I've always hated solving puzzles with my deterministic toolbox, learning along the way and producing something of value at the end.

Glad that's finally over so I can focus on the soulful art of micromanaging chatbots with markdown instead.

I like designing data, algorithms, and systems. I like picking the right tools for the job. I like making architectural and user interface (CLI, configuration format, GUI, whatever) decisions.

Actually typing code is pretty dull. To the extent that I rarely do it full time (basically only when prototyping or making very simple scripts etc.), even though I love making things.

So for me, personally, LLMs are great. I'm making more software (and hardware) than ever, mostly just to scratch an itch.

Those people that really love it should be fine. Hobbies aren't supposed to make you money anyway.

I don't have much interest in maintaining the existence of software development/engineering (or anything else) as a profession if it turns out it's not necessary. Not that I think that's really what's happening. Software engineering will continue as a profession. Many developers have been doing barely useful glue work (often as a result of bad/overcomplicated abstractions and tooling in the first place, IMO) and perhaps that won't be needed, but plenty more engineers will continue to design and build things just more effectively and with better tools.

The assembly line has been mass producing ready-made products for over 100 years and yet product quality, material stability, aesthetic trends, and function design still dominate the purchasing decisions of the general public.

Being tapped into fickle human preference and changing utility landscape will be necessary for a long time still. It may get faster and easier to build, but tastemakers and craftsmen still have heavy sway over markets than can mass-produce vanilla products.

> The assembly line has been mass producing ready-made products for over 100 years and yet product quality, material stability

Luckily if you want stability or quality they are nowhere to be found.

I would generally put “stability” and “quality” as attributes of mass production far more than that of handmade things. Yes, an expert can make a quality product by hand, but MOST handmade things are far more likely to be shoddy. The whole point of mass production was that suddenly you could make a million identical perfect products.

True, but motivations for mass production also are motivations for making things worse off overall.

Agree with this. I think LLMs allow more time to bring these things to the fore and more leverage to do them cost efficiently.

I think reducing what LLMs do to « typing » is misleading. If it was just typing, you could simply use speech-to-text. But LLMs do far more than that, they shape the code itself. And I think we lose something when we delegate that work to LLMs

We do lose something, but really I still see it as an extension of autocomplete.

I had some pieces of code I wrote I was quite proud of: well documented, clear code yet clever designs and algorithm.

But really what always mattered most to me was designing the solution. Then the coding part, even though I take some pride in the code I write, was most a mean to an end. Especially once I start having to add things like data validation and API layers, plotting analysis results and so many other things that are time consuming but easy and imho not very rewarding

To me its just a natural evolution of the search engine.

And now looking back its an obvious outcome. The search engine of the time was the best way to find websites. But those websites grew in quantity and volume over time with information.. that information as we know is/was a vital input for LLMs.

Agreed. Also, it takes time to understand a domain properly- so the innate slowness of coding helps with letting things “simmer” in the back of the mind.

It’s not that they replace the act of typing, so much as figuring out how to express the specific algorithm or data structure in a given programming language, typing that, debugging it, etc.

Once I can describe something well, that’s most of the interesting part (to me) done.

with an LLM, you can have an ill formed idea, and let the LLM mold it into a shape to your liking, without having the investment required to learn how to do molding first.

The art is to decide when shaping the code yourself is worth your time. Not only financially but also experience gain and job satisfaction.

To read it in a kinder way, I can focus on a complex logic problem, a flow, an architecture or micro optimisation. I can have an llm setup the test harnesses.

I improved test speed which was fun, I had an llm write a nice analysis front end to the test timing which would have taken time but just wasn’t interesting or hard.

Ask yourself if there are tasks you have to do which you would rather just have done? You’d install a package if it existed or hand off the work to a junior if that process was easy enough, that kind of thing. Those are places you could probably use an LLM.

> Ask yourself if there are tasks you have to do which you would rather just have done?

Yeah. My laundry, my dishes, my cooking...

You know. Chores.

Not my software, I actually enjoy building that

I enjoy solving interesting problems in software. But when I was doing it for a living, the majority of my work was pretty tedious. I'd have been thrilled to turn over that part to AI and spend all my time doing the interesting stuff.

This is a fools errand

We are paid to do the tedious stuff because it is tedious. If we actually ever succeed in automating away the tedious stuff, we're out of work

Don’t you get it? Machine do the tedious work, all we get to do now is the fun part and we can just relax the rest of the day.

I am producing 5x as before, my boss is paying me the same salary just for two hours of actual work per day. I have so much more time to pursue my passions.

Isn’t the future great?

I'm surprised you've had three replies so far that didn't notice your sarcasm.

But we've been automating the tedious work since the 1950s. There were probably devs back then complaining about imminent job loss when the first compilers were invented. Maybe some jobs were lost, temporarily, but ultimately we all got more ambitious about what software we could make. We ended up hiring more programmers and paying them better, because each one provided so much more value.

When the machines are able to do the hard stuff better than humans, that's when we'll really be in trouble.

I do not believe that past performance is a guarantee of future results. The era of well paid programmers in great demand is pretty much over, and it’s not only because of AI. Even if machines are dumb enough they require supervision, the big bosses do not care and will always prefer the dumb machine if it saves them money vs hiring a junior dev. It means the poor sods that supervise these machines will have to work harder to keep up with demand.

Maybe that'll happen one day, but it hasn't so far. As of this month, Glassdoor reports the median total pay for software developers across all industries and experience levels as $149K.

https://www.glassdoor.com/Salaries/software-engineer-salary-...

That doesn't yet capture the shrinking of the market, especially for juniors.

If demand for developers is shrinking then you'd expect salaries to go down.

If you can prove otherwise, show some stats.

Why do you make such statements with confidence and bluster?

This but unironically. We're at a point where there is still a gap between what managers expect and how fast AI can work. I genuinely do have days where I finish a few tickets and I'm done.

> I am producing 5x as before, my boss is paying me the same salary just for two hours of actual work per day

I don't believe any of this

> I am producing 5x as before, my boss is paying me the same salary just for two hours of actual work per day.

Great. Once your boss notices your actual work has decreased, he'll adjust compensation, increase workload, or both.

You forgot the /s at the end.

Can't imagine you really think "the market forces" all point toward a utopia for the workers? We're all just gonna get paid for 2 hours of work a day and post pics from the beach with a special shout-out to Claude?

There definitely is economic value in solving the more challenging problems. Junior devs who can only do the tedious parts have lower salaries.

There are way fewer challenging problems that people are willing to pay me to solve.

Sure I would love to be working on some cutting edge challenging stuff, but the reality is it has been much more realistic to do the tedious stuff for pay instead

You think people are still getting senior level comp when the job is prompting llm? Ha!

Absolutely everything about it in equal measure? You live environment config, setting up test harnesses, coding the complex part all identically the same? Nothing you would hand off?

Do you find there are zero chores in software development and everything is an identical delight?

You can enjoy doing woodworking without power tools but that's irrelevant to a job where people want it done fast with power tools.

Woodworking analogy for AI is not "power tools vs handsaw", its "power tools vs. wood 3D printer". You don't do any of the creating, you only ideate and allow the machine to do all the creating. It's simply not wood working anymore. Its something else entirely

You don’t have to choose between entirely hand coded and entirely AI built code.

I cannot choose entirely hand-made code, I don't think I'll even be able to choose 50% hand-made code, because my manager will say "why aren't you just using the 3D Wood Printer 9000? Jeff is building house frames 5x faster than you, you need to get with the program or we're gonna let you go"

So what? If I want a cabinet I care about the final product. power tools, 3d printer, I don't care. If it means it gets done faster and cheaper and is good enough for my needs, then that's what I want. Someone else is free to pay for the costly artisanal approach if they want to.

A friend was recently redoing his kitchen. They hired a carpenter for cabinetry, and his wife asked him if he would be willing to make it with only hand tools.

Carpenter told her he'd be happy to, it would take 8 weeks longer, cost more, and probably wouldn't look any better than the regular way

Except a power tool works as it should each and every time. 100% reproducible. That's what's so great about it.

Can we stop with the lazy analogies? Everyone's read some variant of this on here by now. Come up with something that's genius to read.

We have likewise read the same complain of "I want to keep doing it the old way, new way bad".

interesting comparison to cooking. cooking is a chore and takes effort and people enjoy cooking.

Eating is also not really optional

If you're going to spend a pretty good chunk of your lifetime eating, you might as well get good at it so you can enjoy the food you make

Do you want to eat good food or make good food? Is doing the dishes something you hand to a machine or do you always do it by hand? Are there any ingredients you buy pre-made (pesto, curry pastes, do you make your own panko breadcrumbs)?

My point, which you seem to have missed, is that people have an intrinsic incentive to care about learning to cook because eating is something we have to do every single day regardless

No such incentive exists for building software

No such incentive exists for an enormous amount of what humans do.

People don’t only build software because they have to.

I wasn't saying otherwise, I was only making the point that cooking is a terrible counter example

Aren't you proving the point that it's nuanced?

Thread seems to be saying LLMs are great because they do the dirty work and leave the fun work to humans. The counter-point is not exactly that LLMs aren't capable of doing dirty-work, it's that the nature of work isn't going to split so cleanly.

And cooking is a good example. Cooking is work. And slop. And it's also incredibly rewarding and creative, if you want it to be. Robots can help along that entire journey.

Maybe this is the core point: "cooking is a solved problem" that's how engineers always think. Except it's not. And 100% automation is still not going to break that discussion so cleanly.

The comment I was responding to was looking at a state where we looked at markdown files instead of programming, my point was to agree with the original quote that they can remove the drudgery.

> Maybe this is the core point: "cooking is a solved problem" that's how engineers always think.

But it isn’t, that’s a lazy stereotype of a subset.

Gotcha. the engineer generalization was to plant a stake in the ground. I do hear that quite often, especially from higher titled engineers. in any case, definitely admit it's not all of them, and perhaps it's even a vocal minority that i'm better served to intentionally work to expand my influences.

But you don't actually do any of that, do you? Instead, you get tired and lazy and attempt to have the LLM solve those hard problems for you too. You just don't tell others about it.

What an odd bit of moralizing. GP said they enjoy doing the hard parts, in which case they probably do them, because it's fun. If they actually don't enjoy it, there's nothing wrong with them using the LLM, when it's up to the task, and then just checking to make sure the code is good.

amidst this whole AI craze it's illuminating to learn how many programmers secretly hated programming all along

This is exactly how I feel. I knew it already to an extent from my time in college, but so many people come into this industry because they want to be able to produce the end product, or just have a stable job that makes good money. Neither of those are bad reasons to get into this profession, but it does make me sad how few peers I have who do programming because they're passionate about the act of programming. The problem solving, the dance of using programming languages to communicate efficiently and robustly to both machines and humans... I'm very sad how enthusiastically so many of my peers just toss that away.

Aside from many of these things just being a layer difference - it’s not unreasonable to want to work on databases query optimisation an not enjoy css or enjoy building frontends but just want a db that’s fast and works. The flip of your view is that they may find it sad that you don’t want to make things, you just want to solve puzzles.

> Aside from many of these things just being a layer difference - it’s not unreasonable to want to work on databases query optimisation an not enjoy css or enjoy building frontends but just want a db that’s fast and works.

I don't mean that it's unsetting that people enjoy different parts of the job, I enjoy many of those same aspects, but it's sad to me how few people around me care about the aspect that I originally fell in love with, which was the bedrock of our profession. Specifically, the work of solving problems with the machine/human shared language of code, instead of just writing out plain-english specs of what you want to have happen.

> The flip of your view is that they may find it sad that you don’t want to make things, you just want to solve puzzles.

So what? Their "just get it done" POV is far more common in this industry than mine (apparently), and the enjoyment they get from their job isn't being actively optimized away.

It’s clear at this point that the term programmer was used to refer to two very different types of people.

I don't know if it's "hate" rather than "a means to an ends". I love learning new languages, and coding. But it was always a means to an ends. The dopamine hit always came from seeing the project compile and do something.

There are multiple ends in conflict. Code skillfully constructed using abstractions that fit well to the problem space can be extended, maintained, and refactored as necessary to serve customers and markets from high to low level over long periods of time with all the social and industrial change that comes with that. Simply putting in place mechanisms that deliver what is needed now end up unintentionally cutting off future variants, alternative uses, longevity, and robustness all to minimize perceived costs.

And it isn't so much that one approach may be better than another. That is going to depend on context and available resources and more. What we are seeing is the short term being served to the absolute exclusion of thought about the longer term. Maybe if that goes fast and well enough then it will be sufficient, but churning out code bases that endure is a challenge that is only starting to be tested.

Yeah and especially the satisfaction that you were able to make a user delighted to use your thing. Fixing bugs, making things faster, adding new features, for me personally I do it because I feels really good when a customer loves to use the thing I've built.

Weather I've done the manual coding work myself or have prompted an LLM to cause these things to happen, I still chose what to work on and if it was worthy of the users' time.

I realised that early on when I stopped coding as much in my free time. After work I wanted to do practically anything else. But quite a few people at work continued to spend all of their free time coding, and clearly enjoyed the process. The SerenityOS/Ladybird creator spent years coding an arguably pointless project purely for the enjoyment of it.

Whereas I always liked to design and build a useful result. If it isn't useful I have no motivation to code it. Looking up APIs, designing abstractions, fixing compiler errors is just busywork that gets in the way.

I loved programming when I was 8 years old. 30+ years later the novelty is gone.

You can always code by hand as a hobby.

If someone is paying you for your work results, that you find it interesting or fun is orthogonal. I get the sense from the commentary section here that there’s a perception that writing programs is an exceptional profession where developer happiness is an end unto itself, and everyone doing it deserves to be a millionaire in the process. It just comes across as child-like thinking. I don’t think many of us spend time, wondering if the welder enjoys the torch or if a cheaper shop weld is robbing the human welder of the satisfaction of a field weld. And we don’t shed so much ink wondering if digital spreadsheets are a moral good or not because perhaps they robbed the accountant of the satisfaction of holding a beautiful quill in hand dipped expertly in carefully selected ink. You’re lucky if you enjoy your job, I think most of us find a way to learn to enjoy our work or at least tolerate it.

I just wish all the moaning would end. Code generation is not new, and that the state of the art is now as good at translating high-level instructions into a program at least as well as the bottom 10% of programmers is a huge win for humanity. Work that could be trivially automated, but is not only because of the scarcity of programming knowledge is going to start disappearing. I think the value creation is going to be tremendous and I think it will take years for it to penetrate existing workflows and for us to recognize the value.

> at least as well as the bottom 10% of programmers

I don't think this is the flex you think it is... in my experience, the bottom 10% of programmers are actively harmful and should never be allowed near your codebase.

Quite a few people think that about Claude code. I disagree with them, personally, but I think we can agree that AI code generation is qualitatively at least as good as the worst human professionals. I think we would also probably agree that the state of the art today is not as good as the very best.

The value per dollar spent is a different calculus and I would say that state of the art models completely surpass any individual’s productive output.

I don't understand how:

> the state of the art today is not as good as the very best

and

> state of the art models completely surpass any individual’s productive output

are not contradictory. If the models completely surpass any individual's productive output, doesn't that mean they're better than the best humans? Or maybe I don't understand what you mean by "surpassing productive output." Are you talking about raw quantity over quality? I mean, yeah... but I could also do that with a bash script.

>are not contradictory. If the models completely surpass any individual's productive output, doesn't that mean they're better than the best humans?

It would be contradictory if we were talking about a human sure, but we're not. We're talking about a machine that can read thousands of words in seconds and spit thousands in slightly longer.

>Are you talking about raw quantity over quality? I mean, yeah... but I could also do that with a bash script.

Well except you can't. You can't replace what LLMs can do with a bash script unless your bash script is calling some other LLM.

> And we don’t shed so much ink wondering if digital spreadsheets are a moral good or not because perhaps they robbed the accountant…

Caught my eye. I do think we should wonder and hold intentionality around products, especially digital products, like the spreadsheet. Software is different. It's a limitless resource with limitless instantaneous reach. A good weld is beautiful in its own right, but it's not that.

The spreadsheet in particular changed the way millions of people work. Is it more productive? Is an army of middle-managers orienting humanity through the lens of a literal 2x2cm square a net good?

I say we should moralize on that.

since when has velocity or volume of codegen been the bottleneck for any business?

i write less code than my AI-using coworkers but I have as much or more impact. Coding wasn't so hard that I need to spend time learning a new proprietary tech stack with a subscription fee lol. I believe plenty of engineers did suck enough and computers to benefit tho. That is where Anthropic makes their money.

> I just wish all the moaning would end.

It can be unpleasant to participate in a community of differing opinions and experiences. I still think it's worth showing up. If I hadn't then your perspective would have been missed too.

+1024. what the FUCK, Anil. We solved coding-is-for-everyone by throwing up our hands. please crush my body under the heaviest layer of abstraction yet and have the llm read my eulogy because who could possibly know me better than the code I spend all day talking to as if it were a human

Lurked for >10y here. Created an account just to say, "+1 well said."

It’s hard for me to believe that, unless you’re just doing simple glue work or you’re working in a low stakes environments, anyone is just delegating everything to agents. If you’re working on a migration (common in enterprise infrastructure work), you’re familiar with the needless abstractions, and it’s something you’ve done many times over; agents can certainly expedite change. If you’re building anything with depth and you do not have a clear understanding of the underpinning logic, you’re either very gifted in your ability to reason about abstractions or you’re setting yourself for a failure at some point in the future. You need expertise at some point. Programming/debugging as a means of learning a domain is akin to writing as a means of clarifying your thoughts.

That being said, yea enterprise coding can be extremely mundane and it’s setup for learning it deeply then finding a way to do it faster. I’m likely in the 90% range of my work being done by Claude, but I’m working in a domain I’ve got years of experience with hand coding and stepping through code in my debugger.

I think this latter piece is the challenge I’m struggling with. There is an endless amount of work that can be done at my company but as long as the economy is in a weird spot, I’m being led to believe that ai is making me expendable. This is a consequence of the fact that glue work represents 80% of my output (not value). The other 20% of time at work is exploring ideas without guaranteed results, its aligning stakeholders, its testing feasibility with mvps or experts from another area I need some help with. If glue work represents tangible output and conceptual work is something that may not actually have value my manager wants me to explore it, I’m just a glue guy in enterprise while I’m left chasing the dragon of a cool project for me to really sink my teeth into. That project is just a half baked bad idea from someone disconnected with reality. Glue work is measurable in LoC (however useless a metric it is measurable) and it’s certainly paying the bills.

Yea! Back to my amazing Pax Americana of friendly neighbors, high trust in my authorities, and cheerful joyous days in oeace and harmony with my fellow man, complete with gum drop smiles and firm faith in my institutions. A truly brave new world

Why not, normies love to talk with the computer.

Well I do seem to spent a fair amount of my developer time swearing at my laptop screen. And then there's that time I spend just prior to writing code just staring at the wall while I figure out what sort of code I want to write - if I can repackage that wall-staring time into "time spent consulting with AI about approaches and architecture decisions" I'm sure my engineering manager will think more kindly of me ...

I'm puzzled why they don't speak aloud. Isn't it more natural AI interface? How difficult it is to connect a microphone to speech to text engine and connect that to AI? And then speak aloud. Your manager will be happy to hear you work.

It's easier to fake humanity through toneless text with narrow context and low expectstions, I think. A chatbot you type to is of course going to impress easier

I’d love to outsource all the boring, tedious parts of my job to LLM. Unfortunately it is the upper management who decide which parts of my job are boring.

I mean if > 30% of my work is drudgery, I have failed already.

The two types of coder argument seems strong to me. Coders who love the art of programming (optimisation for the sake of it, beautiful designs, data structures...) and builders. The former are in for a rough time. The latter are massively enabled and no longer have to worry about smashing together libs by hand to make crud apps.

Doordash has also enabled home cooks; they no longer have to worry about smashing together ingredients by hand to make dinner. They just prompt the app to make them the food they want.

Doordash is the future of home cooking.

Prepackaged pasta sauces and cake mix. Worse than making it from scratch but enables people with no time to cook more dishes.

Doordash is more like paying someone else to code for you. Luckily that will soon be a thing of the past.

I suggest you stop paying Anthropic, and see how much code gets written. You're absolutely paying someone else to do it for you.

I pay Google £15/month and have never hit the usage limit. But thanks anyway.

edit: I think you might mean vibe coding (and those infamous things that use millions of tokens with no limit) but for programmers using LLMs to code is literally just a tool like anything else and the cost is barely relevant. It's not comparable to contracting out code, and it's not even comparable to eating out in terms of cost!

There are much nore than 2 types of programers, one you forgot are the ones who just need the job and any tool that helps is welcome, also, there the ones that don't care for anything and does programming just because is the only thing that's available to jot work on sales or burger flipping, and the list goes on

"bvilders" right now its mostly people who want to build a substandard app and shill it everywhere.

That's what's visible now. Give it more time and larger, more long-term projects will come out. I'm talking about people with ambitious ideas who -could- code but lack the time or energy.

Thinking carefully about the details of implementation MATTERS. Even with crud apps. Getting something “built” fast isn’t and should not be the only consideration.

I can go to a junkyard and assemble the parts to build a car. It may run, but for a thousand tiny reasons it will be worse than a car built by a team of designers and engineers who have thought carefully about every aspect of its construction.

I agree. However manual code review and heavy refactoring is a laborious and error prone process, and even most human projects don't keep up with it successfully. Plenty of horrible code debt ridden projects in the real world. As long as you're not writing safety-critical code, use of LLM is not incompatible with what you're saying.

For now it matters, but how long ? Context window will keep increasing and soon ai will be able to take care of all our codebase

Yes this is the state of it. But just wait a few months, maybe years, the builders aren't safe either. It just won't be cost effective to let humans build in a matter of time.

Depends on what you mean by "builder."

If you mean "somebody with an idea who wants to make it real" then that person is massively enabled.

So enabled, in fact, that there's almost no point in downloading an already-made app when you can just trivially tailor-make your own. The builder is massively enabled to quickly make anything they want, for an audience of exactly one.

For tiny apps, sure. Some people are making larger projects that take weeks or months even with AI, that they never could have done otherwise.

You think you were able to prompt your way through creating hello world five years ago? Models improve and they need less and less guidance.

Combined with the fact that my use cases aren't your use cases, yes, it might be cheaper for me to make my own than to slog though software that wasn't built to serve my exact needs.

I’m not saying that there’s no need for specialty apps optimized for specific use cases or that you can’t use llms to create them more cheaply than last year. Only that the time to think through how the app should work and iterate on it is still significant in the way that it was last year if you were given the worlds best team of software engineers and they’d code to your product requirements. You’d only take this path for apps where the time tradeoff is worth it vs “off the shelf” apps.

The issue is that off the shelf apps were made at a time when it was too expensive to make apps. Everyone uses 2% of Word, Photoshop, etc, it's just a different 2% for each.

You only need to reimplement that 2% for yourself for it to be worth it, not the entire app.

How would you address user requests? Tailor-make a custom app for every user?

Cars are here and you're wondering how someone could possibly make a faster horse. You wouldn't address user requests. You aren't a business. The users all make their own apps for themselves.

Cars are here and we're all choking on our own atmospheric excrement, so...

Assuming AI lives up to the marketing: Why would someone use an app instead of promoting their agent to figure out how to get something done?

Those "idea men" I've seen are usually not capable of following through a logical product, even if they start using AI. It's not just the code that's the barrier.

The prototypes or whatever can be handy to help them explain themselves to others of course.

There are plenty of programmers who are perfectly capable of delivering products, who have ideas that are too ambitious to do on their own.

Agreed, that's not really who I was referring too.

Yall's blood-diamond-ass mommy bots are going to replace bullshit with bullshit and call it a win. The last datacenter will run out of coal and water and we'll be asking: "but how in the world am I going to make this Todo app?"

Imagine if your operating system or compiler were written by the sort of person that thinks "Coders who love the art of programming ... are in for a rough time."

Yeah but 99% of jobs are decidedly not that.

Perhaps? The thing is, I don't come to HN comments to read what an LLM has to say. If that's what I wanted then I'd paste the contents of the article into one of them and ask.

What's the point of coming here for opinions of others in the field when we're met with something that wasn't even written by a human being?

He was unfairly labelled as a lunatic early on. I'd implore anyone reading this thread to see what he had to say for yourself and form your own opinion: https://youtube.com/watch?v=kgCUn4fQTsc

How do you figure? The portfolio looks to have performed roughly the same as the S&P.

BRK total return from inception to 2025: about 5,502,284% (55,000x gain)

S&P500 total return over the same period: about 39,054% (390x gain)

$1 in BRK would be $55k today. $1 in S&P500 would be $390 today. Therefore, following the hypothetical 99% drop, 1% of Berkshire return would be $550, still well above the S&P500's $390.

> My main gripe with immutability is that making updated data requires building a full copy of the data again with the changes.

Conceptually yes, but the implementation doesn't always necessarily need to work that way under the hood: https://www.roc-lang.org/functional#opportunistic-mutation

Composable single-purpose modules that communicate over a standard interface can be more easily achieved without involving a network and the complexity that comes with it.

IMO, there are only a few cases where the added network traversal make sense.

1. There's some benefit to writing the different parts of the system in different languages (e.g. Go and Python for AI/ML)

2. The teams are big enough that process boundaries start to form.

3. The packaging of some specific code is expensive. For example, the Playwright Docker image is huge so it makes sense to package and deploy it separately.

Otherwise, agreed, it just adds latency and complexity.

It's actually really weird, if you think about it, that point 1 should involve the network. We should be able to just call a function in one language from a function in another language.

Actually this happened to me once. We had two components that needed to talk to each other - one with an Erlang server and C client library that communicated over a socket with a proprietary protocol - and the other in node.js. The first attempt was to write a C translator that took requests over another socket with a different proprietary protocol, but this one was proprietary to us so we could use it directly from node.js. The second, much better attempt was to learn node's C++ module interface and write a C++ node module wrapper around the C client library.

This third-party Erlang component benefited from being an independently restartable process and therefore needing some RPC, but we also had a mess of C/C++ components inter-connecting over RPC that in reality probably didn't need to be separate processes, but for some reason we'd already decided that architecture before we started writing them.

> It's actually really weird, if you think about it, that point 1 should involve the network. We should be able to just call a function in one language from a function in another language.

If you have two languages that both are not C or C++ , and have more involved runtimes, how well does this work? I know for some cases you have things like JRuby or IronPython, but say mixing a JVM language and a CLR language?

For those cases you have to bring the runtimes with you.

With JVM and CLR you can use JNI and COM to generate SOs/DLLs, and both of them can use any SOs/DLLs via FFI. There is also IKVM and Jni4Net that allowed Java code to run in .NET (or at least used to be, I last used it 15 years ago). Results may vary.

For other languages it can be a bit more involved: if there's no such thing as exposing as a library, you must embed the interpreter, which typically involves using C++.

It's not fun. This is why people end up using network requests.

If you can have a text-only interface, or even involve files, you can also just invoke the other app as a process.

The first episode of the second season (at least the beginning), seems entirely possible with current technology

However it can't be produced at the same scale and flood the Internet with misinformation or disturbing imagery at the same rate

Yea it would be really bad if the internet was flooded with misinformation or disturbing imagery. Just imagine that!

> at the same rate

>flood the Internet with misinformation

After the past few years… anyone who can seriously complain about this seems like their identity is wrapped up in not admitting that the worst “misinformation” didn’t come from bad apples - but official sources.