[plt-scheme] Scheme productivity data point

FYI, a small Scheme productivity data point that I just blogged...

> Scheme Is Likely Fast Enough for You
>
> I needed to process a corpus of HTML files, which involved a bunch of 
> parsing, XPath-ing, simple pattern-matching, a little regexp-ing, and 
> HTML generation.
>
> Using PLT Scheme, Oleg Kiselyov's and Kirill Lisovsky's SXPath, Jim 
> Bender's sxml-match, HtmlPrag, and WebScraperHelper, I banged it 
> together in a day for a sample of the data, then spent another day 
> tweaking it to run through the entire corpus. Most of the second day 
> was due to some strangely bad HTML buried in some of the 40,000+ 
> files, and having to juggle remote computers.
>
> Afterwards, half tongue-in-cheek, I played fanboy for the benefit of a 
> colleague who still wants to do symbolic processing in C++, laboriously...
>
>> [...] The output files take less than 7% the space of the input files.
>>
>> And, for people who think Scheme is slow... Wall clock time for the 
>> conversion (which was doing lots of parsing, XPath, simple 
>> pattern-matching, and a little regexp-ing) was only a little more 
>> than twice the wall clock time of "dd" doing comparable file I/O [to 
>> local disk on a fast machine]. I didn't bother to optimize the Scheme 
>> algorithms, nor compile it to native code. I used PLT Scheme, which 
>> isn't a particularly fast Scheme. At the end of a week, when I 
>> imagine that a Java or C++ programmer would finish coding, I suspect 
>> you'd find that the Scheme runtime performance compares favorably. :)
>
> I don't do much advocacy, but capturing even loose anecdotal evidence 
> of productivity boosts as they happen can be helpful.