4 ms·

Rasmus created PHP for his own benefit to begin - how was he to know back in 1994 that it would grow to power so much of the web? We all make mistakes; we all l

by choult 13y ago

Rasmus created PHP for his own benefit to begin - how was he to know back in 1994 that it would grow to power so much of the web? We all make mistakes; we all learn from them. Lets move on. Of course, noone in this day and age would make any dodgy design decisions... would they? http://www.chmod777self.com/2013/08/sigh.html http://www.chmod777self.com/2013/08/sigh.html

goldenkey 13y ago
There's nothing wrong with the code that Node uses for HTTP verbs. It's optimized to do a single byte comparison where it needs to, the code is taken straight from nginx which is brutally optimized. You want speed, you got it.
- choult 13y ago
  While it's true that the code in question was taken straight from nginx, if you bothered to read the NodeJS implementation (pre-fix, and referenced in my link) you would see that a secondary check against the full verb (that nginx performs further down the line) was not included. Hence you could GEM a page or PUN an object. I'm not sure I want a codebase that's "brutally optimized" to the extent that it's not functionally equivalent. EDIT: Used "functionally equivalent" as a more proper phrase than "idempotent" after the below feedback
  - goldenkey 13y ago
    Don't use the word idempotent. One of my pet peeves is use of higher level vocabulary in the wrong context. Nothing is being applied multiple times. And the optimized code is a beast of its own, it's not an 'optimized' operation on a normal piece of code. The code simply does not perform the same rigor as slow, spec-following code would.
growse 13y ago
The problem isn't making mistakes. The problem is not correcting them when you've learned they are a mistake and have had ample opportunity to do so.
- fzltrp 13y ago
  The opportunity is still there. This kind of mistake is easily fixed: create your own aliases for the functions you'd like to rename, and it's done. If the PHP people are unhappy with them, they could do exactly the same, deprecate and remove the original names through a couple of major releases, and the problem is solved as well. Same solutuon for parameter order (needle, haystack, whatever). Really I don't understand all the fuss around PHP functions names.
  - ajuc 13y ago
    > Really I don't understand all the fuss around PHP functions names. You could add aliases to all functions in php in your company, but then you would need to teach these aliases to all new developers. Also every company would have different aliases and people changing jobs would need to relearn everything. So aliases are theorethical solution that nobody use in practice. Changing the standard makes a new common language that you can actually use.
- choult 13y ago
  Very true; I would be disappointed to discover that PHP is still using the same hashing function. However, changing the function names (especially some of the core ones) is fraught with backwards-compatibility issues - PHP code written 15 years ago should, for the most part, still work, and not enough hosts out there run with the right error reporting to point out deprecation warnings, so you would probably end up with a lot of PHP sites with code silently failing when a host upgraded.
  - deleted 13y ago
    [deleted]
  - laumars 13y ago
    I completely disagree. As a language matures, features need to be depreciated as newer / better features are implemented. It's actually quite common for languages to do this. In fact PHP HAS depreciated functions over it's life, so 15 year old code might not run on modern web servers anyway. Yet we still have the same function names where they should have been renamed.
userbinator 13y ago
They could've used a 32-bit comparison instead, which would remove much of the oddities (and probably run at the same speed on modern processors).
laumars 13y ago
Nobody can blame the guy for the design choices and naming conventions he made back then. The problem is that they still exist 20 years later when much of the worlds web infrastructure runs on PHP. I'd have expected (hoped) that by the time of the last major release (v5.0) the chief PHP devs would have used that opportunity to to rename some of the core functions. By that point PHP's popularity was already established and the shortcomings of it known. Plus as there was already a major Zend rewrite under way, to me it seems a sensible time to throw in a few in a few niceties to beautify / simplify the APIs. Perl -PHP's spiritual predecessor- managed to tidy itself up circa v5.8 and now, ironically, Perl is cleaner language to code in despite the jokes about it being executable line noise.
- choult 13y ago
  The past five or so years have seen engineers of greater experience take interest in PHP's ecosystems and core; a greater maturity in PHP is emerging. I suspect we'll see bigger changes coming over the next five or ten years, but it takes time to tame chaos.
  - dscrd 13y ago
    But.. why? Why not just move to a language that is already clean and good?
    - chaosphere2112 13y ago
      http://en.wikipedia.org/wiki/Sunk_costs http://en.wikipedia.org/wiki/Sunk_costs
      - darkf 13y ago
        http://en.wikipedia.org/wiki/Sunk_costs#Loss_aversion_and_the_sunk_cost_fallacy http://en.wikipedia.org/wiki/Sunk_costs#Loss_aversion_and_th...
        chaosphere2112 13y ago

by choult 13y ago

goldenkey 13y ago

There's nothing wrong with the code that Node uses for HTTP verbs. It's optimized to do a single byte comparison where it needs to, the code is taken straight from nginx which is brutally optimized. You want speed, you got it.

choult 13y ago
While it's true that the code in question was taken straight from nginx, if you bothered to read the NodeJS implementation (pre-fix, and referenced in my link) you would see that a secondary check against the full verb (that nginx performs further down the line) was not included. Hence you could GEM a page or PUN an object. I'm not sure I want a codebase that's "brutally optimized" to the extent that it's not functionally equivalent. EDIT: Used "functionally equivalent" as a more proper phrase than "idempotent" after the below feedback
- goldenkey 13y ago
  Don't use the word idempotent. One of my pet peeves is use of higher level vocabulary in the wrong context. Nothing is being applied multiple times. And the optimized code is a beast of its own, it's not an 'optimized' operation on a normal piece of code. The code simply does not perform the same rigor as slow, spec-following code would.

growse 13y ago

The problem isn't making mistakes. The problem is not correcting them when you've learned they are a mistake and have had ample opportunity to do so.

fzltrp 13y ago
The opportunity is still there. This kind of mistake is easily fixed: create your own aliases for the functions you'd like to rename, and it's done. If the PHP people are unhappy with them, they could do exactly the same, deprecate and remove the original names through a couple of major releases, and the problem is solved as well. Same solutuon for parameter order (needle, haystack, whatever). Really I don't understand all the fuss around PHP functions names.
- ajuc 13y ago
  > Really I don't understand all the fuss around PHP functions names. You could add aliases to all functions in php in your company, but then you would need to teach these aliases to all new developers. Also every company would have different aliases and people changing jobs would need to relearn everything. So aliases are theorethical solution that nobody use in practice. Changing the standard makes a new common language that you can actually use.
choult 13y ago
Very true; I would be disappointed to discover that PHP is still using the same hashing function. However, changing the function names (especially some of the core ones) is fraught with backwards-compatibility issues - PHP code written 15 years ago should, for the most part, still work, and not enough hosts out there run with the right error reporting to point out deprecation warnings, so you would probably end up with a lot of PHP sites with code silently failing when a host upgraded.
- deleted 13y ago
  [deleted]
- laumars 13y ago
  I completely disagree. As a language matures, features need to be depreciated as newer / better features are implemented. It's actually quite common for languages to do this. In fact PHP HAS depreciated functions over it's life, so 15 year old code might not run on modern web servers anyway. Yet we still have the same function names where they should have been renamed.

userbinator 13y ago

They could've used a 32-bit comparison instead, which would remove much of the oddities (and probably run at the same speed on modern processors).

laumars 13y ago

Nobody can blame the guy for the design choices and naming conventions he made back then. The problem is that they still exist 20 years later when much of the worlds web infrastructure runs on PHP. I'd have expected (hoped) that by the time of the last major release (v5.0) the chief PHP devs would have used that opportunity to to rename some of the core functions. By that point PHP's popularity was already established and the shortcomings of it known. Plus as there was already a major Zend rewrite under way, to me it seems a sensible time to throw in a few in a few niceties to beautify / simplify the APIs. Perl -PHP's spiritual predecessor- managed to tidy itself up circa v5.8 and now, ironically, Perl is cleaner language to code in despite the jokes about it being executable line noise.

choult 13y ago
The past five or so years have seen engineers of greater experience take interest in PHP's ecosystems and core; a greater maturity in PHP is emerging. I suspect we'll see bigger changes coming over the next five or ten years, but it takes time to tame chaos.
- dscrd 13y ago
  But.. why? Why not just move to a language that is already clean and good?
  - chaosphere2112 13y ago
    http://en.wikipedia.org/wiki/Sunk_costs http://en.wikipedia.org/wiki/Sunk_costs
    - darkf 13y ago
      http://en.wikipedia.org/wiki/Sunk_costs#Loss_aversion_and_the_sunk_cost_fallacy http://en.wikipedia.org/wiki/Sunk_costs#Loss_aversion_and_th...
      - chaosphere2112 13y ago