2012-02-20
Why I still have a custom-compiled Firefox
Not that long ago, I mentioned that I still use a custom-compiled version of Firefox and some people asked why I do it. I have a long history of compiling my own browsers, extending back to when the Mozilla browser was Mozilla instead of Firefox. Unfortunately, at this point I can't entirely remember why I started, but I do remember what the end result was.
(It may have been that Mozilla wasn't available as a system package at the time for Red Hat Linux (back when it was RHL instead of Fedora), or perhaps that the system packages were outdated due to the rapid pace of Mozilla development. This was during a time when Red Hat was doing minor update versions of RHL and thus trying to keep program versions relatively unchanged for a year or more.)
Starting from the early days, I piled on a variety of modifications and hacks. Some of them were simply differences between how Mozilla worked and how Netscape worked (I had a long history with Netscape and was very used to some aspects of its behavior), but others were bugfixes, font hacks, and strange alterations. For example, early versions of Mozilla did some strange and not necessarily desirable things with font mappings in X, and I overrode some of them and took others out. Since I wanted to be able to run Mozilla and Netscape at the same time, I believe that this is where I started customizing how the remote access works.
Over time, the need for most of these customizations and bugfixes dropped away (a bunch became obsolete when Firefox eliminated support for old style X fonts, for example). Today, the only necessary changes I make are my hacks to remote access and changing the Delete key act like the Backspace key in HTML content. I also fiddle the branding for obscure reasons.
(I used to have to hack things so that Backspace would scroll the page up the way control-space does, but Firefox added a preference for that. I care about this because Netscape used Backspace to scroll pages up and I have years of reflexes that I have carefully carried forward from the days when I used Netscape. Besides, control-spacebar is two keys and Backspace is just one.)
Just to show how crazy and recursive this gets, the reason I have to map Delete to Backspace in Firefox is that for reasons well beyond the scope of this entry I already swap Backspace and Delete on my keyboard; the Backspace key generates 'Delete' and vice versa. I believe that in the old days of Netscape both Backspace and Delete scrolled the text up, but I no longer have a runnable Netscape binary to check that with.
Sidebar: on keeping up with the main version of Firefox
Honestly it's not difficult. I build from the Firefox release source
repository, which changes only very infrequently and generally on a
predictable basis. Because Fedora is now generally shipping the current
version of Firefox, a Fedora Firefox package update makes a good prompt
for me to 'hg pull -u' the latest source repository update and do a
rebuild. And Fedora is basically certain to update for security issues,
which are the ones where I care most about being current.
(I'm generally not in a rush to update Firefox for functionality. If I wanted the latest and greatest bleeding edge Firefox I'd build from the beta repositories or the development source, but the days when I did that are now long over.)
My view of where TCL went wrong
Recently there was both an article and the resulting Hacker News discussion on the topic of where Tcl and Tk went wrong. As it happens, I have some vaguely heretical opinions on this.
I have two and a half backgrounds with TCL and TK. First, I've used and minorly hacked some decent sized TCL and TK applications for years, primarily exmh; for the half point, I've also written some trivial TCL/TK programs. Second, a very long time ago I embedded an early version of TCL into a program I was writing and tried to push as much functionality as possible into the TCL code. The latter experience especially left me with some strong opinions about TCL.
To put it bluntly, where TCL went wrong was in core language design and especially in two areas. To start with, TCL is simply not a very nice language. Serious TCL code is simply littered with noise and extra verbosity, where fundamental programming language operations all need additional work. Let's take a representative example:
set x [expr $i/8 + 8]
This requires two extra keywords and an extra set of []'s for what most
other languages would write as 'x = i/8 + 8'. The variable names
aren't even used consistently; we set x but use $i. Even Lisp
manages to be more compact and regular. TCL's semantics may be simple
and pure and easily written down in a short amount of text, but that
doesn't mean that it's a good language; simplicity by itself is not
magic.
(I half understand why TCL syntax is the way it is, but I don't think it's a good decision. One way to put it is that TCL is what you get if you half-heartedly try to create a Lisp, or compromise a Lisp in order to theoretically get greater acceptance from ordinary programmers.)
But that's the smaller problem. The larger one is that TCL adopted a terrible data model; it decided that everything should be a string. Anything that is not actually a string, such as lists or hashes, is at least nominally encoded in a string with special quoting conventions. In early versions of TCL this was quite literal and caused endless problems with quoting; my understanding is that current versions are somewhat less literal and thus more convenient. But even with the interpreter faking things to help you out this is a terribly limited data model, even worse than Perl's.
This quoting issue was the largest single problem when I tried to use the early version of TCL. It caused me serious hearburn and in the end significantly limited what I could easily do in the language itself; my final program did a lot more in C than I really had wanted it to because of this. The experience was sufficiently bad that I swore off TCL afterwards, despite its attraction as an embeddable language.
(At the time, in the early 1990s, it was your only real option for this.)
Sidebar: my view of TK
I don't really have enough experience with TK to have firm opinions on why it didn't catch on. However, my suspicion is that it was too strongly tied to TCL to work anywhere near as gracefully from other languages. Using TK from TCL makes great use of a number of TCL features in order to make code compact and convenient; my vague experience is that writing TK code in Python is not anywhere near as fluid and easy.
I also believe that TK was mostly or entirely documented only from the TCL API for a long time, which can't have helped. Even today I don't know if ordinary TK installations come with C-level API documentation.