" /> Ezra's Research: September 2006 Archives

« August 2006 | Main | October 2006 »

September 25, 2006

Bloody Semicolons

Tim Bray, who is writing Ruby code for a comment-management system on his weblog:


The only downside is that I have to make a few adjustments to the current publishing engine, which is Perl, and to the client-side stuff, which is of course JavaScript. I keep putting : in front of constant strings. And forgetting parentheses. Especially empty parentheses. And semicolons. Especially semicolons. Bloody stupid useless semicolons.

Tim sounds like the ideal user for Links.

Oh, but Links has semicolons.

September 19, 2006

Things I learned about TeX today

  • Unlike every other program that goes looking for files, TeX does not accept a -I argument to tell it where to look.
  • The TEXINPUTS environment variable can be used to control where it looks, but if you don't know the secret, you'll think you have to include every standard TeX directory as soon as you use this variable.
  • The secret (see #2) is that beginning or ending TEXINPUTS with a colon means "include all the standard directories."
  • By default, one of the standard places it looks for include files is under $HOME/texmf. It is wise to put your downloaded packages in there, if you know the second secret.
  • The second secret is that there is a secret way of laying out your files underneath $HOME/texmf. And even though TeX keeps an ls-R file to index all those files (use texhash to update the index), it ignores the ones that aren't exactly where it's expecting them.
    TFM files: texmf/fonts/tfm/fontXX.tfm
    Bitmap (PK) fonts: texmf/fonts/pk/print-driver/fontXX.YYYpk
    Style files: texmf/tex/generic/*
    Font alias mapping: texmf/fontname/texfonts.map
  • The package I care about, chess package, automatically installs its files under the directory of my choice, using a certain hierarchy within that directory, but it is not the hierarchy TeX is expecting.
  • The chess package is over ten years old, and when you run it, you get a warning about "using babel with an old interface," also warning you not complain if you get further errors. You get further errors, but you can ignore them.
  • You can control the resolution of the fonts that xdvi uses by telling it xdvi -mfmode :600 (your resolution in place of 600). You cannot, in any easy way that I've been able to dvine, tell METAFONT to generate fonts in the same resolution that xdvi expects by default.
This is post #128 on this blog.

September 13, 2006

Coq

Earlier this week I started to learn Coq, the proof assistant. I was able to get going in just a few hours of monkeying around—it's clearer and easier to use than I expected, and much more pleasant than previous stabs at Isabelle and the like. My advice to Coq learners is to sit down with the IDE, the tutorial, and the tactics index. Using it is largely a matter of throwing different tactics at the proof until they seem to give you some progress. Of course, having a measure of mathematical and logical reasoning helps, too.

By the end of the first half-day of tinkering with it, I was able to show that every lambda-term has a variable as a subterm. Doesn't sound too impressive, but when you see those nice lemmas and their proofs all written out and mechanically checked, you get a feeling of goodness on your insides. Plus, the hours I played with it just slipped away (though whether that's a good quality or a bad one is debatable). You heard it here first, folks, Ezra elias kilty Cooper gives Coq the thumbs up.

September 1, 2006

Typographical values

Tim Bray has been learning up on Ruby lately, and his comparison of it with the Lisp tradition is too tempting not to respond to:

... as I would have been if I didn't pre-empt it here, every MIT undergrad was doing this kind of thing in Lisp by 1970, isn’t it quaint that the world is catching up, etc etc.
And they’d have a point; but Python and Ruby seem to have oozed further into the mainstream than Lisp ever has.

“Why?” is an interesting question, and I think the biggest single piece of the answer is inheritance from Perl’s culture of ruthless practicality. In other words, not afraid to use syntax to make the point; things are generally lists, except when they’re not; attention to typographic values; building hashes and regexes into the language; not requiring you to ever say “lambda”. Any more?

I'll agree with some of those. Using "lambda" to mean "function" has probably turned a lot of people off Lisp. It's shame they didn't get over that geeky pleasure earlier.

Building dictionaries into the language is a big step that's easy to underestimate: so many things are easily and efficiently done using that data structure.

I don't know what "not afraid to use syntax to make the point" means, nor "things are generally lists, except when they're not." Is there some oblique reference here that I don't get?

Of Tim's notes, the one difference between Lisp and the current crop of dynamic languages that's really critical in my opinion is "attention to typographic values." Ruby, Python, and Perl, to different degrees, are fun to read and write because they're fairly "concrete," in the artistic sense: the code looks like things.

It's a curious fact about Lisp that it originally had an infix notation with more ordinary symbols—the so-called M-expressions—but the abstract, parenthesis-heavy syntax (S-expressions (I use it in my prose (sometimes))) was more popular in that community, apparently because it was more susceptible to macros and meta-programming.

The vast majority of developments in the functional-programming world, after Lisp, have returned to more concrete syntax, and greater typographic values. ML and Haskell allow you to define an infix operator out of nearly any string of symbols, and library writers use this facility, though modestly. Matrix arithmetic is made easy to read, for example, by using mnemonic infix symbols for the relevant operations. Arrow-like operators are nice mnemonics for I/O, for piping data from producer to consumer, and for table lookups.

On a higher level, Tim's analysis is a little lax: I don't think typographical values are part of Perl's "ruthless practicality." They're a stylistic trait that might have been thought of as experimental at first, but which panned out in the end. Language design is an endless process of evolution: of failed experiments and surprising developments that come from breeding with your perverse distant relatives. Perl injected a load of interesting new genetic material and Ruby is the descendant that's optimized it.

Sometimes, outre language communities like the functional community (think Lisp) are dismissed because of impracticality; but these communities develop in isolation for a while and come up with interesting features, which are later able to breed back in to other languages. An excellent example of this is the fact that Perl, Python and Ruby all have variants on Lisp's map and filter, which "mainstream" languages like C, C++, and Java had completely ignored. I see it less that Ruby succeeds where Lisp failed to become popular, and more that these island communities are presently interbreeding after a period of independent development.