Mozilla needs to step it up

I’m currently using the Chromium developer builds for Linux and it’s amazing how Chromium is still so much faster than Firefox even though Google Chrome has been out for over a year now and Mozilla just performed a major release this summer.

It’s pretty obvious that TraceMonkey in its present state doesn’t hold up to either V8 or SquirrelFish Extreme (which score rather similarly in my experience, usually with SFX a relatively slight margin ahead of V8). I understand that TraceMonkey is much more competitive on Windows, but I almost never use Windows so I don’t care to look into that.

Mozilla really needs to focus on getting consistently good performance if they want to remain relevant.

Chromium is a godsend because of the competition and development it has both encouraged and provided in regard to in-browser JavaScript VMs. It is crucial to the future of the web that we get this show on the road, because fast JavaScript and HTML 5 canvas means the end of proprietary, patent-encumbered necessary evils like Flash and Silverlight. It’s almost impossible to browse without Flash anymore, and that must change.

I’m annoyed at Mozilla because despite their overtures and aggrandizing, Firefox is improving very slowly, and still can’t seem to cope with many of the same demos that Chrome 1.0 was chewing through without issue.

The sad thing is that I don’t really want to switch to Chromium and I don’t want the world to switch to it either. Google has way too much control as it is, with access to almost everyone’s email, search history, etc., and the ability to effectively kill off anyone who depends on referrals from search traffic (most sites see 80%-90% of external search referrals from Google) and Firefox already has thousands of good extensions and themes, not to mention a slight rapport and installed base in the general public.

But Chromium is just so much faster and safer; even if I could bring myself to ignore the 250% speed difference in _just_ the JavaScript VM (no mention here of Chromium’s vastly faster user interface), Firefox has been crashing a lot lately due to erroneous packaging by my distro, but if and when Chromium crashes, it only brings down the affected tab and everything else remains intact, which, at least this week, has made browsing much more pleasant.

Chromium’s every-tab-as-a-process technique also makes exploits much more difficult.

These are the results I just got from Sunspider, against the latest available Chromium and Firefox 3.7 nightly builds on an up-to-date Arch Linux install with kernel 2.6.31.

This is a 32-bit Chromium against a 64-bit Firefox, but the 32-bit to 32-bit results were similar and actually a bit less favorable to Firefox.

TEST                   COMPARISON            FROM                 TO             DETAILS

=============================================================================

** TOTAL **:           2.22x as fast     1092.2ms +/- 4.7%   492.6ms +/- 3.6%     significant

=============================================================================

  3d:                  2.10x as fast      154.4ms +/- 1.5%    73.4ms +/- 4.3%     significant
    cube:              1.87x as fast       47.2ms +/- 6.0%    25.2ms +/- 5.4%     significant
    morph:             1.40x as fast       35.0ms +/- 0.0%    25.0ms +/- 7.0%     significant
    raytrace:          3.11x as fast       72.2ms +/- 2.8%    23.2ms +/- 5.9%     significant

  access:              3.50x as fast      130.8ms +/- 1.6%    37.4ms +/- 6.5%     significant
    binary-trees:      20.0x as fast       40.0ms +/- 3.1%     2.0ms +/- 44.0%     significant
    fannkuch:          4.00x as fast       55.2ms +/- 1.9%    13.8ms +/- 9.9%     significant
    nbody:             1.28x as fast       23.6ms +/- 2.9%    18.4ms +/- 3.7%     significant
    nsieve:            3.75x as fast       12.0ms +/- 12.7%     3.2ms +/- 17.4%     significant

  bitops:              ??                  36.6ms +/- 6.2%    37.0ms +/- 4.1%     not conclusive: might be *1.01x as slow*
    3bit-bits-in-byte: ??                   1.6ms +/- 42.6%     2.4ms +/- 28.4%     not conclusive: might be *1.50x as slow*
    bits-in-byte:      1.18x as fast       10.6ms +/- 6.4%     9.0ms +/- 9.8%     significant
    bitwise-and:       *4.27x as slow*      2.2ms +/- 25.3%     9.4ms +/- 7.2%     significant
    nsieve-bits:       1.37x as fast       22.2ms +/- 8.3%    16.2ms +/- 6.4%     significant

  controlflow:         10.7x as fast       34.4ms +/- 4.1%     3.2ms +/- 17.4%     significant
    recursive:         10.7x as fast       34.4ms +/- 4.1%     3.2ms +/- 17.4%     significant

  crypto:              1.82x as fast       56.8ms +/- 7.0%    31.2ms +/- 6.5%     significant
    aes:               3.57x as fast       33.6ms +/- 8.1%     9.4ms +/- 7.2%     significant
    md5:               1.29x as fast       14.2ms +/- 3.9%    11.0ms +/- 8.0%     significant
    sha1:              *1.20x as slow*      9.0ms +/- 16.9%    10.8ms +/- 9.6%     significant

  date:                2.28x as fast      171.6ms +/- 2.2%    75.2ms +/- 3.9%     significant
    format-tofte:      3.46x as fast      104.4ms +/- 3.4%    30.2ms +/- 1.8%     significant
    format-xparb:      1.49x as fast       67.2ms +/- 2.4%    45.0ms +/- 5.9%     significant

  math:                *1.05x as slow*     45.4ms +/- 2.4%    47.6ms +/- 3.5%     significant
    cordic:            1.06x as fast       20.2ms +/- 2.8%    19.0ms +/- 6.5%     significant
    partial-sums:      *1.10x as slow*     18.8ms +/- 3.0%    20.6ms +/- 3.3%     significant
    spectral-norm:     *1.25x as slow*      6.4ms +/- 17.4%     8.0ms +/- 0.0%     significant

  regexp:              4.44x as fast       78.2ms +/- 12.2%    17.6ms +/- 3.9%     significant
    dna:               4.44x as fast       78.2ms +/- 12.2%    17.6ms +/- 3.9%     significant

  string:              2.26x as fast      384.0ms +/- 11.2%   170.0ms +/- 4.8%     significant
    base64:            *1.60x as slow*     11.0ms +/- 8.0%    17.6ms +/- 6.3%     significant
    fasta:             2.49x as fast       72.8ms +/- 3.9%    29.2ms +/- 7.6%     significant
    tagcloud:          2.83x as fast      102.4ms +/- 6.7%    36.2ms +/- 7.4%     significant
    unpack-code:       3.02x as fast      162.6ms +/- 17.7%    53.8ms +/- 3.4%     significant
    validate-input:    -                   35.2ms +/- 18.3%    33.2ms +/- 4.9%

Removing Adobe Drive CS4 in Windows

So, after sitting around for more than an hour waiting for Adobe’s indecently bloated CS4 installer to finish installing Photoshop and Flash, I right-click on a file, and am rewarded with a lovely little “Adobe Drive CS4” context option. I definitely didn’t want this, and I’m upset that when all I asked for was Flash and Photoshop two new Adobe submenus appear on my Start list, one containing only “Adobe Media Player” and another containing nine items, only two of which I asked for, plus another top-level icon for “Acrobat.com”, so Adobe sucks.

Anyway, it seems that the recommended method to remove Adobe Drive CS4 from the context menu is to open the installer and uninstall it (funny that I wasn’t asked about this the first time), but if you’re running Windows in a virtualized guest like me and don’t want to wait the ten minutes it takes Adobe to “[check your system profile]” and “[Load] Setup”, remove these two registry keys:

HKEY_CLASSES_ROOT\AllFilesystemObjects\shellex\ContextMenuHandlers\{C95FFEAE-A32E-4122-A5C4-49B5BFB69795}
HKEY_CLASSES_ROOT\Directory\Background\shellex\ContextMenuHandlers\{C95FFEAE-A32E-4122-A5C4-49B5BFB69795}

and you should be freed from offending entry.

Alas, Adobe Drive CS4 is still sitting around somewhere sucking up space uselessly, but we’ll leave well enough alone for now.

Joel’s “Duct-Tape Programmer” is the only programmer you should ever hire.

I’ve just finished reading Joel Spolsky’s “Duct Tape Programmers” and jwz’s response to it.

These posts strike a chord with me, especially that Spolsky spends the entirety of the article praising “The Duct-Tape Programmer” before he urges you not to try it.

I’ve worked on teams where every member urgently insisted on rigid, absolute application of certain tools, citing familiarity as the main benefit. “When all you have is a hammer, everything looks like a nail.”

These teams tend to be weeks behind schedule, blinded by various unique brands of naivety, and in general this type of management produces an unwieldy monolith of a codebase, slow and non-intuitive.

jwz, on the other hand, is a pragmatic generalist who doesn’t fear learning a new thing if it is the right tool for the job. While others who blindly insist on the same old are motivated by self-interest, fear, and good performance reviews from uninformed business people using worse-than-useless metrics, the “duct-tape programmer”, epitomized by jwz, is concerned with performance, utility, and maintainability of the product, which sadly, often comes at the expense of high corporate positions reserved only for elite sycophants, not practical, usable realists. jwz’s blogs testify to this clearly.

When Mr. Spolsky implores readers not to follow in jwz’s footsteps of judgment and application, he promotes a pervasive negativity and self-decay within a development team. Obsession with fads or hyperfocus on one area of good practice and other symptoms of programming elitism do no good to someone actually interested in developing or maintaining functional software. Often “non-duct-tape” programmers can prattle shallow quips right off to back up their incompetence, but the fact is that attempts to squeeze a round peg through a square hole are always inadequate, even if the big bad “learning curve” must make an appearance. Invest the time up front and do it in a way that loosely approximates an intelligent approach instead of allowing politics and insecurities to hinder development.

I can’t tell you how many hours I’ve seen wasted bastardizing functions deep within the netherparts of CakePHP (for instance) when a faster, better, and more suitable custom component could have been built much faster and maintained much easier. A programmer that does that is an example of a bad programmer because no matter how well he knows the target platform, he’s going to regularly misapply that knowledge, and his technical religion that CakePHP (for instance) is ultimate, and everything must be done the Cake way (which, ironically, is tarnished by forcing yourself to modify core libs because you can’t not use Cake for something), impedes the macro-level goal of “build something that works well, reasonably quickly”.

Spolsky’s description paints the duct-tape programmer as an ignoramus, a programmer who’d just as well stick to pre-1990 languages, methods, and conventions, but that’s clearly not the case with jwz, who was one of the first third-party developers for the Palm Pre. jwz, like all other good programmers, simply knows how and when to avoid cruft and how and when to leverage existing work. This sense of decent judgment is gained only through long experience and technical exploration, the kind a “non-duct-tape” programmer is too afraid to get.

So, when Joel says the “duct-tape programmer”, what he really means is the “pragmatic, profitable programmer, the only kind of programmer you should ever hire or use; a ‘good’ programmer”. These programmers do follow the changes in the field and they do play with new technologies and methods. They simply know when to experiment, when to complicate, when to simplify, and when to ship.

Do yourself a favor and pattern your next hire after jwz; get a programmer with the know-how and the wisdom, because one is useless without the other.