Bugzilla Talk:Languages

On Perl5 cons

I think everyone agrees that Perl5 is difficult for large, maintainable applications, and no one wants to advocate continuing to use it. But still, there's some red herrings:

• Certain syntax things are confusing for new users
  • Granted. But it seems that there would be a strong expectation that anyone programming in a particular language would be far beyond the "new user" stage before they attempted anything big/maintainable/etc -- regardless of the language being used.
    • Ideally, but it's not always the case. And sometimes people have used Perl for years and still don't understand some of the things I listed on the page. But I do see your point there. -mkanat
• Perl doesn't check the type of arguments to subroutines.
  • Given that it's a typeless language, what is there to check?
    • Well, it'd be nice to be able to enforce that the argument was a particular class, or be able to enforce that a reference is an arrayref or hashref without having to do that manually. -mkanat
• $$foo[1] and $foo->[1] mean the same thing.
  • This is analogous to a C/C++ construct where ix->member and (*ix).member mean the same thing.
    • Yeah, which is also confusing in C to many people. :-) -mkanat
• You can't make subroutines private in a class.
  • Not true:

package Foo;

my $private_method_ref = 
    sub { 
         print "hello, I'm a private method\n";
         print "There is no way to call me outside of this package\n"; 
    };

sub public_method
{
  # call private method
  $private_method_ref->();
}

• • • True, and I've seen that example many places. Not exactly intuitive, though. And does that work under mod_perl?

On Python cons

• Not having curly-braces on "if" statements and other blocks makes long blocks hard to read.
  • I think this is mostly a red herring. First, you should not write long blocks to begin with. Second, I've used Python almost exclusively in a large project for over three years and this has rarely been a problem.
    • Okay. But if there was one thing I could change about the basic nature of the language, this would be it. It can be very difficult to remember how many spaces you need to put, if you're adding a line after a complex series of blocks. -mkanat
      • That's a feature. Seriously. You're complaining about Perl being too hard to read, and Python is designed so that totally unreadable code won't compile. Do you really want to review patches where someone has managed to get the braces in the right place but the indentation wrong? I'm actually quite surprised to see someone looking primarily for a maintainable language and not putting this in Python's "pro" column. I often hear it called "executable pseudocode" because it's so readable, and the indentation-based syntax contributes to that. -Slamb
        • Yeah, I know. I suppose different people feel different ways about it. We don't have too many problems with indentation anymore, although we used to in older Bugzilla code. It's just hard when there are lines that are two blocks out after the end of one inner block--you can't really tell what block the line is in. -mkanat

• Poor Unicode handling--strings are ASCII by default, and are Unicode only if you prepend them with u, like u"string".
  • I think u"" can easily be enforced as a coding policy. Depending on how ambitious your Unicode needs are, Python Unicode may not be enough for you. For Chandler we created PyICU to fix cases where Python's natural Unicode support falls short.
    • I was trying to avoid having to enforce code guidelines, though. That is, that's one of the reasons we want to move away from Perl. I can check out PyICU though. -mkanat

• No standard way of installing modules like CPAN.
  • There is: Python eggs. These are pretty new, though, so not all projects make eggs or upload them to cheeseshop (equivalent to cpan).
    • Ahhh. Yeah, I've seen cheeseshop, but I haven't seen it integrated into *nix distros yet. -mkanat

• Python has no equivalent to Perl's "taint" mode.
  • I know of some attempts at this, and I believe Zope has a sandbox thingy as well, so the situation is probably not as bleak as you think.
    • This is really one of my primary concerns. Bugzilla is already used in a lot of situations that require strict security, such as US Government installations. I didn't find anything that would be adequate, in my brief Google search. -mkanat

On Java Cons

• Much slower to write in than scripting languages.
  • This is why most webapps use a scripting language as part of the templating/GUI layer, which is the bit that will require the most customization for most sites
  • Although some tasks can be written very quickly in Perl/Python/Ruby (for example a SOAP client in just a couple lines of code) I'm not sure that is a fair comparison. Although the syntax of those scripting languages is inherently more compact, I don't think this is a fair compairson since the compactness (while impressive in showing off the language) makes the code not only less readable/maintainable, but a good Java IDE or set of Emacs macros will take care of writing/autocompleting most of that for you anyway.
• The Java Classpath is not FOSS
  • It should be mentioned that Java's licensing is rapidly changing and I believe Tomcat can actually be run under 100% OSS components
• Nothing like CPAN's client-side module installer
  • While this is true, it is also completely unfair because Java does not need such a mechanism. There are lots of Perl modules with native code but few third-party Java modules contain any native code, eliminating one of the major third-party module installation headaches. "Installing" a module in a Java webapp is usually as simple as downloading a single JAR file from the module's website and dropping it in your webapp's lib directory. True there is no single repository of Java modules (like CPAN) but finding a module to meet just about any need should not be difficult in this Google age.

Ruby cons

• Performance is apparently orders of magnitude slower than Python (something like 2-3x).
  • 2-3x is not orders of magnitude, except in bizarro-world where log_10(2) > 1. This is an important distinction: since performance is down at #3 on your list of priorities, I don't think you should be worrying about anything but order of magnitude differences. -Slamb
    • It's an order of magnitude in binary or ternary. :-) The item there originally said 10x, but then was corrected and the order of magnitude comment was not removed. -mkanat

PHP Frameworks

You may want to have a look at eZ Components for PHP:

• Backed by a middle large, but well known PHP company: eZ Systems
• A quality first approach: Discussing Requirements, discussing Design, Writing Tests, Coding+Documenting, Reviewing: dev_process
• Some big names from the PHP core developers are part of the team (Derick Rethans is the project leader)
• Sebastian Bergmann, the creator of PHPUnit contributed a workflow component that he developed as part of his diploma thesis. You'll certainly need a workflow for bugzilla
• The Console Tools component helps you with user interaction for shell scripting
• The company toolslave proposed to contribute it's WebServices libraries to the components. This will give us SOAP and REST

A Java Framework (#1a?)

Here's the rub with Java.. don't do GUIs with it, but by all means, make your business object and services layer with it. If you expose Bugzilla features through well-defined web services (ala WSDL) then anyone can: write GUIs for it (.NET, Python, Java, Ruby, Delphi, ...); script command-line clients; plug it in to their favorite IDE's; etc. Here's one FOSS framework/stack:

• EJB 3.0 - a specification for Java application servers
• JBoss Application Server 4.0.5 - an implementation of that specification
  • 4.2 was released yesterday (11 May 2007)
  • Apache Tomcat - a Java-based web server, which also ships with JBoss
    • Apache Axis - web services implementation, talks with EJBs
  • Hibernate - ORM implementation, which also ships with JBoss
    • This lets you work with any database that hibernate works with.. which is most.

That's it for objects and services. But if you want a kind of "reference" implementation of an interface, and something which works closely (locally) with the server-side objects and services, then you could use:

• JBoss Seam - works closely with business objects and services to provide web interfaces, including some AJAX

I call this a "stack" for the many options within each layer: application server, web server, persistence/ORM impelmentation (hence database), GUI, operating system, security services, etc., and that's just the server side. The whole thing is mind-bogglingly complex - too much to consider all at once, but if you build one tower of tools, have a clear domain model and services, pre-defined roles, and an eye for security, then it should build quickly.

To address each point with this set of Java technologies:

1. Ease of Development: It's not easy to learn, but you can rapidly create new features without worrying about details, especially with EJB 3.0 annotations.
2. Ease of Modification: Refactoring Java is a joy, and the tools are excellent (Eclipse). Java has long been exposed to agile programming methods, and benefited greatly from unit testing and other change-embracing practices.
3. Performance: Should be good in normal deployment, but also very scalable.
4. Available libraries: Your server-side stuff should be taken care of, but also GUI libraries, like for charting on a web interface.
5. i18n and l10n: Solved for web interfaces.
6. Security: Server-side security is well established, uses most common authentication and authorization services, and is built into the language. EJB 3.0 in particular uses role-based security for both declarative and programmatic access control.
7. Enforcement of Good Code: The tools (Eclipse at least) do a good job.