Ewww, You Use PHP? [2010]
blog.mailchimp.com
blog.mailchimp.com
Sadly, a lot of incompetent developers email each other articles like this, as fodder for dev team language flamewars. This quoted sentence is likely hyperbole, but they take it seriously and strawman people.
(Naturally, language evaluation is multidimensional. You consider alternatives, foresee tradeoffs, etc. PHP can be right/wrong in your situation.)
I knew programmers (and their CTO) who trotted out such articles to defend the broken PHP framework which they used to run half the business. I'm sure the framework's own authors would be aghast they still used it. The team working on it had near-zero productivity; virtually all spent maintaining the beast. New hires were flabbergasted at how slow the webapp was, which harmed the productivity of most in the company. One maintainer had a private project to incrementally rewrite the shit in another (very popular) language; the CTO indulged him but refused to support it.
(Mercifully, the company got put out of its misery. People might counter that the PHP codebase didn't kill the company. But of course that's not how it works. Incompetence suffuses many such decisions; each of which is just a facet of the same incompetence. And each incompetent decision reinforces the others.)
With the exception of JavaScript which is also "wrong" by many puritan developers opinion, PHP is the only language that is welcome to complete novice programmers. All other languages require a lot of setting up.
Furthermore the ease at which I can combine JavaScript with CSS with HTML with PHP is one of the major reasons it ever got so popular. No other language allow me to do that.
However as far as professional development concerned, I'd be very concerned about being hobbled by sticking with PHP over the long term.
First, because it doesn't have any strong ideas to explore as a language, it just cobbles together ideas from other languages in a very ad-hoc and half-baked manner. If you want to learn the power of first-class functions with closures for instance, those things exist in PHP, but the syntax is so baroque that you'd be excused for thinking they're not worth the trouble.
This effect is compounded by the fact that the PHP community is an archipelago of experts in a sea of beginners. If you're a newbie coming in it's relatively hard to figure out who to listen to to advance your skills.
Finally, there's the external signaling aspect. Although it's unfair, the hard truth is that software developer talent is the classic market for lemons. Most people evaluating you will not have the knowledge and experience to evaluate your skills objectively (heck, I'm a hiring tech lead and even I can't really tell until I actually start working with someone). For a lot of people, the language you use is the signal they use, and in this regard PHP is at the bottom of the food chain just about HTML/CSS.
Cause for me it was the ease of use. I am nowhere near a programmer let alone good at programming but I can solve most of my problems with a combination of PHP, JS and CSS/HTML why should i develop in another language that takes me longer time to setup?
Edit: Why the downvote? If you want to have people start learning "better" languages then it's up to you to find ways to get them to try it out.
Install linqpad, start writing code.
Install intellij/pycharm/rubymine. Click new project. Start writing code.
Having fun whilst you work also matters. Duct-taping doesn't sound conducive to a good time to me. I want to build, innovate and enjoy.
Secondly, by going with PHP you're exposing yourself to many built-in issues: http://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/
They obviously does not hinder you from creating successful companies and that is frankly all I care about.
Ruby, Node.js/Javascript, Python are all excellent, mature languages with huge pools of good developers (at least in London). They simply lack the ease of bootstrapping (as you pointed out).
If you mean by "the ease of combining Javascript with CSS with HTML" is that you get a mediocre, unsafe templating system out of the box, sure. All mainstream languages have various third-party templating libraries which are usually far superior to PHP. The big advantage to PHP is its omnipresence, large standard library and ease of deployment. It remains, however, an awful, warty language which makes it easier to do the wrong thing than most other languages I know.
The limits of the language means nothing to 95% of it's users and even when they do as in the case of facebook it's a problem of success and has been solved.
Lets not make it harder than it is.
Sure. Either your hosting provider supports your language of choice out of the box, or it doesn't. If it does, deployment will be simple. If it doesn't you still need to configure a web server and install whatever package you need (for comparison, here is how you configure Apache for the Flask Python framewrok [1], I don't see how that's significantly harder than configuring Apache for PHP).
> The limits of the language means nothing to 95% of it's users and even when they do as in the case of facebook it's a problem of success and has been solved.
Well, "Bobby tables" and XSS don't mean anything to a lot of people. It doesn't mean that PHP has acquired a sane templating system out of the box, that it's stdlib has acquired consistency or that it suddenly got hold of a type system. PHP is widely supported by hosting providers, and it does make it easy for inexperienced people to use it. That's, IMHO, its real strong point. Apart from that, it doesn't do anything better than other mainstream dynamic languages, and it does a lot of things considerably worse.
Including PHP, of course.
Although PHP does offer the option of using the "PHP framework", which the other languages don't, so, yes, when used in one particularly bad way, PHP is particularly unsafe.
Perl would like to have a word with you :)
One thing that is often overlooked with PHP is the fact that the deployment process if extremely easy, even for novice programmers. Simply use FTP/SFTP/SCP/whatever to copy over your files to a server, reload your browser, done. It's completely optimised for the scenario where you simply want to create a webpage.
Compare that to something like Python, which is very 'novice-friendly' as well, but needs quite some steps before you have a working website deployed on a server.
That really isn't on the same level as "ftp index.php to shared webhosting provider" for most people and that's exactly the point the parent comment is trying to make.
"It's completely optimised for the scenario where you simply want to create a webpage." [for a novice programmer]
I recommend you read over the parent comment again: https://news.ycombinator.com/item?id=8709025
You probably shouldn't do it that way, but that's one way it could be done.
This should only matter if you are making something trivial, like making a contact form for an otherwise static site..
No matter what the language in question, that approach is why we read on HN about so many scaling failures, security breaches, and startups imploding upon success.
Just getting something "shipped" is never the same thing as "done". The latter requires polish, which can be applied in any language, but it takes time.
In total, I think people should give PHP another try. It's worth it.
(cue the torchs and forks)
I do disagree with that statement "Ain't nobody got time for that." If you are going to spend 3months working on something, it's worth learning to use a new tool that is best for the job.
Also, as we are talking about web development, what is best tools? ASP.NET? Rails? Django? Go? J2EE?
PHP will cease to be gross when it's not just the large implementations that are very nicely done. This is not the PHP that exists in the vast seas between these islands. PHP is not something that a rotational employee or someone who is career-conscious will choose or accept for long. They want to work at your company for a while. This can be good. PHP is a career limiter in a way and I think the cringe reaction is a natural tendency to want to open up the conversation to see if what could be a good rotational job is also a toolchain dead end. Career conscious programmers don't want dead ends.
The gripe is and always will be that PHP encourages bad practices because it includes a bunch of "features" that are undeniably prone to bad habits. It's not personal. Really, we don't want companies using PHP well to die. We don't want the programmers using PHP to go away. We want PHP to stay put because better tools are out there, and anything that perpetuates the use of PHP in new products feels gross. It feels especially gross to the career-conscious young ones. Sorry.
However I seem to have swapped that inconsistent, badly designed language with Javascript.
Why go with PHP and have to roll your own framework, when you can go with something else, and leverage all the great work that has been done by the Django/Rails/whatever folks? This post tells me all that they have accomplished, which is cool, but doesn't tell the most important thing: why did they choose PHP?
I have to take missions in PHP (Symfony2 and Zend Framework) from time to time, and it really makes me appreciate how much more advanced Rails is. And I don't mean advanced as giving me lots of options for doing obscure things. I mean advanced as doing for me all the repetitive stuff that I would have to do anyway, so that I have much less code to write, much less room to introduce bugs, and I can focus on what really matters. The PHP ecosystem is trying to replicate that, but so far, it's still quite far behind.
First is ease of finding developers. This may not be so true now, but the post is from four years ago.
Second, and this may be more important: when initial prototyping the original developer is most fluent in PHP, thus he/she hack away first version in PHP. Thus this make the system PHP-based.
Personally, while I know the goods and awesome features of Rails, Django, etc. my most fluent language is still PHP (from using it years ago). If I happen to have some awesome idea to implement fast, I would still do it in PHP.
To be fair, no one has to roll their own framework in PHP, it has frameworks aplenty. I don't know why anyone would do that.
I've since replaced it with my own "framework" which is mostly a very thin wrapper for several really good packages (router, DI container, events dispatcher and query builder wrapper).
I'm getting 10x performance out of it than I was with Laravel, and overall it's a very small codebase which is easy to understand and test.
So yes, no one "has to roll their own framework in PHP", but there sure are advantages to do so if you know exactly what you need and how to get there.
Of course, you could say that about every language, and many do[0].
Faster than Node.js + Express?
> It has enabled millions of people to become web developers.
Factually (probably) correct, but irrelevant to the quality of the language itself. Bit of a pointless argument, as it wasn't the crappiness of PHP that made it popular; it was just the only accessible platform around and happened to be crappy.
> It powers about 90% of the web
Appeal to popularity, not a valid argument. Says nothing about language quality.
Absolutely, yes. Take a newbie and ask them to create a web page using express, then ask them to try in PHP. They are worlds apart in terms of usability and approachability. (I say this as someone who almost exclusively writes in node these days)
> it was just the only accessible platform around and happened to be crappy.
How can it be crappy if it's the only accessible platform around? An alternative view point is that PHP is the best, most empowering platform, because it's accessible to newcomers, and every other language is crappy in comparison because they have failed to match PHP's accessibility.
> Appeal to popularity, not a valid argument. Says nothing about language quality.
You seem to be talking about PHP the language. There is no doubt that PHP the language is flawed. That is totally irrelevant. What matters is how effective PHP the ecosystem is, and it is undeniably incredibly effective. That's why people use it, because it is a practical way to get things done.
So, if we're talking about PHP the ecosystem, then popularity is absolutely a valid metric here. It's easy to hire for, has tons of libraries etc, this stuff matters a lot more than the associativity of the ternary operator.
Thats not at all what people are saying.
It's a great company; super offices, wonderful people and a sustainable, profitable business. If I wasn't in England, I would consider pushing hard to try and become a part of what they're doing.
As it's often the first web development language picked up by people, who may not necessarily know what they're doing, it gets a bad reputation. Used correctly, however, it can be just as powerful as any other web development language.
That's a disputable statement (as I mentioned elsewhere, take long-running processes as an example), and even if it were true, that doesn't make it the correct tool to use. You can hammer in nails with a wrench as well, but you should still probably be using a real hammer.
[0]https://secure.flickr.com/photos/raindrift/sets/721576294929... [1]http://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/#a...
Virtually every language commonly used for web development (Python, Node.js, Perl, Ruby, Lua, ...) has equivalent or better tools. This is in no way exclusive to PHP.
In all this time there has been a huge change in the PHP world
TBH if a "developer" cringes their nose at a very capable tool, just because it is not the latest "cool" thing, It tells me a lot about them.
See, the thing is, PHP has gotten better. That's not in dispute. The problem is that, even after it "has gotten better", it's still far behind most other options that are commonly in use, and still highly inconsistent and upredictable. It is rather telling in and of itself when you have to use "well, it has gotten better" as a crutch to argue that, at least, it meets a minimum standard of viability.
Frameworks don't really solve this problem. Fundamentally, you're still working with a language that does some really weird things - things that are weird enough to cause near-untraceable bugs and completely unexpected vulnerabilities. You can slap a lot of abstraction onto it, and it does make it less unwieldy, but in the end you're still limited by what the language or platform has to offer you in terms of inherent consistency, predictability, and debuggability.
Just take, for example, PHP's CGI-like nature. Yes, it is theoretically possible to have a long-running process, and it's theoretically possible to implement real-time services with it, but it's going to be a major headache and incredibly hard to maintain. The tools are just not really there. Any solution you come up with will, in the end, be a giant hack.
Don't assume that somebody who cringes at PHP is just somebody who likes jumping on bandwagons. There are very real and rational reasons to dislike PHP, even (especially!) as an experienced PHP developer.
Not like the exemplary attitude of "awesome lets cut our wrists all day and open windows explorer to deploy"
What happens when you have existing code in Java or python that does something you do not wish to reinvent the wheel with is you simply interface/bridge with from you PHP code.
Right now I have 5 servers running python batch jobs processing some data (for a few months now) which is called by php with results being added to datastore for later access with php
In the past I worked on an asset tracking system where we collected data from RFID readers, whole system was done in PHP with some glue Java and C code for more "to the bone" edge cases
Everything I have done in PHP i could have done in C which I first learned and still use alot of, doesn't mean I want to spend my life wasting it on 90% of cases where a quick php script does the job within reasonable time
I never claimed PHP is "awesome" or whatever you think I did, but it is a very capable language at getting things done fast, especially if you know what you are doing
Yes there are armies of noobs giving PHP a bad name, but instead of turning your nose at them one is better helping them and showing them how to do things better
The horrid (and unfixable) nature of the language does not become apparent until after you use it for a while. (How long it takes may vary, but you ll hit it eventually, if you keep yourself in good company.). So if you list features of PHP, you might get a list of nice features. But every one of them will be subtly broken when put to real use...
mtgox? :)
>TBH if a "developer" cringes their nose at a very capable tool, just because it is not the latest "cool" thing, It tells me a lot about them.
This is called the straw man fallacy. You wrongly assume that the lack of coolness is why people dislike PHP and you dismiss the whole argument based on that.
Doing great stuff with PHP is like building a skyscraper using nothing but a hammer and a screwdriver and a few rotten planks. It's the builder who's amazing (albeit a bit crazy), not the hammer, the screwdriver or the planks. Imagine what he might've made with proper equipment?
Would you like to live in such a skyscraper?
What PHP is for me, is a paper cup. It's modest, utilitarian, not cool or elegant, but definitely efficient, useful and ubiquitous.
Talk about a backhanded compliment :)
ROFL :D (no tho in hindsight robbing half a billion and getting away with it doesnt seem like bad career path)
Stop being lazy and unprofessional and spend a month or two learning one of the many better commonly used web dev languages.
[1] http://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/
http://www.reddit.com/r/lolphp/comments/2md8c0/new_safe_cast...
Such as?
- "(int)" being a single token in the language
- not being able to call "array()" as a function is bad, apparently (which is the equivalent of wanting to use "return" as a function in C)
- "Most error handling is in the form of printing a line to a server log nobody reads and carrying on." - Bullshit. We send errors to Sentry or via e-mail. In some projects we feed them to a database.
- "E_STRICT is a thing, but it doesn’t seem to actually prevent much and there’s no documentation on what it actually does." - Bullshit. It's a warning, not a magic fix, so what should it do except warn you?
- "Function arguments can have “type hints”, which are basically just static typing. But you can’t require that an argument be an int or string or object or other “core” type, even though every builtin function uses this kind of typing, probably because int is not a thing in PHP." - Yeah, read the RFCs concerning type hints to understand the issues why PHP does not have them [yet].
- "No named arguments to functions. Actually explicitly rejected by the devs because it “makes for messier code”." - "And so I list it as a fundamental flaw in the language because it's not Python."
- "new, private, public, protected, static, etc. Trying to win over Java developers?" - Oh sorry, PHP devs will stop adopting good coding pratices in the next releases. Back to var everyone!
- "Subclasses cannot override private methods." - Yeah, that's why they are called PRIVATE.
- "There are no constructors or destructors. __construct is an initializer, like Python’s __init__. There is no method you can call on a class to allocate memory and create an object." - Yeah, because IT'S FRICKIN' PHP and you should not fiddle with memory. Go write C if you want to deal with malloc.
- "Static variables inside instance methods are global; they share the same value across all instances of the class." - Yeah, that's why they are static. If you want instance-bound variables, use class members.
- "As namespaces are a recent feature, the standard library isn’t broken up at all. There are thousands of functions in the global namespace." - "How dare the PHP devs not break compat with every piece of code ever written when they introduced namespaces? They should have just converted everything to C#!"
- "How do you sort backwards? In PHP, there’s a separate function called rsort()." - Fuck, those PHP dev assholes. How dare they include a shortcut. It's almost as if they just wanted to make simple things simple. PHP should require the developer to implement 20 interfaces to compare two numbers!
- "preg_replace with the /e (eval) flag will do a string replace of the matches into the replacement string, then eval it." - Failure to mention that this behaviour is deprecated for ages now (dunno, has it been removed in 5.6?)
- mentioning classkit as a way to "actually be dynamic in PHP". Yeah sure, without classkit there is NO dynamic feature in PHP, none at all.
- "There is no exponentiation operator, only the pow function." - Wrong, there is now.
- "No Unicode support. Only ASCII will work reliably, really. There’s the mbstring extension, mentioned above, but it kinda blows." - Yeah, no website with Unicode support has ever been built with PHP. Sure. Don't ask me how I manage to handle Unicode with mbstring just fine, I must be a magician.
- "Similarly baffling, arrays stringify to Array with an E_NOTICE." - What else would you like? A JSON representation? A simple comma seperated list? I can guarantee you, whatever you choose, someone will find it bad for their purpose. That's why we consider plainly converting an array to a string a MISTAKE (aka bug).
- "var_dump(strstr) issues a warning and assumes you mean the literal string, "strstr"" - aka "PHP is not JavaScript, so it's bad."
- "There are no generators. (Fixed in 5.5. Wow. They basically cloned the entire Python generator API.)" - Dafuq do you want? For some things, Python is the best thing in the world and everyone should copy it, but when PHP does, it's also bad, because, ya know, PHP.
- "PHP is naturally tied to Apache. Running it separately, or with any other webserver, requires just as much mucking around (possibly more) as deploying any other language." - Welcome to 2014, dickhead. I never heard our admins complain about using PHP-FPM with nginx. And using PHP separately couldn't be simpler: ``php myscript.php``.
- "Similarly, there is no easy way to “insulate” a PHP application and its dependencies from the rest of a system." - This guy has seen too many PEAR-based projects.
- "Configuration files and other “partials” need C-like guards to prevent them from being loaded directly." - a) put the file somewhere outside the docroot; b) configure your webserver to not spew out static files; c) use plain PHP files for config files; d) deny access to config files via .htaccess
- "No XSS filter. No, “remember to use htmlspecialchars” is not an XSS filter." - I beg to differ.
- "No CSRF protection. You get to do it yourself." - Fuck, you have to implement application logic yourself. Damn.
- "No authentication or authorization." - sigh really?
- "No routing. Your website looks exactly like your filesystem. Many developers have been tricked into thinking mod_rewrite (and .htaccess in general) is an acceptable substitute." - And in fact, it is.
- No coherent deployment mechanism; only “copy all these files to the server” -- Yeah, this is truly the worst. Just uploading files is waaaaay not enterprisy enough. Without OpsWorks, Chef and fourteen admins, you can't even call a PHP deployment a "real deployment". Things should be complicated. When uploading new code, PHP should force you to pester the admin to restart Apache!
- "The original built-in MySQL bindings, still widely-used, have no way to create prepared statements." - Yeah, because that wasn't a thing back when ext-mysql was written. That's why we moved to mysqli/PDO YEARS ago.
-----
But hey, it's logical to not remove fixed issues from the list. The point of the list is not to detail the actual flaws, but to just shit on PHP. It's like me shitting on the first alpha of Python or how much Linux 0.0.1 sucked.
Also, you will note that I left out quite a few points that the author brought up. And that's because they are valid points of criticism about PHP. I'm not denying that. But if you shit on PHP, get your shit together first and don't assume all PHP is like a guestbook script from 2003.
The purpose of a programming language is not to allow you to write beautiful code but to produce things. Everything else is a pseudo debate that is necessary at times but not as much as some would like.
I doubt you could convince a developer to condense their opinion of PHP to "PHP isn't the latest cool thing, so I don't like it." As such, I posit you're being as judgmental and dismissive as your supposed adversary.
Can we have less of these sort of articles please, it was a waste of my time skimming it.