
Coding Horror: The PHP Singularity - prajjwal
http://www.codinghorror.com/blog/2012/06/the-php-singularity.html
======
dasil003
The irony of this post is boundless.

> _Except now it's 2012, and fellow programmers are still writing long screeds
> bemoaning the awfulness of PHP!_

Yes, and not only did Jeff write one in 2008, but he wrote another one just
now. You can't write 10 paragraphs about what a blight PHP is and then pretend
like you're being constructive by admonishing us to create better tools.

In fact what everyone is doing with these rants is bike-shedding about an
easy-to-hate language. It makes an easy topic that drives a lot of traffic
because everyone has an opinion. It's just tabloid garbage for the hacker set.

A more objective view of things is that PHP is a capable-if-ugly language, and
it co-exists just fine with thousands of other programming languages and
frameworks all with their own visions, communities, and production
applications. The existence of PHP is not harming other "better" languages at
all. And if you really want to make an argument about languages hurting the
state of programming, how about asserting that the dominance of imperative
languages is irreparably damaging the ability of most programmers to work in
functional languages where solutions are fundamentally more robust. Or what
about the damage that proprietary platforms like .NET (which Jeff uses if I'm
not mistaken) or iOS do to the programming world by restricting progress to a
single company.

I won't belittle Jeff's contributions to the software world, because Stack
Overflow is an amazing service, but despite the fact that I hate PHP, Rasmus'
contribution to the software world is certainly much more important than
Jeff's feel-good blog fluff.

~~~
mishkovski
"Or what about the damage that proprietary platforms like .NET (which Jeff
uses if I'm not mistaken) or iOS do to the programming world by restricting
progress to a single company."

PHP is used for web development. Microsoft's best alternative for web
development is ASP.NET MVC which is open source.

~~~
dasil003
No, PHP is a language with some framework-like aspects. Your nitpicking is
quite poor.

~~~
mishkovski
I'm just saying that Microsoft offers tools(languages or frameworks) for web
developmet that are open source. And yes you have Mono project also.

------
CJefferson
As time goes by, I think the time to get started in a new system (which for
PHP is almost 0 time) is one of the most important things.

The problem is that the developers of rails / grails / Wt / SproutCore / Flex
/ Struts / GWT / Django / Flask / Zope / Merb / Zotonic might be sure their
framework is the greatest ever, and clearly worth a couple of days (or even a
couple of hours) of someone's time to get it all configured and get started.
However, I just see this giant list of options, each of which is in it's time
the 'best thing ever'. How am I supposed to know which one to choose? Getting
people started quickly and easily should be priority 1 if you want more users.

EDIT: Oh, one other strength of PHP. Many people when they start want to turn
a static website they already have into a dynamic one. This is how I started
on PHP, just including fixed headers and footers in a website. Then slightly
customised headers which knew which page I was currently on. Then adding
cookies to remember what users had already done. Then finally full user
support.

In general, one thing PHP excels at adding the '1% dynamic' to an existing
static website. However, I don't think this is as big a market as it once was,
I don't think that many people learn a lot of HTML and make big static website
anymore, then try to add dynamic elements later (or perhaps, I just associate
with different people nowadays)

~~~
mgkimsal
Another part of what makes something "best" is... size/scope of developer
community. PHP quickly gained a foothold, and, for better or worse, continues
to be popular in part because it's popular. I don't mean that as an insult at
all, but it's a continued factor. If tomorrow everyone stopped releasing open
source code for PHP, it would gradually die off in several years while people
transitioned to alternatives, and we'd end up with some other 'largest
minorty' tech/stack getting a lot of attention.

You're right about the 1%, and it's why classic ASP did as well as it did for
a while too, until that was killed off. The fact that big players who once
scoffed at PHP now embrace it (MS is a big one) shows how big PHP is and will
continue to be for the foreseeable future Will PHP be here in 3-5 years?
certainly. 10 years? possibly, but with a difference at least as big as php/fi
-> php5 is, so current php5 skills won't really be of much use on their own.

------
bobsy
Sorry Jeff. The only thing broken with PHP is you (and other people like you).

How much PHP do you use Jeff? Lets assume none. How is PHP hurting you? I mean
seriously, how much contact do you even have with PHP?

PHP is easy to learn, easy to make websites with. There are a tonne of paying
jobs which require PHP. PHP runs a lot of websites.

I am a PHP developer. I prefer Python but my PHP job pays me just fine. There
are a lot of things about PHP that I don't like but it gets the job done just
fine. You can write reasonable code with PHP. You can write secure code with
PHP.

The main people who have problems with PHP are either ex-PHP developers who
usually have gone on to Ruby and look back and fire a few shots at PHP. Or
people like Jeff Atwood. Undeniably smart and talented programmers who for
some reason are irked by the mere existence of PHP.

Please get over yourself.

~~~
billpatrianakos
"I prefer Python". Why did you say that? To me it feels like you said it do
people would take you seriously as a "real" developer. Because surely a "real"
developer wouldn't actually enjoy using PHP or use it unless they were forced,
right?

I agree with your point and I just wanted to add that the fact that we have to
add in little details like "I prefer Python" just to be taken seriously says
more about hacker elitism than it does about PHP.

~~~
polyfractal
_"I walk to work because there are no bike paths, but I prefer biking."_

Why did you say that? To me it feels like you said it so people would take you
seriously as a "real" biker. Because surely a "real" biker wouldn't actually
enjoy walking unless they were forced, right?

------
Loic
From the post:

> _build compelling alternatives and make sure these alternatives are equally
> pervasive, as easy to set up and use as possible._

A bite later:

> _We've got a long way to go. [...] The best way to fix the PHP problem at
> this point is to make the alternatives so outstanding that the choice of the
> better hammer becomes obvious._

Basically, Jeff just agreed that PHP is simply better than the rest. The
problem is that he cannot accept that thanks to PHP anybody can code something
pretty fast. I am always amazed when I see my brother, without programming
knowledge improving his wife website like gardening. Small changes here and
there. End at the end _the website is making money_. He never complained about
the " _awfulness of PHP_ ".

~~~
cageface
_Basically, Jeff just agreed that PHP is simply better than the rest._

Easier != better. Nice try.

~~~
polyfractal
Debatable. What's your end goal? If your primary goal is making money (through
the web) and you are non-technical, easier does in fact equal better. The GP's
brother isn't going to stop what he's doing and learn Ruby so he can rewrite
his whole website in gloriously succinct and elegant code.

He's going to tweak his site, continue making money and stop caring about
whatever the hell his site is written in.

~~~
cageface
Life is full of tempting shortcuts. Take them at your peril.

~~~
polyfractal
Well that's basically saying nothing at all.

Again, from the brother's perspective, perhaps learning Ruby is the tempting
shortcut ( _"I'll just learn this awesome language first and my website will
be super easy to upgrade and modify"_ )

...

and then it takes him too long to get back to his website, which has
floundered and is no longer popular or making money. Or ruby was too hard for
him so he went back to tweaking his site with PHP. Or <whatever>

My point is that it is all about perspective, something that a lot of HN
misses. Not everyone cares about technology. Most people just care about
getting the job done and making money, using whatever tool is _easiest for
them to personally use, at the time they need to use it_. So to that guy, it
isn't a tempting shortcut: it's the best route to prosperity.

~~~
dpritchett
Simple versus easy [1]. Getting started with minimal friction is a great
virtue for the beginning of a project's life, particularly when it allows
amateurs to produce something of value. Software development professionals
with stronger requirements (reliability, maintainability, ease of code
reading) are not always going to reach for the easiest tool. There's a reason
most of the software on your machine isn't written in Visual Basic.

The people who prefer PHP are right. The people who avoid PHP are also right.
They are solving fundamentally different problems.

[1] <http://www.infoq.com/presentations/Simple-Made-Easy>

------
xd
Hey Jeff, let's throw down the gauntlet. You're obviously an experienced
developer. I've been in the game for over 11years so should have enough
experience to tackle you on this bigoted rant.

You choose a problem that you think PHP can't solve[well]. You solve it using
your high level language of choice and I'll solve it using PHP. Let's compare
the outcome on reliability, ease of re-factoring, speed, whatever .. then,
when it becomes apparent that there is little in the way of difference of the
end product let's stop the fucking childishness.

~~~
seiji
Congratulations! You just Blub Paradox'd yourself. At this point in your
knowledge cycle, you are unable to understand something more complex than what
you already know.

Knowledge is power. Defending your own knowledge by refusing to expand and
learn something new is cutting yourself off at the knees (or fingers, as it
may be).

~~~
xd
I'm sorry, but at what point did I say I was refusing to "expand and learn
something new"?

~~~
prodigal_erik
The subtext of your challenge is that no language could possibly exist that is
substantially better than PHP at expressing a solution to any problem, which
would mean there's little to be gained by learning anything else. That's not a
claim I'd ever make about my favorite languages, even though nobody makes huge
lists of indefensible design gaffes in those.

------
alinajaf
Cue legions of PHP drones blubbing about how it does the job just fine, it's
available everywhere and how it's used by Facebook and half the internet. We
get it. We used to be PHP developers too. We took the time to learn other
languages and now work with them. We enjoy our jobs significantly more than we
used to. You might too.

~~~
jrgnsd
I'm a full time PHP dev. My work is in PHP, my personal projects is in PHP, I
even have a PHP framework (like everyone!) that I maintain.

Yet I thought this post was right on target. I'm busy cleaning and finishing
up my PHP projects, and then I won't start another project in PHP. It will be
ruby or python, or maybe I'll go functional. It depends on what I want to do.
Yes, I can say everything that you so sarcastically proposed, but I also see
the value in getting new coders to _not_ start off with PHP.

~~~
alinajaf
Good for you! In my case I moved to ruby but I would imagine the transition is
similar to other languages at a similar level of abstraction. I went through a
long phase where I was trying to bring patterns from ruby into PHP.

It got to the point where whenever I sat down to write PHP, I would write it
in ruby first as a sort of pseudo-code, then expand the brackets out into PHP
after the fact.

Eventually I decided that I would be more efficient just skipping the
expanding out step.

------
mgkimsal
"make the alternatives so outstanding that the choice of the better hammer
becomes obvious."

There's a lot of _frameworks_ that make many types of web site or web app
development easier than PHP. There aren't any _languages_ that were created
_explicitly_ with the goal of being used to create web pages (and later, by
extension, web sites). OK, there might be a few that have gone by the wayside
(ihtml, htmlos, etc), but nothing mainstream.

PHP is "content-type: text/html" by default, which can be overridden for other
tasks. Everything else needs to make some adaptation (however subtle) to
'play' with HTML. Potentially something like mod_ruby or mod_python could take
off, but probably not even then, as you'd be worrying about including base
library stuff or extra modules, the majority of which are already baked in to
PHP (gd, etc).

You have a web page up and just want to add a dynamic copyright date to the
bottom? Copyright <?=date("Y");?> and change extension to .php (or play with
some mod_rewrite rules on apache). Want to capture the output of every HTML
page and rewrite some links (while logging those changes to a db?)?
automatically prepend a php ob_start() call then append an ob_get_clean()
function in the footer, then process away.

Doing these sorts of things in any other tech stack requires a lot more
configuration and meddling, or possibly rewriting core site code. PHP can
scale down to be nice additional decoration in a site, or can power the whole
thing soup to nuts (and can scale up much easier than some other platforms can
scale down).

Related: I recently had a basic site and needed to rethink it in terms of
mobile toolkit. It was much easier to take what I had an add in jquery Mobile
stuff than it was to work with Sencha (as one example) because other tools
like Sencha assumed I was starting greenfield, which I wasn't, and I didn't
have time to learn enough of their stack to try to extract the bits I wanted.
jQuery made it easy to add the bits I wanted, and PHP does that for
HTML/serverside aspects of things as well.

------
citricsquid
I'm a php user. I got involved in programming because I wanted to control my
websites and build new ones.my first exposure to php was through modifying
open source platforms (eg Wordpress and phpbb).

Want to kill PHP? Build alternatives to PHPBB, Wordpress etc that compete on
ease of use (incl installing, that means have host gator etc support the
language used) and PHP will slowly die out.

~~~
mgkimsal
agreed. i don't think many other non-php supporters _get_ how ubiquitous PHP
(and even has been, for a decade or so) in terms of coming pre-installed
everywhere. And apps - yes, have replacement apps that play nicely in shared
hosting environments without requiring 30% of the machine's RAM per user/app,
and you'll see a replacement.

------
anthonyb
Oh great. Another PHP article, where we get to watch all of the defenders of
Rasmussen's misbegotten spawn come out from under their rocks...

    
    
      "PHP works great for me! It runs tons of websites! I don't know what you're complaining about..."
    

To address the article's point somewhat - there are already easy to deploy
frameworks and languages for the web, and everybody who cares about
development is already using them.

~~~
Isofarro
Who's Rasmussen?

> there are already easy to deploy frameworks and languages for the web, and
> everybody who cares about development is already using them.

And yet, amongst your rhetoric, you've conveniently managed to name none of
them. Is this an appeal to the silent majority?

I'm convinced that there are really good developers out there who just keep
building great products in PHP. Good developers write good code largely
irrespective of the language. The code is a mere artificial interface between
the developer and the machine.

~~~
anthonyb
> Who's Rasmussen?

Brainfart. I meant Rasmus.

A programming language is a _tool_ to get the machine to do what you want. A
_good_ tool will help you get the job done faster, and with fewer problems
(like, say, security holes). It's not a "mere artificial interface", and if
you think so, feel free to go write a web server in Brainfuck.

------
methodin
This rant boils down to a tweet "If you don't like PHP then use another
language or build a better one". What a revolutionary concept! That has worked
wonders for languages since. Except not one has come out that is as simple as
PHP thus PHP will continue to exist. Everyone that invents a language now
focuses on abstract concepts that do not help the everyday developer do
anything useful. Is it so shocking it's still around? If these rants are
supposed to be rally cries they are really just awful attempts. Who wants to
follow a whiner?

~~~
SideburnsOfDoom
> If you don't like PHP then use another language or build a better one ...
> Everyone that invents a language ...

But he said nothing about "inventing" a language. In fact said _very_ clearly
that he wanted to take an existing language and add to it - particularly the
things that PHP _does_ do well.

from TFA:

> "to buff up a open source language ecosystem such that it can truly compete
> with PHP in ease of installation and deployment"

~~~
methodin
If an existing language already has potential to replace PHP then I don't see
why it wouldn't have already. What would/could you tweak that would get you
there without fundamentally changing the language capabilities and syntax?

~~~
Rust
Setup costs - PHP has a low barrier to entry in the sense that Apache's
mod_php5 is a simple "a2enmod php5" command away. Even PHP-FPM with Nginx is
only a few well-documented configuration options away from working.

Currently, no other language can match that. They either require a VM running
(Java, Ruby, etc.) or at least have a compile/build step (Python).

UWSGI has a lot of promise, but until it's as easy to get configured as PHP-
FPM, PHP is still way easier than everything else.

------
mmuro
I just don't understand why this is a problem. If the goal of a web language
is to _build websites_ then JUST BUILD WEBSITES. Who honestly still gives a
shit what you build it in?

If you are into .NET and build .NET sites, then cool. I work with a bunch of
WordPress sites and WordPress uses PHP...so that's what I use. Until they
decide to switch languages, I'm sticking with PHP. Until then, shut the fuck
up and let me work without making me feel like an asshole for not conforming
to your way of doing things.

------
kator
I've been coding for nearly 30 years and have seen this rant for every major
language I've coded in. The reality is there is no perfect tool even in
construction as Jeff tries to draw parallels to you will find that many
different tools are required for many different situations. Often a hammer can
be used to make a hole in a wall and other times you use a saw to cut a nail
head off and just pound it into the wall because your hammer has a broken
claw!

Tools evolve over time and saying screw drivers are useless and everyone
should use a battery powered screw driver doesn't change the fact that a screw
driver drives screws.

If you don't like the tool move on to other tools or make your own and get
people to adopt them. Don't bash the brilliant people who worked hard to make
the tool in the first place.

My father is 71 years old and codes in PHP! He was never going to learn
python, ruby or anything else but PHP was approachable for him. Provide a
language with that low barrier to entry and let's talk. Meanwhile I love my
dad but we won't be writing the next google and that's ok by him and I both.
If he wants that he'll ask me to write it in COBOL! :-)

~~~
iwejfweoifjweif
Why is python or ruby too hard for your dad to learn? If anything I would
think something like ruby would be even easier than php since things are a bit
more consistent.

I just don't see how PHP is more approachable, especially compared to the
supposed ease of ruby on rails.

~~~
drivingmenuts
Try getting Django to run on various hosting sites. Dreamhost - been with them
for ten years, gave up trying to get Django to work after a month of poring
thru the docs, trying to get tab A into slot 3x. Mind you, I really like
Python, but it's not worth the effort for a couple more years.

PHP is the A-10 of languages. It's a slow, ugly and easy target. It works
pretty much everywhere.

~~~
mnutt
For pretty much every language these days, there is a hosted service that will
handle deployment for you, and you can just push code to them and they'll take
care of the rest. Better yet, they're _perfect_ for beginners, who usually
don't know much about database tuning, firewalls, etc.

~~~
drivingmenuts
Which kind of leaves me not understanding _how_ it's deployed, etc., which I
kind of feel like I need to know.

There isn't any one perfect solution, just workable ones.

~~~
mnutt
Yeah, but the average person doesn't really understand how their PHP is set up
either. It was done for them, or they copy and pasted some instructions.

Perhaps it's best if you either completely take deployment into your own
hands, or you let someone else do it for you. Given all that, rolling your own
could still be made simpler.

------
kaffeinecoma
Everyone's jumping on the PHP bashing. I don't think that's what this blog
post was really about. Did you read to the end?

    
    
      One of the explicit goals of my next project is to do whatever we can to 
      buff up a ... particular ... open source language ecosystem such that it can
      truly compete with PHP in ease of installation and deployment.
    

Kind of a cliffhanger ending... What are you building, Jeff?

~~~
innerspirit
Whatever it is, it better be fucking perfect after all that. This post is PHP
bashing with a cherry on top. But mostly PHP bashing.

------
cletus
I seriously groaned when I saw this post (title).

I was expecting an elitist diatribe about PHP (because this is perennially
popular amongst particular programmers) but that's not what this post is
intended to be.

Interestingly Jeff does take the usual potshots at PHP almost like he thinks
he'll lose street cred if he doesn't but the basic message I agree with: if
you want someone to stop doing something you consider undesirable give them
better alternatives.

That being said, I simply disagree with the premise. PHP has a lot going for
it:

1\. The CGI type model of creating everything, servicing an HTTP request and
tearing everything down is a powerful one (and used in Python, Ruby and
elsewhere). Once you go stateful (eg Java servlets) you have to worry about
resource leakage;

2\. PHP has a stateless core of API functions. IMHO this is basically ideal
for Web programming given (1). It makes startup/teardown cheap and reduces
resource usage (making it cheaper to provide for hosting);

3\. Imperative programming is IMHO a natural fit for Web programming. One
thing that's wrong with PHP is all the bloated OO mega-frameworks people
create on top of it to try and make it Java, Rails, whatever; and

4\. Inline code in HTML is a powerful technique. The learning curve for PHP is
quite gentle.

So if you want to make a better PHP (something I'd encourage anyone to do
rather than simply jumping on the PHP hating bandwagon) you should tick all
the above boxes. Of course if you do this, you will probably want to fix some
of the following:

\- argument order consistency

\- API function naming consistency

\- default to HTML escaping on output

\- effectively default to SQL parameter binding

\- no register globals

\- and so on

Side note: all of the above is well known. Pointing it out in yet another PHP
hating blog post is both pointless and boring.

Jeff also asserts that PHP's popularity is sheep mentality. What nonsense.
(1)-(4) above explain it far more than that, particularly the cheap hosting
and inline coding.

I like to point out that 4 of the top 20 sites are built using PHP (Facebook,
Yahoo, Flickr, Wikipedia) so--like it or not--it must be doing something
right.

Homer (Simpson) once said "sometimes the only way you can feel good about
yourself is by making other people look bad and I'm sick of making people feel
good about themselves". I see a lot of that with (us) geeks but it's just so
unproductive and pointless. You don't need to hate on "not X" to justify your
choice of "X" (X = Python, Ruby, Lisp, Clojure, Scala, GPU type, phone type,
tablet type, camera type, you get the idea).

EDIT: as far as Facebook goes, they didn't "give up" and use HipHop, they
decided to have their cake and eat it too. They get the productivity benefits
of programming Web pages in a "fit for purpose" language while getting most of
the performance benefits of native code and they only had to give up some
small subset of PHP to do it.

If you argue the subset thing is a problem try working in any C++ shop where
using only a small subset of the language is _de rigeur_.

~~~
ars
> default to HTML escaping on output

??? Is that a joke? Don't do that! That's just as bad as magic quotes.

> no register globals

It hasn't existed for a quite a while now in PHP.

Other than that I quite agree with what you wrote.

Most of the criticism of PHP is simply a desire to be special. If lots of
people are using something, you want to make sure not to, so that you feel
special. Now that you've decided not to use it, you need to justify it to
yourself. And people find all sorts of real criticisms in the process - yet
none of them matter!

~~~
gecko

        > > default to HTML escaping on output
        > ??? Is that a joke? Don't do that! That's just as bad as magic quotes.
    

Microsoft's Razor and Python's Django templates have both shown that HTML-
escaping-by-default can be cleanly done in a way that is not magical and that
is highly reliable. I'm not honestly sure what you're protesting here.

~~~
ars
If I make a string: '<P>' . $var . '</P>' - does it know to encode the
variable, and not the entire string?

What if I assign that string in a variable, and then output it later?

I'm not convinced this can be done well. Maybe if all you do is make some
templates and fill them in you could do it. But I do a lot more than that, I
output dynamically built html all the time.

Just give people a very easy and shortly named function for escaping.

~~~
eru
Just needs a bit of type system magic. Don't use the same type for escaped and
unespaced strings. (And don't use the same type for user generated input
before and after it's scrubbed / escaped of any nastiness.)

Ask any Haskell weeny for details.

Also in your example, you'd probably be better of, if your language knew about
the HTML structure, e.g. something like P($var), instead of putting the tags
in as strings.

~~~
derleth
> Don't use the same type for escaped and unespaced strings.

And if you can't extend your type system to make this work, do it in your
head, mutating the names of variables to help you keep it straight. For
example, esStr and unStr are not of the same type, and moving data from one to
the other without conversion is always an error.

~~~
nradov
This reminds me of Charles Simonyi's classic article on Hungarian Notation. I
know that style gets criticized a lot, but that's usually when it has been
used inappropriately. If you have a language with a weak type system then a
sensible variable prefix convention can help a lot.

[http://msdn.microsoft.com/en-
us/library/aa260976(v=vs.60).as...](http://msdn.microsoft.com/en-
us/library/aa260976\(v=vs.60\).aspx)

------
waffle_ss
_When you don’t create things, you become defined by your tastes rather than
ability. Your tastes only narrow and exclude people. So create._

\- why the lucky stiff

~~~
nollidge
I will always upvote/retweet/point and jump at this quote when I see it. One
of the most important lessons anyone can learn.

------
corford
I'm a PHP guy (started in the PHP3 days) and a few weeks ago I decided to
finally have a go at building a non-trivial site using uWSGI, Flask,
sqlalchemy and mongrel2. I knew a bit of python (from having written a few
trivial sysadmin related scripts) but apart from that I was starting cold. I'm
now a few weeks in and while I'm not ready yet to jump ship back to my PHP
comfort zone, I can say I've been surprised to find that Python (one of the
"better, grown up" languages that's always cited in these PHP bashing threads)
has quite a few warts of its own:

\- Packaging in python seems to have been a nightmare up until quite recently.
It appears things are a little more sane now that pip is emerging as the new
standard but there's still documentation all over the web referencing
easy_install. Of course, then there's distutils2 to muddy the waters...

\- The Python 2 to Python 3 transition was and continues to be an almighty
upheaval. At the moment huge swathes of the python ecosystem have yet to
introduce python3 support (e.g. Flask).

\- Virtualenv is a fairly ugly hack in itself but even worse than that, trying
to move a virtualenv directory somewhere else on the file system turns out to
be impossible unless you use another third party tool.

\- The python language has no switch statement. I refused to believe it when I
first discovered this but it is actually true.

So, two weeks or so in and those are my main gripes thus far. Apart from that,
I'm enjoying python. My favourite "python thing" discovered so far is all the
cool list iteration syntax.

------
narrator
PHP is basically the latest example of "Worse is
better"(<http://en.wikipedia.org/wiki/Worse_is_better>).

\----

Simplicity: The design must be simple, both in implementation and interface.
It is more important for the implementation to be simple than the interface.
Simplicity is the most important consideration in a design.

Correctness: The design must be correct in all observable aspects. It is
slightly better to be simple than correct.

Consistency: The design must not be overly inconsistent. Consistency can be
sacrificed for simplicity in some cases, but it is better to drop those parts
of the design that deal with less common circumstances than to introduce
either complexity or inconsistency in the implementation.

Completeness: The design must cover as many important situations as is
practical. All reasonably expected cases should be covered. Completeness can
be sacrificed in favor of any other quality. In fact, completeness must be
sacrificed whenever implementation simplicity is jeopardized. Consistency can
be sacrificed to achieve completeness if simplicity is retained; _especially
worthless is consistency of interface_.

\----

I don't know about you, but IMHO, this is PHP in a nutshell.

Edit: One other little thing I forgot to mention. PHP is like Java in that it
is really hard for a metaprogramming or type system nerd to do something
tricky and clever that another novice programmer brought in to replace him
would not have a chance of unravelling.

~~~
npsimons
_Consistency: The design must not be overly inconsistent. Consistency can be
sacrificed for simplicity in some cases, but it is better to drop those parts
of the design that deal with less common circumstances than to introduce
either complexity or inconsistency in the implementation._

. . .

 _I don't know about you, but IMHO, this is PHP in a nutshell._

If you had read some of the criticisms of PHP that had been posted to HN (like
[http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-
de...](http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/),
which was even linked to in the current article), you'd realize that PHP is
nowhere _near_ consistent. I'm not sure simplicity, correctness or
completeness apply either. I think the only thing PHP has going for it is
momentum (in having a large userbase and being installed almost everywhere).

~~~
wvenable
PHP's inconsistencies are _minor_. The problem with quoting the fractal
article is at least a third of it is totally wrong and another third is
misunderstandings by the author.

------
elehack
I hope Jeff succeeds in promoting an alternative to the level of ubiquity of
PHP. I think PHP is a generally awful language, eclipsed in sheer programming
linguistic badness only by such systems as MUMPS (which, fortunately, I have
never had the opportunity to work with). Fractal of bad? Check.

And it isn't just a bad programmer thing. PHP's bad habits encourage novice
(or uncaring) programmers to pick up bad habits, especially if they are not
particularly inclined to study how to use their tools well. Given a language
where the obvious thing to do is right vs. one where it's wrong (see PHP < 5
database queries - no prepared statements, mysql_escape_string) vs. an
environment where the obvious thing, encouraged by the introductory tutorials,
is right, I think that the more correct/safer language will encourage
programmers to write better code.

But reading the comments here and on Jeff's post, it is humbling to remember
that people are using it, every day, to build more and better software than I
ever have. I may have a visceral dislike for the language, but good
programmers are able to do good work even with a double-clawed hammer.

------
mootothemax
I agree that it's rather surprising that in this day and age, nothing comes
close to the out-of-the-box ease and performance that PHP gives for web
development. Install a couple of packages, and BANG, you're up and running.
It's been a year since I've taken a look at the rest of the webdev landscape,
but it seems that you either lose out to an overly-complex setup (by
comparison), or suffer with a memory hog that makes bootstrapping on a 1GB VPS
a nightmare.

I'm pleasantly surprised at the high rates my PHP consultancy work commands;
it's obviously helped by the number of hit-it-till-it-works web devs out
there.

~~~
jstalin
Agreed. I can set up a VPS with debian/nginx/mysql/php in about 10 minutes and
have a site up and running. Python? Ruby? There just doesn't seem to be an
easy way of getting them running on a web server. At least, I haven't figured
it out yet if it is easy to do.

~~~
mnutt
`git push heroku` style deployment is pretty easy. And for anything where
having a site up and running in 10 minutes is the primary driver, Heroku is
probably good enough.

Granted, for larger projects where you run your own ruby/python services, it
could surely be easier. But for larger projects you probably want to spend
more time on your deployment setup anyway.

------
wh-uws
Since lately folks have been attacking the people instead of their arguments I
also have to preface my comment.

I am a full time Rails Developer. So here we go...

 _If you want to produce free-as-in-whatever code that runs on virtually every
server in the world with zero friction or configuration hassles, PHP is damn
near your only option._

That is the crux of this whole debate summed up in one beautiful sentence. I
almost cried.

Until someone builds a better solution, where better includes as easy or
easier to setup on than php. Php is going to be the defacto standard.

And for the love of God please don't say well all you have to do install Blub
then configure foo server and...

You've already failed to be easier to get started on than with php. And if you
want php to go away you have to do just that.

Where do I install Blub? What happens when there are 30 different servers that
can run it which one do I pick? Why? What are the trade offs? Version Y is on
the website but everyone really uses version X because the the dependencies
haven't been up dated to Y yet. And the major framework just had a huge
fork/merge/catfight and now its future is uncertain ...

Fuck it I can pay Shithost $5 a month for php and I can toss a few variables
in this html <insert wysiwyg editor> crapped out.

Your average person who needs something to show up on a website

 _and lets be very clear_ if you want to see php go away _these are_ the
people you need to go after

does not care about: \- lambdas

\- good language design

\- namespacing etc,

they don't read Jeff Attwood, Hacker News or any of that.

One thing the php community as a whole has always focused on is ease of
getting started. Take Wordpress. The 5 minute install? That gets up an running
an allowing me to do what I care about (getting my client's content on the
internet) I still use it long after converting to other languages for most
development.

If you can't compete with that it does not matter how many templating
languages or css precompilers or what the hell ever you got. You don't stand a
chance.

TL, DR: Long Story Short. php and its children make it easy to drop in and
play. Thats what you are up against. Not language design beauty/ purity or
features. Ease of getting started.

Because honestly the only people who care enough to switch are people who care
enough to overcome that in other languages.

------
Killswitch
We get it, you don't like PHP. Don't use it. Nobody forces you to use it... If
someone does, it's most likely a client, and that's nobodies fault but your
own for seeking clients that want PHP work done. And if that's the case, you
shouldn't be scolding PHP for keeping food in your mouth and a roof over your
head.

But yes, we get it, you don't like it. Move the fuck on. These "This is what's
wrong with PHP" articles are starting to get redundant... Everyone shouting in
to a empty cave that nobody cares about.

~~~
gfosco
He's really one to talk.... ASP.NET is so amazing, right?

~~~
Killswitch
All languages have their purpose, use the one you want and prefer. I'm getting
sick of people bashing other languages because they don't like it. Especially
people who have never really used the language...

------
chez17
Ok, so here it goes. I haven't commented on this site for over a year.

Full disclosure: I am an average programmer compared to many here. I come to
this site to improve my self and read about what brilliant and amazing things
you all do. Now you have a reference.

I use PHP on a daily basis, have been for years. I am a freelance developer
who has been able to carve out a living with a lot of hard work and a lot of
luck. I just met the right people at the right time. Over the last 7 years
since I started developing professionally, I have seen nothing but people
shitting on PHP constantly. I am in no way suggesting PHP is a perfect
language, but I still never get the hate. It just seems so ivory tower to me
sometimes. Let's look at reality.

I'm starting a small project for a client. They are keeping track of all their
scheduling and doing all their reporting in excel. They want to move this to
the web with basic security so the right people can see the right information
with ability to access it from anywhere. That's it. You know what works for
that? PHP does. It works fine and it works on almost any server in the entire
world with no issues. I don't need a .vimrc file with a million special
configurations, I don't need a hot new framework where my time is spent
figuring out how to do basic CRUD operations, it won't matter if PHP is
statically typed or not, it won't matter if... you get the idea. I just need
to start developing and getting this project done so this business can start
saving time and money. __That's __what matters most to me.

PHP works, and it works damn well for _millions_ of situations every day. No
one is suggesting you use PHP to build a super computer. If your project
requires something different than use something different. PHP is not the
"Nickleback" of programming. PHP is useful. PHP is practical. PHP is easy, and
that's not a bad thing. Facebook, the biggest site in the world, uses PHP.
Think about that.

Finally, let's use his tool analogy. PHP is a double-clawed hammer. What if
your job was to remove nails from wood all day? What a wonderful tool a
double-clawed hammer would be! You wouldn't have to worry about which way the
hammer is facing! That would save you real time and real effort. It's the
right tool for that job. Tools are about how you use them. If someone uses a
tool incorrectly it's not the fault of the tool.

PHP can use improvement. Every language can. I imagine a meeting of otherwise
incredibly smart people sitting around in smoking jackets and sipping fine
brandy standing around with smug smiles on their face. "PHP is horrible!" One
will say. "Hmmmm... Yes... Quite..." A small laughter emerges. They all pat
themselves on the back and enjoy their intellectual circle-jerk. All the while
countless developers are using it every day for the right reasons making real
applications that help real businesses save real time and real money. Laugh at
me all you want, I get Christmas cards from my clients. They like me just
fine.

~~~
kintamanimatt
What other languages besides PHP have you used? I think a lot of us dislike
PHP because we're putting it in the context of better designed languages.

~~~
chez17
Sorry to respond twice to your post, but I realized this was a great
opportunity to learn something. Given my basic example in my post, what
language would you recommend I try to accomplish this task? I like to stay
away from frameworks so basically I'm asking you to not suggest Rails, however
don't be afraid to suggest ruby. If you feel like typing something out, let me
know why you suggest it and what advantages it has over PHP.

~~~
kintamanimatt
Ruby. It's the cleanest language with the most sensible standard library I've
come across to date. Ruby doesn't necessarily mean Rails, and in fact I'm not
a fan of Rails' overly prescriptive paradigm. (As an aside, any time you hear
Rails is an MVC framework, discount it because it's really an MVA framework.)
One of the things you'll find coming from the world of PHP is Ruby has
consistent method signatures. For this and a lot of other reasons you'll
almost certainly be happier with Ruby.

Aside from happiness, there are things that make Ruby more powerful. For
example, you can cleanly implement the reactor pattern (think: NodeJS) with
EventMachine and with EM-Synchrony you can avoid the callback hell that comes
with NodeJS.

If you want, you can look at Sinatra to provide the common functionality that
the PHP framework provides. With Sinatra you're not all-but-forced to use an
ORM like you are with Rails, as Sinatra doesn't include one. If you really
want, you can go closer to the metal and look directly at Rack, which is
middleware between web servers (Apache, Nginx, etc) and the actual
application.

There's really no right way to do it, but the best thing is to learn and
explore. Some people will recommend Python, and while it's a decent language,
it's got some things I consider to be rough edges -- lack of useful language
features, such as switch/case statements, and badly implemented parts of its
standard library that handle network requests.

The next language on my learning list is Go. I've heard nothing but good
things about it, but I'll reserve my judgment until I have some experience
with it.

~~~
chez17
Thank you for taking the time to write this. You have sufficiently peaked my
interest. My next personal project will be done in Ruby.

~~~
dxbydt
>My next personal project will be done in Ruby.

Here's a better idea. Take a very simple problem - say user fubar enters his
name, you say "Welcome, fubar!", populate a backend database with his name
because he's a new user. Otherwise you tell him "Welcome back, fubar!" and
don't mess with your database.

This involves what ? Handling a GET, making a database insert, doing a select
on name in a database, that's it.

Now go do this in atleast 5 frameworks, and time yourself. PHP obviously, but
do try RoR, Django, Play2, JSP and ASP.NET

I actually did the above exercise and came away with a lot of valuable
insight. In my case Play2 was a breeze because on Heroku its trivial to set
up, and each GET xxx request mapped directly to a xxx scala method in the
Controller, so no magic. The others were a little more painful, but not a
whole lot. I enjoyed the exercise.

~~~
kintamanimatt
The only trouble with this is that trivial applications tend to only give a
superficial feel for the framework and aren't representative of a "real"
development experience. For example, I wrote a trivial application in Flask.
Python's Flask, while it looks great on the surface and has fantastic
documentation, rapidly becomes unwieldy in the face of more complex problems.
The same is true for Ruby on Rails.

Most frameworks almost feel like they're tuned to solve these basic problems
and give a fantastic first impression that doesn't sustain.

Developing a complete project in each is a better way to move forward IMHO.

------
givan
There are only two kinds of languages: the ones people complain about and the
ones nobody uses.

Bjarne Stroustrup

------
Sambdala
The problem is that the barrier to entry with coding PHP for the web is to
open up notepad for 30 seconds and then upload a file. It's hardly more
complicated than writing a static HTML page.

The barrier to entry with any other popular language such as Python or ROR is
that's it's hard to just toss a script up and see results.

------
SideburnsOfDoom
Mr Atwood says "One of the explicit goals of my next project is to do whatever
we can to buff up a ... particular ... open source language ecosystem such
that it can truly compete with PHP in ease of installation and deployment. "

But _which_ open source language ecosystem? Is he talking about mono? ruby?
python? erlang? something else?

Either he thinks it's obvious what he's talking about (hint: it isn't to me)
in which case it's probably mono; or he's being deliberately coy and holding
back for a big reveal later.

------
Produce
PHP is broken in many little aspects but if you use a high quality framework,
it's quite enjoyable to work with. The main gripes I have with it are in the
details, like:

You can't do:

$something->doStuff()[0]

if(empty($something->doStuff()))

Overload fucking functions. Fuck.

What sucks:

The namespace separator.

The naming conventions of the core functions.

The speed.

But, overall it works and elegant solutions can be written.

Also, being competent in a market full of incompetents makes you valuable and
getting a well paying job is easy. What's not to like about that?

~~~
RobAley
Speed isn't an issue, at least in my experience, compared to similar
languages. Raw PHP usually beats Rails handsdown, and most PHP frameworks are
usually comparable. PHP performance has increased markedly over the past few
years, and particularly in v5.4. And if you really need a speed bump you can
use the APC cache or HipHop compiler. Its never going to be as snappy as, say,
C, but in the class of languages its in these days it holds it head up high.

I like the namespace separator, but I'll accept I’m in the minority on that
one.

~~~
papsosouid
>Raw PHP usually beats Rails handsdown, and most PHP frameworks are usually
comparable

Being able to keep up with the slowest competitor in existence isn't very
good.

~~~
RobAley
The reason I cited Rails is that its usually proposed as the better
alternative in these anti-PHP threads. Most "high" performance PHP doesn't use
one of the usual-suspects in the framework world and can easily beat Rails
(and usually plain ruby too).

Edit: I should add "in my experience" to the end of that, I have no stats to
hand.

~~~
papsosouid
>Most "high" performance PHP doesn't use one of the usual-suspects in the
framework world and can easily beat Rails (and usually plain ruby too).

If you skip a framework on both languages, they end up as the two slowest
languages. Hard to say if either is faster overall, but they are both awful.
Using jruby provides a huge performance increase, and PHP really has nothing
to compare with that.

~~~
RobAley
To be honest I've not used jruby. It would be interesting to see how it
compares to implementations PHP on the JVM such as IBM's WebSphere sMash, and
Caucho's Quercus. Do you have any views on the performance of jruby vs
hiphop'd PHP?

~~~
papsosouid
Hiphop doesn't really compete in the same space, as it only converts a subset
of PHP into C++, and has very limited support for various PHP modules. I don't
think any of the common PHP apps like wordpress, joomla, etc work under
hiphop. Stuff like Quercus is the jruby of PHP, being an actual implementation
of PHP rather than a source -> source translator. But I haven't seen any
benchmarks showing it actually beating regular PHP. It does have a much better
security record than the official PHP though, and is probably a worthwhile
project on that grounds alone.

------
tocomment
a few years ago a graphic designer asked me for some help using PHP to query a
database.

I wrote a little thing that worked, and then said, "oh wait, this could be a
problem with SQL injection, here's how you fix that".

And his response was "umm can you just send me the first thing you wrote".

~~~
dguaraglia
I completely agree with you. The problem with PHP (besides the myriad warts of
the language and libraries) is the average kind of programmers that use it: 0
code reuse, lots of cut & paste, insecure-by-design philosophy and the culture
of 'immediate results': if there's an error fix it fix it for the current page
so that the next time you refresh it'll be gone; then fix it on the other
pages _later_. Rinse, repeat.

------
nateabele
I'm not saying PHP is so great, not by a long shot; but if it's 2012, and
people are still writing "OMG PHP SUX" posts, yet PHP is _still_ everywhere,
the only thing I can see that meaning is this: the things that matter to
people who write "OMG PHP SUX" posts don't matter to anyone else.

------
njharman
> code that runs on virtually every server in the world with zero friction or
> configuration hassles,

Quit being so fucking lazy, entitled, and expectfull of silver bullet.

Good tools require maint, they require good environment, they require a
modicum of skill and/or effort.

The problem with PHP is not PHP. It is the PHP community. Which is filled (not
all) with ignorant, don't wanna learn/understand, minimal effort expending
schlubs.

The attitude "I'm a dev shouldn't have to know about sysadim", is fail, is
fucked. No, you create a product. Should be aware, if not knowledgeable, of
every aspect of that product and the team that creates it.

------
nir
I notice PHP has really bad rep amongst people who blog about building web
apps. People who build web apps still seem to choose it, though.

I agree with Jeff that the way to replace PHP is to create a better
alternative. Not just for PHP itself, but more importantly to stuff like
Drupal and Wordpress and Magento.

Yet this is isn't happening. Django and Rails are about 7 years old (Python
and Ruby both pre-date PHP) and haven't produced any CMS or blog engine
remotely comparable in popularity.

How come? Maybe because perception of PHP differs so greatly between people
who code and people who write about coding.

------
flyingbuttress
Give me a non-PHP alternative to Drupal, and I'll switch in a second.

~~~
will_work4tears
I found this one to be the better of Python's, IMO anyway.

<http://www.merengueproject.org/>

~~~
hhaidar
Merengue isn't that great. Save the headache and stick with Drupal.

------
jonstjohn
I work with PHP everyday at my job. Is it my favorite language? No. Are we in
a position like others (e.g., Facebook) where we have a ton of code and
infrastructure build around PHP? Yes. Do I love my company? Yes. We have
strict coding standards and high requirements for code quality. Gradually, we
are changing out some of our code for Python, where it makes sense, but I
doubt we'll re-write our entire applications anytime soon.

We've taken our two-claw hammer and done some fairly nice work with it.

------
DigitalSea
My favourite part was when Jeff said that his article wasn't another post
getting on the PHP hate wagon and then he takes pot-shots at the language,
classy. I'd equate Jeff's article to that of squirting a water pistol into the
ocean. Everyone knows PHP has some downsides, but it also has its upsides. PHP
does have its positives, but of course pointing out the negatives of anything
is a sure fire way of getting a response opposed to writing positive things.
You can fault every major language, no language is perfect regardless of what
anyone else says, JavaScript even has downsides but you'll be hard pressed to
find as many hating articles on JavaScript as you would on PHP.

PHP is simple to configure and deploy, I can get a client Wordpress site
migrated from my local environment to their server all setup and ready to go
in less than 5 minutes. I'm tired of the argument of: "Well, I just use Heroku
to push my Python and RoR projects live so your argument is invalid" the real
issue here is that the only argument haters of PHP have against it being easy
to deploy, is using a third party deployment app like Heroku which costs you
money as opposed to being able to push a Wordpress site live via SCP or FTP
without paying a cent.

I think when people hate on PHP they're confusing applications like Wordpress
or PHP frameworks with the language itself. Wordpress is not PHP, it's an
application built on PHP and we all know WP is poorly written but works this
isn't the fault of PHP.

Don't like the language? Improve it or shut up. It's like being who complain
about the war, but keep voting for the same political party..

------
tomkin
I'll start off by saying I don't know shit all about PHP on a fundamental
level. What I have noticed is there there is a sweet-spot of developers,
engineers that need to be involved.

Comments for "Adobe confirms it won't support Android" [1] are typical.
Achshar writes[2], "I think the problem isnt flash itself but the fact that
it's proprietary. This is the reason we have such news in the first place. If
adobe drops support, it's dead. No such thing with open stuff. No one entity
has all the control. This is where html5 upper leg, no one can suddenly start
charging you for using it or dictate it's development."

K, so if being open is what prevents crap, then why are we here talking about
PHP? Maybe its that there are too many hands in the cookie jar. Maybe too many
people working on fundamental design is the problem.

Whether its A/B testing of choices or how many people should work in a group
together – numbers matter. And maybe being too open, rather, too many
(different) people working on the same spec, can also be bad as well.

[1] <http://news.ycombinator.com/item?id=4175399>

[2] <http://news.ycombinator.com/item?id=4176485>

------
suresk
As fun and easy as it is to take potshots at PHP, and as much as I am against
personally working on any medium-sized or larger project that is written in
PHP, I feel like a bit of a hypocrite because I probably owe my career to PHP.

One "feature" of PHP that really no other language or platform has touched is
the vast amount of pre-existing software that is out there written in it that
you can quickly and easily tweak to suit your needs. This is how I got started
programming in the mid-to-late 90's as a kid in high school.

There was some auction software written in PHP, and I setup an auction site
and spent tons of nights making small tweaks to the software to make it a
really cool and fully-featured auction site. Nobody listed a damn thing on the
site, of course, but I was hooked.

\- Bad habits can be unlearned (I've unlearned enough to know)

\- You can go back and learn CS basics

\- You can gain an appreciation for well-designed languages and tradeoffs in
design

But it is really, really hard to replicate that awesome feeling when you start
out with some substantial piece of software and are able to incrementally make
it better - making bigger and bigger changes as you learn more and become
confident. The fact that so much open-source PHP software exists, the
development cycle is so short, and it is so quick and easy to host makes it
pretty good for that. Honestly, as much as I like Java now, if I'd started out
trying to use it, who knows what I'd be doing now.

As crappy as the language is, it is good enough at a lot of things. You won't
"kill" PHP by making a better language any more than you would beat CraigsList
by designing a better UI.

------
eevee
I guess I'll chip in here.

The handful of advantages that make PHP popular are also some of its worst
liabilities. Yes, you can deploy with just FTP... but then you have upload
security to worry about, and have to protect all your library files, and yadda
yadda. Yes, you can do SQL right off the bat... but you have to take care of
SQL injection yourself. Yes, you can stick your code right in your HTML... as
hard to read as that may be. Yes, there's no resource leakage... but every
request has to recompile the code and reconnect to your database.

None of these things are problems _at first_ , but they become problems
quickly once your software expands beyond two pages or a hundred hits a day.
Some of them may not even be obvious problems, but you'll pay the cost anyway
when some kid steals your database.

Other platforms, meanwhile, tend to have fairly simple solutions to all of
these problems, for the price of a minor increase in upfront learning. But
since the problems are all things that happen later on, newcomers will just
see that language X is harder.

This poses something of a difficulty. How can other languages introduce the
ease of PHP that everyone's demanding? We can't just port exactly the same
features over, or we'll have exactly the same problems. mod_python was a bad
enough idea that it's dead now. Heroku is a neat thing, but still requires
writing configuration files, and nobody enjoys doing that. Nothing is really
well-suited for single-page fire-and-forget, either.

I _have_ been thinking about this since writing that damned fractal post, but
I'm not clever enough to have thought up a solution yet. So, you know, it
would be useful if we could brainstorm on how to fix the learning curve and
deployment instead of "just turn everything else into PHP!"

------
apitaru
I worry that these kind of articles are not just annoying. They can cause real
damage.

// A Dramatization //

Consider a young developer that knows a bit of PHP and wants to get started on
her project. Then she (or "he", or "they" .. whatever) reads HN and finds out
that PHP sucks. HN is Mecca to her, so she now spends the next 3 months
figuring out that (truly) superior language. She picks whichever framework
most HNers are (innocently) promoting at the time.

What she doesn't know is that those karma-gods took their sweet time to figure
out 10 other things (== 1000 hours) before using said superior language and
framework. It's supposed to be easy, she thinks. She gets frustrated because
no-one had told her about those 10 other things. Time is running out on her
savings. "I'm not a real hacker", she thinks. She never airs her project.

// End Scene //

Now run the same story, only she doesn't read HN and just codes the thing in
PHP. It's actually a pretty cool project and ends up on first page of HN ...

~~~
Arshdeep
"she doesn't read HN and just codes the thing in PHP. It's actually a pretty
cool project and ends up on first page of HN ..." This happens alot. I see
cool PHP projects on first page all the time.

------
s0me0ne
Anyone have a full article on how to build a site with just Python and not
using Django? This would be more helpful than bashing PHP.

The article would have to show us how to install Python, configure it, get it
working on the server, what to upload, how to deal with forms, cookies, etc.
I've yet to see this kind of article. I wouldn't mind learning Python for web
use, but every book I've seen suggests you just use a framework or has a very
small chapter composing of a few pages. Such an article or even a book, would
get more people off PHP, if that's what people want. Until then PHP gets stuff
done and that's all clients care about, no one cares if I use Windows, Linux
or Mac OS X when I work. Granted I'm not a l33t programmer like most on here,
I'm just here to learn from better coders.

------
CGamesPlay
<http://xkcd.com/927/> s/standards/web app platforms/

~~~
glassx
<rant>Okay, not directed at you, but... It was posted yesterday. Does this
really have to be posted EVERY SINGLE DAY?

Every time anyone suggests improving anything, or make another product in a
crowded space, this comic is posted. The author of this article doesn't even
suggest a new platform - he suggests improving a platform that exists to
enable easier deployment. It was posted yesterday for Chocolat... do we really
have to stop making editors?

In a site targetted to hackers and startups it is disturbing that people are
so unwilling to learn something new, support a new product, improve the world,
do anything new. Yes, redundant standards suck sometimes, but it's not always
the case.

I wish that the comic author would consider deleting this from the server, or
maybe pg could ban it.</rant>

~~~
CGamesPlay
Well, not exactly. The author does suggest a new one:

> I'm starting a new open source web project with the goal of making the code
> as freely and easily runnable to the world as possible.

~~~
glassx
Nope. In this line he's talking about a web app he's writing and how he
considered writing it in PHP to boost adoption. Here's it in context:

"I'm starting a new open source web project with the goal of making the code
as freely and easily runnable to the world as possible. Despite the serious
problems with PHP, I was forced to consider it."

------
dougbarrett
One thing that keeps me coming back to PHP after trying out RoR, Python
(Django), node.js is the deployment.

All I have to do is create a new directory, create a new vhosts file run a few
apache commands, reload apache and I'm done. In total, it should take less
than a minute to get a directory set up for deployment.

With other languages, they haven't gotten the deployment part down as smoothly
as the PHP/Apache experience.

Sure, I can go with Heroku or other IaaS solutions, but I want to run it on
__my __server, I like being able to back up an entire directory that houses
all of the sites and projects I'm currently working on, and not have to figure
out how to use API's of different services.

------
will_work4tears
Ex-PHP developers that bash PHP are like the poor kids that win the lottery
and then start bashing poor people publicly.

Sad and kinda small of them.

I'm willing to win the lottery, mind you, but I'd never waste my time or lower
myself down to bashing poor kids.

~~~
EvilTerran
Surely that'd be

"Ex-PHP developers that bash PHP _programmers_ are like the poor kids that win
the lottery and then start bashing poor people publicly."

or

"Ex-PHP developers that bash PHP are like the poor kids that win the lottery
and then start bashing _being_ poor publicly."

? Very different, IMO.

~~~
will_work4tears
The first one. I think the language is pretty fair game. However, the bashing
seems to carry on over to the programmer often enough.

~~~
EvilTerran
Yeah, it's a fine line between just bashing a tool and bashing its users as
well. I feel the submission came down on the bashing-the-tool-only side, but
that's a judgement call.

------
neovive
I'm a long-time PHP programmer and have been programming with Lua (for gaming)
for the past year and Python for command-line (NumPy) based scripts for the
past two years. Obviously, in comparison, the syntax in Lua and Python are a
thing of beauty as are the data structures (Lua tables FTW), but I always fall
back to PHP for web projects since I haven't had the chance to completely grok
the Python deployment process.

Is there a simple guide to deploying Python web applications (preferably with
Flask)? I know there are quite a few options (WSGI, FastCGI, mod_python), but
what is the best way to do it.

~~~
SomeCallMeTim
Better: Deploy a Lua-based stack. [1][2]

I've tried to get a Python stack to build and it's huge, complicated to set up
and get running well, and so _slow_ compared to LuaJIT as to be pathetic. A
friend was at PyCon surrounding by a bunch of Python hackers who spent more
than an hour _trying_ to get Django installed on his server an they _failed._
If the so-called experts have a hard time with it, then I don't feel so bad
for finding it hard myself -- and I wouldn't recommend it to anyone.

Both Lua solutions I linked are easy and fast to install and configure (if
you've got a shell, at least), and the Lua stacks are like Node.JS done
_right_. You get coroutines so you get non-blocking code without having to
code everything as an awkward callback. And of course you get the awesomeness
of Lua instead of having to deal with the mess that is JavaScript.

[1] <http://tir.mongrel2.org/>

[2] <http://openresty.org/>

------
adjwilli
PHP is like the English language, full of inconsistencies but everyone speaks
it.

------
mschalle
I used to really like Coding Horror, but everything Atwood writes now days he
sounds like a damn broken record. And his twitter feed is nothing short of
immature and childish.

------
mcantelon
>Guess what? It was just as horrible in 2008.

I don't do much PHP these days, but PHP has actually added some good stuff in
recent years: functions as variables, traits, etc.

------
sequoia
_Yawn_. Can someone explain to me why this sort of post keeps getting written?
It seems like it's just snooty hipsterism. "I want to make sure people know
that PHP is bad!" Please, point out to me the developer who has not heard this
_a million fucking times already_.

Serious question: besides "cred" and just stirring the pot, what is the
_point_ of writing a post like this?

------
leothekim
PHP got Facebook up and running, so it has that to its credit. And that's a
huge credit.

As a result, Facebook engineers developed things like this:
<http://en.wikipedia.org/wiki/HipHop_for_PHP>

Which is an impressive piece of technology, but makes you wonder if Facebook
engineers wish their website wasn't written in PHP.

~~~
Isofarro
It surprised me, considering the original developers of facebook (Zuckerberg,
Moskovitz) were doing Computer Science degrees why they chose PHP to build it
in initially. Did they consider other languages, or frameworks.

I'd be surprised if they chose PHP because of future hireability / scaling up.
I'd guess they didn't give it much thought and PHP was just there.

~~~
aidenn0
In the early part of this century, PHP was basically still _the_ free language
for writing dynamic web content.

The second place choice was probably perl (via cgi or mod_perl).

I guess Tomcat was around too.

Both Django and Rails were released after facebook.

------
ianlandsman
My 2 cents: <http://ianlandsman.com/2012/06/29/PHP>

------
elorant
The whole web development thing is broken. Even with cutting edge tools like
asp.net mvc, or rails or whatever we're still using half a dozen different
technologies to build a web page and to me it feels like I'm fighting around
the http protocol trying to hack my way through various inconsistencies.

------
anuraj
Unfortunatley, from language design perspective, both PHP and JavaScript are
down right horrible. But they get the work done. In general dynamically typed
scripting languages are playgrounds for errors - a statically typed paradigm
might help - but we are too late for that.

------
tocomment
Do the PHP frameworks help at all?

~~~
arms
I would say yes, although to varying degrees depending on the framework. IMO,
the safest bet would be to use an 'enterprise' level framework (Zend,
Symfony2). But, as jrgnsd mentioned in his reply, even within the context of a
framework, an inexperienced developer can still make plenty of mistakes and
poor design choices. Learning the framework isn't enough, the developer must
also take care to adhere to best practices in software design.

------
romaniv
Other languages need to work on making application deployment easier. Often,
you can deploy a PHP app without ever opening a terminal. Heck, some hosters
didn't even give you access to a terminal.

------
chernevik
Jeff has buried the lead.

"The best way to fix the PHP problem at this point is to make the alternatives
so outstanding that the choice of the better hammer becomes obvious."

That's a terrific point. Alas, it is at the bottom of what is basically
another of the "PHP sucks" posts, of which he says we already have too many.
And now this comment thread is hip-deep in "Shut up, PHP works fine" posts.

I'm self-taught on Python, and I love it, but as I've moved freelance I've had
to learn PHP, and I . . . don't love it. It is what many of my clients use,
for reasons that seem good to them, so there you go. I don' enjoy learning it
and using it the way I enjoy Python, but as a professional that's Just Too
Damn Bad. So I'm kind of with the people irritated by the PHP bitching.

But I wish that Python had those characteristics that make PHP ubiquitous. I'm
too new to really state what these are, and I imagine there are some good
design reasons for avoiding some of those patterns. But anyone preferring that
something like Python or Ruby should see wider adoption has to consider the
aspects of PHP that have supported its prevalence, and compete on those
aspects.

I am going to guess that Jeff felt the need to critique PHP because he thought
there must be some justification for duplicating those functionalities of PHP.
I think the community is at a consensus that there isn't, and shouldn't /
couldn't be, One True Language, and that it's okay to choose the proper tool
for a particular job. And if that's the case, why would it make sense to
revise Python or Ruby to duplicate stuff that's already done well by PHP? Why
insist that any one language do everything? The best argument would be that
PHP gets a lot right, but couples that to a lot it gets wrong. And whether or
not that is so drives the question of whether some other language should
trouble itself to duplicate the stuff PHP gets right.

It might be enough to say that some people / many people don't like PHP very
much and wish that other tools were more prevalent. Among such people, the
questions then are: 1) are we just being jerks, is there really that much to
be gained by getting away from PHP? and 2) how do other languages have to
change (technically, the installed base / trained developer population
arguments are beyond this discussion) to compete? And I think the two
questions are related. If it isn't hard to make Python as deployable as PHP,
then we needn't gain much to make it worthwhile. But if those changes are
hard, or they somehow introduce into Python anti-patterns of some kind, or
shift the community focus in some negative way, then we would have to see much
larger gains to make the shift worthwhile.

I hope Jeff reviews the reaction to this and responds with another post, one
that explores why PHP is so frequently adopted. (Again, it's best to put to
one side the issues of widespread developer knowledge and default
configuration in support of it, if a better alternative is built those things
will move.) And, what are the challenges of adapting Python / Ruby / Perl to
competing on those technical aspects? And what are the technical / community
risks of making those adaptations? At that point I think he's moving the
discussion in a much more constructive direction.

------
capitao
And you know the saddest thing, I'm sitting here reading all these comments
instead of actually programming... if I'm not getting anything done, does it
really matter which language I'm using?

------
EternalFury
Here we go again...

Maybe it does suck. You can certainly tell it was not designed by computer
scientists. In many ways, it throws away years for programming language best
practices.

This being said, what are the practical alternatives? JSP? Servlets? ASP?
Python/Django? Ruby/Rails? What?

I am sorry but JSP, Servlets, ASP, Python/Django, Ruby/Rails are just shit of
a different kind. But they do not deserve that holier-than-thou aura.

I suggest bad programmers keep blaming their tools for their own shortcomings.
I suggest that when bad programmers have produced enough horrors to sully a
tool, they blame the tool and move on to the next tool.

~~~
TazeTSchnitzel
Python's Flask is a good, lightweight web framework that works fine. It was a
breath of fresh air compared to PHP, and I can understand it, unlike Django.

~~~
EternalFury
I am open minded. I will give Flask a try.

I doubt it'll be easier to deploy than a LAMP server, though. I already recoil
at the idea of having to figure out why Passenger is not working as it should,
or why I should run a terrible HTTP front just to try this out.

~~~
TazeTSchnitzel
It's a little bit more difficult (especially since if you want to use Apache
you'd have to configure it manually), however there are plenty of Python WSGI
hosts out there that should make it simpler.

------
tomkin
> PHP is the Nickelback of programming languages.

Look at this script that uploads a photograph. Every time I see it, it makes
me laugh.

------
wvenable
I wish bloggers would stop quoting that fractal article. At least 50% of
what's written in there is totally wrong/false. Other information is terribly
out of date. And even more information is merely half-truths and lack of
understanding of the language. The article author clearly scanned through PHP
bashing articles and took material from them verbatim; mistakes and all.

I'm not going to argue that PHP is a great language, but the article is a
complete disservice to anyone who has bothered to read it. I'm disappointed,
but not surprised, that Jeff Atwood linked to it.

Just a few errrors in that article:

> Operators are very fragile in the parser; foo()[0] and foo()->method() are
> both syntax errors. The former is allegedly fixed in PHP 5.4, but I can’t
> find mention of a fix for the latter.*

The latter doesn't need a fix because it always worked. Honestly, how hard is
it to test that foo()->method() works?

> Objects compare as greater than anything else… except other objects, which
> they are neither less than nor greater than.

Strict-equals on objects compares the references; but regular equals compares
the contents of the objects. Two objects compare equal if the contain exactly
the same fields and values. Seems pretty reasonable to me.

> \+ is always addition, and . is always concatenation.

This is a good thing; JavaScript gets this wrong.

> There is no way to declare a variable. Variables that don’t exist are
> created with a null value when first used.

Variables that don't exist issue a notice. You can deal with that just like
any other error.

> Global variables need a global declaration before they can be used.

Actually there is also the $GLOBALS array for this. I'll agree that's not much
a solution. Globals should just not be used; if you want to use static class
variables, it's a much better choice with a sane syntax.

> there’s no pass-by-object identity like in Python.

I'm not sure if I understand this but all objects are passed-by-reference in
PHP (since 5) and PHP references act appropriately when used as function
parameters, etc.

> A reference can be taken to a key that doesn’t exist within an undefined
> variable (which becomes an array). Using a non-existent array normally
> issues a notice, but this does not.

An attempt to use the reference will result in a notice but isset() and
empty() operate it on it correctly.

> Constants are defined by a function call taking a string; before that, they
> don’t exist.

You can declare constants in classes and namespaces with the const keyword.

> There’s an (array) operator for casting to array. Given that PHP has no
> other structure type, I don’t know why this exists.

You can cast scalars to single element arrays and objects to arrays with the
same structure. Both are actually very useful.

> include() and friends are basically C’s #include: they dump another source
> file into yours. There is no module system, even for PHP code.

PHP is interpreted -- namespaces and autoloaders are PHP's module system.

> Appending to an array is done with $foo[] = $bar

This is a good thing.

> empty($var) is so extremely not-a-function that anything but a variable,

Empty is equivalent to the not operator but will also work on undefined
variables -- that's why it requires a variable.

> There’s redundant syntax for blocks: if (...): ... endif;, etc.

Useful inside of templates where matching { } is much more difficult.

> PHP’s one unique operator is @ (actually borrowed from DOS), which silences
> errors.

Sometimes you don't care if a function succeeds; like with the unlink()
function which will raise an error if the file you're trying to delete doesn't
exist.

> PHP errors don’t provide stack traces.

Not true. Debug_backtrace() will give you a stack trace in an error handler.

> Most error handling is in the form of printing a line to a server log nobody
> reads and carrying on.

Assuming, of course, the programmer doesn't do anything to handle errors.

> E_STRICT is a thing, but it doesn’t seem to actually prevent much and
> there’s no documentation on what it actually does.

E_STRICT (or lack of it) is for compatibility with PHP4. When enabled it will
"warn you about code usage which is deprecated or which may not be future-
proof." -- quote from the manual.

> E_ALL includes all error categories—except E_STRICT.

Unfortunate naming here -- E_ALL is from PHP4 and prior and E_STRICT is all
about PHP5. Including it in E_ALL would break PHP4 scripts running on PHP5.

> Weirdly inconsistent about what’s allowed and what isn’t.

This author is confused why syntax errors would be parse errors but logic
errors are not.

> PHP errors and PHP exceptions are completely different beasts. They don’t
> seem to interact at all.

This is sort of true; PHP errors and exceptions exist in different universes
but it's easy to unify them and PHP even provides a built-in exception
ErrorException to do so. You can turn every PHP error into an exception with 4
lines of code complete with stack traces. You could even turn exceptions into
errors but I wouldn't recommend that. PHP supports both procedural and OO
programming styles -- this is not a bad thing.

> There is no finally construct

C++ also doesn't have a finally construct. But C++ and PHP support RAII --
class destructors run when the stack is unwound so you can do your cleanup.
Finally would be a welcome addition to both languages.

> function foo() { return new __stdClass(); } leaks memory. The garbage
> collector can only collect garbage that has a name.

PHP is reference counted with a cycle-detecting GC. That would not leak
memory.

> Function arguments can have “type hints”, which are basically just static
> typing. But you can’t require that an argument be an int or string or object
> or other “core” type

This is true, but it's an ongoing discussion on how to correctly handle scalar
type hints. For all the discussion about how PHP isn't designed the author
takes issue with the thing they're taking their time on.

> Closures require explicitly naming every variable to be closed-over. Why
> can’t the interpreter figure this out?

Because of the dynamic abilities of PHP, there is simply no way for the
interpreter to ever figure out the variable to close over. The solution is
actually a rather simple.

> clone is an operator?!

Of course!

> Object attributes are $obj->foo, but class attributes are $obj::foo. I’m not
> aware of another language that does this or how it’s useful.

C++ does it. $obj::foo doesn't make any sense, if you're accessing class
attributes then you use the class name Class::foo.

> Also, an instance method can still be called statically (Class::method()).
> If done so from another method, this is treated like a regular method call
> on the current $this. I think.

Only static methods can be called statically. The other calling methods
statically is similar to C++ ... you can call parent class methods explicitly
by name by-passing any overriding.

> new, private, public, protected, static, etc. Trying to win over Java
> developers? I’m aware this is more personal taste, but I don’t know why this
> stuff is necessary in a dynamic language

This is personal taste not a valid critique.

> Subclasses cannot override private methods.

That is the definition of private methods!

> There is no method you can call on a class to allocate memory and create an
> object.

You can use reflection to create an object without calling the constructor.

> Static variables inside instance methods are global; they share the same
> value across all instances of the class

This is the definition of a static property!

> Yet a massive portion of the standard library is still very thin wrappers
> around C APIs

That is, in fact, the point. PHP is supposed to be a thin scripting language
layer over C. It's expanded beyond that. Many of the poor naming conventions
are not because of PHP but rather are the exact API of the underlying C
library.

> Warts like mysql_real_escape_string, even though it has the same arguments
> as the broken mysql_escape_string, just because it’s part of the MySQL C
> API.

Both the C API and PHP have both these functions for backwards compatibility
reasons. This entire API is pretty much depreciated with both the mysqli
library and PDO replacing it.

> Using multiple MySQL connections apparently requires passing a connection
> handle on every function call.

Yes, exactly. That's the only way multiple connections could possibly work.

> PHP basically runs as CGI. Every time a page is hit, PHP recompiles the
> whole thing before executing it.

Unless you use a free code cache like APC. It will eventually be built in.
Most people don't need it.

> For quite a long time, PHP errors went to the client by default

If you don't handle your errors, they go somewhere.

> Missing features

Most of these are provided by frameworks just as they are in Python, Ruby, C#,
etc.

> Insecure-by-default

Most of these things are now removed from the language after being depreciated
for years.

~~~
eevee
> Strict-equals on objects compares the references; but regular equals
> compares the contents of the objects. Two objects compare equal if the
> contain exactly the same fields and values. Seems pretty reasonable to me.

The line you quoted is talking about ordering, not equality.

> This is a good thing; JavaScript gets this wrong.

It IS a good thing, but it stands out when most of the language is extremely
weakly-typed and even the original manual claims that separate operators for
strings and numbers are confusing.

> I'm not sure if I understand this but all objects are passed-by-reference in
> PHP (since 5) and PHP references act appropriately when used as function
> parameters, etc.

So some things (objects) are passed by reference implicitly, and some (all
else) are not. Yikes!

> You can declare constants in classes and namespaces with the const keyword.

Okay. Why not at top-level?

> You can cast scalars to single element arrays and objects to arrays with the
> same structure. Both are actually very useful.

You've practically invented a bug right there: if I write a function that can
take either one value or an array of items, and you pass in a single object,
I'll get a useless keyed array of its attributes.

> PHP is interpreted -- namespaces and autoloaders are PHP's module system.

What does being interpreted have to do with anything? Python and Perl are
bytecode-interpreted (not positive about Ruby) and they both have rich module
systems that don't require any fussing around. Heck, shell is interpreted, but
zsh manages something almost like modules.

> Empty is equivalent to the not operator but will also work on undefined
> variables -- that's why it requires a variable.

Why does it need to look like a function when it clearly isn't one? return and
echo don't.

> Useful inside of templates where matching { } is much more difficult.

In theory, but I've never seen any actual PHP code that uses them.

> Sometimes you don't care if a function succeeds; like with the unlink()
> function which will raise an error if the file you're trying to delete
> doesn't exist.

That's what exception handling is for -- unfortunately, PHP errors are an
entirely separate beast from PHP exceptions.

> Not true. Debug_backtrace() will give you a stack trace in an error handler.

I said "PHP errors don't provide stack traces", and you aren't disputing that.
Your own code can muck around to give you a stack trace (in most cases), yes,
but the runtime doesn't do it for you.

> Assuming, of course, the programmer doesn't do anything to handle errors.

Defaults are important. I sure have a lot of people telling me it's great that
PHP does web stuff out of the box -- why is it not then bad that PHP doesn't
help you fix errors out of the box?

> E_STRICT (or lack of it) is for compatibility with PHP4. When enabled it
> will "warn you about code usage which is deprecated or which may not be
> future-proof." -- quote from the manual.

Yes, and that doesn't describe what it does. You can't tell what it's for,
either: it's clearly not for compatibility with just PHP4, because even the
PHP 5.4 release notes mention the addition of a new E_STRICT. Yet I can't be
sure on what parts of the language actually ARE deprecated without reading the
entire manual looking for mentions of E_STRICT.

> This author is confused why syntax errors would be parse errors but logic
> errors are not.

Read more carefully; the two lists are written roughly in parallel. A bogus
object attribute gets a warning, but a bogus class attribute is a fatal error.
(Not an exception, either, so you can't catch it with the exception handling
that the OO system is supposed to be using.) A string value stored in a
variable can be called, but the same string value as a literal cannot. And so
on.

> This is sort of true; PHP errors and exceptions exist in different universes
> but it's easy to unify them and PHP even provides a built-in exception
> ErrorException to do so. You can turn every PHP error into an exception with
> 4 lines of code complete with stack traces.

Neat, though my understanding is that this still doesn't work with fatal
errors, which are shockingly common.

I have the same kind of complaints about Perl's exception handling -- it's
entirely possible to hack it into something more useful, but why on Earth
should I have to mess around just to make something as fundamental as errors
be developer-friendly?

> PHP supports both procedural and OO programming styles -- this is not a bad
> thing.

Exception handling isn't inherently OO. Perl has its own flavor of try/catch
that requires zero objects whatsoever.

> PHP is reference counted with a cycle-detecting GC. That would not leak
> memory.

I believe it used to, but I removed this due to the short window during which
it was a bug. I see this list of counter-arguments hasn't been updated in a
while.

> This is true, but it's an ongoing discussion on how to correctly handle
> scalar type hints. For all the discussion about how PHP isn't designed the
> author takes issue with the thing they're taking their time on.

My issue isn't that they're taking their time, but that they implement _half_
of a feature and _then_ decide to sit down and think about the other half
(while now constrained by whatever hack job they've already done).

> Because of the dynamic abilities of PHP, there is simply no way for the
> interpreter to ever figure out the variable to close over.

Every other dynamic language ever sure seems to be able to get this right.

> C++ does it. $obj::foo doesn't make any sense, if you're accessing class
> attributes then you use the class name Class::foo.

Then why not use Class->foo? Why does this need two operators? $obj::foo is
perfectly reasonable if I want the foo attribute of whatever class $obj is;
that's half the reason I ever use class attributes.

> This is personal taste not a valid critique.

Yes, which is why I said it's personal taste. Regardless, it's still wildly
inconsistent with the rest of the language and poorly bolted on.

> That is, in fact, the point. PHP is supposed to be a thin scripting language
> layer over C. It's expanded beyond that. Many of the poor naming conventions
> are not because of PHP but rather are the exact API of the underlying C
> library.

How many people using PHP today came from C, exactly?

> Both the C API and PHP have both these functions for backwards compatibility
> reasons.

No. The C API has two functions because one takes only a value to escape, and
the other takes both a value and a connection pointer. Both functions in PHP
can be called with merely a value, and the "real" one will use the current
global connection. Zend could have merely switched the old escape function to
have the new behavior, and all existing code would have been instantly _fixed_
, not broken.

> Most of these are provided by frameworks just as they are in Python, Ruby,
> C#, etc.

PHP is praised for its web features, but is missing a whole pile of
functionality instrumental for actually writing nontrivial web applications.
Either judge PHP only by the core language, or judge everything else by what
you get with frameworks.

~~~
wvenable
> It IS a good thing, but it stands out when most of the language is extremely
> weakly-typed

You only need distinct operators if your language is weakly typed. If you
language is strongly typed like Python, Java, or C# then there is never any
conflict between addition and concatenation. VB/VB.NET is also weakly typed
and has separate operators.

> So some things (objects) are passed by reference implicitly, and some (all
> else) are not. Yikes!

Yes, like most ever other language in existence. You know, Java, C#, Python,
etc.

> Okay. Why not at top-level?

Because all code should be contained within a namespace going forward.
Constants should not be defined in the top-level.

> if I write a function that can take either one value or an array of items,
> and you pass in a single object, I'll get a useless keyed array of its
> attributes.

No, it doesn't work that way. You have to explicitly cast. If you use an array
type-hint you can only pass an array.

> Python and Perl are bytecode-interpreted (not positive about Ruby) and they
> both have rich module systems that don't require any fussing around.

PHP is also bytecode-interpreted. I'm not really sure what point you're trying
to make. It's super easy to integrate code from different libraries with
namespaces and autoloading.

> Why does it need to look like a function when it clearly isn't one? return
> and echo don't.

Because it's used an expression not a statement like return and echo. The fact
that is or is not a function is insignificant; you use it the same way.

> In theory, but I've never seen any actual PHP code that uses them.

In templates you see it all the time.

> That's what exception handling is for -- unfortunately, PHP errors are an
> entirely separate beast from PHP exceptions.

If you convert all errors to exceptions, you could catch it. It's just an
additional feature. If you handle your own errors, you can even ignore the
error suppression operator if you choose.

> I said "PHP errors don't provide stack traces", and you aren't disputing
> that... but the runtime doesn't do it for you.

Oh, you're saying if you don't provide any of your own error handling and let
it spill out the terminal -- yes, you're right -- no stack trace by default.
Not that you should be doing that. If you really want that though, it can be
provided by the XDebug extension.

> it's clearly not for compatibility with just PHP4

The lack of E_STRICT helps you run PHP4 code on PHP5. That's why it's not
included in E_ALL. For example, I have an application that runs unmodified on
PHP4 and PHP5.

> Yet I can't be sure on what parts of the language actually ARE deprecated
> without reading the entire manual looking for mentions of E_STRICT.

Turn on E_STRICT and it'll tell you.

> A bogus object attribute gets a warning, but a bogus class attribute is a
> fatal error.

Yes, one is defined and one is not.

> A string value stored in a variable can be called, but the same string value
> as a literal cannot.

Calling a string literal is pointless! 'test'() is test()!

> Neat, though my understanding is that this still doesn't work with fatal
> errors, which are shockingly common.

Fatal errors are not that common but I won't argue the point too heavily
because they _are_ a bitch. PHP developers are trying to reduce the number of
fatal errors. Most IDE's will notify you of fatal error as you type.

> but that they implement half of a feature and then decide to sit down and
> think about the other half (while now constrained by whatever hack job
> they've already done).

There's nothing controversial or difficult about object type hinting. Also
since PHP is meant to be typeless there is some discussion over whether scalar
type hints are even necessary. Giving you something you can use right now is
not a bad thing.

> Then why not use Class->foo? Why does this need two operators?

I suspect historical reasons. They really did do very different things in
PHP3/PHP4.

> Regardless, it's still wildly inconsistent with the rest of the language and
> poorly bolted on.

How so? It's PHP object system, there is nothing for it to be inconsistent
with in the rest of the language.

> How many people using PHP today came from C, exactly?

It's not about whether they came from C -- it's the fact that PHP quickly
implemented access to a huge library of existing C libraries (and tracked
their changes). This was a _huge_ deal back when PHP was younger.

> Zend could have merely switched the old escape function to have the new
> behavior, and all existing code would have been instantly fixed, not broken.

If you've ever complained about security in PHP, you need to give that up
right now. Because you just gave everyone a false sense of security.

> Either judge PHP only by the core language, or judge everything else by what
> you get with frameworks.

Wait, why? That's ridiculous.

~~~
eevee
tl;dr: I value consistency in my tools because it's a great measure of how
frequently they'll trip me up and get in my way while reading or writing code.
My biggest problem with PHP above all else, which I tried to write my article
around, is that it's an inconsistent jumble from top to bottom.

You're absolutely correct, of course, in that you can write decent PHP by
avoiding large chunks of the language, memorizing what things act differently
from other things that look the same, not trying to do anything _too_ dynamic,
adding boilerplate to every project to fix useless default interpreter
behavior, and so on. You can also waltz across a minefield if you just
remember where all the mines are. But the necessity of doing all these things
is exactly my argument: why bother with all this from a tool that's supposed
to help you get stuff done? Because it has $_GET out of the box? You can't
even claim "ease of learning" as an advantage after all this, because judging
by your own responses, much of the language is pitfalls just waiting to trip
up beginners who haven't yet learned the right painful lessons.

Yes, I'm not a PHP programmer. And as a not-PHP programmer, a lot of PHP looks
totally crazy. But when outsiders complain about craziness in Python or Perl
or Haskell or whatever, at least that craziness can usually be explained as
consistent with the rest of the language, or part of an overall philosophy, or
the result of some valuable tradeoff. And if not, we're very sympathetic about
the ugly warts on our dearly beloved. Yet all anyone has ever been able to
tell me about PHP craziness is "well, you shouldn't do that anyway" or "that's
how it is in one of ten other languages" or "I have no explanation but here's
a workaround so it's like the problem doesn't actually exist, right".

It is hard for me to understand how even someone who loves PHP can't see this
as deeply alarming.

> You only need distinct operators if your language is weakly typed.

I don't dispute that: I claim that having separate addition and concatenation
operators, but having a single set of equality/comparison operators, is
_inconsistent_.

> Yes, like most ever other language in existence. You know, Java, C#, Python,
> etc.

Incorrect. Python passes everything by reference (value reference, not name
reference) because everything is an object. Passing never performs a copy. I'm
under the impression that Java is the same. Perl passes by alias, though the
aliases are generally then copied to locals, and it has that whole array-
flattening behavior which muddies things.

> Because all code should be contained within a namespace going forward.
> Constants should not be defined in the top-level.

Everything in Perl is in the `main` namespace unless otherwise specified. One
wonders why PHP could not retrofit its new features onto the language like
Perl has done for decades, rather than leaving half the language to flounder.

> No, it doesn't work that way. You have to explicitly cast. If you use an
> array type-hint you can only pass an array.

I'm assuming you're using the explicit cast inside the hypothetical function.

> PHP is also bytecode-interpreted. I'm not really sure what point you're
> trying to make.

You appeared to be citing interpreted-ness as a reason for having a wonky
module system. I am naming other interpreted languages with useful module
systems as counterexamples.

> The fact that is or is not a function is insignificant; you use it the same
> way.

Unless you want to do other function-y things to it, or any of the other
pseudo-functions. The syntax is deliberately designed to make you think
something is a function, but it only acts like a function in one particular
way. (And as a side effect, there are a ton of simple function names you can't
use as method names, because the parser gets very confused -- even though this
seems like it should be unambiguous.)

> Oh, you're saying if you don't provide any of your own error handling and
> let it spill out the terminal -- yes, you're right -- no stack trace by
> default. Not that you should be doing that.

Defaults matter. This is an atrocious default.

> Turn on E_STRICT and it'll tell you.

It'll tell me what things I've already done; I can't easily find out what I
should be avoiding proactively.

> Calling a string literal is pointless! 'test'() is test()!

So what? Both are values; why is there any distinction? Hell, you can call
methods on numbers in Ruby and Python. I don't care about the practical value
here; it's yet another place where PHP is inconsistent for seemingly no
reason.

> If you've ever complained about security in PHP, you need to give that up
> right now. Because you just gave everyone a false sense of security.

Howso? The problem with mysql_escape_string was that it didn't take the
current database handle into account. So: make it take the current database
handle into account. It may not have solved everyone's problems, but the
exceptions are obvious, and it would have fixed problems for far more people
than the actual solution (zero).

If you're using multiple handles and passing them around explicitly, you'll
have to fix your code either way.

~~~
wvenable
> I'm under the impression that Java is the same.

No, Java is not the same. Scalars not objects in Java and are passed by value.
C# is similar, except scalars are value-type objects and are passed by value.

> I'm assuming you're using the explicit cast inside the hypothetical
> function.

That's not what we were talking about. It's incredibly hard to have a
reasonable conversation about this with you because you clearly only know a
very small set of similar languages and have no experience with PHP at all.

> You appeared to be citing interpreted-ness as a reason for having a wonky
> module system.

You cited byte-code interpreted as if that's somewhat significant. PHP's
module system really isn't very "wonky" -- it works as advertised. But since
you don't use it, you wouldn't know.

> It'll tell me what things I've already done; I can't easily find out what I
> should be avoiding proactively.

You could read the manual. If you're new to PHP, you'd probably code strictly
from the start.

> So what? Both are values; why is there any distinction?

Most languages make the distinction. Why shouldn't there be? That's really
ugly code.

> Hell, you can call methods on numbers in Ruby and Python.

That's fine. It doesn't mean _every_ language should do the same. Most
languages, especially those PHP is based on, do not do that. Maybe one day PHP
will have that but because it's weakly typed, it's difficult to know even what
methods should exist. In PHP, it's perfectly reasonable to say strlen(1). Does
that mean every number should have string methods? I'm guessing you never
considered that?

> The problem with mysql_escape_string was that it didn't take the current
> database handle into account.

Yes, because the encoding properties of the current database connection are
needed for encoding properly. If have two database connections, then what? It
picks the first connection as the default and you encode incorrectly? Or if
you had a second connection, do you just break all the existing code? What if
the second connection doesn't happen every time? Then you're code is broken
only every second Wednesday?

You've got a very singular perspective on things. That's fine. But by
critiquing another language without knowing it you're making a lot of
assumptions and blowing things way out of proportion.

~~~
eevee
> No, Java is not the same. Scalars not objects in Java and are passed by
> value.

How are pass-by-value and pass-by-object distinguishable for immutable values?

> That's not what we were talking about.

Yes it is. You said (array) as a cast is useful because a function can accept
either a single value or an array of values, and the (array) cast will produce
an array either way. I contend that doing this doesn't really work, because
passing a single value _that happens to be an object_ will cause the function
to cast it to an array of the object's contents, which will have fascinating
but useless results.

> You cited byte-code interpreted as if that's somewhat significant.

I only mentioned bytecode for the sake of pedantry: strictly speaking Python
isn't interpreted, whereas e.g. shell is.

> You could read the manual.

I had to do quite a lot of that. It's kind of wordy. :)

> Most languages make the distinction. Why shouldn't there be? That's really
> ugly code.

I'm not proposing that people write code like this. I'm objecting to the
inconsistency between a value in a variable and a value in source code.

Note that, for the same reason, you also can't chain calls like `foo()()`.
There ARE good reasons for that: you could return a function name, or a
closure, or an object that supports being called. But because the parser
doesn't just allow trying to use parentheses on an arbitrary value, this
doesn't work. Just like `foo()[]` didn't work until recently, because it too
had to be special-cased.

> That's fine. It doesn't mean every language should do the same. Most
> languages, especially those PHP is based on, do not do that.

Really? C doesn't have methods. C++ has methods, but string literals are C
strings so they have no methods. Perl doesn't consider builtin types to be
objects, but if you turn them into objects with `autobox`, methods work
equally well on variables and literals. Python allows method calls on literals
-- and will let you try to call them, but of course literal strings aren't
callable so this won't do anything. It _parses_ , though. Ruby is the same.
"foo".equals("bar") is a common Java idiom.

What language are you thinking of where there's a distinction made -- _in the
parser_ , no less -- between a variable and an expression?

> Maybe one day PHP will have that but because it's weakly typed, it's
> difficult to know even what methods should exist. In PHP, it's perfectly
> reasonable to say strlen(1). Does that mean every number should have string
> methods? I'm guessing you never considered that?

Sure, why not? Not that I was suggesting PHP direly needs scalar methods, but
if a number responds to strlen(), why not to ->strlen()?

> Yes, because the encoding properties of the current database connection are
> needed for encoding properly. If have two database connections, then what?

Then you're screwed no matter what Zend does and still need to fix your code.
So the options were: 1\. Leave the existing function totally broken. Create a
new one with a confusing and even longer name. Make everyone fix their code
and remember to use the new function in the future. 2\. Fix the issue in-place
for the vast majority of existing code. Make the edge cases fix their code by
doing the same thing they have to do with every other API function anyway.
Optionally, throw a warning when multiple handles exist and
mysql_escape_string is called with only one argument.

What, then, is the appeal of (1)?

> You've got a very singular perspective on things. That's fine. But by
> critiquing another language without knowing it you're making a lot of
> assumptions and blowing things way out of proportion.

I'm hearing this a lot, but (as far as I can be trusted to say this) I don't
see it. I draw a lot of comparisons to Python and Perl because they're in the
same family and I know more about their inner workings than anything else.
That doesn't mean they're the only languages I've used or the only languages I
think are worthwhile.

Yes, I picked on a lot of little things. It's the little things that _matter_.
Every language (ahem, most) has function calls, data structures, and loops.
What differentiates them is the little day-to-day stuff.

So what am I missing? What makes these design decisions _good_ , what makes
PHP great? I've heard a lot of defenses and a lot of statistics, but not too
many outright advantages. Most of your original response is just workarounds,
not reasons why the behavior is good or even acceptable. The image I'm left
with is that of an overgrown playground filled with active mines, but most of
the mines have upturned buckets over them so you probably won't step on them,
and that's supposed to make it a great place to send your kids. If even PHP's
supporters can do no better than explain how to write passable PHP when I have
a gun to my head, why would I want to use it?

~~~
wvenable
> How are pass-by-value and pass-by-object distinguishable for immutable
> values?

They aren't really. There's no real technical difference, just a terminology
difference. All that you need to know is that whether it be Python, PHP, Java,
or whatever that passing around scalars and objects works out the same.

> You said (array) as a cast is useful because a function can accept either a
> single value or an array of values, and the (array) cast will produce an
> array either way.

I never said anything about functions -- just that the cast itself is useful.

> because passing a single value that happens to be an object will cause the
> function to cast it to an array of the object's contents, which will have
> fascinating but useless results.

People cast objects to arrays in PHP _all the time_ because that can be a
useful operation. I understand you point, but I don't really think it's too
valid. If you're explicitly doing a cast, you should know what you're casting
from. This is sound advice no matter what language you're using.

> strictly speaking Python isn't interpreted, whereas e.g. shell is.

It's an implementation detail that's not significant. The next version of bash
should byte-code compile everything behind the scenes and run it (like PHP
does) and it wouldn't make any difference. You could write an interpreter for
C code (they exist) and it wouldn't change anything about C.

> Note that, for the same reason, you also can't chain calls like `foo()()`.

Honestly, there's no language grammar reason why that shouldn't work in PHP.
It's just that parser sucks and they're very slow/careful to make changes to
the parser. If it's a function name, a closure, or an object that supports
being called they're called the same. If you can do $foo() then you should be
able to do foo()(). The same is true about foo()[]. These things don't have to
special-cased so much as the parser has to be modified to be more generally
accepting.

> What language are you thinking of where there's a distinction made -- in the
> parser, no less -- between a variable and an expression?

PHP makes no distinction between a variable and an expression (except as
described above). It's make a distinction between scalars and objects.

> Sure, why not? Not that I was suggesting PHP direly needs scalar methods,
> but if a number responds to strlen(), why not to ->strlen()?

Then there's _really_ no point in having scalars be objects. You could add
syntactic sugar to make strlen($x) and $x->strlen() do exactly the same thing
but what would be the point? I'd rather they do something more interesting
with that ability. I think it's the only way they can successfully implement
unicode.

> Leave the existing function totally broken. Create a new one with a
> confusing and even longer name. Make everyone fix their code and remember to
> use the new function in the future.

MySQL made this decision, not PHP. They just give you the library to use.
Anyway, you seem to have a problem with the concept of backwards compatibility
-- it generally does mean "continue to use this broken thing because you don't
want to change your code".

> I'm hearing this a lot, but (as far as I can be trusted to say this) I don't
> see it.

Someone tells you that you lack perspective and you don't see it -- so ironic!
(I'm just being cheeky)

> I draw a lot of comparisons to Python and Perl because they're in the same
> family and I know more about their inner workings than anything else. That
> doesn't mean they're the only languages I've used or the only languages I
> think are worthwhile.

Yes, but going off on public/protected/private as if it's a flaw in PHP
because _you don't like them_ is not a valid critique. That's just one example
but there are others. Even saying everything should be an object is more
personal taste than anything else. I very much like "everything is an object"
but it's not clear how best to implement that in PHP yet.

> It's the little things that matter. Every language (ahem, most) has function
> calls, data structures, and loops. What differentiates them is the little
> day-to-day stuff.

I disagree. I think I probably switch between languages a bit more than you do
and the little things don't matter that much. What matters is the big things.
Most of the stuff you mention in your article, if I encounter them at all, I
don't even notice. It's such a non-issue that unless you bring it up, I
wouldn't think to tell you. In fact, in some cases, I wasn't even sure what
you were talking about because I don't encounter them (the lack of stack
traces on errors, for example).

> I've heard a lot of defenses and a lot of statistics, but not too many
> outright advantages.

Indeed. I'm not saying PHP has advantages over other platforms -- it has some
-- but, in the end, the differences between any of the platforms aren't
significant and mostly personal taste. I continue to code in PHP because I
know PHP, I know the frameworks, and I have lots of existing PHP code. If I
had to write Python or Ruby, I would. I'm going to be writing ASP.NET code for
next 6 months.

I just think your article blows everything out of proportion. Much of it is
"look how this crazy unreasonable code reacts in PHP". It's not invalid but
it's not really indicative of developing in PHP. Similar lists have been made
for JavaScript and yet that doesn't affect opinions too much. Similar lists
have been made for C and C++ but everybody knows what they're getting into
there.

Here we are talking about mysql_real_escape_string() and that's as legacy as
you can get.

------
peterhunt
Obviously we need to write a Python interpreter in PHP

------
ShaneCurran
PHP is epic. Nuff said.

------
papsosouid
>The best way to combat something as pervasively and institutionally awful as
PHP is not to point out all its (many, many, many) faults, but to build
compelling alternatives and make sure these alternatives are equally
pervasive, as easy to set up and use as possible.

This is clearly not the case. The alternatives are already compelling. They
are equal to or better than PHP in every single respect. Yet they are not as
widespread. The idea that pointing out the flaws of PHP doesn't help is
absolutely incorrect. Demonstrating the flaws of PHP, and the practical impact
that has on producing useful software has been very successful for me in
convincing PHP users to try something sane. I find only a very small minority
of PHP programmers are actually unwilling to try anything else, most of them
will give something else a shot if you simply demonstrate why it is in their
best interests. Some people certainly get upset when you point out that they
are using a bad tool due to ignorance of better tools, but most are able to
get over themselves and realize the better tool will make their life easier.

The overall effect of convincing individuals to use better languages is that
those alternatives do become as pervasive as PHP. How does someone say "I want
the alternatives to be as pervasive as PHP" right after saying "stop trying to
make the alternatives as pervasive as PHP" without realizing how ridiculous
that is?

