Older blog entries for graydon (starting at number 95)

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.

document formats

three things worth pointing out wrt. document formats:

1. 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".

2. 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.

3. 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 :(

ported some bits of slib to ocaml and built a quick sqlite binding. finding ocaml just keeps growing on me as a "serious hacking" language.

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 that eval, in its lisp form, is another of those sorts of things the ML/haskell world usually frowns on as "a bit too dynamic". you don't even know when an eval'ed sexp is well typed. that's scary. that said, there is still dynamic caml should the need arise.
• TCL is actually an interesting case. I used to think it was just a complete joke, what with basically no datatypes, but I'm finding myself occasionally forced to use it (sigh.. work), and each time I am impressed with how far you can go with a clever quoting system and a single datatype. it's further than you think.
• with respect to camlp4, I do think the macros offered are "as powerful" as those in lisp, by any reasonable measure. consider:
  • you can write your own lexer. you don't have to shoehorn your macro notation into sexps</a>
  • you have explicit or implicit control over source coordinates
  • you can programmatically construct your results, or construct them through quotations, or both
  • you can name and layer quotation expansions of different notations
  • you can replace the core grammar of ocaml, essentially re-tasking the ocaml compiler to a "new" language with ocaml semantics.

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.

technik: the SICP text is still online here, though mirroring it might be wise.

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.

A fab month. Graduated with surprisingly higher marks than I thought I deserved, got married and spent the weekend playing skee-ball and air hockey and mini-golf, and am now happily settled into my den of evil at redcygnushat.

Still basically obsessed with the prospects presented in hehner's book which has been consuming my free time since I found it in february. Many new things afoot, but increasingly unable to talk about them. poo.