7 ms·

The PHP team does take speed seriously and just about every minor release gets a little bit faster, sometimes alot, like 20% faster. I'm not even including stuf

by cwt137 13y ago

The PHP team does take speed seriously and just about every minor release gets a little bit faster, sometimes alot, like 20% faster. I'm not even including stuff like the opcode caches that are built in now like APC or Zend Optimizer+. Lots of times, minor releases also get more efficient with memory usage too. If you are not happy with the speed, PHP is an open source project and you can contribute patches to speed it up. Documentation gets fixed all the time. PHP has been historically known as having one of the best docs and the docs have contributed to its success. As with the source code, the docs are open to contributions if you feel the need to modify or add something. That's funny you say PHP can't scale. Facebook, Yahoo, Etsy and a whole lot of other big PHP shops get more traffic than most of us will ever see in a few life times. So, PHP scales. Even pre-Hiphop Facebook got more traffic than most of us will will ever see. Many times scaling is more about architecture design/implementation than language. App Engine is all about scaling and PHP runs on it. Oh by the way, at scale, every language is a data center toaster oven. PHP people aren't mad that people are leaving. They are happy that it is still the #1 language used for web development. The only valid argument you have is the mixed methods and stuff. It would be cool to fix, but it would mean seriously breaking the API and would cause a lot of confusion. Every minor release breaks the API a little bit and people are unhappy. So, this might never change. I don't see it as a big deal because if you are a great programmer, you know the quirks of your language and they don't throw you off. Also, there is auto-completion and docs for you to look up things if you don't know stuff off the top of your head. It is true that lots of developers have left PHP, but it is a falsehood that everybody is moving away from PHP. If that was the case, PHP wouldn't be running on 75% of the public facing web hosts out there. There would be a business incentive (because they are using another language) to get PHP off their box. They could devote those resources to the new language they are using. The 75% number shows that their is no mass exodus, but definitely evidence not everybody is using PHP. Oh, by the way, PHP is open source so you can help contribute to its continued success if you like. If somehow you have already contributed, don't stop till the work is done.

dkhenry 13y ago
I do contribute to PHP. I have had a few patch submission fixing bugs here and there, but then you run into this http://www.php.net/manual/en/internals2.apiref.php This is PHP's documentation for fixing things internally to it. Which would be fine if the internals made any sence whatsoever, but between the implementation of steams and the abmismal design of zval's there isn't much to logically make sence of. And this isn't just well if you find it lacking its open source so make it better. We have we made better PHP's and named then things like Node.js and Python. Why would I implement a JIT in PHP when I could just use V8 and have an awesome runtime right out of the box ? Imperically PHP isn't nearly as fast or efficient as other languages, that’s not just an opinion it's been shown in multiple benchmarks and tests. I know it can be used for doing useful things and can even be used for large projects. I work on one of those daily, the issue is no one seems to care that as a platform PHP is _not_ a good choice any more, and increasingly the community isn't making a point of steering the platform to where it is a good choice. They just rattle off the same talking points of "Well facebook uses it" and "XX% of websites are using PHP so clearly it is good" You want a good PHP release? Provide documentaiton on the entire platform (http://www.php.net/manual/en/internals2.apiref.php http://www.php.net/manual/en/internals2.apiref.php) Fix the zvals to make thbem memory efficient Speed up the core ( not a opcode cache a real tracer and JIT ) Then add in yield and continuations, because without the other parts no one should care about language niceties, because no one should be using the language.

by cwt137 13y ago

dkhenry 13y ago

I do contribute to PHP. I have had a few patch submission fixing bugs here and there, but then you run into this http://www.php.net/manual/en/internals2.apiref.php This is PHP's documentation for fixing things internally to it. Which would be fine if the internals made any sence whatsoever, but between the implementation of steams and the abmismal design of zval's there isn't much to logically make sence of. And this isn't just well if you find it lacking its open source so make it better. We have we made better PHP's and named then things like Node.js and Python. Why would I implement a JIT in PHP when I could just use V8 and have an awesome runtime right out of the box ? Imperically PHP isn't nearly as fast or efficient as other languages, that’s not just an opinion it's been shown in multiple benchmarks and tests. I know it can be used for doing useful things and can even be used for large projects. I work on one of those daily, the issue is no one seems to care that as a platform PHP is _not_ a good choice any more, and increasingly the community isn't making a point of steering the platform to where it is a good choice. They just rattle off the same talking points of "Well facebook uses it" and "XX% of websites are using PHP so clearly it is good" You want a good PHP release? Provide documentaiton on the entire platform (http://www.php.net/manual/en/internals2.apiref.php http://www.php.net/manual/en/internals2.apiref.php) Fix the zvals to make thbem memory efficient Speed up the core ( not a opcode cache a real tracer and JIT ) Then add in yield and continuations, because without the other parts no one should care about language niceties, because no one should be using the language.