I spent a good chunk of the last four days installing an Internet web forum, which claims it can be up and running in 30 minutes.

I like to think I’m pretty alright at computers. So what went wrong here? Well let me tell you.

I’m assuming, if you are on the Internet and reading kind of a nerdy blog, that you know what Unicode is. At the very least, you have a very general understanding of it — maybe “it’s what gives us emoji”.

That’s about as far as most people’s understanding extends, in my experience, even among programmers. And that’s a tragedy, because Unicode has a lot of… ah, depth to it. Not to say that Unicode is a terrible disaster — more that human language is a terrible disaster, and anything with the lofty goals of representing all of it is going to have some wrinkles.

So here is a collection of curiosities I’ve encountered in dealing with Unicode that you generally only find out about through experience. Enjoy.

Also, I strongly recommend you install the Symbola font, which contains basic glyphs for a vast number of characters. They may not be pretty, but they’re better than seeing the infamous Unicode lego.

Creating a programming language is apparently all the rage these days, and it’s got me thinking about what I would really like to see in one. I’m starting to suspect the things I want are either impossible or mutually incompatible, so I’d better write them down and let smarter people tell me why I can’t have everything and also a pony.

I’m strongly influenced by my love of Python, my aversion to C and C++, my fascination with Rust, and the bits of Haskell I understand. I very recently read an overview of Nim, which is part of what got my juices flowing. Also I have a lot of fond memories of what Perl 6 could have been, so, fair warning.

This is a brain dump, not a linear narrative, so some of this might be mutually referential or causally reversed or even complete nonsense. Please pardon the dust.

Almost a year ago now, Jack Diederich gave a talk entitled “Stop Writing Classes“, in which he implores Python programmers to stop creating classes just for the hell of it, and specifically calls out the common pattern of a class with only a constructor/initializer and a single method—which should, of course, just be a function.

A few weeks ago, Armin Ronacher wrote a rebuttal entitled “Start Writing More Classes“, which argues that classes are essential for both writing extensible code and smoothing over crappy interfaces. (Hm. Now that I look at it again, if you read the post backwards, it almost sounds like he’s suggesting writing a class to smooth out the crappy interface you get from using too many classes…)

I’m having some trouble here, because I agree with both points of view. There must be a way to resolve this contradiction, a message that resonates with everyone.

I think I’ve found it.

Stop writing stupid classes.

(This article has been translated into Spanish (PDF, with some additions) by Jorge Amado Soria Ramirez — thanks!)

Preface

I’m cranky. I complain about a lot of things. There’s a lot in the world of technology I don’t like, and that’s really to be expected—programming is a hilariously young discipline, and none of us have the slightest clue what we’re doing. Combine with Sturgeon’s Law, and I have a lifetime’s worth of stuff to gripe about.

This is not the same. PHP is not merely awkward to use, or ill-suited for what I want, or suboptimal, or against my religion. I can tell you all manner of good things about languages I avoid, and all manner of bad things about languages I enjoy. Go on, ask! It makes for interesting conversation.

PHP is the lone exception. Virtually every feature in PHP is broken somehow. The language, the framework, the ecosystem, are all just bad. And I can’t even point out any single damning thing, because the damage is so systemic. Every time I try to compile a list of PHP gripes, I get stuck in this depth-first search discovering more and more appalling trivia. (Hence, fractal.)

PHP is an embarrassment, a blight upon my craft. It’s so broken, but so lauded by every empowered amateur who’s yet to learn anything else, as to be maddening. It has paltry few redeeming qualities and I would prefer to forget it exists at all.

But I’ve got to get this out of my system. So here goes, one last try.

An analogy

I just blurted this out to Mel to explain my frustration and she insisted that I reproduce it here.

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.

ADDENDUM Jul 3: I don’t know how, but this got a bit of attention. chromatic has compared me to Barbie, szabgab wondered if I’m a troll, and several people suggested that I’m trying to justify leaving Perl for Python.

Remember, I’m a long-time Perl developer. I’m the ideal target audience: someone who already uses your product. In recent years I’ve become disillusioned with Perl, having watched several similar languages eclipse it. I’m surely not unique in feeling this way.

So why is the reaction to downplay what I said, rather than to tell me why I should want to use Perl, or to make Perl something I’d want to use again? chromatic suggests I just haven’t done my research. But if I don’t know why I should use your product, that’s your problem.

I did have an interesting discussion in #perl6 about this, which led to an insight. Perl 6 is unusual, possibly even unique, in having a large spec written before an implementation. I think some of its communication issues stem from this: outsiders see a spec and take it to mean an implementation isn’t “1.0” until it reasonably matches the spec. Implementors, on the other hand, regard the spec as merely a direction to move in. So outsiders are waiting for a blessed 1.0 release, and think the insiders sound slow and stuffy for not giving them one. Insiders are working on an organic thing, and think outsiders are obnoxious and impatient for wanting something absurd.

Explaining the discrepancy to people who want to use Perl 6 is technically correct, but not practically helpful. It may be better to carve up the Perl 6 spec into discrete and useful milestones, with some big ol’ colored chart detailing what’s supported by which implementations. (I actually can’t tell right now what Rakudo supports and doesn’t. rakudo.org is just a blog.)

I feel the need to respond to this series of blog posts about Perl 6, whether it should be renamed, and what the implications are for Perl 5.

I’m a Perl person. I’ve been using Perl since I was eleven. I got paid to write Perl for the past four-and-a-bit years. Let’s pretend I’m qualified to say anything here.

A confession: I wince when I call myself a “Perl person”. I think it makes me sound crusty and obsolete. Because Perl 5 is crusty and obsolete.

Who is using Perl for new software? Besides a couple grumpy nerds I know personally, I haven’t the slightest clue—and I sort of pay attention to Perl. I have zero interest in Java or .NET, but I’m still dimly aware that things are built with them. I can’t tell you what Perl is actually being used for besides all the cool new modules on CPAN designed to make Perl suck less.

What has happened with Perl since 5.8? 5.10 brought us the smart-match operator, the defined-or operator, and given/when. 5.12 brought us… well, nothing. 5.14 allows push $arrayref. And that’s all! There are a lot of bullet points in the changelogs, yes, but almost all of them are arcane things like “the … operator” or “$, flexibility”. These are improvements, technically, but they’re not anything that’s going to make me jump for Perl 5 for my next project; they’re just going to make existing Perl 5 work hurt less. (And even that isn’t automatically true; my previous job is at least a year into an effort to move from Perl 5.8 to Perl 5.10. Note that Perl 5.10 is now so old it’s unsupported.)

The ecosystem is moving, sure, but if you buy into that then you’re still stuck with the language. Worse, if you use any other Perl software, you probably have to work with an object system you don’t use, an exception model you don’t use, some kind of bundling thing you don’t use, and on it goes.

I don’t see anyone talk about Perl except people who are really into Perl already. It doesn’t attract new blood; I certainly wouldn’t point anyone towards it. If it were a human language, we’d certainly call it dead, or at least moribund.

I spend a lot of time in #python and #perl. Far more than is healthy, probably. And I’ve noticed some patterns in the kinds of questions people ask.

There are plenty of people who have trouble expressing themselves well enough to get answers in the first place, but those are just communication problems. (That’s a good read if you ever ask nerds for help, by the way.) More subtle, more insidious, and more common are people who just ask questions that shouldn’t be asked in the first place.

These are architectural fallacies: logical flaws in the very process of building or designing something. They lead programmers towards solutions that are hard to understand, are inefficient, or just don’t work. And they confuse the heck out of the people trying to help.