Air taxes

Lotta hubub lately about air taxes.

Buy a ticket from a major airline, part of your money goes to fund small airports. Yep, your ticket money is paying to help rich people with corporate jets….well, and hobbyists with $30K Cessnas, but nevermind them.

Presumably this is nothing new. So how come it’s suddenly an issue?

Maybe some airline PR department and/or lobbyist got worried about this.

“could radically change the airline industry by disrupting the hub-and-spoke system we all know and despise”…yep, them small airports gotta go.

They’d better shut em down fast, tho. The reason the small airports need the taxes is that they’re underutilized. Looks like that’s about to change.

NASA has been working on this for years, by the way. They know the hub system is reaching its limits. They’ve been working the air traffic control side…trying to come up with new systems that can handle a lot more planes in the sky. Companies like Eclipse are building the cheap little jets – a million bucks for a jet, way cheaper than the smallest corporate jets a couple years ago. Now Dayjet is getting the on-demand scheduling nailed.

And when they do…well, driving an hour to your nearest big airport, showing up two hours early, sitting around for six hours when your flight gets delayed, layovers, lost bags…all that mess is a lot less appealing than scheduling an air taxi and driving five miles up the road when it’s twenty minutes from flighttime. And once it really catches on, I bet it won’t cost that much more, either.

The little jets won’t take you across the continent. But for a business traveller who’s not going too far, this can’t be beat. On my last flight, a plane that was supposed to leave at 7 pm didn’t take off until 10:15. I was annoyed, but not nearly so much as a fellow passenger, who was only on this flight because his lunchtime flight had been cancelled. He’d missed a meeting because of it. He said it happened in that airport a lot, and sure enough, my return flight was cancelled too. I made out ok, but another guy got put on a 2-hour taxi ride. Last year, an airline cancelled all flights to my destination for the next twenty-four hours…I had to fly to another city and hunt for a rental car and hotel. At midnight.

The hub system is obsolete. It’s too inflexible and brittle; poke the schedules and they break. The airlines are dinosaurs, and they know it. If they don’t get congress to take out the mammals, they’re done.

Beyond Dvorak

During lunch I spent some time going through the new Erlang Book. Now my pinky is sore.

Here are some characters that you type a whole lot in Erlang: []{}|

Every one of em takes a pinky stretch, and | takes a huge stretch. I type Erlang maybe half as fast as I’m used to. And it’s not just the typing, it’s the interruption of “flow” that bothers me.

I don’t think it’s really Erlang’s fault. The syntax is elegant, just hard to type on a qwerty keyboard. A lot of languages make heavy use of these characters, along with others like ()-_<>. Maybe the best keyboard for programmers would put these on the home row.

I won’t complain too loud, because Erlang doesn’t require all that much typing. For example, suppose we need a routine to find all the permutations of a string. Think how you’d go about doing that in C# or Java. How many lines of code would it be?

In Erlang it’s two…here’s the code, from Joe’s book:
perms([]) -> [[]];
perms(L) -> [[H|T] || H <- L, T <- perms(L–[H])].

But as for the keys…homerow would be awfully disruptive…but my numeric keypad doesn’t really need navigational functions, because I have dedicated keys for that. So I could remap the numeric row to the pad, and use the pad keys for #$% etc. Then I could remap these pinky keys to the left side of the top row. I’ll leave the () where they are, and map capslock to another shift. That should make things quite a bit more comfortable, without driving me nuts whenever I have to use someone else’s keyboard or type regular text.

The laptop keyboard might take a little more thought.

The Two Things

A lot of people are linking to The Two Things, a fun little page with the premise that for any subject, there are really only two things you need to know…the rest is application.

Charles Miller proposes the two things for computer programming:

1) Every problem can be solved by breaking it up into a series of smaller problems.
2) The computer will always do exactly what you tell it to.

The first is good but the second has a couple problems. One is that it’s too obvious. Another is that while it’s a good assumption to make while debugging, it’s not necessarily true!

There could be a bug in your libraries, which means the computer is doing what the library writers told it to do, but not what you told it to do. There could be a strange loop in your compiler, so it’s doing what Ken Thompson told it to do. If you have multithreaded code on a multicore processor, the computer might try to do what you told it to do, but occasionally fail because the cores get into a fight. (Threading bugs happen with one core too, of course, but not quite so unpredictably.) And as chip features get smaller, the bits get more vulnerable to cosmic rays, so the computer ends up doing something the Universe told it to do.

So here’s my version. Neither is original, but I don’t remember the source of the second one:

1) Every problem can be solved by breaking it up into a series of smaller problems.
2) The thing that compiles your program is just another program.

Pretty much everybody applies the first one, because you can’t get by without it. Not that many people think much about the second, but if you’re not writing microcode it’s the foundation of your work anyway… and if you do apply it consciously, you can get an awful lot of mileage out of it.

Concurrency and Coordination Runtime

There are several reasons I study weird languages, but one of them is to stay ahead of the curve. I got hooked on this idea when the .Net beta came out. At the time, we were pure-Microsoft at work, writing classic asp and VB6 code. VB6 was boring so I spent time at home with Java, C++, and Python. Sometimes I wondered if I’d be better off studying VB6 in depth. Then .Net came out, I spent a couple days reading the O’Reilly book, and went “ok, no sweat, this works just like Java.” Just like that I was up to speed.

The process continues, and now that VB/C# have most of the mainstream features, the frontiers are stranger. If you want to be ahead of the C# curve, you have to look at languages like F# and Boo.

Yesterday I was pleasantly surprised to add Erlang to that list. If you’re not familiar with Erlang, it’s a language designed by Ericcson to run telephone switches. It’s good for massive scalability and reliability; Ericcson has a large application built with Erlang that has 30 milliseconds of downtime per year. There’s also an Erlang webserver called Yaws which, in a test, served up 80,000 dynamic webpages per second. Apache on the same machine crumbled at 4000.

When I started looking at it, there was one book…I ordered it via Amazon and it arrived in an international package from Sweden. They say it’s a bit out of date. But now, the Pragmatic guys are coming out with a book, written by one of Erlang’s creators. I’ve got the beta pdf and it’s quite nice.

Erlang is a great technology to know for its own sake. It gives you a whole different way to look at concurrency; shared state and locks really aren’t the best way to do it. Well now, some guys in an odd corner at Microsoft have figured that out. And the best part is, they’ve released a library that you can use in your C# 2.0 applications today.

Inverson of Simplicity

Right now I’m reading about Microkernel, an inversion-of-control thingy used by the Castle Project, which is an opensource .Net web framework along the same lines as Ruby on Rails.

Inversion of control used to make my eyes glaze over when people mentioned it. But this time, I looked at it and went “oh…that’s all it is?”

The basic idea, as described on devx, is dead simple…instead of building objects like this:

public class A{
  private B b

  public A(){
    b = new B();
  }
}

you build em like this:

public class A{
  private B b;

  public A(){
  }

  public setB(B param){
    b = param;
  }
}

This way if, say, B is a logging component and you change how you want to change how A logs things, you don’t have to change the implementation of A, or subclass it, you just pass a different kind of B into it. You can even make this change at runtime.

This is stuff that languages like Smalltalk have been doing forever. You’re always passing blocks of code into the framework objects. And they use it a lot more than Enterprisey folks dream of. When you read about Inversion of Control, they’re always talking about enterprisey things like logging and messaging and database connections. You can even get all sorts of fancy frameworks to do this stuff for you, maybe configured by some xml file somewhere. It’s very impressive and architectural.

By contrast, in Smalltalk you can’t even do a conditional or a loop without passing some custom object into a framework object. And it’s easy, because the language syntax is built around doing this sort of thing very concisely.

Another book I’m reading is Thinking Forth by Leo Brodie. Even if you’re not interested in Forth, it’s a great book on software design. And one thing Leo talks about is exactly this…making each component do one little thing, and building them to plug into each other, so it’s easy and concise to do whatever you want.

It’s like my comment on DSLs in the last entry…a lot of these Enterprisey people seem to make a big deal, and big complicated messes of code, out of things that in other programming communities are utterly simple, built into the language, and part of everyday programming. It’s not a bad thing, necessarily, to have a nifty framework that mashes your objects together according to an XML file – in fact, that might not be a bad DSL, except for the repetitive syntax – but if you’re stuck thinking in that mode you might miss how you can use this same technique, on a smaller and simpler scale, to improve all the code you write.

Just do the simplest thing that’ll possibly work, while thinking of your objects as little words and the whole system of objects as a language, with nouns and verbs and adjectives and adverbs, and I bet you end up with a beautiful, elegant, and supremely flexible design, no matter what language you use.

Hello world!

So after years of procrastination I’ve started a blog. I can either let it sit while I try to come up with a good introduction, or I can just start right in like I’ve got a thousand entries under my belt….I think I’ll do the latter, since I might be the only one to read it anyway :)

Right now I’m reading Jimmy Nilsson’s book Applying Domain-Driven Design and Patterns, with examples in C# and .Net. On page 31 he talks about software factories, and says at their heart is domain-specific languages. The trouble, he says, is that you have to be a huge organization with thousands of people to benefit from them, because the overhead is so high.

Depends on your language I guess, since if you’re programming in Lisp it’s standard practice to develop DSLs, even if you’re the only programmer on the project!

Otherwise good book so far. If, like a lot of .Net developers, you’re used to putting a lot of business logic in stored procedures, and you’re curious about the new object-oriented designs people keep talking about, then Nilsson’s your guy, since he used to work the same way you do. OOP people and database people have a way of talking past each other…Nilsson knows both worlds, and he understands the benefits of working directly in the database, which object people sometimes miss.

 As you can see, this is yet another programmer weenie blog.