Bugzilla:Languages
This is a basic overview of various possible languages that we could move to, for Bugzilla.
Please put discussion on the discussion page. This page is only for technical pros and cons of each language from the perspective of Bugzilla.
Of all of the ones I (mkanat) have used, I'm most in favor of Ruby as a language, because I think it'd be the fastest to write code in and it seems well-designed for writing large applications. That doesn't necessarily mean it has the best frameworks or libraries available.
In addition to looking at the languages themselves, we should also investigate various tookits available for the languages that would make our development easier. For example, Python has Pylons and lots of other frameworks, and Ruby has Rails and Nitro. If one particular language has a framework that would be perfect for us, that could swing the decision.
The existance of this page does not mean that Bugzilla is abandoning Perl. This is only some research being done, and it may or may not ever happen (and consensus among the developers currently says it won't, but the discussion is probably worth having anyway).
Primary Considerations in Picking a Language
1. Ease of Development: We want to rapidly create new features and not have to wory about little details.
2. Ease of Modification: We want to be able to change the code without too much work. The more "abstraction" opportunities a language or framework offers, the better off we are.
3. Performance: It shouldn't perform significantly worse than current Bugzilla code.
4. Available libraries: We don't want to have to re-write the things that we're using now from CPAN. We also want libraries generally available or built-in to the language that we can use in the future.
5. i18n and l10n: We want to be able to easily localize Bugzilla in different languages without people having to re-write the templates like they do now. Anything supporting GNU Gettext in an easy way would be great.
6. Security: Perl has a Taint mode, which encourages security. We want a language that has good security-oriented features, and that has a community with a history of paying attention to security issues.
7. Enforcement of Good Code: One place where Perl falls down is that it doesn't enforce any good coding standards. A language that does would be welcome .
- (Comment). Good luck finding a language that enforces good coding standards.. here's a hint - it's a people problem - technology won't make your developers better at their job.
Frameworks Under Investigation
This lists the particular frameworks that we're actually considering.
- Perl with Catalyst
- DBIx::Class for ORM.
- Ruby with Rails
- Python with Pylons
- Using SQLAlchemy
- Mako for templating, or use the upcoming Python TT port.
- Examine ToscaWidgets and FormEncode
- Possibility of using AuthKit
- PHP with CakePHP
- The "serious PHP framework" space it boiling down to one of two these days - Symfony, which yahoo! have used or Zend's Framework which has serious backers like IBM (financially and contributing manpower I believe)
Pros/Cons of Individual Languages
This section goes over the various advantages and disadvantages of the languages themselves, from Bugzilla's perspective.
Perl
Pros
- Lots of modules available in CPAN. They are very well tested due to distributed test system. Anybody can participate in testing.
- Relatively fast.
- mod_perl is very mature and extremely fast.
- Would make us not have to port, avoiding possible Second System Effect and making any transitions (such as to a web framework) easier.
- Excellent Unicode handling.
- Excellent regex support.
- Core is actively developed but not released as often as Python and Ruby.
- PAR can create standalone executables
- crossplatform
Cons
- See The Problems of Perl.
- Some more complaints from people who don't know the language (removed)
Perl6
Pros
- Implements many features we'd like to have that Perl5 doesn't have.
- Would be the easiest language to port our current code to, since it's so similar to Perl5.
Cons
- Essentially vaporware. There is an interpreter written for it, but it's in Haskell and it's not shipped by any distro.
Python
Pros
- Quite popular (but still smaller userbase than Perl or PHP, far fewer local user groups)
- Stable.
- Actively developed.
- Quite a lot of modules (but still a lot less, and less organised or consistent than CPAN)
Cons
- Not having curly-braces on "if" statements and other blocks makes it hard to figure out where you are in the block structure without a special editor to help (like Komodo).
- Poor Unicode handling--strings are ASCII by default, and are Unicode only if you prepend them with u, like u"string".
- No standard way of installing modules like CPAN. (Cheeseshop and easy_install exist, but they're not universally standard.)
- Python has no equivalent to Perl's "taint" mode.
- Sometimes has unclear error messages. Basically only compiler error message is "syntax error"
- Python lacks variable declarations, which means that invalid variables are caught at runtime instead of compile-time.
Ruby
Pros
- Extremely modern language, lots of great features built-in to the language.
- RubyGems, a CPAN-like method of installing modules.
- Becoming more and more popular.
- Very easy to learn, development is very natural and very fast.
- Very actively developed.
- Has a taint mode, just like Perl.
Cons
- Not yet as well-known as Perl and other languages (lacks the large userbase of Perl or PHP)
- Not installed by default in most distros or in hosting services
- Good Unicode handling isn't coming out until 1.9, but that's the next release.
- Performance is apparently orders of magnitude slower than Python (something like 2-3x).
- Interesting Blog Post About Ruby Cons
Java
Pros
- Excellent "design by contract" features (compared to the other languages in this listing).
- Very stable.
- Fast.
- Allows for easy web application installation.
Cons
- Much slower to write in than scripting languages.
- The Java Classpath is not FOSS.
- Nothing like CPAN's client-side module installer.
PHP 5 or 6
May be worth investigating PHP::Interpreter
Pros
- Extremely popular
- Easy to setup / get hosting
- Basically fast
- mod_php is basically intrinsically as fast as mod_perl
- Decent object-oriented features
- There is no "Higher Order PHP" that only experienced hackers can understand.
Cons
- Lacks strict (variables) mode
- Note: Enabling PHP E_NOTICE error messages (e.g. in php.ini) does something similar. But PHP security is an issue (many gotchas for the inexperienced) - a framework could help a lot here
- Lacks a taint mode.
- Not historically designed for applications in the classic sense, but rather focused on scripting. (This also affects its reputation with application programmers.)
- Charset encoding is not yet well supported (PHP6 should solve this)
- PHP is more focused on writing web pages than being a general-purpose language. (Might not be as good for our command-line scripts.)
- mod_php is stateless and can't store data beyond a single request, but we don't do that now in Bugzilla anyway. It also parses all program for every request.
- No separate comparison operators for strings and numbers, so to be sure operators like '===', strval and intval are required.
- Too many different functions for one purpose
D Programming Language
Pros
- Can compile to native code as fast as C++'s
- Language support for "Design by Contract"
- GPL implementation (gdc)
- Native Unicode character support
- Easy to learn
- Can do Imperative/OOP/TMP programming paradigms
- Under active development
- Enthusiastic user community
Cons
- Not as well known as other languages
- Tool support isn't as comprehensive
- Not as many libraries available
C#
I hear lots of good things about C#, but I've never actually worked with it. Maybe somebody else could fill this in? I'm be slightly wary of it, since the Windows .NET stack will probably always be ahead of Mono (the *nix .NET stack), and thus the language is essentially controlled by Microsoft.