This is my promised post on standards.

In my experiece the best stuff is designed by very small groups, ideally one or two people. Any group larger than that seems to wind up in the Swamp of Design by Committee. This explains why Python, C, and Scheme are great languages, and why the IT standards designed to support our nation's roadway automation (http://www.ntcip.org) are such a mess (http://www.kneuro.net/jk_old/traffic/).

Of course, small groups aren't a gaurantee that you'll end up with good stuff, but large groups invariably get it wrong, in my experience. Often, this is because various interests are at odds and exerting pressure on the standard in different directions; and in other cases, it seems to be more about ego.

In the couple of committees I've sat on, all related to traffic-control-device standards, there were a small number of individuals who usually got what they wanted; and technical merit was not always the deciding factor. There was definitely a pecking order among the more vocal committee members, and then there were also some individuals that stayed more or less on the sidelines and simply voted on whatever issue the others had brought to the table. The folks on the sidelines were often the ones with the best technical arguments, but it was difficult for them to get their views a fair shake, because they were often technical people (programmers, mainly), whose social skills tended to be overshadowed by the more management-oriented types. In one case, this dynamic resulted in a simple and elegant 30-page version 1.0 standard being expanded to more than 200 pages in version 2, with little practical increase in supported functionality. This was largely because the strong voices insisted that the standard had to be structured in a particular way, while at the same time many different individuals wanted to get particular features included.

Ego is a great thing; without it, nothing would get done. But it seems to work best in small quantities. An individual with the drive to build something useful, beautiful, or popular, can produce a cohesive whole. What should have been done in the above case, in my opinion, is that the governing organization should have tasked one or two individuals with the production of a coherent standard; the role of the committee would be merely to approve or reject that standard, not to micro-manage the language of the standard itself.

Doesn't everyone want to design a programming language? Maybe not; it seems a thankless task in the long run. Look at poor Bjarne Stroustrup.

But I'm thinking about giving it a whirl, anyway. I've tried to come to terms with Common Lisp (too many practical problems) and Scheme (too verbose, no macros), but I always seem to end up doing most things in Python. Python is, as Paul Graham has mentioned, one of the Lispiest of the current crop of "scripting" languages, yet it still lacks things that Lisp hackers avow are integral to the spiritual core of Lisp. The possibility of insane power lurking just out of reach is like an itch that I can't quite scratch. What I want is essentially Python, with Python's standard library and all that it implies; but with more regular syntax, and real, Lisp-style macros (probably not hygienic ones). My name for this beastie is _Pomo_:
a pun on "postmodernism", or, if you prefer, an acronym: Python On Macro Opiates.

So I'm thinking about implementing Pomo as a thin wrapper around Python. I would give it I-expressions (like S-expressions, but expressed via indentation) for traditional Python feel, yet would allow S-expressions when they were convenient. I'd provide defmacro, backquote, comma, and comma-at, and provide all of this as a Python module that can be used to parse Pomo code and turn it into Python, expanding macros as necessary.

This really sounds like fun...

I've spent the past, oh, four hours or so, in the middle of the freakin' night, absolutely captivated by Steve Yegge's rants: http://www.cabochon.com/~stevey/blog-rants/

Later.

I've been doing a lot of thinking recently about abstraction and how to achieve abstractions that can be easily tested. This is an important issue in software development, because making code easy to test is really the only way to ensure that the code will actually be tested.

I spent many years writing C++ code and doing ad-hoc testing. During those years, the code I wrote tended to have this kind of organization. That is, the application consisted of some code that implemented a tower of abstractions which interacted with one another in a layer-oriented way. For example, the top abstraction layer might be "Score", which implements an abstract interface to musical compositions; the middle layer might be "Instrument", which "Score" uses to play itself on a particular instrument; and the low level might be "MIDILayer", which handles pushing MIDI messages out to physical instruments in order to play the score. "Score" might instantiate a number of "Instruments" to play itself, and each "Instrument" would use the "MIDILayer" to send appropriate messages over the MIDI bus.

The problem with this is that, unless you are very careful about the design of the interfaces between layers, it can be extremely hard to test the "Score" class without working implementations of "Instrument" and "MIDILayer". And "working" can often mean that "Score" only works if the lower layers are fully configured for real-life operation. In some cases it may be reasonable to implement fake layers that mimic the behavior of the real layers, but on the other hand, it may not be possible. If, for example, one of the layers is a network-transport layer that uses socket handles in its public interface, or something like that, then implementing a dummy interface is probably going to be a real pain. You may say that's a stupid way to design an interface, and you'd be right; but if you aren't thinking about testing, those kinds of interfaces are all too easy to stumble into.

Within the past couple of years, I've begun doing quite a bit of test-driven development. When I need some new functionality, I try to write test code that exercises that functionality, before I start implementing it. That usually works really well, and it seems to lead to code that is considerably simpler. I have also noticed that the organization of my code tends to come out more like this. That is, the application consists of some code that instantiates some other things (typically implemented in a number of separate libraries), and wires them together. In terms of the musical example, a "Score" might create lists of "InstrumentCommands" to be executed by "Instruments", without ever itself actually touching an "Instrument". An "Instrument" might then execute "InstrumentCommands" and reply with a list of "InstrumentResults", which the application would hand over to the "Score" for processing.

In my experience, test-driven development tends to lead naturally to this "broad" (as opposed to "tall") abstraction heirarchy, because code organized in this way is a lot easier to test. You don't need to know about "Instruments" or "MIDILayer" in order to exercise a "Score" instance; all you have to do is understand "Score". This reduces the amount of stuff the programmer has to think about when writing tests, which makes test-writing a lot less complicated. But really the causation is (at least ideally) reversed: you end up with simple abstractions because you want to start by writing simple tests.

As I mentioned above, the tower of abstraction is amenable to testing, but only if the interfaces are designed with testing in mind. Likewise, the "broad" abstraction heirarchy, which already consists of easily-tested interfaces, can be safely transformed into a tower, by letting "Score" directly talk to the "Instrument" instances created by the application, etc. Once the application creates the appropriate instances of the "Score", "Instrument", and "MIDILayer" interfaces -- which could just as easily be the real deal or hollow stubs for testing, or anything in between -- those instances can call one another without caring about how they came into existence. This is essentially the "factory" pattern described in Design Patterns, which encapsulates what is possibly the most important principle of OO design: code that depends upon some interface should use the interface, but not create instances of it. That way, it's simple to use a different implementation of the interface if you need to. And test-driven development leads naturally to an architecture that embodies that pattern.

The other aspect of testability, though, is that ideally interfaces will be "narrow" in the sense that they are expressed in terms of the simplest entities that it's practical to express them with. [More later...]

Perhaps another way of looking at PG's article is not in terms of LFSP vs LFM, but rather LFIndividuals vs LFGroups.

To elucidate this, I will use the example of object-orientation in two languages, Forth and Python. Forth does not have a standard OOP framework; however, implementing object-orientation in Forth is rather simple; in fact, it's probably been done literally hundreds of times. In Python, OOP is 100% standard, and everyone agrees about the essentials.

Two weeks ago, I received my 3rd-degree black belt in American Kenpo Karate. I'm not going to say too much about that, other than it was a very intense weekend-long affair, and I'm glad it will be at least three years before I have to do it again.

However, in the process of preparing for and participating in the belt test, I realized a couple of important things. The first is that I haven't been taking my karate sufficiently seriously. I have much knowledge, not so much understanding. The second is that in spite of that, my journey so far has been completely worthwhile. Considering that I didn't begin serious study of the martial arts until I was in my thirties, I've come a long way, and gained some very useful skills. What I need to do now is to concentrate on hands-on application. To this end, I plan in the near future, along with another recent third-degree graduate, to initiate a free-fighting class at my karate school. We normally have some free-fighting time during normal classes, but black belts are usually too involved in teaching the classes to participate; and since few of our students are adults, even when we do fight during class, it is usually in a pedagogical role. I want a class that's purely for free-fighting, and which caters mainly to adult students.

I would also like to run a hands-on self-defense class. The Kenpo discipline consists of two essential bodies of knowledge: free-fighting (or kumite), which is closely related to the practice of kata (form); and self-defense, which consists of a large number of discrete techniques, each of which is a defense against a particular attack. Free-fighting is how we learn to dynamically respond to open-ended combat situations, normally with trained opponents. On the other hand, self-defense is (at least in my conception) oriented toward swift and decisive response to an unexpected attack by one or more individuals, who may or may not be trained fighters. If someone walks up to you on the street and tries to hit you, you would not normally want to engage in drawn-out combat; rather, you would simply discourage, disable, or kill that person in the most efficient way possible. If that person turned out to be a trained fighter, you may end up in a free-fight, but the goal of each self defense technique is to completely neutralize the attack without delay. In this respect, Kenpo is one of the more practical styles of martial art, which is one of the reasons I've pursued it for a number of years.

It's too simple now, though it is still way more complex than the C standard library. For example, when you want to do multiplexed I/O in C under Unix, all you really have to understand is the man page for select(), which is just pitiful. I mean, how are we supposed to maintain our reputations as Real Programmers when a single man page contains everything we need to know about multiplexing?

Sun has improved matters with the java.nio.channels package. I'm trying to do a simple select() to find out if a socket is writeable, and to understand how to do that, I had to read the Javadoc for no less than five separate classes (Channel, SelectableChannel, SocketChannel, Selector, SelectionKey). I almost feel like a Real Programmer, now. But I think they could do better if they put their minds to it.

OK, removing tongue from cheek now: why can't it be essentially as easy as C?

class Selector {

  public static List select(List check_read,
                            List check_write,
                            List check_except,
                            long timeout_usec) throws WhateverExceptionsAreNecessary {
      //...
  }

}

I should start by pointing out that I love Emacs. I've used it regularly for almost twenty years now, and it fits me like a huge fuzzy complicated glove with many extra digits that are really useful from time to time.

However, I''ve just had to re-install Windows on my laptop development machine (long story), and while setting everything up again, I decided not to even install Emacs at all. I've got Vim6.4, which ought to be enough for anyone, right?

Wow. I feel like I'm standing on the top of a high mountain, the wind ruffling my hair, and a sharp precipice at my feet. Using Vim as my primary editor will almost certainly drastically reduce my productivity, at least for a few weeks; and it may even inspire me to return to depths of computer-inspired profanity that I've spent the past several years trying to avoid (with some success, I might add). It will also inspire frequent updates to my vi-for-Emacs-users page. (Update 6-15-2006: I'm reading Peter Siebel's Practical Common Lisp, which recommends Lisp in a Box for doing experiments and exercises. So I had to install Emacs, since it's a component of Lispbox. I've become very comforable with vim over the past couple of months, though.)

This is a little premature, but here are some things I'd like to hear from a presidential candidate:

• "I am basically a libertarian. In general, I do not want to spend your money, and I will work to reduce the size of the government. I believe that people mostly should be allowed to live their lives in whatever way they see fit, provided they do not harm others. However, there are a small number of areas in which I see an important role for the federal government, which I will outline below."

is the means by which much radical Islamic terrorism is financed. So it's simple: if we get ourselves off of the "oil standard", we'll be well on our way to winning the war on terror.

I should mention that while I agree with Mr Reisman's analysis of the sources of terror funding, I dont' agree with his suggestion to reduce oil prices by drilling in US wilderness areas. I've seen the urbanization of America proceed essentially unchecked in places where I've lived, and I consider that to be tragic. It's nice to have the possibility of expanded oil exploration in North America as a backup plan, but I think we should consider it a last resort. Only if such exploration and extraction could be achieved with minimal environmental impact would I support it. Anyway, increasing the oil supply would undercut terror financing, but it would not address the underlying problem of our out-of-control petroleum consumption.