I feel like CA (single, or multi-state) would work quite well on dedicated hardware, how big could the grid even be? I may be missing the obvious, but it does seem easier to scale compared to cores and manual dispatch.
But otherwise yeah, not the most efficient on current CPUs.
> 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.
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
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.
"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.
> 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)
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.
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.
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.
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?
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.
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.