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:

1. Only apply namespaces to OO code (classes, interfaces, etc.)
2. 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.

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).

See it in action.

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;
    }
}

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

Reset CSS by Eric Meyer

/* 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

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

CSS 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

Centering a floated menu

.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

1. Ctrl+C
2. Ctrl+V
3. ???
4. Profit

6. Opacity in IE

CSS 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?

For my Linkurious project, I needed to get the computed style of an element in a cross browser way. I came up with an implementation that works in every version of every browser (within reason, the C64 is not supported), and is easy to use.

I’ll leave the details of how it works as an exercise to the reader. I will say that this is a good example of how to use a closure to improve the efficiency of a function. Notice that the cross-browser garbage is only executed once, not on each call.

//must be executed on or after the domready event, since it (may) require document.body to be non-null
var getComputedStyle = function() {
  var func = null;
  if (document.defaultView && document.defaultView.getComputedStyle) {
    func = document.defaultView.getComputedStyle;
  } else if (typeof(document.body.currentStyle) !== "undefined") {
    func = function(element, anything) {
      return element["currentStyle"];
    };
  }

  return function(element, style) {
    return func(element, null)[style];
  }
}();

//and use like so:
getComputedStyle(document.getElementById("foo"), "display"); //might return "inline-block"

But the sad part is that there is no walk extension method. Walk is a functional programming staple that iterates over a collection of stuff and applies a callback to each one. In PHP, there is array_walk, in JavaScript there is each.

You might be thinking, “but there is a ForEach() extension method on List!”. And you would be wrong, because there is a subtle, yet important difference between IEnumerable and IList.

IEnumerable is late-binding. That means you can do whatever you want to it, but execution is deferred until you actually enumerate the enumeration, i.e. using a foreach construct. In a list, there is no deferred execution. This deferred execution is accomplished through the magic of closures and expression trees. Read up on them.

In the meantime, here is a fluent implementation of walk:

public static class LinqExtensions {
	public static IEnumerable<T> Walk<T>(this IEnumerable<T> source, Action<T> action) {
		foreach (var t in source) {
			action(t);
			yield return t;
		}
	}
}

You can prove that this is in fact using deferred execution with a simple test:

class Program {

	class Foo {
		public int Bar { get; set; }

		public override string ToString() {
			return string.Format("Foo(Bar={0})", Bar);
		}
	}

	static void Main() {
		IEnumerable<Foo> foos = new[] { new Foo { Bar = 2 }, new Foo { Bar = 1 }, new Foo { Bar = 3 } };

		Console.WriteLine("IEnumerable.Walk():");
		foos.Walk(Console.WriteLine);
		Console.WriteLine();

		Console.WriteLine("List.ForEach():");
		foos.ToList().ForEach(Console.WriteLine);
		Console.WriteLine();

		Console.ReadLine();
	}

}

The output looks like this:

Notice that nothing got printed the first time through, using the Walk() extension method. There’s your deferred execution. That means our extension method did not enumerate the enumeration, so it’s safe and efficient to use walk in a normal linq expression where you are depending on deferred execution, like this:

IEnumerable<Foo> foos = new[] { new Foo { Bar = 2 }, new Foo { Bar = 1 }, new Foo { Bar = 3 } };

Console.WriteLine("Doing more stuff:");
var listOStuff = foos
	.Where(foo => foo.Bar >= 2)
	.Walk(foo => foo.Bar += 10)
	.Select(foo => new Baz { Foofy = foo })
	.Walk(baz => baz.Foofy.Bar--)
	.OrderBy(baz => baz.Foofy.Bar);

foreach (var stuff in listOStuff) {
	Console.WriteLine(stuff);
}

Console.ReadLine();

Well, maybe that’s not “normal.” Whatever.

I recently found a cool thing I created while in college: a Sudoku solver. It’s nothing new or innovative, but it is coolish looking. And it’s a Java applet! Remember those?

It might just be amusing to look at the HTML source and laugh at my foolish naïvete. No doctype? Not quoting HTML attributes? 1998-style mouse rollovers? JPEGs? Not using swing? The futhermucking <applet> tag!? You might have to see it to believe it.

Be delighted.

Stay cool over the summer, guys.

PS: on a more up-to-date note, I had to change the name of the isValid() method because it was causing NullPointerExceptions during the panel/applet init phase. I guess the order of method calling changed since 1.4?

PPS: obviously I shouldn’t have been overriding Component.isValid(), but I didn’t know what I was doing. I was only 20!

Questions from a freshman math student, no doubt. The uncountable vs. infinite problem is a turning point in the quest for a bachelor’s degree in mathematics. To be crude, it’s the “shit or get off the pot time” for the aspiring undergrad. It’s also one of the coolest definitions in mathematics, because it’s paradoxical and basically impossible to explain without also proving it. Not very many problems are like that.

This problem has to do with the cardinality of sets: “prove that such-and-such set is countable”. Not surprisingly, this comes up a lot in discrete mathematics and group/ring theory, since both topics use sets as input and output to problems.

Infinitude

So what does it mean to be infinite? That’s actually the easy one: it goes on forever. The set of integers is infinite, because, for example, there’s no upper bound on how high you can count. The natural numbers [1, 2, ... n-1, n, n+1, ...] are also infinite, for the exact same reason. Yet it seems like the natural numbers should be half the size of the integers, since it’s really just the set of integers without the negative ones. Yet both sets are infinite, and we still have .

So we have two infinite sets, and one is a subset of the other. We already have a paradox, and I haven’t even gotten to countability yet. Isn’t math fun?

Countability

So, how is uncountable different? Well, actually, the definition of countable is really the interesting part here. The formal definition of countable is:

A set is considered countable if it is isomorphic to the natural numbers.

Like any good mathematical definition, it leaves you searching for a dictionary. Basically, it means that a set is countable if you can come up with a function that maps every element in the set to a distinct element in the natural numbers. If you think about that for a minute, it kind of makes sense. The natural numbers are also known as “the counting numbers”. If you can represent another set as a function that maps to [1, 2, 3 ...], then you’ve just proven that it’s fundamentally equivalent to the counting numbers, so it should be countable. Of course, a proof by grammar isn’t really acceptable, but for the purposes of comprehension, it might help. Or not. Whatever.

So, obviously, the natural numbers are countable, because the function maps every element in the natural numbers () to itself.

Diagonalization

Now, we come to Cantor, and his proof by diagonalization. Basically, Cantor came up with a simple of way of expressing the countability of sets using a matrix where the diagonals of the matrix are significant. But the theory of that is not important right now. Right now we’re going to use diagonalization to prove that the rational numbers () are countable.

Let’s put the rational numbers in a matrix, such that the pattern is obvious.

If the pattern’s not obvious, we’re enumerating the rational numbers, starting in the top left corner with . To the east, the denominators increment, and to the south the numerators increment. By enumerating the rationals in this way, it should be equally obvious that given an infinitely large matrix, we would generate every single rational number. For example, where would be? It would be at the intersection of the 117th column and the 934th row.

Now, Cantor’s diagonalization comes in to prove that the rationals are countable. If we use a pen and traverse the matrix starting at the top left corner at , we can traverse it in such a way that our pen never leaves the table, and we hit each number only once. This graphic should help visualize it:

QED.

How does this prove that the rationals are countable? Well, we just showed that we can enumerate every single rational number, and traverse them in a unique way such that we only hit each rational number once. There’s your isomorphism. If you really want, you can put that sentence in the form of a function, but I’ll leave that as an exercise to the reader.

Of course, you’re at the mercy of whatever kind of limping scrod they shove out their codehole, but hey, it’s free!

Quite often, their stuff sucks, or they don’t maintain it, or it doesn’t compile, or it doesn’t work, or it only works in certain environments, or whatever. But every so often, you find that one nugget of well-maintained and well-written rad that makes you love America! Or in this case, it makes you love the Netherlands.

I was following up on on this post and trying to compile the PECL translit extension on 64-bit Windows. Obviously, I was destined to fail. And fail I did. So then I emailed the author of the extension with a cry for help:

I was curious if the translit extension is available for Windows. I noticed there was no configuration file for it, so I attempted to hack together a config.w32 and build it but didn’t have much luck. Is it conceivable that this extension is buildable on Windows?

I’m trying to build it for PHP 5.3 on x64, which probably isn’t helping my chances…

Anyway, the documentation I found didn’t mention if it was even viable on PHP 5.3, so I could be barking up a dead tree. For the record, the error was pretty immediate and looked like this:

C:\code\php64\php-5.3.1\ext\translit\data\compact_underscores.c : fatal error C1083: Cannot open compiler generated file: ‘x64\Release_TS\ext\translit\data/compact_underscores.obj’: No such file or directory

Thanks,
Tommy

I didn’t really expect anything back for a while. I know he’s a busy guy, and there hadn’t really been any updates to this extension for a couple years, but I figured I’d give it a shot. In 3.5 hours, I had a reply that said, basically, “I’m not sure if it works on Windows, but you can pull the latest from SVN to make it build. I just built it on 64-bit Windows but I haven’t tested them.” And then he freaking attached the compiled DLLs. Both thread-safe and non-thread-safe versions. Seriously. Here’s proof:

That’s dedication to maintaining your project. Not only did he answer my question, but he went the extra mile of verifying that it was a solution himself.

Derick Rethans, you are rad. There needs to be more open source developers like you.

PS: I checked out the latest version of translit from the SVN repository he specified and rebuilt, and it totally worked.

It is a compile-time error for an expression in an anonymous object initializer to be of the null type.

And you can’t. Directly.

var obj = new {
  Value = null //syntax error: "cannot assign null to anonymous type property"
};

var obj = new {
  Value = (object)null //full of win
};

//seriously, it works
Console.WriteLine(obj.Value == null); //True

Somebody please explain to me why this works.