Tony Faustini on OCUR and Lucid recollections

0
177

Tony Faustini, of Microsoft’s Silicon Valley Media group, is interviewed by this french site about the forthcoming OCUR standard for Media Center PCs. (Google-provided English translation here.)

Why do I point this out? Two reasons.

First, I’m looking into setting up a Media Center Edition and I learned at Mix 06 that I ought to check out some of the new HD capabilities coming soon. And Tony talks about the new OCUR (Open Cable Unidirectional Receiver) standard built into the CableCARD-ready Media Center PCs. The jist of it is that you’ll be able to connect your cable directly to a box connected to the computer or embedded within it and get HD. All of this is targeted for the Vista time frame.

Second, Tony was one of my CS professors at ASU. His research centered around rethinking programming languages. In particular, he was known for his interest in data flow languages and at the time a language called Lucid.

Lucid tried to challenge the way you think about programming. It’s not a step-by-step procedural language like C++ or CSharp. Nope. Instead you think in terms of infinite streams and writing filters that manipulate them.

A Lucid block of code might look like:

x
where
x = 1 fby x + 1
end

In English this says, a “stream” called x starts at 1 and increments by 1 each iteration (fby means “followed by”).

I was never very good at writing a Lucid program. I couldn’t break the procedural habit, but a few things stuck with me.

When I take notes, for instance, I often write “fby” rather than “followed by.”

And when I’ve experiment with languages that describe the processing of image streams (one of my other hobbies), I keep coming back to using “where” clauses–similar to Lucid’s–that specify what operations should apply to a given image. I often use “lazy” arrays too–another Lucid implementation trick–which only keep track of what’s needed to process a statement. For instance, when differencing consecutive image frames you may only need the current frame and the preceding one. That’s all. So there’s an image at time t and an image at t-1. The rest of the “array” doesn’t exist yet or is discarded. If a function needs four frames, then it only has to keep an array or queue of four images. Other data structures can work the same way. You just keep a history long enough as you need.