600 Lines of Code

Like Charles Petzold, my first reaction to Jeff Atwood’s question “What Can You Build in 600 Lines of Code?” was along the lines of “5 articles!”

But actually, I think 600 lines is just about the right benchmark size for a language, because it’s:

  • Small enough to develop in a weekend
  • Large enough so that “finger typing” is neither dominant nor drowned-out
  • Large enough to exploit a language’s particular idioms and strengths

A caveat though: the use of libraries and frameworks can grossly distort this discussion. Frankly, the quote “commercial project written in less than 600 lines of Ruby code” (ibid.) is wrong: it ought to be “of Rails code.” It’s akin to saying “In DOS batch I can create a spreadsheet in a line of code — all I have to do is type ‘excel’!” (I know it’s not exactly the same, but there’s a similarity.)

This is one of the reasons why writing a parser has always been a measure of a programming language — it involves complex pattern matching, the creation of a complex datastructure, transforms of that structure, and a fair amount of IO.

Harry Pierson’s F# PEG parsers (is that redundant?) are a good example: I don’t doubt he’ll complete a parsing front-end to the “ToyScript” language in less than 600 lines of code. The first night at Lang.NET, I wrote an ANTLR parser for ToyScript (# lines in ANTLR, expands to # lines of C#!). From the impression I got of Newspeak, I think it would take significantly less than F#.