Scott Hanselman goes ga-ga for the SideShow API, the Vista functions for auxiliary displays. When I was first told about SideShow quite a while ago, the emphasis was on displays embedded in the outer shell of the notebook, just as clamshell phones often have a little aux display on their surface. I wrote an article back in 2004 in which I was more excited about “REM mode” applications (applications which can be run by a computer that’s somewhere between hibernating and fully awake) than by the aux display itself.
Happily, the SideShow APIs seem to be fully decoupled from the physical attachment of the display, so Scott’s excitement is primarily about using the SideShow APIs from one’s main desktop machine to drive alternate displays.
Wesner Moise points to “generalized regular expression matching” as a moderately hard problem that might serve as the basis for comparing programming languages and approaches. He says “Microsoft’s implementation of regular expression matching over strings is spread across 24 files and 14,455 lines of code including comments and whitespace.” (I’m not sure how he’d know that — I assume he’s talking about Rotor source code.)
He wonders if a functional approach could be more efficient and points to a 14-line Python program.
No, no, no: they are two incredibly different capabilities.
The Python program implements something like the original definition of a regular expression –restricted to that which can be expressed in a single line of Extended Backus-Naur Form without recursion. “Regular expression support” for today’s languages means something very, very different, starting with compatibility with Perl5 and going from there. Backslashes, named groups, etc. are complex features that require, in any language, something in excess of 14 lines.
Having said that, regular expressions are a good fit for functional approaches. But, just to point out the lack of silver bullets, attempting to parse a left-recursive grammar (a grammar with a production of the form A->AB) will hang a simplistic recursive-descent parser.
Tim O’Reilly posts his always-intriguing quarterly analysis of the tech book sector.
Joe Gregorio interprets the 53% growth in sales of Ruby-based books as evidence that there is no “next Java” or “next framework.” I’m sympathetic with his thesis, but I’m not sure that 53% growth counts as any kind of failure…