Yes - my company, iAnnounce, which we started about 18 months ago. The sites use only Perl (unless you include a little JavaScript in the templates :), running in a mod_perl environment.

We host family announcements (births, deaths, marriages etc) online for 50% of the regional newspapers in the UK, for instance:

• Newsquest
• Johnston Press
• Johnston Press Ireland
• Trinity Mirror
• Newbury Media
• Kent Messenger

Clint

Successful Perl startup, just stopped smoking... Seems like a good time to be Clinton. (congrats!)

On topic, in the Boston area tech startups are seemingly a dime a dozen. I browse job listings occasionally out of curiosity. My gut feeling is that while not many jobs at startups are for perl developers, there are a sizable number that have it as a requirement or "the ideal candidate would also know X" sort of clause.

Actually, last year (almost exactly a year ago), I got offered a job at London-based a startup. It was a Perl role, and while I think they were using a lot of PHP on the front-end, a lot of their back-end was Perl. I only turned down the role because I wasn't keen on working startup hours.

Admittedly, it wasn't really a "pure" startup - it was bankrolled by pretty intelligent money, and some of the guys working their had already run successful startups in the dot-com era using Perl, which is probably why they chose that. Ironically, the company probably has a lot better chance of succeeding than your average Ruby/Python/PHP type startup.

I'm working at a company that uses lots of Perl that's not exactly a startup, but it's still a young company. Sure, we use some PHP and Python as well, but Perl's a vital part of the software code base.

My guess is that 'new' companies sell themselves as using 'new' technology (for some definition of 'new') in order to present themselves as 'cutting edge'. But I think Marc Andreesen has really nailed it in this blog post of his: the only thing that really matters is pressure from the market to provide a good or service that it wants. The technology that it's built on is secondary, tertiary or plain Just Doesn't Matter.

Personally I can't get too excited about startups - there's nothing quite like seeing all your code go to /dev/null when the money runs out to take the fun out of a project... And don't even get me started about stock options!

-sam

I really agree with Stiller on this one. People don't use Perl to “use Perl.” They use it to do stuff. And that “stuff,” not Perl, is all that really matters.

I've seen first-hand over the past year that you can either build great stuff using Perl or you can churn out mountains of malodorous junk. You can do that in a startup mode or in an established company. Some companies start-up as startups (of course...) and transition to established-company and they're still turning out junk!

The key I'd look for in any company, regardless of size, is really not “what language(s) do they use,” but rather, “do they have a disciplined process?”

I think that a lot of start-up companies drop into the mode that they don't really pay attention to what they are producing:   they just want to produce it very, very fast. “Quick ’n dirty” seems to be the Order Of The Day, and soon-enough that comes around to bite you in the ... “ * ” !! You can also run into some rather spectacular personalities.

So if you land in a company that's (using Perl and...) has done more serious study of software-engineering than just learning how to spell “Joel,” it could be great. Otherwise it's going to be misery. Computer programming, as you will discover, is not just a matter of what you do and how you write it, but your company's or workgroup's entire approach. I feel that start-ups tend to have a higher concentration of poor or non-existent practices, and relatively little understanding or regard for their importance, especially if software is the core-focus of the company.

I feel that start-ups tend to have a higher concentration of poor or non-existent practices, and relatively little understanding or regard for their importance, especially if software is the core-focus of the company.

They get a lot of attention in weblogs though.

Uh huh. I was a regular subscriber to “f**kedcompany.com” in the late 1990's. (It was a parody of fastcompany.com and much better. “All that money,” flowing around like water, but companies were failing so hard and so fast that every day brought fresh news.

An awful lot of what they produced subsequently got lampooned, and rightly so, in “Web Sites That Suck,” which I think is on its third hilarious volume by now. None of them really had a ghost of a chance; their failures were a foregone conclusion. So, why did they attract so much well-intentioned money and how did they manage to go on for as long as they somehow did? I mean, I'm sure that lots of 'em were using Perl ...

Maybe the first question to ask in an interview is “do you know how to spell Joel?” “There are lots of books out there on good engineering practices: which ones do you use here, and how exactly do you apply them? Can you tell me anything more about them than their buzzwords?”

No matter how badly you need the job, you need to ask hard questions too. “Leave no stone unturned,” but you won't find gold coins under most stones. (It's mostly fungus.) If you find yourself stuck in a job that you hate, and you notice that you keep winding up in those kinds of jobs, part of the problem could well be you!

Maybe it's just because I've used so many languages over the years, but really I find that the language doesn't matter. I opine that it should not weigh heavily in your job-selection criteria. If they're cranking out crap and seem to be happy with it, shop elsewhere: such problems are systemic. You'll be caught-up in them for a time but won't change them. The company will always have cash problems and politics problems and so your job will never be stable. You can find better stones to turn.

I have no experiences to offer, but from reading online I get the impression that some startups want a "secret weapon" with which they can out-code the competition (a la Paul Graham's Lisp war stories).

Could be that Perl is no longer thought of as a secret weapon. Maybe it's not secret enough anymore? ;)

I have no experiences to offer, but from reading online I get the impression that some startups want a "secret weapon" with which they can out-code the competition (a la Paul Graham's Lisp war stories).

The secret weapon is CPAN. The other languages are always just about to catch up, but somehow...

Thanks for the informative reply, but I don't by the shoe analogy - you don't need to learn for entire years how to wear a shoes - but that is the case with programming languages (if you take into account learning about the available libraries, the community mailing lists and websites).

Really? I have yet to find a language that a competent developer cannot become conversant enough to be useful within a couple weeks. Within 3-4 months, with guidance, that developer can become solidly embedded into the community. Personally, I've done this with Javascript (was a Dojo contributor within 3 months of really taking up the language) and flirted doing so with Ruby. Programming is programming. Coding is coding. Don't confuse the two.

---

My criteria for good software:

1. Does it work?
2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

Don't underestimate fashion - mimesis is sometimes considered the cornerstone of all culture. And

the survivors will be the next google or facebook

So yes the 90% of the startups will die - but the rest will define the rules of the next game.

I was contracted at a startup the end of last year that was Perl (in the client and the server) + JS for a browser plugin. It was a really very clever design. The client was in POE and handled proxying to the API server and such for the JS which was embedded in IE with some C and with chrome in FF.

Maybe it's just because I've used so many languages over the years, but really I find that the language doesn't matter. I opine that it should not weigh heavily in your job-selection criteria.

Now why in the world would he say that? Assuming that he is referring to one of the latter day languages, of course, your Perls or your Pythons, I agree entirely. When you are focused on your true problems, the languages are mere tools.

I work with startups because it is fun, and because I get to directly introduce them to best practices and to a set of conventions that work.

The startup that I am working with now has a network of 40 servers. I racked the first four for them, and established the first conventions and standard Linux best practices. They are considered to be a Java based company. They use Java for the front end dev, because it is quantifiable and because large, lower skilled teams can build in quantifiable ways with it. They also use it for Lucene, which I set them up with.

Nontheless, I've used Perl consistently for them.

I don't think in terms of languages. I think in terms of higher order problems, such as team management through software tools, nearly zero administration, automated build, test, deploy; I think hard about how to properly benefit from a panoply of open source projects that provide functionality that we can rapidly devleop with. All this has to be done with forethought, with separation of customizations from projects. With plans for allowing for project and tool upgrades in an integrated version control and auto-build, auto-test, auto-deploy environment.

I also think about and write tools to keep the front end developers in controlled pens. I only give them limited apis and don't let them break frameworks or get at apis that have too many options for them to handle.

I only allow them to check out a standardized and consistent stack that auto-builds on their dev boxes. etc. I use the appropriate tool to introduce greater reliability and as much automation as possible.

If the project is language x, I write the limited apis in language x. I even have create an extension and seemless upgrade with version control system for a mambo PHP app that they have on their network. It took me a few hours to master enough of the PHP to come up with an extension plan. And I hate PHP! Even so, I can advise on how to extend and support a huge PHP app. Because it is a good tool. PHP is a bastard child of the internet on steroids and if it is on my network it is my baby!