Python syntax in Lisp and Scheme

[Rob Hunter]

Forgive me if this has already been addressed, but...

I think a few of the posts (that I have read), like the two below, 
don't quite give an expandable language like Scheme or Lisp its fair 
share.  Raffael notes that, "For 90% of tasks, even large projects, 
Python will certainly have enough in its ever expanding bag of tricks 
..."  This is probably true, but I'd like to comment on the word 
"expanding."  You could imagine, as an exaggerated example, a language 
in which every program was one word.  Basically, you would create this 
language with a huge dictionary that maps each word to some longer 
program.  This language certainly wouldn't need any expandibility 
features, since it already has a way to write every program concisely.  
The problem, of course, is that this language is unusable since you 
would have to learn a new keyword for every single program you wanted 
to write.  And this is what scares me about things like an "ever 
expanding bag of tricks".  Taking this expansion to its conclusion, 
maybe you'll end up with a language like the one I described.

A good language has a good set of language constructs and a good 
selection of libraries (which generally don't extend the language, but 
rather, give you more functionality *within* the confines of the 
language).  Python, IMO, does a great job with both of these things.  
But here's the problem: For even non-super-complex problems, you still 
are going to want the language to be pushed further in order to cater 
to your particular domain*.  And one way to solve this problem is to 
expand the language's bag of tricks.  But, IMO, this is often not a 
good way of doing it.  Why?  Because eventually you end up with a 
language that can do everything with one keyword, and it's entirely 
useless.  Because you have to learn some new special trick of the 
language for everything you want to write.

Instead, imagine a language that had a useful set of language 
constructs**, where one of them was a construct that allowed you to 
easily extend the language.

Such a language is Scheme (or Lisp).  In Scheme, you can easily extend 
the language with macros, and of equal importance, your extensions are 
*bootstrapped* in the language itself, and thus you avoid the problem 
that you have with "built-in" functionality---ie, you don't need a 
manual to figure out what it does.  And, when you're done with one 
project, you haven't 'cluttered' your language up with the domain 
specific language constructs you created for the project.  You, if you 
want, always start with a fresh Scheme.

Rob

* By domain, I don't mean AI, or numerical analysis, or comp bio 
programming.  I mean the *exact* problem you happen to be coding up, 
using a particular design, using a particular set of libraries, with 
particular things you want to optimize.

** Scheme language constructs are functions, application, macros, and 
then libraries.  That's really all it is, and so you never learn new 
features of the language.  You only really learn new ways to use these 
(really powerful) features.


On Sunday, October 12, 2003, at 03:42 PM, Raffael Cavallaro wrote:

> Pascal Costanza <costanza at web.de> wrote in message 
> news:<bm9g9m$28n$1 at newsreader2.netcologne.de>...
>
>> Lispniks are driven by the assumption that there is always the
>> unexpected. No matter what happens, it's a safe bet that you can make
>> Lisp behave the way you want it to behave, even in the unlikely event
>> that something happens that no language designer has ever thought of
>> before. And even if you cannot find a perfect solution in some cases,
>> you will at least be able to find a good approximation for hard
>> problems.
>
> This I believe is the very crux of the matter. The problem domain to
> which lisp has historically been applied, artificial intelligence,
> more or less guaranteed that lisp hackers would run up against the
> sorts of problems that no one had ever seen before. The language
> therefore evolved into a "programmable programming language," to quote
> John Foderaro (or whoever first said or wrote this now famous line).
>
> Lisp gives the programmer who knows he will be working in a domain
> that is not completely cut and dried, the assurance that his language
> will not prevent him for doing something that has never been done
> before. Python gives me the distinct impression that I might very well
> run up against the limitations of the language when dealing with very
> complex problems.
>
> 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.
> -- 
> http://mail.python.org/mailman/listinfo/python-list
>