put my OLS slides online, if anyone's curious.
citeseer surfing this evening turned up a more detailed note on the matter of keeping the difference between local and remote resources different, in a program.
I sort of which I'd read this before spending all that time working on berlin. though perhaps the lesson is best understood when experienced first hand.
it is good to think of programs as logical terms, because you can then consider the "specification" or "interface" of a program as some logical term which is implied by another term, say the implementation of the program or the assembly language of it. these are all terms within the same logic, some using a restricted vocabularly but all logically related. the act of "writing a program" is then viewed as "locating a more syntactically restricted term which logically implies the more abstract specification".
this is a useful view since it eliminates the pointless distinction between specification and programming language. you view the programming language as the subset of the specification language that you happen to have hardware which can follow.
for example, say I have a specification / program of the form:
for i from 1 to 10: x[i] := x[i] + 1;
there is no "direct" encoding of that sequence of symbols as something my hardware will try to follow. but there is another program which logically implies the first one:
load r1,1 top: load r2,r1 subtract r2,r2,10 branch-if-zero r2,end load r3,x load r2,r1(r3) increment r2 store r1(r3),r2 increment r1 jump top end:
and this, given a small change-of-encoding into machine words, is a specification my hardware will follow. but note the relationship: the pseudo-assembly implies the pseudo-C, not the other way around. it implies it, not in the informal sense of "it's a reasonable translation", but rather in the formal sense of a computer with memory that can assume various states, and control that passes from instruction to instruction, with the post-state of one instruction being the pre-state of the next. what if your logic doesn't have the symbols "jump" or "for" or ":=" in it? well, it's time to change to a logic that does.
three things worth pointing out wrt. document formats:
editability is a factor worth paying close attention to. many users want to be able to "freeze" a document and make it non-editable, either in the name of preserving "pristine content" or (benevolently) by composing content using a higher-level abstraction than the delivery format.
this has similar moral character to compiling source code, insofar as derived documents are very difficult to produce. many people think that derived documents never happen in the real world; I would advise such people to consider how much worse the web would be without "view source".
machine-readability is also an important factor. if you assume many document retrieval tasks in the future will be partially machine-assisted (beyond merely presentation) then you've got to keep things like citeseer, google, and glimpse in mind when working on document formats.
for non-editable, mostly presentation-oriented documents, the djvu format is very good.
I'm working fully-remote now, which is an interesting change, but really has just served to demonstrate the flexibility of free software to me; with a little bit of glue here and there, the system feels exactly as if I were in the office. minus all the socializing :(
otherwise pretty relaxed. I'll be heading up to OLS in a couple weeks to give a talk on building ridiculously small domain specific compilers. and then I'm taking a fantastic vacation through the western end of the country. very much looking forward to it.
I think you are right about the scene graph location. I was initially quite a fan of "location transparency", but have come to feel that there are always at least 2 locations in any computer program: here and elsewhere. Here is at least host-local, probably user-local, process-local, and even thread-local. Really, I don't think a display server ought to have more than one thread anymore either. I think Miguel was quite right in that argument we had years ago. But that's a different kettle of fish.
In any case, collapsing here and elsewhere into just one case leads to, well, corba. Increasingly, I don't think corba is wise at all; remote resources are just too intrinsically different from pointers.
One might be motivated, then, to wonder what remote resources are like. Obviously with some sequence number trickery, remote resources can be organized into things like streams (hence TCP socket ~~ file descriptor), but can they be made into something even more structured? 9p thinks remote resources can appear like a VFS tree: open, read, write, close, and walk. Seems a useful, and mostly harmless extension. But I think it's important to keep open vs. closed, and explicit i/o, as part of the equation. Trying to do those things transparently is trouble.
I wish paul graham would stop publishing articles claiming lisp has the only useful syntactic metaprogramming system. it's especially irritating since he seems like a smart guy, and should know better. you don't need car and cdr to do good syntactic metaprogramming (indeed, alone they are awkward); you just need a quasi-quote notation and a place to hook your extensions into the evaluator.
hell, even TCL satisfies the menu here, though few people bother to learn it. unless he's been hiding under a rock for a couple years, I can't believe he's seen and understood camlp4, and still thinks defmacro is "unique to lisp".
in response to chalst, and further on the topic of type systems:
there is no deep theoretical difference between static and dynamic type systems. you are still talking about writing a specification (program) in which the computer may do something you do not expect or desire. the only practical question worth asking is: how much confidence do you have that the specification you wrote will get the computer to do the thing that you, or your customers, want?
testsuites test some cases. type systems check consistency. the assumption is "consistency implies correctness", and it's hard to come up with much better definition for correctness than both "testsuite pass" and consistency; in practise this is as close to true as we get.
I've used many C and lisp systems professionally, and a few HM systems, and the HM systems are by far more designed around consistency checking. you can consistency-check lisp if you have the luxury of using ACL2 or a vendor compiler with a deep partial evaluator or soft-type inferencer. but usually in lisp you are working on a lousy implementation, with an OO or struct system someone threw together for fun, and less checking even than the "disjointness guarantee" inherent in fundamental scheme types. likewise in C you are not usually working with a larch or lclint-annotated system; you've got a system which "made up" an OO type system on top of liberal pointer casting, and not a hope in hell of checking its consistency. C++ thankfully has a good type system, but as the original article points out it can get pretty brutal to compile.
the more checking I can perform before I ship something to a customer, the better. imho everything else is religion and bafflegab. ocaml and haskell currently give me lots of good checking without taking away too much, so I use them when I can.
frances and I just bought a small TV/VCR with which to pursue our mutual love of crass anime and high quality older films. lucky for us, suspect video carries lots of both. we're hoping this device will not lead to more actual broadcast TV watching, as we both lost sizable chunks of our childhood to that. so far we're seen keiko kamen and dead reckoning (bogart, 1947). going for joan or arc (bergman, 1948) tonight.
miscellaneous link-dropping: highly satisfied with the recent ghc 5.00.1 release. anyone who's held back from haskell for a while would do well to try it. It now includes a mixed-mode compiler/interpreter with dep chasing and an interactive mode not unlike hugs, only you get access to nice optimized copies of hslibs. It's a 5-minute fix to get emacs hooked up to it, then you have a nice ":reload" function at your fingertips. also pleased with unison, which does what you thought rsync was going to do when you first got it. counterbalance the amusingly pragmatic nature of dumbcode with some positive evidence that not all free software consists of broken instant messaging clients in python: boost, atlas, R, maxima and openDX. finally, was tuning nasty code with some nice profiling tools recently, worth pointing out: cacheprof, functioncheck, perfAPI, and jprof
obTechnicalPhilosophy: there is a delicate balance necessary between sticking with the things you know and can rely on, and exploring things which have the potential to be better. assuming that one or another of these strategies is the one true way is silly.
New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!