This is just another example of someone beating a dead horse (which has already been beaten) for page views. Next week we'll have another "bash php" post, and the week after that another.
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.
For someone coming from other language background, including C#, JavaScript, Ruby, I find PHP absolutely unconventional, odd, unexpected, and inconsistent.
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.
I'm not defending PHP, and I'm not claiming the author "has no right" to make their post. What I am saying is that this post has no value, as it's simply a summary of the same posts we see here week after week. This isn't just stating the obvious, this is literally rehashing the posts (he even cites the sources, which I do commend him on) that have already been made.
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.
To be fair, while the author is a friend of mine, he's not the one who submitted it, nor did I consult him before doing so. So if anyone can be claimed to be exploiting this for upvotes, it's myself, not him.
What I am saying is that this post has no value, as it's simply a summary of the same posts we see here week after week.
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.
Yeah, I'm tired of PHP bashing too -- BUT! -- this is probably the best written article on what's wrong with PHP that I've ever seen. So... kudos to the author for a good argument.
You probably also shit after a bad meal to get it out of your system, but although you may have convinced someone to not eat the chicken, the rest of the office has to deal with the terrible stench you left behind, when you could have just gone home and taken care of things in private.
Even if it's a dried up subject, the blog is comprehensive and concise enough to almost be reference material. Everyone knows PHP sucks but this is a damn good illustration of why.
Until people stop using PHP I welcome detailed critiques of the language. There are still enough PHP apologists out there that we can use all the ammunition we can get.
Why is it not good for the web? Unless an insecure website is leaking personal information, I don't see how that affects you. Besides, how many websites designed by newbies reach hundreds of thousands of daily visitors (or even tens of thousands for that matter)? If said website is so terribly designed, no one would visit it because it would load slowly and be ridden with bugs; no fun.
Because it's bad for the industry as a whole. Clueless managers are looking exclusively for PHP developers because all they know is that there are a ton of them around. Meanwhile, people who've mastered more powerful tools and can produce more work of higher quality are being excluded from contracts for trivial reasons.
People have been writing murder mysteries for the past hundred years, and some people are still writing murder mysteries, and some people write them in the hope of selling millions of copies. There’s nothing wrong, in itself, with writing about a topic that has been written about before.
A nice long list of things all concisely put into one blog - I'm sure this took some time to write. Can we move on though? Seriously - no one's forcing you to use PHP, so in your own worlds "It has paltry few redeeming qualities and I would prefer to forget it exists at all." do just that - forget it exists and wake up tomorrow a bit less grumpy. Trust me, you'll feel better!
You may be able to do some fancy (i.e. useful and profitable) stuff in another language and show it to your boss. Maybe do this in your spare time while learning another language for fun. It may impress them!
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. :)
Hm. I think my choice of words weren't adequate to describe my situation.
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.
There are those of us who have been forced to use PHP, and quite honestly, we could use a few good round-up posts of why there are better choices for a project these days than PHP.
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.
Oh! Do one on motherboard design next! Or the highway system of the eastern US. Or, as others already said, just realize it's warped beyond repair and hindsight is 20/20 for all involved. Very very very comprehensive post, but... yeah.
Well, you can't really much rip the US highway system off the face of the Earth, and I'm guessing that it's rather inconvenient to route around it, but you surely can not use PHP, and inform those poor misguided souls who believe that it's a standard, or the web's assembler (seriously, I've heard both of those personally!) or that it's, you know, good.
Little new functionality is implemented as new syntax; most of it is done with functions or things that look like functions.
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.
There's surely some middle ground, here. PHP defines constants with a function, creates functions with a function, creates data structures with a thing that isn't actually a function but is inexplicably designed to sorta resemble a function. Only now are these basic value definitions getting dedicated syntax.
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.
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.
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?
Well, if you take the engineering analogy in a somewhat different direction, you end up with all the structures we ever created before we mastered statics and material sciences. Those bridges the Romans built were evolved patterns based on trial and error of previous designs, where the last design was the testing.
Those bridges weren't continually "enhanced" by slapping on more stone and wood (at least not the ones that remained standing for long). Each bridge was a fresh design, based on the best practices of the day.
Survivors bias, I think. We just don't see all those buildings/bridges that collapsed.
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.
> PHP wasn't "designed" ... it evolved. Pieces were added, here and there, re-factored, deprecated, etc. etc.
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.
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.
Exactly! That's the reason I hate broccoli -- every person who tries to feed me it seems concerned that salt and vinegar potato chips are the only vegetable I eat. It seems to be part of their whole culture.
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.
> 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.
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.
Yep, trivial deployment model and trivial stack integration so every free host or ISP providing 20MB "web hosting" to users could give out PHP execution as well.
The implicit assumption here is that the world doesn't change. PHP comes from the world of Perl, C, and ASP/VBScript. Procedural programming, embedded HTML, etc. It's impossible to predict the future.
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.
Again, Python et al have not evolved. They have continued to be modified and refined by the deliberate application of thought, particularly the kind of insightful, discursive thought that programming language design calls for.
The point is, Python wasn't (and perhaps isn't) perfect. Mistakes were made. Fixes introduced. PHP continues to be modified and refined as well. PHP developers are hard working developers with a difficult job; I can't help but think you're being insulting to them.
The difference is that at each stage, Python's designers have exercised more global reasoning than PHP's.
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.
The problem is that many early design decisions were made when PHP was a small personal project with the goal of accomplishing something immediately. It wasn't intended to be object-oriented. But that was a long time ago. Many of the points made about PHP design are ancient decisions and difficult to change because of backwards compatibility.
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.
"It evolved" is a reasonable excuse for an 0.7 product, or an ecosystem like the Internet, where no single entity is in control.
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.
The prevalence of exactly this attitude is why we need all the informed PHP bashing posts we can get. It amazes me how eager people are to wear their ignorance like a badge these days.
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 love a good, high quality rant; this is a very good one. Kudos.
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.
Spend some time on the PHP developers' mailing list and watch exactly how the language evolves. You will lose that feeling of awe and reverence pretty quickly.
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.
If the clown who wrote that article had spent as much time programming, as he did writing that drivel...
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.
Since my day job is PHP-centric and I was already aware that PHP is awful, this is theoretically helpful to me, but oh lord, it makes my liver hurt.
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.
I can't believe that this is a real thing. The fact that a (purportedly) serious language runtime designed for web applications would have this in it seems like a staggering breach of professionalism.
"(And strictly speaking, Facebook isn’t written in PHP; it’s written in a C++ macro language with a striking resemblance.)"
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.
"Prosaic license"? If the essay was written in iambic pentameter, it certainly escaped me. Anyway, "C++ macro language with striking similarities" has a pretty precise technical meaning, which sane, literate people might actually mistake.
PHP as a language is, at present, defined by the behaviour of the canonical PHP.net implementation. Change the implementation, and de facto you've changed the language; Perl 5 is similar in this respect. A claim that an alternate implementation or tool chain supports _that_ very same language is a curious statement. It is an alternate implementation, and surely it must differ behaviourally, even if only by having unique bugs.
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?
Which canonical PHP.net implementation? They differ across minor revisions, in intentional and unintentional ways.
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.
This was the same argument I was having in my head, and in the end I couldn't draw a clear enough line between something like Jython and something like HipHop.
Does warts-and-all PHP include that eval wart, or is it more like most-warts-and-a-subset-of-all PHP? Not snarky, just curious if there was something I missed.
The HipHop compiler will optimize much, much more effectively if non-trivial eval() is disallowed, as it is in FB's production code. Obviously, since it's an ahead-of-time system, complex code in eval() will run slowly. The HipHop virtual machine is perfectly happy with eval().
Name one. I can't think of any that aren't better served by other constructs.
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.
"Name one. I can't think of any that aren't better served by other constructs."
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.
Even in the case of a REPL, what you want isn't "interpret this string as code in the language in which this program is written and apply it to the state of the currently executing program". What you're really looking for is "interpret this string as code in language X and apply it to the state of the given sandbox".
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: ")
Terribly insecure for webpages, sure, but very efficient use of my time.
I see no reason to use JavaScript to process my data files - keep in mind this is data post-processing of experiments, not a user-facing application. And I enjoy Python, so I'll stick with it. But thanks for the pointer to literal_eval, I have not explored that part of the standard library.
For some reason, I can't reply to colanderman's comment above/below, but Python's namedtuple is implemented using eval (technically it uses exec, but it's the same idea in Python).
I find it to be an interesting philosophical question about what defines a language.
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.
There used to be a generally accepted answer, which is that there were languages, and there were implementations of languages, and that those were separate things. C++ was not g++, and vice versa.
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.
They have an interpreted version of HipHop as well. Can't use the PHP interpreter due to a couple added features (python-esque yield is the only one I know of)
Somehow i find that very comforting that such a heavily trafficked site relies on it. I 'm a happy PHP programmer for at least 10 years. Not overly happy about it but in the end not disappointed about it. I haven't found an overall better alternative tool for the domain yet.
Hm, I'll admit I've spread a bit of misinformation on that matter myself, thanks for the correction. The source for my confusion (and I suspect others as well) was some comments around the time hip hop was made public that it basically wasn't worth using unless you were willing to put in a significant effort to write your php according to some strict guidelines. That made me peg it as something akin to pypy's rpython.
I seem to remember reading that Facebook was using XHP, which allowed XML literals. That would certainly be an improvement over "warts-and-all PHP", in my opinion.
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?
I enjoy Eevee's posts. I was first introduced to him through a handful of Pokémon sites where users would reverse-engineer the Pokémon games and protocols. He writes good code and knows his stuff. He even offered some assistance when I was writing a .pkm file manipulation package.
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.
My goal is to move away from PHP completely by 2013 for my websites.
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.
I agree that statically typed languages have a lot of advantages but I can't see much reason to use C++ for anything if you have reasonable alternatives. Why not Scala or Haskell or even just plain old Java?
Have a look at the OK Web Server[1]. It has a clever design that cleanly separates application and HTTP concerns and the default libraries are written in C++.
You realise that there are tools to get around the problems that you describe? Linters and automated testing will both catch the sorts of problems that you're having.
I got into the web space through WordPress and naturally progressed into learning PHP. There are times that I wish I could work with another language just as well as I can in PHP.
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.
> EDIT: note to self "-x points" = x many people with limited sense of humor or very old and don't get it.. /sigh..
HN is not a site where you just drop a meme image and walk away. Humor on the site is appreciated if it's contextually relevant and clever. This isn't Reddit.
I actually have to agree. I started out my programming experience with C# -> PowerPC (strangely) -> C++ -> touched upon PHP -> Java -> Python -> Objective-C. Out of all of these languages, Python was by far the easiest and most flexible language to learn.
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.
If I had to guess I'd say it's fear of the unknown combined with a reluctance to embrace new ideas on some subconscious level.
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.
I completely agree with all of the author's points, but my day job is still PHP and I actually don't hate it so much now.
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.
They say eventually you learn to love your captor.
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.
It's all fun and games until you want to find a string in an array.
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'm going to be unfair and quote just two words from the article:
> 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.
It's not awesome if the applications so developed by amateurs grows to store PII, financial information or do anything that has any security consequences whatsoever since it is likely to be riddled with "game over" security vulnerabilities.
Most applications developed by professionals in Big Freaking Enterprise Languages working in regulated industries will also have game over security vulnerabilities. Most applications developed by the cool kids in Ruby/Python working for startups will have game over security vulnerabilities.
The current state of information security: basically, we're screwed.
Agreed. While PHP apps are definitely more likely than others to be vulnerable to systemic SQL injection, XSS, and other vuln classes of that sort, all applications are equally vulnerable to things like command injection, authorization bugs, etc. No one gets that stuff right, and if you can execute code on the system, well, it doesn't really matter if you can't find SQLi.
Why is PHP more likely than others to be vulnerable to SQL injection attacks? Most people (and likely All newbies) will be using PDO which automatically protects them.
How do other dynamic languages (e.g. Ruby, Python) deal with this?
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).
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.
It's not a matter of preference: it's a matter of secure or insecure. The mysql extension for PHP doesn't support prepared statements and as such is inherently less secure than any other mechanism for working with MySQL (The mysqli extension and PDO being the two alternatives for PHP). But losvedir's point is that the number of tutorials that use the mysql extension's API far outweighs the number of tutorials that use PDO or mysqli, and that those tutorials are often very poor quality (ie: contain SQLI).
Actually, I agree with you and I think this is often missed as one of the main contributing factors to PHPs bad rep. If I had enough spare time (and a wider personal network of php pros to draw from) I'd love to make something like www.betterphp.org with short tutorials and guides teaching newbies the current best practices. As it is, anyone picking up PHP for the first time is confronted with a minefield of conflicting and out of date information, some of which is dangerous.
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.
PHP sites will have a hell of a lot more of them, though. You're not shielded against CSRF, XSS or SQL injection attacks unless you use a framework - at which point you're back to being a programmer with no "empowered amateur" in sight...
Interesting point, and I agree that PHP has some properties that make it easier for beginners to get started with (which doesn't necessarily make it the best language to learn with, but definitely an easy one). I wrote my first few programs in BASIC before I graduated to C. Like BASIC, PHP makes it easy to get something running quickly, and horrible to do anything more complex.
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.
I posit that one of our modern "Things You Can't Say" is that the widely-held belief that the world would somehow be better if every single average Joe learned to program just might be totally bogus.
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?
You can put up whatever barrier to entry you like. Invent a certificate for Haskell programmers with Ph.Ds. Require everyone who works on your website to have your certificate. Have fun.
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 if that's only true because we as a society don't (yet) hold people accountable for the code they write, in the way we hold them accountable for the bridges they build or the cars they manufacture?
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?
Even if hypothetically, such a barrier to entry was desirable, it's not viable to maintain one. It'd be treated as damage, and routed around. It's better in the long term to funnel people through something which teaches them the "right way" from the start, by making that "right way" easier than anything else.
I find it odd how many people keep saying it's that simple to push PHP code to a box and get it working. Sure, if you've got crazy simple requirements it's generally a cinch. Once you do anything remotely non-trivial (want to read from a file? use some third party library, handle errors in a consistent manner) then you start hitting into issues with file permissions, PHP version differences, modules not compiled in by default, etc etc. I've been dealing with PHP for a long time, and getting a local dev setup to match the remote version (or getting code to work on both environments) is just a pain to do.
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.
I think you're mistaken to assume the beginner even has such a thing as a local development environment. When first learning PHP I wrote all my code on a $10/month web hosts, saving directly to the FTP server.
Only later did I install a local dev (now made very easy with MAMP), learn about version control, PEAR etc.
Yes, this is why PHP is easy for beginners. The standard practice is to edit directly on the server. It's a hard habit for a lot of PHP devs to break. It's very straightforward and direct: Edit a file, hit reload, see the result live.
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.
Sure, if you've got crazy simple requirements it's generally a cinch. Once you do anything remotely non-trivial (want to read from a file? use some third party library, handle errors in a consistent manner) then you start hitting into issues with file permissions, PHP version differences, modules not compiled in by default, etc etc.
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.
I have a feeling you've gotten so used to deploying PHP that you've forgotten all the headaches involved in it. I idle in about 3 irc channels that provide PHP support, and pretty much every day someone comes in with some deployment related problem. Someone will come in complaining that they can't read some file (the user apache is running as can't traverse into that directory), complain about some missing function (did you install gd? -> show how to get phpinfo -> show how to install gd -> show how to modify php.ini to enable it -> show how to restart apache), or just general errors on their server (is your error reporting on? -> figure out what error reporting is locally -> figure out what error reporting is remotely -> explain how to change the setting -> etc.)
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.
I have a feeling you've gotten so used to deploying PHP that you've forgotten all the headaches involved in it.
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'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).
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.
And what "EXACTLY" is the problem with having a devlopment system that mirrors the live production one?
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.
I can attest to PHP deployment being an absolute nightmare. Of course, the difference is that we're not beginners here; far from it, really.
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'.
I don't understand how deployment, source control and not patching your live code have anything to do with PHP.
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.
I agree with you and I'm really surprised in 15 years, or how over old PHP is, THERE IS NOT ONE SINGLE ALTERNATIVE!!
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.
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.
We don't WANT to replicate PHP's deployment model! It's hard to scale, it's hard to configure, it's hard to secure, it's hard to make work across different web servers. It's convenient for newcomers, sure, but even for something like phpbb the model is strained. We need better deployment tools, not worse forms of deployment.
mod_python was notoriously unstable and is now disgustingly obsolete, it has been replaced by mod_wsgi for some years now (with the additional advantage that apps which work on mod_wsgi will work on many other servers).
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
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.
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.
Instead of blaming "the other communities" blame the web hosts which decide that they only like to support PHP out of the box. Many other languages can be made easy to deploy on shared hosting, it is up to the host to actually do so. Nobody can force them.
> You can get really excellent, easy $10/mo Python hosting...
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.)
Webfaction[1] is really quite good, and well inside your budget. It's shared hosting, but it's good shared hosting, and they're very Python friendly. One click to create a Django app, and you can easily install your own frameworks and stuff. Depending on what your neighbors are doing you may get varying performance, but what can you do?
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>)
The Perl equivalent to the PHP model (request handler entry point is already your template) is called Mason. It's had a pretty huge customer for about a decade now.
I can't really fault anything that was said in the article. What left me wanting was the ending. I was expecting the equivalent of the main character happily walking into the sunset. In other words, something akin to: "And now that we have established why PHP sucks let me tell you what I use and why. I use <language/languages>. Here are all the reasons for making these choices:"...
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.
Ha, I actually avoided doing this so as to not sound like a shill for better-thing-X :)
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.
As someone who goes to PHP when he needs to program for the web, and has been doing so for some 13 years now, seeing the horse beaten again didn't move me. I can't say I spent much time on your article, mostly because at this stage of my life, focusing on the negative doesn't earn you anything.
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. =)
PHP doesn't really have any strengths any more. The last one was ease of use and setup, but nginx and FastCGI seem to have beaten that too. The only things keeping it around as far as I can see are:
* 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...
First, do not assume that I only know PHP. I enjoy Python, and in fact, Erlang as well. =) Erlang is an especially nefarious little devil in that it almost makes me giddy with how it forces you to think.
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.
I see your point, but it's the same point that every other pro-PHP person has made. PHP lets you get stuff done fast... but in a few weeks (or even days depending on the person) Python and Ruby will have overtaken you, because all of the tutorials out there teach you to build a giant pile of insecure spaghetti hacks.
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.
I don't think you do. Are you really saying that introduction to python should be about REPL and basic syntax, and not accomplish an actual goal?
> 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.
You're making a lot of assumptions about what I am and am not saying. Check my profile if you want to see how I think Python should be introduced (hint: by doing actual stuff).
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.
Every time someone does that, the argument gets derailed into talking about the other language and into a not-actually-related argument about its problems and the relative merits of the two languages and so on. You've seen it happen a zillion times. When the article is just a headshot on PHP, it's easier to get the point of "don't use PHP, use anything else" and PHP ... "apologists," like folks upthread, can't derail it into talking about the problems with Python/Ruby/whatever.
I admit, PHP sucks. But there is one thing it has going for it. It's simple to configure and secure a server that your general userbase can run applications on. I work at ITECS, the Engineering IT department at NC State University. ITECS is responsible for maintaining the server infrastructure for dozens upon dozens of university Web sites, most of which have dynamic content. Not to mention the people server, which anyone affiliated with the College of Engineering can get directory space and a MySQL database on.
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.
Whoa. Definitely don't run Python as CGI. Use WSGI, run your app as a devoted low-priv user, proxy to it. Then you have only one entry point; there IS no sandbox, and nothing to exploit.
I agree. Why not run the webapp as the user account the code belongs to. With virtualenv and pip, normal users can install modules into their own site-package in their home folder, and any runserver started as them will only have permission to access anything they have access to. The only thing that is possible to exploit is what they've allowed in their code, but that's pretty much the same issue you have with php.
Because (a) mod_wsgi is nowhere near as easy to sandbox as PHP (again, php.ini settings), (b) configuring proper production servers to run as specific users is a pain, and (c) this is a university where people have access to sensitive student information and research data in the AFS system. How bad do you think it would be if a random student could exploit their professor's site and change their exam grade?
That's odd, because usually servers get owned from faulty wordpress/joomla instances. I rarely hear of web servers getting rooted via web apps run on python. I'm not really an experienced php dev myself, and when I installed joomla on my vm last year, it was rooted within the hour -- I was notified by a data center admin saying my vm was using an insane amount of bandwidth. I'm sure it was some script scanning for boxes with slightly old versions of joomla. I haven't had the same kind of bad luck installing python apps.
The PHP on our servers is also ridiculously locked down due to a combination of php.ini sandboxing settings including open_basedir (which AFAIK no other language has out of the box) and very strict AFS permissions (the server only has access to your specific Web locker, and it only has write permissions if you specifically enable them in the locker portal).
Don't complain about it, simply don't use it. The language seems to be good enough for some of the largest sites out there to use it as their primary langauge.
These complaints are all well founded and researched. They serve as an education on what not to do if you're working on any computer language or applications with an API that are used by others.
"Good enough" is not good enough. COBOL was "good enough" for many companies. We can do better, and we should try to.
I had a one-to-one talk with Rasmus Lerdorf a few weeks ago. This is one of the few things he said:
"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.
As far as I understand it, the real tragedy is that PHP as used at scale. PHP as Lerdorf intended it was the quick fix, the we-need-to-get-it-done-now fix. And then that fix grew and grew until the things that PHP fixed were eclipsed by the things in PHP that needed to be fixed--but PHP was already too big to be fixed; people were using PHP not just for fixes, but for everything, and to fix everything would break everything... And that's how we got here. Because nobody will understand your intention when your code is on the screen and the intention can only be inferred from someone who is not in the room with you.
Popularity doesn't determine how many design flaws exist in a language, merely how many people actually get screwed over by each of them. Python and Ruby aren't perfect, and they've had more than enough attention for the flaws to have been found. Even if every developer in the world migrated to one of those languages overnight (o happy day) that language would not suddenly become as profoundly inept as PHP.
Sorry, there is no audio/video of it. This was supposed to be just a casual chat, but it turned out to be an incredible exchange of more than one hour. I wasn't prepared to record the conversation, but I wish I had.
There is a quote from Bjarne Stroustrup saying along the same line...
“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
"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.
Well, that's coming from the perspective of someone who doesn't like "private" in the first place; it forces me to rely on whatever use cases the author has imagined and makes extending the class in a novel manner a pain. Except this is PHP, so I can just go change the "private" to "public" anyway.
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 forces me to rely on whatever use cases the author has imagined and makes extending the class in a novel manner a pain
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.
The argument there is that your tests are telling you that your code has the wrong structure, so if you need to be getting at private methods in your tests, those private methods could be public methods on some delegatee you inject into the class under test.
I'm not convinced this is universally applicable, but I'm otherwise sympathetic to it.
I'll preface things with, I don't care about the cleanliness/consistency/correctness of languages, I really just care about tools to get a particular job done.
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.
You know, with Microsoft people using node.js, Microsoft is actually really friendly towards JavaScript at the moment. They have made proper JavaScript debugging tools and Visual Studio integration!
PHP was designed by people who neither knew, nor cared what the hell they were doing, but knew they wanted something to do what they wanted to do. In that sense you cannot blame PHP for being a huge wasteland of terrible design just as you cannot blame a blind man for not being a great painter.
That being said, thank you for documenting why nobody should ever seriously use this language unless it's absolutely necessary.
It would be nuts to consider starting a brand new, dependency-free project in PHP today for all these reasons and more. If the reason for doing that is "all I know is php", well, now you have two problems.
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.
Meh, I've written a lot of PHP code. I also work in Ruby and Python. All three have problems, but I like all three.
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.
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.
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.
Catching exceptions and returning a 200 OK blank page is about the worst thing that PHP is doing. A simple error can trash your google index (Oh, page replaced by blank content, fine!) or mess up API communication when the receiver does not explicitly check for the response content (POST to endpoint, 200 OK, ok, nice). And while you can catch and handle some of those errors with your own error handlers, there are error classes that you can not handle and which will always be handled internally. It's a pure mess.
I understand fail fast, and errors do still get logged and made visible (New Relic is great like that). I would rather fail a bit slower, silently, though. It's much less jarring to users, and therefore you lose fewer.
It's less jarring for the users that you have to tell them weeks after they entered some important data that all this data has been lost? Is it less jarring if they order something and the order confirmation does not arrive and they don't know whether to try again or not?
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.
Lets say for someone who is new to PHP, how long does it normally takes to learn where the minefields are? Is there anyway to start on this? I know in JS there is Javascript The Good Part. Is there anything equivalent in PHP?
Hm, not that I know of. The biggest thing is to read about PHP's security issues (especially how to avoid SQL injection attacks). After that, it's mostly writing code in it. If you start by writing PHP like you'd write C and then branch out, you can figure it out. Stay away from running anything shell related from your PHP code or anything that manipulates the file system unless you know what you're doing. If you're doing anything that's very critical to your users, I'd probably do it in a different language.
513 comments
[ 3.0 ms ] story [ 296 ms ] threadI 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 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.
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.
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.
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.
http://www.0php.com/php_easter_egg.php
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.
1. http://www.php.net/manual/en/ini.core.php#ini.expose-php
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.
Terribly insecure for webpages, sure, but very efficient use of my time.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?
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'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.
[1] https://github.com/okws/okws
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 feel there is more important stuff for me to do with my life than worry about the structure of a common language.
I actually think you answered your own question :) A love of simplicity is as meaningful as a love of good structure, consistency or design.
I envy your ability to -not- want for something better.
HN is not a site where you just drop a meme image and walk away. Humor on the site is appreciated if it's contextually relevant and clever. This isn't Reddit.
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.
are you saying that Python is easier to learn than PHP
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.
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.
> 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>)
[1]: http://www.webfaction.com
[2]: http://www.webfaction.com?affiliate=chaos
http://www.masonhq.com/?AmazonDotCom
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.
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.)
"Good enough" is not good enough. COBOL was "good enough" for many companies. We can do better, and we should try to.
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."
"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
"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.
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.
That being said, thank you for documenting why nobody should ever seriously use this language unless it's absolutely necessary.
http://www.reddit.com/r/PHP/comments/rh3u2/any_new_major_sta...
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.
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.