Everybody out there who is fluent in conversational Latin, please raise your hands. (Peering out) Not many. How about Esperanto? Perhaps a few more, although you all seem to have shaggy beards and a perpetually quizzical expression. (Not that there’s anything wrong with that.)

Human languages come and go, even though they are so closely identified with a people. There are efforts to keep them going wherever possible, and records indicate that there may be as many as a thousand or more so-called “endangered languages.”

So it should come as no surprise with the pace of technology that there are endangered programming languages as well. Some, like B, were stopgaps until something else came along. Others, like COBOL, were historically important but really aren’t around much today (other than a lingering small group).

When does a programming language become pervasive enough to get interested? And when does it wither enough in ubiquity that it’s no longer relevant for a project? Both are tough (and squishy) issues.

In terms of the upswing, my bias is to get interested pretty early in gestation — not necessarily to use the language for a client project, but to get a sense about where language (and compiler) development is going. I’m not likely to use Ada or even Haskell when building something that others will need to maintain, but, as an example, looking at how Haskell handles lazy evaluation and “first-class” functions is fascinating, and broadens the knowledge of the team.

So perhaps the better questions are about when to use a language for a project that will be released into the wild — and when to stop doing so, as a language’s star is falling? The answers to both are really the same: when maintenance and long-term expertise is easy and relatively cheap to find.

We’d love to be in lifetime engagements with clients. And many of our clients are with us for many years. But we don’t assume that, and we don’t want to build something that will create hassles for the client later. So that means, no matter how much we love Forth, we’re probably not going to use it to build a web application. There just aren’t enough people out there to support it. (Plus, that’s not really a great use of the tool.)

But let’s take a tougher example: perl. Fifteen years ago, it was everywhere. If you didn’t know it, you weren’t considered serious about building for the web. As PHP has usurped some of that space, perl remains a widely-used language (although more and more, it seems to be confined to the back-end and server side).

But man, I love perl. It has an ability to work with bits of data and patterns that is perhaps matched, but rarely surpassed. Contrary to some of its reputation, it can be elegant — but it doesn’t force it. (Why is there so much bad perl code? Bad perl coders.) And the CPAN archive of modules and third-party libraries is peerless.

What to do, then? Objectively, perl’s fortunes are falling. Has it passed the threshold of use on a major project? Well, as of this writing, I’d say no — but it’s getting close. The thumb on the scale that balances cost-benefit of using a language for a project is getting kinda heavy. It’s probably in the space where we will build and maintain perl-based projects that are already in that language, but are unlikely to starting something from scratch in it.

Which is sad, but for every one of those, there’s an Objective-C or a C# that’s climbing up the charts. Goodbye Esperanto, hello Mandarin.