Python syntax in Lisp and Scheme

[Pascal Costanza]

Raffael Cavallaro wrote:

> For 90% of tasks, even large projects, Python will certainly have
> enough in its ever expanding bag of tricks to provide a clean,
> maintainable solution. But that other 10% keeps lisp hackers from
> using Python for exploratory programming - seeking solutions in
> problem domains that have not been solved before.

I would like to add to that by pointing out that it is even a good idea 
to use Lisp for problem domains that others have solved before but that 
_I_ (or "you") don't understand completely yet.

To me, programming languages are tools that help me to explore domains 
by writing models for them and interactively testing how they react to 
commands. In a certain sense, they are an extension of my brain that 
help me to manage the tedious and repetitive tasks, and let me focus on 
the essential problems.

Many programming languages require you to build a model upfront, on 
paper or at least in your head, and then write it down as source code. 
This is especially one of the downsides of OOP - you need to build a 
class hierarchy very early on without actually knowing if it is going to 
work in the long run.

What you actually do when you build a model of something is that you 
start _somewhere_, see how far you can get, take some other route, and 
so on, until you have a promising conceptualization. The cool thing 
about Lisp is that I can immediately sketch my thoughts as little 
functions and (potential) macros from the very beginning, and see how 
far I can get, exactly like I would when I would be restricted to work 
on paper. Except that in such an exploratory programming mode, I can get 
immediate feedback by trying to run the functions and expanding the 
macros and see what they do.

I know that OOP languages have caught up in this regard by providing 
refactoring tools and other IDE features. And I definitely wouldn't want 
to get rid of OOP in my toolbox because of its clear advantages in 
certain scenarios.

But I haven't yet seen a programming language that supports exploratory 
thinking as well as Lisp. It's like that exactly because of the 
s-expressions, or more specifically because of the fact that programs 
and data are the same in Lisp.

Computers are there to make my tasks easier. Not using them from the 
very beginning to help me solve programming tasks is a waste of 
computing resources.

In one particular case, I have used the CLOS MOP to implement some 
special case of a method combination. At a certain stage, I have 
realized that I have made a conceptual mistake - I have tried to resolve 
the particular method combination at the wrong stage. Instead of doing 
it inside of the method combination it had to be done at the call site. 
It was literally just a matter of placing a quote character at the right 
place - in front of the code to be executed - that allowed me to it pass 
to the right place as data, and then expand it at the call site. I can't 
describe in words what an enlightening experience this was. In any other 
language I have known until then, this change would have required a 
complete restructuring of the source code, of the phases in which to 
execute different parts of the code, of the representation for that 
code, and so on. In Lisp, it was just one keystroke!

It's because of such experiences that Lispniks don't want to switch to 
lesser languages anymore. ;-)


(More seriously, there are probably very different ways to think about 
problems. So Lisp might not be the right language for everyone, because 
other people might find completely different things helpful when they 
try to tackle a problem. It would be interesting to do some research on 
this topic. As much as I don't think that there is a single programming 
paradigm that is best suited for all possible problems I also don't 
think that there is a single programming style that is best suited for 
all programmers.)


Pascal