How the first PHP functions were named(phpmanualmasterpieces.tumblr.com)
phpmanualmasterpieces.tumblr.com
How the first PHP functions were named
http://phpmanualmasterpieces.tumblr.com/post/70257636397/im-crying-literally-crying-actual-tears-in-my
10 comments
When I was visiting my brother for Christmas last year, my 14 year old nephew told me he was interested in coding and really wanted to learn Java and PHP. My reaction was "you clearly don't read Hacker News".
Yes, PHP has some odd function names. We know. Move on already.
PHP has a ton of oddities:
http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-de...
Why do people feel the need to spam this on every single PHP thread?
Yes I know. Crazy, right?
Why should people move on? I want people to be educated in how horrible PHP is, I want to see PHP burn and be abandoned.
I like the story of PHP because it is a very powerful reminder that ultimately what matters is that something works, not that it is beautifully designed or appeals to some other higher-order train of thought. It's a very grassroots-style of innovation where pragmatism prevails, and there is no "right" way that people dogmatically follow. You don't have to know much about data structures or hashing to do anything useful, just find a way that works. You don't have to worry about finding the "perfect design". If people can learn a language like English with far more irregularity, inconsistent function names are the least of their worries. Just do it. And I find that very inspirational and motivating because it says that anyone who puts enough effort into getting something done, will.
I completely lost interest in programming because of PHP. When I discovered other languages where I didn't need to search the documentation every time I tried to remember a function name, or debug crazy text encoding/silent failure bugs, programming because fun again.
I have written good amounts of PHP code since then, and maintained even more of it. I've also used MVC frameworks like Symfony2, where few of the usual arguments against PHP apply, but it still feels like a low quality language with the tens to hunddeds of pitfalls one has to watch out for. And don't get me started on the Wordpress development that seems to be the main technology for webdev jobs today.
The argument that PHP is easy to get started with for beginners is a lie. Sure, you can install LAMP and start writing echo statements and it just works, but what then? The behavior of your code is sometimes weird, functions have cryptic names, and there's really nothing to point you in the right directions. There's no enforced or even encouraged conventions, and there's heaps of "Common Knowledge" one must acquire to write safe code.
I have written good amounts of PHP code since then, and maintained even more of it. I've also used MVC frameworks like Symfony2, where few of the usual arguments against PHP apply, but it still feels like a low quality language with the tens to hunddeds of pitfalls one has to watch out for. And don't get me started on the Wordpress development that seems to be the main technology for webdev jobs today.
The argument that PHP is easy to get started with for beginners is a lie. Sure, you can install LAMP and start writing echo statements and it just works, but what then? The behavior of your code is sometimes weird, functions have cryptic names, and there's really nothing to point you in the right directions. There's no enforced or even encouraged conventions, and there's heaps of "Common Knowledge" one must acquire to write safe code.
Sorry to break it to you but that's simply not going to happen (at least anytime soon). Why not direct your effort at improving the language instead?
Edit: I'm not necessarily disagreeing with you but I just want to know what your reasons would be to see it die rather than be improved.
Edit: I'm not necessarily disagreeing with you but I just want to know what your reasons would be to see it die rather than be improved.
"Why not direct your effort at improving the language instead?"
Or indeed developing a successor. Loads of people bitch about how bad PHP is - I see very few efforts to even come up with a better alternative.
Or indeed developing a successor. Loads of people bitch about how bad PHP is - I see very few efforts to even come up with a better alternative.
They already exist (python, ruby, ...). Improvement is the only way the PHP commuity as the php community will progress.
Sadly, for that PHP-community, many developers outgrow PHP and move on.
Instead of the developers growing and improving, and so pulling the entire community upwards, many simply choose to leave. I've had this personally with Drupal: many, many years did I poor a (joined!) effort into getting proper TDD, OOP, deployment strategies into this CMS, but in the end I gave up. I mean: why put effort into making Drupal something it does not want to be; while a few weeks of learning a new language, the thing I wanted Drupal to become, already exists.
I think PHP is mostly a station in the career of many webdeveloper, before they move on to what are often considered "more professional environments". Sure, there are a few brilliant and very professional PHP-devs who stick around. But relatively seen, they are a tiny minority.
Instead of the developers growing and improving, and so pulling the entire community upwards, many simply choose to leave. I've had this personally with Drupal: many, many years did I poor a (joined!) effort into getting proper TDD, OOP, deployment strategies into this CMS, but in the end I gave up. I mean: why put effort into making Drupal something it does not want to be; while a few weeks of learning a new language, the thing I wanted Drupal to become, already exists.
I think PHP is mostly a station in the career of many webdeveloper, before they move on to what are often considered "more professional environments". Sure, there are a few brilliant and very professional PHP-devs who stick around. But relatively seen, they are a tiny minority.
yes but simply put, no one gives a shit what you want, other than the ones that already share your feelings.
You're not going to convince good php developers to stop using php, but you will convince the bad ones... actually go on with your bad self, ruby/python needs more bad devs
You're not going to convince good php developers to stop using php, but you will convince the bad ones... actually go on with your bad self, ruby/python needs more bad devs
I have been a longtime PHP avoider myself, but I just recently installed Wordpress for the first time and I admit to being impressed by a few things.
One is the fact that because of the implementation of PHP, where I assume a totally new process is created for every web request, a PHP app can actually edit itself and emerge different for the next incoming request.
Because of this, Wordpress has amazing features where non technical users can install plugins and even edit the source code of Wordpress, in Wordpress... This would not be as easily done in any of the various reputable languages I'm aware of... at least not in the standard implementations of those languages.
One is the fact that because of the implementation of PHP, where I assume a totally new process is created for every web request, a PHP app can actually edit itself and emerge different for the next incoming request.
Because of this, Wordpress has amazing features where non technical users can install plugins and even edit the source code of Wordpress, in Wordpress... This would not be as easily done in any of the various reputable languages I'm aware of... at least not in the standard implementations of those languages.
Plugin support is not something that is exclusive, or even easily implemented, in PHP. Compiled languages with Lua bindings does this better, with the benefit of very easy sandboxing. Ghost (https://ghost.org/) is a more mainstream example, and it has plugin support.
As someone who has developed wordpress themes, the plugin support in wordpress is a gigantic source of frustration. It is not amazing under the hood.
As someone who has developed wordpress themes, the plugin support in wordpress is a gigantic source of frustration. It is not amazing under the hood.
Perhaps you never learned that you are on the wrong side of the "Worse is Better" divide...
Ah, the great PHP massiah. This indeed looks like some very productive use of your time and effort.
I love PHP.
Interesting trivia I've wondered about (like "why are the registers in x86 named in A, C, D, B order), not really any issue though; you memorise them just as well in any case if you work with enough code.
> why are the registers in x86 named in A, C, D, B order
Umm...they're not. Who names them in that order?
Umm...they're not. Who names them in that order?
Ah, Ok, I did not know that. You learn something new every day. Thanks!
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
Of course, noone in this day and age would make any dodgy design decisions... would they?
http://www.chmod777self.com/2013/08/sigh.html
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
One thing I like a lot about PHP is its version stability, it has changed somewhat over time, but not to the point where it breaks important features.
I have seen many a framework and language (the sort that you might see hyped on this website) that make drastic changes and only their most ardent fans stick with the new version. It's often an opportunity to switch to the next big thing.
I have seen many a framework and language (the sort that you might see hyped on this website) that make drastic changes and only their most ardent fans stick with the new version. It's often an opportunity to switch to the next big thing.
I'm not asking for PHP to break it's compatibility over night, but it's fairly reasonable for a language to depreciate a function over several major releases which might span a few years.
ie version 5.6 will raise a warning when some_function is called, saying that some_function will be depreciated in future versions of PHP. So you have both the old and new functions running in parallel for a while. Then a couple of major versions later, you drop support for the older function name.
As I said before, PHP has already been doing just this for some stuff for a while now, so it's not an alien concept to PHP developers.
ie version 5.6 will raise a warning when some_function is called, saying that some_function will be depreciated in future versions of PHP. So you have both the old and new functions running in parallel for a while. Then a couple of major versions later, you drop support for the older function name.
As I said before, PHP has already been doing just this for some stuff for a while now, so it's not an alien concept to PHP developers.
I'm all for standardizing core function names and deprecating outmoded items, but I was merely pointing out the problems inherent in doing so - there are pros and cons to all decisions, and a great deal are complicated greatly once they're out in the wild for a long time.
I think the latest PHP APIs are the least of your problems if you're running sites with code that hasn't been touched in 15 years:
* new security threats that have been discovered in that time which needed to be coded against (In the last 15 years, a lot has changed with the approach we have to building secure sites).
* newer web standards and browsers - thus compatibility on the client side might now be an issue.
* different computing paradigms (we use touch interfaces where hover-over menus wouldn't function. There's a massive range of different client side screen resolutions and aspect ratios these days too).
* different methods of sharing content (for some types of sites, supporting OpenGraph and Twitter Cards is pretty important if you depend on your content getting exposure from "word of mouth").
* different user expectations (a 15 year old site is unlikely to look any good compared their modern counterparts. While that might not matter for some sites, if you're trying to generate traffic from the average layman, then they might be put off and prefer a site which is more aesthetically pleasing).
So if someone is trying to port 15 year old PHP code to a new server, then I'd expect they'd want / need to do a sizeable amount of rewriting anyway - regardless of API compatibility. In this instance, API compatibility is the least of their worries as you can at least just use the 'find/replace' tool in your text editor to fix renamed APIs, where as fixing the other issues (eg switching from the older method of dropping variables into an SQL string, to the current preferred method of parametrized SQL which negates the risk of SQL injection attacks) will take much longer.
* new security threats that have been discovered in that time which needed to be coded against (In the last 15 years, a lot has changed with the approach we have to building secure sites).
* newer web standards and browsers - thus compatibility on the client side might now be an issue.
* different computing paradigms (we use touch interfaces where hover-over menus wouldn't function. There's a massive range of different client side screen resolutions and aspect ratios these days too).
* different methods of sharing content (for some types of sites, supporting OpenGraph and Twitter Cards is pretty important if you depend on your content getting exposure from "word of mouth").
* different user expectations (a 15 year old site is unlikely to look any good compared their modern counterparts. While that might not matter for some sites, if you're trying to generate traffic from the average layman, then they might be put off and prefer a site which is more aesthetically pleasing).
So if someone is trying to port 15 year old PHP code to a new server, then I'd expect they'd want / need to do a sizeable amount of rewriting anyway - regardless of API compatibility. In this instance, API compatibility is the least of their worries as you can at least just use the 'find/replace' tool in your text editor to fix renamed APIs, where as fixing the other issues (eg switching from the older method of dropping variables into an SQL string, to the current preferred method of parametrized SQL which negates the risk of SQL injection attacks) will take much longer.
[deleted]
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.
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.
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.
But.. why? Why not just move to a language that is already clean and good?
I'm not defending the practice, I'm just saying it's the argument that gets used. "We're an oracle shop, we've spent $N Million on getting set up as an oracle shop, and we'll always be an oracle shop. Let's use ADF[1]."
[1]:http://www.oracle.com/technetwork/developer-tools/adf/overvi...
[1]:http://www.oracle.com/technetwork/developer-tools/adf/overvi...
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).
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.
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
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
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.
The code simply does not perform the same rigor as slow, spec-following code would.
According to this stats: http://w3techs.com/technologies/history_overview/programming... PHP has 80% market share and growing. There must be some other advantages over this badly picked function names.
But if we talk about disadvantages, me personally do not like WordPress because of its slowness.
But if we talk about disadvantages, me personally do not like WordPress because of its slowness.
I find it hard to use this survey as actual statistics. I could not find any details on how they measure, how many sites and servers are measured and so on. As far as I know, someone emailed his 400 friends on Facebook and placed the results in an excel-sheet.
* Does it take volume into account? Github (Ruby, Java, Scala) alone serves more pages then your average 10K Wordpress-sites will. Yet Facebook (PHP) serves such a huge number that it might even dwarve all the "enterprice" C#, Java and Cobol sites of probably all governments in the entire EU.
* Does it take economic value in account? One gov. site, or one large application (say, google docs) alone costs a multitude of what a 100K mom&pop PHP-webshops have cost. I, personally (as in: this is not a statistic nor any proof of anything) see a lot more value going around in the Ruby on Rails webdevelopment-economy then in the PHP-economy; the latter seems to consist of mostly a few-hundred-bucks Drupal installs or WordPress themes, whereas the first is almost always custom built and startup-development growing far over the 1K.
* How do they adjust for "not recognised"? I mean: it is hard to hide the fact that you are running a Drupal site, even for something large as the Whitehouse.gov. Whereas your average custom-built Django-backend is probably not even accessible for crawlers and even if so, most probably not recognisable as being Python/Django powered. In other words: off-the-shelve stacks are far more often recognised; and are, quite probably, nearly always PHP.
* How does this account for all the backend? Sure, WordPress is written in PHP, but many WP sites run off MySQL, which is just as important as the PHP-part; is WP not, PHP and MySQL powered then? Or other backends: the startup where I work now, has 90% of its code in the backend, Rails, with a tiny 200 lines PHP-app facing our users. This is certainly not a PHP-app, but would this survey count it as such?
* Does it take volume into account? Github (Ruby, Java, Scala) alone serves more pages then your average 10K Wordpress-sites will. Yet Facebook (PHP) serves such a huge number that it might even dwarve all the "enterprice" C#, Java and Cobol sites of probably all governments in the entire EU.
* Does it take economic value in account? One gov. site, or one large application (say, google docs) alone costs a multitude of what a 100K mom&pop PHP-webshops have cost. I, personally (as in: this is not a statistic nor any proof of anything) see a lot more value going around in the Ruby on Rails webdevelopment-economy then in the PHP-economy; the latter seems to consist of mostly a few-hundred-bucks Drupal installs or WordPress themes, whereas the first is almost always custom built and startup-development growing far over the 1K.
* How do they adjust for "not recognised"? I mean: it is hard to hide the fact that you are running a Drupal site, even for something large as the Whitehouse.gov. Whereas your average custom-built Django-backend is probably not even accessible for crawlers and even if so, most probably not recognisable as being Python/Django powered. In other words: off-the-shelve stacks are far more often recognised; and are, quite probably, nearly always PHP.
* How does this account for all the backend? Sure, WordPress is written in PHP, but many WP sites run off MySQL, which is just as important as the PHP-part; is WP not, PHP and MySQL powered then? Or other backends: the startup where I work now, has 90% of its code in the backend, Rails, with a tiny 200 lines PHP-app facing our users. This is certainly not a PHP-app, but would this survey count it as such?
> Facebook (PHP)
Facebook (PHP transpiled to C and compiled into a binary)
Facebook (PHP transpiled to C and compiled into a binary)
They abandoned that a while ago. Facebook now runs on HHVM, which is a JIT-compiler implementation of PHP.
Oh, neat. Didn't realize they had. Thanks.
which is why I mentioned this specifically: would this survey count Facebook as PHP, or as C? This makes a big difference on the outcome of "the amount of large sites running on language X"
>There must be some other advantages over this badly picked function names.
Very easy to learn
Very easy to learn
I'd always argue against this. Python is, by far, easier to learn. Python was, after all, designed as a language to teach programming.
The issue is, that people often compare apples and oranges here:
Good, SOLID, and well-architectured OOP PHP applications (YII, Zend) are far harder to learn then Django or Rails. It is unfair to compare the "hacking of a free WordPress theme" to "setting up and deploying a full MVC application in Rails". When you compare similar stacks, PHP is, nearly always, the harder-to-learn choice.
A simple, hacked-together sequential script serving a webpage is, by far, easier in both Python and Ruby then in PHP. If only for the fact that both Python and Ruby come with decent, built-in webservers. PHP has gotten this in the latest release only, but before, a fair comparison would be: a PHP app requires you to erect a full LAP-stack, whereas a python-script could be serving pages on the most barebone machine with Python installed.
Again, the very beginning of PHP might seem easier to learn, because in practice, a lot of the infra is there and a lot of groundwork is already done (LAMP-stacks come for almost free; Passenger or Fastcgi not so much, allthough they are there). And then, when going a bit further then "removing these two menu-items in a WP-theme", when moving into the area of proper designed, maintainable webstacks, PHP is a lot harder to learn. And when moving one step further, e.g. including stuff like asyncronous workers, long-running-threads, commandline-tools, and so forth, PHP is often even completely unable to cope, but in the very least, proves a really hard and cumbersome tool.
The issue is, that people often compare apples and oranges here:
Good, SOLID, and well-architectured OOP PHP applications (YII, Zend) are far harder to learn then Django or Rails. It is unfair to compare the "hacking of a free WordPress theme" to "setting up and deploying a full MVC application in Rails". When you compare similar stacks, PHP is, nearly always, the harder-to-learn choice.
A simple, hacked-together sequential script serving a webpage is, by far, easier in both Python and Ruby then in PHP. If only for the fact that both Python and Ruby come with decent, built-in webservers. PHP has gotten this in the latest release only, but before, a fair comparison would be: a PHP app requires you to erect a full LAP-stack, whereas a python-script could be serving pages on the most barebone machine with Python installed.
Again, the very beginning of PHP might seem easier to learn, because in practice, a lot of the infra is there and a lot of groundwork is already done (LAMP-stacks come for almost free; Passenger or Fastcgi not so much, allthough they are there). And then, when going a bit further then "removing these two menu-items in a WP-theme", when moving into the area of proper designed, maintainable webstacks, PHP is a lot harder to learn. And when moving one step further, e.g. including stuff like asyncronous workers, long-running-threads, commandline-tools, and so forth, PHP is often even completely unable to cope, but in the very least, proves a really hard and cumbersome tool.
Yep, I think Rails is easier to learn compared with Zend, which is over-designed for me. I will choose CodeIgniter in the shared hosting world, but in the cloud age haha, you can host almost everything for free - Spring, Rails, Django. So this can change the things, except for "Brochure Web Sites" where WordPress is the king.
When comparing stacks, (1) to serve a PHP page you upload it to the server and you're done, (2) a basic PHP page is a web page. Python just lost. (Not that I don't prefer python.)
It's not PHP, it's mod_php that makes PHP so easy to use.
It's not PHP, it's mod_php that makes PHP so easy to use.
You're correct, but unfortunately that's not the point. PHP makes it very easy to learn to write ugly hacky code quickly, and in the beginning, that's all that matters - the person learning simply doesn't know any better.
> If only for the fact that both Python and Ruby come with decent, built-in webservers.
With PHP 5.4+: `php -S 0.0.0.0:8000`, just as useful as SimpleHTTPServer.
And I wasn't aware of Ruby coming with a web server. I know of WEBrick for Rails -- but is there a standard module that Ruby ships with that's similar to the above PHP and Python servers?
With PHP 5.4+: `php -S 0.0.0.0:8000`, just as useful as SimpleHTTPServer.
And I wasn't aware of Ruby coming with a web server. I know of WEBrick for Rails -- but is there a standard module that Ruby ships with that's similar to the above PHP and Python servers?
Webrick comes in the <a href="http://www.ruby-doc.org/stdlib-2.0.0/libdoc/webrick/rdoc/ind....
I explicitely mentioned that the latest release of PHP comes with the built-in -S server. But that before this, it was always either install *AMP of some variation, which is, frankly a lot harder. And even now, Whereas Rails requires a few commanline commands, a CMS like Drupal still needs quite some fiddling to get it ro run on your localhost. (Source: I have been professional Drupal trainer for years)
But let me note that neither three of these servers are anything good for production. But, for small (internal) projects, `SimpleHTTPServer`, `Webrick` or even `php -S` might suffice, especially when behind a reverse proxy. Yet of all three, Webrick is especially slow, and php-s is especially memory-leaking and unstable.
I explicitely mentioned that the latest release of PHP comes with the built-in -S server. But that before this, it was always either install *AMP of some variation, which is, frankly a lot harder. And even now, Whereas Rails requires a few commanline commands, a CMS like Drupal still needs quite some fiddling to get it ro run on your localhost. (Source: I have been professional Drupal trainer for years)
But let me note that neither three of these servers are anything good for production. But, for small (internal) projects, `SimpleHTTPServer`, `Webrick` or even `php -S` might suffice, especially when behind a reverse proxy. Yet of all three, Webrick is especially slow, and php-s is especially memory-leaking and unstable.
If I had to take a guess, with PHP there's never been an opinionated nerd yelling at you that you're not smart enough to do it.
Just web-hosts and instant gratification.
Just web-hosts and instant gratification.
Note the original source of the screenshot was posted to Hacker News a few days ago: https://news.ycombinator.com/item?id=6919216
It has since spread like wildfire. This appears to be simple blogspam (tumblrspam?) of that.
It has since spread like wildfire. This appears to be simple blogspam (tumblrspam?) of that.
1. Write a blog post about how horrible PHP is.
2. Instant up-voting on HN. Yay traffic!
3. Profit!
Full credit to the underpants gnomes: I couldn't have done it without you guys.
2. Instant up-voting on HN. Yay traffic!
3. Profit!
Full credit to the underpants gnomes: I couldn't have done it without you guys.
And while PHP has been screaming to its community to "CHECK ALL INPUTS SDGY&F⁴8943%#$%#"
and then we have the Ruby guys coming along, butthumping Rails and mass assignment fests.
Name a perfect language/framework?
and then we have the Ruby guys coming along, butthumping Rails and mass assignment fests.
Name a perfect language/framework?
I find the inconsistency of the ordering of parameters in core PHP functions to be more frustrating than the names of them.
Either way, I guess I have to agree that people are spending a lot more time than necessary referencing php.net.
But then again, no need for all the anger and rage. There are a lot of things in the World much worse than PHP. There are things that are horribly wrong and yet still ubiquitous. Go fight racism, not web programming languages.
Either way, I guess I have to agree that people are spending a lot more time than necessary referencing php.net.
But then again, no need for all the anger and rage. There are a lot of things in the World much worse than PHP. There are things that are horribly wrong and yet still ubiquitous. Go fight racism, not web programming languages.
https://twitter.com/rasmus/status/413669330216185856
No such thing as bad publicity?
No such thing as bad publicity?