[Extremely long post warning!]
EDIT: I meant to title the Topic Compression-oriented programming, I guess I was thinking of the alternate name of Algorithm-oriented programming that Casey mentioned and it slipped. I unfortunately don't know how to edit the topic title though.
After this week of seeing Casey coding, I believe I have a better understanding of what he means when he talks about compression-oriented programming. Since it is something he has been asked about a few times, I have decided to get the ball rolling and start a thread on this topic. As a starter to anyone who hasn't followed the whole Handmade Hero series (and a complement to those who have) I highly recommend reading his blog posts on the topic at http://mollyrocket.com/casey/stream_0019.html and http://mollyrocket.com/casey/stream_0020.html the first of which I believe features the first appearance of Bob, of "the only way Bob can screw up is if Bob is just incompetent" fame.
As Casey has repeatedly stated during the coding of the windows platform layer, the fact that he was coding something which he already knew how it should look at the end has conditioned many of his decisions. Although he has tried to throughly explain every decision he has taken through each step, today's stream has IMHO shown the true process of compression-oriented programming. Through the week he has been setting up today's World and TileMap positioning (the Canonical and Raw positions) not in a way where he knew what the final code was going to look like but quite literally writing whatever code came to mind that accomplised the task at hand. This has had the consecuence of his code following a step-by-step evolution that followed his thought process from conception to code that accomplished the task. Funny enough, for those of you that paid attention at the end of thursday's stream and beginning of today's stream, the same logical steps resulted in rewriting the IsWorldPointEmpty function with the same exact argument calls at one point of today's stream. However, and most importantly, that first "evolution" of the code was just a momentary first step which resulted in two completely different functions by the end of the stream.
So what are the reasons to "evolve" the code that is initially written? Before starting to watch this series I would probably have said to make it more maintainable (easier to read and modify), to make it more modular (separated into chunks that can be applied to different scenarios) and possibly to make it more efficient (although I really would have meant more "clever looking" through the use of some algorithm that was specifically tailored to the task). After watching Casey code, I have realized the mistake of these approaches: the reason of the code is quite literally to DO SOMETHING. Once the code does that, I might want it to do ONE MORE THING. If that change is trivial then I look at how to DO YET ONE MORE THING. If, however, the change from one to two things requires a new structure, or I realize that I have to retype a chunk of code or variables and I see that I will have to repeat them shortly, then I will create a function or structure to avoid doing that. Thus, it is the code as I type it that "tells" me how to organize it and not the other way around (or, as in OOP, a programming paradigm which tells the code what to do regardless of anything else, which explains Casey's distate of OOP, or functional programming, or of any other set system of organizing the code).
This very fact was patent in the evolution of the "Canonical" and "Raw" positions on today's stream, and how Casey's understanding of their uses evolved with each iteration of what the code had to do, up to the point where he is confident he wil get rid of the raw position. It is however important to note that he has NOT gotten rid of the raw position structure, and it is my understanding that he is waiting for the time when the positioning code accomplishes all the functions it requires before deciding it is redundant to then delete it. It is my guess that if this was a part of the code that he had previously written before (as he has the windows layer) he would have started using the cannonical position from the beginning and we would not have seen this process unfold live. This would be a result of him having solved the problem before and thus having a different view of the logic to solve it, which starts with the cannonical view and not the raw position.
What I also found interesting about this whole process is the analogy between this short term process and the concept of the "Exploration-based Architecture" he presented on day 27. In both cases the end goal is relegated to something that only affects the current task in as much as it should be compatible to the next task which also points towards the same goal. Once I start thinking about how Casey has talked about how when having trouble with coding regulaly his solution is once again to think about coding for "just one hour" thus not thinking about the final goal but the next step, I start thinking it might be time to call it Compression-oriented Philosophy... but that might be just one step too far.
This is all of course just my understanding at this point of what Casey means with compression-oriented programming, and I might be wrong at some points, or even way of overal. I'd love to hear everyone elses opinion, including of course Casey's himself. Thanks to everyone who took the time to read the whole post!
EDIT: I meant to title the Topic Compression-oriented programming, I guess I was thinking of the alternate name of Algorithm-oriented programming that Casey mentioned and it slipped. I unfortunately don't know how to edit the topic title though.
After this week of seeing Casey coding, I believe I have a better understanding of what he means when he talks about compression-oriented programming. Since it is something he has been asked about a few times, I have decided to get the ball rolling and start a thread on this topic. As a starter to anyone who hasn't followed the whole Handmade Hero series (and a complement to those who have) I highly recommend reading his blog posts on the topic at http://mollyrocket.com/casey/stream_0019.html and http://mollyrocket.com/casey/stream_0020.html the first of which I believe features the first appearance of Bob, of "the only way Bob can screw up is if Bob is just incompetent" fame.
As Casey has repeatedly stated during the coding of the windows platform layer, the fact that he was coding something which he already knew how it should look at the end has conditioned many of his decisions. Although he has tried to throughly explain every decision he has taken through each step, today's stream has IMHO shown the true process of compression-oriented programming. Through the week he has been setting up today's World and TileMap positioning (the Canonical and Raw positions) not in a way where he knew what the final code was going to look like but quite literally writing whatever code came to mind that accomplised the task at hand. This has had the consecuence of his code following a step-by-step evolution that followed his thought process from conception to code that accomplished the task. Funny enough, for those of you that paid attention at the end of thursday's stream and beginning of today's stream, the same logical steps resulted in rewriting the IsWorldPointEmpty function with the same exact argument calls at one point of today's stream. However, and most importantly, that first "evolution" of the code was just a momentary first step which resulted in two completely different functions by the end of the stream.
So what are the reasons to "evolve" the code that is initially written? Before starting to watch this series I would probably have said to make it more maintainable (easier to read and modify), to make it more modular (separated into chunks that can be applied to different scenarios) and possibly to make it more efficient (although I really would have meant more "clever looking" through the use of some algorithm that was specifically tailored to the task). After watching Casey code, I have realized the mistake of these approaches: the reason of the code is quite literally to DO SOMETHING. Once the code does that, I might want it to do ONE MORE THING. If that change is trivial then I look at how to DO YET ONE MORE THING. If, however, the change from one to two things requires a new structure, or I realize that I have to retype a chunk of code or variables and I see that I will have to repeat them shortly, then I will create a function or structure to avoid doing that. Thus, it is the code as I type it that "tells" me how to organize it and not the other way around (or, as in OOP, a programming paradigm which tells the code what to do regardless of anything else, which explains Casey's distate of OOP, or functional programming, or of any other set system of organizing the code).
This very fact was patent in the evolution of the "Canonical" and "Raw" positions on today's stream, and how Casey's understanding of their uses evolved with each iteration of what the code had to do, up to the point where he is confident he wil get rid of the raw position. It is however important to note that he has NOT gotten rid of the raw position structure, and it is my understanding that he is waiting for the time when the positioning code accomplishes all the functions it requires before deciding it is redundant to then delete it. It is my guess that if this was a part of the code that he had previously written before (as he has the windows layer) he would have started using the cannonical position from the beginning and we would not have seen this process unfold live. This would be a result of him having solved the problem before and thus having a different view of the logic to solve it, which starts with the cannonical view and not the raw position.
What I also found interesting about this whole process is the analogy between this short term process and the concept of the "Exploration-based Architecture" he presented on day 27. In both cases the end goal is relegated to something that only affects the current task in as much as it should be compatible to the next task which also points towards the same goal. Once I start thinking about how Casey has talked about how when having trouble with coding regulaly his solution is once again to think about coding for "just one hour" thus not thinking about the final goal but the next step, I start thinking it might be time to call it Compression-oriented Philosophy... but that might be just one step too far.
This is all of course just my understanding at this point of what Casey means with compression-oriented programming, and I might be wrong at some points, or even way of overal. I'd love to hear everyone elses opinion, including of course Casey's himself. Thanks to everyone who took the time to read the whole post!
Edited by Iker Murga
on
Seems like an excellent summarization of the philosophy, to me.
The beauty of it, as I understand it, is that in a general sense it can encompass multiple "paradigms" of programming if they are the easiest way to achieve compression. Objects could be an easy way of compressing the idea of an actor with attributes who performs actions. Functional thinking can compress systems that need to be general and work in composable ways. Introspection can compress code that needs to know about itself.
Having created tilemap systems before, the way we're doing it in Handmade Hero seems a lot easier and a lot faster (both in programmer time and in computer time) than what I've done in the past. And in two hours of work, too.
The beauty of it, as I understand it, is that in a general sense it can encompass multiple "paradigms" of programming if they are the easiest way to achieve compression. Objects could be an easy way of compressing the idea of an actor with attributes who performs actions. Functional thinking can compress systems that need to be general and work in composable ways. Introspection can compress code that needs to know about itself.
Having created tilemap systems before, the way we're doing it in Handmade Hero seems a lot easier and a lot faster (both in programmer time and in computer time) than what I've done in the past. And in two hours of work, too.