Lisp Hackers: Luke Gorrie [+ his ECLM video]

Luke Gorrie is a proverbial hacker following his passion for programming to various places in the physical world, like Sweden or Nepal, or programming world, like Erlang, Forth, Lisp, Lua, or some other fringe language. And enjoying the process of exploration and meeting different people, while fiddling with computers, from OLPC to telecom equipment, working with world-famous technologists, including Joe Armstrong or Alan Kay, and, generally, doing whatever he likes in the programming world.

He was one of the main authors of SLIME in its early days. And recently he founded a Lisp networking startup Teclo Networks, the story of which (as of fall of 2011) he told at ECLM 2011. Here's the video, that he asked to hold off for some time due to business reasons, and only now it's posted online. Enjoy!



Luke's twitter account is @lukego

Tell us something interesting about yourself.

I enjoy exploring the world. I was born and raised in Australia (Brisbane), I've lived for many years in Sweden and become a Swedish citizen, and these days I'm extremely happy to be settling myself into Switzerland. I've spent a couple of years traveling continuously with just my backpack and unicycle and no home anywhere to go back to. I've found this interesting. You can find links to my exploits on my homepage.

I like to feel a bit out of my depth and to be "the new guy" who has a lot of catching up to do. This is why I so much enjoy learning new programming languages and visiting new programming communities so much: the feeling of having to think really hard about how to formulate even the most basic programs, just like when I was a kid, while other people do it so naturally.

What's your job? Tell us about your company.

I'm currently starting a new project called Snabb. It's too early to say very much about this yet, so I'll talk about the past.

I've had a few major jobs that have shaped my thinking. I worked in each one for about 3-5 years.

The first was Bluetail AB, the first Erlang startup company. I was hired by Joe Armstrong because I had enthusiasm pouring out of my ears and nostrils. I moved immediately to Stockholm in the middle of winter for this job -- I was 21 years old and I'd never left Australia or seen snow before. I learned a lot of things at Bluetail, besides practical matters like how to walk on ice. The programmers there were all way above my level and I was routinely stunned at the stuff they had done, like when Tobbe Törnqvist mentioned in passing that he'd written his own TCP/IP stack from scratch as a hobby project and that his dial-up internet connection uses his own home-brew PPP implementation. I used to roam the corridors at night borrowing tech books from people's shelves, there must have been a thousand books in the office.

Bluetail was bought by Alteon, who were bought by Nortel at the same time, and become a productive little product unit in a big networking company.

Next was Synapse Mobile Networks. This was an amazing experience for me: to switch from a big company to a small company and take care of everything from design to development to deployment to support by ourselves. Really getting to know customers and internalizing their needs and building the right solutions. The product is a device management system, which is a realtime database in a mobile phone network keeping track of which phone everybody is using and making sure all their services work. The whole thing was written in Erlang and BerkeleyDB, even with a from-scratch SS7 telecom networking stack in the end. I would routinely fly to a really interesting country -- Kazakhstan, Jordan, Russia, Algeria, you name it -- and spend a few weeks deploying the system and developing customizations on-site. Synapse was the first company in this market and they are still the market leader today. The system has by now configured approximately 1 billion actual mobile phones by sending them coded SMSes.

Synapse was also instructive in seeing how much a strong personality can shape a company. I'm still in awe of our fearless leader Per Bergqvist. What a guy, as they say on Red Dwarf.

The most recent is Teclo Networks. This is a company that I co-founded with friends from the SBCL community -- mostly drinking buddies from ECLM -- and friends from the telecom world. I served as CTO during the phase of finding the right problem to solve, building our series of prototypes and our real product, and finding our very first customers. I'm a Teclo-alumnus now, not actively working in the company, and: Wow, this was a really intense few years.

Teclo builds network appliances that optimize TCP traffic for cellular internet at about 20Gbps per server. The product speeds up the network, improves consistency, and globally eliminates buffer-bloat. The company is currently moving forward with a lot of momentum: we have Lispers like Juho Snellman, Tobias Rittweiler, and Ties Stuij currently deploying systems in real live networks all over the world. Go Teclo :-)

Do you use Lisp at work? If yes, how you've made it happen? If not, why?

I've mostly done Lisp hacking for my own pleasure on the side, but I've also used it quite a bit at work.

The first time was when I used Scheme at Bluetail. Specifically, I used Kawa to extend a Java application. I'm sure this raised some eyebrows amongst my colleagues but frankly I was having too much fun to really notice. Kawa is a great piece of software.

I wrote a bunch of Common Lisp networking code while reading books like TCP/IP Illustrated. This was a hobby project called Slitch and Netkit. I used this slightly in my work at Nortel to replicate a DoS against the Linux kernel that was crashing some of our appliances.

Teclo is very much a Lisp-hacker shop. In the first year or so we used Lisp for absolutely everything. We've written and deployed a prototype TCP/IP implementation written in Common Lisp (SBCL), wrote network analysis tools for cross-referencing and visualizing traffic captures (often working on traces that fill up a whole disk i.e. hundreds of gigabytes), and developed all of the operation-and-maintenance infrastructure in CL. These days Teclo uses C/C++ for the main traffic handling, R for statistical analysis, and Common Lisp for the rest -- mostly operation and maintenance and data visualization.

Among software projects you've participated in what's your favorite?

SLIME! This was wild fun. The project started when Eric Marsden, a CMUCL hacker, posted to #lisp his weekend hack to annotate individual S-expressions in an Emacs buffer with CMUCL compiler messages. His source files were slim.el and skank.lisp, after the Fatboy Slim song he was listening to at the time. I loved the idea so I started toying with it, renaming the files to slime.el and swank.lisp to make them easy to diff. I quickly posted my version to the cmucl-dev mailing list where Helmut Eller jumped right into it too. We created a Sourceforge project and quickly snowballed from there to over 100 contributors.

SLIME's mission was ultimately to replace ILISP as the standard Emacs mode for interacting with Common Lisp. ILISP worked by sending S-expressions between Emacs and Lisp via standard I/O and it had the unfortunate habit of getting stuck a lot. ILISP was also about 15 years old at that time (SLIME is catching up now at 8 years!) and really hard to work on due to the heavy use of reader conditionals in the source code, like #+cmucl #-lucid #+sbcl #-lispworks #+acl #-acl4.2 and so on.

I really enjoyed the feeling of working on a growing and thriving open-source project. Seeing the steady stream of new names appearing on our mailing list, getting patches from dozens of people, feeling good about positive feedback we received, working hard on negative feedback right away, and so on. Twas a really productive flow.

I think that writing development tools is also really satisfying because your users are your peer group: people you really look up to and respect and sometimes drink beer with. It's a great feeling to build stuff that they like to use.

Helmut Eller and I also had a really great working style. Very often I'd do some late-night hacking and check in a bunch of new functionality, which Helmut would then read through and think about and then thoughtfully rewrite in a simpler way. Then I'd see what he'd done, think about it, and rewrite it to be simpler again. And so on. This was a really pleasant and productive way of working. He is also an absolute magician when it comes to suddenly checking in what seems like a month worth of work that he did over the weekend. (Juho Snellman has this uncanny ability too.)

I hacked on SLIME from the beginning and up to version 1.0. Then I was engulfed by an Erlang startup. Here're some posts that I fished out of the mailing list archives to give a sense of the early days:

• SLIME is born
• Users!
• SLIME User Survey
• SLIME 1.0 release party :-)

What brought you to Lisp? What holds you?

My friend Darius Bacon brought me to Lisp (Scheme) by gently and persistently singing the praises of Abelson & Sussman back in the days when I was a teenager hacking Java. This book was a revelation for me: particularly the Digital Circuit Simulator. So I was a Scheme-lover for several years, but Darius also gently and persistently sang the praises of Norvig's Paradigms of AI Programming, which was another revelation to me, and made a Common Lisp convert of me.

What holds me to Lisp is the people. I love hanging out with Lisp hackers: I find that we're an unusually diverse community. How often do you attend a small conference where attendees are building nuclear defense systems, running intensive care wards, designing aeroplane engines, analysing Lute tablature, developing cancer drugs, writing FIFA's legal contracts, and designing their own microchips? Surely this describes few tech events other than Arthur & Edi's European Common Lisp Meeting :-).

What you dislike the most about Lisp?

I have a few stock rants that I'm tempted to rattle off -- fragmentation, threads, GC-phobia -- but honestly I doubt they are applicable these days. There have been so many improvements to SBCL and great developments like Quicklisp and so on.

I can say I'm personally disappointed about the missed opportunity for us to write Teclo's production traffic path in SBCL. Ultimately, the software has just a few microseconds' budget to process each packet, and can never spike latency by more than a millisecond. I don't know how to deliver that kind of performance in a high-level language like Lisp. So we fell back to C.

I'd also like to have embedded SBCL in the C program to take care of high-level work like slurping in configurations and spitting out statistics. But the SBCL runtime system is a bit heavyweight to make that practical. It gets in the way when you want to debug with strace, gdb, etc. So we wrote this stuff in C++ instead.

I'd have written a lot more Lisp code in recent years if I'd found good solutions to those problems. But at the end of the day it is C's niche to write lots of tiny state machines with extremely predictable performance characteristics, so I'm not especially shocked or disheartened. A language can't occupy every niche at once :-).

Describe your workflow, give some productivity tips to fellow programmers

I'm an incrementalist. I like to start from minimal running code, like (defun program () (print "Program 0.1")), and move forward in a long series of very small steps. I tend to choose designs that I know are too simple or too slow, because I enjoy the feeling of hitting their limits and knowing that I didn't prematurely generalize or optimize them. Then I fix them. I'd say that I'm much influenced by watching the development of Extreme Programming on WardsWiki in the 90s.

This isn't a hard and fast rule though. In Teclo I once spent a whole month writing a complex program without even trying to compile it once. This was a rewrite of the main traffic engine in C after having written a prototype in Lisp previously. This was a really fun way to work actually. I produced a tremendous amount of bugs in this style though and I wasn't smart enough to fix them. Christophe Rhodes did that part -- don't ask me how :-).

I do have a tip for getting into "the flow". It's a simple one: make a little TODO list of some features you want to hack, and take the laptop into the park away from the internet for an hour or two until they're done. This works every time for me.

Oh, and I highly recommend printing out and reading your programs. This is the best way that I know for improving their quality. This is why I'm a bit picky about things like the 80-column rule and the layout of functions within a file. I want to be able to print programs out and read them on paper from top to bottom. I wrote a program called pbook to help with this -- it's not a very good implementation though, with all those regexps, so I'd love if someone would make a much simpler one.

You have played around with so many languages, like Erlang, Lisp, Smalltalk & Lua. If you would design your own, how would it look like?

That's really hard to imagine. I'd have to find a reason that I needed a new programming language, and the details would probably follow from the problem I needed to solve.

I learn new languages mostly because I enjoy meeting new people and learning new ways of thinking. It's very seldom from any sense of dissatisfaction with previous languages I've used. My favourite languages are Common Lisp, Emacs Lisp, Forth, Erlang, Smalltalk, and C. So the best I can say is: those are the languages that I'd like to have designed.

P.S. Luke asked to give my warm thanks to John Q. Splittist for reading over these answers before I sent them to you (and for many other things!).
submit

Book Review: Beautiful Code

It took me, probably, more than a year to read Beautiful Code (almost from cover to cover). Because of its volume, list of authors and coverage of languages and topics this book can absolutely be considered one of the bibles of modern programming. I've learned a lot from it and can recommend it to any programmer: both novice - to get the general picture of what programming spans and what is important in reality - and experienced - to study previously uncharted corners and maybe rethink some of the underpinnings of personal programming philosophy.

Surely, not all essays were of the same quality - on the contrary it ranged from very poor and dull, although still mostly informative, to insightful and even fascinating. The book features reknown authors: programming language designers and authors of famous books, as well as not so well-known but at times even more interesting people from various scientific and engineering communities. Almost all languages, ranging from FORTRAN to Lisp and Ruby are covered, and most of the topics are viewed, so to say, from two angles: most of the essays are paired either by language, or by topic, or both. Not surprisingly, almost half of the essays feature at least some code in C, as it was and remains the lingua franca of computing.



Each author was given a very vague task - to describe the most beautiful code, they've ever written or seen. Some interpreted it literally and just told and analysed an algorithm or hack. Others told a story about the whole system, how it evolved and became beautiful - these kinds of stories, were surely, the most interesting part of the book for me with two favorites. The first being the story of PGP-enabled Perl-based mail service Cryptonite, which maybe could feature in some collection of Cyberpunk novels; and the second - The Most Beautiful Code I Never Wrote by Jon Bentley, the author of Programming Pearls, in which he presents the analysis of Binary search algorithm, that helped to understand many aspects of this fundamental programming tool. Yet some people, who surprisingly include such famous programmers as Doug Crockford or Tim Bray, just used it to describe an idea, that they had found interesting, sometimes even without explaining why...

Personally for me the highlights of the book were:

• how extensibility and unification played an ultimate role in most of the stories about system beauty
  
• the proliferation of callback techniques on one hand and rather poor support of them in most of the languages on the other hand
  
• and the articles, emphasizing different aspects of programming craft, like Beautiful Debugging and Code in Motion (about code formatting)

I've also used a chance to dive deeper into Perl and get a glimpse of FORTRAN, as well as to learn about a lot of low-level optimization techniques and considerations.

So what's beautigul in code? I've tried to summarize the views of all authors (33 articles don't represent a statistically meaninugful sample, but still :)

Unsurprisingly, simplicity & elegance are emphasized a lot (6 times) and its backers include Brian Kernighan, Yukihiro (Matz) Matsumoto and Jon Bentley. It's also matched, or even slightly overrun in terms of proponents number by clear interface/API abstraction and code structure/organization (i.e. proper OO or functional design). Flexibility comes next with 3 people, championing it. Only 2 people root for modularity, or as the Unix philosophy goes "small pieces loosely joint", but their articles are very good and insightful: Simon PeytonJones on STM in Haskell and Greg Kroah-Hartman about the Linux Kernel driver model. Than comes a long tail of features, like: frugality (not being wasteful), being close to the low-level, balance, and visual readability. Some authors didn't emphasize any one aspect of beauty, but told about some area they thought may be beautiful. These include: search, code generation, tests, debugging, top-down operator precedence parsing, hygienic macro support and math.

P.S. And here's an alternative review by Jeff Atwood, based on the same data, but with different conclusions, which boil down to this: code per se can't be beautiful. He quotes another opinion:

The chapter written by Yukihiro Matsumoto, the creator of Ruby, was the most impressive standout. It is three pages in which he simply writes about what he believes beautiful code is. He explains his understanding of beautiful code to you. This is what the book should be!

While provoking interesting thoughts and discussion, those three pages weren't enough: they were quite shallow and didn't bring enough useful evidence to the table. The best chapters did both, and there are quite a few in the book.

Alan Kay about keeping history in CS

So true and very well explains my motives behind "Lisp Hackers":

Binstock: You once referred to computing as pop culture.

Kay: It is. Complete pop culture. I'm not against pop culture. Developed music, for instance, needs a pop culture. There's a tendency to over-develop. Brahms and Dvorak needed gypsy music badly by the end of the 19th century. The big problem with our culture is that it's being dominated, because the electronic media we have is so much better suited for transmitting pop-culture content than it is for high-culture content. I consider jazz to be a developed part of high culture. Anything that's been worked on and developed and you [can] go to the next couple levels.

Binstock: One thing about jazz aficionados is that they take deep pleasure in knowing the history of jazz.

Kay: Yes! Classical music is like that, too. But pop culture holds a disdain for history. Pop culture is all about identity and feeling like you're participating. It has nothing to do with cooperation, the past or the future — it's living in the present. I think the same is true of most people who write code for money. They have no idea where [their culture came from] — and the Internet was done so well that most people think of it as a natural resource like the Pacific Ocean, rather than something that was man-made. When was the last time a technology with a scale like that was so error-free? The Web, in comparison, is a joke. The Web was done by amateurs.

-- Dr.Dobbs «Interview with Alan Kay»

Lisp Hackers: Peter Seibel

Peter Seibel has helped more people (including me) discover and become user of Lisp as probably noone else in the last decade with his Practical Common Lisp. Dan Weinreb, one of the founders of Symbolics and later Chief Architect at ITA Software, a succesfull Lisp startup sold to Google for around $1B in 2011, wrote, that their method of building a Lisp team was by hiring good developers and giving them PCL for two weeks, after which they could succesfully integrate under the mentorship or their senior Lisp people.

A few years after PCL Peter went on to write another fantastic programming book Coders at Work - here's my summary of it with the social network of Coders :)



Aside from being a writer he was and remains a polyglot programmer, interested in various aspects of our trade, about which he blogs occasionally. His code, presented in PCL, laid the foundation for a wide-spread CL-FAD library, which deals with filenames and directories (as the name implies), and more recently he created a Lisp documentation browser Manifest. Before Lisp Peter had worked a lot on Weblogic Java application server.

He's also active on twitter: @peterseibel

Tell us something interesting about yourself.

I’m a second generation Lisp programmer. My dad discovered Lisp when he was working at Merck in the 80s and ended up doing a big project to simulate a chemical plant in Lisp, taking over from some folks who had already been trying for quite a while using Fortran, and saving the day. Later he went to Bolt Beranek and Newman where he did more Lisp. So I grew up hearing about how great Lisp was and even getting to play around with some graphics programs on a Symbolics Lisp Machine.

I was also a childhood shareholder in Symbolics—I had a little money from some savings account that we had to close when we moved so my parents decided I should try investing. I bought Symbolics because my parents just had. Never saw that money again. As a result, for most of my life I thought my parents were these naive, clueless investors. Later I discovered that around that time they had also invested in Microsoft which, needless to say, they did okay with.

Oh, and something I learned recently: not only was Donald Knuth one of the subjects in my book Coders at Work, but he has read the whole thing himself and liked it. That makes me happy.

What's your job? Tell us about your organization.

A few months ago I started working half-time at Etsy. Etsy is a giant online marketplace for people selling handmade and vintage items and also craft supplies. I’m in the data group where we try to find clever ways to use data to improve the web site and the rest of the business.

Do you use Lisp at work? If yes, how you've made it happen? If not, why?

I always have a SLIME session going in Emacs for quick computations and sometimes I prototype things in Lisp or write code to experiment with different ideas. However, these days I’m as likely to do those things in Python because I can show my co-workers a sketch written in Python and expect them to understand it and I’m not sure I could do that with Lisp. But it makes me sad how slow CPython is compared to a native-compiling CL like SBCL. Usually that doesn’t matter but it is
annoying sometimes mostly because Python has no real excuse. The rest of my work is in some unholy mishmash of Scala, Ruby, Javascript, and PHP.

What brought you to Lisp? What holds you?

As I mentioned, I grew up hearing from my dad about this great language. I actually spent a lot of my early career trying to understand why Lisp wasn’t used more and exploring other languages pretty deeply to see how they were like and unlike Lisp. I played around with Lisp off and on until finally in 2003 I quit the startup I had been at for three years, which wasn’t going anywhere, with a plan to take a year off and really learn Common Lisp. Instead I ended up taking two years off and writing Practical Common Lisp.

At this point I use it for things when it makes sense to do so because I know it pretty well and most of my other language chops are kind of rusty. Though I’m sure my CL chops are rusty too, compared to when I had just finished PCL.

Did you ever develop a theory why Lisp isn’t used more?

Not one that is useful in the sense of helping it to be used more today. Mostly it seems to me to be the result of a series of historical accidents. You could argue that Lisp was too powerful too early and then got disrupted, in the Innovator’s Dilemma sense, by various Worse is Better languages, running on systems that eventually became dominant for perhaps unrelated reasons.

Every Lisper should read The UNIX-HATERS Handbook to better understand the relation between the Lisp and Unix cultures—Lisp is the older culture and back when the UNIX-HATERS Handbook was written, Unix machines were flaky and underpowered and held in the same contempt by Lisp geeks as Windows NT machines would be held by Unix geeks a few decades later. But for a variety of reasons people kept working on Unix and it got better.

And then it was in a better position than the Lisp culture to influence the way personal computing developed once micro computers arrived—while it would be a while before PCs were powerful enough to run a Unix-like OS, early on C was around to be adopted by PC programmers (including at Microsoft) once micros got powerful enough to not have to program everything in assembly. And from there, making things more Unix-like seemed like a good goal. Of course it would have been entirely possible to write a Lisp for even the earliest PCs that probably would have been as performant as the earliest Lisps running on IBM 704s and PDP-1s. My dad, back from his Lisp course at Symbolics, wrote a Lisp in BASIC on our original IBM PC. But by that point Lispers’ idea of Lisp was what ran on powerful Lisp machines, not something that could have run on a PDP-1.

The AI boom and bust played its role as well because after the bust Lisp’s reputation was so tainted by its failure to deliver on the over-promises of the Lisp/AI companies that even many AI researchers disassociated themselves from it. And throughout the 90s various languages adopted some of Lisp’s dynamic features, so folks who gravitated to that style of programming had somewhere else to go and then when the web sprang into prominence, those languages were well positioned to become the glue of the Internet.

That all said, I’m heartened that Lisp continues to not only be used but to attract new programmers. I don’t know if there will ever be a big Lisp revival that brings Lisp back into the mainstream. But even if there were, I’m pretty sure that there would be plenty of old-school Lispers who’d still be dissatisfied with how the revival turned out.

What's the most exciting use of Lisp you had?

I’m pretty proud of the tool chain I’ve built over the years while writing my two books and editing the magazine I tried to start, Code Quarterly. When I first started working on Practical Common Lisp I had some Perl scripts that I used to convert an ad-hoc light-weight text markup language into HTML. But after a little while of that I realized both that Jamie Zawinski was right about regexps and that of course I should be using Lisp if I was writing a book called Practical Common Lisp.

So I implemented a proper parser for a mostly-plain-text language that I uncreatively call Markup and backends that could generate HTML and PDF using cl-typesetting. When I was done writing and Apress wanted me to turn in Word files, I wrote an RTF backend so I could generate RTF files with all the Apress styles applied correctly. An Apress project manager later exclaimed over how “clean” the Word files I had turned had been. For editing Code Quarterly I continued to use Markup and wrote a prose diff tool that is pretty smart about when chunks of text get moved and edited a little bit.

What you dislike the most about Lisp?

I don’t know if “dislike” is the right term because the alternative has its own drawbacks. But I do sometimes miss the security of refactoring with more static checks. For instance, when I programmed in Java, there was nothing better than the feeling of knowing a method was private and therefore I didn’t have to look anywhere but in the one file where the method lived to see everywhere it could possibly be used. And in Common Lisp the possibilities for action at a distance are even worse than in some other dynamic languages because of the loose relation between symbols and the things they name. In practice that’s not actually a huge problem and some implementations provide package locks and so on, but it always makes me feel a bit uneasy to know that if I :use a package and then DEFUN a function with the name of an inherited symbol I’ve changed some code I really didn’t mean to.

From time to time I imagine a language that lets you write constraints on your code in the language yourself—kind of like macros but instead of extending the syntax your compiler understands, they would allow you to extend the set of things you could say about your code that the compiler would then understand. So you could say things like, “this function can only be called from other functions in this file” but also anything else about the static structure of your code. I’m not sure exactly what the API for saying those things would look like but I can imagine it being pretty useful, especially in larger projects with lots of programmers: you could establish certain rules about the overall structure of the system and have the compiler enforce them for you. But then if you want to do a big refactoring you could comment out various rules and move code around just like in a fully dynamic language. That’s just a crazy idea; anyone who’s crazy in the same way should feel free to take it and run with it and see if they get anywhere.

Among software projects you've participated in what's your favorite?

Probably my favorite software I ever wrote was a genetic algorithm I wrote in the two weeks before I started at Weblogic in 1998, in order to build up my Java chops. It played Go and eventually got to the point where it could beat a random player on a 5x5 board pretty much 100% of the time. One of these days I need to rewrite that system in Common Lisp and see if I can work up to a full-size board and tougher opponents than random. (During evolution the critters played against each other to get a Red Queen effect—I just played them against a random player to see how they were doing.)

Describe your workflow, give some productivity tips to fellow programmers

I’m not sure I’m so productive I should be giving anybody tips. When I’m writing new code I tend to work bottom up, building little bits that I can be confident in and then combining. This is obviously easy to do in a pretty informal way in Common Lisp. In other languages unit tests can be useful if you’re writing a bigger system though I’m often working on things for myself that are small enough I can get away with testing less formally. (I’m hopeful that something like Light Table will allow the easy of informal testing with the assurances of more strict testing—I’d love to have a development environment that keeps track of what tests go with what production code and shows them together and runs the appropriate tests automatically when I change the code.)

When I’m trying to understand someone else’s code I tend to find the best way is to refactor or even rewrite it. I start by just formatting it to be the way I like. Then I start changing names that seem unclear or poorly chosen. And then I start mucking with the structure. There’s nothing I like better than discovering a big chunk of dead code I can delete and not have to worry about understanding. Usually when I’m done with that I not only have a piece of code that I think is much better but I also can understand the original. That actually happened recently when I took Edi Weitz’s Hunchentoot web server and started stripping it down to create Toot (a basic web server) and Whistle (a more user friendly server built on top of Toot). In that case I also discarded the need for backward compatibility which allowed me to throw out lots of code. In that case I wasn’t going for a “better” piece of code so much as one that met my specific needs better.

If you had all the time in the world for a Lisp project, what would it be?

I should really get back to hacking on Toot and Whistle. I tried to structure things so that all the Hunchentoot functionality could be put back in a layer built on top of Toot—perhaps I should do that just to test whether my theory was right. On the other hand, I went down this path because the whole Hunchentoot API was too hard for me to understand. So maybe I should be getting Toot and Whistle stable and well-documented enough that someone else can take on the task of providing a Hunchentoot compatibility layer.

I’d also like to play around with my Go playing critters, reimplementing them in Lisp where I could take advantage of having a to-machine-code compiler available at run time.

PCL was the book, that opened the world of Lisp to me. I’ve also greatly enjoyed Coders at Work. So I’m looking forward for the next book you’d like to write. What would it be? :)

My current theory is that I’m going to write a book about statistics for programmers. Whenever I’ve tried to learn about statistics (which I’ve had to do, in earnest, for my new job) I find an impedance mismatch between the way I think and the way statisticians like to explain stuff. But I think if I was writing for programmers, then there are ways I could explain statistics that would be very clear to them at least. And I think there are lots of programmers who’d like to
understand statistics better and may have had difficulties similar to mine.

Discussion on Hacker News

submit