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

Lisp Hackers: Juan José García Ripoll

Juan José García Ripoll is a physicist and the principal developer of Embeddable Common Lisp (ECL), an implementation that compiles to C instead of native code and provides a shared library, so that Lisp programs can be distributed without the Lisp runtime and be embedded in other programs. He also actively contributes to the improvement of ASDF, the foundational system definition facility (one of his posts on the topic).




Juanjo is a representative of a large group of Lisp users - researchers and scientists, who are not professional programmers. Although Lisp is not generally considered on par with specialized research environments, like Matlab or R, it is quite useful in this field, because of its solid mathematical foundation, coupled with truly interactive and robust environment.

Tell us something interesting about yourself.

I do not consider myself to be an interesting character or have interesting hobbies, but my job is quite interesting and unconventional: I work on Quantum Computation, developing new ways of computing using, for instance, superconducting circuits, or arrays of atoms. Actually I find that the fact that human technology has progressed to the point that we can trap and harness individual atoms is pretty cool.

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

I am a physicist and work as a scientist for CSIC, the Spanish Research Council. It is the largest research institution in Spain and my group works on all kind of exotic things related to the implementation of quantum computers.

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

From my description above it might seem that it would be hard to use Lisp for anything, but quite the contrary: 50% of our time is spent doing simulations and programming. Quite interestingly, the programs that we develop are very short-lived. We have a question, write a simulation, get the data, move on. This is the reason why most people in our field use Matlab. I reached Lisp looking for an interactive programming language that was more powerful than Matlab in the fields of expressiveness, extensibility, optimization. That is how I started working on ECL, with the aim of empowering it for numerical simulations. Along the way I got distracted and more interested on the fields of language development.

Despite this I have found room for Lisp in my daily routine, from scripting all the way up to solving actual problems. For instance, in one of our research topics we had to solve huge instances of 3-SAT problems using a very basic algorithm. The fact that Common Lisp comes with bignums reduced the development time to one afternoon and the program we produced was faster than the C++ prototypes we had.

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

My favorite is ECL, but my second favorite was developing for an extinct operating system, OS/2. Back when I was at the university, OS/2 was still alive and I got some interesting projects finished, such as an X-Windows server and the port of Doom to it. It was pretty cool to learn multithreading and GUI development back then and OS/2 was pretty well thought out.

What brought you to Lisp? What holds you?

My job brought me to it, and what keeps me is the possibility of learning a lot about language implementations, compilers and making a tool that is useful for a larger community, including other projects such as Sage. It is a weak link though, and sometimes personal interactions make me question whether this is useful at all.

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

ECL. Really. After one year of development it was awesome to see ECL being able to build and compile itself from scratch for the first time. Also, every time I finish yet another feature, it feels really good. And finally, developing a Common Lisp implementation is a great excuse to learn a lot of things, from the subtleties of the POSIX specification, to the Unicode collation algorithms.

What you dislike the most about Lisp?

The unspecified corners. Multithreading was not in the specification and implementations have evolved in somewhat random ways, with some common denominator and features (process-kill) which are not really well suited for existing operating systems and are nightmare to implement. I also miss a better specification of physical pathnames.

Describe your workflow, give some productivity tips to fellow programmers

Sorry, I am a terribly disorganized developer and ECL users suffer from it. No advice here, hehe.

You are a physicist by main occupation, yet you manage to almost single-handedly support ECL. Why? and How?

Everybody needs some projects in life other than work and this one is a lifelong companion that I would like to see to the end. I had a lot of help from freelance programmers at the beginning and users cooperate with patches and bug reports, and a lot of patience for my mistakes and absences. That helps.

That does not mean I consider the current status an optimal one. I consider it a personal failure the fact that ECL does not have a larger community and a better support base. It still persists the wrong impression that ECL is a lesser implementation, covering a niche (embeddability) and inferior to other implementations which are more lispy in nature. That is not the case: we have sufficiently proven that the underlying core, C, does not prevent any feature from being implemented, performance is improving and stability, well, this is not always optimal, but it has to be blamed to the small size of the developer team, which has scarce resources for testing the code.

submit

Lisp Hackers: Pascal Costanza

Pascal Costanza is a researcher, and an active Common Lisp programmer and community enthusiast:

• he's the maintainer of Closer to Mop library, that provides a common facade to the MOP implementation in different Lisps, and is the basis of some of his more advanced libraries like: ContextL and FilteredFunctions;


• the originator of Common Lisp Document Repository (CDR) project, that collects proposals for improving the language (a la JCP for Java or PEP for Python);


• and the author of a Highly Opinionated Guide to Lisp, which can serve as introductory text for those, who come from other languages. (It was quite a useful text for me, when I started studying Lisp.)

In the interview Pascal shares a lot if insight into his main topic of interest — programming language design — grounded in his experience with Lisp, Java, C++ and other languages.

Tell us something interesting about yourself.

I share a birthday with Sylvester Stallone and George W. Bush. I have been a DJ for goth and industrial music in the Bonn/Cologne area in Germany in the past. I once played a gay Roman emperor in comedic theatre play. I played a few live shows with a band called "Donner über Bonn" ("Thunder over Bonn"). My first rock concert I ever attended was Propaganda in Cologne in 1985. The first programming language I really liked was Oberon. I often try to hide pop culture references in my scientific work, and I wonder if anybody ever notices. My first 7" single was "Major Tom" by Peter Schilling, my first 12" single was "IOU" by Freeez, my first vinyl album was "Die Mensch-Maschine" by Kraftwerk, and my first CD album was "Slave to the Rhythm" by Grace Jones. I don't remember what my first CD single was.

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

I currently work for Intel, a company whose primary focus is on producing CPUs, but that also does business in a lot of other hardware and software areas. (Unfortunately, Intel's legal department requires me to mention that the views expressed in this interview are my own, and not those of my employer.)

I work in a project that focuses on exascale computing, that is, high-performance computers with millions of cores that will be on the market by the end of the decade, if everything goes well. I am particularly involved in developing a scheduler for parallel programs that can survive hardware failures, which due to the enormous scale of such machines cannot be solved by hardware alone anymore, but also need to be dealt with at the software level. The scheduler is based on Charlotte Herzeel's PhD thesis, and you can find more information about it in a paper about her work and at http://www.exascience.com/cobra/.

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

At Intel, I do all software prototyping in Lisp. The scheduler I mentioned above is completely developed and tested in Lisp, before we port it to C++, so that other people in the same project and outside can use it as well. It didn't require a major effort to convince anybody to do this in Lisp. It is actually quite common in the high-performance computing world that solutions are first prototyped in a more dynamic and flexible language, before they are ported to what is considered a "production" language. Other languages that are used in our project are, for example, MATLAB, Python and Lua. (Convincing people to use Lisp beyond prototyping would probably be much harder, though.)

The implementation we use for prototyping is LispWorks, which is really excellent. It provides a really complete, well-designed and efficient API for parallel programming, which turns LispWorks into one of the best systems for parallel programming of any language, not just in the Lisp world. The only other system that is more complete that I am aware of is Intel's Threading Building Blocks for C++.

What brought you to Lisp? What holds you?

I have participated in one of the first Feyerabend workshops, organized by Richard Gabriel, one of the main drivers behind the original Common Lisp effort. I have also read his book Patterns of Software around that time. Later we had a small discussion in the patterns discussion mailing list. He tried to promote Lisp as a language that has the "quality without a name", and I made some cursory remarks about Lisp's unnecessarily complicated syntax, just like anybody else who doesn't get it yet.

To me, the most important comment he made in that discussion was: "True, only the creatively intelligent can prosper in the Lisp world." The arrogance I perceived in that comment annoyed me so much that it made me want to learn Lisp seriously, just to prove him wrong and show him that Lisp is not as great as he thought it is. As they say, the rest is history.

I actually dabbled a little bit in Lisp much earlier, trying out a dialect called XLisp on an Atari XL computer at the end of the 80's. Unfortunately, it took too long to start up XLisp, and there was not enough RAM left to do anything interesting beyond toy examples, plus I was probably not smart enough yet to really get it. I was just generally curious about programming languages. For example, I also remember trying out some Prolog dialect on my Atari XL.

In the end, Lisp won me over because it turns out that it is the mother of all languages. You can bend it and turn it into whatever language you want, from the most flexible and reflective interpreted scripting language to the most efficient and static compiled production system. For example, the scheduler mentioned above easily gets in the range of equivalent C/C++-based schedulers (like Cilk+, TBB, or OpenMP, for example), typically only a factor of 1.5 away for typical benchmarks, sometimes even better. On the other hand, ContextL uses the reflective features of the CLOS Metaobject Protocol to bend the generic function dispatch in really extreme ways. I am not aware of any other programming language that covers such a broad spectrum of potential uses.

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

When I decided to make a serious attempt at learning Common Lisp, I was looking for a project that would be large enough to prove to myself that it is actually possible to use it for serious projects, but that would also be manageable in a reasonable amount of time. At that time, I was intimately familiar with the Java Virtual Machine architecture, because I had developed compilers for Java language extensions as part of my Diploma and PhD theses. So I decided to implement a Java Virtual Machine in Common Lisp - under normal circumstances, I wouldn't have dared to do this, because this is quite a complex undertaking, but I had read in several places that Lisp would be suitable for projects that you would normally not dare to do otherwise, so I thought I would give it a try. Over the course of 8 weeks, with something like 2 hours per day, or so (because I was still doing other stuff during the day), I was able to get a first prototype that would execute a simple "Hello, World!" program. On top of that, it was a portable (!) just-in-time compiler: It loaded the bytecode from a classfile, translated it into s-expressions that resemble the bytecodes, and then just called Common Lisp's compile function to compile those s-expressions, relying on macro and function definitions for realizing these "bytecodes as s-expressions." I was really impressed that this was all so easy to do.

The real moment of revelation was this: to make sure to reuse as many of the built-in Common Lisp features as possible, I actually translated Java classes into CLOS classes, and Java methods into CLOS methods. Java's super calls posed a problem, because it was not straightforward to handle super calls with plain call-next-method calls. Then I discovered user-defined method combinations, which seemed like the right way to solve this issue, but I was still stuck for a while. Until I discovered that moving a backquote and a corresponding unquote around actually finally fixed everything. That was a true Eureka moment: In every other programming language that I am aware of, all the problems I encountered until that stage would have required a dozen redesigns, and several attempts to start the implementation completely from scratch, until I would have found the right way to get everything in the right places. But Common Lisp is so flexible that at every stage in your development, you can tweak and twist things left and right, but in the end you still get a convincing, clean, and efficient design. As far as I can tell, this is not possible in any other language (not even Scheme).

What you dislike the most about Lisp?

There is not much to dislike about Lisp itself. There are some technical details here and there, some minor inconsistencies, but nothing that cannot be fixed in easy and straightforward ways. From a purely conceptual point of view, Common Lisp is one, if not the most complete and best integrated programming language that covers a lot of ground. Some rough edges are just to be expected, because nothing is ever perfect.

What concerns me a lot more is that there is too much unwarranted arrogance in the Lisp community. I don't know exactly where this comes from, but some Lispers seem to believe, just because they understand some Lisp concepts, that they are much smarter than anybody else in the universe. What they are forgetting is that computer science as a discipline is very, very young. In one or two hundred years from now, Lisp concepts will be common knowledge, just like elementary algebra. There is no reason to be arrogant just because you know that the earth is round, even if most other people still believe that it is flat.

Describe your workflow, give some productivity tips to fellow programmers.

I strongly believe that the one thing that made me most productive as a programmer is my interest in doing some form of art. I used to spend a lot of time making my own music, both by myself with synthesizers and computers, as well as in bands. I also was an actor in an amateur theater group. Art gives you a sense of making parts (notes, chords, melodies, rhythms, or acts, characters, plot lines) relate to each other and form a coherent whole. It also makes you aware that there is an inner view on a piece of music or a play, as seen by the artist, but also an outer view, as seen or heard by an audience, and if you want to make good art, you need to be able to build a bridge between those two parts.

Programming is exactly the same: you need to make parts (functions, data structures, algorithms) relate to each other, and you need to bridge the inner view (as seen by the designer and implementer) and the outer view (as seen by the user of a library or the end user of the final software).

The important aspect here is that you need to be able to change perspectives a lot, and shift between the local, detailed view, the global, architectural view, and the many different levels of a layered design. This is especially important when it comes to designs that incorporate meta-programming techniques and reflective approaches, but also already for simpler designs.

Like in art, the concrete workflow and the concrete tools that work best vary a lot for different people. It's also a good idea to just play around with ideas, expecting that most of them will turn out useless and need to be thrown away. Artists do this all the time. Artificial, seemingly nonsensical rules and restrictions can be especially enlightening (use only effect-free functions; use only functions that receive exactly one argument, not more, not less; make every function pass around an additional environment; use only classes with exactly two slots; etc., etc.), and then try to build larger programs strictly following such rules - this will make your mind a lot more flexible and train you to see new potential solutions that you wouldn't see otherwise.

(I actually believe that this is what makes fans of static typing so excited: Static type systems always impose some artificial restrictions on your programs, and enforce them to the extent that programs that violate these rules are rejected. If you then program in such a statically typed programming language, you will indeed have some interesting insights and see new solutions that you would otherwise miss. However, the category error that fans of static typing often seem to make is that they ascribe the results to the static type system, and therefore usually get stuck with one particular set or kinds of rules.)

Apart from that, I believe that LispWorks is a really good development environment.

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

I don't know how to answer that. At any point in time, I'm always most excited by the one I'm currently working on. So far, I am quite proud of ContextL and the ClassFilters project for Java, because they are or were both used in one way or the other in "real" applications. Closer to MOP is a favorite project of mine, because it makes me feel like I can give something back to the Lisp community from which I otherwise benefit so much. But this doesn't mean I dislike anything else I have done in the past.

One of your papers, "Reflection for the Masses", researches the ideas behind 3-Lisp, "a procedurally reflective dialect of LISP which uses an infinite tower of interpreters". Can you summarize them here?

That paper was actually mostly the work of Charlotte Herzeel, and I was only her sounding board for detailing the ideas in that paper. Reflection is one of the essential concepts that was born out of Lisp. Every program is about something, for example a financial application is about bank accounts, money and interest rates, and a shopping application is about shopping items, shopping carts and payment methods. A program can also be about programs, which turns it into a meta-program. Lisp macros are meta-programs, because they transform pieces of code in the form of s-expressions into other pieces of code. C++ templates are also meta-programs in the same sense. Some meta-programs are about "themselves," and thus become reflective programs.

3-Lisp is "procedurally reflective" in two senses: On the one hand, it allows you to inspect and change the body of procedures (functions). Common Lisp, for example, also gives you that, in the form of function-lambda-expression and compile/eval, among others. On the other hand, 3-Lisp also allows you to inspect and alter the control flow. Scheme, for example, gives you that in the form of call/cc, but in 3-Lisp this is actually part of the eval interface. 3-Lisp goes further than Common Lisp and Scheme combined, in that it provides not only first-class access to function bodies and continuations, but also to lexical environments, always both with facilities to inspect and modify them, and provides a clean and integrated interface to all of these features. Unfortunately, because 3-Lisp goes that far, it cannot be fully compiled but always needs to be able to resort to interpretation, if necessary.

The reason for the requirement to always have an interpreter around is because the eval interface in 3-Lisp is so flexible that you can run programs inside an eval invocation that in turn can inspect and change (!) the environment in which eval runs, and can then invoke further evals in those changed environments, to arbitrary levels of recursive invocations of eval. These recursive invocations of eval build what is called a reflective tower, where every level in the tower is conceptually an interpreter being executed by an interpreter one level up in the tower of interpreters. The amazing thing about 3-Lisp is that an implementation of 3-Lisp can actually collapse the tower into one level of interpretation, and arrange that one interpreter in such a way that the several different levels of interpretations are only simulated, so the tower is actually just an "illusion" created by the 3-Lisp implementation.

This may all sound quite esoteric, but is actually practically relevant, because there is strong evidence that all meta-programming approaches eventually need such towers, and some ad-hoc way to collapse the towers. For example, you can find the tower in Racket's and R6RS's macro systems, where they are explicitly mentioned; in Common Lisp's macros, where eval-when is used to control which part of the tower sees which definitions; in the CLOS Metaobject Protocol, where the generic function dispatch can be influenced by other generic functions, which can in turn be modified by some meta-classes at a higher level; in the template metaprogramming system of C++, where "concepts" were devised for C++11 (and rejected) to introduce a type system for the template interpreter; and so on, and so on. If you understand the concept of a reflective tower better, you can also better understand what is behind these other meta-programming approaches, and how some of their sometimes confusing semantic difficulties can be resolved.

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

I have some ideas how to design reflection differently for a Lisp dialect, which I believe has not been tried before. If I had all the time in the world, I would try to do that. I also have many other ideas, so I'm not sure if I would be able to stick to a single one.

Anything else I forgot to ask?

I think one of the most underrated and most underused Lisp dialects is ISLISP. I think people should take a much closer look at it, and should consider to use it more often. Especially, it would be an excellent basis for a good teaching language.

Discussion on HackerNews submit

Lisp Hackers: Marijn Haverbeke

The next person in our series is Marijn Haverbeke, who's not only the author of several pretty useful Common Lisp libraries (some of which he touches in the interview), but also a succesful JavaScript hacker, winning JS1K contest, and writing a profound book about the language — "Eloquent JavaScript". Besides, he hacks on Mozilla Rust and his own language Hob, not to mention co-authoring a JavaScript-to-Common-Lisp transpiler, writing some games in Scheme, and experimenting with Haskell. In the interview he shares his perspective, based in knowledge and experience with so many different languages.

Tell us something interesting about yourself.

I once thought I wanted to be a Sociologist. Before that, I also once thought that I wanted to become a treasure hunter. And a dinosaur researcher. I ended up a programmer, largely self-taught, and I'm very happy with how things turned out.

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

I'm working free-lance. Currently, I'm doing a lot of work for Mozilla, hacking on their Rust compiler. Rust is a programming language that's supposed to fit the C++ niche, without the insanity of actual C++. If the project works out, and it's going swimmingly so far, Mozilla will try to apply it to writing a next-generation browser, without the constant danger of buffer overrun exploits and threading bugs that comes with C++. True to Mozilla's spirit, all development on Rust is happening in the open, on github.

Another things I'm busy with is my own CodeMirror project, a code editor written in JavaScript. It's not a 'job', really, since it's open-source and no one is paying me to maintain it, but it's grown popular enough to generate a decent amount free-lancing gigs and a small income stream from support contracts.

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

Not currently, beyond that I always have a REPL open in emacs, and switch to it to do quick computations and experiments. I've spent several years doing almost exclusively Lisp (mostly working on AllegroGraph, Franz' RDF database), and it has definitely been somewhat painful to find myself working with non-interactive, macro-less languages again, after being used to the luxuries of Common Lisp and Slime.

What brought you to Lisp? What holds you?

Ten years ago, during my sociology study, I randomly chose a Lisp course in university. I was spending so much time in emacs that I figured I might as well learn more about its scripting language. The course worked through Structure and Interpretation of Computer Programs, using the video lectures from Abelson and Sussman. Having been exposed mostly to Java, C++, and Python before that, the elegance and depth of this material was something of a revelation to me.

My professor for that course, Eduard Hoenkamp, was a real Lisp chauvinist with an MIT background, and properly indoctrinated me with regards to Lisp's glorious superiority. I wrote a text adventure game in Scheme for the end project of the course, my first non-trivial Lisp endeavor. I still have the code. I ended up starting a PhD with this very professor, and though I never finished it, it did provide me with ample opportunity to learn Common Lisp.

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

I think that'd be CL-JavaScript, a JavaScript-to-Common-Lisp transpiler that I wrote together with a friend. It actually handles the whole ECMAScript 3 language and produces programs that run reasonably fast—about on par with the 2009 generation of browser JavaScript engines. This is quite amazing, given that it's less than 4000 lines of code, at least an order of magnitude smaller than those engines. The Lisp compiler handles most of the optimization for us. (I should point out that the browser JS engines have a much higher speed of compilation, which is a necessity for handling web content.)

What you dislike the most about Lisp?

I must say that the lack of static typing really gets in the way on larger projects. Being able to confidently change datatypes and function signatures, knowing that the compiler will point out most inconsistencies that you introduce, is something that I've really come to appreciate after working with Rust and Haskell. Test coverage helps, of course, but I'm not a very diligent test writer, and tend to feel that type signatures are easier to maintain than an exhaustive test suite.

Describe your workflow, give some productivity tips to fellow programmers.

My approach to writing software is embarrassingly unstructured. I'm not sure I can claim to have something that merits the term 'workflow'. One thing that is very important for me, and that, had I figured it out earlier, would probably have saved some past projects from dying, is to never have a system in a half-refactored, non-functional state for longer than an hour or so. A lot of momentum and motivation comes from having a working program in front of me. This sometimes means I have to split up big changes in a number of more indirect, trivial steps, and resist the temptation to start hammering out my big change in one go (which, even when seems straightforward in my head, will always hit some complications during implementation).

Also, really learning git in depth has had a big influence on how I code. Once you really understand that changes (if you bother to commit often and with care) can be reverted and picked at will, and that branches are cheap and easy to create and maintain, you start to see a codebase differently. I often take multiple shots at making a tricky change — if it feels like my first approach is not working out, I simply commit it, back up, and start again, knowing that if the new approach doesn't work out, I can simply flip back to the old one again. Knowing that this is theoretically possible is not enough—you need to have actually done it, often, to start applying it properly.

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

Postmodern, the PostgreSQL client, was my first non-trivial open-source project, and the first piece of actually useful software that I designed and executed on my own. I was extremely proud when I got it to work the way I wanted (modular, fast), and meticulously wrote out a long set of docs (copying Edi Weitz's style). Seeing people actually use it (and even write good things about it!) really drove home for me the fact that it is worthwhile and rewarding to package up the stuff I write, and share it.

The community involvement in Postmodern, though always low-volume, has also been awesome. Most bug reports came with a patch, or at least an informed view of the problem and useful diagnostic information. This in sharp contrast with the JavaScript community, where of course great contributors also occur, but one has to deal with a lot of noise and lazy bug reporting.

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

I am working on my own programming language, Hob, which tries to combine the virtues of Lisp and ML. This is a huge project, and unfortunately it's moving forward only slowly. If I didn't have financial constraints, I'd spend a year (or two) finishing it. Its 'bootstrap compiler' (the compiler that will compile the first self-hosting compiler) is in the process of being written in Common Lisp. The writing that I currently have online about it is quite old and out of date. I just spent a week rewriting the compiler from scratch, moving the language to a completely regular syntax—think s-expressions, though Hob looks somewhat different. My work on Rust has convinced me that, even with all the good will in the world, you can't bolt macros onto a classical language with a non-regular syntax without making them very painful to write (and use!). They have to be part of the design from the start.

You've been actively using Common Lisp and JavaScript. When you use JavaScript, what do you miss the most from CL? What do you miss from JavaScript, when you're in Lisp land?

The greatest thing about Common Lisp is that the standardization process drew from years and years of experience and organic growth. This makes the language feel singularly solid and practical. Most languages feel immature compared to CL. I suspect that this is not just age, but also the fact that Lisp allows users to extend the language to an unprecedented degree, which allows for much more experimentation, and thus faster growth and invention.

The great thing about JavaScript is that it has so few concepts. It manages to strike a balance between being dumbed-down enough to be easy to grasp, which has allowed it to become as widespread as it currently is, and still being a more-or-less decent lambda language, which makes it scale up to complex programs relatively well. It is on its way to become a lingua franca of scripting, which Common Lisp will never be, because it is much more demanding of its programmers—they need to understand a lot more concepts.

And here is the Hacker News discussion. submit

Lisp Hackers: Christophe Rhodes

Next in our series of interviews with inspiring lispers is a conversation with SBCL's principal maintainer Christophe Rhodes. He was among the first two people to join the project, after it was solely developed for more than a year by William Newman. And he is, probably, the most "stable" contributor, still remaining very active in the community, after more than a decade. What fascinates me personally about him, is the aura of a profoundly creative mind, fiddling with reality in interesting and unexpected ways.

Tell us something interesting about yourself.

I'm a singer, specializing in performance (admittedly somewhat rare at the moment) of unaccompanied music of the European Renaissance. My next concert is Brumel's "Earthquake Mass" with the vocal ensemble De Profundis. I did my doctoral research a few doors down from Stephen Hawking. AndI was a cast member on "Una Stravaganza dei Medici", a reconstruction of the Florentine festivities for the marriage of Ferdinand de Medici and Christine of Lorraine - which means that there's at least some chance I have an Erdős-Bacon number.

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

Oh, well, that's a bit complicated! :-) Most of my time at the moment is spent with Teclo Networks, a Lisp-flavoured startup which is bringing reliability and usability to mobile broadband. I'm on leave of absence to pursue this from Goldsmiths, University of London, where I am a lecturer in Computing, responsible for undergraduate teaching, postgraduate supervision and independent research.

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

I do. I should say that I'm no longer, if I ever was, a programmer by trade; most of my work at Teclo is not writing code, but when I do it is in C, R or Common Lisp. Working in a Lisp-flavoured startup (I'm not the most famous Lisp programmer in the company, and quite some way from being the best...) has made Lisp a natural tool to use when it's appropriate; while it might be a bit of a shame that Lisp is not used exclusively, the balance of idealism and pragmatism is pretty good, and it's fairly satisfying to know that the high-performance network element that we ship has Lisp code controlling its operation.

I wouldn't make an argument that C is a Lisp by any stretch, but I've popped up at a couple of events in the last year to argue that R has some claims to being a Lisp; it has conditions, handlers, restarts, generic functions, macros operating on parse trees... and a SWANK backend.

Another part of what I do is write documents, both for Teclo and for Goldsmiths. I have in the last couple of years fallen in love with org-mode and in particular with "reproducible research", or living documents; the ability to have executable sections of code for generating results, which can then themselves be further analysed by other bits of code — in other languages, if that's appropriate — and the whole exported as a document typeset to what I consider to be high-quality standards. The fact that there is also acceptable-quality web output from the exact same process is gravy.

What brought you to Lisp? What holds you?

Two seminal moments on my road to Lisp: the first was, as an undergraduate, getting a job in the summer of 1997 to work on simulating fluid dynamics in the context of galaxy formation, to assist in trying to understand how the spiral arm structures form. I'd being told "here is K&R, here is USENET, here is XEmacs, here is Tcl; in five weeks let's see what you've come up with" — I distinctly remember reading comp.lang.lisp and a "Lisp is slow" thread, with active participants combating the troll with disassembly.

The second, a few years later, was wandering into the #lisp IRC channel on openprojects, to find an almost-empty channel, about 10-20 participants; one of whom was there twice (dan_b and dan`b), using the channel to paste bits of alpha assembly between his laptop and his desktop, in his efforts to get SBCL on alpha working.

As for what keeps me, well, when what I have to do is solve problems that no language has built-in libraries for (scalable audio similarity detection, say, or musical structure inference) then I want to be working in a language where I can focus on the problem itself, rather than the detail of that language — and for me, Lisp permits that kind of separation of concerns, given its easy support for DSL and embedded language generation, protocols, and the ability to run partial programs.

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

I enjoyed most working on an editor for lute tablature, I think. Partly because it was a chance to learn about things (parsing, CLIM, user interfaces) that I hadn't really thought about before. Partly because of the feeling of being able to build up incrementally and rapidly from a very simple prototype to deliver something which was actually useful; and partly because it was also interesting to learn about the problem domain. Gsharp (G#), the score editor largely designed by Robert Strandh, is an editor for what you might call "common practice" notation: five lines in a staff; dots and lines to indicate pitch (by height) and duration (by glyph) of notes. In my research group at Goldsmiths, though, we have a lutenist (a player of the lute) who had a research project on cataloguing and transcribing a particular repertoire of 16th-century lute music, which was notated in "tablature": six lines, one per string of the lute; letter or number glyphs on each line to indicate finger position; and glyphs above the staff to indicate duration.

The point about this was that when I first came on the scene the project had a truly awful workflow, because they had a batch renderer from the textual format to encode this music to something visual. This made the process of encoding painful, in particular for the error correction phase: it was fairly easy to find an error in the visual rendering, but to go from there to the text corresponding to it was painful. So I wrote a little CLIM app with an editor buffer and a display; the display was a rendering of the "Tabcode" in the editor buffer, and each glyph in it was associated with a text cursor position, so that you could click on the display and have the editor cursor warp to the Tabcode corresponding to the glyph. This was a productivity win for the project.

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

I don't get easily excited by technology. So for me, what was exciting was seeing a community of users and developers grow around SBCL — in particular, working with extremely focused and motivated individuals on improving the system, subject to all sorts of constraints, not least those imposed by real-world uses (including the QPX poster-child of ITA Software).

SBCL contributors seem to be a very active, closely-knit, and united community. How did that happen? Maybe you could share some insight into the history of the project. Also what were the factors, that determined its success?

I think part of SBCL's success as a community was the finding of like minds — which came about partly because it started off as a project when access to information channels was growing, but also partly because there were some explicit principles laid down: Bill Newman made it very clear that he was aiming for something maintainable, and also taught by example the meaning of maintainability. In the SBCL source distribution, there are over 100 lines of textual detail describing his ideas about what he was aiming for, and although it's nothing like an explicit charter which every SBCL developer (or user!) has to sign up to, it's nevertheless a useful indication of a direction to drive in. Both detailed and motivated enough that even a graduate student with no software development experience could understand that there were tradeoffs involved, and someone had thought hard about which side of the tradeoffs they wanted to be. I'd also point out some of Bill's advodiary entries of the time, including http://www.advogato.org/person/wnewman/diary/6.html and http://www.advogato.org/person/wnewman/diary/9.html, which perhaps illustrate that he was thinking about this kind of software maintenance all the time. ("To foil the maintenance programmer..." :-)

I think this is particularly important when the bulk of the work is done by volunteers; it helps to keep focus (I've written before about how software is only sustainable if it can stay alive in the minds of its developers).

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

There's lots that I'd like to do, both hacking on Lisp itself and things I'd like to explore, for which I'm likely to reach for Lisp first. I'd also like to get more fluent with emacs lisp, enough to be able to quickly write the user interfaces I would like to use to various bits of software that I use every day.

submit

Lisp Hackers: Edi Weitz

The first post of the series got some very good responses, so I'm continuing it with another very obvious candidate — Edi Weitz. His vast contributions to open source Lisp, made during the last decade, collectively known as Ediware, include the indispensable regex library CL-PPCRE, written on a bet in Hamburg café, and a whole stack of web-related libraries with the most widely used Lisp application server Hunchentoot and HTTP client Drakma. Together with Arthur Lemmens he also co-organizes European Common Lisp Meeting. And that's, surely, not all...

Tell us something interesting about yourself.

Well, I'll leave it to someone else to tell you what's interesting about me. I'll rather tell you what I find interesting in addition to Common Lisp: I collect photo books and I'm doing a bit of photography myself. I like to listen to the music of Frank Zappa and to Jazz. I read a lot. I'm interested in mathematics, especially in set theory.

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

I'm a professor for mathematics and computer science at the University of Applied Sciences in Hamburg. I started this job in September 2011.

Before that, I was a freelance hacker for about 13 years.

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

In my new job, I've been using CL in my math lectures a couple of times and will continue to do so.

In my old job, I've been using CL exclusively for the last six or seven years. As I was working freelance, this was kind of easy — I either had projects where the customer didn't care about the programming language that I used as long as I got the job done, or I was hired specifically for my CL skills.

What brought you to Lisp? What holds you?

I came to Lisp via Emacs Lisp in 1999 or so. What got me hooked was the wonderful book "Writing GNU Emacs Extensions" by Bob Glickstein. It opened my mind for the beauty of the Lisp language family — something I had missed the first time I had encountered Lisp (in university, a few years earlier). The two CL books by Paul Graham and Norvig's PAIP then paved the way for Common Lisp.

What holds me is that I haven't found a better programming language so far — and I don't expect to find one very soon.

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

I don't know if "exciting" is the right word, but it makes me happy that so many people use "The Regex Coach" and like it. I stopped keeping track, but there must have been at least half a million downloads since 2003.

I'm also kind of proud that some of my open source libraries are used by various commercial and research projects around the world.

But probably the most awe-inspiring encounters I had with Lisp were the few occasions when I played around with Genera or watched someone else using it. I think this OS really was a work of art.

What you dislike the most about Lisp?

There's nothing I really dislike about Common Lisp. There are a few warts here and there, but so far I've found nothing that was serious enough to prevent me from being productive.

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

Working on the Windows port of Piano — an extremely impressive application which has been around for almost 20 years and has been used by almost every aircraft manufacturer in the world. Dimitri Simos, Piano's main author, has been the most enjoyable client I've worked with so far.

Describe your workflow, give some productivity tips to fellow programmers.

I usually just start up the LispWorks IDE and hack away. The best productivity tip I can give is to stick with one implementation and IDE and to invest a lot of time to really learn how to use it — including all the implementation-specific goodies like debuggers, inspectors, steppers, browsers, and so on.

Ediware became hugely popular (by Lisp standards), and with this popularity came a lot of work and responsibility. You seem to have mostly handed over supporting it to Hans Hübner. What's up next for you in the land of programming and Lisp in particular?

I'm planning to give a lecture about the use of AI techniques in games in the next year and I might use some Lisp there. I might also — as a sideline — resume my CL consulting work sooner or later. I don't expect to publish new open source code in the near future, though.

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

When I was still working as a hacker, I always dreamt of finding someone to pay me for working on an open-source CLOS object store — written in pure Common Lisp, OS-independent, portable, not relying on third-party software, fast, reliable, thread-safe, well-documented, etc.

submit

Lisp Hackers: Zach Beane

I'm starting a series of interviews with lispers, who inspire me. Lisp community includes a lot of amazing programmers, who's thoughts, I believe, deserve more prominence and recognition, than they usually enjoy. Besides, unlike many other languages, lisp users span several generations of programmers: there are a lot of people, who'd made great contributions, but have since moved on. I hope to have some of them in this series as well.

And the candidate for the first interview was obvious to me. Zach Beane is the uniting link of the whole community. The creator of Quicklisp and a number of useful open-source libraries, like Vecto and ZS3, he is also always active on #lisp irc channel answering questions, as well as keeping a blog, where he shares interesting Lisp news, and supporting Planet Lisp blog aggregator. And that's not all...

Tell us something interesting about yourself.

I live in Maine and enjoy hacking Common Lisp projects for fun and profit.

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

I work at a small telephone and Internet company.

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

I currently use Lisp to analyze some large data files we get from vendors and partners and produce reports. I've recently used Lisp to produce KML files for Google earth visualization of some internal data. I use stuff like cl-ppcre, drakma, postmodern, cl-mssql, cxml, and more to gather data from various systems when preparing reports. The growing library ecosystem has made it really easy to get stuff done.

Lisp is accepted because I can produce useful stuff pretty quickly with it. It's a small company with a small team so there isn't a bureaucracy to fight to use something non-standard. Does the tool work? Is the result useful? Then there's no problem.

In some cases, where it isn't a good fit for the final product, I use Lisp to prototype ideas before writing a final thing in some other language, e.g. C or Perl. But I even use CL to generate data and code in other languages, so it's still in the mix, still a part of my workflow.

What brought you to Lisp? What holds you?

Paul Graham's Beating the Averages describes a really exciting way to use an uncommon tool to great advantage. That got me interested in how I could do the same thing. I started off with some stuff in Scheme because I thought CL was old and crufty and gross, but when I started using SBCL I found it was a great, practical tool, and I never stopped using CL after that.

I continue to use CL because it has a great mix of features (object system, first-class functions, fast compiled code, multiple implementations, a fantastic standard, etc, etc) and it works well in my favorite working environment, Emacs on Linux. I feel like I know it well and I can see quickly how to use it to explore and solve new problems.

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

Making graphics with Lisp for wigflip.com. It's always fun to have an idea about some kind of visual toy and then tinker with it until it's right.

It's also fun to do something fast. A few years ago I got a project to fill out some PDF forms automatically. The project started with a few days scheduled to research third-party solutions, but in those few days I had a working prototype that used CL-PDF and CLSQL.

What you dislike the most about Lisp?

There are a lot of negative perceptions about Common Lisp that are reinforced by current and former Common Lisp users. I can accept that CL is not for everyone, but some of the criticism is just years (sometimes decades) of moaning and nitpicking about decisions made in the distant past that are not really up for review right now. I wish the people who are vocally, chronically dissatisfied with CL would go off and do their own thing and stop bothering people that are happy with Common Lisp.

There are some remarkable trolls that like to pick on CL, but they're not usually taken seriously by anyone, but "insiders" who complain about CL are perceived to be giving some sort of genuine insight. It's very annoying.

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

Quicklisp has been very rewarding. There's a lot of positive feedback from people who feel it really helped them use CL more easily. More generally, the whole CL ecosystem has been a lot of fun. I enjoy trying new libraries, sending feedback and bug reports, helping people get started, and all that stuff. Common Lisp has a lot of smart, helpful, friendly people who share a lot of knowledge, and I feel lucky to get to learn from them and to try to share what I know, too.

Describe your workflow, give some productivity tips to fellow programmers.

For typical projects I feel like I'm building more tools into my REPL workbench. I don't write scripts that I call from the command line, I write functions that I call from the REPL, and use the slime and Emacs environment to create and interact with data, whether it's data from a file, from a computation, from the web, a database, etc.

I find it really helps to have small, focused functions that are easy to follow and that do one thing and do it well. The fine granularity of testing, tracing, intermediate values, etc. can help wire together a very useful set of behaviors from a small core of simple functions.

Some productivity ideas...

Knock the rough edges off your working environment. Write code to automate stuff. Make it easy to repetitively do complicated but boring stuff. For example, I used to be afraid of the hassle of making new releases of my projects, but recently wrote a CL program that does everything for me, from PGP-signing the tarballs to uploading them along with the documentation to my website. Now I don't care if I make ten project releases in a day, it's just a few function calls.

Customize your environment to make it comfortable. Make it easy to look up info in the hyperspec or in other documentation sources. Make it easy to create new projects. I use quickproject a lot for that, but I also have some Emacs templates that put some boilerplate into my files automatically. Make a program do your work for you.

How did quicklisp change your life? What are current plans for its development?

I can get up and running in a new environment very quickly now. Before Quicklisp, I could usually build up a set of libraries that were comfortable and useful, but it could be a hassle to move them from computer to computer, or to make sure they were up-to-date. Now I just use Quicklisp and don't worry about it.

As Quicklisp maintainer, it's really helped me see where some people are coming from when they want to try Common Lisp. It's a totally different mindset than what I'm used to. I think there's room for some documentation or tutorial on the system-oriented, REPL-workbench style of Common Lisp development that I like to use.

I want to write more documentation for Quicklisp, particularly how users can publish their own software for it or customize it via its internal protocols.

I also want to gather and share documentation for all Quicklisp-loadable projects, so there can be a single place to learn what a given project does, and get access to all its documentation.

I'd also like to make it easy for people to share feedback about their experiences with a project, so you could decide if it's likely to fit your needs. Something like the feedback you see for products on Amazon, but for Lisp libraries.

Anything else?

Common Lisp is a great system that rewards in-depth study.

P.S. Xach gave a talk about Quicklisp at the last ECLM, and I think his motto for Lisp development, he presented there, is really worth sharing and following :)

PPS. And here is the Hacker News discussion. submit