I'm not in the mood for writing a teaser, just read programming considered harmful it turns out to be strikingly close to some of the thoughts i've been having for the last few years.

I'm not sure why, but my personal webpage has demonstrated a lot of problems i see with existing software--programming languages, operating systems, file systems, content management systems, databases, etc. For years now i've wanted to completely revamp how i create my web pages, but every time i go to plan it out, i find myself redesigning more and more things, until i find myself wanting to start from a completely new processor architecture and build from the ground up.

Hierarchy is one of the things that has bugged me most. I put hierarchy into my image collection, and this pyblosxom blog system organized things in a ridged hierarchy. The problem is that hierarchy never works right for me. This blog entry is a good example, is it a ramble, or a technical article, or a technical speech. And when making the hierarchy, i sat for hours trying to decide if books, articles, and speeches should be subsets of technical and humor or vice versa. The same thing with image categorization, is a sunset an event, or a landscape, or a thing? Eventually i just made myself be arbitrary because i wasn't getting the problem solved.

In Ontology is Overrated (also hear the audio version), Clay Shirky argues that hierarchical categorization is fundamentally not what we want, except in certain very limited situations. I highly recommend skimming what he has to say on the matter.

This is actually why i'm so excited about spotlight. While not everything is there yet, it is headed in the right direction to allow your operating system and filesystem to be your content management system.

In the meantime, i'm off to go work on redesigning our concept of the ALU.

Eric got me interested in Plan 9, especially it's 9P protocol (see The use of name spaces in Plan 9 and The organization of networks in Plan 9).

The synopsis is that Plan 9 treats everything as either a file or a collection of files. If you want a program (or script) to interface on a network socket, rather then using calls like socket() and bind(), you open files in directory specified by convention. This is really interesting in that when you are creating a new programming language, you only have to import the system calls for interacting with the file system (~13 if i understand correctly), and your new language can interact and control _any_ of the system devices, network, etc. 9P is a simple protocol that implements these file system interfaces over a simple channel. Plan 9 also has per process filesystem name spaces; each process can mount/bind to change its view of the filesystem. With a network channel and 9P it can mount a file system from another computer. The remote computer's file system includes all of its device files though, so if our process binds the portion of its file system implementing networking, for example, our process has essentially gained the ability to proxy through that computer. Since all system interactions are done through the files system, with proper permissions anything can be used remotely!

I've been thinking more about capability based languages and operating systems. From my understanding, such a system can be built on scope: if code only has access to what it has been given (which should be only what it needs), and if there is no global/static state including library calls granting it access to such, then it is secure.

Between Plan 9 and capabilities, namespaces are apparently quite an important topic. So important that... why shouldn't they be first class?

Searchings doesn't turn up an overwhelming amount of material on first class namespaces. First off, mit and umb schemes apparently have first class name spaces. They have a 'make-environment' call, and an optional argument to the eval function, specifying an environment. Not real exciting.

On the other end of things, there's Symmetric Lisp, which completely remolds lisp with first class namespaces. Interestingly, things like structures, classes, modules or packages, closures, and even streams can be modeled using these namespaces! The final surprise is that they get parellelizable code for free! (see Environments as first class objects and A programming language supporting first-class parallel environments)

Finally, Erlang make concurrency incredibly simple. They have a function like primitive that you wrap your function call in. The primitive runs that function as a separate process (possibly on a separate computer) and returns a handle which can then be used to pass messages. It makes concurrent programming incredibly simple.

Now, if i could only make a capability based language with first class concurrent environments.

There's a good example of rolling an example modal web server (formerly known as continuations based web server). I was easily able to follow this article, but i'm not sure if that means anything as this is possibly the first time i've tried again after really getting continuations. (I think Lisp in small pieces and the mini scheme interpreter built in PIAP are what finally completed my understanding, although a page about call/cc helped seed the more practical side of understanding.

Thought provoking short story: The Algorithms for Love.

Someone on Planet Lisp pointed out NIST's Dictionary of Algorithms and Data Structures. There i happened to run across the Doomsday algorithm, which helps you compute the day of the week any date was on---in your head! It's really surprisingly simple.

It has been popular to desecrate the C language by referring to it as some kind of a glorified, semi-``portable'' assembly language. A recent thread on comp.lang.lisp grabbed my attention by stripping its claim to assembly: LISP to C vs machine level. The post points out quite a number of problems that challenge LISP implementations that target C.

This reminds me to my college programming language class, where a friend and i wrote a small language which was targeted at C. While it made interfacing to other libraries a snap, trying to fight with C to control the stack quickly demonstrated how C fails to be a convenient assembly language. Luckily, though, we wrote the compiler in Python. It was sad watching our classmates struggle with every architectural change they had to make.

If i had to do it again, i think i would target assembly, and try to do something similar to Stackless Python.