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