There’s a reason PHP “lives in the past”

One of the reasons PHP has a completely awful reputation is that a not-inconsequential number of its core users – people either with commit karma or enough pull to influence decisions on internals – revere backwards compatibility as the most holy thing.

Today in awful BC reverence and general WTF are you thinking? we have phpclasses.org and the blog post, “The Plot to Kill PHP MySQL Extension“.

The summation part is pretty accurate, but then goes wildly off the rails in “The PHP 5 adoption fiasco all over again?”.

So what was wrong with PHP 5? Many details, but I think I can sum it up to not being 100.0% compatible with PHP 4. Nobody wants to change code that just works.

If by “just works” you mean any number of things – possibly host to SQL injection or XSS attacks, awkward or inefficient to maintain due to poor design, or unable to take advantage of useful features added to the language, sure.

In many cases, code that was running well in PHP 4, would still run well on PHP 5, except that it would probably throw many deprecated syntax notices that only seems to make it look like the code was wrong, despite there was nothing wrong about it.

Except there was something wrong with it: its features were deprecated. The exact why varies with feature to feature, but the bottom line is, these features are no longer desired in PHP and will be removed in the future without notice, or in general, however it used to work was wrong or bad or we just felt like changing it.

A BRIEF SIDEBAR ABOUT HOW THE PHP CORE GROUP ADDS FEATURES TO, AND REMOVES FEATURES FROM, THE LANGUAGE

Simply put the core group is driven by consensus. There is no BDFL. Decisions are made by vote, generally based on RFCs and patches submitted to the group and stored on the wiki. Zend, “the PHP company”, has no special say in the direction of PHP (although Zeev and Andi have commit karma, as do several people who work for Zend in some capacity).

It is said that you can’t participate in Internals unless your shit-slinging arm is strong. This is true. It’s a blessing and a curse, like most open source communities. Discussions can get hot-headed and end up so far afield of what’s being discussed, the entire point is lost and it’s highly unlikely the feature/bug/whatever will get the attention it otherwise might merit. On the plus side, these arguments can sometimes produce a lot of interesting debate and thought about how people actually use software in the real world. One of the merits of PHP is it’s not driven by an academic’s desire for “purity” or a company’s desire to meet a checklist of features for sales sheets.

Yes, namespaces arrived way too late and closures are a half-ass implementation, but it more-or-less works as well as most other stuff out there, when used in a safe and sane manner.

ANYWAY

So these features, marked as deprecated, somehow survived the shit-storm that is internals. Agree or disagree, the community came to a consensus: something is wrong, and here’s how we’re going to change it. They produced good enough code with few enough bugs, and it made it in.

The author then goes wildly off the rails:

PHP core developers wanted everybody to replace var class variable declarations with public declarations. You may ask: what was the point of that? In my opinion, none.

You’re high as a kite. Have an argument about the usefulness of visibility in methods and properties, but that’s the point.

The author then goes on to ramble about property visibility, and throws in one of my FAVORITE bugaboos from Internals:

It introduced theprivate and protected declarations, so the old var declarations should be replaced withpublic to be more consistent. Be more consistent with what? Java, I suppose. But PHP is not Java.

(Emphasis mine).

If I was in the mood to enter an Internals-like shit-slinging contest, I’d say something along the lines of, “Oh, blow it out your ass, I can name half a dozen OO languages with property and method visibility, you’re picking on Java because Java scares the peons”. Or something like that. Then I’d get banned from Internals for being a dick.

I don’t know why people on Internals (and elsewhere in the PHP community) through around Java as a hand grenade. Java has its problems – oh boy does Java have its problems – but, like PHP, the language, class libraries, the JVM, all that falls under the Java moniker, works well in lots of different ways to solve lots of different problems.

And to me, PHP is really a scripty, slightly insane servlet platform. The two share a lot of similarities, more than a lot of people are comfortable admitting.

Moving on:

So, is this PHP mysql extension deprecation really necessary. I don’t think so, but that is just my opinion. At most it will avoid the need to maintain the documentation of multiple extensions to access MySQL databases.

Yes, it has nothing to do with weaning a generation of fragile brains off the idea of

select * from foo where id=$_GET['thingee']

and using prepared statements (standard in PDO). Nope, none at all.

But wait, there’s more!

So, for the PHP developers that have old code to access MySQL databases this idea will not be beneficial at all. Once the deprecation becomes official, it will start annoying PHP developers that do not want to waste time rewriting code that always worked for many years.

It took me perhaps an hour in BBEdit to upgrade our old-ass PHP4 app to use MySQLi. PDO might take a little longer. In other words, cry me a fucking river.

So I am afraid the first PHP version that introduces this deprecation will suffer from the same adoption delay problems as PHP 5.

What, “OH NOES, I might have to change something!”?

PROTIP: using the fine PHPUnit code lets you test things. It’s really cool. But then again, it uses those scary objects and it’s strongly influenced by Java and its unit-testing practices, and as you said, PHP is not Java. So I guess good unit tests are a bad idea for PHP, too? Not using unit tests in my shop is a great way to get your ass fired.

I believe that conservatism with respect to software platforms is always a good, default stance. Don’t make changes for the changes sake, or because something happened to be fashionable enough to end up on Reddit and Hacker News. But this is a forward-thinking business and our job is to invent the future.

And for FUD’s/fuck’s sake, this discussion is not even about ending PHP’s support for MySQL as some people seem to think. We’re talking about ending the PHP4-era MySQL code in favor of the code the community has reached a consensus about as betterfasterstronger.

Engineer the future now. Yesterday’s for mice and gods. Knock it off with the BC holy writ. Get over it, PHP4 sucked.

About these ads

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s