![]() Users couldn't care less whether the underlying code is pretty. Adoption of this open source database isn't slowing in the least because their codebase happens to be poorly written and difficult to troubleshoot and maintain. This particular friend of mine is no stranger to bad code- he's been in a position to see some horrifically bad codebases. I have a friend who works for an extremely popular open source database company, and he says their code is some of the absolute worst he's ever seen. It's actively used today by some of the largest and most famous open source projects on the planet, including the Linux Kernel, Mozilla, Apache, and many others. But- and here's the important part- Bugzilla works. ![]() It is utilitarian bordering on downright ugly. I don't think Bugzilla is anyone's favorite bug tracking product. Neither Perl nor the circa-1998 Bugzilla codebase have aged particularly well over the last 10 years. Perhaps it would make sense to rewrite Bugzilla in a friendlier, more modern language. It's a credit to Max that he cares enough about the future of his work to surface these important issues. But I'm seeing more and more products come into the bug-tracking arena, and I'm not sure that we can stay competitive for more than a few more years if we stick with Perl. So we shouldn't abandon what we're doing now. Currently, our popularity is actually increasing, as far as I can see. Without taking some action, I'm not sure how many more years Bugzilla can stay alive as a product. In 2007, though, having worked with Perl extensively for years on the Bugzilla project, I'd say the language itself is our greatest hindrance. In 1998, Perl was the right choice for a language to re-write Bugzilla in. There are at least two bug-trackers that I can think of off the top of my head that didn't even exist in 1998 and were developed rapidly up to a point where they could compete with Bugzilla. 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. Nowadays, almost all of our competitors have one advantage: they are not written in Perl. PHP has decent object-oriented features, python has many libraries and excellent syntax, Java has matured a lot, and Ruby is coming up in the world quickly. Since 1998 there have been many advances in programming languages. The same flexibility that makes Perl so powerful makes it very difficult to enforce code quality standards or to implement modern object-oriented designs. However, Perl would not be my first choice for writing or maintaining a large project such as Bugzilla. Perl has many great features, most of all the number of libraries available and the extreme flexibility of the language. PHP was at version 3.0, python was at version 1.5, Java was just starting to become well-known, ruby was almost unheard of, and some people were still writing their CGI scripts in C or C++. In 1998, there were few advanced, object-oriented web scripting languages. My understanding is that he re-wrote it in Perl because a lot of system administrators know Perl, so that would make it easier to get contributors. When it was open-sourced in 1998, Terry (the original programmer), decided to re-write Bugzilla in Perl. Once upon a time, Bugzilla was an internal application at Netscape, written in TCL. In The Problems of Perl: The Future of Bugzilla, Max Kanat-Alexander* laments the state of the Bugzilla codebase:
0 Comments
Leave a Reply. |