[TheMode]

I personally do not like how his solution boils down to "just learn more" which may be true at an individual level, but not as the general solution to awful software.

You will never be able to force developers worldwide to start writing everything in C/Assembly, or even to care beyond "it performs fine on my machine". Individuals can have fun micro-optimizing their application, but overall, we have the app we have because of compromises we find somewhat acceptable.

More likely the solution will be technical, making great/simple/efficient code the path of least resistance.

[sarchertech]

Watch some of the intros to his performance aware programming videos. He doesn’t want everyone to use C or Assembly. He also doesn’t want everyone micro-optimizing things.

>compromises we find somewhat acceptable

His entire point is that most developers aren’t actually aware of the compromises they are making. Which is why he calls it “performance aware programming” and not performance first programming.

[TheMode]

I have actually watched many of his videos, as an individual I very much like his advices. What I am saying however is that this has nothing to do whatsoever with improving software at scale.

But my point still stands, Casey focuses solely on the cultural aspect but completely ignore the technical one. He says that developers became lazy/uninformed, but why did that happen? Why would anything he currently say solve it?

[sarchertech]

I don’t think you can blame him for not having a large scale systemic solution to the problem.

Imagine if there was a chef on YouTube who was telling everyone how bad it was that we are eating over processed food, and he makes videos showing how easy it is to make your own food at home.

Would it be reasonable to comment to people who share the chefs message that you don’t like how his cooking videos don’t solve the root problem that processed food is too cheap and tasty?

And here’s the thing, he doesn’t have to solve the whole problem himself. Many developers have no idea that there’s even problem. If he spreads the message about what’s possible and more developers become “performance aware” maybe it causes more people to expect performance from their libraries, frameworks, and languages.

Maybe some of these newly performance aware programmers are the next generation of language and library developers and it inspires one of them to create the technological solution you’re hypothesizing.

[TheMode]

But he says that he has a large-scale systemic solution, it is literally the reason for his videos.

He isn't doing it so I can get my CPU trivia, but because he believes it will result in better software. Been at it for years, and so far I don't think it's going better.

My opinion is that better software will not come from CPU-aware people, but from people having enough of all the BS and switching to simpler solutions. You speak about language/libraries, what make you think it would come from those?

I do believe he is smart, just unfortunate he puts his talent on the wrong path. It's not like he does not understand the impact of simplicity/working independently, as it is how he made his "fast terminal" showcase: by tying to bypass system libraries as much as possible, transforming it into a simple (or at least less theoretical) problem.

[sarchertech]

This is such an absolutely wild take to me. Screw those Mythbusters guys trying to explain the scientific method to people. That's not a systemic solution to fixing scientific illiteracy in the US. Sesame Street teaching kids to count? Those guys are way off the mark because it's not going to measurably improve economic performance. You'll never actually change anything just by teaching people stuff.

I'm 100% certain that Casey Muratori doesn't think that his paywalled course is going convince literally every programmer to to care about performance, or to stop Facebook from building slow apps.

He's trying to convince some small percentage of people that performance is something they should be thinking about when they program, and that they should understand the tradeoffs they are making when they choose to use some slow method, algorithm, library, language, or system because it provides some other benefit.

When someone writes a book like "math for dummies" that says on the back cover "I think basic math is a useful skill for everyone to have, and if we all learned basic math the world would be a better place!"

That's not the author stating their true belief that their book is going to literally teach the majority of the world basic math. That's an aspirational goal or in the worst case it's sales copy.

Publicly calling that person out for wasting their time is really something else.

Creating straw men to attack like "You will never be able to force developers worldwide to start writing everything in C/Assembly" when he explicitly states that this isn't his goal makes me think you're just looking for some reason to shit on the guy.

>You speak about language/libraries, what make you think it would come from those?

I have no idea when if or how a technical solution will be found.

[TheMode]

"Math for dummies" book writers don't argue that mathematicians are stupid/incompetent because they do not spend enough time on the basics.

It has also nothing to do with teaching people to count, read, or the scientific method. Every. Single. Software I use is bloated, I am unaware of any software solely consuming that it should, nothing is close to the theoretical limit, this is not a knowledge issue. If you have such software in mind feel free.

Casey continuously says that the problem with software is that developers do not understand performance, and so that the problem will be solved once they do. I am not overly familiar with his paid course, but he did stuff before that. He has essentially the same opinion as Jonathan Blow.

The course being paywalled isn't really an argument for either of us, on his side it is most likely a compromise, just because this isn't the grand plan to convince millions of developers doesn't mean he doesn't intent for it to help his cause.

Casey believing the problem at scale to be cultural isn't some guess, I actually asked him: https://x.com/cmuratori/status/1687138791356833793

> that this isn't his goal makes me think you're just looking for some reason to shit on the guy.

You can consider it a hyperbole if you want, but essentially what I am saying is that he wants to put the burden on the developers, without really changing the underlying structure.

I am not shitting on him for the sake of it. I do really like his (and Jonathan) observations, and I will continue to watch them, I just find it unfortunate that both waste their time on solution that will not affect anything at scale (one with a custom language, the other with specialized course)

[patrick451]

The real problem is that we have a broken, anti-performance culture. We have allowed "premature optimizaiton is the root of all evil" to morph into "optimization is the root of all evil. That single quote has done untold damage to the software industry. We don't need to pass laws to force all programmers worldwide to do anything. Fixing our culture will be enough. In my view, that's what Casey is trying to do.

[TheMode]

I don't believe this is the root cause, computers got faster, and software got quicker to the state of "run good enough". I'm calling Wirth's law on it.

"Clean code" is indeed often a bad idea, but you are overestimating the impact. Even software written by people caring very much about performance consume way more than it theoretically should.

Plus, if this was that simple, people would have already rewritten all the bad software.

Your message is exactly the reason why I do not like Casey, he is brainwashing everyone into thinking this is a culture problem. Meanwhile nobody tries to solve it technically.

[gmueckl]

The free market is preventing technical solutions. People generally buy based on features first and everything else second. This allows for a precarious situation in software market: the company producing the most bloat the fastest wins the biggest market share and sees no need to invest in proper fixes. Everyone that cares about software quality too much gets outcompeted almost immediately.

And since software can be rebuilt and replicated with virtually zero cost, there is no intrinsic pressure to keep unit costs down as it happens in industry, where it tends to keeps physical products simple.

[TheMode]

It doesn't have to come from the free market, FOSS is hardly exempt of awfully slow/unstable software. Nobody figured out yet how to make writing good software the default/path-of-least-resistance.

[patrick451]

Wirth's law doesn't bolster your point. He observed software is getting slower at a more rapid rate than computers are getting faster. Which is the whole point. We write increasingly slow, increasingly shitty code each year. I read and hear this attitude all the time that is basically "if you optimize something, you're bad at your job, only juniors try to do that". That's a culture problem.

It's frankly insulting you think Casey brainwashed me into this stance, when it's been obvious to me since long before I'd ever heard of him. IDGAF if code is clean or not. I care that Jira can display a new ticket in less than 15 seconds. I care that vscode actually keeps up with the characters I type. None of this software is remotely close to "runs good enough".

[TheMode]

What I am saying is that this is a natural phenomenon assuming no technical solution. People will tend to optimize their software based on the performance of their hardware.

I completely agree that many apps are horrendously slow, but given the alternative are hard pressed to arrive, I can only conclude they are considered "good enough" for our current tech level.

The difficulty involved in rewriting modern apps is one of the reason I would give that result in slow software. Can't really complain about the number of independent web browsers when you look at the spec. Ensuring the software we use is easily reimplementable by a few or one developer in a few days would go a long way improving performance.

Another reason would be the constant need to rewrite working code, to work on new platforms, to support some new trendy framework, etc. etc. You cannot properly optimize without some sort of stability.

[lmm]

Jira runs good enough to get idiot managers to pay for it, which is what it's designed for. And, yeah, microoptimising (or micropessimising, who knows since the changes are usually just made on vibes anyway) random bits of code that probably aren't even on any kind of hot path, while compromising maintainability, is something only juniors and people who are bad at their job do. It's easy to forget how common security flaws and outright crashes were in the "good old days" - frankly even today the industry is right to not prioritise performance given how much we struggle with correctness.

A lot of code is slow and could be faster, often much faster. This is more often because of people who thought they should bypass the abstractions and clean code and do something clever and low level than the opposite. Cases where you actually gain performance on a realistic-sized codebase by doing that are essentially nonexistent. The problem isn't too many abstractions, it's using the wrong algorithm or the wrong datastructure (which, sure, sometimes happens in a library or OS layer, but the answer to that isn't to bypass the abstraction, it's to fix it), and that's easier to spot and fix when the code is clean.