I have been programming for about 40 years now. Unfortunately, I have been sucked into many programming fads over the years. However, over time, my practical programming experience has almost entirely converged on principles that are nearly identical to what Casey, and Jonathan Blow, have been talking about for years and is reflected in the content of this course: straight-forward programming for the machine is almost always easier to understand and remarkably efficient. Unfortunately, this insight has been almost entirely lost in today's programming scene.
Telling people to "roughly" program like you did in the 80s and 90s (when computers had fewer resources) doesn't sell books, videos, or consultant gigs. Ironically, Casey can make an educational series like this to fill the gap/correct the misconceptions, and get folks to pay up. It's not that fashions go in cycles -- Casey is espousing on eternal truths of programming: programs all run on real, physical machines. This is not a fad but a way to help people reconnect with fundamental truths.
I just want to say: this is really well-written, and I think gets to the heart of your point very clearly. Perhaps it would be helpful to link it somewhere in the original video, maybe pinned comment or description!
I'm am doing a series of "tech talks" to fellow developers at my company - a major industry standard product... and it is about this topic. I have tried to come at it from the angle of how the hardware executes their code, and open eyes as to why performance issues exist, and to why even after "clean code" - the source is still chaos. So I am doing it that way, rather than trying to tell people their "clean code" is bad - because I think people will just dig their heels in, and I'll make no progress is changing opinions. It is almost like a religious war, even though it is our side that has the empirical evidence to back up our claims.
I haven't heard about segregated arrays before and an internet search on it only brings up irrelevant results or this page. It doesn't seem to refer to SoA. Can I get a short description or a link?
I don't know what DoD people call it, but it's just the basic idea that if you have n different types, you keep them in n different arrays, and that way you don't have to use any dynamic dispatch - you just do n different loops, one over each array. This is a nice technique when you know your types will not be "mixed together" in terms of the order of operations.
Since years, i am trying to get all those misunderstandings about bad programming patterns out of the way of my colleages, but it is useless. Because they simply dont care if the performance is bad. They only care about features! They rather wait some seconds/minutes, running thousands/millions of instructions for no reason.
But for me it always a hassle to find a bug in that piece of trash, because i have to follow hundreds of indirections and it gets worse when code is behind (async/await pattern) - hiding the multithreading side of things.
It is extremly frustrating and showing the "clean code" - horrible performance video has not helped either :-( As a matter of fact, it inspired them to write more "clean code", because the example was not matching their programming model.
Really we need a much more complex real-world use-case, that would reach more people and does not leave much room for wrong assumptions. Like for example, reading streams from the network, parsing strings, doing math operations of data and include some sort of display with some user interactions.
I have read that clean code book and i have tried and failed repetedly to get through the gang of four design patterns. And I dislike clean code and like this thing you do because I find this way easier. When you show these performance differences that is just dessert for me. I just dont want to deal with all that other stuff. It tires me.
I wish you would also do something like this for how frontend ui work is done using a component based model. I have followed handmade hero and it was a completely different approach to drawing on the screen. Although I know this is probably not going to happen and im happy to try and extrapolate the things you teach into react and vue etc. I found that old video you made about immediate mode uis. That helps a lot to try and imagine how you might have tackled the frontend ui work in your style.
THANK YOU for calling bullshit on bloated code that utterly ignores the hardware it runs on. Way too many CS grads have absolutely no idea how computers actually work or the architecture of CPU they're using.
As someone who writes code on bare metal microcontrollers and DSP chips, I'm always baffled at how much resources apps require, and their slow execution.
It also drives me bonkers to read "clean code" where most of the code doesn't actually do anything real, it's just a huge artifice of "elegance."
When I saw the video I was really happy about it. I started about 10 years ago as a .Net Dev and got taught that Clean Code stuff just as you said. And yet I have to find a code base that is not turned into a clean mess by OO and clean code principles. It took me years to realize how bad of an idea this is.
It actually struck me, as I switched to web front end and there every thing was written in a pure functional approach with redux and all that stuff. The first time in my professional life, I experienced real clean and fast (Js) code. Unfortunately I learned this company was actually the exception, when I switched jobs. Even in web dev Clean Code and OO are still quite dominant. And since that one experience where I experienced real lean, reliable, extendable and fast TypeScript code it's especially hard for me to work on those messy code bases.
And I'm really frustrated about how often "clean" OO code gets confused with fast code. When in reality the real cause is most often the direct mutations which are just very common in OO, but not OO itself. certainly not inheritance.
And depending on the context or problem space, even mutable code can be slower than immutable. E.g. in web ui many frameworks like react rely on a virtual dom. And one of the most expensive operations is the rendering process. so to achieve good performance you should rerender only what is necessary. this is done via diffing. so each time the app state changes, react compares the previous with the new virtual dom. but since each dom element is an js object, which is mutable, you can not compare both by reference. you have to compare each of there values one by one and this can be slow.
Elm on the other hand is a pure functional programming language that is specifically design for web front end apps and it compiles to java script. Therefore it can rely on the resulting js-code to be 100% immutable. So when it comes to diffing, elm can compare each dom element by reference, since each change to a dom element results in a new object. That way elms immutable code easily outperforms mutable js solutions in this problem space. Simply because its diffing algorithm is faster and more reliable.
So what I'm trying to say is, it is really important to understand a given problem space very well and those general coding principles aren't helping at all. Unfortunately this pairs with a very bad incentive our industry currently has. That is, our main goal is to write a (kind of) working app fast. In fact, it's more important to be the first who offers a solution (App), rather than to be the one who offers the best, fastes or most reliable one. I mean this probably goes hand in hand with our free market. Being the first on the market, means you can get ahead, which means you gather market strength and the farther you get ahead, the more you can dominate the market.
But I don’t think Casey has to emphasize _what actually happens in a CPU_? IMHO it’s already charming there exists a new and old kind of language that we can use to discuss about programming, in a much more thought-provoking, constructive and non-dogmatic way.
Nonetheless, isn’t emphasizing too much about _what actually happens in a CPU_ ultimately becomes a bit radical and dogmatic in some way? I mean sometimes I get paranoid a bit about performance instead of the actual functionality too. I kind of know that hard metrics like micro-benchmark performance are most useful at convincing the unacknowledged broad audience. And I kind of know the broader audience need a more radical voice to pull them out of this performance nightmare.
But I think what’s equally important is how you managed to achieve better architecture, clarity, maintainability without all these clean code and SOLID guidelines. Of course people will argue about how your standard of clarity will be different than theirs, and those will surely be harder arguments than the performance ones. But overall I feel it’s more beneficial than convincing some random people on the orange site? I don’t know.
But personally I really want to learn more designing insights from you, as I was never disappointed when Casey showed up and over and over again presented clever yet simple solutions to the problems that confused me so much. Over the past few days, I just learned so much by trying to complete the 8086 decoder!
I took a look at the /r/programming thread for the video out of morbid curiosity. Most of the time, when one of your videos makes it onto there, the response is typically a mix of praise/gratitude, disagreement, misunderstanding, excuse making, and comments about your attitude. Often times it skews pretty positive. This time, it seems that a lot of it was surprisingly negative and missing the point like you mention in your bullet points here... SO many people were making the mistake of thinking there's a pure dichotomy between "fast, messy code" and "slow, clean, maintainable" code. It's sad to see that this is the kind of reaction a not-insignificant portion of the programming community has. Here's to hoping that people will start listening eventually. Don't give up!!
For anyone that’s interested in a reasonable software design book, I highly recommend “A philosophy of software design” book over the way too popular Clean code
There is unfortunately a lot of this sort of thing that goes around. Five minutes in godbolt will tell you otherwise, but unfortunately nobody checks :(
I have been programming for about 40 years now. Unfortunately, I have been sucked into many programming fads over the years. However, over time, my practical programming experience has almost entirely converged on principles that are nearly identical to what Casey, and Jonathan Blow, have been talking about for years and is reflected in the content of this course: straight-forward programming for the machine is almost always easier to understand and remarkably efficient. Unfortunately, this insight has been almost entirely lost in today's programming scene.
Telling people to "roughly" program like you did in the 80s and 90s (when computers had fewer resources) doesn't sell books, videos, or consultant gigs. Ironically, Casey can make an educational series like this to fill the gap/correct the misconceptions, and get folks to pay up. It's not that fashions go in cycles -- Casey is espousing on eternal truths of programming: programs all run on real, physical machines. This is not a fad but a way to help people reconnect with fundamental truths.
I just want to say: this is really well-written, and I think gets to the heart of your point very clearly. Perhaps it would be helpful to link it somewhere in the original video, maybe pinned comment or description!
I'm am doing a series of "tech talks" to fellow developers at my company - a major industry standard product... and it is about this topic. I have tried to come at it from the angle of how the hardware executes their code, and open eyes as to why performance issues exist, and to why even after "clean code" - the source is still chaos. So I am doing it that way, rather than trying to tell people their "clean code" is bad - because I think people will just dig their heels in, and I'll make no progress is changing opinions. It is almost like a religious war, even though it is our side that has the empirical evidence to back up our claims.
Very interesting.
I haven't heard about segregated arrays before and an internet search on it only brings up irrelevant results or this page. It doesn't seem to refer to SoA. Can I get a short description or a link?
I don't know what DoD people call it, but it's just the basic idea that if you have n different types, you keep them in n different arrays, and that way you don't have to use any dynamic dispatch - you just do n different loops, one over each array. This is a nice technique when you know your types will not be "mixed together" in terms of the order of operations.
- Casey
Thanks :) I know about that technique but don't know a term for it either. Not the first thought of OoP people.
Since years, i am trying to get all those misunderstandings about bad programming patterns out of the way of my colleages, but it is useless. Because they simply dont care if the performance is bad. They only care about features! They rather wait some seconds/minutes, running thousands/millions of instructions for no reason.
But for me it always a hassle to find a bug in that piece of trash, because i have to follow hundreds of indirections and it gets worse when code is behind (async/await pattern) - hiding the multithreading side of things.
It is extremly frustrating and showing the "clean code" - horrible performance video has not helped either :-( As a matter of fact, it inspired them to write more "clean code", because the example was not matching their programming model.
Really we need a much more complex real-world use-case, that would reach more people and does not leave much room for wrong assumptions. Like for example, reading streams from the network, parsing strings, doing math operations of data and include some sort of display with some user interactions.
I have read that clean code book and i have tried and failed repetedly to get through the gang of four design patterns. And I dislike clean code and like this thing you do because I find this way easier. When you show these performance differences that is just dessert for me. I just dont want to deal with all that other stuff. It tires me.
I wish you would also do something like this for how frontend ui work is done using a component based model. I have followed handmade hero and it was a completely different approach to drawing on the screen. Although I know this is probably not going to happen and im happy to try and extrapolate the things you teach into react and vue etc. I found that old video you made about immediate mode uis. That helps a lot to try and imagine how you might have tackled the frontend ui work in your style.
For more about immediate mode UIs,, you might be interested in https://github.com/ocornut/imgui .
Yep I know about this. I think it was sparked off from that old video? I am not sure about that though.
THANK YOU for calling bullshit on bloated code that utterly ignores the hardware it runs on. Way too many CS grads have absolutely no idea how computers actually work or the architecture of CPU they're using.
As someone who writes code on bare metal microcontrollers and DSP chips, I'm always baffled at how much resources apps require, and their slow execution.
It also drives me bonkers to read "clean code" where most of the code doesn't actually do anything real, it's just a huge artifice of "elegance."
When I saw the video I was really happy about it. I started about 10 years ago as a .Net Dev and got taught that Clean Code stuff just as you said. And yet I have to find a code base that is not turned into a clean mess by OO and clean code principles. It took me years to realize how bad of an idea this is.
It actually struck me, as I switched to web front end and there every thing was written in a pure functional approach with redux and all that stuff. The first time in my professional life, I experienced real clean and fast (Js) code. Unfortunately I learned this company was actually the exception, when I switched jobs. Even in web dev Clean Code and OO are still quite dominant. And since that one experience where I experienced real lean, reliable, extendable and fast TypeScript code it's especially hard for me to work on those messy code bases.
And I'm really frustrated about how often "clean" OO code gets confused with fast code. When in reality the real cause is most often the direct mutations which are just very common in OO, but not OO itself. certainly not inheritance.
And depending on the context or problem space, even mutable code can be slower than immutable. E.g. in web ui many frameworks like react rely on a virtual dom. And one of the most expensive operations is the rendering process. so to achieve good performance you should rerender only what is necessary. this is done via diffing. so each time the app state changes, react compares the previous with the new virtual dom. but since each dom element is an js object, which is mutable, you can not compare both by reference. you have to compare each of there values one by one and this can be slow.
Elm on the other hand is a pure functional programming language that is specifically design for web front end apps and it compiles to java script. Therefore it can rely on the resulting js-code to be 100% immutable. So when it comes to diffing, elm can compare each dom element by reference, since each change to a dom element results in a new object. That way elms immutable code easily outperforms mutable js solutions in this problem space. Simply because its diffing algorithm is faster and more reliable.
So what I'm trying to say is, it is really important to understand a given problem space very well and those general coding principles aren't helping at all. Unfortunately this pairs with a very bad incentive our industry currently has. That is, our main goal is to write a (kind of) working app fast. In fact, it's more important to be the first who offers a solution (App), rather than to be the one who offers the best, fastes or most reliable one. I mean this probably goes hand in hand with our free market. Being the first on the market, means you can get ahead, which means you gather market strength and the farther you get ahead, the more you can dominate the market.
Sry for rambling around. but yeah...
Thanks for the video!
Amazing post!
But I don’t think Casey has to emphasize _what actually happens in a CPU_? IMHO it’s already charming there exists a new and old kind of language that we can use to discuss about programming, in a much more thought-provoking, constructive and non-dogmatic way.
Nonetheless, isn’t emphasizing too much about _what actually happens in a CPU_ ultimately becomes a bit radical and dogmatic in some way? I mean sometimes I get paranoid a bit about performance instead of the actual functionality too. I kind of know that hard metrics like micro-benchmark performance are most useful at convincing the unacknowledged broad audience. And I kind of know the broader audience need a more radical voice to pull them out of this performance nightmare.
But I think what’s equally important is how you managed to achieve better architecture, clarity, maintainability without all these clean code and SOLID guidelines. Of course people will argue about how your standard of clarity will be different than theirs, and those will surely be harder arguments than the performance ones. But overall I feel it’s more beneficial than convincing some random people on the orange site? I don’t know.
But personally I really want to learn more designing insights from you, as I was never disappointed when Casey showed up and over and over again presented clever yet simple solutions to the problems that confused me so much. Over the past few days, I just learned so much by trying to complete the 8086 decoder!
I took a look at the /r/programming thread for the video out of morbid curiosity. Most of the time, when one of your videos makes it onto there, the response is typically a mix of praise/gratitude, disagreement, misunderstanding, excuse making, and comments about your attitude. Often times it skews pretty positive. This time, it seems that a lot of it was surprisingly negative and missing the point like you mention in your bullet points here... SO many people were making the mistake of thinking there's a pure dichotomy between "fast, messy code" and "slow, clean, maintainable" code. It's sad to see that this is the kind of reaction a not-insignificant portion of the programming community has. Here's to hoping that people will start listening eventually. Don't give up!!
For anyone that’s interested in a reasonable software design book, I highly recommend “A philosophy of software design” book over the way too popular Clean code
There is unfortunately a lot of this sort of thing that goes around. Five minutes in godbolt will tell you otherwise, but unfortunately nobody checks :(
- Casey