Late last December, I woke up and it was freezing in my apartment. I checked the thermostat, and it was already less than 60 degrees! I turned it from hot to cold to hot. And again. I turned it all the way up. The furnace never clicked on. COME ON! I checked, and the pilot light was on, so I had no choice but to call maintenance to get it fixed.

Most days this wouldn’t have been a problem, since it would be fixed while I was at work, but I was in my end-of-year vacation-burning crunch. Maintenance always fix minor problems really fast, so I knew it would take all day to come and fix the heater. Sure enough, help didn’t arrive until 6PM.

I tried lying motionless on the floor under some blankets and played some Assassin’s Creed 2. This worked for an hour or so, but if I’m at home all day and not working on something on the computer, I start to feel like a waste. This was in the middle of trying to get a side project of mine off the ground, and I wanted to get a beta version working before returning to work in January.

Could I use my laptop as a heater? It gets pretty warm when the CPU runs at full blast on one core. If I kept both going for hours, would that be enough?

8 minutes later, I had a C++ program that ran 2 CPUs at full blast. I hate picking C++ for a personal project, but I’ve used it for 10 years and I’m just not familiar enough with any other language’s CPU usage patterns to do the work that quickly. I probably didn’t have to worry, but I was cold!

The program, warmup, runs NUM_CPU copies of this thread:

int fn(bool *go)
{
  double a = 0;
  static mt19937 rng(static_cast<unsigned> (std::time(0)));
  normal_distribution<double> norm_dist(1.0, 1.0);
  variate_generator<mt19937&, normal_distribution<double> >
  normal_sampler(rng, norm_dist);
 
  while(*go){
    double val = normal_sampler();
    a += val;
  }
  return 0;
}

I already had Boost, and I’d never used their pRNGs before, so I decided if it was a copy/paste job, I would give them a test run. Sure enough, it plugged right in.

The main function is even simpler:

int main()
{
  bool go = true;
  boost::scoped_ptr<boost::thread> threads[NUM_THREADS];
 
  for(int i=0; i<NUM_THREADS; ++i)
  threads[i].reset(new boost::thread(fn, &go));
 
  std::string asdf;
  cout<<"enter any input and hit <Enter> to kill"<<endl;
  cin>>asdf;
 
  go = false;
 
  for(int i=0; i<NUM_THREADS; ++i)
    threads[i]->join();
 
  return 0;
}

Within 12 minutes of starting, I was nice and toasty!

I posted the code on Github in case I needed it somewhere else: [code]


In “Are We There Yet? A Deconstruction of Object Oriented Time,”[slides] [interview] Clojure creator Rich Hickey looks beyond concurrency support in popular programming languages to see what’s on the horizon. He asserts that wrapping our objects in locks – the popular solution – is an attempt to treat concurrent objects as if they were accessed by a single thread. Hickey describes the problems with this approach in two slides:

We don’t make decisions about things in the world by taking turns rubbing our brains on them.

Nor do we get to stop the world when we want to look around.

Instead of this awkward locking model, he suggests a versioned approach to representing object instances. He also presents some programming constructs to be used in his versioned model.

Below, I present his idea of a pure function to update the view of objects to a new state. I also introduce a problem that this doesn’t handle, the expiration problem, that language designers should either address or state they don’t handle.

Background

In Java and C++ (and many other languages), it’s very easy to write concurrent code that causes inconsistent results across multiple reads. So easy, in fact, that it’s the default for everything! You’d have to do external locking or go to heroic lengths to avoid doing it. It happens regardless of the thread safety of the underlying class!

Let’s look at an example: Assume that some Evil Crime Syndicate is trying to kill me. Even worse, they have cracked all government mainframes and always possess my contact information. Like all Evil Crime Syndicates, they have a gigantic code base written in Java that runs the whole operation. To save themselves some personnel costs, they wrote an automated assassin dispatching system.

Let’s look at a scenario where the assassin acts on an inconsistent kill order:

Assassin code

  class Assassin
  {
    void killPerson(Person person)
    {
      String personAddress = person.getAddress();
 
      // --- INTERMEDIATE ACTION BY ANOTHER THREAD ---
      // I enter the Witness Protection Program, and my
      // name and address are changed.
 
      String personName = person.getName();
 
      // Some private method
      actOnKillOrder(personName, personAddress);
    }
  }

Application code

Person nextTarget = TargetFactory.makeTarget("Jake");
 
// Not shown: logging, passing the target info to a central
// database, etc
 
currentAssassin.killPerson(nextTarget);

If I officially enter the Witness Protection Program while killPerson() performs sequential reads, the assassin will look for a new name at an old address. In the best case, he’ll get some puzzled looks when he asks around for a new identity at the old location.

We’ll call the worst case deadlock

A second chance for the Evil Crime Syndicate

Could language features help the Evil Crime Syndicate kill me? Hickey proposes that instead of looking at objects as a single mutable data point, we treat objects as a succession of states. Each view perceives an immutable state at some point in time, and references it until it is updated. If the view needs to know the current state of the object, then it can call a function that returns the object’s newest state. If the object is constantly being updated by other views, you won’t see any of these changes until you call this function and get the new version of the object.

This is a version control system for objects. You query the object once and do stuff with the data that you get back. When you want to pull the current updates for the new object, just call the system’s update command and get a new version! The system handles all of the reads and writes behind the scene, just like a real database. Interesting aside, databases and version control systems concurrent systems that Joe Coder already uses on a massive scale with minimal concurrency problems.

To imagine this feature in Java, let’s call our pure function Update(). It takes the current view of a Java object and returns the newest value of the object. Yes, I know that adding a function to Java completely breaks the consistency of Java’s all-object model, but you’ll notice that I have no control over the language features added to Java. This continues to be a good decision made by Sun Microsystems.

It turns out that Update() makes it easy to show that the assassin always acts on consistent data!

Assassin code

  class Assassin
  {
    void killPerson(Person person)
    {
      String personAddress = person.GetAddress();
 
      // If my data is updated here, this view's
      // view of 'person' doesn't change. All reads
      // are consistent!
 
      String personName = person.GetName();
      actOnKillOrder(personName, personAddress);
    }
  }

Application code

Person nextTarget = TargetFactory.makeTarget("That Jake guy");
 
// Not shown: passing the target to a central database, etc
 
person = Update(person);
currentAssassin.killPerson(nextTarget);

In this code snippet, the fact that Update() is called before dispatching the assassin ensures that the assassin is acting on a consistent and relatively recent view of me. I mean, I could enter Witness Protection as the assassin travels, or immediately after Update() is called. However, that’s a logistics problem for the assassin, and he won’t get any sympathy from me!

The Expiration Problem

Now the wrinkle! What if we query real-world objects for their state? Let’s say that you have an atomic clock hooked up to your computer via a serial port.

     AtomicTime time = atomicClock.queryTime();

Let’s assume that the delta between the AtomicClock time and the system time is known and constant, which is not usually a reasonable assumption. For the sake of discussion, let’s also assume that Update() can update an AtomicTime to the most recent value pulled from the AtomicClock. How does Update() interact with this real-time object?

Most of the time, it works very well. We can use Update() to ensure that our view of the time is consistent if we read hours, microseconds, and nanoseconds sequentially.

As we use it more, we run into a problem! Let’s assume that we want to display the atomic time to the user. We could just constantly Update() the time returned from the atomic clock, but I’m not a big fan of polling. Why? If we hit unexpected latency or blocking and we poll slower than we expect, we’re going to display times to the user that are no longer accurate. The data changed and nobody told us.

I call this the expiration problem. Sometimes it’s easy to fix — dude, just poll the clock faster. Duh. — and other times it’s not so easy. Just look at the assassin example. Even when we could show the function always worked consistently, the assassin could still be dispatched to an old address looking for an old name. This is obviously bad: the data rotted and the programming language stayed silent. The system knows everything it needs to say, “Hey, by the way, this data isn’t good anymore,” but it doesn’t.

The front office of the Evil Crime Syndicate naturally doesn’t understand the distinction and will totally give my would-be assassin a hard time. “What do you mean you killed the wrong person? Our system always gives a consistent and up-to-date target. Obviously this is your fault. You’re getting a pay cut after you finish this assignment.”

Of course, there are also problems introduced when values are allowed to expire. The data doesn’t always need to expire! An assassin could gather clues from old aliases and residences, for instance. You could want to store a list of AtomicTimes for processing elsewhere.

Any language that uses expiration as an explicit action needs to also allow the programmer to differentiate between the following:

• Hard expiration: Occurs when using a dated value could be expensive or harmful. An exception is thrown if you attempt to use the object after expiration.
• Soft expiration: The programmer wants to know if the value goes bad, but the value is still usable in some views. This could be implemented through either callback handlers or exceptions.
• No expiration:  The default for most data.

Ideally, this would be settable per each view of the data.

Conclusion

Concurrent programming has a lot of inherent wrinkles, and trying to remove all of them out is a very deep rabbit hole. Each solution usually points to another problem. Sometimes they don’t really matter, like showing an atomic clock time for an extra few nanoseconds. Sometimes they could cause expensive mistakes, like sending an assassin to the wrong place for the wrong target.

Rich Hickey’s pure function that returns the future as a function of the present is a great idea, and I’d love to see Hickey implement something like it in Clojure. It may also be possible to implement expiration! I recall that Clojure allows validators to be attached to objects to check for consistency across updates. I don’t see why expiration couldn’t be handled similarly to check for staleness on reads.

I would love to see some other language-level ideas and implementations for aborting a current action if the data fails a staleness check. “Data is guaranteed consistent and up-to-date!” would be a pretty good selling point for a language, even if the utility of having both at the same time is often low.

The expiration problem exists in every language, but if we’re actively trying to ease the pain of concurrent programming, it’s something that needs to be explicitly formalized and addressed. In fact, I’d bet a dollar that there are already 5 different formalizations for this phenomena. Does anyone know if this has been discussed in a more professional or academic publication?

Special thanks to Sarah Braun and Greg Molyneux for reading drafts

• Its data was stored in the same structures as its program.
• It had macros that were powerful and simple. That’s huge coming from C++.
• It was REPL-based, something I never took advantage of with Python.
• You could create new code on-the-fly at runtime from lists.
• Completely dynamic and backed by garbage collection.
• The language itself is very mutable.

The sum of its parts was greater than anything that I had ever used before, and it quickly became my favorite language. I learned quite a bit about functional programming techniques, did some experimentation with image processing and database application programming, and worked through all of Graham’s  ANSI Common Lisp and large swaths of Norvig’s Paradigms of Artificial Intelligence Programming.

Recently, a nagging though started to cross my mind: What if I didn’t go far enough to break out of my box?

That didn’t happen until two weeks ago, when I started porting Genesis, my toy genetic algorithm framework, to Clojure for fun. I wasn’t very aware of the features of Clojure: I knew that it was a Lisp on the JVM and that it supported Software Transactional Memory, but I didn’t think it would be that different from Common Lisp aside from Java interoperability.

To clarify, I expected that the primary method of manipulating Clojure would be list-based, and that it would still mostly turn a blind eye towards mutable data and multithreading issues, with the option of phrasing memory updates in terms of transactions if you were using multithreaded applications.

Clojure turned out to be different than any language that I had ever tried – save my forays into Haskell to grok enough syntax to follow sigfpe’s easier articles.  If you trust the language and work with the core Clojure data structures, it takes a lot of the worrying about parallel programming out of your hands. Its creator, Rich Hickey, ended up with a language that has a good balance between functional programming and practicality. It is definitely a good Modern Programming Language.

You Said Something About A Box..?

Right, I said I didn’t go far enough outside of my comfort zone when learning Common Lisp. That’s really only half true.

From the perspective of programming, Common Lisp is a great language. Using the functional programming primitives provided on top of lists feels very natural, and I was able to work on complicated problems with relative ease. Even though I don’t use the macro system in Common Lisp very often, it usually provides a great fallback for either refactoring or changing the way the problem can be represented. The REPL is just icing on the cake.

However, not all is flowers and roses. Looking at Common Lisp from perspectives other than single-threaded programming, it begins to look mortal! For instance, the Common Lisp standard was written without a thought to having multiple threads of execution. Although most implementations provide extra support for multithreading, you’re back in the same locking boat that you were with any of the other popular languages once you need to share mutable data. Naturally, the syntax for things like grabbing mutexes is easier with Lisp than with other languages thanks to the “with-” design pattern for macro writing, but you’re not gaining much with respect to avoiding race conditions.

Looking at it from a data-processing perspective, functional programming is easy in Common Lisp, but it isn’t required at all. There’s nothing stopping the programmer from falling back into using local mutable state, functions with side-effects on global variables, and destructive functions. Combined with the single-thread design, that’s fine. You can’t avoid state all of the time, and I don’t go out of my way to be strictly functional. That’s how most other languages are designed. Hell, the Common Lisp standard even offers a whole slew of functions that are destructive for the sake of efficiency!

I’m only really getting at the fact that even the ultra-flexible of Common Lisp wasn’t written to handle all computing scenarios.

Some languages have support for neat automatic threading features: Haskell has extensions where type annotations can allow automatic parallelization, and you can use OpenMP in C++ for automatic parallel processing. For those wondering, Erlang is somewhere on my list of languages to take a look at, but it has to wait its turn! I’m still having too much fun with Lisps.

Axiomization and Language Design

Love him or hate him, Paul Graham has written quite a bit about the design of Arc. I’m not going to talk about it directly, but I will borrow his idea of reaxiomizing the core of a language as a means of producing better code on top of it. He mentions axioms as neither primitives nor library functions, but I will consider primitives as well.

I’ve talked about this a little in the past. For instance, I’ve made the case for operator overloading in Java. It was explicitly verboten in Java, as decreed by the designers. In fact, written in an early Java whitepaper titled “The Java Language Environment“,

2.2.7 No More Operator Overloading

There are no means provided by which programmers can overload the standard arithmetic operators. Once again, the effects of operator overloading can be just as easily achieved by declaring a class, appropriate instance variables, and appropriate methods to manipulate those variables. Eliminating operator overloading leads to great simplification of code.

By the letter of their assertions, they were correct. A lot of programmers would never need operator overloading to produce good code. In fact, if you’re using it just for the sake of expressiveness, you’re going to produce an unintuitive hodgepodge most of the time. However, a small but powerful minority – particularly those who do mathematical work for a living – would absolutely benefit from being able to write inline operators. I mean honestly, have you ever tried to use a BigInteger to implement something more complicated than RSA? The best that will happen is that it will end up… verbose.

Essentially, leaving out operator overloading forced Java to be more verbose and/or less readable than it needed to be. Leaving it in as an ‘axiom’ could measurably produce more compact, readable code for programmers who used it judiciously.

As an aside for those who think I’m just trolling Java, there is definitely a great Java feature for each one that misses the mark. For instance, the enums in Java follow the idea to its logical conclusion.

If you’ve been incensed by my Java discussion or are otherwise unsure that axiomization could lead to a better language, let’s look back at Lisp. Lisp changes quite a bit if you remove utility functions like reduce: it would break a lot of the compactness of the language and ruin some otherwise good functional programming. Now, it doesn’t support operator overloading, per se, but there’s nothing stopping you from changing the language to support it.

Where the Hell is All of This Going?

Back to Clojure! Clojure is based on a much different set of axioms than many of the popular languages. At its core, we see support for thread-safe data structures whose data are immutable and persistent. These were written in as axioms to the language, and you can make some good predictions for the language, assuming people stick with it.

The biggest one is that as libraries are converted to Clojure or abstract away their Java API, Clojure will develop a large set of libraries that could be given a thread-safe guarantee.  For my day job, I work in a C++ shop that uses a bunch of C libraries, and we need to constantly be aware of whether or not our base libraries are thread-safe. My workplace recently developed a non-Clapack fork of our linear algebra abstraction for this reason: using libraries that aren’t designed to be threadsafe in a multithreaded environment builds bombs.

I’m too young to get a sense of what the next 10 years of programming languages might look like – but if you pressed me, it would look a lot like it does today, and we wouldn’t be better off for it. The languages that are currently in the design phase are slowly adding quite a bit of features while remaining mostly the same: for instance, C++ is getting a makeover that includes concepts, lambdas, futures, and a multithreading primitive.  I’ve known C++ for over half of my life (holy shit!), and a lot of the features are sorely needed. However, it’ll be an incremental improvement at the cost of obscure compiler bugs and increased complexity.

These aren’t easy problems: for instance, if you didn’t care a lick about any external concerns like backwards compatibility and wanted to change C++ to support lambdas, how could you without just tacking it on? However, we have new languages that can pick up where the old languages left off, and continuing Fred Brooks’ prediction, there will be no silver bullet, only incremental improvements. Languages like Clojure are a step in the right direction as far as testing new computing ideas.

So What’s It About?

“Underground” by Suelette Dreyfus is a great historical fiction narrative detailing the rise and fall of some crackers and phreakers and their opponents: phone company employees, system administrators, and Feds. It takes place between 1988 and 1994, when multi-user BBSes were starting to pop up and a telephone call was the ONLY way to access other computers. It’s about 99 times better than this review. In fact, I request that you stop reading this immediately and just read it yourself. It’s really that good.

That being said, most of the stories are told from the perspective of the attackers, except for a few spurious tales of BBS operators and virus attacks. All of the attacker stories have similar plot themes:

• Personal Background: Who were their friends? How was their family life?
• The first taste: How did they get into the scene? Who were their friends and mentors? How did they get free international calling? Were they chasing a white whale, or were they just enjoying themselves?
• The glory days: Usually describes a list of big fish that the attacker accessed, as well as the social support the attacker got in his home community. At this point, the Feds notice the attacker and start playing cat-and-mouse with him.
• The Law Won: The Feds make an identification, and either the attacker goes on the lam or gets busted at his computer. Nobody who got away would be at liberty to contribute to the book, so logically the attackers mentioned in the book are all caught. The court cases are described, as well as public reaction.
• Where they are today: How the legal system treated them, what they did after their legal troubles were over, and are they currently employed?

Literary Freeware

The author, Suelette Dreyfus released the book as “Literary Freeware,” allowing anyone with an internet connection to download the book for free. The text of the book was released to Project Gutenberg, and the author herself wrote a special forward for the free version of the book, describing the reasons a book’s author might decide NOT to get paid for the book:

From the forward:

Because part of the joy of creating a piece of art is in knowing that many people can – and are – enjoying it. Particularly people who can’t otherwise afford to pay $11 USD for a book. People such as cash strapped hackers. This book is about them, their lives and obsessions. It rubs clear a small circle in the frosted glass so the reader can peer into that hazy world. ‘Underground’ belongs on the Net, in their ephemeral landscape.

[...]

By releasing this book for free on the Net, I’m hoping more people will not only enjoy the story of how the international computer underground rose to power, but also make the journey into the minds of hackers involved. When I first began sketching out the book’s structure, I decided to go with depth. I wanted the reader to think, `NOW I understand, because I too was there.’ I hope those words will enter your thoughts as you read this electronic book.

The book’s website also hosted dozens of different formats/languages of the book. However, don’t try to go there anymore! It’s been taken over by some crappy hacker book e-commerce website. A reader named Rory Gordon searched the internet much more thoroughly than I did and discovered that http://www.underground-book.net is apparently the website’s actual address. Also the Wayback Machine has you covered! It even archived the 26 language/file format combinations the author made available.

How Was It?

It is good. How good? I dislike reading e-books. I like to read on my bed and sometimes write on my copy of the book. By the time I drag my desktop computer over to my bed and plug it in, I’m no longer in the mood for reading, and when I draw on the monitor, I can’t use it for other things. I actually ordered a hard copy of A New Kind of Science — review coming, whenever I summon the courage to read the last two chapters — so that I didn’t have to print out 1000 pages or read it on my computer monitor.

Despite all of this, I read the whole PDF (~300 pages) within 48 hours when I first got my hands on it — summer of 2007, for those keeping track. I stayed up late, I snuck peeks in my school IT job, and I couldn’t put it down to save my life.

At times, the pace is a lot like The Da Vinci Code, but with much longer chapters. If you don’t like that, the pacing is a lot like Harry Potter. If you don’t like that, the pacing is similar to the action sequences of Snow Crash. If you don’t like any of them, then I feel you need a good hug and some cake.

Highlights

First and foremost, it is well-written from a technical standpoint. There aren’t any “Law and Order” moments where images are super enhanced and Visual Basic GUIs are prototyped to track IP addresses. The author accessibly writes like she knows Unix systems, which is refreshing, given the number of errors I find in technical articles written by non-techies.

As for content, the story of Par is by far the best out of all of them. On a tip, he found a computer that was almost literally a gold mine: dialing it at certain times of the day caused it to spit out a large list of valid credit card numbers owned by rich Saudis. He ends up handing them out and using them like they’re free candy, which ends up drawing the eye of the Secret Service. He ends up having to go on the lam, surviving on the kindness of fellow hackers — and his 23-year-old Swiss girlfriend, Theorem. What follows is a great description of the techniques the Secret Service used to track him down (involving agencies working together on a few different continents), as well as his dumb luck in evading capture for so long.

Also, the book is chalk-full of moments like this:

If, however, the line did not have a trace on it, the company’s modem would search for its lost connection to the hacker’s modem. Without the continuous flow of electronic signals, the NorTel modem would hang up after a few seconds. If no-one reactivated the line at the NorTel end, the connection would time-out 90 seconds later and the telephone exchange would disconnect the call completely.

Mendax listened anxiously as the NorTel modem searched for his modem by squealing high-pitched noises into the telephone line. No modem here. Go on, hang up.

Suddenly, silence.

OK, thought Mendax. Just 90 seconds to go. Just wait here for a minute and a half. Just hope the exchange times out. Just pray there’s no trace.

Then someone picked up the telephone at the NorTel end. Mendax started. He heard several voices, male and female, in the background. Jesus. What were these NorTel people on about? Mendax was so quiet he almost stopped breathing. There was silence at the receivers on both ends of that telephone line. It was a tense waiting game. Mendax heard his heart racing.

A good hacker has nerves of steel. He could stare down the toughest, stony-faced poker player. Most importantly, he never panics. He never just hangs up in a flurry of fear.

Then someone in the NorTel office–a woman–said out loud in a confused voice, ‘There’s nothing there. There’s nothing there at all.’

She hung up.

Mendax waited. He still would not hang up until he was sure there was no trace. Ninety seconds passed before the phone timed out. The fast beeping of a timed-out telephone connection never sounded so good. Mendax sat frozen at his desk as his mind replayed the events of the past half hour again and again. No more NorTel. Way too dangerous.

In Conclusion

Read the book! This whole paragraph is a big link to the PDF. Just read it! It’s good!

In my mental model of knowledge, I split skills between three major mastery levels:

• Those we can use professionally. I program professionally, and I practice daily to strive for mastery. I’m getting to the point where I can handle any task that is thrown at me.
• Those we can use. I can cook without killing myself of burning down my apartment complex, even though I can’t make many types of food and wouldn’t recognize a Mother Sauce if it was poured down my shirt.
• Those we couldn’t really use if our life depended on it. I’m not good at drawing. I’ve never spent time on it, and I have no motivation to learn. I can “draw” diagrams and get my point across, and this is enough for me.

All people treat the skills from the first category differently than the other two: we use them with confidence. Some people use them with arrogance. We know these fields well enough to absorb innovations and new ways of thinking. We can confidently discuss them with other people.

In my mental model, starting from scratch in our expert area causes people to reject a change. For instance: an Excel or Word guru would never willingly switch to a completely unrelated product. Relearning things line inserting line-breaks and adding pictures to a text document is completely orthogonal to anything they actually have to do on the job, much less something more complicated like Mail Merge. Instead of using it like it should be used, they would likely try using it like they used their old product, declare that it can’t ramrod the flimjam, and switch back to their old way of doing things, regardless of which is really better.

Interfaces and APIs

Altered interfaces are difficult for the end user. This isn’t just about GUIs or the placement of buttons in a menu; this extends to software APIs as well.

An altered menu causes all users to waste time looking for new ways to do something they could do 5 minutes ago. Changes to an API cause the programmers relearn a library they already knew — not to mention the laundry list of changes that need to happen to the new stuff!

APIs and Interfaces

The interface for a library or class develops massive unavoidable dependencies with use. I’ve called this “code inertia” in the past. Joel and Jeff’s recent discussion of dependencies between unit tests and code is a perfect example of code inertia: making nontrivial changes to an application can force a nontrivial number of changes to your automated testing environment.

This has not only a physical effect on the code, but also a mental effect for programmers! I’ve actually heard arguments from programmers based on the IDEA of possible future change: we shouldn’t use this library because it’s changed significantly in the past, and it might change again! Having to relearn the API combined with the frustration of updating broken code leaves a giant red flag in a programmer’s mind, even though any codebase that is being properly maintained will go through interface changes as new versions are released.

Excel

I was fortunate enough to take a Numerical Methods and Analysis class during my senior year of college.

If you’re not familiar, it’s the mathematics of computation: finding efficient approximations, determining rate of convergence, and knowing the margin of error at each stage.

This was my only college class where a calculator was ever useful. Most of our homework involved finding the values and error in iterative processes, so the professor suggested a “complex math package” for our homework: Excel.

Despite my initial skepticism, Excel is AWESOME with iterative numerical computation: type in a relative formula, highlight 50 rows, and click “fill down.” Voila! You can put a bunch of results in adjacent columns and compare convergence rates visually before you even prove that it converges at a certain rate. It’s quick, it’s interactive, and it supports easy experimentation.

Why is this relevant? My college upgraded to the Microsoft Office 2007 suite the previous summer, toolstrip and all. Every single class was punctuated by my professor loudly complaining that she HATED the new Excel because the interface was WORSE and she couldn’t find anything.

Even though she knew where everything was after 2 weeks of use, we got the same complaint every week. She had already made up her mind: it was worse.

KDE and Linus

A few years ago, Linus Torvalds publicly announced his Linux desktop preference on the GNOME message boards:

I personally just encourage people to switch to KDE.

This “users are idiots, and are confused by functionality” mentality of Gnome is a disease. If you think your users are idiots, only idiots will use it. I don’t use Gnome, because in striving to be simple, it has long since reached the point where it simply doesn’t do what I need it to do.

Please, just tell people to use KDE.

Linus

The different camps typed their representative emoticons — and D: — and then life continued as normal. However, Linus was eventually forced to switch when the next version of KDE changed too much:

Interviewer: Another open source project that underwent a big change was KDE with version 4.0. They released a lot of fundamental architectural changes with 4.0 and it received some negative reviews. As a KDE user how has this impacted you?

Linus: I used to be a KDE user. I thought KDE 4.0 was such a disaster I switched to GNOME. I hate the fact that my right button doesn’t do what I want it to do. But the whole “break everything” model is painful for users and they can choose to use something else.

I realise the reason for the 4.0 release, but I think they did it badly. They did so may[sic] changes it was a half-baked release. It may turn out to be the right decision in the end and I will re-try KDE, but I suspect I’m not the only person they lost.

I got the update through Fedora and there was a mismatch from KDE 3 to KDE 4.0. The desktop was not as functional and it was just a bad experience for me. I’ll revisit it when I reinstall the next machine which tends to be every six to eight months.

The GNOME people are talking about doing major surgery so it could also go the other way.

Linus realizes that it might be the right decision in the long run, but there’s no escaping the fact that even the big guns in the field can’t spend his time relearning the basics every day, even if it’s the right thing to do. He has a mental model of how the desktop is supposed to work, and when KDE broke it, he fixed the problem.

Adult Learning and Malcolm Knowles

To me, a lot of the principles of API and interface design fall under adult learning. To state the obvious, most of the indended clients for interfaces are adults. We’d like them to learn how to use our products with the minimal amount of fuss.

However, if your interface is exactly like every other interface, there would be no reason to use it. You’re trying to solve a problem for yourself, and you’re trying to solve a problem for your intended users. Your users will have to learn how to solve their problems with your interface, and it had better be easy.

Enter the research of Malcolm Knowles. He is one of the big-shots in the field of adult learning, having done a lot of the early theoretical work. This site has a good description of his life’s work with researching, for the interested.

In particular, Knowles attempted to find the theory of what caused adults to best learn. Believe it or not, there hadn’t been extensive research in the field before he started. The closest that he was able to come was his theory of informal learning, through group sessions or other kinds of informal meetings. He also developed his assumptions by which adults learn:

Malcolm Knowle’s Assumptions on Adult Learning

1. Self-concept: As a person matures his self concept moves from one of being a dependent personality toward one of being a self-directed human being.
2. Experience: As a person matures he accumulates a growing reservoir of experience that becomes an increasing resource for learning.
3. Readiness to learn. As a person matures his readiness to learn becomes oriented increasingly to the developmental tasks of his social roles.
4. Orientation to learning. As a person matures his time perspective changes from one of postponed application of knowledge to immediacy of application, and accordingly his orientation toward learning shifts from one of subject-centeredness to one of problem centredness.
5. Motivation to learn: As a person matures the motivation to learn is internal.

The salient bullet point is #2: experience. It’s directly listed as a basis for adult learning. I’m not saying that this is a direct proof of my mental model of knowledge, because quite honestly it’s just not a proper conclusion. However, designers of APIs and GUIs should take this as an indication that experience is something to build on, not disregard.

To use an aforementioned example, I really like the ribbon interface in Office 2007! I was proficient after only a few hours, and I enjoyed using fewer keystrokes to achieve my goals. I thought that it mapped pretty well to the old menu-based methods, and it was pretty obvious when it didn’t. If I could use only keyboard shortcuts to navigate, it would be the ideal control.

However, it’s probably a bad idea releasing it in the same year as Vista, which already scrambled some menus, changed some positions, altered some interfaces, renamed some popular folders, added UAC, etc. It all added up to too much of a change: when people sat down at it for the first time, nobody couldn’t use the darned thing.

Live and learn!

Footnote

I remember a minor fuss when Linux 2.6.0 came out because the device driver interface changed. Linus himself descended from the cloud to state that he makes the right design choices for Linux without regard to compatibility issues. It was going to tie in really nicely with my point, and my Google Fu has failed me. up. The device driver interface changed from 2.4 to 2.6, and that there was a of device driver complaints. At this point, I just want to know if I was making this up.

Overview of BattleCode

The competition’s focus tends to vary from year to year. Last year’s competition could be won either by capturing most of the towers on the map or by completely wiping out the players on the other team.

It’s even better this year: it’s primarily a resource-managing competition. Certain tiles on the game board contains a resource (flux) that you can gather. If you have more when the round ends — or cross a magic threshold during the match — then your team will be declared the winner.

It’s probably still possible to create a winning team that is entirely militaristic, but I have a feeling that the organizers are trying to reward teams that split-up. Most of the teams that split up into groups last year were defeated by monolithic swarms, but this mechanism of resource mining and control might better side with teams that split.

The good news is that it seems like there is a core group of functionality that remains the same from year to year, so code that is written for a previous BattleCode tournament is still usable the next year. I just found out about it, so I’m in the process of developing a player from scratch.

Great Design Decisions

A great BattleCode design decision involves the maximum number of units: it’s self-regulating. There is no ‘official’ limit to the number of units that can run at any one time, but all units must return to one of 6 central energon-producing units (Archons) from time-to-time or they die. The Archons produce Energon at a constant rate, preventing too many units from existing at once.

The genius of the design of the soft-cap is that it allows two extra strategies into the game: first, you can send some of your units on a suicide run guilt-free! If a unit decides that it’s FUBAR, it can send a message home saying “Just trying to kill some bugs, sir!” and its parent can feel free to spawn a new unit at its earliest convenience.

As a result, the Archons are as valuable as a King in chess: it’s not very powerful, but you can’t afford to lose it.

Java-Based Programming

The competition software uses the Java VM to control the matches. The user overrides a Runnable class named RobotPlayer. The run() function lets the user define the behavior of the AI agent. They provide a default function that solely moves the AI, but it probably won’t get you very far in the main competition.

The run() function is written as a loop, and robots don’t have a clear idea of a separation of turns: they are limited to 3000 Java bytecodes per “turn,” and the controller switches to the next robot automatically. A “yield()” function is provided that artificially ends a turn.

Very Algorithm-Friendly

There is no centralized user-written player to pass strategy and tactics to individual units: they have to decide that amongst themselves. You need to tell them how to move, how to fight, and they need to be able to manage their own health.

The two major categories of algorithms that need to be developed are dynamic path-finding algorithms (because a robot needs to know where it’s going!) and distributed organization. You need to be able to use your units to protect your Archons, they need to be effective fighters, and it would be a poor unit that gets stuck on the first non-passable square it encounters.

I have no doubt that some teams are eventually able to publish papers on some of the organization techniques that they use: quite a bit of work can be accomplished in 3000 bytecodes, and I bet that some of the organization and attack techniques are more sophisticated than many papers that have been actually published.

My Plans

My goal is to have a force that can fully spawn, move, and fight by the end of January, and my final strategy and tactics to be decided by the end of February. I will most likely merge with a team that has a few of my friends by the end of the month, but you’ll be able to find me by my username (jakevoytko).

Quick-Links for the TL;DR Crowd

About Lisp: Describes Lisp as an overview.
High Level Overview: Describes in general what is needed to program with Lisp.
All you need

• SBCL
• Emacs
• SLIME
• asdf-install

Code examples: A few rudimentary Lisp snippets.
Other Lisp Features: Features that I did not feel like explaining
Resources

About Lisp

Note: For a complete introduction, I recommend this e-book. If you only want to learn enough to get started, read on!

Interactive

Most languages take an input file and produce an executable or run a script. Lisp is interactive: all input is entered into the REPL, and the computation’s result is printed to the screen.

REPL: Read Evaluate Print Loop. A C++ coder can think of it like this:

void lisp()
{
    while(true){
        cout<<">"; // prompt
        cout<<evaluate(read())<<endl;
    }
}

If you’ve ever used Python’s command line prompt, you’ve used a REPL. A bash prompt is a REPL. So is Lisp.

Prefix

Most expressions in C-style languages are prefix, but exceptions are made for arithmetic, such as 1/(x+3). All expressions in Lisp are prefix expressions: the first argument of an S-expression (Sexp) is a function name, and the rest of the atoms of the S-expression are the arguments for the function. The following are examples of Lisp function calls:

(/ 1 (+ x 3))         ; 1/(x+3)
(format t "~A~%" x)    ; prints the value of 'x' and a newline.

All Expressions Return Values

All expressions in Lisp return values. For instance, the ‘if‘ statement in Lisp not only chooses which execution branch to follow, but returns the result of the executed expression. ‘nil‘ is the default return value of an expression, which also evaluates to false (‘t‘ is true).

In C-style languages, expressions don’t necessarily return values. The expression ‘1+3‘ will return ‘4‘, but ‘cout<<1+3‘ doesn’t return anything (They return a reference to an ostream, so this is a mistake) void functions don’t return anything; they can’t be used as a sub-expression for a larger statement of code.

Functions in Common Lisp can return multiple values. The ‘multiple-value-bind‘ macro is used to bind multiple return values to multiple variables.

High Level Overview: What You Need To Get Started

1) An implementation. All you need is an implementation that conforms to the standards. All of them have an edge case or two, but odds are it won’t affect you. If you absolutely need to switch later (for CLisp’s fast arbitrary precision arithmetic, for instance), nothing is stopping you; most libraries support all popular implementations.

2) An editor. I personally recommend Emacs with the SLIME extension. You can also use Vim and Limp if you either prefer Vim or you can’t stand Emacs. I left Vim before I started using Emacs, so I’ve never used Limp. Caveat emptor!

You don’t absolutely need to use an editor that interacts with Lisp. It’s POSSIBLE to run a Lisp program like a script, but it usually makes as much sense as opening a bag of chips with a hammer. You will want to use the REPL for most of your Lisp tasks, and this will only be bearable from within a good editor.

3) A Lisp tutorial or reference. I highly recommend “ANSI Common Lisp” by Paul Graham [see my review].

4) An installation system, like asdf-install. Installation systems automatically load Lisp projects into your current image, and are essential for working with a large project. asdf-install allows you to download libraries from cliki.net and load them into your Lisp image from within the interactive Lisp command prompt!

Details: What You Need To Get Started

SBCL

About

Steel Bank Common Lisp (SBCL) was forked from Carnagie-Mellon University Common Lisp (CMUCL) in 1999. It is named after Carnagie and Mellon’s respective industries, steel and banking.

Most Lisps can be interpreted or compiled, depending on the context. However, SBCL compiles all Lisp code it receives. Having used SBCL for 6 months or so, there’s not much of a pause even for large Lisp files. On the other hand, the compiler is very verbose, but this can be tweaked.

Why SBCL: Popular

Naturally, I can’t find good numbers on the popularity of SBCL. However, it is noteworthy that asdf-install and LIMP were initially designed to work with SBCL. This seems to be par for the course for all of the libraries I’ve used.

Why SBCL: Active Development

Development of SBCL is still roaring along, with 1,228 commits to their Sourceforge page at the time of writing, including several in the past few weeks. New releases come at the beginning of every month, and this month was no exception: version 1.0.23 was produced December 1, 2008.

Installing SBCL

Installing SBCL: Linux

SBCL can be installed like any other package:

sudo aptitude install sbcl
# Or your local variant.

Once that’s finished, it’s easy to test the installation:

jake@justalaptop:~/code/genesis$ sbcl
(+ 2 2)
*
4

Installing SBCL: Windows

There is an “experimental” Windows installation binary: [link].

I’ve ran it for brief periods and it seems to work fine, so I’m not sure what’s so experimental about it. Again, Caveat emptor!

After installation, run SBCL. You will get a command-line prompt, and type the following:

> (+ 2 2)
*
4

It works!

Emacs

You can use whatever editor that you want to write Lisp. Emacs has good advantages:

ELisp: Emacs is scripted in its own subset of Common Lisp. Called ‘elisp’, anybody who has been working with Lisp for a few months and can type “ELisp manual” into Google can customize Emacs to their taste.

Irony alert: I typed “elisp manula” into Google on my first try.

Automatic indentation: Yeah, I know, every editor in the history of the world does automatic indentation. However, Emacs’ authors primarily write Lisp code, so they paid close attention to how Emacs interacts with Lisp. I rarely see Emacs do the Wrong Thing. When it does, I’m usually writing awful code.

SLIME: The Superior Lisp Interaction Mode for Emacs. In order to effectively code in Lisp, you need an editor mode that will interact with a Lisp implementation. Typing the code directly into a command line is nice for small experiments, but is painful for anything more than 30 lines of code (for me at least.. your pain tolerance may vary).

SLIME

SLIME combines the editing power of Emacs with the interactive nature of Lisp.

If you’ve ever used Python’s command-line prompt, you’re aware that it’s painful to use for any amount of time. The editing capability is limited to that of your console, and when you exit Python, all of your code disappears!

SBCL (and all other Lisp implementations) is no different. If this were the only option for working with Lisp, nobody would. You must work with the REPL from within a real editor. You COULD write code in an external file and load it into SBCL from the command line, but that removes the interactive nature of Lisp.

Enter SLIME (Superir Lisp Interactive Mode for Emacs). SLIME spawns a new Lisp process and acts as the liaison between you and the process.

To start the whole process, just type “M-x slime“, and a new REPL buffer opens. Any Lisp command can be entered into this buffer, and you get all of the editing commands from Emacs. slime-mode begins in all of your open Lisp buffers, which gives you code completion and function argument hints for all compiled functions.

If slime-mode is enabled in a Lisp buffer, you can compile the file with “C-c C-k“, or compile a single function with “C-c C-c” (it looks to me like dependencies are propagated correctly). SLIME knows what capability your Lisp has, so it can take advantage of implementation-specific capabilities like debugging.

Installing SLIME

SLIME is installed the same way as any other Emacs plugin:

• Download and extract.
• Add the load path to your .emacs file
• Add any other code snippets required.

In this case, you’re going to be adding the following code to your .emacs file (open using “M-x M-f ~/.emacs“):

(add-to-list 'load-path "<em>/the/path/to/slime</em>")
(require 'slime)
(add-hook 'lisp-mode-hook (lambda () (slime-mode t)))
(add-hook 'inferior-lisp-mode-hook (lambda () (inferior-slime-mode t)))
(setq inferior-lisp-program "sbcl")

I haven’t tested it on Windows, so I’m not sure if there are any extra gotchas. If you find that you’re running into undefined function errors, one possible workaround is to install Cygwin and add C:\cygwin\bin and c:\cygwin\usr\bin to your %PATH% environment variable. Some people run away in horror at the idea, so if you don’t like it, you’re on your own.

asdf-install

One thing that you should research is asdf-install, a package manager for Lisp. If you find that you need a package that is found on cliki.net, you can download it with one step:

> (require 'asdf-install) ; Not the one step.
("ASDF-INSTALL")
> (asdf-install:install 'postmodern) ; The one step.
NIL

The above installs Postmodern, a simple Postgres interface for Common Lisp. Once you’ve done this, you only need to load the package into your Lisp image. This is also accomplished using asdf-install:

> (asdf:oos 'asdf:load-op :postmodern)
NIL

Using those 3 lines, you can now start to define database connections and operations on the database, without ever leaving Emacs!

Starting to Code

I highly recommend that you find a real reference or a real tutorial and start using that to write code. However, if you’re looking for things to enter into the REPL, I’ll give you some overviews of the basics of Lisp.

Arithmetic

> (+ 2 2)
4

This adds 2 and 2. Notice that Lisp arithmetic (and all Lisp functions) have prefix notation: the function name always comes first. You can nest values like the following:

> (+ (+ 1 1) 1)
3

Printing

> (format t "Hello, ~A~%" "Jacob")
"Hello, Jacob"
nil

‘format‘ is the function name. This is the Lisp-version of ‘printf‘,

The second argument is the destination stream. You can give this ‘t‘ or ‘nil‘ for true or false, or the name of a stream.

When ‘t‘ is given, the value is printed to Standard Output. When ‘nil‘ is given, the value is returned as a string.

The third argument is the formatting string. “~” is the escape character. “~A” means that it takes an argument that follows (like printf), and ~% is a newline.

There are other functions that you can use for printing, like ‘princ‘. I usually stick with ‘format‘, but there are different print semantics for different functions.

Defining functions

> (defun adding-function (arg1 arg2)
    "Adds arg1 and arg2."
    (+ arg1 arg2))
ADDING-FUNCTION
 
> (adding-function 1 2)
3
 
> (+ (adding-function 1 2) 1)
4

Here we see a function definition and two function calls. Let’s examine the function definition:

> (defun adding-function (arg1 arg2)

This can be considered the prototype line. ‘adding-function’ is the name of the function. It takes two mandatory parameters, ‘arg1′ and ‘arg2′, both with no default values.

"Adds arg1 and arg2."

This is the “documentation string.” A string may optionally be the first atom of a function, and it can be accessed from within Lisp using Lisp’s documentation reading abilities. Note that unlike wimpy strings in most languages, Lisp strings can contain newlines with no extra syntactical work.

(+ arg1 arg2))

This is the executed statement within the function body. A Lisp function returns the return value of the last statement. Since this is the only statement, it returns the addition of arg1 and arg2.

Defining variables

Defining a variable for the first time in SBCL:

(defvar my-var) ; my-var is 'nil'.
(defvar my-var 'a-value) ; my-var is 'a-value'.

Notice the quote in 'a-value. The single quotation mark indicates that the following expression is data, not code. Otherwise, it would try to look up the value of the variable a-value, which we may or may not have defined. Either way, it’s not what we want.

If a variable is already defined, you can use ‘setf‘:

> (setf my-var 3)
3

Conditionals

For statements that only execute when something is true, use ‘when‘. For statements that only execute when something is false, use ‘unless‘.

> (when (= 1 1)
    t)
t
> (unless (= 1 1)
    t)
nil

For statements of the form “if (true), do (x), otherwise do (y)“, use ‘if‘.

> (if expression
    x
    y)

If ‘expression‘ doesn’t evaluate to ‘nil‘, then ‘x‘ is executed and its return value is returned. Otherwise, ‘y‘ is executed and its return value is returned.

For statements involving a lot of if, else-if clauses in other languages, use cond:

(cond ((test1) (expression1))
      ((test2) (expression2))
      ; ...
      (t (default-expression)))

Iteration

The two easiest ways to iterate are the macros ‘dotimes‘ and ‘dolist‘.

> (dotimes (i 3)
    (format t "~A" i)
012
nil

‘dotimes‘ is exactly as it sounds: it executes a statement a number of times. You assign a variable (in our case, ‘i‘) and tell it the number of times it shall execute, and the variable takes on the values of all of the integers in the range [0, n).

> (dolist (i '(1 2 3))
    (format t "~A" i))
123
nil

‘dolist‘ iterates through a list much in the same way ‘dotimes‘ does.

Reduce

The idea of ‘reduce‘ is to iterate through a set, applying a function to each value that acts as an accumulator. For instance, we can do this with addition:

> (reduce #'+ '(1 2 3))
6

Lambdas

If you want to define your own functions for ‘reduce‘ without writing formal functions, you can do them as a ‘lambda‘. That’s just a fancy word for ‘function with no name’. It consists of the name, the argument list, and a function body to execute:

> (lambda (x) (+ x 2))

This defines an anonymous function that adds 2 to the input given. The only difference from ‘reduce‘ is that we need to provide two parameters: the accumulated value and the next value in the list.

You’re going to use this. A lot. Formally defining every function is not worth it. A lot of Lisp code ends up much cleaner with functional approaches.

To define our own addition function for ‘reduce‘:

> (reduce (lambda (x y) (+ x y)) '(1 2 3))
6

Other features of Common Lisp

• Macros: Creating code on-the-fly
• CLOS: Common Lisp Object System. Lisp’s answer to Object Oriented programming.
• Packages: This is how Lisp does namespacing.
• More iteration constructs than you know what to do with.
• ‘mapcar‘: Apply a function to each element of a list
• Hash tables
• Arbitrary precision integers and numbers
• cons: “Construct” function. This is the function that builds lists.car: Returns the first element of a list.
• cdr: Returns the tail of a list (everything but the car).
• Arbitrary binary manipulation
• ‘eval‘: Generate code from data at runtime.
• File streams, input streams, output streams, stream redirections, oh my!
• FFI: Foreign function interface. This lets you interface Lisp with C. You’ll probably need to do this if you want to add functionality to Common Lisp. It’s actually surprisingly easy to use.

Resources

Books

ANSI Common Lisp by Paul Graham. A great first Lisp book. It can be used as a textbook.

Paradigms of Artificial Intelligence Programming by Peter Norvig. The best programming book I have ever read. It does have quite a bit on AI, but it also has extensive sections on advanced Lisp programming.

Websites

SBCL: The Lisp implementation I currently use.

SLIME: A Lisp interaction plugin for Emacs.

Limp: A SBCL plugin for Vim.

cliki.net: A general Lisp resource. The home of all projects remotely installable using asdf-install.

Common Lisp Cookbook: An incomplete, yet still helpful, recipe book for Lisp code.

I’ve been programming a lot recently (instead of blogging about programming!). I caught the genetic algorithm bug along with the rest of the internet, so I’m in the middle of writing a Lisp library to make it easier to develop genetic algorithms: Genesis [Github link].

I’ve made some progress in the past few weeks!

The first version of my program was only a genetic programming library, and barely. It produced a rule set that could be evaluated as a function, but it wasn’t anything different than hill-climbing (a phrase I learned from snobby Reddit commenters). It was inefficient, it was unwieldy, but it produced great results when it ran long enough.

I’ve added a population! An arbitrary number of critters evolve in parallel at the moment. Previously, the individual would just mutate. I also added a basic gene-sharing algorithm: random merging.

It’s faster! In my first version, I used two ‘eval’s per rule per round. Now I use 1, and I will cut it down to 2 per rule evaluation (instead of per round) soon.

It’s in a package! I finally decided to follow my own advice and namespace everything properly. The package layout still needs work, as I’ve been too busy coding to figure out the ASDF system for installing packages.

The package system in Lisp is a lot more flexible than most module systems I’ve ever used, so I’ve been reading a few other popular Lisp packages to see how they are organized before I jump off the deep end without my swimmies.

I started to add tests! Some of the functions are very fundamental in nature, so I’ve started to add solid tests for them.

I segregated the example! There are currently 2 different files: genesis.lisp and square-root-sample.lisp. square-root-sample shows the code necessary to produce a simple/stupid example: finding an algorithm to calculate square roots. As I’ve mentioned before, the results are very good:

All you need to do in order to run this example is load genesis.lisp and square-root-sample.lisp and call the following:

(square-root-sample <em>generations population-size</em>)

After it has finished (run a small number of generations to get a sense for the time it takes), you can call the following to get the best answer so far:

(funcall-best *CURRENT-POPULATION* #'sample-fitness-function 16)

Work Needed

A recent popular example of genetic programming is the production of the Mona Lisa using random polygons. My program should almost be able to handle this. I don’t allow for a “modify rule” function at the moment, only a “new rule” function. It would probably work, but convergence would be even slower than the example given.

I’m also not allowing for one of the most powerful methods of genetic algorithm development: binary serialization. Imagine: if you can represent your whole algorithm as a binary string, then crossover, reproduction, and mutation are all made trivial. I am instead using this idea for lists, which is convenient in Lisp, but I feel it lacks some of the punch.

On The Horizon

Of course, this is still in the toy phase. I still have a pretty substantial to-do list, but here are some of the high-notes:

• Finish writing tests for core functions.
• Multiple populations, including cross-breeding between populations.
• Add multithreading.
• Give the user much greater control over (genetic-algorithm) by allowing extra key arguments.
• Self-awareness: Gather statistics on which alterations produce better improvements, and make beneficial changes more likely to occur.

What are Genetic Algorithms?

Genetic algorithms are one of the best things that computer science has produced. Rather than figuring out a good algorithm yourself, you let your random number generator find one while you sleep! Well, after an up-front design cost to generate proper random functions, and evaluating them, and determining how you’ll evolve them, and how long they should run…

I’ve long been interested in genetic algorithms, and now that I’ve learned my first language with an eval — Lisp — I’m starting to make a library. I spent the past few days prototyping and testing my code,
and I got some encouraging initial results: I got a great almost-linear approximation to my simple test problem (finding square roots) using only addition, subtraction, multiplication, and division (see below).

I know, square roots. What a scorcher. But real people are making real solutions to real problems using genetic algorithms! NASA engineers produced an antenna. They determined acceptable design parameters for the antenna, figured out how to evaluate new designs, and let randomness determine the rest.

The result is described here.

My Genetic Algorithm Plans

I want to produce a Lisp package over the next few weeks (since I should have a boatload of freetime around Christmas) that makes it easy to define new genetic algorithms. I’m going to do it in a few stages, and blog about intermediate results if and when they are interesting.

This will also give internet denizens plenty of opportunity to criticize my awful Lisp code! I am a nublet when it comes to Lisp, and I have no illusions about the quality of the code I’m writing.

This week: prototyping. I picked an easy problem to work out the basics of genetic algorithms. My problem? Finding square roots between 0 and 99, inclusive, with just one rule set.

Disclaimer: This is potentially the stupidest use of genetic programming known to man. Attempting to regularly solve numeric problems with genetic algorithms can lead to blindness, irrational exuberance towards Republican politics, and death.

To give you a sense of the data it ingests, I present the main interface:

(defun genetic-algorithm (generations starting-rules rule-fun
                          fitness-fun)
  "Runs 'generations' number of generations. The rules are initially
  set to to 'starting-rules', the rule generating function is
  'rule-fun', and the evaluation function is 'fitness-fun'"
  (prep-rules starting-rules)
  (dotimes (gen-num generations)
    (run-generation rule-fun fitness-fun)))

Here is the invocation I used for my square root problem:

(genetic-algorithm 32000 '((/ num 2) (+ num .2))
                   #'sample-rule-fun #'sample-fitness-fun)

The typical work for defining genetic algorithms is split into a few stages:

1) Problem definition: What do I even want to solve?
2) Evaluation function: How far am I from right?
3) Picking components: How can I build my algorithms randomly?

Problem Definition

Find the square root of an integer, n, in the range [0, 99].

Evaluation Function

Sum of the squared error of all of the integers in the problem statement.

Interestingly, we can predict the quality and form of the results: since we are minimizing the sum of the squared errors, the result should mimic a least-squared approach. Since I’m only using basic arithmetic, it probably won’t be a very good one (linear at best..).

Prototype Implementation

Warning: There be dragons in the parens ahead.

The rules are stored as a list of lists:

(defvar *RULES* nil)

We also store the possible operators:

(defvar *sample-nodes* #(leaf + leaf - leaf / leaf * leaf))

Woah, what’s with all of the “leaf”s? Well, a balanced binary tree has about as many nodes as leafs (I’m generalizing…), so I started at leaf/operator parity and moved up until I stopped getting stack overflows when generating new functions, which happened at one .

How do the leafs get translated into values? First, they are picked from an array of random values:

(defvar *sample-values*
    #(-1 1 num num randomnum randomfrac))
 
(defun sample-generate-leaf (list)
  "Picks a random element from 'list' and translates it into the proper atom
  or list."
  (let ((elt (random-array-element list)))
    (case elt
         (randomnum (random 1024))
         (randomfrac
          (let ((val (ignore-errors (/ (random 1024) (random 1024)))))
            (when (null val)
              (setf val (/ 1 2)))
            val))
         (t elt))))

These are pretty self descriptive (num is the input number, and it is included twice because I got better results ). ‘randomnum‘ is a random integer in [0, 1023], and ‘randomfrac‘ is a fraction whose
coefficients are in [0, 1023].

So how is all of this put together?

(defun sample-rule-fun ()
  "Example random rule generator. Generates a random arithmetical
  expression."
  (let ((elt (random-array-element *sample-nodes*)))
    (case elt
      (leaf (sample-generate-leaf *sample-values*))
      (t
       (append (list elt) (at-least-once #'sample-rule-fun))))))
 
(defun sample-generate-leaf (arr)
  "Picks a random element from 'arr' and translates it into the proper atom
  or list."
  (let ((elt (random-array-element arr)))
    (case elt
    (randomnum (random 1024))
    (randomfrac
     (let ((val (ignore-errors (/ (random 1024) (random 1024)))))
       (when (null val)
         (setf val (/ 1 2))) ;; avoid divide by zero
       val))
    (t elt))))

This is also fairly straightforward: if you pick an operator, generate a new list, if you pick a leaf, generate a new value.

Results

Square Root Function Test

I ran it for about 18 hours (overnight and after work), and when I came back, the results were nothing short of amazing:

I included a range of values outside of the initial zone because the results are better than I could have hoped for.

I saved the data, and then was trying to save the rules (there were 18 in all), and then I lost them from my first Emacs freeze. C’est la vie. However, my initial guess that the data would fit as a least-squares appears to be a better guess than I ever could have hoped. I want to add arbitrary polynomials, and I hope to see a higher-order best-squares fit of the data plot, with much less error.

Implementation Time

The first implementation was done in a 4-hour chunk of one evening (during which I played X-Moto for at least an hour…), which I find impressive. I probably would have spent at least 3 times that on the prototype in C++. This problem is made extremely because of several of Lisp’s features:

eval: My method is based on runtime list generation, and eval-ing it as a lambda.

Insanely simple Lisp syntax: The same syntax that defines lists also defines their programs? This reduces random function generation to a random list generation problem, which is almost trivial.

REPL: Lisp is a REPL (read-eval-print loop) language, meaning that it has an interactive prompt. Combining this with Emacs’ multiple buffer capabilities, and it’s super easy to make changes and reload.

TODO

It’s never finished!

Rules

Allow more than one rule set, define the maximum number of rules per set, define rules as arrays for better lookup, etc.

Better use of eval

I eval the rules every time I need them, as opposed to the once I should generate them. I will probably see a significant speedup when I do this.

Define a package

Namespacing everything has obvious benefits.

Cross-breed rules

Allow true genetic properties by copying subsets of rules into other rules.

Better rule trimming

My current program produces some stupid rules: such as f(x)=x. In fact, my “amazing results” had 4 rules that evaluated a number to itself out of a total if 18 rules.

Allowing the user to define rule inputs.

Putting the package in an easy-to-use location

Stay tuned for more!

What is “Code Inertia”?

I’ve been interested in “code inertia” for a few years now. It should sound familiar to anyone with a basic understanding of physics: code with a lot of inertia is very resistant to change. You’d either have to be crazy, uninformed, or very well paid to try to shake the way the system is organized.

I met my first gigantic and arcane system at my college internship. It was a Java-based web platform with 8 years of cruft built on top. There was no documentation for even creating a development environment, and it had a complex and lengthy build system. It was a mountain of pain ready to strike. There was no way in hell that the system could be considered “beginner friendly,” and there was no clear path for gaining knowledge of the system.

It was so complex that only a handful of individuals had the Keys to the Kingdom. Everybody else used the tools produced by the Chosen Ones and went on their merry way. I tried to become a Holder of Knowledge, but the system proved too great for me, the college intern.

Why do I mention it? Because the whole system had a gigantic amount of inertia! There was so much code built on top of the mountain, that nothing could be changed. You couldn’t change the build system, because then you’d have to alter a mountain of configurations for hundreds of sites. Despite the amount of code, very little of it was actually reusable, and there was no central repository of knowledge for code reuse.

The most helpful changes became the ones that were the most impossible to make. It was a big, suffocating force, and the company eventually abandoned it for a shiny new toy called Sharepoint. The old way of doing things simply wasn’t sustainable. Whether they learned their lesson or not I’ll never know, because I have since left the company and landed a real programming job.

Because of the monstrosity I mentioned, I appreciate my current job’s gigantic, fairly documented, and accessible code base quite a bit. It’s not close to perfect, but it does a lot of real world tasks very well, and beginners can use a good chunk of it pretty quickly.

Windows.h

If you want THE BEST example of inertia, just look at “windows.h“. It might have the greatest code inertia of any file not defined in a language standard. It is the basis for every Win32 application. Could it be modified? Potentially, but only by appending to the standard. The file itself could never be modified without wasting an impressive number of programmer hours.

This is unfortunate, because it has classic design errors. Windows programming still isn’t very “easy” with it, and you have to watch #include order and know what macros it defines. Yuck. However, none of these things can really be fixed, because even innocent-seeming changes would probably break builds for arcane reasons. Obviously, it should be replaced.

The .NET framework is the first Microsoft offering that has the potential to deliver a knockout blow to the old way of Win32 programming, since MFC wasn’t up to the task. Some people reject .NET for the runtime size, and others reject it because it’s Microsoft-specific, but it’s a lot easier to work with than Win32 for your run-of-the-mill windowed application.

Reasons for Inertia

Code can pick up inertia for different reasons:

So many files depend on this code that changes would be prohibitively expensive.

This is (in my personal experience) the most common kind of code inertia, as it’s hard to avoid even for well-designed systems. You design a few nice classes, build useful utilities around them, and use the library in 162 programs.

You could easily change the low-level code underneath the utility abstractions. Unfortunately, the top-level interface has picked up quite a bit of inertia. If you want your whole system to be consistent, you’ll need to make quite a few changes. Otherwise, you can do sneaky things that are good enough for most situations, like deprecate the interface while maintaining a backwards-compatibility layer.

The code itself is so large that changes are prohibitively expensive.

This is related to the previous point, but sans dependences. That finance application you were writing for that coal business? Well, they suddenly decided that they wanted to enter the asphalt business, and want the application to reflect that.

The code is so complex and ill-written that changing it is likely to break everything.

This is likely to have been written “by somebody else.” Everybody tacks their changes on to the system instead of modifying how it works, and hope it falls apart when the next guy uses it.

That guy who knew how everything works quit.

“Fricksticks, Frank’s gone. Now nobody knows how the the whole Foo suite works. Frick frick frick.”

Predictive Power of Inertia

Let’s say that our company has two million lines of code that works wonders with widgets, and our CEO suddenly sees a golden opportunity in the gadget market.

We have a big problem: our code wasn’t designed with gadgets in mind! You might find some core libraries are abstracted enough to work with gadgets. The rest of it explicitly assumes widgets.

What’s going to happen? As nice as refactoring the entire code base would be– and I think I threw up a little inside thinking about it– it’s obvious that gadget code is going to be added on top of the widget code base, instead of working with it. That’s a prediction that anybody can make.

Adding the basic gadget functionality you need NOW will be much less effort than changing your code to handle widgets, gadgets, gizmos, and pandas. It’s the right way to go from a business perspective (less time, less expense, same results), but it’s unsatisfying from a technical perspective, and probably misses some nice opportunities for generalization.

Some people will point out that there are lost opportunities for the future. You may want to also be able to work with thingamajigs and whatchamacallits in the future. If you tack on gadget code, you’re going to be tacking on code for everything else.

It’s important to realize that there’s never a free lunch in any of this regard. Even if all of your library code has perfect abstractions, you’ll still need to build up some extra gadget-specific code that reads and writes them, interfaces with your existing utilities, etc. It’s all just a matter of ease of modification.

Law of Large Code Bases

All code bases cross a size threshold where addition is less costly than modification.

When you need new functionality in your code, you have two options:

1. Modify the existing code to solve your problem.
2. Creating new code to solve your problem.

Sometimes, Option 1 is unacceptable, and it’s unfortunate. In a perfect world, we would write code once, and it would work for all of our situations. In a less perfect world, we should always be able to modify our existing code to best be generalized. Unfortunately, software is a business, and rewriting/heavy modification isn’t always in the cards.

Option two is a short term solution, but an interesting corollary becomes immediately obvious:

When a code base has crossed the threshold mentioned in the Law of Large Code Bases, adding additional adds additional inertia to the code.

When code crosses this boundary, you can consider it a marked man until it is changed for the general case.

Can We Plan Around Code Inertia?

The planning phase of the project is obviously the best chance to take code inertia into account. Unfortunately, there’s not usually a whole lot that you can do. You’re not always under control of the scope of your project, and you don’t know what problems you’re going to need to solve in 2 years. That’s fine.

Trying to find flexible solutions is a great way to start. Just take a look at Steve Yegge’s post on Property Lists as a programming paradigm. You can express a tremendous number of solutions in terms of
property lists, and they’re very flexible if you use them right.

Another successful strategy is the One Thing Well philosophy. Unix systems come with a broad variety of tools that “do one thing, but do it well.” Chaining the tools together is easy, and any system programming problem can easily be solved in terms of these tools.

In writing this post, I noticed that deprecation/change seems to be the most successful way of supplanting old methodologies. Python 3000 is a great example of this. So is the module system of the Linux 2.6 kernel. It turns out that it’s really easy to change code that’s underneath a layer of abstraction, but you can’t change code that relies on the abstraction.