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#.