3 ms·

Replace optimization with security, good design, or any other important facet of software engineering, and you have the same story. Good software is a multifac

Replace optimization with security, good design, or any other important facet of software engineering, and you have the same story. Good software is a multifaceted effort, and great software takes care of the important parts with attention to detail where relevant: great games libraries don't add significant overhead to frame time, great filesystem libraries don't increase read time, great security libraries don't expose users to common usage pitfalls creating less secure environments than had you used nothing at all. It happens to be that optimization gets deprioritized at the expense of other things, where "other things" in this context is some category I fail to pin down because PMs don't give a shit about what that other category could be, and instead just care that whatever you're working on is shipped to begin with. Great software developers will respect the important parts, and still ship. And yes, it's always easier to do this from the start than it is to figure it out later. Many things in life are this way. I have a soft spot for performance, though, so I care about this message. One day hardware will reach spacial, thermal, and economic limits and when that day comes, software engineers will have to give a shit, because too many sure as hell don't seem to give a shit now.

taeric 8y ago
Fully agreed. I feel for teams working on something that requires all of this. Things are much easier when you do less. For many many reasons.
stcredzero 8y ago
The Rule of Everything in Software Development: Everything should be subject to cost/benefit! Corollaries: (...don't do that!) - If you paint yourself into an untenable corner, you lose! - If you plant a time bomb that explodes and kills you, you lose! - If you sink yourself too deeply into technical debt, you die! You lose! Avoiding pre-optimization is just the flip side of the intelligent cost/benefit analysis coin. Don't start writing hyper-optimized code everywhere. However, also don't architect your real-time game system such that making string comparisons is inextricably the most common operation. Here's a solution that I've found. It's not foolproof, but it will get you out of trouble quite often. Code such that you can change your mind. HN user jerf's "microtyping" technique in Golang let me do that with my side project. I committed the egregious error I mentioned above, of using string identifiers for the UUID of my MMO game entities. But because I followed the "microtyping" technique and did not directly use type string, but rather used ShipID, I could simply redefine: //type ShipID string // old bad way type ShipID struct { // new way A int64 B int64 } Where possible, your code changes should be bijections. Renamings should be bijections and never surjections. The bigger your changes, and the more automation is involved, the more you should hew to bijective changes.
- perfmode 8y ago
  what do you mean by bijection/bijective in the context of refactoring and iteration?
  - jessaustin 8y ago
    Presumably GP meant that the mapping from old ShipID to new ShipID must be injective. Bijective would also work, but if the mapping were merely surjective there could be multiple entities in the old code mapped to a single entity in the new code. That seems sure to cause problems.
    - stcredzero 8y ago
      Actually, a surjection might result in a refactoring in the pedantic sense. Also, some refactorings work out to be surjections.
  - stcredzero 8y ago
    Remapping ShipID from string to a struct of two 64 bit integers is bijective. No information was lost in that transformation, and I can reverse it at will. The following is a bijection. It is reversible. A ---> a B ---> b The following is not a bijection. It is not easily reversible. A ---> b B ---> b So for example, if I rewrite all occurrences of "ShipID" to be "string," those occurrences get lost among all of the other uses of "string." I could always go back to git and back out the change, but what happens in the future, when those changes have become interspersed with other changes?

taeric 8y ago

Fully agreed. I feel for teams working on something that requires all of this. Things are much easier when you do less. For many many reasons.

stcredzero 8y ago

The Rule of Everything in Software Development: Everything should be subject to cost/benefit! Corollaries: (...don't do that!) - If you paint yourself into an untenable corner, you lose! - If you plant a time bomb that explodes and kills you, you lose! - If you sink yourself too deeply into technical debt, you die! You lose! Avoiding pre-optimization is just the flip side of the intelligent cost/benefit analysis coin. Don't start writing hyper-optimized code everywhere. However, also don't architect your real-time game system such that making string comparisons is inextricably the most common operation. Here's a solution that I've found. It's not foolproof, but it will get you out of trouble quite often. Code such that you can change your mind. HN user jerf's "microtyping" technique in Golang let me do that with my side project. I committed the egregious error I mentioned above, of using string identifiers for the UUID of my MMO game entities. But because I followed the "microtyping" technique and did not directly use type string, but rather used ShipID, I could simply redefine: //type ShipID string // old bad way type ShipID struct { // new way A int64 B int64 } Where possible, your code changes should be bijections. Renamings should be bijections and never surjections. The bigger your changes, and the more automation is involved, the more you should hew to bijective changes.

perfmode 8y ago
what do you mean by bijection/bijective in the context of refactoring and iteration?
- jessaustin 8y ago
  Presumably GP meant that the mapping from old ShipID to new ShipID must be injective. Bijective would also work, but if the mapping were merely surjective there could be multiple entities in the old code mapped to a single entity in the new code. That seems sure to cause problems.
  - stcredzero 8y ago
    Actually, a surjection might result in a refactoring in the pedantic sense. Also, some refactorings work out to be surjections.
- stcredzero 8y ago
  Remapping ShipID from string to a struct of two 64 bit integers is bijective. No information was lost in that transformation, and I can reverse it at will. The following is a bijection. It is reversible. A ---> a B ---> b The following is not a bijection. It is not easily reversible. A ---> b B ---> b So for example, if I rewrite all occurrences of "ShipID" to be "string," those occurrences get lost among all of the other uses of "string." I could always go back to git and back out the change, but what happens in the future, when those changes have become interspersed with other changes?