I consider myself a Python programmer. Python was the first language I learned, and still the one I am most proficient. With the possible exception of the Bourne shell language, it's the programming language I spend the most time working with, and the language I first turn to to solve problems.

I have tried other languages; for starters, I tried Perl and Ruby. In fact, if I had started with either of those, I probably would still be using them as my primary language today. However, since I already knew Python, I never got to the point of writing idiomatic Perl or Ruby - by the time I would have learned that, I had already moved back to Python to complete some project that had stumped me in other languages.

I dabbled in other languages, both compiled and interpreted. Ultimately, only one has had a lasting effect - Lisp.

My curiosity in Lisp was piqued (like many others') when I read the essays of Paul Graham, and from other influential advocates - Peter Norvig, Eric Raymond and of course Stallman. I began to dabble in Lisp, particularly in the parts that worked more or less like Python - simple defuns, stateless recursive functions (Fibonacci, anyone?) and the like. Getting into it was rocky - I distinctly remember my first time at the sbcl shell, and being totally mystified at the debugger. I ended up having to killall sbcl to get out of there.

Another thing I noticed what that it was pretty hard to set a variable. Compared to python's var=value, Lisp didn't seem to have a straightforward way to setting variables. Defvar, defparameter, setf, setq, set, defconstant, and the list goes on. It was soon after that that I realized that the functions that I had managed to write were not actually using any variables, and I began to grasp (really, rather than just conceptually, grasp) the ideas behind functional programming. A total lack of state - a radical idea for someone coming from procedural languages. Lisp made it hard to set variables, but in some ways, this was a feature, not a bug.

Yet still, I struggled with Lisp. To practice, I began working through the problems posed by the excellent Project Euler. I could write solutions in Python far faster, but in Lisp, the solutions tended to be shorter and more general. The Lisp solution seemed, to me, to be "dense" - each line did multiple things, and the entire function - usually not more than a half-dozen lines - read more like a paragraph of text than the long, verbose functions we'd expect from C-family languages.

Sure enough, having been an Emacs user for a couple months at that point, the parentheses hardly bothered me at all. Most any editor will pair the parentheses, and I found that instinct worked well. Simply guessing how many parentheses I needed to close to get the correct logic was far faster than stepping through everything, and it worked almost every time. A well-formatted error message would tell me what my mistake was if this was not the case. In all, the syntax was, for me, very simple.

I never did get beyond trivial functions. Finding myself ill-equipped to move on to larger things, I decided to retreat back and study harder, learn more thoroughly. I read Practical Common Lisp, first online, then from the book. I watched the SICP video lectures.

And, just a little bit, I began to "get" Lisp.

Describing exactly what makes Lisp special is difficult. For starters, there's the fact that you really need to know what you're doing to really understand it. Even then, reasonable people can disagree about non-trivial points. And it can be explained in many ways that are neither incorrect nor complete; neither correct nor lacking.

One way to describing this would be to note that Lisp is written in the languages' primary data type, the list. Writing a program as a linked list results in a greatly simplified syntax, and even in the 60's, fostered the dynamicity that Lisp was known for before interpreted languages became mainstream.

Another would be to note that unlike most languages, in which source code is parsed into a syntax tree, writing Lisp is actually writing the syntax tree itself. This makes macros infinitely more powerful, since instead of modifying symbols that still must be valid symbols to be parsed later, macros can actually modify the tree itself.

Unfortunately, I have so far been unable to apply and use these concepts. I have a vague understanding of what they make possible, but every time I return to the Lisp interpreter to try to hack some code, I get hit by how unpleasant it is to use.

In some ways, it may be in the "zen" of Lisp for the implementations to be somewhat tedious to use. After all, for someone well-versed in Lisp culture, the rituals of packaging, setting up an environment, and debugging on the fly is probably near-memorized. But for a relative programming newbie, the problems become showstoppers.

I have been using the sbcl implementation of Common Lisp. The first problem I have is with the number standard symbols. Setf, Setq and all of the defvar variants still confuse me. They are not, strictly speaking, difficult to learn. Using them correctly is simply a matter of practice and discipline. And as many have said, the prize at the end is supposed to make this relatively small annoyance seem insignificant in comparison, right?

I don't know. As a new user, I can't yet see the light at the end of the tunnel; I can only compare with Python. What I've found is that what I would really like is Python, in a Lisp syntax. Common Lisp is not important to me; a fast, stable, practical Lisp with a large standard library is. Python, in fact, almost fits the bill perfectly. Many others - Norvig, for starters - have noted the similarities between Python and Lisp. While Python shares Lisp's affinity for number calculation of arbitrary size, multi-paradigm style and high-level constructs, Python lacks the defining feature of Lisp - the syntax.

I would like to propose, then, that a programmer far better than myself re-write the Python interpreter to accept a Lisp dialect as input. Keep the Python data types, the dictionaries, lists and strings; use the Lisp syntax. Eliminate Python's [], {} and () syntax's, and replace them with explicit but not tedious Lisp functions. Keep the Python backend code, but write a new parser for it. Don't worry about Common Lisp; far more important that Common Lisp is usable, useful (dare I say it, Pythonic?) Lisp.

I would argue that this intrepid programmer could even ignore, for the time being, macros, another core Lisp feature. Once the syntax has become Lisped, a macro system will evolve quickly.

There are, of course, pitfalls. The first is that Python lacks the list-centredness of Lisp. Whether this is a showstopper, I do not know. Would the source code be a Python list, or a Python tuple?

I regret that I cannot, at least now, be the person to do this. My C education is sorely lacking, although I am, slowly, working on fixing this. Nevertheless, I do not have the breadth of experience that would be necessary to do the low-level work with the Python source code to create an alternative syntax. I can offer support and a promise to write documentation to whoever wants to do this.