MozillaWiki

Bugzilla:Languages: Difference between revisions

Bugzilla Discussion

Bugzilla:Languages (view source)

Revision as of 18:56, 13 May 2007

1,971 bytes added ,  13 May 2007
→‎Perl Cons: Don't edit this page again, Aaron. Do you not read the history? I even sent you a personal email that you replied to. You even removed the link to the blog that started this page!
(→‎Perl: Perl is not "actively developed" compared to every other scripting language in this comparison. I already had the CPAN advantage listed.)
(→‎Perl Cons: Don't edit this page again, Aaron. Do you not read the history? I even sent you a personal email that you replied to. You even removed the link to the blog that started this page!)
 
(58 intermediate revisions by 9 users not shown)
Line 1: Line 1:
This is a basic overview of various possible languages that we could move to, for Bugzilla.
This is a basic overview of various possible languages that we could move to, for Bugzilla.


Of all of the ones I (mkanat) have used, I'm most in favor of Ruby, because I think it'd be the fastest to write code in and it seems well-designed for writing large applications.
'''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.
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 =
= Primary Considerations in Picking a Language =
Line 21: Line 25:
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
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 =
= Frameworks Under Investigation =
Line 29: Line 32:
* Perl with Catalyst
* Perl with Catalyst
** DBIx::Class for ORM.
** DBIx::Class for ORM.
* Perl with CGI::Application
** Easy short-term goal, stepping stone towards Frameworks like Catalyst, Maypole, Jifty, etc
* Ruby with Rails
* Ruby with Rails
** Also investigate [http://www.hobocentral.net Hobo].
** Also investigate [http://www.hobocentral.net Hobo].
Line 34: Line 39:
* Python with Pylons
* Python with Pylons
** Using SQLAlchemy
** Using SQLAlchemy
** Different templating systems are available:
** Mako for templating, or use the upcoming Python TT port.
*** Elements
** Examine [http://toscawidgets.org/ ToscaWidgets] and [http://www.formencode.org/ FormEncode]
*** Mako (like HTML::Mason)
** Possibility of using [http://authkit.org/ AuthKit]
*** Kid
*** Genshi
* PHP with CakePHP
* PHP with CakePHP
** The "serious PHP framework" space it boiling down to one of two these days - [http://www.symfony-project.com/ Symfony], which [http://www.symfony-project.com/weblog/2006/10/28/yahoo-bookmarks-uses-symfony.html yahoo! have used] or [http://framework.zend.com/ Zend's Framework] which has serious backers like IBM (financially and contributing manpower I believe)
** The "serious PHP framework" space it boiling down to one of two these days - [http://www.symfony-project.com/ Symfony], which [http://www.symfony-project.com/weblog/2006/10/28/yahoo-bookmarks-uses-symfony.html yahoo! have used] or [http://framework.zend.com/ Zend's Framework] which has serious backers like IBM (financially and contributing manpower I believe)
Line 50: Line 53:
=== Pros ===
=== Pros ===


* Lots of modules available in CPAN.
* Lots of modules available in CPAN. They are very well tested due to distributed test system. Anybody can participate in testing.
* Relatively fast.
* Relatively fast.
* mod_perl is very mature and extremely 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.
* 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.
* Moose allows complex class definitions, though it isn't part of Perl itself.


=== Cons ===
=== Cons ===


See [http://avatraxiom.livejournal.com/58084.html The Problems of Perl].
* See [http://avatraxiom.livejournal.com/58084.html The Problems of Perl].
* Private Methods aren't well supported require additional scaffolding.
* Multiple Inheritance can be problematic in extreme edge cases.
* Certain elements of syntax can be confusing for new users, by long experience in training new Perl users:
** The difference between () and [].
** The fact that %var is a () (which is also the array notation) but {} is $var.
** The fact that subroutine arguments aren't really subroutine arguments, they're just an array that gets passed to a function. (This also brings up confusion on the difference between using $_[1], my $var = shift, and my ($var) = @_.)
** The fact that $hash{'key'} and $hash{key} are the same.
** qq[] is a string (as is qq{}, etc.), q[] is a string, though qw() is an array.
** &sub() is resolved at runtime but sub() is resolved at compile time, ''except'' for methods.
** The conversions from one type to another can sometimes be horrendous to read. Eg: [keys %{ @{ $var } }].
** $$foo[1] and $foo->[1] mean the same thing.
** That numbers are compared with "==" but strings are compared with "eq", even though in other places strings are interpreted as numbers if used numerically.
** Figuring out what's $1, $2, $3, etc. from a regex result. And the fact that $1 and $2 don't get reset if there's no match.
*** Perl 5.10 will have named captures.
** That Perl errors are in $@ but system errors are in $!, and when to use which one.
** That Perl doesn't really have a class system, it just has a package system with @ISA or "use base," "bless," and SUPER::.
** That "my ($var) = @_" will get you the first item of the array, but "my $var = @_" will get you a number.
** In a hash created with (), if you accidentally have invalid items, you have an invalid hash. That is, you can't really do %hash = (key1 => $cgi->param('unset_param'), key2 => 'something'), because then you'll actually just have an invalid hash. (key1 will equal "key2" and "something" won't even have a real value.) In general it's safer to always make hashrefs when in doubt.
** In array context, $cgi->param('value') returns an ''empty list'' if "value" wasn't passed to the CGI. It doesn't return undef. This is why we have "scalar $cgi->param()" all over the code.


== Perl6 ==
== Perl6 ==
Line 68: Line 95:
=== Cons ===
=== Cons ===


* Essentially vaporware. There is an interpreter written for it, but it's in Haskell and it's not shipped by any distro.
* Essentially vaporware. There is an interpreter written for it, but it's in Haskell and it's not very popular yet.
* Perl 6 is still very punctuation-heavy and very influenced by Perl 5.


== Python ==
== Python ==
Line 74: Line 102:
=== Pros ===
=== Pros ===


* Quite popular (but still smaller userbase than Perl or PHP, far fewer local user groups)
* Quite popular.
* Stable.
* Stable.
* Actively developed.
* Actively developed.
* Quite a lot of modules (but still a lot less, and less organised or consistent than CPAN)
* Quite a lot of modules (but fewer than CPAN)
* Will attract the python fanboys who haven't jumped on the Ruby Bandwagon yet.


=== Cons ===
=== Cons ===


* Deployment choice can be a bad thing (i.e. mod_python, mod_wsgi etc.) - harder to install
* 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).
* Not having curly-braces on "if" statements and other blocks makes long blocks hard to read.
** (added comment) subjective - could it be you're trying to write Perl in Python? I.e. python is really trying to discourage you from writing those long blocks and investigating stuff like list comprehensions
* Poor Unicode handling--strings are ASCII by default, and are Unicode only if you prepend them with u, like u"string".
* Poor Unicode handling--strings are ASCII by default, and are Unicode only if you prepend them with u, like u"string".
** (added comment) subjective - once you know how it works and how to use it, it's actually really well implemented IMO - see [http://boodebr.org/main/python/all-about-python-and-unicode All About Python and Unicode]
* No standard way of installing modules like CPAN. (Cheeseshop and easy_install exist, but they're not universally standard.)
*** (added comment) Ruby and Perl handle Unicode far better.
* Python has no equivalent to Perl's "taint" mode.
**** (added comment) Ruby has better Unicode support? You must be joking!
* Sometimes has unclear error messages. Basically only compiler error message is "syntax error"
***** Good point, so it's just Perl that has non-sucky unicode then ;)
* Python lacks variable declarations, which means that invalid variables are caught at runtime instead of compile-time.
* No standard way of installing modules like CPAN.
* The "you need to upgrade the whole of python" problem with applications that require or use newer libraries.
** There's the Cheeseshop and easy_install. It's not universally standard, but it works with most modules, and though it has its problems, I find it easier than CPAN.
* Doesn't use OS threads, so individual python programs can't take advantage of multi-core or multi-processor systems.
*** How can that be easier than CPAN "cpan 'modulename'" isn't very hard automatic resolution of dependancies, testing as well as standardised ratings, bug reporting, smoke testing, search interface, etc.
* Lacks any type declarations (can make code more verbose, as more tests for data validity need to be done in the code.)
* Python has no equivalent to Perl's "taint" mode. (This is nothing to do with strong typing, and is about validating data by what it says rather than because it's a string rather than an integer)
* Poor error reporting
** Care to elaborate?
*** @threads.something is apparently a 'syntax error' in one version and entirely valid in one point release newer. Perl would be far more helpful about a missing library, or unimplemented whatever. In fact Python's error reporting weakness was pointed out at the LPW talk on Python.


== Ruby ==
== Ruby ==
Line 111: Line 132:
=== Cons ===
=== Cons ===


* Not yet as well-known as Perl and other languages
* Not yet as well-known as Perl and other languages (lacks the large userbase of Perl, Python, or PHP)
* Lacks large userbase of Perl or PHP
* Not installed by default in most distros or in hosting services
* Not installed by default in most distros or in hosting services
* RubyGems still small and immature compared to CPAN
* Good Unicode handling isn't coming out until 1.9, but that's the next release.
* 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).
* Performance is apparently considerably slower than Python (something like 2-3x).
* [http://blog.cbcg.net/articles/2007/04/22/python-up-ruby-down-if-that-runtime-dont-work-then-its-bound-to-drizzown Question marks over Ruby runtime]
* [http://blog.cbcg.net/articles/2007/04/22/python-up-ruby-down-if-that-runtime-dont-work-then-its-bound-to-drizzown Interesting Blog Post About Ruby Cons]
* 24x7 Ruby web apps = FastCgi plus writing scripts to monitor fastcgi daemons (and restart them) + getting up at 7am on Sunday to manually restart
* 24x7 Ruby web apps at higher traffic = 24 * mongrels + 4 * mod_proxy + lots of code tuning + dedicated sysadmins + [http://diveintomark.org/archives/2007/04/16/dhh-translation verbal abuse]


== Java ==
== Java ==
Line 128: Line 145:
* Very stable.
* Very stable.
* Fast.
* Fast.
* Popular, although more in Enterprise apps and less in Open Source than scripting languages.
* Allows for easy web application installation.
* Allows for easy web application installation.
* Adopted by many enterprises.
* Strongly typed language. This makes it easier to detect errors before runtime.
* Secure. Policy files can be used to control what the JVM is allowed to do on yur system.


=== Cons ===
=== Cons ===


* Much slower to write in than scripting languages.
* Generally slower to write in than scripting languages.
* The Java Classpath is not FOSS.
* Nothing like CPAN's client-side module installer until Java 7 (see JSR 277).
* Nothing like CPAN's client-side module installer.
* The standard Java Classpath is not FOSS, but Sun's OpenJDK is.
* Code is sometimes is more verbose than in other languages. Java 5 improves on this.


== PHP 5 or 6 ==
== PHP 5 or 6 ==


May be worth investigating [http://cpan.uwinnipeg.ca/dist/PHP-Interpreter PHP::Interpreter]]
May be worth investigating [http://cpan.uwinnipeg.ca/dist/PHP-Interpreter PHP::Interpreter]


=== Pros ===
=== Pros ===
Line 146: Line 168:
* Basically fast
* Basically fast
* mod_php is basically intrinsically as fast as mod_perl
* mod_php is basically intrinsically as fast as mod_perl
** ... but it prevents scripts from storing data on the heap (like globals) beyond the lifetime of a single request - some information on that [http://devzone.zend.com/node/view/id/1021#Heading3 here] or my dumbed version [http://www.sitepoint.com/blogs/2004/02/06/lazy-php-part-1/ here] - i.e. no more killing / restarting Apache processes - the PHP runtime is effectively stateless
* Decent object-oriented features
* Decent object-oriented features
* For this type of project, that PHP isn't a "clever language" could be a feature (no "Higher Order PHP" that only the ueber hackers can understand)
* There is no "Higher Order PHP" that only experienced hackers can understand.


=== Cons ===
=== Cons ===


* Lacks strict (variables) mode  
* Lacks strict (variables) mode  
** (Added comment) 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
** 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.
* Lacks a taint mode.
* Not historically designed for applications in the classic sense, but rather focused on scripting.
* 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)
* Charset encoding is not yet well supported (PHP6 should solve this)
* The "PHP Sucks" factor will discourage the ueber-hackers
* PHP is more focused on writing web pages than being a general-purpose language. (Might not be as good for our command-line scripts.)
* PHP is not a general purpose programming language - it's best at web pages, period (e.g. run that script for more than 30 seconds on the command line and you might start noticing how PHP's garbage collector sucks).
* 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, unless an accelerator such as APC or eAccelerator is installed.
** In other words you'll probably need another language to for anything not directly related to servicing HTTP requests
* 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
* No namespace support.


== D Programming Language ==
== D Programming Language ==
MaxKanatAlexander
canmove, Confirmed users
345

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/56154...56704"