6 ms·
I don't think PHP's main problem is speed. It's generally used for websites, and a few milliseconds aren't going to make a difference when pages are so bloated
by nkkollaw 9y ago
I don't think PHP's main problem is speed. It's generally used for websites, and a few milliseconds aren't going to make a difference when pages are so bloated by JavaScript libraries to often be 5-10MB.
PHP's problem IMHO is that I wouldn't be able to use it if it wasn't for autocomplete: inconsistent function names, inconsistent parameter order.
The ecosystem is fine, there's Composer, PSR, Laravel. The problem is PHP's legacy.
I wish someone created a PHP class one could use to namespace sane function names and parameter order:
\PHP\html_entities()
\PHP\url_encode()
EDIT:
...and here it is: https://github.com/nkkollaw/php https://github.com/nkkollaw/php, discussion here: https://news.ycombinator.com/item?id=14885226 https://news.ycombinator.com/item?id=14885226.
Pull requests welcome :-)
- rrrryhffyhg 9y agothat should be static \PHP\String\htmlEntityEncode() and static \PHP\String\urlEncode() good luck
- frik 9y agoStupid idea IMHO. PHP is great BECAUSE it organic growth. It fully exposes the incorporated libraries with the same naming convention of the library functions and often additionally also in ObjectOriented style. Have a look how green field planned ObjectOriented Namespaces in Java and dotNet Framework 1-4 turned out. Java's String vs StringBuilder vs StringBuffer, Java's deprecated Date and Time classes, the whole "old" dotNet Framework has been deprecated for a slightly incompatible new dotNet Core namespace and several namespace parts got deprecated long before, some got useless with the move to asynchronous programming (something C/C++ based WinAPI supported since 1994), etc. What history showed us that monolithic namespaces designed by committee doesn't work out that well, an organic growth may look ugly to you but is easier to remember and quite sympathetic - I for one like PHP also because of that. JavaScript, C99, C++11, have a similar long term history. Also PHP is so great because of it best of class documentation on PHP.net - no other language has such an extensive docu (and for so many years) incl useful comments on every page. JavaDoc, MSDN, MozillaWiki, etc are unfortunately worse in every regard. (MDN is catching up; and even W3School is quite handy)
- k__ 9y agoAs I remember PHP docs from back in the days, they were mostly crap with the occasional comment that told you how they were crap.
- frik 9y agoIt's just you. PHP.net documentation was always better than the rest, easy to read, some simple examples and with helpful comments. JavaDoc, MSDN had no comments for decades, little examples and the later one lacked lots of API parts. Show me one online documentation of a language that is/was better. Also great are the book "Programming in C 2nd ed" and "Programming Lua", and the Golang focus isn't bad. PHP.net 2017 explode function: http://php.net/manual/en/function.explode.php http://php.net/manual/en/function.explode.php PHP.net 2005 explode function: https://web.archive.org/web/20050206214005/http://php.net/manual/en/function.explode.php https://web.archive.org/web/20050206214005/http://php.net/ma...
- k__ 9y agoI'm not saying the otheres were better. I 'm just saying that PHP.net docs simply had false claims and they needed the users to comment and make them right. I don't wanna know how much hours I lost with that, haha. Well these days I simply look in the source, because it doesn't lie
- lawpoop 9y agoWhat were the false claims?
- batat 9y agoSome awful stuff: http://php.net/manual/en/function.escapeshellarg.php http://php.net/manual/en/function.escapeshellarg.php http://php.net/manual/en/numberformatter.setpattern.php http://php.net/manual/en/numberformatter.setpattern.php
- nkkollaw 9y agoYou can't tell me that the fact that the opposite of the `htmlentities` function is `html_entity_decode` is "great, easier to remember and quite sympathetic". Of course you need great documentation, with those inconsistencies users have to look at it every 5 minutes to even know what they're doing. EDIT: Thanks. https://github.com/nkkollaw/php/commit/eeb8d6b38272eadaae4055e1330665c228da60cb https://github.com/nkkollaw/php/commit/eeb8d6b38272eadaae405...
- k__ 9y agoIf I remembered correctly, PHPs problem was never speed. All the conference talks back in the days were about how PHP-is-not-the-bottleneck-TM. Funny thing is that a bit of async Nodejs blow it out the water then, but maybe DBs got faster and PHP couldn't hold up on I/O perf? I don't know.
- ransom1538 9y agoReally? So the main issue with php is a few functions have inconsistent parameter order? Ignore the massive speed improvements, composer package manager system or huge community. Good companies use php. I haven't met someone at facebook that can't code it. (please spare me the HHVM comment or how your intern friend does haskell in the basement). Have you read about python 2 vs 3? Have you actually seen real programming language issues? Or tried to scale rails? Or worked on deploying java with 30 other people? Tracked a memory leak in c++? Been thrown into callback hell of node? Have you tried to get stackoverflow answers while developing in MEAN. IMHO people are just justifying their own stack (while secretly suffering with python - a 26 year old programming language) [1][2]. In reality they know php can do anything web / probably in less lines, portable, with easy to find information, with a strong community, in less time, faster. I will let everyone get back to figuring out what the difference between urllib and urllib2 is in python. [1]https://wiki.python.org/moin/Python2orPython3 https://wiki.python.org/moin/Python2orPython3 [2]https://stackoverflow.com/questions/2018026/what-are-the-differences-between-the-urllib-urllib2-and-requests-module https://stackoverflow.com/questions/2018026/what-are-the-dif... PS. Also, wtf does javascript librarys have to do with php.
- nkkollaw 9y agoWell, I specified "IMHO". That's the main issue that I have with PHP. I have no idea what they do at Facebook, and I don't have to work on the biggest community in the world that often. The problems I encounter in term of performance for websites/apps are along the lines of pages being super-slow because of the 100 JavaScript frameworks we like to use nowadays for the smallest of projects, my clients uploading 10MB images that get resized via HTML and still load at full-resolution, etc. As for coding yes—one issue I have is that not using PHP exclusively I get confused by the fact that the opposite of html_entity_decode is htmlentities and not html_entity_encode, and that slows me down for no apparent reason except the fact that 20 years ago one guy added htmlentities and another guy html_entity_decode, and no one thought about aliasing or deprecating one of the two to fix the unintuitive naming.
- ransom1538 9y ago"As for coding yes—one issue I have is that not using PHP exclusively I get confused by the fact that the opposite of html_entity_decode is htmlentities and not html_entity_encode" Ah yes. You will probably have to hit 'tab' on your IDE with php - to type "html_entity_encode". But if this is too hard - Here you go, Try it out in python (careful of the 2/3 quirks!): Python: https://stackoverflow.com/questions/275174/how-do-i-perform-html-decoding-encoding-using-python-django https://stackoverflow.com/questions/275174/how-do-i-perform-... Java: https://stackoverflow.com/questions/5741311/how-to-encode-special-chars-in-html-content https://stackoverflow.com/questions/5741311/how-to-encode-sp... Go: https://gist.github.com/brandonrachal/10605780 https://gist.github.com/brandonrachal/10605780 Rails: https://stackoverflow.com/questions/1600526/how-do-i-encode-decode-html-entities-in-ruby https://stackoverflow.com/questions/1600526/how-do-i-encode-... c++ (get your own sax ready!): http://forums.codeguru.com/showthread.php?448809-C-Replacing-HTML-Character-Entities http://forums.codeguru.com/showthread.php?448809-C-Replacing... Again the anti-php movement in action. A bunch of devs who used php 15 years ago.
- Lazare 9y agoI work on a modern PHP 7.1 codebase, and I personally disagree: > PHP's problem IMHO is that I wouldn't be able to use it if it wasn't for autocomplete: inconsistent function names, inconsistent parameter order. I know the functions you're talking about, and they're definitely a wart, but approximately 0% of my day is spent actually calling them directly. I spent a lot of time working with eg, collection classes which extend a base collection class which, sure, calls one of the interchangable array_* functions with their endlessly inconsistent parameter order, but I'm not calling them. Similarly, a lot of code I write every single day relies on encoding and decoding HTML entities, and yes, the fact that it's html_entity_decode and htmlentities is certainly embarrassing, but again, it's all handled by a library. It's an issue, but I'm not sure I'd find room for it on a top 10 list of issues with PHP. How about, say, the lack of generics? Now that's a flaw that actually impacts people using PHP professionally, whereas the htmlentities/html_entity_decode thing, in my experience, doesn't.
- nkkollaw 9y agoI get what you're saying but your point is that inconsistencies with PHP aren't a problem because you use libraries instead of core functions. That doesn't make core functions awesome, it's just that in your case you don't use them.
- Joeri 9y agoWell, the speed improvements unlock new kinds of things you can do. Old-style PHP code had to off-load any significant work to extensions, which made PHP a glue layer between the browser and the thing that did the real work. Now it's fast enough you can actually write all the code that does the real work in PHP. I spent 10 years writing PHP, and lately I'm writing Java, Scala and Node code instead. In each case it was due to needing specific libraries that PHP didn't have, but it did give me some insight into what PHP is missing to no longer be the glue layer but a real platform for "serious code": 1. No more ugly mix of procedural and OO code. I want all of PHP's stdlib to become object-oriented, including the primitive types. Also, I need a real type-hinted collections API, not just all-purpose arrays with global functions as primary API. Yes, it's just syntax. Yes, it does matter, a lot, even if you use phpstorm and auto-complete all the things. 2. Generics. Without generics it's impossible to do a properly type-hinted collections API, or a type-hinted FP library. Don't get me wrong, I don't want to type-hint all the things, but I do want to have type-hinted API's to build my own code on top of, and PHP's lack of generics makes this mostly impossible. I can't fix in userland what it misses in its stdlib. 3. A standard story for async and long-running code. Yes, I know about things like pthreads, curl_multi, amp and react-php. I never really felt like any of that stuff was really suited for mature production code and real-world deployment patterns, which is why I always ended up with architectures that boiled down to handing off anything long-running to a queue with separately launched workers processing it in series. I would like an extension to the standard PHP execution model and core language that gives a path towards fully non-blocking architectures as a standard feature.