On Apr 24, 11:33 pm, Kai wrote:
> The implications of Kay's talk are potent; and when one considers that his
> team at VPRI have mostly fulfilled their vision to reduce the tens/hundreds
> of millions of lines of code needed for personal computing down to under
> 20,000 lines (includes OS, networking, graphics, office apps, web
> browsing), the implications are stunning.
>
> There's much more information available at VPRI's website on the STEPS
> project:
>
> http://vpri.org/html/writings.php
>
> There, filter by "Fundamental New Computer Technologies" and look at the
> annual reports to the NSF for detailed descriptions; the most recent report
> was released Oct. 31 2011, athttp://www.vpri.org/pdf/tr2011004_steps11.pdf
This is a very interesting project. It is clearly related to the
literate
programming topic. I quote from the NSF report:
"In the STEPS system, this document is live: the examples
are actually runnable demos; the code shown is changeable
and testable, etc."
and
"Another addition is the presentation of code as “active essays”
that explain the code by showing how to build it using the live
code in STEPS as just another media type"
Their project goal is to
"The STEPS research project arose from asking embarrassing
questions about many systems (including our own) such as:
“Does this system have much too much code and is it messier
than our intuition whispers?” Almost always the answer was
“yes!” We wanted to find ways to write much smaller code,
have it be more understandable and readable, and if possible,
to have it be “pretty”, even “beautiful”.
Ignoring my literate fetish, though, the formal approach wins.
A lot of the work that Rich has done defines functionality that
allows compact expression, e.g. pattern matching for things
like guards. But pattern matching is a bottom-up technique.
In case you haven't had time to see the talk, the feature of
most interest, at least to me, was that Kay managed to create
a mathematical foundation for the 2.5D screen geometry.
>From that mathematical basis, they derived a correct, small,
fast, and clean program. In 20,000 lines of code they seem to
have built a system from hardware to graphics, a project of
comparable size to Clojure. Would formalizing aspects of
Clojure make it reliably correct? Smaller? More portable?
I can see two directions where Clolure could clearly benefit
from this approach.
One would be an internal development, trying to create a
more formal definition of Rich's ideas of states, identities,
etc., and using these to model software transactional
memory.
Rich has done a lot with locking and ensuring ACID-style
operations. A related piece of formal work can be found in
Chandy and Misra [1] on p278+. On page 281 they show
how to derive an optimized program. In fact, chapter 15
on Mutual Exclusion is a potential starting point for a
Clojure STM formalism.
One the other path, we look at the external challenges.
Clojure deals with concurrency but not with parallel and
distributed algorithms. These are becoming important
as I see a headline on Hacker News about a 32 core
machine. I've purchased 288 computers (a Green
Arrays Forth chip) where everything is parallel and
distributed. What concepts are missing in Clojure to
support parallel work? Lynch's [2] book provides formal
algorithms for handling leader election, stopping failures,
lockout-free mutual exclusion, etc. Can Clojure provide
primitives to support these operations?
If Clojure is to support parallel programming work, does it
need to provide Go-like channels? Does it need a reliable
message queuing primitive (or do we just wrap things in an
STM? But what about retrys?). Everyone has to solve this
problem which implies that language features become critical.
Rich made it possible to hide locking and improved life for all.
A similar set of support for common distributed and parallel
pain points is needed.
Formalism is generally a royal pain. But as Kay has shown
it has the potential to move programming into correct, small,
and understandable realms where we can have confidence
in the result. Better yet, from my point of view, we can write
things that improve human to human communication. A
move to a more formal basis would lift Clojure into a
qualitatively better way to program.
Tim Daly
[1] Mani Chandy and Jayadev Misra
"Parallel Program Design: A Foundation"
ISBN 0-201-05866-9
[2] Nancy A. Lynch
"Distributed Algorithms"
ISBN 1-55860-384-4
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
