XO Critical Configuration 1

Until a recent trip, I hadn’t used the XO very hard, or configured it at all. Before heading out, I read Bill’s article and found some real gems that, along with my own preferences, make using the XO a much more pleasurable experience. They follow:

The XO was made for its creators

After using the OLPC XO heavily for the past three weeks for web browsing, pdf reading, and educational game playing (by my 5 year old nephew), I can’t help me get the feeling that the XO was made for its creators, and not for children.
Now don’t get me wrong, I love the thing; but how do you explain to a 5 year old (albeit a very smart one) that he can’t start more than 2 or 3 programs at once because the machine will run out of memory and the CPU will get bogged down?! (An aside, how you explain it is by doing just that, excluding the part about memory and cpu).
The vision of a computer where everything is written in Python and everything is modifiable and maintainable by the user is a fun idea, but only for hackers, aka, the creators. Kids could care less. What they want are programs they can use that work well. Are they getting that right now? Well, they are getting something that works “well enough”, but it seems like the XO creators are painting themselves into a corner here in terms of performance; since the hardware will never get upgraded, the only place they’ve got left to speed things up is in the code, and that seemingly has not been a priority thus far.

PLT Scheme 3.99 (revision 10030) for the OLPC XO

DrScheme is very, very close to its 4.0 release. I wanted to try out the newest bits on my OLPC XO using one of the nightly builds, but ran into the same problem as I did last time:

/home/olpc/apps/plt-3.99.0.25/bin/mred: error while loading shared libraries: libGL.so.1: cannot open shared object file: No such file or directory

Some folks have resolved this dependency using Mesa for OpenGL emulation, but I found it easier to prepare a build that doesn’t depend OpenGL.
Here is the tarball and the md5sum for a trunk build that I made at revision 10030.
Here is how I did the build:

./configure --prefix=$WORKDIR/$DESTDIR --disable-gl --disable-shared --enable-origtree
make
make install

Memes are Brainwashing

From Wikipedia:

A meme consists of any unit of cultural information, such as a practice or idea, that gets transmitted verbally or by repeated action from one mind to another.

Whether or not you agree in the validity of memes as a science (I don’t); the term is often used in authoratively in pop culture. They typically represent some bit information, usually in the form of a frequently repeated phrase, that spreads around and around the community. In the programming community, there are plenty. For example, here are a few: “convention over configuration”, “don’t write code just to make the compiler happy”, or “every developer must learn how to program concurrently: it is the future”.
The interesting things about memes are that they often have an element of truth behind them. For example:

  • “Convention over configuration”: Abstract away often repeated work
  • “Don’t write code just to make the compiler happy”: Use the right language for the task at hand
  • “Every developer must learn how to program concurrently: it is the future”: Use the right problem solving approach for the task at hand
  • “[My programming language] is purely functional“: For the type of program I am writing, side-effects are not welcome

The idea of memes is to pass around the interesting idea so that we can all benefit from it. The problem with them, though, is that they don’t. Instead, they sort of pass around a half-truth whose only intention is to further, most probably, some individual’s agenda. For example:

  • Lisp is convention or configuration taken to the extreme, but you never hear anyone saying that (If you hear me saying it, slap me), and they shouldn’t. Ruby on Rails is to Ruby as Struts was to Java; the only and therefore best of its time.
  • “Don’t write code just to make the compiler happy” is pretty silly. Use a statically typed language for a reason. Use dynamically typed language for a reason. There is a difference. You should understand the difference and its impact to your development process.
  • The IEEE, ACM, and nearly every presenter at JavaOne 08 preached fear of the multicore future without expounding on why every developer needs to master multi-core programming (solution looking for a problem?). That said: if every programmer learned how to program really well in the first place, we might not need 64 cores.
  • “Haskell is purely functional, so it is better than all other impure languages”: Please help me, the reader, understand why!

Because memes are half-truths, people often don’t get to the meaty goodness of the truths behind them. Perhaps at some gut-level they know there is a very good truth hiding back there. If, like most people, though, they don’t explore it further, then they will instead assume the meaty truthful goodness to be the ugly, half-truth of the meme. Since the community largely supports the meme; it becomes common knowledge that the individual must accept it in order to keep his place in the community.
Therein lays the danger of memes, whenever the meme is reintroduced, the individual sort of experiences the behavior modification reaction much like a Skinner pigeon; they have to buy into nonsensical statements about which everyone agrees. Sprinkle any article or blog post or discussion with any number of such memes and you have instant gold for making your point unbeatable. It is a strange and disappointing phenomenon that draws into question much of what is written in the tech world today.
Addendum: 12/10/08
Today I fixed typos, revised the grammar, and altered the content to reflect what I actually meant. As such, I believe this to be a “good faith” modification that didn’t merit change-tracking for the reader’s sake.

Writing the next great Java book

At JavaOne 08, the presentation “Writing the next great Java book” looked to be pretty exciting. It was originally billed as an introduction to a couple of authors, a QA session, and then primarily a review of great books in Computer Science history so I was pretty excited. In reality, it was very disappointing.
The authors blabbed about the same “Authoring 101” that you can pick this up on any “Intro to Authoring” website. In other words: it is really difficult, it will take four times as long as you think, and your family will hate you. The rest of the session was exhausted by the “Head First” authors Kathy Sierra and Bert Bates giving the same, canned presentation that they’ve been giving since at least 2006 (the first time I saw it).
Now don’t get me wrong; Sierra and Bate’s presentation is awesome. It is a lot of fun, and you learn a lot. The problem is that you learn a lot about selling; not about writing. Take the tenets for example:

  • Passion: Enable people’s passion
  • Experience: Provide a no-suck experience
  • Feeling: Don’t make people feel stupid; make them feel like they kick-ass

Very, very cool ideas. One problem, though; Computer Science is hard. You will feel stupid. Self-reflection is part of learning, and saying to your self “Darn, I don’t get this. It is only 5 sentences and I don’t get it. I feel stupid”. The next step is to press on and learn it. Books don’t make you feel stupid, you do; it is part of learning!
Now, if you truly find a book that sets out to make you feel stupid, be amazed, because such books are sure not to sell any copies. Contrast that with the classics of Computer Science that are works of art, and may involve you feeling stupid, but surely don’t set out with the intention to make you feel stupid, but to teach!
To wrap up the presentation, no time was given to classic Computer Science books.

Closure Cookbook

At Java One 08 Neal Gafter gave the “Closure Cookbook” on Closures in Java; in particular the BGGA implementation that he is proposing as a JSR.
To sum up the presentation, it was about closures, in Java. In particular, it went into explaining what are closures and how you might use them. The tough, and more interesting part, is how you would use them in a statically typed language like Java.
It will be interesting to find out what percentage of the Java community will actually grok how to utilize closures. The impression that I got from the presenter is that closures will be limited to the library and API writers in all but trivial cases.

Java One 08 Keynote

Is Sun in touch with Java developers?
The entire keynote was spent talking about how developers are soon going to be able to write applets that run on a desktop, in a web browser, and also on a phone. We have had this for years. Whose idea was this?
The really interesting stuff in Java land right now is Java 7 features and concurrent programming with Java, but apparently none of that was worth mentioning.
The worst part of it all is that during the demo, the applet repeatedly crashed, and crashed, and crashed. The first Java program that I ever saw was running was an applet running in a web browser, in 1995.
13 years to get applets right? Come on Sun.