I am by no means anti-Perl, but I’ve read and heard so many horror stories about Perl from developers that I trust and respect. Significantly more than any other (current) language I can think of. Max is yet another example. I do think there’s a kernel of truth there.
I think you need to widen your circle of developer friends. The only kernel of truth is the current code base is crappy.
Jeff, the truth is that you need both. Code written as well as humanly possible, and user interfaces that are as good as you can make them.
Perl has actually aged extraordinarily well. Perl has been at the forefront of pushing automated testing for the past several years. Other languages are still playing catch-up. The Perl community has a much higher standard for testing and documentation than most, as you can see in the popular modules on CPAN. Perl has also evolved mature tools for managing code style (Perl::Critic, perltidy) and has top-notch object-relational mappers and templating tools, i.e. the things you need every day in web development.
You’re right. Time to recode in a shiny new language.
Incidentally, Shiny New Perl 5.10 is just out 
I have to state here that perl is not so bad. Some people can write things that look unintelligable in perl quite easily, but many people stick to KR style that they have grown familiar with from C. Much of the style of perl programming fits with C nicely also, but this goes for much of ruby too.
The thing about perl though is that it’s quick to do something that most other languages take a lot of lines to complete. Such as IO::Socket::INET, which lets you do what you want over the wire so easily. LWP::UserAgent and WWW::Mechanize also are great favorites for doing stuff with HTTP sites.
I think people should really not complain about perl being messy, we see this a lot all over the internet that perl is ghastly, but this really isn’t the case. The only complaint that I have is that many variables start with $ - simply because it’s sometimes hard to find on the keyboard.
Bugzilla is an opensource project, so if your code looks like crap it will be hard to find developers to maintain it.
Ouch, I injured my finger having to use that scroll-wheel to get all of the way down to the bottom. Seems to be quite an issue. So, even through I’ll get lost in this mass of comments, I’ll still ump in:
Pretty much, Perl, PHP, C, C++, Java, Ruby, etc. are all fundamentally the same. OO or not, there are a few slice and dice differences, but not enough to make any real difference to any implementation. Contrast these languages with APL, Lisp or Prolog and you’ll see what I mean. Given that, I don’t buy the argument that writing in Perl makes Bugzilla outdated. When used with restraint, Perl is close enough to any of the other languages that it would be hard to tell the difference. “Used with restraint” is key.
So, to me at least, what this is really about is a hugely messy codebase that has not been cleaned up. That ‘problem’ is independent of language or technology. You can make a brute force mess in any of the above languages just as easily as any other; although some features in Perl and things like macros in CPP make it a bit easier to accomplish.
Our problems lie with the way we are designing and building our code. It comes up again and again: flailing at the keyboard for all hours of the night eventually produces something unmanageable. The problem isn’t any specific language or technology, it is the way we creating things. You can’t coalesce thousands of rickety sheds into an apartment building, it just ain’t going to work.
Jeff,
I can’t belive I just read this post on your site…
I know that “nobody but I” cares but that’s what makes me great, (And nobody cares 
/Jonas
Yes, end users do not care about your code as long as IT WORKS!! The moment it starts behaving weird; causing too much problems; showing too much bugs; then end users starts caring about the other stuff and can easily be bought for polished nice presentations having mentions of latest technology; latest language; UI etc. etc.
Jeff,
I agree that usability and the user experience is the utmost. At the same time what about continued maintenance (and future development) of the product. This is when coding conventions and choice of programming language becomes especially important. There is always the possibility of the product outliving the programmer.
Raghav.
Jeff, I think you missed the point entirely:
“Nowadays, almost all of our competitors have one advantage: they are not written in Perl. They can actually develop features more quickly than we can, not because of the number of contributors they have, but because the language they’re using allows it.”
The guy who wrote the yahoo stores said something similar–he had a competitive advantage because he was using a powerful language, LISP.
No the users don’t care what something is written. Yes the user interface is important. Yes programmers need to pay more attention to what the users sees and needs rather than just architecture or plumbing. But in order to keep cranking those features out, a good language and good code is essential. We’ve ALL been the situation where we can’t bring business value to our customers (features) because we’re too busy wrangling with code (or languages) that suck. There comes a point where bad code DOES affect the customer, even though they don’t know it.
I’m a big fan Jeff, but I think your post is irresponsible and i think you missed the point.
Users SHOULD care what the code looks like, unfortunately they have their own short sighted pressures on them as well.
If I bought a house and didn’t go down the basement to see if the pipes leaked, how the wires looked, or what the HVAC looked like … I’d be a very sad homeowner in a short time.
If you don’t address the code to the two target audiences that it will have: the machine it runs on, and the humans needing to maintain it (programmer or analyst) - you are just not writing good code (imho).
“people only care if it works and how it works e.g. user experience”
I’m sorry, to argue that you can slap some shit together and put the crap out there and it won’t matter as long as the UI is pretty is wrong. At best it’s far from being 100% right. It’s like some contractor arguing that the faster they slap some new house together, the better because people just want it to look pretty. Never mind the mistreated wood trusses for the roof or the overloaded electrical box or the shingles that weren’t put on quite right or the landscaping that doesn’t quite slope away from the house so that there’s a good chance the basement’s going to end up damp after a hard rain. Sure, they won’t cause issues right away. But they’re going to be a huge pain in the ass when they do costly to fix.
Well written code is easier to maintain, always for more time to create new features, leads to better avoiding releasing bugs in software and, when they do happen, being able to fix them more quickly. And the productivity of all these activities affects the cost of building and maintaining that code.
These things are ALL part of the user experience. It’s not limited to the UI. It hits their pocket book. How long a bug may exist affects them. So does having a bug in the first place. HAVING GOOD CODE MATTERS.
Well, there’s some truth here if you’re delivering compiled closed-source code. Your article reminds me of companies who advertise their code as “developed using object-oriented techniques”, or, more recently, “developed using agile technologies”. As if anyone cared!
But if (as, for example, in the case of Bugzilla) you’re delivering something open source and not-compiled, I care deeply about what the code looks like (to me, that includes things like the installation instructions, the license, the documentation). I might need to patch this code, I might want to adapt it; I might even want to join the development team! Code quality is certainly a factor in choosing this kind of tool.
Do you think Bugzila at this point can be rewritten in another language? Say PHP/.net/Java/Ruby? What kind of risks one would accout here? Would that be a sound business call? 10 years development would have historical domain skills accounted in every small function. Will this not be a big risk for migration? What in that case should be the strategy?
They refactored Bugzilla to work on mod_perl to speed up it. Maybe it is time to refactor it in modern Perl. And use Perl::Critic.
When I rent an apartment I tend to look at the layout and not the underlying architecture and raw material used to build it. But going ahead, if I do decide to dig a hole in the wall, I would not expect the building to come crashing down! I TRUST the builder. Geez…
It is YOUR responsibility as a vendor to provide solid code that can accommodate changes quickly and continue to maintain the stability of the application. It is NOT the responsibility of the USER. WHY SHOULD HE CARE ? What is he paying YOU for?
Sure,most users don’t care about the your code ,if you satisfy their question “does the programme work ?” with a “yes ,it does” then you’ll not have any problem with them .But your employers do care about your code so you should as well if you want to stay employed.
Firstly, they guy you were quoting never (in the quote at least) said that their code is ugly. He said that developing big software systems (such as Bugzilla) in Perl is slower than in other major languages. And that is not a surprise because Perl is not suited (and was not designed) for that. From that quote we can’t really conclude how ugly or beautiful the Bugzilla’s codebase is, so it wouldn’t be correct to cite Bugzilla as an example of a popular application with happy users despite it’s ugly code base.
And what about Spolsky and Wasabi? Would you label their code ugly just because it’s written in Wasabi and not in Ruby? I’m sure their code is very beautiful judged by the Wasabi’s beauty standards. Why? Because I assume they have good programmers, and good programmers don’t write ugly code.
Good programmers write good-looking code automatically and naturally. Simply because they are good at writing code, and they don’t like producing crap. So, ugly code is a sure sign of a bad programmer. Obviously, if you have too many bad programmers on your project, then your project is in trouble. Which brings us to a conclusion: the uglier your codebase is, the more trouble awaits your project.
Yes, it’s totally correct that users don’t give a damn about how your code looks like (why should they?). So what? Is there really anybody who believes (or have seen) that it’s possible to successfully (i.e. well beyond the version 1.0) develop complex applications on a predominantly ugly code base?
Does it matters that the house you buy is well conceived?
Does it matters that the foundation of a building are sound?
Does it matters that your diet is correct?
Does it matters that your country/city is well run?
Does it matter that your car is well designed?
Of course it matters! but when you buy a house, construct a building, eat, vote or buy a car; we ask some questions but certainly we miss some very important questions.
I believe that a reasonable level of quality of code is important. Like for the foundation of a house. It doesn’t necessary important that they are very beautiful and that they can handle an earthquake of force 10 but its better that they are done correctly and could handle a force 6 earthquake.
The problem is to find a way to define and after that control the quality of code. After that the user, theoretically, the user could ask some level of quality. We have already some methodology that enforce some quality checks. We have also some metrics. But how many time did you find very ugly architecture or code?