SXML and authoring

9 September 2004 12:14 PM (scheme)


Fixed a few broken links on the site recently. It seems a number of people still search for the water management paper we did a while back.

The Apache Redirect and RedirectMatch directives have been crucial to the switch in site structure. I'm going to start a new campaign: No more 404!

er... a little help here?

Four years ago, I put some fortran code on the web, hoping it would be useful. A few times a day, people would go to that page, try to download a file, get a 404, and just give up. Four years of that, and not once did someone email me to let me know. The web is a passive medium indeed.

authoring in SXML

Lately I've taken to writing my web pages in SXML. It's quite useful as a templating engine. I can write simple pages and have them follow the look of the site.

SXML also lends itself well to programmatic processing. SXML provides a higher-order processing framework, pre-post-order from (sxml transform), that is much easier and much more expressive than XSLT. With it, I can write in a domain-specific language, then programmatically translate that more abstract language into plain HTML.

Finally, with SXML it's impossible to write malformed HTML. If the scheme interpreter can read the SXML, it is well-formed, and the translation process guarantees a well-formed output.

The system does have a drawback, though. Whenever a SCM file changes, I have to manually generate the HTML file. This would be made easier by a new Apache module to regenerate output as necessary. Then one could control the rebuilding rules via the standard .htaccess. Such a system would resemble a stripped-down version of make.

quality of conversation

Imagine the kind of conversation you would have with someone so far away that there was a transmission delay of one minute. Now imagine speaking to someone in the next room. You wouldn't just have the same conversation faster, you would have a different kind of conversation. In Lisp, developing software is like speaking face-to-face. You can test code as you're writing it. And instant turnaround has just as dramatic an effect on development as it does on conversation. You don't just write the same program faster; you write a different kind of program.

-- Paul Graham, On Lisp

I've found this to be painfully true, as I stepped back from my wonderfully alive Guile development environment to hack up that wordpress-advogato plugin. I had to code over ssh from Africa to the US to edit code on the live site, because obviously it had to try to place the articles on advogato itself. That was excruciating -- type, and emacs changes a second later. Then to test it, I had to submit web forms back home, then check the different sites to see if I messed things up. I was shouting from another continent. Thus, the plugin sucks a lot.

I did fix up one thing recently, though. The output filters are applied before the data is sent to advogato. This should fix the paragraph problem I used to have.

Comments are closed.