Chad Perrin: SOB

6 April 2006

Mezilla Project: What language?

Filed under: Mezilla — apotheon @ 03:48

There’s been some discussion of programming languages to use for the new browser development project I’ve proposed. One thing we all seem to agree on is that we should avoid Java like the plague (“like the plague it is,” some might say). Other than that, there hasn’t been a whole lot of distinct statement of preferences. I’d like to change that, and maybe get something nailed down.

The most basic sort of “default” option, I suppose, would be to use nothing but C/C++ for it. It has been suggested by someone unconnected with the project that we might consider using a different language (one that’s more “fun” to use, more high-level powerful, and blessed with garbage collection whether it be “true” garbage collection or a work-alike mechanism such as Perl’s reference count management). That individual brought up OCaml as a possible replacement, which has the benefit of being a language whose parser creates persistent binary executables. As that individual pointed out, though, and as the project manager and chief architect (henceforth PMCA) also pointed out, garbage collection can be provided by way of the Boost libraries for C/C++, thus solving that problem at least.

Languages such as Perl, Python, and Ruby are other possibilities. Ruby is really not a very practical option at this time, due to issues of “maturity” of the language and its tools. The language itself would be great, but what surrounds it is just not quite up to par for this project, at this time. Python and Perl have the difficulty of requiring a means of Python or Perl parsing on the end-user computer, and Python has the added disadvantage of making my eyes bleed, though at least it works well and easily with C/C++ libraries. Perl has the added advantage of being quite familiar to most of the people involved thus far.

The Lisp family of languages would be quite high on Paul Graham’s roster of languages from which to choose, I’m sure. I respect the guy’s analysis of programming needs quite a bit, but there are a number of potential issues with using Lisp, such as the fact that I don’t think anyone currently involved is much of a Lisp hacker. I’ll start looking for more reasons to use Lisplike languages in the future when I have more familiarity with it myself, of course, but at the moment I’m less than lukewarm about using it for Mezilla (me + zilla, get it?). I won’t bother investigating it any further as a possibility unless someone else gives me compelling reasons to do so.

Based on my discussion of Lisp dialects, it should be obvious that I’m not too keen on trying to tackle Haskell for this project, even with its ability to compile to persistent binary executables. Ada, Prolog, and a slew of other languages are even further afield, and require proportionally greater inducements for consideration.

Making this a .NET/Mono project is pretty much a non-starter. I’d rather have a more portable application than that, installable in a self-contained binary where necessary so that reliance on runtime frameworks and the like is not an issue. Also, y’know, Microsoft, so no. This pretty much entirely rules out anything like C# and VB.

There’s always Javascript. The interpreter for Javascript is built into the Gecko rendering engine, which is a definite plus for Javascript as a possibility as a scripting language for browser design. It also benefits from what some regard as a better object model than C++ “enjoys”, and is generally a lot easier to write. It’s also kinda dog-slow, lacks libraries and other tools for this particular sort of project, and raises the specter of containment issues for Javascript parsing within web-served documents. The complications and performance issues strike me as, well, huge.

Object Pascal and Objective C are compiled programming languages with more regular structural features than C++. They have advantages and disadvantages. ObjC has been described as what we would have gotten if C++ were done “right”. Both Object Pascal and ObjC lack library support and widespread familiarity, though, and the tools (compilers, et cetera) do not tend to receive as much quality attention as those for C/C++. There’s also the simple fact that the GRE already uses C/C++, which might be a factor.

Anyone suggesting COBOL, VBScript, shell/batch scripting, or PHP should probably get his/her head examined. Anyone making joke suggestions like Brainfuck and Whitespace should prepare to be ignored or mocked. Assembly language is hereby disqualified by the running, by executive decision by me as the Cat Herder and Chief Bottle Washer (henceforth CHCBW, pronounced “chalk-uh-bow”).

Please, discuss. While you’re at it, check back at the initial project announcement, at the end of the users as programmers entry. Thanks for your time.


  1. I would love Ruby, but there’s the whole runtime interpreter thing. If Ruby could compile native, then you could extend it in C for whatever it didn’t provide.

    Other than that, I’m leaning towards C/C++, for all the reasons you named above, as well as for the fact that I have more experience in that/those language(s) than just about any other.

    Comment by Sterling Camden — 6 April 2006 @ 04:32

  2. I haven’t tracked the progress of Mono lately, but the idea of an open-source .NET implementation is a Really Good Idea. And using C# doesn’t tie you to Microsoft any more than using Java would tie you to Sun. Plus it wouldn’t be any work at all to port the project to Windows later.

    That said, I stil understand the reluctance to rely on runtime environments, be they .NET or the JRE. But if your objection is also that C# has its origins with Microsoft, then I say boo on ya. The Not Invented Here mindset can kill open-source projects just as easily as in the corporate, closed-source world.

    But again, if you’re looking for maximum portability, then C/C++ is still the best option, I think. Then you can release the source to me so I can port it to .NET. Muwahahaha.

    Comment by Brian Martinez — 6 April 2006 @ 08:15

  3. Java isn’t a very good example for showing how something isn’t tied to a particular vendor. To make use of the wealth of Java libraries, you would of necessity tie yourself to the proprietary Sun Java implementations. There are, in fact, some pretty awful compatibility issues between Java virtual machines, and relying on the “standard” of a proprietary implementation is pretty darned stupid.

    If you want to port it to .NET when we’re done with it, you’re welcome to do so. As for m’self, I’d rather see if I can translate it to Objective C. It might be fun to “run that up the flagpole and C,” so to speak.

    Comment by apotheon — 7 April 2006 @ 02:52

  4. OK, Java wasn’t the best example. Perhaps I was thinking more in terms of restrictions on the redistributables. You’re free to use Java however you like as long as you don’t try to modify the runtime environment or the class libraries. My point was that using Java or .NET doesn’t restrict how you can distribute your programs, other than needing to have their frameworks on the target machine.

    I’m not very familiar with the various JVMs; are you saying that the incompatibilities make it impossible to run the same code on different platforms, or that some JVMs differ greatly in performance? Because I’ve worked in shops where we developed Java on Windows workstations but deployed on Un*x boxen, without any compatibility issues.

    Comment by Brian Martinez — 7 April 2006 @ 09:07

  5. Often, code written and tested with one JVM doesn’t work properly with another JVM. Thus, the “write once, run nowhere” jokes. This can especially be a problem because of the fact that there are a fair number of JVMs that only run on one platform (compare Blackdown with the now-defunct MS JVM, for instance).

    In any case, it’s true that Java source code isn’t necessarily tied legally to a given platform, but there are just far too many negatives associated with using Java for browser development. Most of those negatives tend to translate, at least in part, to .NET platform development as well.

    Comment by apotheon — 7 April 2006 @ 11:58

  6. Perhaps a look at what Mozilla does would be useful. I don’t know much about the compiled parts of Mozilla products (which include the Gecko engine), but the user interface is (at least largely) programmed in XUL, which is an XML-defined language. The XUL is compressed in zip format in .jar files. (Despite the suffix, Mozilla does NOT contain Java code.) The uncompressed code is easily modified text, much like HTML files. The XUL code is machine-independant, except for the relatively small ??-mac.jar ??-unix.jar & ??-win.jar files (less than 1% of the total .jar file size.) (The ?? is the language code, the original being en = english.) Admittedly the interpreted XUL is theoretically slower than a compiled interface, but it allows easier product enhancement and easier internationalisation — in addition to platform-independance (of the XUL code).
    (I’ve been involved in translating the user interface to French.) I use the Mozilla suite (aka Seamonkey), I haven’t had a problem with it’s responsiveness, compared to ms-ie. Of course the binary parts of Mozilla are machine-dependant. For the compiled parts, using a language that is available as open source on all Geckos-supported platforms would be advantageous. If one uses the same language as Mozilla, parts of their code could be readily reused/adapted if desired. (Their code is freely available under various open-source licensing.) I don’t know enough to make detailed comparisons of the various options.

    Comment by andr_ — 17 May 2006 @ 07:19

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

All original content Copyright Chad Perrin: Distributed under the terms of the Open Works License