PHP, thou art a wart on the face of the web

I’ve long despised most dynamically typed languages, for reasons which I’ve yet to properly enunciate, but I’ve begun to loathe one above all the others: yes, I’m referring to the abomination that is PHP. I’ve never got around to properly writing about why I abhor it so much but I was recently given a link to an article on another blog, which contains (amongst a much larger and very well argued discussion) this little gem (reproduced with permission):

I can’t even say what’s wrong with PHP, because— okay. Imagine you have uh, a toolbox. A set of tools. Looks okay, standard stuff in there.

You pull out a screwdriver, and you see it’s one of those weird tri-headed things. Okay, well, that’s not very useful to you, but you guess it comes in handy sometimes.

You pull out the hammer, but to your dismay, it has the claw part on both sides. Still serviceable though, I mean, you can hit nails with the middle of the head holding it sideways.

You pull out the pliers, but they don’t have those serrated surfaces; it’s flat and smooth. That’s less useful, but it still turns bolts well enough, so whatever.

And on you go. Everything in the box is kind of weird and quirky, but maybe not enough to make it completely worthless. And there’s no clear problem with the set as a whole; it still has all the tools.

Now imagine you meet millions of carpenters using this toolbox who tell you “well hey what’s the problem with these tools? They’re all I’ve ever used and they work fine!” And the carpenters show you the houses they’ve built, where every room is a pentagon and the roof is upside-down. And you knock on the front door and it just collapses inwards and they all yell at you for breaking their door.

That’s what’s wrong with PHP.

I’ve not really ever had to write much PHP but I’ve sat looking over the shoulder of someone who was in the process of coding some small PHP scripts, and I was horrified. The problems with the ‘==’ operator, and the overloading of the function return types, were particularly unsettling. I’ve written previously about my difficulty in just compiling PHP so that it worked as I wanted – which just adds to the feeling that PHP was simply slapped together from a load of unrelated pieces, and it was only by chance that a turing-complete language emerged. One of these days I’ll get around to explaining just why dynamic languages are bad, but in the meantime get some entertainment (and perhaps education) by reading Eevee’s post.

2012-05-05 addendum: Add “insecure” to my list of gripes.


Cairo 1.12.0 – buggy as buggery?

Cairo 1.12.0 has been released with a swag-full of new features (such as XCB backend) and improvements. Apparently. For me, it causes random text corruption, noticeable most prominently in Firefox (when built with –enable-system-cairo of course) but also in a few other GTK-based apps. I’ve tried compiling with both GCC 4.7.0, 4.6.3 and LLVM 3.0 without any resolution. Cairo 1.10.2 doesn’t produce corruption, 1.12.0 does. For the moment I recommend holding off on the upgrade.

The situation would be a lot better if Cairo had a halfway decent test suite. It does have a test suite, but when I run it (on 1.12.0 or 1.10.2) I get a huge number of failures which are completely inexplicable to me and apparently to LFS authors also. Quotes from that page:

As the test suite is currently unreliable, it is best to simply skip it at this time.


Note that the tests take a long time to run and many of them fail for unknown reasons.

… which pretty much sums up my experience as well. What a joke.

Update: seems I’m not the only one who’s seen this. Not clear at this stage whether it’s really a bug in cairo, in the radeon driver, or the EXA extension.

Cinnamon. WTF is it?

Check out the Cinnamon web site.

It’s not so bad, as web sites go, in terms of appearance. Nice width, good text/background contrast. They’re probably using WordPress in the backend. That transition between screenshots (if that’s what they are) effect is really nice, I like it.

Notice they had a release recently – up to version 1.4 now, it seems, and 1.3.1 was … well, I don’t know how long ago, because the news items aren’t dated, which does seem like a serious omission, but at least I can click the links to get the full story with date: 1.4 was released 14/3/2012 and 1.3.1 was 20/2/2012, less than a month earlier. Ok, I can live with that. Hmm, fast release schedule! Usually a sign of a project in its infancy: enthusiastic developers, and plenty of low-hanging fruit in terms of bugs to fix and features to add. Which makes the next observation even more puzzling.

No – mention – anywhere – of – what – the – heck – it – is.

How exactly do you manage to put together a website with flashy screenshots and monthly news items and still neglect this most basic, this most essential of details? I can only assume that the webmaster is some form of greater ape. Possibly an orangutang. Don’t get me wrong, I like orangutangs, they have an odd graceful sobriety about them, and you can train them to wash clothes and (apparently) bang up a quick website, but they just don’t have the intelligence of a real human.

So please, Cinnamon, ditch the ape, get a human, and put an “about” page on your crappy website.

(For anyone who’s just itching to know, LWN has an entry here which explains what Cinnamon is).

Updated C compiler benchmarks, Feb 2012

With several new compiler releases it’s time to update my compiler benchmark results (last round of results here, description of the benchmark programs here). Note that the tests were on a different machine this time and the number of iterations was tweaked so numerical results aren’t comparable.

Without further ado:

So, what’s interesting in this set of results? Generally, note that LLVM and GCC now substantially compete for dominance. Notably, GCC canes LLVM in bm4, where it appears that GCC generates very good “memmove” code, whereas LLVM generates much more concise but apparently also much slower code; also in bm8 (trivial loop removal – though neither compiler actually performs this optimization, GCC apparently generates faster code). On the other hand LLVM beats GCC quite handily in bm6 (a common subexpression elimination problem).

GCC 4.6.2 improves quite a bit over 4.5.2 in bm5 (essentially a common subexpression refactoring test). However, it’s slightly worse in bm3 and for some reason there is a huge drop in performance for the bm7 test (stack placement of returned structure).

The Firm suite, surprisingly, mostly loses ground with 1.20.0 and remains uncompetitive.

Edit 25/03/12: I’ve noticed a flaw in bm6, which when corrected causes GCC to perform much worse – about 0.5 seconds rather than the 0.288 reported above.

Evince installation documentation

I just upgraded Evince on my system. Initial attempts were unsuccessful; I got the following message when trying to start it:

(evince:22841): GLib-GIO-CRITICAL **: Settings schema ‘org.gnome.Evince.Default’ is not installed

I have no idea what this means so in the interim I try upgrading ‘glib’. This mostly goes without hiccups (except that newer versions of glib apparently have a dependency on libffi, for reasons which are tentatively explained in the glib README), however, I get the same error message when I try to start Evince. After some Googling, I discover the necessity of ‘compiling the schemas’:

# glib-compile-schemas /usr/share/glib-2.0/schemas

No mention at all of this in Evince build documentation. It looks like the schema might be compiled automatically if you “make install” Evince without setting DESTDIR, but frankly the necessity of compiling the schema should be documented.

Crappy g++ documentation on template instantiation

The g++ documentation says on template instantiation:

G++ has extended the template instantiation syntax given in the ISO standard to allow forward declaration of explicit instantiations (with extern), instantiation of the compiler support data for a template class (i.e. the vtable) without instantiating any of its members (with inline), and instantiation of only the static data members of a template class, without the support data or member functions (with (static):

extern template int max (int, int);
inline template class Foo<int>;
static template class Foo<int>;

The one I’m interested in is “extern”. The docs as quoted above say that it “allows forward declaration of explicit instantiations”, but that’s useless; explicit template instantiations don’t need forward declarations, you may as well just do the instantiation. Of course, the documentation is actually incorrect by omission: the “extern” keyword in front of an explicit template instantiation (as in the example above) actually causes gcc not to emit the instantiated template (even when it would otherwise do so because of implicit instantiation). This means that we can use this syntax to avoid emitting a template instantiation which we know is already emitted in another module.

Avoiding the emission of a template instantiation in many cases has only limited practical value – it might reduce compilation and linkage time ever so slightly, and likewise reduce the disk space used by object files ever so slightly. It would also allow for removing the emitted instantiation from a shared library or executable if the same instantiation was known to be present in another library that we were linking against.

The point is, there’s a potentially useful feature which isn’t documented, yet the syntax is documented – with an incorrect description of what it does.