> "I don't believe in
comments because they slow the PHP
interpreter down."
For some bizzare reason, a lot of PHP devs obsess over mini benchmarks and tiny speed issues while ignoring massive latency factors (like the DB).
I find it amusing, though, as PHP hasn't been a direct interpreter for years. It compiles to an internal opcode array and interprets that. While its opcode compiler is silly (it doesn't build an AST and directly emits opcodes, which causes all sorts of things not to work), it does have a proper lexer and I think comments are completely ignored aside from doc comments[1] which can be obtained in userland with reflection.
> For some bizzare reason, a lot of P̶H̶P̶ devs obsess over mini benchmarks and tiny speed issues while ignoring massive latency factors (like the DB).
This sort of behaviour isn't unique to PHP Devs, not even close.
Reminds me of all the roadies (road cyclists) who would come into our bike shop and demand the lightest components to put on their bikes, then rave about how they cut 10 GRAMS off of their bike weight. Totally ignoring the fact they're pushing almost 220lbs themselves.
Hah! I have this discussion every time somebody tries to upsell me at the bike shop. I tell them that if I'm going to try to take 5 pounds off the me+bike combo, I'm not starting with the bike.
Way back when, I did a small study (4 cyclists, 5 reps). The question: Could the rider tell which was heavier between a water bottle filled with lead shot, and one with glass beads. (2.5kg vs ~ 1kg).
1 rider managed to get more than half right. And he was a frame builder riding his own bike.
And there's nothing wrong with having optimized code. This seems to be a discussion about having the right priorities, not on the virtues of the optimizations themselves.
No, it's not unique to PHP devs. I've encountered C++ programmers that obsess over pass-by-value versus pass-by-reference and strings and minor things like that, even after that code has been written and proved to be fast enough, while ignoring the real bottlenecks that demonstrably hurt performance. A lot of times when there's a big glaring bottleneck, it needs to be solved at the macro level, by reworking the approach to macro-level features, seeing how you can get to the same place by doing fewer time-consuming operations. Those folks are penny-wise, pound-foolish.
For some bizzare reason, a lot of PHP devs obsess over mini benchmarks and tiny speed issues while ignoring massive latency factors (like the DB).
I find it amusing, though, as PHP hasn't been a direct interpreter for years. It compiles to an internal opcode array and interprets that. While its opcode compiler is silly (it doesn't build an AST and directly emits opcodes, which causes all sorts of things not to work), it does have a proper lexer and I think comments are completely ignored aside from doc comments[1] which can be obtained in userland with reflection.
[1] They look like this: