Comment by TheMode | Hacker News Reader

Comment by TheMode | Hacker News Reader

Parent Full thread

"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)

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

His argument isn't that they don't spend enough time on the basics. His argument is that they don't know the basics even exist.

This is true in my experience. I've interviewed scores of candidates over the years who just have absolutely no mental model of what is going on under whatever abstraction layer they generally work in.

Making trade offs to sacrifice performance for things like developer speed is fine. But if you're not aware you are making those trade offs, I might not call you stupid, but I will call you ignorant.

>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.

It's not binary. There's a continuum. No software is ever going to use exactly the minimum theoretically possible number of instructions and memory over the entire program.

But some software is worse and some is better.

It is possible to believe that the problem can be solved by changing the culture, while simultaneously believing that you aren't going to be able to completely change the culture. While also believing that you can shift the culture ever so slightly such that you make it just a little bit better.

You can also hold all of the above beliefs while believing that there is a systemic underlying issue that you have no idea how to solve.

From my observations (having watched a good bit of early handmade hero and a good bit of his paid course) the above is pretty close to his beliefs.

It's also fairly close to my own thoughts on the subject. The underlying issue is that software is an industry that primarily competes on features, not quality. I think the reasons for that are numerous--everything from software being an immature industry, to the distorting effects of cheap money flowing into the industry from the previous few decades.

I believe this will work itself out to some degree over time as the industry becomes more mature and we start to see more diminishing returns for just adding new features. Developers will start to look towards other things to differentiate themselves and quality/performance could be one of them.

I don't think there's anything I or Casey can do to change the market dynamics, and I can't think of a technical fix to this issue. I suspect Casey can't either.

I also think that there are niches today where performance and quality can outcompete more features.

Given all the above, I think pushing to convince a small percentage of people that spending a bit more time thinking about performance is a rational goal. Maybe it's the best you can do. But maybe you end up with just a few less wasted cycles in the world. Maybe you end up with a few more pieces of software that feel snappy and pleasant to use than you otherwise would have.

I completely agree that some (if not the majority of) developers aren't aware of what's happening under abstraction layers, but then I have to ask: is it the developer fault, or the abstraction's?

If you were to ask a new programmer to make a very simple calculator which would then be distributed to various people using various devices, what would they use? How long would it take them? How much would it consume? Does this cost have anything to do with the programmer being unaware CPUs have multiple cores or that memory access is slow? Theoretically I would struggle to find a way to make this calculator takes up more than 10mb of memory (which is already more than Mario 64), both as CLI and GUI. You literally have 4 bytes instructions for add/sub/mul/div and a framebuffer, it is not like I am talking about micro-optimization, this should be the default and simplest path.

Discord takes around 400mb on my machine and will happily take a whole +3ghz core from me if I start scrolling. If I were to give a new programmer a method to query messages, and another to render to a framebuffer through software rendering, would they even succeed matching discord/chromium's bloat? Seems to me it would require some genuine effort.

You could explain me that this bloat come from fancy/convenient features, but it does not change that programmers are always exposed to complex problems even though theoretically easily composable and therefore friendlier to changes.

If you were to ask me for less theory and for a more practical example, I would say that each programs should be written/compiled to a potentially different format with the common point of being easily interpretable (stack machine, Turing machine, lambda calculus, cellular automata). Each platform (OSes, hardware) should come with a program that expose every single potential IO action, and to run an actual program requires finding an interpreter for the specific format (either made yourself in an hour at most, or downloaded) and mapping your exposed IO calls through the platform app, in the same way you would configure keybinds in a video game.

- Developers are always exposed to their lowest layer

- Programs are always cross-platform, even to future ones

- Programs are stable, increasing the chance of being optimized over time

- Heavily limit dependencies (and therefore additional abstractions)

In this example, none of it depends on understanding how CPUs work. Also does not require a change in market dynamics, individuals can start, and make it slowly gain relevance as anything written this way cannot (easily) break and become abandonware.

Ultimately, even unaware programmers are able to explain their webapp in few words, the problem is that they cannot easily map those words and have to work around frameworks which they cannot really give up on. Android/iOS helloworld templates illustrate it nicely.

I 100% agree that you don't necessarily need to know how a computer works to make a less bloated discord app.

But I do think that knowing the limit of what is possible with respect to performance makes you appreciate just how bloated and slow something like discord is. If you've only ever don't web development or electron apps, and you've only ever used bloated apps, you have no idea that you can do better.

You don't have to teach people about the limits, you could build a discord client on top of a "a method to query messages, and another to render to a framebuffer through software rendering" and show them how much faster it could be how much less memory it could use.

But the thing is Casey likes teaching at a lower level than that. He likes teaching about the domain he finds interesting and that he's an expert in. He thinks he can make the world more like the world he wants to live in, and he thinks he can do it by doing something he likes doing and is capable of doing.

That doesn't mean there aren't other faster or more impactful solutions to less bloated software, but he's not necessarily the guy to work on those solutions and there's nothing wrong with that. Judging by the number of people who watch his videos and the frequency with which the topics he promotes are discussed, he's making an impact--maybe not the optimal impact he could be making, but that's a fair thing to judge someone on.

> Each platform (OSes, hardware) should come with a program that expose every single potential IO action, and to run an actual program requires finding an interpreter for the specific format (either made yourself in an hour at most, or downloaded) and mapping your exposed IO calls through the platform app, in the same way you would configure keybinds in a video game.

Have you looked at the Roc language? It has a lot of similarities to what you're describing.

> You don't have to teach people about the limits, you could build a discord client on top of a "a method to query messages, and another to render to a framebuffer through software rendering" and show them how much faster it could be how much less memory it could use.

The problem is exactly that this is not that simple. I believe that there is a huge gap between the theory of a chat application, and the way they are implemented now. I do not believe it is about better abstraction layers, personally I have always found explanations using raw sockets and bits the simplest.

If you were to ask a programmer to write a discord client, you would very likely end up with a giant mess that somehow break a few months later at most (if ever). Even though they would be able to flawlessly go through the program flow step by step if you asked.

Discussions about efficient code kind of avoid the topic, I don't believe we are in a situation where multithreading is relevant, the bloat is on another level. The bloat is generally not related to whatever language you use, the O(1) or O(n) algorithm you choose, but more likely the overall control flow of the program which you already understand in your head but cannot figure out how to act on, and the inability to make simple problems simple to solve (like the calculator, text editor, or even games)

Now you are probably right about Casey ultimately doing what he likes, and even if suboptimal make other people aware. Although I would believe that this benefit comes somewhat in spite of himself.

> Have you looked at the Roc language? It has a lot of similarities to what you're describing.

Gave it a look and unfortunately, I don't think I have seen the similarities? It has environment/IO access, call host language functions, and doesn't really strive to be reimplemented by independent people.

>Gave it a look and unfortunately, I don't think I have seen the similarities?

I was specifically thinking about this https://www.roc-lang.org/platforms

I'm not an expert. I haven't actually used it, but I have been following it a bit. Roc splits things into apps and platforms. When you implement a platform you're responsible for implementing all (or the subset you want to provide) of the I/O primitives and memory allocators.

>Discussions about efficient code kind of avoid the topic, I don't believe we are in a situation where multithreading is relevant, the bloat is on another level

Case does talk about other kinds of bloat. Things like structuring things so blocking operations can be batched etc...

Reply on news.ycombinator.com