

Why PHP really won - wooby
http://alan.dipert.org/post/70990749/why-php-really-won

======
smoody
"why would I use PHP for anything more than toy projects?"

Clearly PHP can, and is, being used for projects that go well beyond being toy
projects. I doubt, for example, that anyone would call Flickr, Facebook, etc.
'toy projects.'

"But at my current job, I’m in charge of adding features and debugging a
massive functionally-written PHP codebase. It is horrifying."

Ah...there it is. His real complaint is about maintaining bad code and not
about a bad programming language. I would argue (and even wager) that equally
difficult-to-maintain code could be written in Java, Prolog, C++, Lisp, Forth,
and Logo (well, maybe not Logo).

I've written commercial applications in perhaps a dozen programming languages
(including Prolog) and I've had love affairs with them all and yet I'm using
PHP for my current project. But then again, I'm writing some great code and I
love maintaining it! :-)

~~~
natmaster
I interned at Facebook, and let me tell you, there weren't many people
enthusiastic about being stuck in PHP.

A lot of modern sites are in PHP, because that's what the best choice was when
they started (as far as they could tell), and now are stuck with that
decision.

~~~
fauigerzigerk
OK but look at this jobs trend line from indeed:
[http://www.indeed.com/jobtrends?q=PHP&l=](http://www.indeed.com/jobtrends?q=PHP&l=)

All those companies just got stuck and see no way out? I'm no devotee of PHP
at all, but just getting stuck isn't something that works for long periods of
time for so many new projects. These are websites, not core banking systems or
OS kernels.

I think the real reason for PHP's success is that PHP doesn't force people to
become software engineers when all they want to do is print some database
records on a web page. And it doesn't force employers to hire expensive
software engineers just to thrust software engineering complexity down their
throat when they really don't need any of it.

Believe it or not, there is still a great number of websites that are not web
apps and never become web apps. They just show you some pages of content with
some dynamic parts on some of them.

There's no reason for MVC, no reason for object orientation, no reason for
separation between designers and developers, no reason for ORM, no worries
about transactions, no interaction with messaging systems or other integration
stuff, no need for unit testing or mock objects, no need for 101 deployment
scenarios, no need for REST APIs, no need for maintainability because there
simply isn't that much code to maintain. But that's what 90% of RoR, Django,
JEE documentation is about.

People complain about atrocious PHP code. That's because some websites
"degenerate" into web apps over time. The majority of people who create them
are not software engineers and have no interest in becoming software
engineers.

And yes some of those "degenerate" websites are getting stuck with PHP. But I
think you would be mistaken to assume that all or even most of them go down
this route. Most websites just remain websites. Some do a rewrite. Others add
more interaction or features by installing one of those clunky CMSs. And the
CMSs are written in PHP to let the creators of websites (not web apps)
customise the system using little pieces of PHP, again without any need for
software engineering practices.

So if you need a taxi today, why would you hire an international logistics
specialist? Is it because you might get stuck with Beijing taxi drivers
shipping iron ore to your steel factory, or because you may never need iron
ore deliveries? I think for most users of PHP it's the second. They never do
complex web apps.

And all of that has nothing to do with whether or not PHP is suitable for
creating complex web apps using software engineering principles.

~~~
vlad
Great post, though it is hard to follow in some places. For one, the parent's
statement that "a lot of modern sites are in PHP, because that's what the best
choice was when they started (as far as they could tell), and now are stuck
with that decision," is logically sound, while your response that "there are
more jobs for PHP developers than ever" isn't mutually exclusive to the
parent's idea, so I don't see where he is wrong; as well, I think his post was
limited to putting in context the opportunities for coding what we consider to
be modern apps of today, back in 2003 and 2004.

~~~
fauigerzigerk
I'm not saying the parent is entirely wrong. I just expressed my opinion that
getting stuck is not the main reason for PHPs success, which is what I think
the parent was implying.

------
wvenable
This article includes the same false assumption of just about every other
article on PHP:

    
    
        PHP is Easy
    

I'm not sure how anyone can claim that a language which only exposes the
underlying C API of all the included libraries could be considered _easy_.
Does no one stop to think that the reason 99% of PHP code is bad is because
the language is actually _hard_? It's the C of scripting languages; it doesn't
include a lot of fancy constructs or high-level abstractions. And, like C,
that's what makes it powerful.

I think confusion exists because PHP is extremely _accessible_. It's
intimately connected with the web environment (more so, and less securely, in
the past) making it _quick_ to get started. But that has never made it easy.

~~~
anc2020
> I'm not sure how anyone can claim that ... could be considered easy.

PHP is Easy, and it's easier than Perl, I'd be surprised if you argue with me
on that. PHP has very little to trip you up mentally (or at least that was
definitely the case when it started winning). No closures, "arrays" are just
hashes etc.

PHP is not hard. Actually the hardest thing about PHP could well be its
dynamic variable names, like $$foo.

Neither is PHP powerful, it is extremely un-expressive when compared with just
about any other modern programming language.

With PHP you _just_ use the clean wrappers on the C API, and that is also easy
to do, no knowledge of C required at all. It's so easy you can pretty much
write PHP apps without knowing that "4" is any different from 4.

I don't know if I've convinced you, but honestly, I would have a hard time
making a language that was any easier.

~~~
wvenable
PHP is a simple language, but that doesn't make it easy. PHP does give you
enough rope to hang yourself, and unlike most other languages with a similar
property (like C, C++, and Perl) PHP gets too much blame for that.

I think Python is a far easier language. No $'s, much greater consistency,
more available abstractions.

You can pretty much handle most of the common complaints of PHP and build very
large complex code bases, however, you have to put in the work. Other
languages have that work already included.

~~~
anc2020
Ah, well this is where we differ, I'd say PHP is easy, not simple, and that
Python is simple not easy.

My reason for feeling that way hinges upon Python having more available
abstractions.

Scheme is an exagerated example of this. Continuations are a very simple idea,
you can describe call/cc to someone without much hassle. But the implications
of call/cc can be very difficult to grasp.

The closure is a lesser example of a simple, pure abstraction which allows
complex code through this devious form of simplicity.

So that is (pretty much) why it is very easy to reach expert level in PHP but
very very hard in Scheme.

At the end of the day, what's easier to learn: closures, or the fact that a
callback (in PHP) is supplied by giving its name as a string?

Its easier to not learn something than it is to learn it :)

~~~
wvenable
I think I can explain the problem. I taught PHP for a semester at the college
level to Web designers. I had 3 months (1 class a week) to get them from no
programming experience at all to having a small web application (a contact
list). Mostly they all managed to accomplish the task but obviously there's
only time to cover the minimum functionality necessary. In that sense, PHP is
easy.

Now, here's the problem, absolutely nothing they learned is useful for
building a reasonable-sized long-lasting web application. They didn't use any
classes. They didn't use a template engine. They didn't use a database
abstraction. They learned PHP but they didn't learn to use PHP to build real
applications. So all that easiness of PHP is all wrong. If you want to do it
right, it's not easy.

~~~
habibur
> They didn't use a template engine.

PHP is a templating engine. Writing a templating language for PHP, like
Smarty, is like writing a second templating language running on the first
templating language.

~~~
wvenable
PHP is a crappy template engine. Inlining code into an HTML document requires
a lot of discipline, a lot of code to write, and is error prone. Why not let
software handle that task for you? You want to create more work for yourself?

~~~
habibur
Don't want to inline code? Well don't inline code. No second templating engine
can reduce complexting any more than using PHP directly as a templating
language. PHP was built as a templating engine from day 1.

There is a reason why php scripts start with <? --- ?>

~~~
wvenable
"No second templating engine can reduce complexting"

Oh yeah, compare:

<?php echo htmlentities($firstName, ENT_COMPAT, "UTF-8"); ?>

with:

{$firstName}

Isn't that reduced complexity? And that's not even getting into other
constructs. In my template language (based on smarty), a single {loop} tag
expands to 10 lines of PHP code.

Would you also claim that no programming language can ever reduce complexity
over assembly language? Probably not. This is just the same thing. Compiling a
higher level language into a lower level language.

~~~
habibur
Well, here is what I would write:

Smarty: {$firstName}

vs

PHP: <?=h($firstName)?>

And, loops?

Your: {loop}

vs

PHP's loop: <?while(loop()){?>

Of course you have to define function h() and loop() somewhere. Just don't do
it in your template file and you are fine. Hardly saving you even one line of
code. We are down to counting how many charecters each need.

 _Would you also claim that no programming language can ever reduce complexity
over assembly language? Probably not. This is just the same thing. Compiling a
higher level language into a lower level language._

I woun't.

~~~
wvenable
"PHP: <?=h($firstName)?>"

Bzzzt wrong. And this is why having a template engine might be a good thing.
<?= isn't 'safe' because it can be disabled in the php.ini file (and is
disabled by default). If only you had a template language that keeps you
having to know that! Also, the default is that your html escapes -- you can't
forget to wrap your variable in the h() function. So it's already less error
prone. And this is still just a simple example.

"PHP's loop: <?while(loop()){?>"

It's at least <?php while(list($key, $item) = loop($iterator)){?> to be
correct and useful. And the template engine can inline the code (rather than
call a loop() function) for better performance.

All those correctly expanded PHP tags intermixed in the HTML makes the
template harder to follow. You might want to type twice as much identical code
for each output variable, but I don't want to do that. It is an advantage that
it's cleaner and clearer.

~~~
habibur
_<?= isn't 'safe'_

This is a web app for God's sake. You have full control on what your php.ini
have. Which one is more complex? Install a templating language? or ensure your
short-tags=On (or whatever that is) in your php.ini. And if you are talking
about hosted service, short tags are by default kept "On" on most hosted
services, if not all.

 _<?php while(list($key, $item) = loop($iterator)){?>_

No, I can write any of the following if I want the variables localy.

<?while($r=loop($rs)){?> <\---- this is the version I use most frequently.

<?foreach($rs as $key=>$item){?>

or even

<?while(extract(loop($rs))){?>

Now compare all these with any other language beside PHP. Java, C# or Python.

response.write "<html><head><title>" + myTitle + "</title>";

response.write "<body bgcolor=\"white\">";

while(loop inside iterator){ response.write "<tr><td" + print_var; }

Imagine typing your full page like this! You need to enclose each of your line
inside a quote and also escape all quotation marks inside it. Here code and
design are mixed in real sense. These are the languages that really need a
templating engine.

 _And the template engine can inline the code (rather than call a loop()
function) for better performance._

Here is an idea, better performace is gained by not loading the templating
engine at all. Whatever number of chars typing saved is more complicated by
loading and initializing the whole templating engine. Even that is not enough,
which is why Smarty has {if}, {else}, {switch} statements. So long for
seperating code and design.

 _You might want to type twice as much identical code for each output
variable_

I am not typing identical code even once.

 _If only you had a template language that keeps you having to know that!_

We can continue discussion without making attacks? No?

~~~
wvenable
"You have full control on what your php.ini have."

If you're writing, for example, an open source application or an application
that is hosted by your customers (I have worked on both) you can't assume you
have any control over the php.ini. The recommended php.ini file has
short_open_tag disabled and having short_open_tag enabled makes it more
difficult to use PHP to template XML files. It's not deprecated yet, but I
wouldn't count on it sticking around forever.

All my PHP software works irregardless of the php.ini settings and works
across all platforms. If that's not a concern of yours, that's fine. We just
have different requirements.

"<?while($r=loop($rs)){?>"

You're making the assumption that my template constructs are just simple
1-to-1 mappings to PHP statements but that's not the case. My {loop} tag gives
access the previous entry, whether or not the row is odd or even, whether or
not it's the first and last entry, etc. It's a very powerful tag for the kind
of common tasks that come up in a web application. But that's just one
example, there's also tags for caching template blocks as well as tags for
interactive controls. The level of complexity that's hidden behind a few
simple tags is enormous -- which is entirely the point. I have lots of code
which uses PHP itself for templates so I'm aware of the difference. I didn't
start using templates, I started the other way and worked towards using
templates because they make the job easier and quicker.

"Here is an idea, better performace is gained by not loading the templating
engine at all."

For a compiling template engine, there's the initial cost of compiling the
template when it's been changed but then there is very little additional cost.
It generates a regular PHP file that's run just any other. Once the app has
been running for a few minutes the template engine doesn't need to be loaded
at all.

"We can continue discussion without making attacks?"

That wasn't an attack. I was making a point -- the template engine insulates
you from all kinds of problems. If you forget to wrap some variable in your
h() function, you might never even notice. However you've just opened yourself
up to a cross-site scripting attack. And even if you never make mistakes ever,
you might not be the only one working on it.

------
kwamenum86
"Did PHP really win?"

Yes, for now. It is probably the most widely used language for web apps right
now.

Anyone who calls PHP a toy language is not skilled enough to write anything
better than a toy in PHP. It is not really a criticism, just an observation.
Until you become skilled enough in any language you are pretty much doing
fancy versions of Hello World. With many languages the skill of the programmer
matters more. For example, I am still struggling to understand why I would
ever use functional language for anything but that is a) because I haven't
needed it yet and b) I haven't taken the time to acquire the knowledge and
skill needed to write anything more functional than toys.

------
jcl
Perl: the language of "geniuses and academics"... Was it ever actually
perceived as such? Or was the author simply intimidated by other, more
academic languages as well? I'm pretty sure Perl doesn't do tail-call
optimization like the article implies.

My impression of Perl was always as a practical, "get-'er-done" language, much
like PHP -- and prone to the same legibility/maintainability problems if care
was not taken.

------
bprater
Mmm... Matt's Script Archive.

Good ole days.

------
vaksel
I'm still waiting for a post to get frontpaged titled "Why PHP didn't win"

------
wenbert
I really do not understand people reacting violently on how "PHP
sucks/horrifying". PHP is just a tool that people use. Blame the programmer
not the tool. I have had encounters with horrifying code with a lot of times
BUT most of my complaints were on bad design and how programmers badly handled
their code.

"Being mindful of best practices in software development fundamentals can be
more effective than adopting every latest technology." - Bill Karwin

------
grandalf
Did PHP really win? I haven't used it in about 4 years.

------
th0ma5
this is accurate. this is how i felt. php was a statement, and asp and
coldfusion at the time perhaps were right there, too, but each had their tie-
ins and paradigms, and php seemed to be positioned in opposition to that. and
i agree anymore it would be best if it is in java or python or something if at
all possible, way more maintainable.

------
lallysingh
I'd submit that PHP is for this generation of programmers what BASIC was to a
lot of the older generation (including me).

I started on BASIC on a Trash-80. Actually you can probably substitute some of
the terms in this blog post for my journey from BASIC to now.

------
owkaye
If you want easy, quick and accessible all rolled into one, try WebDNA. Nah,
on the other hand I think you 'real' programmers would not be interested in
using such a simple tool.

