Programming Manifesto

This is an open letter I wrote for a professor who rejected a proposal I gave for a semester-long research project in creating a programming language I'm designing. It became a personal programming manifesto and as such was inappropriate for actually sending to said professor, so I merely publish it here.

If you are the originally-intended recipient, hello! I'm flattered that you would read my blog.

Dear Professor,

I just realized that I misrepresented myself when I last came to propose my independent research project for next semester. I unintentionally revealed my foolishness with such a crazy project idea. The problem is that I am a perpetual student. I have no intention of pushing forward the field of computer science, because I've decided that I just don't know enough yet. Thus, all I can do for now is study.

I have the philosophy that if we can only learn by doing, and we learn from our mistakes, that the greatest way to learn is by throwing oneself headlong into projects that have every opportunity for failure. So I do this on a daily basis.

In Operating Systems class, I eschewed the recommendations to create a disk-based filesystem based on i-nodes; instead I ported an old, naive implementation of malloc. It took several times longer and I thought I could smell failure around the corner several times, but in the end I had a system that was faster, supported files and directories the size of the disk, and added a few items to my list of things to never do again.

What it came down to was the fact that I didn't want to take the safe bet. Everyone could see the flaws of such a simple system, so there was no element of exploration. Trudging down that road would have been mindless busy-work. As I'm blissfully ignorant of most CS literature, my own approach was surely just as primitive, but even if I had read that it was the least effective filesystem possible to design, I likely would have tried it if only to see whether it was true. A big part of my self-education is digging back through time and testing our base assumptions for myself.

I maintain a blog that used to be written in PHP. After a while I discovered Ruby on Rails and re-wrote it. Running on Ruby, it became slow, and I decided to figure out whether all the beauty Ruby gave me was worth it — so I rewrote the site in C. I certainly got further than I expected — recognizing URLs and serving several different pages — but when it came time to use library calls for managing things like database connections or file handles, I took some good looks at the documentation for the C API calls and decided that it was time to move on.

I had rediscovered something I had been told many times over: C is inappropriate for designing web sites. Now I know exactly how, which means the wheel I'm reinventing is about as good as those we had a decade ago. One day I hope to catch up and invent cutting-edge wheels of my own, but just as motivating is understanding what drove the development of wheels from the mess that preluded them.

So pardon my affection for the tried-and-failed. I won't be coming by your office again for quite some time — enough for me to prototype the system on my own to examine its merit, in fact. I was never any good at finding problems for my solutions, but perhaps one will show up before classes begin again.

Sincerely,

Tom Lieber

In case you were wondering, the language I proposed was a real doozy. Remember when self-modifying code was all the rage? Combine that with an in-memory code layout I'm having trouble finding a textual representation for, and an interpreter which is never meant to lose state, and you've got a really scary system on your hands. If this project doesn't put some hair on my chest, I don't know what will. Wish me all the best!

Posted May 04, 2008, in the afternoon.