I've been trying to get going with the whole PhD dissertation thing for some time now, and I seem to have gotten out of the habbit of writing. Now, this is a problem, because the things I want to cover in the modeling languages book require a good deal of tricky writing, and I'm just not up to it yet. So I've started work on a less ambitious project, one which I hope will help me ramp up to the modeling languages book - a book on little languages. I've even started a web site, littlelanguages.com, to start working out some of the ideas for this book. It is my hope that I'll be able to pull together a good primer on these techniques which I use all the time, and that the experience of writing the little languages book will give me the momentum (and expertise) to write the modeling languages book.

This is mainly a warning to my friends. T and I saw UltraViolet this weekend with Alex, and it is bad. Really bad. Don't give them money. Watch something else.

So I was talking to T about better ways to spend $200 billion dollars to insure the safety of Americans than fighting in Iraq. Here we define better as more likely to reduce American casualties. This is a short list, though I'm sure you'll have your own.

• reduce driving fatalities
  In 2003, there were 42,643 driving fatalities in the US (17,013 of which were alchohol related). Let's say that 200 million of the US's 297 million population are drivers (a high estimate), that's $1000 per driver to reduce fatalities. Do you think we could make a dint?
• reduce infant mortality
  In 2003, the total infant mortality reported by the CDC was 28,428. That averages 6.9 deaths per 1000. Think we could make a dint in that? Think of the children.
• reduce suicides
  According to the CDC, in 2001, suicide took the lives of 30,622 people in the US. In 2002, suicides led to 132,353 hospitalizations, and 116,639 trips to the emergency room which did not require an overnight stay. I'm sure we could do something for the emotional health of the 100,000+ people a year who hurt themselves (and impact our health costs).

I've got something. Not sure what it is, but it isn't bad enough to stay in bed, though it has brough me home early from work, and I did skip a day last week. It just isn't going away, I've had it for about a week now. My sinuses itch.

In other news, work's interesting, but I can't really talk about it. I've got a largeish project I'm working on, hoping to finish this week, and I'm doing lots of documentation/process work to try and clean up projects of this sort. Keeping me busy, and a little confused.

I'm hoping to start making some real progress on the Disertation front soon, I'm beginning to piece together a larger outline for it, and I've made some changes to the core terminology that I think are solid.

Here's a neat bit of python I worked up for fun the other day. It's a curry function, but it supports keywords as well, I call it kurry. Using kurry, you can do the following sort of things, which is quite useful in python: def foo(a, b, c, d, e): return { 'a': a, 'b': b, 'c': c, 'd': d, 'e': e } bar = kurry(foo, 1, c = 3, d = 4) assert(bar(2, d = 5, e = 6) == foo(1, 2, 3, 5, 6)) The code for kurry makes extensive use of python's variable-argument and keyword mechanisms. The following things are true: def varargs(*args): # *args in param def means collapse args into tuple return args assert(varargs(1,2,3) == (1,2,3)) # *args in function call means expand arg tuple assert(varargs(*(1,2,3)) == (1,2,3)) def varkwargs(**kwargs): # *kwargs in param def means collapse keyword args into dict return kwargs assert(varkwargs(a=1,b=2) == {'a':1, 'b':2}) # **kwargs in function call means use dict as keywords. assert(varkwargs(**{'a':1,'b':2}) == {'a':1, 'b':2}) Here is the code for kurry: def kurry(func, *cargs, **ckwargs): "curry a function, with keyword support" return lambda *largs, **lkwargs: \ func(*(cargs + largs), **dict(ckwargs.items() + lkwargs.items())) We save the positional and keyword arguments at kurry time, and we append the new arguments, and update the keywords at call time.

Theresa and I spent saturday (Oct 22nd) at the 2005 Space Eleveator Games from elevator2010.org There was a lot of cool stuff, and we got about 4 hours worth of footage. We're going to cut this together into a series video pods, and we plan on getting the first one out this week.

Morgan is in town, and he and T and I are all heading to see The Brothers Grimm at the matinee today. It looks purty, and since I was raised upon quite a few books of fairy tails, I'm totally siked!

This absolutely fascinated me, it's a gallery of anti-sit technology, litterally, different devices for impeding sitting on various pieces of archetecture. The Anti-Sit, Boing Boing

So, I'm trying to start my disertation, for real, really. Really. God. Ick. Okay, here's my pickle. I'm trying to describe the problem that my work addresses in a readable manner (see "How to do things with words" for a good example of 'readable'). The polite way of talking about this is that you mustn't tell anyone that they are wrong. People reading about language design already have pretty strong opinions about what they are doing. So, let's see, a language is:

1. A set of symbol strings, as defined by some automata (from finite automata theory).
2. A mapping between 2 discrete symbol fields (from semiotics).
3. Both 1, 2, and the domain knowledge necessary to edit statements in the language (from psychology).

So I'm trying to describe this whole design problem, with minimal jargon. I know that I'm not getting out of this without some jargon (but a big part of my planned doctoral work is driving the various field's jargon towards coherence), but you can't open a book with a sledgehammer of vocabulary. You have to hold people's hands, and walk them comfortably into the context you are trying to deliver.

I've just put together an Mbook for Accelerando, which you can pick up from ACCEL.
Btw, California is awesome. I've just gotten my blog environment back up and running. I'll do a post about who I work for in a day or two.