PHP is Dead
PHP is dead. Probably.
Allow me to preface this with some context. I <3 PHP. It’s probably my favorite language for a variety of reasons, but the number one reason being I’m pretty expert at it. But I’m not above recognizing that the majority of PHP programmers are generally idiot script kiddies, and don’t know how to write code that is not terrible. In that way, all PHP programmers get a bad name, because, like in all other aspects of life, the morons far outnumber us geniuses. It’s our cross to bear.
Anyway, PHP is dead. Probably. Here’s why.
PHP is Stagnating
PHP 4 was released in May 2000. PHP 5 was released in July 2004. PHP 4.4 was released in July 2005. PHP 5.3 was released in June 2009.
These dates are not enumerated here to poke fun at the slow release cycle of PHP (I’ll get to the core team later). Rather, it’s to illustrate a point. Here are some numbers that I pulled from some random data dump from some non-English site that’s probably totally legit:
SELECT SUBSTRING(libelle, 1, 1) `php version`, SUM(nombre) `count` FROM stats WHERE libelle REGEXP '^[3-6](\\.\\d(\\.\\d)?)?$' AND `date` LIKE '2008-10-06%' GROUP BY SUBSTRING(libelle, 1, 1)
php version count ----------- ------- 3 8096 4 2396211 5 1977067 6 23
If it’s not abundantly clear to you unwashed masses what a “libelle” is, I’m pretty sure that’s “label” in some kind of European language. The dataset represents a census documenting what technologies people use to power their sites. Basically, this query is saying that in October of 2008, 2.3 million people used PHP 4 on their website and 1.9 million people used PHP 5 on their web site.
At that time, PHP 5 had been stable for 4 years, and PHP 4 had been stable for 8 years. Their usage in production is pretty much even. PHP 5 added a lot of features, such as, you know, object-oriented programming. And yet it takes ten years (and counting) for PEAR to get off their asses and convert their code to PHP 5.
For those who don’t know, PEAR is the PHP Extension Application Repository. It’s a packaging mechanism similar to yum or apt-get, as well as a repository for extensions to the PHP language written in PHP (as opposed to PECL, which are extensions to the PHP language written in C). It defined a coding standard, and generally did a lot of good for the PHP community, except that it’s written in freaking PHP 4, and the coding standard is embarrassingly terrible.
For example, they prefix member variables with underscores to indicate that it’s not public, since PHP 4 didn’t have the notion of member variable accessibility. PHP 4 also didn’t have the notion of static. You should see the way they implement the singleton pattern in PHP 4. It’s pretty hilarious.
PHP 4 also didn’t pass objects by reference. That means you manually had to insert ampersands everywhere to make sure that your objects wouldn’t be treated like a value type. And when I say everywhere, I mean everywhere. This is a very common occurrence in PHP 4:
$myReferenceType =& new AwesomeClass();
DEAR GOD YOU COULDN’T EVEN USE THE NEW KEYWORD WITHOUT EXPLICITLY DEFINING THE REFERENCE. WHY ARE PEOPLE STILL USING THIS VERSION OF PHP?
This is all a long way of saying that PHP 4 is hideously outdated, both in calendar time and technologically, and yet it remains very prominent. I die a little inside when I see someone using a host that’s rocking Apache 1.3 and PHP 4.3. It’s like seeing someone using the cgi-bin directory. Aren’t we past that yet? This isn’t 1997 anymore.
The same argument goes for PHP 5.3 as well. It added some sorely missing features, such as namespaces and true anonmyous functions, as well as a plethora of classes in the SPL, and yet no one is upgrading. It’s been a year, and people are still creating classes called Awesome_Controller_Abstract instead of using namespaces like a normal person. It’s heartbreaking.
This is what will cause PHP to always be slightly behind the curve technologically: its users’ snail’s pace upgrade rate. Eventually, its one strength, the extremely low barrier to entry, will be nullified as other languages figure out how to be more accessible to the masses.
The PHP Core team is separated from reality
So, I imagine this is a problem for a lot of languages, and I’m definitely making unfair blanket statements, but I want to bring it up for one very specific reason. Try to read the next sentence without laughing.
In PHP, the namespace separator is the backslash.
You laughed, didn’t you?
Allow me to give a bit of backstory without citing any sources.
There was fairly raging debate among the core developers on what to use for the namespace separator in the months before PHP 5.3 was released. You see, it wasn’t as simple as you might think, because PHP isn’t primarily an object-oriented language.
The original solution was to use the paamayim nekudotayim (scope resolution operator, but the Hebrew version is way cooler) as a namespace separator. But oh no! That caused problems in situations like this:
//bar.php
namespace Bar;
function foo() {}
//meanwhile, in baz.php
require_once bar.php;
class Bar {
static function foo() {}
}
Bar::foo(); //which foo gets called? in the Bar namespace or in the Bar class?
So, the core team realized they had a problem. There were several solutions:
- Only apply namespaces to OO code (classes, interfaces, etc.)
- Change the namespace separator character to something unambiguous
Hindsight is always 20/20, but the second option there seems pretty retarded to me. It’s hard to find an unambiguous character in any language that has previous releases, because they’re all being used. What happens is you’ll end up choosing a character that’s hard to type (i.e. one you have to press shift for), or you’ll choose something that’s unambiguous technically (meaning not significantly used) but has ambiguous semantics (like, say, the escape character in every language besides T-SQL).
At one point, the core team actually created a matrix where each row was a different character (I think the triple colon was in the running at one point, which would probably be even more awesome when translated to Hebrew), and each column had funny stuff like “is hard to type” with a numeric value. The last column summed up the numeric values and the row with the highest number was the winner. It was all very democratic (THROUGH PURPLE MOUNTAIN MAJESTIES…).
The backslash won.
Well, kind of. Pretty much everybody who typed code for a living hated the backslash because, you know, IT’S THE BACKSLASH. Nobody wants to look at that.
But PHP is an open source project, which means most or all of them don’t get paid to work on it, so that means that the easiest solution will win. And in this case, the easiest solution was the one that was already done. One of the core developers got tired of the bickering and the matrices and the Hebrew and he spent a weekend implementing the backslash namespace separator and committed it to the branch. Then he wrote tests covering all possible cases, and created a patch against trunk.
He had everyone at “tests” and “patch”. And that’s how the backslash became the namespace separator for PHP.
This was all a a long way of saying their decision was made with their brains instead of their guts. If they used their guts, they would have realized that NOBODY GIVES A CRAP ABOUT NAMESPACES EXCEPT PEOPLE WHO DO OBJECT-ORIENTED CODE. Nobody cares if the 4000 lines of random functions in stuff.php is in a namespace. The only people who care about namespaces are those that experienced it in another language (like say, an object-oriented language) and would want to apply the same organizational structure to their PHP code. And those people are only writing classes and interfaces.
Ergo, they should have ignored the collision issues illustrated above, only applied namespaces to classes and interfaces, and rocked the PAAMAYIM NEKUDOTAYIM like it was going out of style. But since the PHP core team are experts in C, not PHP, they didn’t really realize this.
Instead, we are condemned to a life full of backslashes. I’ve already started a support group.
PHP 6 is a disaster area
I don’t have a lot to say about this, except that it seems like it’s an absolute disaster. The main thing going on in PHP 6 is unicode support.
yay.
I’m not totally sure why that’s so awesome, but it’s a lot of work, and it isn’t going well. Again I’m not going to cite any sources, but it’s been in the works for about two years to add unicode support to PHP, and I don’t think it’s very close to being done.
The problem seems to be that they can’t just add unicode support, because every extension would be incompatible. So they’re trying to retroactively add unicode support to everything at once, which is as terrible as it sounds. I could be making all this up, but it sounds similar to something I might have read once.
Basically, they’re attempting to add a feature that will be of minimal value, and it’s taking forever. Instead, they could be adding cool things, like some of these:
- C#-style properties
- Auto-boxing
- Traits
- Enumerations
- Function call chaining (oh god yes)
- Static classes
In Conclusion
PHP is dying. Probably. I hope I’m wrong, because I think PHP is a very expressive, convenient language. It has, by far, the best function library of any language. It also has, by far, the best documentation of any language, as well as a giant, open community around it. For those reasons, I hope it doesn’t die. But I’ve seen little evidence that it’s not going to march straight to hell.
July 8, 2010
Posted in: php, rants 
No Comments
Refresh Current Page in JavaScript
It’s more annoying than it sounds. You could do the classic:
window.location = window.location; //refresh lol!
But you’ll get screwed if there is a fragment, like, say, http://example.com/index.html#section1. The page won’t refresh. Or rather, it will, but browsers won’t send a request to the server if the url contains a fragment. It will just try to navigate to that fragment within the document.
Solution: be awesome.
(function(){
var refreshCookie = "mysite.refreshFragment";
var refresh = function() {
var url = window.location.href;
var fragmentPosition = url.lastIndexOf("#");
if (fragmentPosition >= 0) {
if (fragmentPosition !== url.length - 1) {
$.cookie(refreshCookie, url.substring(fragmentPosition + 1)); //store the fragment in a cookie
}
url = url.substring(0, fragmentPosition);
}
window.location.href = url;
};
var applyFragmentFromCookie = function() {
var fragment = $.cookie(refreshCookie);
if (fragment !== null) {
window.location.href += "#" + fragment;
$.cookie(refreshCookie, null); //delete cookie
}
};
//reapply the fragment (if necessary) when the page is loaded
$(document).ready(applyFragmentFromCookie);
//expose to the public (you would of course properly namespace this, right?)
window.refresh = refresh;
}());
//then, when you wanted to refresh the page...
refresh();
I use the jQuery cookie plugin, because all the kids nowadays are using jQuery. Substitute your own cookie handling framework, or roll your own (I’ve done it, it’s not enjoyable).
May 9, 2010
Posted in: javascript, web development 2 Comments
Subversion, Apache, nginx and “Entity Too Large”
tl;dr: add client_max_body_size 10m; to your nginx vhost.
This one took me a while to track down. My brother uses my subversion repository, and he was trying to commit a 1MB flash file. The TortoiseSVN error he got back was:
This was a bit perplexing. I figured it was some sort of mod_dav setting I had never encountered, so I turned to Google. Google spouted a bunch of stuff about where to put your SSL directives in your Apache configuration, some stuff about Apache not handling the Content-Length header correctly, some promising mailing list threads about using the LimitXMLRequestBody mod_dav directive, and a bunch of stuff about some idiots trying to commit 4GB files to a subversion server running on Windows.
None of these were my problem.
It turns out I needed to add another keyword to my search. After I searched for svn apache nginx “entity too large”, the first hit took me home. Like everyone else who is awesome, I’m using nginx as a proxy to Apache running mod_dav. nginx’s configuration was getting hit first, and Apache and Subversion had nothing to do with anything.
It turns out the default maximum request body size for nginx is 1MB, exactly the size my brother was trying commit to the repository. Adding this one line in my virtual host solved it all:
server {
listen 80;
server_name svn.tommymontgomery.com;
client_max_body_size 10m;
location / {
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://svn.tommymontgomery.com:8080;
}
}
May 4, 2010
Posted in: apache, nginx, subversion No Comments
Seven CSS Tricks No One Should Ever Have to Memorize
CSS is kinda cool, or at least it would be if everybody used the same browser. Instead, they don’t, so doing stuff with CSS is mostly impossible. There are few super annoying hacks and tricks that I use every six months but can never remember, and then end up scouring the internet looking for an implementation that’s not on webmasterworld.com. Seriously, how is that site still so far up in the Google rankings? It’s so terrible.
Anyway, I’ve compiled a short list of seven things that I’m constantly googling for. Note that this isn’t a list of “Tommy’s 101 CSS tricks for beginers (sic)!”. This is a list of things I can’t be bothered to remember. I already know all of the basic stuff, and I’m assuming you do too.
1. Reset
/* v1.0 | 20080212 */
html, body, div, span, applet, object, iframe,
h1, h2, h3, h4, h5, h6, p, blockquote, pre,
a, abbr, acronym, address, big, cite, code,
del, dfn, em, font, img, ins, kbd, q, s, samp,
small, strike, strong, sub, sup, tt, var,
b, u, i, center,
dl, dt, dd, ol, ul, li,
fieldset, form, label, legend,
table, caption, tbody, tfoot, thead, tr, th, td {
margin: 0;
padding: 0;
border: 0;
outline: 0;
font-size: 100%;
vertical-align: baseline;
background: transparent;
}
body {
line-height: 1;
}
ol, ul {
list-style: none;
}
blockquote, q {
quotes: none;
}
blockquote:before, blockquote:after,
q:before, q:after {
content: '';
content: none;
}
/* remember to define focus styles! */
:focus {
outline: 0;
}
/* remember to highlight inserts somehow! */
ins {
text-decoration: none;
}
del {
text-decoration: line-through;
}
/* tables still need 'cellspacing="0"' in the markup */
table {
border-collapse: collapse;
border-spacing: 0;
}
The reset CSS creates an even playing field across all browsers, by removing the default styles that each applies. If you want to create a cross-browser compatible web app, then use this, and don’t question it.
2. Clearfix
/* new clearfix */
.clearfix:after {
visibility: hidden;
display: block;
font-size: 0;
content: " ";
clear: both;
height: 0;
}
* html .clearfix { zoom: 1; } /* IE6 */
*:first-child+html .clearfix { zoom: 1; } /* IE7 */
This hack has gone through a few iterations, so I don’t know who the original author is. I use the one described at the link above. Use this if all child elements are floated, and you want the parent element to retain its “assumed” height. Useful for horizontal menus made up of floated lis. Give your <ul> a clearfix.
3. MIR Image Replacement
Malarkey Image Replacement Examples
.mir { letter-spacing : -1000em; }
/* Just for Opera, but hide from MacIE */
/*\*/html>body .mir { letter-spacing : normal; text-indent : -999em; overflow : hidden;}
/* End of hack */
This is a useful hack for when you want your fancy menus/giant h1 tag to gracefully degrade when styles are removed. Slap a class="mir" on it, give it some text, and you’re good to go. See the examples for examples (derp).
4. 100% height
html { height:100%; }
body { min-height:100%; }
#content { min-height:100%; }
While you can of course solve this (and the world’s) problem with tables, you shouldn’t. Because tables suck, much like urmom. But seriously, this is an incredibly difficult problem with an extremely simple solution.
5. Center an unordered list
.container {
width:100%;
overflow:hidden;
}
ul#menu2 {
margin:0 auto;
list-style-type:none;
float:left;
position:relative;
left:50%;
}
#menu2 li {
float:left;
position:relative;
right:50%;
}
You won’t figure this one out on your own. Stop trying.
Tommy’s Steps to Success
- Ctrl+C
- Ctrl+V
- ???
- Profit
6. Opacity in IE
.something-with-opacity {
opacity: 0.5; /* everybody under the sun except IE */
filter: alpha(opacity = 50); /* IE */
}
You might also need that zoom: 1 crap for elements that don’t have layout.
7. Vertically center a block element
Vertically Centering in CSS or How (Not) to Vertically Center Content
If you already know the width and height of the container, then you should be able to figure out how to vertically center something by using math (hint: division) and absolute positioning. If it’s more fluid, then you’re probably screwed.
For inline elements, use line-height. For block elements, use JavaScript. If that’s not an option, then you can attempt at implementing something like the above links, but I wouldn’t hold your breath. It’s mostly impossible.
If absolute positioning is not an option, you can try the display: table-cell; vertical-align: middle route, but it’s a crapshoot, and it doesn’t seem to work in all browsers. Using position: absolute; top: 50%; is viable as long as you know the height of the element and don’t care about absolutely positioning something.
Of course, you could valign yourself to success if you’re using tables, but you wouldn’t be stupid enough to do something like that, would you?
May 1, 2010
Posted in: web development 2 Comments