Ha, ha! A hilarious and original pun.

I’ve had several conversations now about Perl 5’s level of deadness and Perl 6’s level of disastrousness. So here is a followup, which surely won’t get as much attention because it’s not as potentially inflammatory.

Pyramid is, to skip a lot of history, a successor to Pylons. It’s a Web framework for Python. (And there goes half my audience.) This post is about dispatch: mapping URLs to the code you want to run. (There goes the other half.)

I’m currently hosting a small pile of projects on a combination of self-hosted gitweb and self-hosted Redmine. I keep glancing meaningfully in the direction of GitHub; it’s code-oriented, it has wiki support, it has an issue tracker, and it can do simple site hosting via some contrived abuse of git. So why am I bothering to host my own stuff? There are actually a few reasons, thus I need the Internet to decide for me.

Here’s a question that should be really easy to answer: what is Diaspora?

Okay, well, I know what Diaspora is. It’s an attempt to make a decentralized social networking service. But my knowledge ends around there. What kinds of things does it share? What useful functionality does it provide for me? How does its concept of identity work? And the million dollar question, how does the decentralized bit actually work? Do I show up as eevee@diaspora.com on other sites, or do I auto-get a local account, or do I manually sign in with OpenID, or is there a central registration server, or do nodes sync their account lists… or what?

Consider this a companion article.

I love Python. It’s healthy and thriving and attracts a lot of clever people. It has its warts, but they’re mostly manageable.

Unfortunately, it still strikes me as a bit invisible. I haven’t really been able to articulate why, but after reading a bunch of those Perl blogs that bring up CPAN, I think it might actually be the software.

For example: there’s no good Python forum software. I’m sure there are some bits and pieces here and there, but nothing that’s attractive, feature-rich, and easy to deploy. That last one is a bitch, I know, but it’s important. Right now, if I want to throw up a forum, my viable options are really phpBB, vBulletin, and some other crappy PHP things. I think MyBB might be Perl, but who even uses that?

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.

floof does not, as of yet, support deleting artwork. It’s not exactly a high priority for getting an art site off the ground; we need to facilitate creating content before removing it is even a thing to be done.

Recently, I keep returning to the question of whether deletion should even be supported at all.

I hear complaints about this all the time on FA: people move accounts, people “clean up” their old art (what?), people just up and decide to leave and remove all traces of themselves in the process. Suddenly, a lot of people have tons of gaps in their favorites, with no trace of what used to be there or why.

Now, obviously part of this is purely technical: it’s easy enough to let favoriters know what’s been removed, and those gaps shouldn’t really exist in the first place.

But then, my whole philosophy so far has been about compromise. There are sites where producers have all the power, and sites where consumers have all the power, but not really anywhere that tries to appeal to both sides, and that’s the niche I’m either inventing or filling.

Consider a wiki: when you write an article, you’re creating something. The article is your prose, created by you, copyright to you. Yet nobody leaving a wiki project would think to delete all the articles they’d written in the process; the very idea is absurd, because we hardly even acknowledge that the individual writing itself is an individual creation. The project is the wiki itself, created by everybody and owned by nobody.

So can an art site do this? Can the site itself function as that kind of singular project, with individual artwork acting as mere contributions to the whole? I’ve always had the inkling that public art sites are for sharing the art, and features like disabling comments or restricting viewing ability run contrary to that goal; this is the same kind of idea taken to a further extreme.

I’m still not sold on this myself; I feel like there’s some obvious use case I’m missing that would drive many artists away. But most of the problems I think of aren’t actually solved by deletion from a single art site, since most art ends up mirrored in untold dozens of archives and imageboards. The only real difference is that the artist doesn’t directly see that it’s going on.

The biggest hurdle won’t be with discouraging artists from deleting art they upload. It’ll be discouraging artists from uploading art they might want to delete in the first place. If you don’t well and truly want to share it, then you probably just shouldn’t. This is a tricky problem; if the site resembles deviantArt-style sites, it’ll be easy to assume that it works the same way. Big scary warnings are helpful, but “no deletion” sounds more like lazy development than a nod to the subtle philosophy I’m gradually figuring out here.

I don’t know. Are you interested? Are you an artist? Am I crazy?

Addenda: Some things that were mentioned to me:

1. Wikis tend to require that you (often passively) license your contribution under a free documentation license or similar. I doubt that would be amenable to everyone, but at the very least we’d need something granting permission to display the work indefinitely.

2. One comment implied allowing an artist to remove art from his/her gallery without actually deleting it from the site. This is actually kind of interesting, and hints at another problem I haven’t much thought about: some artists let commissioners upload purchased work, but don’t bother to upload the works themselves. If “your gallery” is just all the art tagged as being created by you, how can we handle that?

For those not aware, the GNOME world is getting shaken up lately. GNOME 3.0 was released last month, with a completely redesigned interface called GNOME Shell. Meanwhile Ubuntu, the biggest GNOME-based distribution by a gigantic margin, decided that they are super special snowflakes and do not want to use GNOME Shell, so they repurposed their netbook interface, Unity, and scrambled to make it tolerable on desktops for the 11.04 Ubuntu release next week.

Our media center is running some ass-old release of Ubuntu and its main partition is too tiny to even upgrade any more, so a few days ago I bought a new drive, slapped it in, cleaned out an inch-thick layer of dust, and installed the 11.04 beta for the hell of it. After using Unity for “long enough”, I installed GNOME Shell and gave that a spin too. Here is my impression.

Quick version: They are both terrible and I am sad.

I’ve touched on this kind of thing before, but I just saw it come up again, and I think it’s worth its own post not buried in an avalanche of armchair psychology. Plus, I remembered that Blogofile does syntax highlighting.

Closures in a loop

If you’ve been linked here, you’ve probably complained that this doesn’t work as you expect:

1
2
3
4
5
6
7
8

funcs = []
for i in range(4):
    def f():
        print i
    funcs.append(f)

for f in funcs:
    f()

The output will be 3, repeated four times. Gasp! Python is totally broken! It doesn’t support closures!

Well, no. Python supports closures all too well, and that’s causing the problem here. The issue is with scoping.

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.

I hate to rank my own skill at anything, but if you forced me to, I’d say I’m pretty good at Perl. I get paid for it, at the very least. I’ve been around it a long time, and I know it well enough to tell you in intricate detail why I now use Python, instead.

But this is not that post. This post is about a particular wart of Perl: that it has a lot of warts. Large chunks of Perl are antequated, bug-prone, or outright obsolete. The trouble is that there are no warnings in the interpreter or documentation for many of these things, so a newcomer—or even an old-timer—won’t know to avoid such pitfalls until told by someone else.

Such secret knowledge has been documented in bits and pieces in many places, but none of them are complete, and some of them are similarly antequated. So, here’s my list.

Hey, remember these things?

This was the future, man. A gadget that displays anything in the universe you want to know, at your fingertips. One of the coolest things in Star Trek. “Hey, Bob, you have those simulation results?” “Yeah, right here—on my magical tiny touch computer.” And nerds everywhere cheered; paper was for norms, man.

Now we actually have these devices: smartphones, tablets with their own custom-tailored OSes, ebook readers. But what are we using them for?

Ebook readers actually get a pass here; I expect them to do exactly one thing, and anything else is just noise. I know Sony and Barnes & Noble are embroiled in an arms race over this, but the results on both sides are worse at the one thing I want an ebook reader to do. (The Nook Color has an LCD screen. Why would you do this?) I do welcome the merger of tablets and readers, should the screens somehow become as easy on the eyes as e-ink.

But a significant chunk of smartphone applications are just “Our Website: The App”, built by developers who forget that every phone platform has a fully-featured Web browser on it. Many of the rest are desktop applications jammed into the alien form factor and made worse—either in UI or functionality—by the transition. Tablets aren’t much better off; last I heard, many tablet applications were those same shrunken-down smartphone applications, scaled back up again.

Look at the top Android apps and this Time list of alleged top iPhone apps. YouTube, a website. Gmail, a website-slash-email-app. Twitter, a website. Best Buy? Cut the Rope?

Smartphones are incredible pieces of hardware, and by all appearances, we’re barely using them for anything. Crappy versions of desktop software, crappy versions of websites, and perhaps an MP3 player so we have one more free pocket each. This is a sad state of affairs.