Lisp Hackers: Vladimir Sedach

Vladimir Sedach is an active open-source Common Lisp developer and proponent, as well as a computing philosopher to some extent. At his carcaddar blog he writes about decentralized social networks, forgotten bits of computer history and, surely, Lisp. He is the maintainer or originator of a few open-source libraries like parenscript and Eager-Future2, and works on Vacietis C-to-Lisp compiler, which he describes in more detail in the interview. Together with Andrey Moskvitin they were the driving force behind 2012 cliki update effort (see cliki2).

Tell us something interesting about yourself.

In 2012 my best friend and I rode our bicycles across the USA.

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

Right now I work at ZestFinance in Hollywood. We're a relatively new company that's helping the underbanked receive access to credit on more reasonable terms than otherwise obtainable, by using machine learning. The only thing bad about my job is that I get so focused on programming at work that I don't have any desire to hack on Free Software projects when I come home, so a lot of my own projects are currently badly neglected.

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

I've used Lisp for new commercial projects where people trust me with the technology choices. I've also come in to work on existing Lisp projects. I have used Lisp for one-off tasks at "non-Lisp" companies, but I've never started a Lisp project at a company that wasn't using Lisp already. Most computer programmers tend to make technical decisions based on cliches they read about on the Internet, and unfortunately I don't know the cure for being dumb.

What brought you to Lisp? What holds you?

As a teenager I got interested in computer graphics, and came across this really cool 3d graphics program called Mirai from Nichimen Graphics. Mirai was written in Common Lisp, and I read more about Lisp in the Slashdot interview with Kent Pitman, and started reading SICP based on Kent's recommendation. By the second chapter computer programming had finally made sense to me, and by the third I had decided to study mathematics in university.

As an aside, Mirai is directly descended from the S-Graphics software from Symbolics. Not many people know this, but Symbolics was actually the second producer of commercially available 3d computer animation software (the first was Wavefront). S-Graphics was a complete modeling, animation, and painting system, and it was all written in Lisp in the mid 1980s.

Common Lisp is still the best programming language I've come across. There is the feeling of freedom. No one is telling you what patterns or types to use. You can always just write code in a way that is most appropriate for what you're currently doing.

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

Working with Daniel Gackle on Skysheet. We did some very awesome things with Parenscript.

What you dislike the most about Lisp?

No one has yet invented a good way to write "one-liners" in Lisp. I would love to replace my Unix shell with a Lisp REPL someday.

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

Vacietis, for the sheer amount of hacks per line of code, and for the "I proved them wrong" factor. It was during the development of Vacietis that I came up with my current programming philosophy: "when stuck, do the stupidest thing possible"

Tell us about Vacietis: your vision for it, the project's progress and roadmap, what's lacking?..

Vacietis was originally intended to be a translator for a subset of C code to Common Lisp. I discussed the idea for Vacietis a few times online before starting to code, and people generally thought it wouldn't be doable. Scott Burson, who wrote the Zeta-C compiler for Lisp Machines in the 1980s, told me it would take at least a year of full-time of work.

As I worked on Vacietis, I realized that adding more and more of the "advanced" C functionality was actually easy. First came the C preprocessor (which is implemented as part of the Common Lisp readtable that also parses the C code), then large patches of the C standard library, and then one day Brit Butler came along and sent me a one-page patch that actually used Vacietis as a stand-alone C compiler! I hadn't even realized the project had gotten to that phase. The compiler comes as the "vacietis.vcc" ASDF system as part of Vacietis.

Some big things that need to be done are struct call-by-value, pointer scaling, arguments to main(), some libc stuff, setjmp, and making VCC produce linkable Lisp "object" files (fasls) for the different implementations. I would also like to change the pointer representation to be a fixnum offset into a sparse array (right now pointers are represented by structures that look like <offset, array>).

Overall, I am amazed by how much progress Vacietis has made given how little time I spent on it. I am now convinced that Common Lisp is mostly a superset of C, and have a newfound appreciation for gotos and PROG.

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

A single-address space Common Lisp operating system based on capabilities (Jonathan Rees wrote a dissertation on doing this in Scheme in 1995) and a virtualized package system. I really like Azul Systems' hack of using the EPT/RVI virtualized page tables as a hardware read barrier for real-time garbage collection, and with a single-address space operating system I think you can do the same thing on hardware with a regular MMU.

If you follow the steps of the Viewpoints Research Institute's Fundamental New Computer Technologies project and keep the system as simple as possible, it should be a surmountable amount of work to realize a somewhat working system.

Vacietis is actually the first step in the Common Lisp operating system project. I'd like to have a C runtime onto which I can port hardware drivers from OpenBSD with the minimal amount of hand coding. The way hardware drivers are written in OpenBSD (a set of patterns it borrows from NetBSD, where they originated and are colloquially known as "bus_dma") is very pleasant. Theo de Raadt was also the first well-known Free Software operating system developer to take a position against binary hardware drivers, and I respect him tremendously for that. Linus Torvalds doesn't care, and as a result it is now impossible to get drivers for any of your ARM devices, even though 99% of them run Linux. OpenBSD will continue to have great, stable Free Software device drivers that are easily portable for different hardware architectures and to the other BSD-derived operating systems. I hope OpenBSD's model of Free Software hardware drivers catches on more widely.

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

I tend to design software systems in advance only at the level of the domain. I find that programmers who try to come up with APIs or draw class diagrams ahead of starting to code tend to write very poor code.

I rely heavily on interactive programming for doing mundane tasks, and since most programming time is spent dealing with mundane things, I spend most of my time in the REPL. Fortunately the Common Lisp REPL is the best programming environment I have come across. Things like the Rails console don't even come close. The only comparable environment is the Unix shell.

It's also very easy to turn Common Lisp REPL code into unit tests, which I tend to do a lot. That is something that's very hard to do with object-oriented code, which is why idiotic things like dependency injection and Test-Driven Development have to be invented.

For difficult problems, it's always better to step back from the keyboard and just think about your code. Hacking around in the debugger is usually a waste of time (the only exception is when you're having data structure issues, but then technically you're in the object inspector). I mostly tend to debug with print statements.

The best productivity tip I've come across is the "Seinfeld technique" that I learned about from reading Hacker News. It involves doing something, no matter how small, on your project every single consecutive day, without any gaps or interruptions. Apparently Jerry Sienfeld uses a big calendar and tries to mark up large "runs" of consecutive days on it. That really keeps you focused.

One thing I try to focus on in my code is giving unambiguous, unique (ie, easily grep-able) names to symbols. That makes it easy to go back to old code and quickly figure out what is going on. Common words like "status," "mapping," etc. make terrible names unless you qualify them.

submit