David's Blague

I'm sitting in the speakers' lounge at the O'Reilly Emerging Technology conference, frittering away my last few minutes before the speech. If you're in the audience, and you read this while I'm talking, then STOP SURFING AND PAY ATTENTION!

Just kidding. I'm actually surfing the web up there on my other screen, too.

Once I'm back in DC, I will post slides, the text of the speech (as I wrote it, not as I spoke it), and all the code samples and GraphViz dot files. And in case you missed it, there will also be audio available courtesy of the fine folks at O'Reilly.

Wolfram characterizes the class of cellular automata pictured here (of which this is but a sample) as "one-dimensional". He further characterizes any cellular automaton rendered on a two-dimensional grid as being two-dimensional.

But is this actually right?

The problem is this. Rendering the model in a single dimension does not make it one-dimensional any more than rendering it in two dimensions (note that this, in fact, is what Wolfram's model does as pictured here) makes it two-dimensional.

The state of every cell (black or white) in a Wolfram-style automaton depends upon the state of exactly three other cells. If the term "dimension" is to have any meaning in this field, nascent though it may be, it must have some correlation to the realities of the underlying model.

Each cell in this picture is of the following form:

Each cell has three ancestors. Wolfram conveniently deems the Middle Ancestor to be "Cell on a previous time step," but there are certainly plenty of applications for cellular automata where time is not even a consideration (at least not in the way physicists think it is).

It turns out that Wolframs simple class of cellular automata could just as easily be rendered on a 3-d grid like the Game of life (The three dimensions being height, width, and time). They could even be rendered as a (possibly infinite) 3-d solid.

So why settle for sloppy definitions of dimension?

Well, it's quicker, for one. It's obvious, for two. But it's still wrong.

The picture we started with should be called a "two-dimensional projection of a three-dimensional cellular automaton." This would, at the very least, give the cellular automaton with two neighbors first-class citizenship (come to the talk or ask me afterward why this is important for the field).

The problem with blogs these days is that everybody's got one. Everyone who wants a blog can make one easily and for free whether they have something to say or not, so why post your valuable opinion on someone else's where you'll be relegated to a threaded discussion when you can headline your own.

Note that this site lacks any place for you to comment. Because it's not about what you think, it's about what I think.

That being said, what I miss about, say, the early days of Slashdot, are the knock-down drag-out fights that could be found all in one place. In order to find fights like that these days, I'd have to visit nine or ten different sites, and even then everyone might just be getting along.

Even on the wikis you now need to pay pretty close attention before the janitors clean up and throw away all the good civil discourse (apparently Wikipedians don't share everyone else's conviction that it's a great place to argue).

So what we need is a place for good arguments to happen. Knock-down drag-out Emacs is better than vi, Gnome beats KDE, Windows versus Mac, Protestant/Catholic kind of things. And since every argument has (at least) two sides, (at least) two authors should be first-class citizens. And everyone else should have an easy way to gather in a circle and jeer while they see civil discourse at its best.

That is what we need: a big online argument.

I mean, besides the Internet.

Labels: argument, blog, shouldbe, wiki

While rehearsing for my presentation at the Emerging Tech conference, it came clear to me that the term "cellular automata" is in that awful, yet oddly ubiquitous class of scientific terms that explain exactly nothing to the lay person.

I am all for obfuscation when it serves some purpose, but in this particular case, the term doesn't do much for hackers, either. Lacking a PhD, I can't speak for them, but the only purpose I can imagine such a term would serve, is to make the speaker sound "really smart" (read: like a pompous ass). The term was coined by a guy whose first language was abstract math, with Hungarian as a close second- not exactly the poster children of clarity.

Here is where I've arrived so far. It still needs polish:

A cellular automaton is a graph, with each node (cell) on the graph containing exactly one member of a finite set (value). The state of the model is completely specified by the values of each cell. The value of a cell is updated by applying a rule to the values of its neighboring cells.

My objection to other descriptions I read are not entirely overcome by my own description. I have used the words "graph" and "node" from graph theory, and implied the word "vertex" without using it by using the phrase "neighboring cells."

Not perfect.

But better than some. My big objections to other descriptions is that they include too much math, physics, or biology to be considered generally useful abstractions. After all, one of my favorite models in this class is from a social scientist.

Labels: cellular automata, discrete models, etech, graph theory

I am a Kool-Aid drinker. One summer, my college roommate and I drank 400 gallons of the pre-sugared variety, and saved all of the containers in a large Kool-Aid pyramid. And not just for the free stuff we could have gotten, had we bothered.

That, as usual, is a tangent.

I also drank the Free Software Kool-Aid. Richard Stallman is right. Open Source misses the point. But I think Richard also misses an important point, which I'd like to address: the development practices associated with "Open Source" are not, in fact, practical or pragmatic.

When I, a programmer, write software, I do so to solve a problem that I have, or that someone else has paid me to have. I do so with the understanding that I will spend the least total number of hours possible on the lifetime of this problem. It is because I understand the virtue of laziness in a programmer.

As soon as the new GNU General Public License is completed, it will become my license of choice. In the meantime, I use the current version (GPL v2). I license the software under these terms, so that other people will have the option of making my software more useful for themselves.

In doing this, I exercise my essential freedoms, and accept the fact that others share these essential freedoms (they are, after all, essential). In exercising my freedoms, I have sacrificed nothing, and possibly provided something of value to someone else. But it is that person's freedom to make my software valuable to herself, not my responsibility.

The latter is a theoretically pragmatic argument (If more people use the software, it will be better) made by advocates of "Open Source" philosophies.

It is, simply put, not entirely true.

The siren song of the programmer is to solve generic problems (e.g. Object Relational Models or Full Stacks or Productivity). And in doing so, programmers often doom nascent efforts to poor performance, long development cycles, and, perhaps worst of all, frustration for the programmer.

Whereas solving specific problems well results in joy for the programmer, code that is written quickly and performs according to the programmer's need or skill, and code that may (or may not) be generally useful.

Over the long term, after enough programmers have done this, meta-programmers (e.g. RedHat or Apache or Ubuntu) can string together enough narrowly useful pieces to make a system that is generally useful. But systems that set out to be generally useful rarely are.

To me, the ethic of Free Software is a true ethic of freedom, and my chief responsibility is not to take these freedoms from anyone else.

Now that's pragmatic.

Labels: development, freedom, software

Well, Testy 0.1 is built, commented, passing all 30 tests (had to cut a few out), and installed on my local machine, doing everything I need it to do.

I'm calling it version 0.1, since it "works". My next milestone is self-hosting (e.g. getting all of Testy's tests in Testy). That will require quite a bit more doing on the output side, but I think most the input is there for now.

Following that, I'll play around with some UI options. I'm thinking 3 or 4 minimal mod_perl handlers, wrapped with some HTML::Template and some CGI::Application.

Anyone interested in seeing what it looks like so far can browse here: http://testie.googlecode.com/svn/.

If you do, let me know what you think.

Okay, so I've been going on and on and on about all the new kinds of laziness I've discovered. I'm using a full stack framework, I'm not making anything configurable, I'm not making anything portable.

Damn, this is going fast. Over half my tests are already passing.

And I'm having some fun.

This afternoon's rant is about databases, and all the things they can do, but don't do when developers rely on the least common denominator.

Foreign keys are great. I'm using them in Testy, and they're doing exactly what they're supposed to: protecting referential integrity. If you're writing an application to use "any" database, you can't rely on foreign keys working like you'd think they should. But if you're writing it for your own database, you know how they work.

The same goes for NOT NULL and PRIMARY KEY. The former can be used to ensure variables have values before being stored, and the latter can be used to ensure uniqueness.

Why not use the database for what it's good for?

Maybe part of the problem is the proliferation of Object Relational Models and other database interfaces that try to generalize the interfact to the database across all drivers. Maybe the problem is that developers are so used to handling everything in the application layer that they've forgotten what a database is good for.

As for me, and my house, we will use MySQL 5.x, and use the hell out of it.

Because we're lazy that way.

It's possible that portability and configurability are the enemies of rapid software development.

Now, up to a point, I'm all for making software portable or configurable. For instance, if a piece of software can only run on my laptop, it's only useful to me. And if I have to change source code every time I change to a different computer or database or password, that's probably also bad.

But how bad?

And is that really ever a problem? I mean, really?

In reality, the opposite problem occurs more frequently. I start writing some code, and think to myself, "What if the person using this code doesn't have a database? What if they aren't using MySQL? What if they don't have anything but a stone tablet?" And I start moving from solving my own specific problems to solving a set of generic problems.

I think I mentioned in a previous post that I'm writing an irritable piece of software called Testy. Now, if you're writing a piece of software called "Testy," it damn well better have good tests. So that's where I started. I usually end up in the t/ directory pretty soon after starting a project anyhow, but this time I really did start there.

And I found myself doing what I always do- trying to make the (largely unwritten) software do things that I simply don't need.

So I stopped.

Paused.

Re-read some chapters of Getting Real.

And I wrote three sets of tests (for unit tests, plans, and tags) that do exactly what I want them to do, and nothing more. No extensibility, no configurability, no premature optimization.

Phew, this is fun! Someone had better hire me quick, or I could start to enjoy this a little too much.

Now that Surely the Robot has lived her 90 seconds of fame (I swear I will post it here when she's on HGTV), I've turned back to software. At the moment, I'm flying solo. Primarily due to the fact that nobody has hired me to fly point.

I've been playing with Perl 6 a lot. You want it, it's cool.

And I've been playing with Jifty.

The two projects have got me thinking about how software development should be handled, particularly on a big project. The tool that I'm writing at the moment is called Testy. Testy is an irritable unit testing framework.

Heh, I said unit.

My first version of Testy was written in Jifty, and it took about half a day. My result was not particularly usable, but it was quick. Testy allowed me to create testing plans, add unit tests to those plans, and, finally, to tag them.

I know we're going to look back on tagging in another ten years and say, "huh?"

Anyhow, I did all this without much of a plan, and it was a great experience. I had an idea, I executed it, and I was able to quickly move to thinking about all the problems with my idea. Before I'd even shown it to anyone.

How does this relate to Perl 6?

Pugs serves much the same purpose for Perl 6. It's not being built from a spec- it's being spec'd from a build. I imagine that Pugs will eventually cease to exist, but its purpose in the development cycle is nonetheless critical.

So, while I'm not a huge fan of "full stack" web development frameworks, they do serve the purpose of going from nothing to a finished application very quickly. And if the finished application isn't fast enough or pretty enough, I imagine it will be easy enough to clone it without all the overhead of the framework.

We'll see.