PHP: A fractal of bad design
me.veekun.com
me.veekun.com
I'm a Facebook engineer who works on the HipHop compiler and HipHop virtual machine. It's in PHP, absolutely full stop.
It's amazing how much the fact that g++ is involved somewhere in the toolchain confuses people in this matter. C++ is just an intermediate representation; the source language really is warts-and-all PHP.
From the free dictionary:
poetic license n. The liberty taken by an artist or a writer in deviating from conventional form or fact to achieve a desired effect.
IIRC Facebook engineers must use HipHop for all their development, with PHP.net's php being now incompatible (hence the push to speed up the interpreter.) Wouldn't that make the language-supported-by-HipHop a PHP flavoured superset at the very least?
In the absence of a standard, saying what is and is not PHP is necessarily a practical matter: useful PHP implementations are those that run non-trivial PHP applications. HipHop qualifies.
FB's dependence on HipHop is because of backwards-compatible extensions to the language (like yield, e.g.). These extensions don't prevent HipHop from running normal PHP programs, though our use of them does prevent us from using Zend. The extensions are under flags that default off, if you don't want to use them.
Or a compiler at run-time.
eval does have one huge, honking problem though: it permits text to be interpreted as code. This is just asking for code injection attacks.
If you really need incremental/multi-stage evaluation, see MetaOCaml (http://www.metaocaml.org/) for the proper way to do it (without exposing yourself to injection vulnerabilities). It's a consequence of PHP's by-the-seat-of-your-pants approach to language design that the PHP devs settled for eval instead.
User input of code. It's hard to implement a REPL without it. Even if you do implement without it there's still an "exec" implementation hiding in there somewhere.
Also, on rare occasions, it is actually an optimization when used carefully, like the Python nametuple example mentioned nearby.
I'm just answering your challenge. I totally agree that in general it's a bad idea and that's an unusual case. While for it to work properly it has to ship with the interpreter, if I were designing a language I would move it out of the global namespace at least, and require some sort of explicit module import with lots of dire warnings in the documentation.
The problem with using eval for a REPL is that you want an interpreter, but eval gives you unprincipled incremental compilation.
Javascript (and I'm sure other languages) is moving in the right direction with sandboxed evals, but those are very difficult to get right in an imperative language, where a lot of code relies on global state (e.g. the DOM). Purely functional languages solve this problem well by disallowing side-effects. Of course there remain the issue of unconstrained resource usage but this is much easier to solve.
I use this in my Python data processing scripts. That is, when I generate data, I generate it as Python literals, either lists or dictionaries. When I have to process it, minimal parsing needed, I just eval it into my code.
def parse_and_append(line, seq, str):
if str in line:
seq.append(eval(line[line.find(str) + len(str):]))
nums = []
mappings = {}
for line in data_file:
parse_and_append(line, nums, "nums: ")
parse_and_append(line, mappings, "mappings: ")
If you write code in Java, but compile it to native format (using gcj, for instance) instead of using the JVM, is it still Java? In doing so, you lose what is probably the language's biggest selling feature.
Or, perhaps less relevant now, but I remember the days where people would go on about how Ruby didn't support native threads. Except there were interpreters that did use native threads with the exact same Ruby code. Was Ruby code running under one of those other interpreters still a Ruby application?
PHP too comes with expectations about the environment, like how it integrates into the web server stack, which if not met, is it still PHP? I'm not really familiar with HipHop, but, for instance, if you have to compile your code before deployment, you're not meeting one very prominent expectation of PHP: The ability to edit the code in-place on the live server (best practices notwithstanding).
So, what does define a language? Is a language just the syntax? Standard library APIs? Standard library behaviour (see Ruby example)? Runtime environment? I'm not sure you will find a generally accepted answer.
But the lines got very much blurred by the rise of scripting languages, in which - typically - the language was defined by the implementation. So for a few years there, it really was difficult to tell whether this was Python or CPython.
Fortunately, nearly all the languages to which this applies matured and got new implementations. Rubyists often to refer to the C ruby implementation as MRI (Matz' ruby interpreter), and there are lots of different Ruby implementations now. Python went out of its way to document behaviour which was specific to CPython, and put a lot of weight behind Unladen Swallow and Pypy.
But your Java example is bonkers. Compiling Java to native is still Java, its just not JVM. Compiling clojure to JVM is just JVM. The language feature is not the language. In Java's case, the language is specified, the VM is specified, the bytecode is specified. There really should be no ambiguity at all there.
Most people without a proper CS background mix the language with the implementation.
A language is defined by:
- syntax
- semantics
- libraries
Everything above can be made available as:
- bytecode interpreter
- text parser based interpreter (like the earlier BASICs)
- compiler
- JIT
That is why it is absurd to discuss language A vs language B in regard to implementations, because any language can have all types of implementations.
It is always a matter of cost/benefit which type of implementation is used as default for a given language.
Well, you're the authority, but is that really a fair assessment? Has HipHop diverged from PHP enough to really still be considered PHP?
Of course, I'll trust what an actual engineer from Facebook is saying over some article that I can't even cite. Is this not the case?
> empowered amateur
PHP is a gateway drug to web development. And that's awesome.
With almost every other popular web development language I've heard of[1], there's this grey area between "my app works on my local machine" and "my app works on the server" that is really hard to grok as a beginner. There's a reason entire businesses are built on the idea of making this easy.
With PHP? You get an apache box with PHP, you put the files up, and you're done.
For a professional web developer? PHP is probably nuts. I've purposefully left out things like PHP frameworks, setting up a database, or doing any sort've advanced web development. And yes, it is possible to create a large, successful, stable web app with PHP. It seems kind've hard given the legitimate criticism in the article.
But, honestly? Once you've started doing web development, you should be able to improve your own skills without the community pushing you. It's the people who are just starting out who need all the help they can get.
[1] Which isn't at all exhaustive. I'd love to hear about alternatives that are beginner-friendly.
Unsurprisingly, most PHP applications end up in this state. Cf. http://web.nvd.nist.gov/view/vuln/search-results?query=phpbb... - and phpbb is one of the popular ones with an active community...
The current state of information security: basically, we're screwed.
Also, if you've reached the point where PDO is too restrictive for what you want to do, you should be knowledgeable enough to write your own db class that incorporates sql injection protection (since all that largely consists of is escaping strings).
http://www.google.com/search?q=php+mysql
Searching for PHP and MySQL yields tons of tutorials, code examples, and documentation related to the now-deprecated mysql interface. When I wrote my first comprehensive PHP application last year I spent half a day trying to determine best practices before finally settling on PDO. Newbies won't go through that effort, and will naively land on mysql rather than PDO or mysqli as likely as not.
PHP has been around forever and Google has a long memory. Unfortunately, for every good blog post/tutorial on PHP development there are 100 or more bad or out of date ones.
The problem comes in when people don't quickly figure out that the language that they started out in should not remain their primary language for any serious project.
As was pointed out by djmdjm below, there are Real Consequences when amateur hour overflows into the real world. In many cases it simply would be better had many of these apps not been made by the unskilled - even if that means they hadn't been made at all.
What's so wrong about a barrier to entry that is effective against those who have not yet figured out what the fuck they are doing? We learned despite such barriers, did we not?
But most of the world will tell you where to stick that certification and will cheerfully walk around your "barrier to entry". Then they will hack together a web page using whatever programmers and tools they can find, certified or not, because web pages are very important in the twenty-first century and even the lousiest, slowest, buggiest PHP site is often more valuable than a paper sign stuck on the wall, an entry in the Yellow Pages that nobody reads anymore, a bunch of people sending individual text messages to friends-of-friends, or a static web page from 1997 with a little animated GIF on it.
I wonder what the costs of, say, the Gawker password database breach were? Or perhaps the Sony DRM rootkit on CDs? (Or Apples unpatched Java bug?)
What if the people who wrote and/or deployed the code knew (before they shipped/installed it) that they were going to be held responsible for the costs of any future failures? My guess is we'd then have training and certification and insurance, and professional organisations rising up to certify people as being skilled enough to qualify for insurance for themselves and/or their companies. Much like "Engineers" (who's titles the software industry loves to assume) or "Pilots".
I can torture the "Pilots" analogy further - much like you can do very little training to get a car license, perhaps you'd be allowed to write software that affects only a few people at once, your family and friends, perhaps a colleague or two, even occasionally a stranger, but never more than 6 or 7 other people at once. If you want to store data for more than 6 or 7 people, you need a different class of license - a mini bus license for a dozen or two, then a full bus license, then a train or passenger jet license...
Who _should_ be held responsible for a website's password database getting compromised? At what stage in the progression from "shared GoDaddy hosted out-of-date-wordpress blog about my cat" to "Gawker network with a million or so login credentials inadequately secured" do we draw the line and say "Here is the line in the sand across which more care needs to be taken, and lines of responsibility drawn up and accepted"?
'Cause _surely_ there _should_ be that line somewhere, right?
We are not good at this.
Also, PHP is not helpful in local development. I think there's a built-in runserver in the newest versions, but for all of history, to develop PHP you had to install (and set up) apache and all your required modules locally.
With python and Django, I use virtualenv+pip to get a consistent environment, manage.py runserver to test locally. I can pretty much start developing everywhere (my desktop, my VPS, my laptop, that same laptop after I reformat it and install some new distro to test) with 3 commands.
Only later did I install a local dev (now made very easy with MAMP), learn about version control, PEAR etc.
Something like, e.g., Heroku is awesome, yes, but not only do you need to learn how to debug a thing which you can't really touch in production, not only do you have to master the distinction between "the file I just edited here" and "the file on the remote machine"… but you have to use Git for that. I love Git, but years of watching PHP devs try to figure out Git have taught me just how intuitive it isn't.
Although PHP suffers from this, I'm not sure it is alone. I suffer a lot of pain setting up Ruby environments (I don't think I've ever managed it the same way twice) and getting everything to play nice. Even Python, a language I am about as familiar with as PHP, has it's annoyances on this front.
I suspect the difference is familiarity; I can deploy a working PHP environment in my sleep, because I've done it so many times.
The other day I had to set up Java/Tomcat - literally the worst experience of my life...
Also, PHP is not helpful in local development. I think there's a built-in runserver in the newest versions, but for all of history, to develop PHP you had to install (and set up) apache and all your required modules locally.
You're thinking like a seasoned pro :) For a newbie there is xampp - a familiar looking windows installer configures the Apache/PHP/MySQL (and others) stack, then it disappears into the backround and, largely, can be forgotten.
This is huge for a new developer.
Think about it this way; if you had a class called "Learn to Write Websites", for absolute beginners, I argue PHP is a good initial choice. Because you don't have to worry about the environment, how to server it, command line, package management - which, say, Ruby would require. You just chuck in a brief overview of how servers work in general, and then get them working on some PHP scripts, with instant results.
I love this!
I like Ruby, of course - it's powerful, has modern standards, and Rails is brilliant. But for a beginner, and even moderate, developer it is a bit of a pain to work with.
With python and Django, I use virtualenv+pip to get a consistent environment, manage.py runserver to test locally. I can pretty much start developing everywhere (my desktop, my VPS, my laptop, that same laptop after I reformat it and install some new distro to test) with 3 commands.
This sort of thing (http://pypi.python.org/pypi/virtualenv) is non-trivial for a beginner.
I'm not trying to defend PHP too much here; I like it, but it is a horrible language on many levels (as are other languages).
It also just works, especially for beginners.
I'd consider myself a seasoned PHP dev and it always takes me a few hours to figure out what happened when I get the white screen of death.
XAMPP isn't any sort of solution to this, because not all servers are configured in the same way that XAMPP is (and the fact that they compile in most packages doesn't help).
Developers at a local makerspace did a project last year using PHP, and even though there were tons of very smart guys, mostly everybody we brought onto the project took a whole afternoon to get set up. To me that's unacceptable.
Understanding how to set up virtualenv isn't trivial for a beginner, but that doesn't stop a beginner from jumping into my python projects with no pain. All they need is to get easy_install (which is included in all distros I've seen) and do a git/hg pull (both probably also available from distro). The rest can be handled by a shell script in the repo that grabs pip+virtualenvwrapper, sets up the virtualenv and installs all the required packages. Then you tell them "if you need to work on this project, just type `workon projectname`", and with that they're ready to start hacking.
That's precisely my point! :)
and even though there were tons of very smart guys, mostly everybody we brought onto the project took a whole afternoon to get set up. To me that's unacceptable.
As mentioned, I can rattle out a PHP environment in minimal time (basically as long as it takes for the installers to run). But task me to work on a Python project, or Rails, it will take a lot longer.
I think my larger point was that for an absolute beginner PHP offers some key advantages over other languages (even you simple description of jumping into Python involves some major pain points - like using Linux, the command line, package management, what is git/hg?).
The advantage to PHP is purely that it is intended as a web language; Python, Ruby et al require additional steps to get to that stage (or, at least, steps that are not braindead-automated for beginners).
I started writing a long rant which essentially boiled down to exactly that - PHP may be shit, but so is everything else. I hate all the languages that we're stuck with, and every time I start a project it's more a matter of picking the least shittily inadequate tool for the job than a matter of picking a language that I actually like, because there are none. They quite seriously all suck, very badly in most cases. The pain comes in different places, in varying degrees, but it's always there, whether it's coding pain, tools pain, ops pain, installation pain, documentation pain, etc. I have yet to find a development stack that didn't make me want to scream "fuck!" at least a dozen times over the course of a week of using it.
The real problem with most non-PHP stacks is that they front-load that pain: I have to say "fuck!" and hit Google many more times before I see a page generated from Ruby, Python, Scala, C, Java, or Haskell running on my webserver than I do to see a dynamic PHP page. Is it any surprise people tend to go with PHP pretty often, given that?
I think detractors would be wise to focus a little bit more about what's awesome about PHP, rather than what sucks about it (there's a lot, nobody argues otherwise). Because there's got to be plenty that's great about the language (or perhaps the environment overall) if it attracts people in such large numbers. We should be trying to add that to other languages/environments, not merely looking down on the newbs that still use PHP.
I worked at one place where our hardware guy who wanted the dev test and live systems to come from the same production batch from SUN just to make sure there where no strange MB rev problems.
Ok having identical hardware is high end but seting up a system where your running the same linux distribution an the same version of mysql php etc is not exactly rocket science.
While the beginner will love being able to open up an FTP client (probably one that's a browser extension) to upload a few files they've changed, that's not going to fly for us.
We want proper deployment, source control, and for it to be used properly. We don't want to go anywhere near patching code directly on the live server. Just make sure the fixes are committed, nothing's broken, and run the deployment script of choice.
The requirements for 'simplicity' are completely different. And it's for this reason I think Rails and Django* and the like become attractive prospects for developers who want a more reliable, consistent environment.
* I'd struggle to list a PHP framework here because each one has a different vision of what the 'PHP way' is, probably because there is no 'PHP way'.
Keep your source in a svn or git repo, export the new release branch or bug fix release to a testing box and once you're happy move it over to production. What does any of that have to do with PHP itself?
If you're talking about moving from one version of PHP to another, just compile the new version of php in a different directory from the old version (e.g. /var/lib/php/5.4 ), create a new virtual server definition in apache and point it to the newly compiled php version (e.g. using Apache's mod_fcgid) and test your site. Once you're happy, make that virtual server live to the public and retire the older one.
Even those that do run their own server many linux installations have options to install the AMP part of LAMP by default. Again, nothing to do
Why? For PHP I sign up for one of the million LAMP ISPs, I upload a .php file with .php embedded in HTML and I'm done.
Where's the Ruby version of this? The Python version? The JavaScript version? The Perl version? THEY DON'T EXIST. You wanna use Perl or Python. You either have to use slow slow cgi or you have to RUN YOUR OWN SERVER. (virtually or otherwise)
PHP sucks, I hate it. I don't code in it unless I absolutely have to. But it's not the language that makes it popular. It's the combination of pre-installed + no setup + plus faster than cgi + works on a shared host + inline templating that's made it popular.
mod_perl? mod_python? As far as I understand them they're not useful on shared web servers so they don't fit the niche PHP is filling. Node? Ruby? They are the server rather than a plugin for apache. Again, not filling the same niche.
Someone with some chutzpah needs to step up and bring the EXACT SAME COMBINATION OF FEATURES except with a different language to the Web. They can be rich writing books and running conferences.
--
Ok, now, I suspect most would want this to be in Python or Ruby but I'd argue if you really want it to succeed make it JavaScript. Because most PHP programmers have to learn JavaScript as well for their webpages. Less to learn = more likely to succeed.
But honestly, if anyone could get any of those languages to fill the niche PHP is providing it would be a huge boon over today.
heroku ? you don't even have to upload anything manually, a single command deploys your app.
With PHP, you have a file with a .php file suffix on your server.
That file has code in it. Navigate to that file on your browser. You have a dynamic website.
No installation of external programs is necessary. No terminal. Often, you don't even need an FTP client, since you can use your hosting provider's GUI.
That blinding level of simplicity gets the non-programmer started in under an hour.
To run Heroku (on a Mac), you need to download (1.8GB) and install XCode (or another version of GCC for Mac, but the moment you say GCC, the beginner's eyes glaze over). Once you install XCode, you need to open up terminal (no GUI). Then you install homebrew in order to install the dependencies that Heroku tools require (some JSON libs, if I recall). Once that's installed, you need to install the heroku cli tools. Now you can deploy your heroku app, which requires registering (or, in the case of beginners, generating) ssh keys.
Every single one of those steps is too difficult for the beginner. That is why PHP wins.
The reason you have trouble deploying Python is purely that the hosts you are trying to use CHOOSE not to support it.
You can get really excellent, easy $10/mo Python hosting but if you ask for 'free,' beggars can't be choosers, so you will get whatever they feel like giving you. This is not a function of the underlying technology.
Don't blame other languages if you have not ever figured out how to do anything other than PHP
Well this is why I guess php wins. Because the other communities have complete disregard for what the common newbie considers valuable.
The question is whether something matches php's economic model. If the answer is no, its no.
You can get the hosting for $x/mo is not an answer nor a solution for most people.
Any recommendations? I need one for a small biz (in the US), so this is a serious question. I would pay 2-3x that much for a "really excellent" platform I could build a business site on without having to be the entire sys admin.)
If you need more reliability than shared hosting can give you, then you either head into the VPS/IaaS/dedicated space (and need to do your own sys admin stuff), or you head into the GAE/Heroku/PaaS space (and need to pay a lot more).
There are always tradeoffs. :) (And no, I have no reason to recommend them other than being a happy customer. <shameless>...unless you want to use my affiliate link[2] to sign up, of course.</shameless>)
With PHP, you have to develop a coding style that naturally avoids PHP's weird areas. It's not really that hard to avoid the mines, but you do have to be aware of them.
In exchange, you get a scalable web server and a language that requires minimal babysitting. Instead of automatically throwing a 500 on a random, unimportant, uncaught exception, PHP makes a best effort, and most of the time the result is fine. 99% of the time, this is better behavior from a user's perspective as long as functioning perfectly isn't mission critical. It may feel offensive to your OCD programmer nature, but from a pragmatic engineer's standpoint, it's oftentimes a better choice, especially when dealing with the dirty data that's so common in webapps. Do not use PHP in a banking setting.
Compared to running a rails app, administering and scaling mod_php is pleasantly hassle-free. A single webserver with a modest amount of memory can handle an large number of concurrent PHP processes and requests without needing to resort to reverse proxies or anything more exotic than a simple apache install. That's nice not only for the ease of setup, but also because it means fewer moving parts, and less maintenance. That's a very real plus, and I'd say that the shared-nothing architecture of PHP was great engineering choice.
Yes, the language is weirdly architected and oftentimes inconsistent. It can also be extremely productive, and many of its weird choices are extremely pragmatic. The security holes are pretty horrifying, though - the defaults should be much more locked down, and I've always been a bit mystified that they're not.
And how precisely does PHP "know" which exceptions are important and which are not? In my experience of 6 years as a web developer, the faster and the more explicitly something fails the better. If the user gets a 500, that's a pretty clear sign of a problem, I get an email notification about it, including user id, session data etc. Then, in most cases, I can easily see what the problem was, decide what the correct behaviour is and create a fix immediately and even notify the user after releasing it if I wish to do it. If there is no exception there is a case in the code I was not aware of when writing it and it will still not be brought to my attention. In the best case, the user will report some problem with the functionality and I will have to spends hours trying to find the logs for this user and reproduce the problem, which will now be much harder, quite some time could have passed since the error, the database entries for the user could have change meanwhile (including corruption caused by the system continuing to operate despite an error) and so on. In the worst case, the bug will continue to affect users (which might not even know what the intended behaviour was) and I will learn about it a year from now, accidentally.
Reproducing bugs is hard enough in web applications due to their distributed nature, some of the applications I worked on had serious business-affecting bugs that went unnoticed for months and failure to clearly signal errors is one of the common cases. It doesn't matter whether you are in banking or just building another social CMS/CRM "kind of thing", if you have bugs you loose users and with them money.
See also: http://en.wikipedia.org/wiki/Fail-fast
If there's an issue that affects business logic I'd like my app to display "Sorry, something blew up. Please leave a message and we'll get back to you." instead of chugging along quietly. If the error is not critical (some external feed gone, whatever) _I_ as a developer can decide to catch the error and handle, log or even ignore it. But it's not PHP that can decide to do so.
I completely agree with most everything in this post, too. It can all be summarized in this sentence later down the page:
> PHP is a minefield.
You can measure a language's design by how often you shake your head at something. I've run in to pretty much every problem he outlines in the Operators section alone. Too often, a problem I'm having is due to a quirk in the language itself and not in my logic. Too often, I find myself needing to check the docs to see which order I need to supply arguments to core functions.
It's hard to imagine the pain of working in PHP without working in it. All those little things you take for granted in Python, Lisp, Ruby, etc. are gone. The only consistent thing about PHP is its inconsistence.
If you don't mind, I'd like to save this for future reference when someone tells me, "PHP isn't that bad." Yes, as others have said, it was beating a dead horse, but we shouldn't forget just how bad a language can be and still become wildly popular.
"I wrote PHP as a hammer to do my stuff. Around 1993, the only way to write web apps was by hacking C and Perl. This was extremely painful, and you would have to do the same thing over and over again. So I started writing a tool which would make my work easier."
"I never thought while writing PHP that someday millions of people will be looking over my shoulder into my code. If I would have known that, I would have surely done a few things differently. But nobody knows that. Some appreciate the language, some don't. I don't blame them."
"PHP is a hammer. Use it for the right purpose at right place. Learn Python, Ruby, Haskell, Scala, etc. every language and use them where they fit. No language is perfect. There are trade-offs involved in each of them."
"When anything is too popular, criticism naturally follows. When people compare a language which is used in, say, 35% of the web apps to a language which is used in, say, 5%, their comparison is highly skewed because then they directly compare the number of things that have gone wrong in one with respect to another. They don't scale them to the same level and then see the faults. I don't blame anyone for that."
"You can scale horizontally with PHP as much as you want. There are many companies doing that, and they have been very successful."
"I can teach a semi-intelligent monkey to code in PHP in three hours."
There were many other cool and brilliant things he pointed out. What I learnt: Accept what it is. If you don't like it for your purpose, use another language which fits in.
P.S. In the new release of PHP, there are even driven servers (libevent), Support Vector Machine (SVM), Traits, Instance Method Call, built-in web server for testing, improved error messages, broad performance improvements, and many others. This language is not going to go away soon.
“There are only two kinds of languages: the ones people complain about and the ones nobody uses.” ― Bjarne Stroustrup, The C++ Programming Language: Special Edition
I wish people spent as much time creating new things as they did bitching. As well written as this article is, it contains absolutely nothing that hasn't been said ten thousand times already- in fact, most of this seems to be regurgitated from those other articles rather than being actual original thought. Some of the issues brought up have been depreciated and removed a long time ago- too bad the author didn't limit his google search to the last year when looking for other people's examples to post.
This is not a language, where you expect intuitively on what method to call unless you do a StackOverFlow search on existing problems, raised by others like me.
Yet, I currently develop a web app on PHP. Certainly, I can't wait to move over to Ruby or other languages in my next project.
The author is stating the obvious. But he/she has every right to do so, because PHP is simply not user friendly enough to programmer. If PHP truly targets non-programmer, they totally succeed in their goal.
The point is the PHP circle jerk is getting old. I don't see the value in repeating the same discussions every day, and most of these posts just reek of exploitation- these authors know php bashing will get upvoted, so they write an article, submit it here, and wait for the traffic to pour into their otherwise unknown blog. I just think we'd all be better off if they actually wrote something useful.
Actually, I would state that, "a summary of the same posts we see here week after week," does indeed have value. Now you can bludgeon the next guy who posts a PHP rant with a link to this one.
Like I said, I wrote it to get this /out/ of my system; I am now impervious to PHP arguments. Either this will convince someone or it will not. Done.
Well done. Nice to get it out.
What I'm saying is disregard that guy.
2. It's symptomatic of a general "good enough" mentality that makes software development much more difficult than it needs to be.
3. It breeds bad habits in novice developers that are likely to be my colleagues one day.
4. It steals mindshare and time that might much better be spent improving better alternatives.
5. It provides LAMP detractors with ammunition to shoot at the entire open source web stack.
6. I may one day have a half-assed PHP mess dumped in my lap to clean up.
I was once talking to our Systems people about, why not allow Python applications. They said that every time they have experimented with allowing CGI scripts in any language supported by their Web servers, someone has always found a way to exploit their sandbox. With PHP, the applications can still get exploited, but they have never had a breach that affects the servers themselves.
So if you're a startup or a major tech company who can spend time customizing a Web server and trust everyone who has access to it, then you're crazy for using PHP. But if you're a college with 8,000 students, almost 1,000 faculty, and a bunch of support staff in addition, and a good quarter of them need Web sites, PHP's pretty much the only option that will keep you sane.
In my opinion, that's something that seriously needs fixing. But it's certainly an explanation for why PHP is still around now.
(I also haven't seen any Joomla installs.)
If I could get away with it, I'd never again trust my credit card number to a system based on PHP, but I suspect that that's about as easy as never trusting your credit card to an ATM/point-of-sale machine based on Windows.
Would you visit a dentist that used tools as bad as PHP? "Hey, it's not about the tools," they'd scream while you're running away.
I don't really have a choice. I can't afford to move (no, seriously, I can't), and there is no other work that I'm able to do.
I dislike PHP. I wish my boss would let me explore alternatives. :(
He just won't let me.
No offense, but you should really find the time to learn. That's not a hit against PHP (which I don't care much about one way or another; anything good enough for Facebook but full of such a large number of gotchas can obviously be read either way) and it's not even a comment about the marketability of your particular skill set.
Instead, it's just intended as a friendly reminder that you, not your boss, are in charge of your life. :)
It's not that I don't know how to do other things. It's that the things that I'm capable of doing put me in a narrow niche. With a long-standing back injury and medical problems resulting from exposure to chemical allergens, there's very little work I can do in the light industrial sector.
I have training as a carpenter (and I can do everything from foundation and framing to roofing and finishing - I have the training), but I'm no longer physically able to do it.
The list of programming environments I'm comfortable in is quite long, too. It's just that my choices are PHP, C#, and Ruby. And the PHP guys are the only ones hiring. I really should move to Seattle or something, but the cost of just getting there is a little over what I can do.
Sometimes we can't forget that it exists, so we try to educate people so that with a little luck, they won't pick PHP for their next project.
I've attempted to learn Ruby. I know C++/C#/Java/Objective C. Yet I still come back to PHP. I can't explain it. I like PHP. I understand PHP. There are nice people willing to help me with PHP. PHP does what I ask.
It's not the greatest. It's no MIT Graduate. But I like working with it. PHP works hard and fast, plus it's a little fun.
I feel there is more important stuff for me to do with my life than worry about the structure of a common language.
I don't know, if anyone can help me understand my attraction it would be most appreciated.
I've never done any sort of web development at all (no HTML, CSS, JavaScript, etc.), but I set up a local Django server to do stuff with, and I absolutely love it. I learned Pyton for web development, but I can really see it coming a part of my future projects.
You should give Ruby or Python a shot as an alternative. C# comes with all the .Net baggage, it's a whole different game, and Java is far too enterprise for someone living in PHP-land.
There are things that are stupidly easy to do in Ruby and Python that are virtually impossible to do in PHP, and these are things you do all the time. PHP's feeble list transformation routines, which are a fundamental operation in even Perl, are a huge problem.
If you think PHP is fun, you would love a well designed language.
PHP isn't sexy, hell, it might be classified as a backwater these days. Fact is, it is a simple language, it works, and a whole lot of useful tools are built on top of it. I've done many bad things with PHP, some I will admit to, some I won't. Hell, I built a bunch of authentication services and prototyped a storage backup system using PHP because it was the most mature language at the time (this was years ago, and mod_php was light years ahead of mod_python, ruby wasn't even in the discussion). It worked, the security issues were known, and we knew how to scale the system.
The first post on http://anodejs.org a couple of weeks ago was pretty amazing. The title "We work at Microsoft and we use node.js". That statement in itself was amazing (you wouldn't have seen that 5+ years ago), but the use of Javascript in a large company/large team environment is an interesting exercise. My experience is that a team of 4-6 people working in the Javascript/Node server side have to put tools in place to ensure code quality and consistency that was never needed in PHP.
Each language has it's strengths and weaknesses. In the case of PHP, it isn't sexy, it is pretty homely, but a lot of people are still getting a lot of stuff built using it.
If you look behind each one of the features you will find that they aren't 'design decisions' but rather a consequence of circumstance.
Most of what is being discussed in this post doesn't really matter because:
a) most PHP developers will never touch some of the smaller nuances
b) newer versions of PHP are changing things (and people still keep using older version. there was an entire holdout movement with version 4). this entire post could have been pulled from the PHP issue tracker.
c) super duper huge websites and web applications are being built with PHP
I don't consider myself a PHP developer, but the argument about it being useless in spite of all the evidence is just ridiculous.
Really, PHP is excellent for what it was originally designed for: little server-side scripts that do relatively simple things. I know that its authors would currently like it to be used for more than that, but, well, don't.
As long as you're not making a massive application, PHP's massively filled global scope, decent batteries-included approach, documentation-with-examples, and its support on virtually every web host (and then some) make it an excellent choice.
Therefore, I disagree with the author's notion that it's bad for everything. It's excellent for little scripts, which is was mr Lerdorf originally intended it to be for anyway.
I tried writing a little one-off Python thing in Flask last year and was actually surprised by how little effort it took. I spent more time learning Flask (and Flask is really, really simple) than I did actually deploying the thing to a VPS with spare cycles. It could stand to be slightly more turnkey, but running a tiny app server isn't nearly the nightmare it's made out to be.
…no template system. There’s PHP itself, but nothing that acts as a big interpolator rather than a program.
As if that was a bug and not a feature. PHP succeeds because there is one PHP templating syntax and it is called "PHP".
PHP started life as a templating language, and that's where its soul lies. Which is important, because if a non-programmer wants to start editing dynamic HTML pages, most likely the first thing they open in their text editor will be a template. And if a customer wants to change the website, but doesn't want to pay a highly-trained programmer (we're very expensive, especially because none of us really wants to be paid to edit templates all day), they'll hire someone who knows how to edit the theme. For every seasoned programmer in the world, there are half a dozen themers who know how to edit HTML and CSS, and maybe how to embed a "foreach" loop that calls a stock WordPress function, or edit an argument list, or swap one Drupal function name for another. And for every themer there's a dozen non-programmers who dream of knowing enough to be themers.
This class of user is what every other platform tends to neglect. Ruby and Python programmers tend to design tools that are intuitive to other programmers. We build "frameworks", where one must tinker and monkey-patch and fork to such a degree that only another programmer can download and assemble a working system, let alone customize it. (One word: Gemfiles.) We write programmer-centric documentation filled with jargon terms from Javaschool, like "object". (PHP themers often do not understand OO, and often don't need to. This, all by itself, could be why PHP is so popular.) But one leaves a lot of money on the table when one designs software systems exclusively for users whose programming education entitles them to six-figure salaries. There aren't enough such people on earth; that's why they earn six-figure salaries.
Designing the minimum viable product for borderline-non-programmers who want to tinker with dynamic web pages is hard work, though. PHP evolved into that niche, but if you don't start there it's hard to steer there deliberately. For me, trying to remember when object inheritance and version control and function definitions were mysterious is like trying to remember when I didn't understand algebra. (And, believe me, I really didn't understand, once. But I'll be damned if I can remember why not.) It's so hard to keep one's eye on that ball that even the PHP developers lost the plot long ago: PHP has long since bulked up with features borrowed from other languages. But if you ignore its newer features the soul of PHP is still a little templating language that you can edit into the HTML on your server; change a filename extension and reload and you're good to go. And, the thing is: You can write a crazy-complicated core system in PHP, but then expose it as an API at the template layer, and those tinkerers hacking at the HTML on their servers will be able to use it.
Is there something about consistent naming, or consistent behavior of different library functions, or consistent syntax and operators -- they can be lenient and type-coercing, but consistent, like Javascript's -- that would make it a worse language for people to wade into in the form of templated HTML? Of course not. That's what irritates people, the endless parade of bad design decisions that appear totally bad, with no upside, where they could have just as easily made a good decision and didn't.
But these irritations are only apparent once you're inside the PHP conversion funnel. And, as I have observed time and again as a pro PHP developer, once a PHP programmer knows ten lines worth of PHP it is easier for them to struggle through the eleventh line than to start over with another system.
The entrance to the funnel matters, a lot! Everyone passes through it, and the bulk of your user base will never even leave it. That's my theory of PHP's apparently inexplicable success. (It also explains a lot about every other platform's userbase, by the way.)
And it's not as if one can't master PHP to the point that one could build, say, Facebook: It's empirically evident that one can build Facebook, WordPress, and Drupal in PHP. And, though PHP eventually turns into one gotcha after another - almost immediately, actually; the array() semantics are an absolute horror show - at every single step of the PHP experience there are ten people stuck on that step along with you, and you're all being coaxed ahead live, on the internet by the ten people who are stuck one step above you. So it eventually works out, at least as well as any good hack does, and trying to pretend otherwise doesn't fool anyone. You can try to tell people that PHP can't possibly fly, like the scientists in the urban legend who allegedly tried to claim that the bumblebee can't fly, and they'll smile at you and go back to struggling with PHP.
The question implicit in your comment is: Could we design a system that offers the ease of accessibility of the first few steps of a PHP programmer's career but, as one climbs the learning curve, eventually blossoms into Python or Ruby or even Lisp? I wish I knew. My best guess as of this morning is that a demigod could design such a system, but it's very difficult for mortal humans to do so, because once you know how to program it's hard to avoid overdesigning, putting in things that will eventually be useful in year two but are discouraging in year zero. We make terrible pedagogical mistakes, like turning everything into an object. (Does your ORM seem intuitive to you? That is why PHP is beating your system in the marketplace.)
I contend that learning a proper language will be of greater benefit to a person just starting web-development, and putting in just a few extra hours at the beginning to get a solid foundation will in fact save them time in the long-run.
Also, giving complete amateurs this loaded, rusty .44 magnum and pointing them at the battlefield is bad for web security and the web in general, they will inevitably lose all the plaintext usernames and passwords they have in their database.
PHP is a blight on the web.
Now you have two options. One is to learn the entirety of automobile engineering before touching your car, second is to learn enough fix the problem for the moment. Needless to say any normal person will prefer the second approach.
Now some mechanical engineer may make an argument that this small quick fixes are harmful for long term mechanical engineering practices. But for the guy who does this quick fixes, none of this matters or is even relevant.
Also, the tires are likely to explode every 16 left turns unless you know about the secret tire fixing button under the dash.
It is true that PHP may save people a few hours in the beginning, but at what expense? How longer does it really take to get a noob running a Sinatra, web.py, dancer or something similar?
Some people doesn't want to learn web programming. They want to get things done. Think of PHP as an equivalent of Bootstrap on the server side. People don't use Bootstrap because it's beautiful but because they can't design and in fact don't need anything fancier.
There really needs to be a "good" version of PHP.
Given my past experience I was planning to use PHP as it is the only language I have any experience with and while the functionality I'm shooting for is totally different, I don't envision it being any more difficult to code than the blogging platform. I will be interacting with a database.
Are the other options as easy to pick up as PHP? Is it as easy to google for help?
Of course, that was my impression given my prior knowledge, which of course influenced my start with that environment. But i found it to be great almost instantly.
[set Greenspun Cynicism Level to MEDIUM HOT]
Other platforms wrap up SQL to the extent that you are encouraged to pretend it does not exist. This is an irreplaceable killer feature if you are trying to encourage new programmers to design things that will eventually prove difficult for them to optimize, or are trying to drum up membership in the NoSQL-silver-bullet-of-the-month club, but in the end what was good for 1996 is still pretty good for 2012: Pull the data from the database using classic SQL from the 1970s, loop through the result set, paste each row into the template, and ship it out to Apache.
PHP does this transparently, which makes it relatively easy to figure out what is going on. Of course, what is going on may be "the novice PHP programmer is staring directly at the SQL but still cannot optimize it", but hey, at least now you can see the problem.
[set Greenspun Cynicism Level to LOW]
For years I consoled myself by calling myself a "Drupal developer". I'm not a PHP developer; if I weren't using Drupal I wouldn't touch the language with a ten-foot pole.
But I agree that basic PHP is optimized for the style of web development that dates back to 1996: Server-side rendering of HTML templates. (More powerful PHP - the underpinnings of the PHP frameworks, the stuff one gets in the latest versions like objects and namespaces and closures - basically turns the language into the equivalent of every other scripting language, though obviously much more inconsistent; there's no great reason to choose any of that over Python or Ruby except that it degrades gracefully to PHP, which may actually be very important, but only so long as what you're building looks superficially like a server-side-rendered HTML template from 1996.)
One reason why I'm spilling 10,000 words on PHP is that I've been working with it for five years now, but I'm having trouble getting excited by its future. It has a long future, because 1996-style web sites are not going anywhere: WordPress.com has a zillion users and Drupal is taking over the enterprise and, well, Facebook. But one eventually gets tired of living in 1996. And PHP is useless for client-side-rendered "HTML 5" views, or mobile app client development, and its advantages as a templating language become moot if your server-side code is just an API coughing out JSON objects RESTfully. No newb can figure out that stuff today - even wizards can't agree on the proper semantics of REST, for example - and if ever we do develop a framework for designing RESTful APIs that's as easy for novice programmers to pick up as PHP is for 1996-style templating, I'm betting that framework won't be built in PHP.
But maybe I'm wrong. Hence, deep thought.
My experience running PHP cloud services suggests that, operationally, PHP is a dream. It's the least problematic layer of the LAMP stack, at least once you've learned what the words "APC cache" mean.
How are any of these not fit for building an MVP in 2012?
http://silex.sensiolabs.org/ http://twig.sensiolabs.org https://github.com/nrk/predis
There are also modern libraries for a plethora of other RDBMS and NoSQL systems (I think PHP is even going to support mongodb natively soon i.e. no third party client library required).
But PHP has either missing or NOTORIOUSLY inferior Memcached/Redis/Mongo/Cassandra/HBase/Riak/etc clients. They get the job done, but they underperform, say, Python or Java versions in benchmarks and introduce far more bugs and quirks than I've experienced in other languages.
This has actually been a positive thing, because when you're using these data stores/queues/etc at scale and you need bulletproof client libraries, you naturally are led to a SOA. You end up with Python/Erlang/Clojure/Java services that interact with the datastore, that you consume from PHP using Thrift et al.
But being so bad that it pushes you into building a better architecture is kinda a preverse benefit
Having said all of that, if you are building a site that uses NoSQL and needs to scale to millions of simultaneous hits you'd be insane not to develop it with SOA in mind. Using just PHP (or any other single language) wouldn't make sense.
But Memcached, certainly (and even doubly so for the `Memcache` extension that ill-informed developers install instead of the better `Memcached`), and the others listed, either are slower/etc or just don't exist.
Yes, you can enjoy these wonderful modern tools for PHP at home meanwhile you suffer with old-tier libraries at work because everyone refuses to move forward.
This article is garbage -- don't be taken by it.
I'm not going to argue that PHP is a great language, but this article is a complete disservice to anyone who has bothered to read it.
The "non-programmers" remark refers to a quote from the PHP 2.0 documentation. I tried to minimize the editorializing.
The latter doesn't need a fix because it always worked. Honestly, how hard is it to test that foo()->method() works?
> == is useless.
Actually, it's not useless. It does have a few stupid edge-cases and I will admit that. But in most common cases actually does the right thing and the truth table isn't too different from JavaScript.
> Objects compare as greater than anything else… except other objects, which they are neither less than nor greater than.
Strict-equals on objects compares the references; but regular equals compares the contents of the objects. Two objects compare equal if the contain exactly the same fields and values. Seems pretty reasonable to me.
> + is always addition, and . is always concatenation.
This is a good thing; JavaScript gets this wrong.
> There is no way to declare a variable. Variables that don’t exist are created with a null value when first used.
Variables that don't exist issue a notice. You can deal with that just like any other error.
> Global variables need a global declaration before they can be used.
Actually there is also the $GLOBALS array for this. I'll agree that's not much a solution. Globals should just not be used; if you want to use static class variables, it's a much better choice with a sane syntax.
> there’s no pass-by-object identity like in Python.
I'm not sure if I understand this but all objects are passed-by-reference in PHP (since 5) and PHP references act appropriately when used as function parameters, etc.
> A reference can be taken to a key that doesn’t exist within an undefined variable (which becomes an array). Using a non-existent array normally issues a notice, but this does not.
I just discovered this recently and it's a great feature. Obviously an attempt to use the reference will result in a notice but isset() and empty() operate it on it correctly. This can be very handy.
> Constants are defined by a function call taking a string; before that, they don’t exist.
You can declare constants in classes and namespaces with the const keyword.
> There’s an (array) operator for casting to array. Given that PHP has no other structure type, I don’t know why this exists.
You can cast scalars to single element arrays and objects to arrays with the same structure. Both are actually very useful.
> include() and friends are basically C’s #include: they dump another source file into yours. There is no module system, even for PHP code.
PHP is interpreted; I'm not sure what kind of module system you think it needs. Most projects don't use include() directly and instead have autoloaders.
> Appending to an array is done with $foo[] = $bar
You state this like it's a bad thing!
> empty($var) is so extremely not-a-function that anything but a variable,
Empty is equivalent to the not operator but will also work on undefined variables -- that's why it requires a variable.
> There’s redundant syntax for blocks: if (...): ... endif;, etc.
Useful inside of templates where matching { } is much more difficult.
> PHP’s one unique operator is @ (actually borrowed from DOS), which silences errors.
Yup. I find it very useful on the unlink() function which will raise an error if the file you're trying to delete doesn't exist.
> PHP errors don’t provide stack traces.
Not true. Debug_backtrace() will give you a stack trace in an error handler.
> Most error handling is in the form of printing a line to a server log nobody reads and carrying on.
Assuming, of course, the programmer doesn't do anything to handle errors. How is this different from any other language?
> E_STRICT is a thing, but it doesn’t seem to actually prevent much and there’s no documentation on what it actually does.
E_STRICT (or lack of it) is for compatibility with PHP4. When enabled it will "warn you about code usage which is deprecated or which may not be future-proof." -- quote from the manual.
> E_ALL includes all error categories—except E_STRICT.
Unfortunate naming here -- E_ALL is from PHP4 and prior and E_STRICT is all about PHP5. Including it in E_ALL would break PHP4 scripts running on PHP5.
> Weirdly inconsistent about what’s allowed and what isn’t.
Then you go on to be confused why syntax errors would be parse errors but logic errors are not.
> PHP errors and PHP exceptions are completely different beasts. They don’t seem to interact at all.
This is sort of true; PHP errors and exceptions exist in different universes but it's easy to unify them and PHP even provides a built-in exception ErrorException to do so. You can turn every PHP error into an exception with 4 lines of code complete with stack traces. You could even turn exceptions into errors but I wouldn't recommend that.
> There is no finally construct
C++ also doesn't have a finally construct. But C++ and PHP support RAII -- class destructors run when the stack is unwound so you can do your cleanup. You could that finally would be a welcome addition to both languages.
> function foo() { return new __stdClass(); } leaks memory. The garbage collector can only collect garbage that has a name.
I am unsure where you got this idea from. PHP is reference counted with a cycle-detecting GC. That would not leak memory.
> 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
This is true, but it's an ongoing discussion on how to correctly handle scalar type hints. For all the discussion about how PHP isn't designed you take issue with the thing they're taking their time on.
> Closures require explicitly naming every variable to be closed-over. Why can’t the interpreter figure this out?
Because of the dynamic abilities of PHP, there is simply no way for the interpreter to ever figure this out. I thought the solution provides was actually a rather simple way of resolving the problem.
> clone is an operator?!
Of course! Why wouldn't it be.
> Object attributes are $obj->foo, but class attributes are $obj::foo. I’m not aware of another language that does this or how it’s useful.
C++ does it. $obj::foo doesn't make any sense, if you're accessing class attributes then you use the class name.
> Also, an instance method can still be called statically (Class::method()). If done so from another method, this is treated like a regular method call on the current $this. I think.
Only static methods can be called statically. A non-static call can be made that way and passed on $this. This can be useful and isn't terribly confusing -- similar syntax as calling parent methods.
> new, private, public, protected, static, etc. Trying to win over Java developers? I’m aware this is more personal taste, but I don’t know why this stuff is necessary in a dynamic language
PHP classes are basically statically compiled. The class code isn't run, it's compiled into byte code before the execution of the script. This is similar to if you just ran the Java compiler on Java code before each run. It's a design decision that has it's pros and cons.
> Subclasses cannot override private methods.
That is the definition of private methods!
> There is no method you can call on a class to allocate memory and create an object.
You can use reflection to create an object without calling the constructor.
> Static variables inside instance methods are global; they share the same value across all instances of the class
Again this is the definition of a static variable in any language!
> Yet a massive portion of the standard library is still very thin wrappers around C APIs
That is, in fact, the point. PHP is supposed to be a thin scripting language layer over C. It's expanded beyond that. Many of the poor naming conventions are not because of PHP but rather are the exact API of the underlying C library.
> Warts like mysql_real_escape_string, even though it has the same arguments as the broken mysql_escape_string, just because it’s part of the MySQL C API.
Both the C API and PHP have both these functions for backwards compatibility reasons. Of course, this entire API is pretty much depreciated with both the mysqli library and PDO.
> Using multiple MySQL connections apparently requires passing a connection handle on every function call.
How would you expect that to work?
> PHP basically runs as CGI. Every time a page is hit, PHP recompiles the whole thing before executing it.
Unless you use a code cache like APC. It will eventually be built in but an easily added option. I suspect most people, however, don't need it.
> For quite a long time, PHP errors went to the client by default
If you don't handle your errors, they go somewhere.
> Missing features
Most of these are provided by frameworks just as they are in Python, Ruby, C#, etc. Why would PHP be any different.
> Insecure-by-default
Only if you're using an ancient version. Some of these things are now removed from the language after being depreciated for years.
I'm actually getting a bit tired so I'm going to bed. I didn't comment on everything in the article: some of them are right. But some of them are just different. Some of them have even been replaced by newer methods of doing things.
PHP has been around for a long time -- I remember when I switched from Classic ASP (yes, VBScript) to PHP and it was a dream. Many of things to complain about now, like the kitchen-sink standard library, were a godsend. It also evolved very quickly during that time and I suspect if it hadn't then it wouldn't have caught on enough to be bitched about now.
For the most part you've defended PHP's behavior as design decisions or offered workarounds. Workarounds just demonstrate that the language is Turing-complete. Design decisions are only okay if they actually make a useful tradeoff; these generally do not.
I can give you individual responses if you really want, but I suspect you won't be swayed no matter what I say. I will comment:
PHP doesn't need a module system? What? Once your program consists of more than two files, you're going to want to import stuff from one into the other in a structured manner.
PHP has a module system: Namespaces and the class autoloader.
But a few things are weird to you but not some objective view of weird. Many of your points I didn't comment on are not unique to PHP at all (such as octal numbers)
> For the most part you've defended PHP's behavior as design decisions or offered workarounds.
You could say that unifying PHP error codes and exceptions is a "workaround" but the language provides specific support for it (The ErrorException class) so it's pretty much a standard pattern. The end developer has the choice of development style.
> PHP doesn't need a module system? What?
I have projects with thousands of files -- as someone else said, Namespaces and Autoloaders covers this.
Also you should check out what Alan Storm has to say about this: http://alanstorm.com/python_imports_for_php_developers
Mr. Storm is a crackerjack PHP developer: perhaps you will listen to him.
PHP does things differently; you don't import things before you use them -- PHP loads modules/classes as necessary when they're used. If you don't use a class, it's not loaded.
Other features of PHP make things like "import *" impossible (or at least very expensive) but at the same time it's also much less necessary.
I could complain about PHP all day but at least I know what I'm talking about!
> Because of the @, the warning about the non-existent file won’t be printed.
So your complaint is that when you use @ to suppress an error it... suppresses the error?
> The language is full of global and implicit state.
"Global" is one of those dogmatic points. Nothing is truly "global" in PHP. The "global" in PHP just means it is request-scoped (ignoring $_SESSION, which is explicit anyway).
Do people complain about request-scoped data in any other language? No. The PHP haters just decide to hate this largely due to the (somewhat incorrect) label of "global".
> There is no threading support whatsoever.
That's a good thing. It forces you to use async HTTP programming or something like beanstalk, both of which are better than the complexity of threading.
> array_search, strpos, and similar functions return 0 if they find the needle at position zero, but false if they don’t find it at all.
So, it's a problem that array_search returns 0 when something is at... position 0? And returning false is just a sentinel value, much like functions in other languages might return -1. So what?
> In, say, Python, the equivalent .index methods will raise an exception if the item isn’t found.
I, for one, hate throwing an exception when an item isn't found. This sucks:
try:
index = a_list.index(a_value)
except ValueError:
# do something
Yes, you have to use --- and basically understand that otherwise 0 == false. So what? In C/C++ you also have to remember to use == not -.
> [] cannot slice; it only retrieves individual elements.
Much like Java/C/C++. PHP has array_slice() if you want it.
It's since been redacted but the OP originally claimed that Facebook doesn't really use PHP (because, hey, that fits his world view).
Look, I could go on but really what's the point? Haters gonna hate.
Sure it would've been nice if PHP had been consistent with, say, parameter ordering (needle, haystack vs haystack, needle) and function naming (sometimes using underscore, sometimes not) but really none of that matters. If you use it, you soon remember. Humans are built to understand inconsistent languages. If we weren't, we wouldn't be able to speak to each other.
Some like to argue that PHP is a beginner's language. I disagree. I think PHP is a fine language for just throwing something together... if you know what you're doing. Otherwise it's just a recipe for SQL injection and XSS vulnerabilities.
A common mistake with PHP is people try and turn it into Java with complicated object frameworks. There is typically lots of hand-wringing about OO'ness.
The procedural style is actually very natural for serving HTTP requests. The core of PHP is a stateless core of API functions. This is incredibly useful for keeping resource usage down. Much like the old CGI model, the entire environment is created, used and destroyed on each request.
This is a feature not a problem. Anyone who has done Java Web development (with stateful servlets or any derivative) should know this as it is virtually impossible not to have come across resource leakage and concurrency issues at some point. The stateful model, while useful, has a significant cost.
I really don't understand this need to complain so vocally about something like this. Possible reasons:
- It affirms the OP's sense of superiority somehow;
- It's about "street cred" with [Python, Ruby, Node.js, insert other language here]; or
- One is so obsessed with "purity" that one spends all one's time complaining about how everything isn't Lisp.
Use it or not. I don't care. If you're not going to use it, why complain about it? If you are using it, what does the public snobbery (which is really adding nothing new to all the other PHP rants) really add?
I'm a big fan of pragmatism and the fact is that 4/20 of the most visited sites on the Internet are written in PHP.
EDIT: /sigh/ I get the inevitable "you must be a PHP programmer" retort (like that's actually a retort and not just more snobbery). For the record, I've only used PHP for ~6 months. My main experience is Java (~14 years), Python (~2 years), C (~5 years) and C++ (~4 years).
While there isn't multi-threading in PHP, you can in fact multi-process which provides similar functionality.
I've run into these a few times and acquired a bit of mastery of PHP's PCNTL, POSIX and Semaphore/SHM/IPC extensions.
I don't do much PHP work anymore, but I do maintain an OSS library for other people in that situation: PHP Simple Daemon -- https://github.com/shaneharter/PHP-Daemon
This is half-plug, half +2 to your point.
The original post just can't be sensibly called "anti-PHP snobbery". It just points out PHP's shortcomings. But when all these PHP-users can't really attack the truth, they attack how it's presented instead (and of course whip up some strawmen and generally just try to skirt around the issues).
The human ego is a sad thing.
(Disagree? How about commenting instead of downvoting with self-righteous indignation?)
PHP devs certainly know its shortcomings like JS guys know that languages too. It's not the fact that he points out the shortcomings, that's fine. What makes it snobbery is how the author points out flaws and is so passionately anti-PHP with the subtext being "what I use is superior". He points out flaws in his preferences but in a way that makes it seem like flaws in Python are acceptable but flaws in PHP are never acceptable.
A lot of people who "point out PHP's shortcomings" are really just on a mission to make themselves and their preferences superior. It's a big pissing contest and these arguments come and go like how JavaScript was once despised and now loved.
More programmers===better programs. How can this be a bad thing?
As far as the snobbery goes, to me it just seems like natural human behavior. People need to believe that their beliefs, their choices are the right ones. For some, the easiest way to do that--rather than being honestly objective or introspective--is to degrade what others do.
I'm not sure this is true. Going with the articles example, that's like saying "the more people who know how to use a hammer, the better houses we will have".
I think it pretty basic an assumption that the more eyes looking at something, the better the chances of finding (and fixing) mistakes as well as finding room for improvement.
However: I think today we have more beautiful design that we would have had if the design tools had not become democratized, maybe not in percentage, but certainly in amount.
My speculation: programming --> more programs. Both crap and great ones.
There are two ways in which this could be dealt with: one would be for PHP to have a change of religion by the core developers and start a massive cleanup project fixing API warts, adding placeholders to or deprecating the default MySQL driver, etc. This wouldn't be easy but it wouldn't be especially difficult except that the core developers are usually hostile to suggestions that they fix, or even document, mistakes.
The other would be for other languages to start simplifying the learning process - Google AppEngine is probably the easiest intro of all, albeit with a severely non-standard architecture, Rails.app, etc.
I think a language like Python or Ruby is likely to gain a smooth dev server install before PHP becomes less treacherous.
(Pro-PHP flamers: I started using PHP back in 1999. Your arguments are not new.)
- Be able to start and serve in minutes, across most platforms
- Allow for portable code e.g. the code you create locally should be able to be ported over to an actual webhost with only [S]FTP.
- Not require the command line to "work". At all.
I tried to learn django ~a year ago, and it was an experience wrought with frustration and pitfalls. The documentation was so-so, and limited in resources (or I couldn't find it). The main trouble was getting all the packages/dependencies correct. I am quite comfortable with linux and terminal (again thanks to PHP), and though I eventually got it working, I was turned off enough by the whole process that I didn't do anything with it. My accomplishment was that I got it to work, which for me was certainly still worthwhile as I was still learning, but a newcomer would likely have gone back to Facebooking long before that...
What is dangerous about the PHP bashing in my eyes (speaking with some current experience as a newb), is when someone decides to try and learn programming and they google some stuff about PHP and read endless diatribes on how horrible it is. So they go off and try django or RoR, are met with tough situations with little to no documentation; can't get anything to work, and give up all together.
Whether or not PHP is pretty, it is accessible. The divide that is created by language ideology only serves to hurt the community as a whole, IMO.
This is the one big problem python has; terrible package management. I can think of 3 different package management systems for python. All of them barley work and the various libraries all require different mangers and different python versions.
This package requires python 2.6. This other package requires 2.5. And now we have separate python 3.x packages. Ridiculous.
HN's fascination with cloud computing and massive scalability is not representative of web dev in the rest of the boring world. The vast majority of web sites out there are powered by shared hosting, where the norm is to cram 1,000 sites on a cPanel server. Apache+PHP makes economic sense in this environment because when your site isn't getting any requests, it uses no resources. But if everybody started running a persistent Django or Rails process in the background, or if every customer had to be given a VPS, hardware and maintenance requirements would quickly exceed what the provider can profitably offer.
I can host a small website on NearlyFreeSpeech for $0.30 per month plus bandwidth, even less before they introduced a surcharge for dynamic websites. One of my old clients is hosted on another pay-as-you-go shared host, where she incurs all-inclusive charges of $0.07 per month on average. (The site is mostly static, with a PHP guestbook.) Like it or not, PHP makes this possible by folding the app server into the web server, and a lot of effort has gone into making such an environment reasonably secure without blowing up resource requirements. Even if you use a regular shared host that charges $8.95 per month, that's still cheaper than a medium-quality managed VPS.
The current state of shared hosting might not be anything to write home about, but the low cost (compared to a VPS) allows anybody, including dirt poor students, to run a web site without being held hostage to a less customizable service that might or might not exist tomorrow, e.g. Posterous. I think this contributes to technical literacy and independence in a small but unique way. Any realistic alternative to PHP had better meet the same requirements.
See, that's part of the problem. PHP has been terrible for close to two decades. It used to be even worse than what Eevee describes.
Ruby, rails: "rails server" Ruby, sinatra: "ruby <sinatra script>" Python, django: "python manage.py runserver"
All of these spin up an app server on some port > 1024. I'm honestly not sure how it can get much easier than that.
Technically PHP isn't much easier if you need to compile it, configure Apache, etc. but in practice they just pay $1/mo for a crappy hosted account where they simply upload a file and start fiddling.
This is a trivial distinction for a professional developer but there are quite a few PHP users who started with a personal homepage and grew from there – and despite the stereotype, they're not all designers, either. That's why I like the Rails.app idea: give today's bright 13-year-old a nice, easy path to getting something visible and let them get hooked before they need to learn all of this other stuff.
The local stuff was indeed nice and simple.
The PHP crowd is mostly filled with "Internet Programmers" [A person who copies code from the internet and pastes in one's codebase, without even reading it, and expects it to work.] And this also applies to all the javascript programmers who can download a jquery plugin and successfully use it in a website.
They even don't know that you can install PHP, apache and mysql separately and use it. For them XAMPP is all there it is, armed with dreamweaver and a ftp client. Most of them will be lost without cpanel.
I've tried teaching a few but all I get is :"go away don't try to be smart in front of me, I know what I'm doing."
Most of you here are smart people. But out there this is what you get from most of the PHP programmers.
That's the real idea with the principle of least surprise. It shouldn't surprise experts. But programming is hard. It's modeling real world processes in the abstract. That's hard. It isn't going to be simple for people who don't know how to program.
If there's one thing that annoys me on programmer forums in general, it's that pointing out PHP's giant flaws is conflated with snobbery. Design matters, and that is not the same thing as saying it's impossible to build anything good with PHP.
This is quite harsh sarcasm, but if it isn't true for the GP, it's true for so many people. Well said.
No one in this comment section is saying to you "stop using php on this project you're doing because it's badly designed". No one is in your business.
That is, we're not telling people to stop after they've gone into McDonalds, we're decrying the fact that so-called health experts are telling people that McDonalds is actually just fine for you. That's a better analogy.
Who are you to advocate that? Or to advocate anything?
I despise people who presume to know what's in the best interest of others. You only know what's in your best interest. You have no idea what is good for anyone else.
You want to share your experience? Great. Do it when it's asked for. Nobody asked for a hit piece on PHP.
> we're decrying the fact that so-called health experts are telling people that McDonalds is actually just fine for you.
Exactly which maven and luminary of computer science has advocated the use of PHP?
That is outright nonsense. At no point has that happened. PHP grew organically, without a single endorsement.
Wow. Are you seriously advocating the equivalent of moral relativism in programming? You have no idea if, say, Brainfuck is good for anyone else?
I didn't say that they were luminaries per se. Programmers telling non-programmers that PHP is OK for them is what I'm referring to. That would match the analogy--someone who's studying health science telling someone who hasn't studied health science that McDonalds is perfectly healthy.
Programmers need to stop telling non-programmers that it's perfectly OK to use PHP. Frankly, they need to be blunt that programming is hard. That you either have to willing to put in the investment or don't do it at all. This soft runway into developing applications is exactly the reason why so much poor software exists in the common market.
PHP has some wrong design decisions, however many of them don't really matter (like function called strpos instead of str_pos - really, that's your problem?). Some do, and people are welcome to propose solutions for them. People also welcome to write rants about "PHP sucks, nobody should use it, anybody who uses it is an idiot" but they shouldn't expect this will be taken seriously.
When did the original article ever suggest that? I got the impression that he had looked it up in the docs, and found the docs seriously broken. That fits my recollection of PHP's docs - there are a lot of them, but they often don't tell you what you need to know, so you have to go trawl through the comments. Of course, most of the code in the comments is crap, full of errors, has security holes or all three.
> function called strpos instead of str_pos - really, that's your problem?
Yes, that's a problem. Ditto for arguments in random order. It means that it's much harder to remember the function without having the docs open in another window.
"PHP sucks, nobody should use it, anybody who uses it is an idiot"? Sounds about right. I know people who are security consultants, who've worked with PHP for years and years - I even know a guy who works at Wordpress. None of them think that you should be using PHP...
Programming language critic come up every now and then in HN, this is nothing new. If you got a point, why not refute it?
Are you saying language design don't matter and not worth discussing?
You can always do:
index = a_list.index(a_value) if a_value in a_list else -1 >>> "foo".find("a")
-1 if value not in list:
# value not found
return
index = list.index(value)
# Code to deal with the thingFrom your edit, you've only been working with PHP for about 6 months, so you may not have seen some of the code most others have. Can you imagine, then, diving into a website's back-end to see @ all over? It turns out, the previous developer realized all those nasty notices and errors stopped happening if he slapped a @ on everything. Now your client/boss/friend is pissed because when someone submits their form and they have a space in their name, the entire site crashes, and you have to figure out what's causing it through a tangled web of spaghetti code with no errors.
This is the norm in PHP because, like the author said, it makes it incredibly easy to write bad code.
> If this one thing that annoys me on HN it's the pervasive anti-PHP snobbery.
This isn't anti-PHP snobbery. To write it off as such is an attempt to dismiss most of the (quite valid) complaints. And complaining about someone complaining is really only highlighting your own hypocrisy.
As you said, you really don't understand his need to complain. That's fine, but many on HN do. This was a great write-up for all of PHP's downfalls. Some of it is really only complaining about how PHP isn't Python, but there are a lot of fantastic points about language design and how PHP sacrifices consistency for... really no reason at all. So don't assume every complaint about a language is "snobbery" or an attempt at "streed cred" (wut?) Instead, ask yourself why there are so many people writing so many complaints about this one language. Then, ask yourself why you're writing them off.
You've turned something that's a person's fault into something that's the language's fault.
Other languages have some sort of warning suppression as well, like Java's @SuppressWarnings or C#'s #pragma warning disable. Although they won't suppress all errors like PHP does, it can still bite you if you don't fix them.
It IS snobbery. You're taking a look at other people's code, and judging the language from it. I've written PHP for about 3 years and I've never once used the @ to suppress errors.
Not to mention that I have no idea why the original commenter picked on this. It was listed as one of the 7 or so things that can go wrong with that one single, not unusual line of code. It's not like he had a whole paragraph about why @ is bad.
Nonsense. The @ error suppression is a tool, just like any other. It should be used sparingly, but it does have its uses. I have been writing in PHP for over a decade and I have used it exactly one time. And yes, it irritates me when I see it in other's code all over the place ... which is why I refactor all external PHP code before I place it inside of mine.
The amazing thing about PHP is that it has a plethora of tools available and the language doesn't force you to write code in some constrained manner according to what some snob perceives as the right way. The only right way is the way that works and works well.
You don't like a feature of PHP? Don't use that feature. Simple as that.
> I refactor all external PHP code before I place it inside of mine
> You don't like a feature of PHP? Don't use that feature. Simple as that.
I don't know anything about you, but judging from that attitude you haven't worked in many teams. Of course it's not as simple as that. If I had a penny for every time I had to fix someone not checking that strpos() === FALSE, well, I could fund my own startup. You may have the luxury of refactoring all over the place, but the reality out there is that horrible code like this is left to fester until it causes real business damage.
I haven't worked on any teams. I've always written software solo. What of it?
> You may have the luxury of refactoring all over the place, but the reality out there is that horrible code like this is left to fester until it causes real business damage.
Refactoring is not a luxury, but a necessity. Not only do I refactor other peoples' code, but I refactor my own. That's the only way to get to a quality code base.
Well, that means you have zero experience with the majority of concerns expressed in this thread, and so are not qualified to opine on them. You work in a happy bubble and I envy you for it, but in the real world you very very rarely get the go-ahead to refactor old code. So in the real world, you very very rarely get to see a quality code base. In any language, really, but PHP compounds this problem with its idiosyncrasies. But you wouldn't know about that.
Out of curiosity, where do you side on the C-is-an-unsafe-evil-language-because-of-pointers debate?
> You're taking a look at other people's code, and judging the language from it.
At some point, you have to start blaming the language for fostering an environment where that code is acceptable.
PHP programmers have only one single thing in common. PHP.
But there is a huge difference here. PHP directly encourages it, making it so easy to do "just prefix it with @" and dedicating a part of the core language syntax to it (thus spending such a nice character for such a triviality). I believe (correct me if I'm wrong) that in Java, it is just another annotation, and in C# just another preprocessor directive.
And I think that's what the article is about - so many things are wrong in the very foundation of the language.
To get the same effect as @ you'd have to use try {} catch {} blocks all over the place and leave the catch blocks empty, as with any other language with runtime exceptions. Sadly this is done more that one would think...
Is it so wrong to use @? I've always used (@$_REQUEST['foo'] === 'bar') as a shorter way of writing (isset($_REQUEST['foo']) && $_REQUEST['foo'] === 'bar') - I'm curious if there's a problem with that approach.
You'd probably be better off creating a function to do what you want succinctly rather than using the suppression operator.
I do maintenance for a lot of PHP sites at my job, and the code is staggeringly difficult to debug or modify. It's punishment for my sins.
PHP was a tool for generating textual data structures (HTML) and it should've been leveraged by another tool for control flow and business logic, but it wasn't. The code I maintain is pre-frameworks; it's got no DRY, no separation of concerns, no design forethought at all. It's just HTML generation that satisfies its needs as they arise.
Now PHP is a quirky, mediocre, and capable language that's still really good at generating HTML.
PHP makes it extremely easy to write ANY code. But since article saying "I've noticed this piece of good code in PHP" is not going to get on HN anytime soon, you get much more attention to bad one. That's like saying Internet is the source of filth because it makes easy to post bad stuff. It makes easy to post all stuff, that's the point.
"This was a great write-up for all of PHP's downfalls."
These "downfalls" are known and discussed 1000 times. Really, who needs another article about "PHP sucks because I can find 3 functions with inconsistent parameters"? How exactly it is going to make anything better? What exactly does it contribute to the world?
No. PHP makes it easy to write bad code and between normal and challenging to write normal code. This is why Doctrine, the closest thing PHP developers have to SQLAlchemy, needs three ways to declare table and column metadata: a separate YAML file, a separate XML file, and in PHP comments. All three of those methods are awful, and only one allows you to keep the metadata and class in the same file.
> These "downfalls" are known and discussed 1000 times.
And, like a wiki, it's useful to have them all in one place.
I write code in a number of languages, and there's nothing "challenging" in writing proper code in PHP. The fact that your example has nothing to do with code quality or language only underlines that.
> "And, like a wiki, it's useful to have them all in one place."
Maybe, but that article isn't it. PHP has a wiki: http://wiki.php.net/. You want to list things you want fixed in PHP and have it in one place? Ask for an account and maintain a page there. Rehashing old tired "strpos doesn't have underscore and str_rot13 has, oh noes!!! I can't use language with missing underscore!!!" is really stale by now and doesn't contribute anything new.
Any old tired issues for you could be something new for someone else.
Maybe my point wasn't clear. It's not a difference in how those two ORMs accomplish their goal; it's that PHP doesn't let you do what SQLAlchemy does, even if you wanted to. Want to write an ORM that uses YAML, XML, or comment annotation in Python? Great! Want to write an ORM that uses classes or objects as column declaration in PHP? Too bad.
> Rehashing old tired "strpos doesn't have underscore and str_rot13 has, oh noes!!! I can't use language with missing underscore!!!" is really stale by now and doesn't contribute anything new.
Now I think you're just being petty. Obviously an underscore isn't what we're talking about here. Take your straw man elsewhere, please.
> Now I think you're just being petty. Obviously an underscore isn't what we're talking about here. Take your straw man elsewhere, please.
What he's talking about here is known and talked about for 10 years. It's just function names, it's not that big a problem. Yes, we know old function names are inconsistent. No, we can't change them because that will break code. If that's what makes or breaks language for you, PHP is not for you, and most languages are not for you, because you're obviously not interesting in solving the problem, you're interesting in boosting your self-esteem by boasting shiniest tool out there. Nothing wrong with it, but PHP is not created for that. If that means for you that PHP sucks, fine, but for 99.99% out there shininess is very low on the list of priorities. So if you want to discuss important stuff, leave old stale stuff like ranting about strpos alone and discuss important stuff.
You must have missed the rest of that paragraph. I specified what it does.
> What he's talking about here is known and talked about for 10 years. It's just function names, it's not that big a problem.
Again, missing the point. Python has these same minor inconsistencies in its stdlib. It's the combination of all these minor inconsistencies with a language that gives you more tools to write bad code than good that makes PHP torturous. It's everything that the author wrote about in one neat little package.
What prevents you from doing that in PHP?
https://github.com/gigablah/fsphinxphp/blob/master/src/FSphi...
Note the $getter parameter.
I'm actually doing just that; it's not as clean as you can do in Python but it's not outrageously verbose either. Trying to map one languages features onto another is not a valid critique.
Different language has different limitation. Just because you can not have SQLAlchemy in C, does not mean C encourage bad code.
> So your complaint is that when you use @ to suppress an error it... suppresses the error?
This was one bullet-point from a 7-item list. Also it didn't say that @ is bad in any way (perhaps its use is), it was there only to demonstrate error configuration which is clear by the bullets after it.
> > There is no threading support whatsoever.
> That's a good thing.
You are right that for many tasks not even thinking about threads is a good idea, but there are cases where threads are very appropriate. Having the feature wouldn't hurt, would it? (Considering how tied the php is to C)
> So, it's a problem that array_search returns 0 when something is at... position 0? And returning false is just a sentinel value, much like functions in other languages might return -1. So what?
He explained the "so what" in the next few lines. I'll cite it for you: "If you use FALSE as an index, ..., PHP will silently convert it to 0 for you. Your program will not blow up; it will, instead, do the wrong thing with no warning"
Having a try statement is same as having to check for the value to be FALSE/-1/whatever, we can agree on that. But letting users write code that appears to work (yet it does not) is not a good property of a language.
> Much like Java/C/C++. PHP has array_slice() if you want it.
PHP's arrays are very different (uniform types) from those of C/C++/(Java?). So why compare them? Other than that, I agree, having slice function is enough. The author could've left this one out.
So two of your points were taken out of context, one was your opinion (two if we count your preference of if over try when checking for errors), and only two were probably justified. Rather strange choice considering you had dozens of options.
I still don't see the point that's trying to be made here. Whether it returns -1, FALSE, or you need a try/catch, the programmer still needs to check. To successfully program in any language with an 'index of' function, a check needs to exist regardless...
No, you should not. You should never have error reporting turned off. You should certainly have it set to not display errors to the client, but all errors should be sent to a log, preferably syslog, and they should be reviewed. Your code shouldn't generate any errors.
Ha. Ha ha. Ha ha ha.
Tell me more about maintenance programming and legacy production systems.
Sorry bro, if you have ever put code on production with error reporting on...you are doing it wrong.
In production, you should have error_reporting set to something like: E_ALL & ~E_DEPRECATED
And then:
display_errors = Off display_startup_errors = Off track_errors = Off html_errors = Off ignore_repeated_errors = Off ignore_repeated_source = Off log_errors = On error_log = /path/to/log/file (or syslog)
The settings related to displayed errors in the page are error_reporting and display_errors. The error logging is a totally sperate group of keys starting with log_
I could not agree with you more. Advising beginner programmers to use PHP is like handing out guns in a playground, someone is going to get hurt, and it will probably be the users.
I am confused by why you think this is "anti-PHP snobbery". What about HN's attitude to cold fusion or to VB? How can you tell which criticism is valid criticism from experienced developers about which tools are good and which are bad and which is "snobbery"?
It's not like experienced developers who dislike PHP for being poorly designed and having a poorly managed community is a rarity. It's very common among respected developers. I suppose that to be a respected developer you must conform to the anti-PHP bias? Does the conspiracy go all the way to the top?
Or maybe a lot of these criticisms are valid, but you disagree for your own specific reasons?
It's important to re-iterate what the article is NOT saying. It's not saying that you can't do awesome work in php, there's tons of great counterexamples. It's not saying that you can't change the world with php. It's not even saying that you can't write a maintainable, legible, beautiful app with php.
The problem with php is that the core language ignores a ton of what we as a community have learned about language design: Be consistent. Make it easy to do the right thing. Make unwise code look awkward. Pick a type system and embrace it. Don't try to magically do the right thing. Be predictable. Avoid action at a distance.
It's not that PHP makes for a great beginner language. So does Python. It's not that PHP has flaws, so does every language. Many darlings of the Hacker News crowd even have some of the flaws from this list. But I'd challenge you to make a list a quarter of the size of this one with Python, or Haskell, or frankly even Javascript.
I can tell you my reasons: the market. Not all of us can roll a globe, close our eyes, pinpoint a place and tomorrow have a job there. Here where I live, about 80% of webdev jobs are PHP. Even when I do manage to get a Ruby or a Python job, chances are that I will be doing lots of PHP code maintenance and migration anyway. I would like to change it, and I don't know better than to advocate, pro and against.
I'm getting the impression that this is why a lot of people hate PHP - Money. People don't like that the market is full of money wasted on an inferior language. Perhaps there's a bit of envy in that, perhaps not.
The winners in the marketplace aren't always the best, and it's not easy to change minds. People get religious about the things that make their living, whether it be a programming language, certification/designation or some other thing.
But Atheists aren't going to convert many Christians and Christians aren't going to convert many Scientologists.
In the end, you have to work within the parameters of the market or create your own. I guess for some people, like the OP, it's easier to vent. Nothing wrong with that - we should all speak our minds, but it's not necessarily going to be effective in converting anyone.
Look at the resulting discussion here, the OP's either preaching to the choir, or his message is falling on deaf ears. I don't see a lot of 'a-ha, he's right, I'm switching now' posts.
> the OP's either preaching to the choir, or his message is falling on deaf ears.
That was the point of the post. If he points people to it, and they read it but still disagree that PHP is crap, then there's obviously no hope for them.
Yeah, but why would you care unless you're begrudgingly participating in the PHP industry? It's not your problem unless you make it your problem - i.e., if you're so against it, don't work in a PHP shop, don't take PHP contracts. Problem solved - if other people want to use lame/bad languages, who cares?
The impression I'm getting is that a segment people who hate on PHP are participating in the PHP economy because there aren't as many local opportunities in {insert language here}. To me, that's not much different from the guy who's stuck working in a "lowly" coffee shop because he can't find a job in his field of study, which of course, makes him entitled to be rude to customers and his fellow employees.
The money is nice, but after watching the ridiculous waste of PHP idiocy for the Nth time, you can't help but want to get people to stop.
At least with PHP it's likely to be some vaguely HTTP/POST-ish interface, not some XML/WSDL monstrosity...
And, unlike you, I don't think these articles are pointless. I hope they help PHP get more bad reputation among coders, and peer pressure will do the rest.
Bashing and negativity is not the way to do it.
You'll get much farther showing a PHP person something more interesting (whether it be Rails, Django, or whatever) and highlighting all the cool things about it. Because that person will not be on the defensive, his/her mind will be way more likely to have that 'Wow, that's so cool I should try it' moment.
* PHP is open source. If you don't like it, change it. Or submit patches. Or bug reports
* PHP does what is says on the can. It's a hypertext preprocessor, and it does this exceedingly well
* If you're having difficulty doing complex work in PHP, you're using it for the wrong problem
The anti-PHP stance on HN is almost meme like. The lack of silly memes is why I respect HN over other aggregators,
That having been said, I agree PHP does what it was designed to do, but has been leveraged into pretending to be a general purpose language (much like what happened with perl)... which it is NOT really good for.
Bug reports have been filed and closed for many of these issues.
A full on fork of php might be interesting, though the thought of what's going on behind the scenes in the php interpreter terrifies me.
PHP is the MS Word of web programming. It will be here for a long time, just get over yourselves and concentrate on what you write, not how you write it.
He (playing with his iPad 3): PHP
Me: I thought PHP devs died out for years??
He (angry): PHP is still the most used language for the web and it's fast.
Me: Do you guys still mix front-end and back-end code?
He (still angry): Of course not.
Back home I started googling "PHP" and "PHP frameworks" for the first time since 2003 again. I was surprised: there are many Rails-inspired frameworks like Yii, Zend, Codigniter, etc. And I tried to be objective giving PHP another chance (I haven't an actual use for PHP but I was just bored and wanted to be prepared for better counterattacks next time).
My impressions:
- There seem to be too many frameworks or call them ecosystems, so I couldn't figure out which is the dominating one (Zend?). And I am not sure if they are really interoperable
- Not relevant but awkward: most frameworks websites (except Yii) and in particular the PHP site look like 2003. What disturbed most was the often used claim "no console needed".
- On Freelancer.com, Monster or any other job-related site the quantity of postings for PHP devs were massive—any other web-related fraemwork/language else like Ruby, Python, Django was a small fraction oft that.
After looking at some "modern" PHP code (which strictly follow the MVC patterns now) I still couldn't get warm with PHP. I assume that most PHP devs are long-time PHP devs and I don't understand how PHP can attract people compared to newer concepts.
I've just spent the weekend porting an old site to Silex and Twig (a PHP equivalent to HAML) and its been a breeze.
Both frameworks come from the same people and have excellent documentation and support (i.e. they are not run by a couple of geeks somewhere who might suddenly stop developing them once they get bored). See: http://symfony.com/elevator-pitches
People honestly still believe PHP is fast? Wow. Even Ruby (1.9, YARV) is as fast as PHP nowadays, and it's one of the slowest mainstream scripting languages you can use right now...
http://shootout.alioth.debian.org/u64q/which-programming-lan...
I work with PHP everyday, and it's a fine tool. It does what I ask of it, at least. If the objective is to drive a nail into a board, you can do it with a hammer or a rock, and it doesn't really matter which. Accomplishing the goal is what matters. If you can do it in the same time, why does it matter which tool you use? So one may be more elegant. So PHP is slow as balls.
Programming isn't a religion. We don't need to be so dogmatic.
>Don’t comment with these things
>>I’ve been in PHP arguments a lot. I hear a lot of very generic counter-arguments that are really only designed to halt the conversation immediately. Don’t pull these on me, please. :(
>>>Do not tell me that “good developers can write good code in any language”, or bad developers blah blah. That doesn’t mean anything. A good carpenter can drive in a nail with either a rock or a hammer, but how many carpenters do you see bashing stuff with rocks? Part of what makes a good developer is the ability to choose the tools that work best.
>>>Do not tell me that it’s the developer’s responsibility to memorize a thousand strange exceptions and surprising behaviors. Yes, this is necessary in any system, because computers suck. That doesn’t mean there’s no upper limit for how much zaniness is acceptable in a system. PHP is nothing but exceptions, and it is not okay when wrestling the language takes more effort than actually writing your program. My tools should not create net positive work for me to do.
That's not even deep in the article! By spouting off exactly the arguments that the author anticipates, you're making yourself look like a jerkhole who didn't even do basic reading before spouting off a reflexive, unthought, and worthless opinion.
Secondly, I don't think PHP is a bad tool. You can accomplish tasks very quickly in PHP. It is certainly not the fastest language, of course, it's not compiled, but it has a lot of great features. A lot of the points made in the article I consider features of PHP and are not detrimental.
I've recently been toying around with various methods of tying C++ to a web frontend, with varying degrees of success. My current favorite method is to use mongoose to create a very simple HTTP interface for any C(++) project (mongoose is great!) and then use AJAX and JSON for any and all communication to and fro client and server. However, this leaves people that have JS disabled out of the loop.
My problems with PHP aren't so much the language as much as it is the environment. It's such a mess with so many dependencies that keep breaking any time you want to do a security update. I'm running PHP-FPM w/ nginx on Ubuntu LTS (Lucid), with the suhosin patch, xcache, memcached, and libcurl (I try to keep the external dependencies down to a minimum. PHP's 3rd party libs are so poorly developed and leak memory like crazy. They're also strictly non-TS builds, and will segfault like there's no tomorrow if used in a TS environment.). Trying to keep up with all the security patches means rebuilding a zillion different packages and applying a few dozen patches each time. It's not a piece of cake.
As soon as I've found a nice, convenient, and lightweight C++ web interface (wt is nice, but it's very intrusive and all your code becomes wt-specific), I'm planning a series of tutorials and open-sourced projects that can help anyone else interested in dumping PHP.
Honestly, it's not so much moving towards C++ as it is away from dynamically typed languages. I've had it with subtle bugs that appear only during run time and only when a certain codepath is taken with languages that let you implicitly define variables. I've come to the conclusion that implicitly defined variables and structures are of the devil himself, and no developer should ever end up working in a language where the compiler doesn't alert you at compile time that your codepath uses previously undefined values. ugh.
"Subclasses cannot override private methods. Subclass overrides of public methods can’t even see, let alone call, the superclass’s private methods. Problematic for, say, test mocks."
IMHO you don't want private methods to be visible in subclasses, because this makes the fragile base class problem worse. If I'm a framework developer working on a UI library, I should be free to add private methods to my Button class for the second version of my library without worrying that they'll influence the behavior of a FooButton that some app wrote that's derived from the class in the first version of my library.
The problem, of course, is testing. You want to be able to cleanly substitute mock objects for unit tests, without having to make everything depend on an interface or to use protected everywhere. It'd be nice if languages had more unit testing facilities built in. Microsoft Fakes is an interesting approach here.
Namespacing within an inheritance tree is a problem, yes, but just hiding as much of your namespace as possible sucks. As does ahem ahem double-underscore prefixing. Surely there's another option here, but until someone figures out what it is, I'm okay risking collisions.
It's purpose is to isolate you from implementation details you're not supposed to care about and allow the library/framework developer to update their code without fear of breaking your components. It's also a form of enforced documentation.
I'm not convinced this is universally applicable, but I'm otherwise sympathetic to it.
It would be better for everyone if people could mentally separate PHP's features and misfeatures and learn from both, instead of just bashing the language and jumping to its defense as a whole.
I would really like to see PHP take the time in the next version to fix all of the inconsistencies.
That being said, it's nice to be able to sit on the most version of PHP and use awesome frameworks like FuelPHP and Laravel. I would not really consider doing anything besides nice CRUD app's in PHP though.
Frameworks can help a lot, but what PHP really needs is an equivalent to CoffeeScript that fixes all of these glaring issues with PHP.
Although there's issues with the PHP language implementation, the biggest problems are the enormous number of functions with quirky argument ordering that need to be understood by a developer before they're operating at full efficiency.
http://code.google.com/p/php-snow/
Frameworks definitely help a lot. I've done a little work with FuelPHP, and I found that to be pretty pleasant.
The entirety of the PHP API should be bundled up in a burlap bag, beaten savagely with a baseball bat, then thrown in a shallow grave to be set on fire before being buried. The "Goodfellas" treatment is way too kind in this case.
I remember switching to PHP for three reasons about 9 years ago. I cycled through Perl, ColdFusion, Java Server Pages, and ASP JScript before getting to it.
1. It was the most accessible free alternative to costly platforms (ColdFusion, MS ASP) or more strict / difficult to configure platforms (Perl, JSP). Error checking was as simple as ASP/JSP and starting up was as simple as paying for a cheap LAMP server that would run it out of the box.
2. It had the largest set of online documentation for both the language itself and tutorials / code examples. This was one of the biggest unavoidable draws to the language. The community was huge and still is to this day although documentation is much more evenly distributed across other languages now.
3. PHP may be one ugly beast but it does pre-package practically every piece of functionality you could ask for within it. I'm not sure I have ever liked the look of the code but there was something magical about being able to grab remote server code via file_get_contents for the first time. It was so damn easy!
If I were to suggest a platform today I would probably have to go with Python. It has all of the same advantages that PHP had in the past but has the added benefit of being better designed and applicable to more than web programming. Ruby would be my second choice simply because the environment setup is a bit more complicated still, although the language is the most beautiful in my opinion.
Those who think otherwise are most likely stalwart proponents of some other language, engulfed in functional programming or have read the latest post by _____ that explains a concept that should be used only rarely and will use it as an attack to state why another language is awful.
The fact is, you will never, ever, ever convince someone that your opinions are better than their own if they don't already think those things. Every language sucks and every language is awesome. Get over it. Bootstrap/CSS, HTML, jQuery and the database are easily 80% of the code of any generic site that isn't a business. The rest is Database access, AJAX functions, Auth, View rendering and hopefully security - and while important are very small in comparison to the grand scheme of things.
You don't need sockets. You don't need Duck typing. You don't need event-driven functionality to do most of the things you find on the internet. Those things are fun, but are not that important in the long run.
PHP is outdated, seemingly random and can let you write terrible code. It also does not get in your way if you are a competent developer and shortcomings are slowly being addressed, which is a good thing. When was the last time you wrote a site that NEEDED the things PHP is missing as a language?
Actually about half of the article was about how it does exactly that by being inconsistent, having action-at-a-distance effects, and not having real hashes/arrays/tuples.
Also you appear to have skipped the "Don't comment with these things" portion of the article, which anticipates all of your arguments.
That said, my primary language is PHP and I've written a whole lot of it over the last few years. I can report back that the choice of language is somewhere around the 37th most important factor in the end result. Whatever its flaws, they just don't have that strong of an impact in reality.
That being said, thank you for documenting why nobody should ever seriously use this language unless it's absolutely necessary.
The mind reels.
http://perldoc.perl.org/perlop.html#s/PATTERN/REPLACEMENT/ms...
"e Evaluate the right side as an expression.
ee Evaluate the right side as a string then eval the result."
empty() doesn't issue a notice if the variable isn't set, like it would if it were an ordinary function. It's basically isset() with extra functionality. That makes it useful for checking form variables:
if (!empty($_POST['foo'])) { ... }"Similarly, there is no easy way to “insulate” a PHP application and its dependencies from the rest of a system. Running two applications that require different versions of a library, or even PHP itself? Start by building a second copy of Apache."
If you're running PHP via fastcgi (e.g. mod_fcgid on Apache), you can build as many different versions of PHP as you want and then point the various websites/webapps to whichever version they need. It's trivially easy to do.
There's nothing stopping you running php on a separate dedicated machine from the web server. You'd just use mod_fastcgi and php-fpm.
You can run it in a webserver thread (mod_php), run it in its own process alongside the webserver (mod_fcgid), run it on a dedicated machine (mod_fastcgi) or run it from the command line.
That's the beauty of PHP, it lets you do what you want. The downside is that this flexibility can be dangerous in inexperienced / naive hands.
Actually, I don't get what's so simple about deploying PHP files individually via ftp. All I do is enter 'cap deploy' on a terminal. And I get free rollback. (there's web interfaces as well)
PHP is a product of evolution. It's not nice but it's incredibly well adapted.
Instead of complaining about how ugly it is people should be researching why it flourished and make sure that they introduce the same qualities in their designed systems.
I have few guesses what might these qualities be.
- Script serves one request and dies. Problems are limited in time and range. They most likely won't bring your app down. - You have universal data structure, ordered dictionary with lots of functions that operate on it and some additional features for numeric keys. - you have php.net/name_of_the_function which gives you description of the function and it's parameters, return values with comments and examples of use from the users. - getting things sent by browser is extremely easy, sending stuff to browser is even easier. - if you want to do something, functions that will help you are there because someone needed that before you and just added them there. And it's not in some obscure package that you have to download from God knows where. It's in the core and it's most likely only one of it.
You can dissect a rat and complain how ugly it is but it will still eat your lunch.
All the elegance of other languages are not that important. 99% of software development is not architectonic cathedrals. It's telling your slave what you want from him.
Also 78% of the statistics are bogus including this one.
I'll admit that I am new to web app development and learned how to program(web apps) with PHP. The simplicity and forgiving environment is what made it so alluring. Sure my first bits of code may have been sloppy, but that sense of false confidence pushed me to learn more and improve my understanding. I gained experience and "real" confidence quickly. After seeing how easy it was to make simple apps with authentication features and whatnot, I moved onto Python. PHP quickly taught me the basics which then allowed me to jump into more advanced features and other languages, and that is why I appreciate it.
Before anyone uses my words against me where I mentioned a sense of false confidence, I think that's actually a positive thing. It pushes the user to learn more, or at least it did for me. Do you really think anyone with a complete lack of understanding of OOP, frameworks, or programming in general will be able to hack together a Facebook, ebay or Paypal?
I've sometimes heard of programming as an art, like poetry, but if so I'd prefer to maintain that it is a minimalist art that enjoys pragmatism and flourishes when reduced.
Put another way - I don't want to write 'A Tale of Two Cities' in PHP, I want to write a website in PHP. Or more correctly, I don't want to write a website in PHP.
I heard that on the radio, and I've been looking for it for years! If anyone knows the show, ideally the specific show or interviewee, I'd be supremely grateful!
And LISP is the best programming language there is, even if I don't know most of the other programming languages, because LISP has macros.
I highly doubt it anybody is qualified to make such statements, because you'd need to speak fluently every language there is, just to be sure. Seems like somebody just wanted to feel better because his language is the best.
Luckily, programming languages are a bit easier to learn and replace than spoken languages.
because computers suck
They do not. Barring only the wonders of the realm of nature, computers are in my opinion one of the most wondrous things, it is a testament to Humans as to how creative, industrious and sheer genius we can be. They allow us to do computations beyond our wildest possibility, allow us to control, consume, produce and every other verb you care to mention.
Computers do not suck.
As with most things, it's both good and bad. It IS fantastic that you can so easily toss a .php file into a directory, make a few minor Apache config adjustments, and BAM - dynamic website behavior.
...that's also a glaring weakness, though, when a complex application is developed without the structure imposed by other tools. I have to maintain an event registration system written in PHP, and I'm having incredible difficulty with it. The logic to store form data, look for errors, display the current form, and prepare the form for submission are all in a single, 1000+ lines spaghetti-code file.
I think the author's point (and certainly the one I'm making) is not that this is the only possible outcome of writing in PHP, or that other languages do not have this problem. Rather, the point is that the lack of cohesive structure removes barriers to writing bad code; in fact, it makes it (initially) easier than writing good code.
This was about when I stopped caring about what the author had to say. The sentence where he snobbishly belittled me and called me an amateur because of the programming language I use.
1. Ooo, PHP is awesome, I can make stuff happen on a server!
2. Hm, well, PHP has its problems, let's open source a microframework to fix it!
3. Oh my god, PHP is horrible, let's rant about it on a blog!
4. Who cares that PHP is horrible? It's the application that counts.
Hello world
If all you want to do is print some text, just put some text outside the <?php delimiter. If you want to do nothing else, you don't even need the <?php delimiter.
Hello World
I wrote this because nobody had written it comprehensively enough, and as an engineer I am inexplicably convinced that I can do everything better than everyone else if I just redo it from scratch.
What really can be done? Should they make a new version that provides more consistant function names and break backwards incompatibility? I've yet to hear what people think should be done with PHP besides abandoning it.
That being said I don't think it should die, I think it has it's place. I'm not as smart as the rest of the folks on here, but for doing client sites, PHP gets the job done very fast.
To me at least, an equally thorough treatment of what he might consider the "right" or "good" language would have made the time invested in reading the bitch-about-PHP feel more valuable. You'd walk away with at least one well-studied view for a potential direction away from PHP. As the article is currently written you are told all the reasons why what you are using is shit but not given any hint as to what you might consider looking into.
I namedropped Python a couple times, and I do enjoy it for webdev. I've been considering writing something about getting into Python webdev from a purely PHP background; might do that sooner rather than later.
I say that because, while it's clear you spent a lot of time on this, it's not really useful precisely because you don't provide any direction. Who is this article for? New people? They aren't going to understand half of what you wrote, but more importantly, they don't know where to turn to for the next step. You mention Python. And that's cool! Python is an awesome language. Your target audience (new programmers or new web developers) aren't going to read through that entire thing. The only people who will are PHP developers who want to respond and people already hate a programming language.
What would be valuable is if you took a look at why people pick up PHP, and instead of trying to destroy it's existence with a single post, you actually show them how they can use Python to do what PHP does. You've clearly done the research, so you know where PHP's strengths are, and why people still navigate toward it.
Anyone can destroy. It takes actual effort to create. Help create. =)
* the huge lock-in with existing code + knowledge
* network effects (aka. "Facebook and my mate Ken use PHP, therefore it must be good")
* Most PHP devs don't know/want to know anything else.
Like the post above says, learn anything other than PHP. Python or Ruby are both solid choices - you can go with something wacky, like Lua, Scheme or Erlang, but if you only really know PHP, that might be too much.
It really doesn't matter - just pick a language and (small-ish) project, google for a framework that looks good (Django, Bottle, Flask, Rails, Sinatra, ...) and go! By the time you get that done you'll be better placed to pick something new that works...
I'll make the assumption you weren't talking to me, but rather, the general audience instead.
> Like the post above says, learn anything other than PHP.
Python is an excellent language to learn! I agree. However, people aren't interested in learning a language. Consider the context of my post, and the article, mind you. If you really want to help people choose a language, focus on the the accomplishment.
Case in point: Learn anything other than PHP.
That's the wrong approach. That's not good advice. In fact, that's horrible advice... for someone who wants to build a dynamic website.
And, frankly, if someone is looking to build a dynamic website, PHP makes that insanely easy. Much easier than anything else, especially when their hosting probably already has it up and ready to go.
So the challenge, as I see it, isn't to focus on "Not learning PHP", but simply saying "This is how you create dynamic websites" and use Python to do it.
You know the difference between most PHP tutorials and Python tutorials for beginners? PHP starts you out creating a dynamic website. Python starts you out using the REPL. 1+1 isn't going to inspire anyone. It isn't going to excite anyone.
But getting a form in place that displays the results? That's awesome!
That's the difference. I'm generalizing here, but I think it's a fair conclusion. I know their are articles for Python that focus on that, but they are far fewer then the ones you find for PHP.
And, with regards to this post we are discussing, the author really does just leave it at that.
Learn any language other than PHP is the worst advice you can give to someone who has an idea. They want to be focusing on the idea, not the installation or language. At that stage, they are focused on building, not the tools. You might argue (rightly) that the tools and material matter, but that isn't going to win you people choosing Python.
PHP being easy for beginners isn't just about the setup. It's the entire scope of the project, from the community, to the tutorials, to the software they are already using. If the only thing you focus on is installation, you won't succeed.
Sorry, this is a bit long. Hopefully my point is made.
PHP is a terrible language for a beginner to learn, because there's no rhyme or reason to most of the things that it does. Which leads to cargo cult programming and bad habits that take a long time to break.
> because all of the tutorials out there teach you to build a giant pile of insecure spaghetti hacks.
I think this says it all. You really aren't interested in changing anything, just bad mouthing everyone and anyone that will listen. This entire time I've tried to have an honest conversation with you, and at each point, you've done your very best to dismiss what I've said and insult as many people as possible.
I'm sorry, I don't work with your type. Good day.
TL;DR: Beyond the very basics, PHP is only going to frustrate beginners. It has confusing syntax and weird special cases. You should pick something different as a first language.
<? if ('9223372036854775807' == '9223372036854775808') { echo "I can not count!\n"; } ?> (see https://bugs.php.net/bug.php?id=54547)
or
built-in PHP web server dies with a large Content-Length header value: The value of the Content-Length header is passed directly to a pemalloc() call in sapi/cli/php_cli_server.c on line 1538. The inline function defined within Zend/zend_alloc.h for malloc() will fail, and will terminate the process with the error message "Out of memory". (see https://bugs.php.net/bug.php?id=61461)
Luckily we are getting Javascript ready to replace all PHP on the server sooner or later ;-)
Besides, I enjoy analysis of programming languages, the good and the bad parts.
Until there is something else where you can deploy a prototype by dragging a single file onto a server with a FTP program, then PHP is serving a purpose that no other language can meet.
So stop crying about how PHP is horrible; stop trying to fix what is obviously a broken language; make something else that can fit this need, and you will kill PHP.
The only reason why still PHP exists past hobbyists is because people who start businesses want a fast prototype, cheap hosting, and no fuss. It may not be ideal, secure, fast, scalable, maintainable, or anything else, but if it's making money in the shortest amount of time possible, with the lowest cost barriers, then it's a success.
PHP is a language with problems like all others (c, java, python, etc). It can be used for good or for bad like any other programing language. All the problems on the article are well known by decent programmers.
PHP is out there, use if you want.
Go write decent code... stop nagging.
If you actually read the article, you knew that one of the author's point was that PHP's problems are magnitudes of magnitudes worse than other languages in the wild.
That's more or less a matter of fact and that there are still people deny it just shows the sad state of PHP "programming" in general.
Nothing in the whole world is easier and faster for a 4/page Personal Hypertext Project.
Nothing.
Don't blame me, I use python and go most of the time, I just wanted to point out the answer to why people still use PHP today. It was created with that only purpose, it grew like weed out of control.
Don't you ever compare php to python, ruby, java or haskell. Don't even try to ridicule php, the only one looking bad will be you for being so ignorant to compare a rock with a hammer and wasting a whole post complaining how the rock doesn't even have a handle.
I am not familiar with any precise quantification of the bad parts of JavaScript and PHP which could serve as a basis of that conclusion. That said, both PHP and JavaScript are web scripting languages that are full of bad parts. Extrapolating outwards, the entirety of modern web development is flawed.
> Plus, it's actually quite easy to code in JavaScript avoiding the bad parts.
In a sense it is harder to avoid the bad parts of JavaScript because it is tied to the browser platform, with PHP you can avoid basically all of its bad parts by simply using a different language like Clojure or Scheme.
Here's some stuff I've picked up from his about page (http://veekun.com/about)
He loves Pokemon (really cool depending on how old you are)
He's "extremely picky about software"
He, "tend to rave about bad products a bit too much. After having been bitten by it too many times, I can't stand sloppy languages or sloppy databases."
I wonder if python's Django stack traces are better on errors in templates and such.
Fortunately there are many options when it comes to web development. You don't like PHP? Avoid it! Do not use it! Use Ruby or something.
I used to get cranky about Facebook. Now I don't use at all.. what do I feel about Facebook now? Nothing. No point getting your pants in a twist about something that doesn't need to a part of your life.
If you don't like PHP, Just don't fuc_ing use it.. Nobody is forcing you to use it..
Let developers make their own decisions on Which language they want to use.
As long as WWW exists developers will use PHP, Get over that.
As long as PHP will have all these warts, people will condemn it, Get over that.
That's a problem? I think it's a problem if new functionality can't be implemented as part of a library. I think it's a problem if the best way of implementing new functionality is always to have new syntax.
The PHP eco-system (largely made up of platforms and templates) is huge. Ignore it at the peril of your revenue.
I like the fact that + is for addition and . is for concat.
It's kind of up in the air if you do "1" + 1, does it become a string? Or an integer?
The other day I was asked to do a cron task and I was able to do it with Zend Framework very quickly and quite elegantly. It was surely not the perfect tool but since it integrates with the culture of devs and sysadmin there it was certainly good enough and very maintainable.
http://www.reddit.com/r/PHP/comments/rh3u2/any_new_major_sta...
"Good enough" is not good enough. COBOL was "good enough" for many companies. We can do better, and we should try to.
stack traces? learn to throw exceptions and I'm given a very nice stack trace.
complaining ftl..
time python -c "for i in range(int(1e8)):pass;"
time php -r 'for($i=0;$i<1e8;++$i);'
go on, run the commands.
Outside of the wide availability of PHP servers for cheap, what makes PHP so great for beginners? With Ruby, Python, Go, hell, even JSP for the "instant", in-HTML effect, I just don't see PHP as some gloriously "easy" language to use.
On top of it, there are hundreds of thousands of PHP tutorials all across the Internet that just have poor, poor, poor suggestions and design patterns that lead to people storing passwords unhashed, or unsalted. Sure, it's not unique to PHP, but it's really, really easy to get wrong in PHP and that's painful for a beginner and it's hard to progress and mature as a PHP developer without an existing code base to learn from.
tl;dr: I'm not convinced is as great as many here make it out to be. (To note, the first thing I sold was written in PHP in highschool. Since then I've used JSP/J2EE stack/python/ruby and now am infatuated with Go, so my opinion is not simply based on group-hate for PHP)
This is a horrible design for a large webapp, but even as an experienced programmer, sometimes I just want a quick hacky self-contained script, like the many, many .py files in a subdirectory of my home directory (but on the web, Python does not provide this convenience in commonly used setups). A beginner can similarly benefit from simplicity: even if Rails tutorial code is pretty, there is still a lot going on behind the scenes; sometimes, the smaller conceptual model required to really understand what's going on, the better.
Cause as a designer who programs (mainly php) that is the number one reason why I haven't been learning a new language.
They all require way too much. Php just works for my needs. If I get bigger needs then I am sure I will make the switch to another language.
What? I understand for a beginner, but come on. If you're really a programmer programming for many hours aday... you really won't take the time to learn how to wire up wsgi to a python process? It's no harder than wiring Apache up to mod_php5 and telling it where to serve out of. It just takes a very modest effort on your part to learn it.
And then you get all the benefits of... not having to use PHP and getting to use... anything else.
It's been done times and times again. Look at Sinatra for an example in the ruby world (http://www.sinatrarb.com/), I'm sure python has something similar. Maybe a static site generator such as octopress or push would be an option as well.
The problem is that the simple php approach does not scale. Sticking files in directories will only get you a small step, you'll need includes to share code soon. And then the mess starts if you're not using a framework. And good PHP frameworks go a long way beyond sticking a file in a directory - you'll have the same steep learning curve as with rails or something similar.
From what I can see and aside from the ease of install, it is the namespace. You type <?php and you have hundreds of functions at your disposal. Not the case with Python or Ruby where you need to understand imports and global objects.
Sometimes everything not being an object helps, but only in the short run.
It's not great, but it's the easiest to grasp.
Maybe new devs should learn Perl, instead... http://search.cpan.org/~adamk/Acme-Everything-1.01/lib/Acme/...
- Making better languages more accessible to utter newbies (PHP is unarguably the easiest to "get working", if nothing else of the prevalence of hosting).
- Showing newbie PHP developers how to do it better
- Introducing "better" languages to advanced newbies
The fact that PHP is used so widely as a gateway language, and the web is stuffed full of bad advice, is a systemic failure in those of us who know how to program well...
The ease of php (as mentioned repeatedly) is that you get global access to hundreds of functions. If you know how to call a function, you can probably hack together what you're trying to do. Others (python, ruby, go) are meant for more mature applications because real problems are not that simple. You "have to" do imports and write more boilerplate, but it's also more explicit as to what's happening in the context of HTTP and enables and encourages better design.
I feel like it's a compromise and I think creating something new that is as well thought out as Go but as simple as `<?php header("Location: http://google.com) ?>` would be difficult to do. See other things like PHP: JSP, etc.
From my perspective, Ruby on Rails is really, really difficult so far. You have to learn to use the terminal (which I've seen other people in my position use to totally mess up their computers); to make a simple application you're already looking at maybe a dozen files, many of which you don't understand; most importantly for me, because there is a lot of stuff going on that you can't see, it's very hard to extrapolate from examples.
I have learned what programming I know from breaking apart example programs and then using the pieces to build other things. I'm not good at learning from textbooks or tutorials. This has proved very difficult with RoR so far. I'll take components that look like they should make something happen, and then they'll throw an error that I don't understand and can't seem to locate.
Doing otherwise is like trying to learn PHP by looking at the Drupal codebase.
I don't mean to be saying that I'm doing it right, or that mine was a good way to learn programming. Just mean to be giving a data point about the relative approachability of PHP and RoR for actually making stuff as a beginner.
Eventually, I heard about Sinatra, and decided to try it out. It's a great way to learn about web apps. You'll learn the HTTP verbs if you haven't already, and you'll understand the routing process.
When you jump into Rails, you'll already understand Controllers and Routers, since Sinatra is basically the router and controller of Rails combined. You'll probably learn about views too.
Basically, learn sinatra, then go to Rails.
Be able to put a <yoursolution>.<YourLanguageFile> inside any folder where your apache/nginx serves fiels from, then make your file give a much nicer file listing than the default of nginx/apache with possibility to comment on the file (using a __comments/directory and text file for each comment and sequence number as filename). Come back when you have to struggle with various "deployment" options in django/flask and .war files.
Deploying as PSGI would take, like, three lines of nginx configuration and wrapping the bulk of the script in a function.
PHP wasn't "designed" ... it evolved. Pieces were added, here and there, re-factored, deprecated, etc. etc.
PHP is a natural language. It wasn't fabricated at some university, nor in the lab of some billion dollar company. It evolved.
That is its strength. It is the most adaptable language around. It can be used for anything and it has been used for everything.
And that is why it is the most popular programming language.
Not popular with stuck-up pretentious twits who have nothing better to do than to offer their opinion to the world. No, it is popular with people who build things and get things done.
That's what it's for. To build. If the clown who wrote that article had spent as much time programming, as he did writing that drivel, we might have something useful to praise him for. Even if it was written in PHP.
That is its strength. It is the most adaptable language around. It can be used for anything and it has been used for everything.
Programming languages are not human languages. Programming languages are engineering tools. Would you cross a dangerous river on a shaky, lashed together bridge that had "evolved over time from a single plank"? Or would you rather cross via well designed, properly tested bridge, even if it was made from the same materials as the evolved design?
Anyhow, just something to ponder about.
Kind of like new programming languages.
And they put bridge designers beneath the bridge when legion crossed it for the first time. If we started to do equivalent for programmers, we would have much better code quality :)
And in regard to programming language design we don't have calculus, either. We're just experimenting, and trying to repeat what works.
That's definitely part of it. But the Romans really did care about engineering and took it seriously -- one of the earliest writers on architecture was Vitruvius. What did he say about buildings?
That they should be safe, functional and attractive, in that order.
> And in regard to programming language design we don't have calculus, either.
Church and McCarthy would like a word ...
We are all aware of that. We don't like that. Not because of its genesis, but because of the result of that process.
> PHP is a natural language. It wasn't fabricated at some university, nor in the lab of some billion dollar company. It evolved.
> That is its strength. It is the most adaptable language around. It can be used for anything and it has been used for everything.
You have to purposefully design a language that can't be "used for everything". And boy, the way PHP has "adapted" could be done by any language or designer or committee if they were just to lower their standards enough. But most haven't, and have adapted with more success. Why did PHP barely get (half-assed) closures just now?
> And that is why it is the most popular programming language.
Where?
(Though I think IHBT)
One of the reasons I hate Ruby is that nearly every person I've come across that likes it is exactly how you describe. It seems to be part of the Ruby culture.
They're clearly just potatohaters.
I'm sorry if you like using Ruby and the majority of the community are pretentious assholes. I will never use Ruby or Rails for any project.
I can tell I must have gotten a little too close to home.
No. That's it's weakness. Programming languages are not like natural languages. PHP did not emerge spontaneously from conversations amongst PHP programmers -- people actually sat down and wrote code. When that happened, they had the choice to exercise some degree of higher thought. They did not do so.
PHP is a perfect example of how local optimality -- slap on the first thing that "works" -- can lead to wildly suboptimal global outcomes. PHP is a system that is a constant state of partial failure.
> And that is why it is the most popular programming language.
This is demonstrably false. Folk didn't adopt PHP because of some hand-wavy, post hoc, revisionist bullshit about linguistic evolution. They did so because in the late 1990s it was not possible to run multiple mod_perl applications on a single Apache process, but mod_php could do so.
That's it. Perl's horse wasn't shod. The rest is merely a painful, expensive, misbegotten parade of path dependency.
When it comes to single factors explaining its success in the 1990s, the one I've heard cited more often is that you could embed PHP into HTML documents with the <?php ...> kind of deal, and a lot of shared hosts enabled that by default, making it by far the easiest way to get server-side scripting up and running.
Other languages have evolved as well; Python has changed significantly from it's earliest incarnations. And, during the time of early PHP, Python was a complete failure as web language.
The PHP bar for inclusion, for most of its life, seems to have been "it compiles".
I don't think it's possible to directly compare PHP and Python and not draw the conclusion that PHP was basically slapped together out of any old thing that came to hand without any degree of planning or foresight.
I'd say it's entirely unfair and incorrect to say the bar for inclusion has been "it compiles". Even some of the decisions made for PHP4, which I disagreed with, were debated endlessly.
Take, for example, the introduction of namespaces into PHP -- it got a lot of flack for using an additional character but if you study the design carefully it's nearly impossible for it work any other way in PHP. You might look at that and say there was no planning or foresight (or that it was simply the easiest solution) but that betrays the truth.
But when you've gone through 5 major versions over a decade, I don't think you can say, "Well gosh, it jes' growed that way." That takes it from "evolved" to "poorly planned".
Also, I wouldn't lean too hard on "most popular". Bud Light is the most popular beer and American Idol is the most popular TV show. "PHP: The Bud Light of programming languages" is not really helping your case.
Python, Perl and Ruby also evolved organically without (at least initially) the help of any corporate sponsor. Yet none of them are the pig's breakfast that PHP is.
I was starting to entertain the idea of doing a project in PHP, thinking it can’t be that bad. Thanks for convincing me otherwise. The inconsistencies you listed would drive me up a wall.
It does remind me of the Unix Haters Handbook (http://en.wikipedia.org/wiki/The_UNIX-HATERS_Handbook); I used to have my very own copy; I would read it and laugh and think how lucky I don’t have to use Unix on regular basis.
Of course, that was back in the day; now I spend a lot of time at the command line on my MacBook Pro.
And every language is designed. This one happens to be designed by committee, with all the attendant issues.
Also, nobody is arguing about whether it is popular. (Although, "most popular programming language"? What planet do you live on?) We are not arguing whether it can be useful. We are discussing whether it's a good language. Try to follow along.
You had some interesting points about pragmatism and emergent design, and then you had to go with this aggressive insulting bullshit. Come on, we can do better than that.