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 happe…
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!
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!