3 ms·

I don't at all mean to say he is wrong about performance. Casey is brilliant, his approach to writing software is optimal or near optimal when viewed through th

I don't at all mean to say he is wrong about performance. Casey is brilliant, his approach to writing software is optimal or near optimal when viewed through the lens of performance. And yet this is not the only lens through which to view software development. Correctness, expressiveness, portability, developer hours. There are many possible things to optimize for, and Casey barely gives these an ounce of weight compared to performance. The reason to target a program towards a platform with an operating system and a file system is because writing these things takes time, using them affords flexibility, and minimizes bugs from you're bespoke code. Casey does not view these as problems. Casey writes near-C for bare metal, or when not using bare metal directly against the platform API and if you only learned from him that's the only approach you would view as valid. When talking about his approach to writing code he constantly derides, sometimes very harshly, those who would think about program architecture any other way. I don't think the Rustacean evangelists' obsession with memory safety is the last word is software development, or Linus's assessment of languages other than C, or Jonathon Blow's and Casey's orientation with performance above all else. These are ideas, opinions, and there's some value in representing them as such.

sirwhinesalot 5y ago
100% agreed. I think when it comes to performance, the biggest takeaway from Casey/Jonathan is to just have the computer do less work. If you can get away with just poking at a big buffer then that's what you should do. It keeps the code both simple and efficient, no need for 30 layers of abstractions. But beyond that, IMO, it's fine to use higher-level constructs and target higher-level "platforms" (i.e. electron) to improve portability, developer productivity, etc. Even within that setting you can avoid doing things that pessimize your performance, and that's often enough for a massive improvement. Dogma is the bane of software-development, be it abstraction at all cost, immutability at all cost, or performance at all cost, etc.
- webmaven 5y ago
  > Dogma is the bane of software-development, be it abstraction at all cost, immutability at all cost, or performance at all cost, etc. You seem very sure of that.
  - sirwhinesalot 5y ago
    I do not claim to be enlightened, I am as flawed as my peers ;)

sirwhinesalot 5y ago

100% agreed. I think when it comes to performance, the biggest takeaway from Casey/Jonathan is to just have the computer do less work. If you can get away with just poking at a big buffer then that's what you should do. It keeps the code both simple and efficient, no need for 30 layers of abstractions. But beyond that, IMO, it's fine to use higher-level constructs and target higher-level "platforms" (i.e. electron) to improve portability, developer productivity, etc. Even within that setting you can avoid doing things that pessimize your performance, and that's often enough for a massive improvement. Dogma is the bane of software-development, be it abstraction at all cost, immutability at all cost, or performance at all cost, etc.

webmaven 5y ago
> Dogma is the bane of software-development, be it abstraction at all cost, immutability at all cost, or performance at all cost, etc. You seem very sure of that.
- sirwhinesalot 5y ago
  I do not claim to be enlightened, I am as flawed as my peers ;)