Lisp development with macros faster than Python development?..

[Kirk Job Sluder]

"Kay Schluehr" <kay.schluehr at gmx.net> writes:

> Kirk Job Sluder schrieb:
> > In what way do lisp macros prevent the creation of modular libraries?
> > Common Lisp does does have mechanisms for library namespaces, and in
> > practice a macro contained within a library is not that much different
> > from a function contained in a library or a class contained in a
> > library. Macros just provide another mechanism for creating useful
> > domain-specific abstractions.
> 
> To be honest I don't understand what a "domain-specific abstraction"
> could be? What is the benefit of abstractions if they are not
> abstracting from particular domain specific stuff?

The usual trend in higher level languages is to abstract away from the
algorithmic details into domain-specific applications.  So for example,
rather than writing a block of code for handling the regular expression
'[a-zA-Z]+, then a different block of code for the case, 'a|b|c', we
have a regular expression library that packages up the algorithm and the
implementation details into an interface.  The python standard library
is basically a collection of such abstractions.  In python you usually
work with strings as an object, rather than as an array of byte values
interpreted to be linguistic characters located at a specific memory
address as you would in c.

Object oriented programming is all about creating domain-specific
abstractions for data.  This enables us to talk about GUIs as widgits
and frames in addition to filling in pixels on a screen.  Or to talk
about an email Message as a collection of data that will be stored in a
certain format, without having to do sed-like text processing.

> > The primary advantage to macros is that
> > you can create abstractions with functionality that is not easily
> > described as either a function or a class definition.
> 
> As long as macros are used to create new language features such as an
> object system like CLOS this technique may be perfectly justified for
> language developers ( ! ) but I still consider it as a bad idea to
> muddle the language development and the application development, that
> seems to be the favourite programming style of Paul Graham. On the
> other hand thinking about language development as a certain application
> domain I find nothing wrong with the idea that it once reaches somehow
> a state of a mature product that should not be altered in arbitrary
> manner for the sake of a large user community.

Well, at this point, Common Lisp has been formally standardized, so
changing the core standard would be very difficult.  There is in fact,
strong resistance to reopening the standards process at this time, based
on the impression that most of what needs to be done, can be
accomplished by developing libraries.  So I think that CL as a mature
product is not altered in an arbitrary manner.

However, from my view, quite a bit of development in python involves
adding new language constructs in the form of classes, functions, and
instance methods, as well as interfaces to C and C++ libraries.  I would
argue this is one of the core strengths of python as a language, the
fact that we are only limited to the builtin functions and standard
library if we choose to be.  As an example, whenever I work with a new
data source, I usually end up creating a class to describe the kinds of
records I get from that data source.  And some functions for things that
I find myself repeating multiple times within a program.  

Macros are just another way to write something once, and use it over and
over again.  

> 
> Kay
> 

-- 
Kirk Job-Sluder
"The square-jawed homunculi of Tommy Hilfinger ads make every day an
existential holocaust."  --Scary Go Round