
Ewww, You Use PHP? - niekmaas
http://blog.mailchimp.com/ewww-you-use-php/
======
apinstein
As another startup in Atlanta trying to hire _good_ PHP developers, I can
sympathize entirely with MailChimp on this one. I have been searching for
months for local PHP developers with _experience_ doing TDD or other
agile/modern practices and it is extremely difficult. If you are one, please
feel free to contact me.

I think good TDD/agile/architecture cultures are more prevalent in ruby/python
but as those languages have become more mainstream the quality of the average
dev in those environments has dropped quickly. A few years ago only really
good devs ventured into ruby stuff. Now everyone is trying it as the tools
have made the language much more accessible for the average developer. I am
seeing more and more programming mistakes in the ruby code I dive into than I
used to.

Language choice doesn't matter too much from a technical perspective. It
matters from a practical perspective. Consider the jQuery/prototypejs war.
Prototypejs was technically superior for a long time, yet due to jQuery's more
accessible plugin culture and prettier web site they were over time able to
build a more robust community and took the mindshare lead in the js space. I
still think one of the core reasons ruby/rails and python/django got big is
that for a long time there was only one major framework available for the
language and this caused a better community than the php landscape, which pre-
dated frameworks by a long time (this happened to perl as well). So there
wasn't "one true way" in php to build apps quickly, and this hurt the php
community when rails got big. I think as a community we lost a lot of talent
to ruby/rails in the last few years.

Bottom line is that accessibility, pervasiveness and low-learning-curve are
critical to the initial and continued success of any platform, whether it's a
language (ruby > php > perl), OS (ios > android > rim), etc.

Language advances in PHP (circular gc, traits, closures, etc) have brought
php's language capabilities forward enough that it's a respectable platform
for sticking with. However, you can't fix the community really since it's so
fragmented. Fortunately some frameworks are getting enough traction to have
rich ecosystems, and that's definitely a great thing for the language and the
community.

~~~
simonw
"Prototypejs was technically superior for a long time"

Can you expand on that at all? What made Protoype technically superior?

~~~
apinstein
In addition to the functional programming techniques it offered (which are now
handled by underscore in the jQuery landscape) its selector was much more
performant than jQuery's for a long time.

------
tibbon
My main beef with PHP is that the most deployed applications that use it are
some of the most difficult to manage and messy pieces of code that I've ever
seen.

I'm talking about Wordpress and vBulletin.

While MVC isn't the only valid design pattern, some varient of it is rather
nice when working with websites and these two seem to ignore it through and
through. Testing? What's that?

I know that better can be written in PHP, but for apps that I've had to deal
with, PHP normally looks like an overpowered scripting language that's just a
mess. I'll stay with Rails and Sinatra when I can.

~~~
naz
Don't forget Mediawiki. Try to decipher the source to their wiki markup parser
(or try writing a compatible one). Shudder.

~~~
JonLim
Having recently created a theme for MediaWiki and then reskinning that theme
for another install, let me just say... it is frightening.

MediaWiki is all over the place and the themes included in the install are
just horrifying. Whoever made the original (monobook) theme should get slapped
in the face.

------
maratd
For many years now, more and more code has been moving to the client side. At
this point, for me, PHP is just the glue between the database and the client
side code. There's nothing left to hate. Move on already.

~~~
rbanffy
There still has to be a lot of glue logic on the server. When your client-side
code calls something like "validate_purchase" on the server, you'd better have
some trusted code handling that.

~~~
maratd
> When your client-side code calls something like "validate_purchase" on the
> server, you'd better have some trusted code handling that.

Why am I calling "validate_purchase" on the server?

Client Clicks Buy -> JSONP to Payment Gateway -> Gateway to Server (with all
the info) -> Server to Client Confirming Transaction

All my server is doing is recording the transaction and forwarding the info to
the client. The gateway is trusted, since they are processing payments.

I'm serious. This is where we're headed. Yes, you will have a hell of a lot of
server-side code on the gateway, but that's a service, not the application.

~~~
amalcon
Your payment processor isn't going to know how much anything costs. You'll
need some (server-side) validation logic if you don't want people buying new
high-end smartphones for a penny. Which event invokes that logic is
immaterial.

~~~
maratd
> Your payment processor isn't going to know how much anything costs.

So?

> You'll need some (server-side) validation logic if you don't want people
> buying new high-end smartphones for a penny.

That validation logic should be expressed in SQL. It's really really simple.
If inventory id and price match in your inventory table, insert into your
transaction table.

Again, see my original point. PHP is just the glue for the database.

~~~
pak
Hmm. Not to nitpick, but what if:

\- you're running a promotion

\- the price changed in between the time the person added it to their shopping
cart and checkout

\- two people are processed for a payment on the last item in inventory at the
same time

\- there are different options on the item, e.g. color, that change the price

\- other people bought the last item in inventory already, but there's an
equivalent product at the same price

\- the person bought the product using a combination of real money and gift
card money, which the payment processor does not handle

\- the person bought other things in the same transaction, e.g. a gift card,
that do not have an inventory ID

Those are just a few cases off the top of my head, but the short end of it is
that expressing all of this with a combination of SQL and client-side logic is
just madness. If you're saying that we don't need to write business logic in
PHP any more, I think you just don't work with the same constraints that most
businesses do.

~~~
moheeb
All of these, save for the payment processor one, can and should be done in
sql.

I think you are uncomfortable with SQL.

Ultimately it is the designer's choice where the business rules are
handled...but to abstract those rules to levels above where the 'business'
actually happens seems like a poor practice.

~~~
pak
'Business' does not just happen within the database! You will have to perform
logic based on events that occur elsewhere, e.g. on the network or within
outside data sources! And to say that something should be done in SQL just
because it can is patently absurd--do you know how much performance suffers as
soon as you start roping in subqueries and calculated values? Half of the
things I listed would require stepping outside of indexed columns in awkward
ways--that was kind of my point. Good luck keeping that performant past a few
million rows.

In fact, I would love to see you design a query that _branches_ on the
condition that the item is out of stock and automatically returns the top 3
equivalent parts for each brand using a junction table containing
equivalencies, ordered by a column in the junction table containing the
closeness of fit. Go ahead, humor me. Then try to pretend that that query will
ever stand up under scale.

------
creativityhurts
This was on HN already 9 months ago
[http://www.hnsearch.com/search#request/submissions&q=eww...](http://www.hnsearch.com/search#request/submissions&q=ewww&sortby=points+desc)

------
KnightWhoSaysNi
PHP has its faults, but it also has dead-easy deployment, cheap and reliable
hosting, good documentation, and an excellent community.

~~~
masklinn
> it also has dead-easy deployment, cheap and reliable hosting

Matters for a single 15 years-old developer. Deployment is never easy when you
get do anything non-trivial, and the cheap hosting... hosting for other
languages start at $5 or $10... The only cheaper hostage PHP has is free.

> good documentation

That's highly debatable. I've also seen the PHP doc comments being pimped, I
could never find anything worth more than a laugh in that cesspool.

~~~
KnightWhoSaysNi
Regarding hosting I wasn't just talking about shared hosting. Setting up a
LAMP VPS is just a couple of clicks. Compare that to setting up e.g. Django or
Rails. I personally love Django, Flask, etc., but setting up a website is
still faster with PHP (depending on your setup, of course).

~~~
encoderer
I like PHP just fine, but what you just did there, was compare a language--
bundled with apache even--and compared it to 2 frameworks.

It's just as easy to get mod_python working as it is mod_php.

~~~
KnightWhoSaysNi
To use WSGI (which is what most people would use instead of mod_python) you
have to write some lines in your server configuration plus a script that loads
your framework of choice.

Compare that to getting CodeIgniter up and running: SFTP the files into the
server, and you're up. No server configuration needed.

One could argue that this is not a feature of PHP itself, but that doesn't
change the fact that "normal" PHP solutions are simply faster to get up and
running.

~~~
encoderer
(Read my tone here is debatish and not di^kish plz)

In what circumstances does the fact that a _Hello World_ can be setup in 5
mins versus 10 actually matter?

We spend _thousands_ of hours developing software.

Five mins versus 10 is truly moot.

Besides, you're going to get into httpd.conf to configure a vhost before long
-- mod_php or mod_wsgi -- so it's not as if it's a hands-off experience with
PHP.

------
saibotd
PHP is what I've started with and after many projects in Python and Java I
still come back to it whenever I need to get stuff done. I mean look at the
array functions (<http://www.php.net/manual/en/book.array.php>)! Some consider
this bad design, but I love this about PHP.

~~~
generalk
There are some good reasons to like PHP but the array functions in the
standard library are not one of them.

* Arrays are created with array() as opposed to a more modern [].

* Arrays are not objects, so you have a ton of functions in the global namespace starting with array -- array_join() as opposed to $array->join().

* The functions are not consistent. Half of them don't have "array_" as a prefix. The order of arguments isn't consistent with other parts of the standard library.

I'm really curious about why you consider this a strong point of PHP.

~~~
sequoia
I hear what you're saying about arrays not being objects and there's really no
excuse for the conflicting ($array, $argument) & ($argument, $array)
signatures of many functions, but regarding "array() as opposed to a more
modern []:" whenever I read this I can't help but think "Who fucking cares??"

When people want to pick nits about this or significant whitespace it makes me
think that there must very little variance between the languages if THIS is
the issue that deserves scrutiny. Am I missing something about array() vs [] ?

if you really hate typing array(), <http://codepad.org/ASREdjTK>

~~~
Androsynth
This is one thing that really bugs me about the arguments against php. The
language has _fundamental_ flaws. Poor oop, no functional programming
whatsoever, minimal reflection.

Finding the argument order for a method takes ~3-5 seconds. Its irrelevant.
array() vs [] is actually a bigger deal as its indicative of php's verbose
syntax. But its not a killer.

People like JS because it got the fundamentals right. The bad parts are just
details. PHP is bad because it got the fundamentals wrong. But people still
harp on the details.

~~~
generalk
Yes, PHP has fundamental flaws. But the only decent fix for that is to use a
different language, and there may be many valid reasons why a developer is
using PHP.

But the "details" grate daily. Poor reflection, no FP? Fine, you craft
solutions that don't require them. But having to look up order of arguments
for standard library functions is a pain in the ass.

------
skrebbel
The problem with PHP isn't so much PHP itself as the shares of bad
programmers, libraries and examples out there.

Awesome PHP is awesome.

~~~
Androsynth
Any examples of awesome open source php examples? (real question, not a snide
remark)

~~~
knieveltech
Drupal. Recently rumored to platform 1% of all websites. The codebase is clean
(even cleaner in Drupal 7), and naysayers be damned the hook system baked in
makes modular coding a breeze. Of course, code quality varies once you start
looking at community contributed modules, but that's to be expected.

Downvote? Really? Pfft.

~~~
eropple
Drupal's core architecture is extremely dated. You might like the hook system,
but it is in no way a replacement for dependency injection a la Symfony2.

~~~
knieveltech
Dated? By who's standards? Yours? The UN, NATO, Amnesty International and Sony
all disagree with your assessment.

~~~
eropple
Yes, by mine. I've spent quite a lot of time elbow-deep in Drupal. It is
better code than Wordpress--though that is damning with faint praise--but does
not really reach the bar of a Lithium or a Symfony2.

Now, it's certainly more normal-friendly than Symfony2 or the like by way of
allowing non-developers to implement (a subset of) features, but I wouldn't
call it programmer-friendly and I wouldn't use its internals as an example of
good code.

------
jinushaun
At least it's not ColdFusion... I'm convinced some websites out there use fake
.cfm file extensions as a joke. No way they're actually _using_ ColdFusion!

~~~
tobias3
CFScript is JavaScript (ECMAScript). Which means it actually should be cool at
the moment ;)

~~~
bad_user

          CFScript is JavaScript (ECMAScript)
    

No it isn't, by any stretch of definition or imagination.

In fact, I think Ruby has more in common with ECMAScript than CFScript does.

------
OzzyB
This seems to be a common essay from well-established companies who use PHP
and then write "oh gosh we use PHP!"

The key here, as it states, is that they "built their own
framework/libraries", which essentially means _nothing_ to indie-devs and
other small non-well-established companies who want to build something...

So the trend is simply this:

1) We use PHP because it's what we know, easy to get started with etc.

2) It gets us by while we build our business

3) Profit! Re-factor our codebase, in PHP!

Thus, the blog post should read: "Hey Mailchimp is doing awesomely, so we
refactored our PHP codebase with our very own custom framework!"

It's not that PHP is _all_ bad; it just lost the "framework wars" IMO, and I
think when companies come out and state things like this, it kinda proves
it...

~~~
middus
_The key here, as it states, is that they "built their own
framework/libraries"_ In the end, isn't that what everybody is doing anyway?

~~~
OzzyB
Well yes, when you speak to experienced PHP devs that's their response when
confronted with the "PHP sucks" argument -- they always say they have their
own framework/libraries, which don't suck and thus in turn "PHP is fine"...

I don't think everyone is doing that (building frameworks), or can, or even
should when they're other possibilities _outside_ of the PHP world...

------
naner
If you're in Atlanta you're near Georgia Tech. They're pumping out CS
graduates, have undergraduate students looking for experience, and also have a
pretty good internship program. It is not Silicon Valley but you're better
situated than a lot of other places.

------
j_col
Damn, long thread. I use Java, PHP, and Ruby: whever gets the job done in the
given problem domain. Not a fan of a technical monoculture at all. PHP has
been the language that is fashionable to hate for years now, but I still love
it for web apps.

~~~
troels
_I use Java, PHP, and Ruby: whever gets the job done in the given problem
domain_

I never really understood this argument. I mean, the overlap between Ruby and
PHP are so great that they are virtually interchangeable.

~~~
skrebbel
Wait, you can upload a .rb file to a random hosting provider and it'll _just
work_?

~~~
jrockway
Wait, you're eleven years old?

(Hint: copying files to a server is not how real applications are deployed.)

~~~
de90
Could you elaborate? My programming experience is just for fun\learning, and
I'm ignorant about this.

~~~
jrockway
You just bought your shipment of 1000 servers. Do you really think you ssh to
each one, edit config files, and copy your code over? Nope. You write a
computer program to do all that. (See: puppet, etc.)

At that point, it's equally easy to install a stack like haproxy + varnish +
nginx + a bunch of CPAN modules as it is to rsync over a bunch of .php files,
and therefore "it's easier to deploy" is meaningless. You click a button.

Not to pick on you specifically, but one argument that comes up quite
frequently, especially in PHP vs. X discussions, is "I don't see how xxx
feature of other language is beneficial." Well, the reason you "don't see"
that is because you simply don't have enough experience yet. Deployment is the
same way; a lot of people get by for years without ever "doing it right". But
that doesn't mean the wrong way is right, it just means you haven't been
required to get deployment right yet.

~~~
pak
>At that point, it's equally easy to install a stack like haproxy + varnish +
nginx + a bunch of CPAN modules as it is to rsync over a bunch of .php files

Ahem. I get what you are trying to say, but I think you're gonna have a hard
time saying that Ruby is as easy to deploy "right" as PHP. Rsyncing a bunch of
PHP files is a single shell command. Writing puppet or bcfg2 specs to deploy
your six-tier web stack for your RoR app is a bit harder, it is most certainly
not a button click out of the box, and neither process is necessarily more
"right". It certainly helped the PHP ecosystem that deploying a LAMP stack is
as easy as running three package installs and copying over some PHP files. The
fact that a simple-to-understand, well-established process will scale you up
to decent load before you need to get fancy will continue to make it an
attractive platform.

------
bufo
Nice idea and design, however chimps are NOT brown!

------
ristretto
PHP started at a time when web development was not considered "serious
programming". I mean, people switched to it from building GUI or console apps
on C/C++ and Perl. It was fast, efficient, had convenient hashtables and
defaults in place, and it was better than writing simple HTML files, but it
was still considered "scripting". Nowadays, web apps are a lot more
complicated, but web development is still messy: as HTML always stands in the
way, it's still hard to abstract the whole web development process without
restricting yourself to a specific mode of development and its limitations.

------
alecco
It's hilarious how most PHP programmers think they are exceptional compared to
the rest. While most of them rarely code in any other language besides
PHP/ActionScript/JavaScript/ASP. And virtually none of them read a serious
algorithms book.

------
pkkk
Java and JVM as reliable platform +1 just go whatever language you want Scala,
Haskell, Ruby... here language doesn't matter. If you want to create custom
web based application (not RIA one ofc) go django or rails, now it's more
matter of taste both choices will give you a lot benefits, and ofc you can run
it ontop of JVM. But if you considering building anything today on PHP (when
you have sooooooooo fucking many better platforms) you are incompetent and
plain stupid, because it will be a big technical debpt for the whole project.

~~~
snorkel
From the CTO perspective choosing a niche language is considered a much bigger
risk because when your lead developer gets bored and quits you then have to
scramble to find another lead dev who can quickly grab the reigns and
continue. I've talked to many a CTO who have mandated PHP for exactly this
reason, because you can throw a rock and hit a dev who knows PHP.

~~~
zeemonkee
Sure, but what's the chance you hit a _good_ dev ?

~~~
jasonlotito
Oh, a snide question deserves an equally snide answer. =)

Probably better than finding a _good_ dev in other languages for web
development considering all the good PHP developers are still using PHP, and
all the ones that couldn't cut it went on to learn the next LotM.

Honest answer: The same chance of hitting a good dev regardless of the
language.

