By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,740 Members | 790 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,740 IT Pros & Developers. It's quick & easy.

Lisp development with macros faster than Python development?..

P: n/a
I've been reading the beloved Paul Graham's "Hackers and Painters".
He claims he developed a web app at light speed using Lisp and lots
of macros.

It got me curious if Lisp
is inherently faster to develop complex apps in. It would seem if you
could create your own language in Lisp using macros that that would be
quite an advantage....

I realize that Python has operator overloading and OOP so I'm not sure.

Any ideas? Any *evidence* one way or another?

thanks!

Chris

Jul 21 '05 #1
Share this Question
Share on Google+
37 Replies


P: n/a
se******@spawar.navy.mil wrote:
I've been reading the beloved Paul Graham's "Hackers and Painters".
He claims he developed a web app at light speed using Lisp and lots
of macros.

It got me curious if Lisp
is inherently faster to develop complex apps in. It would seem if you
could create your own language in Lisp using macros that that would be
quite an advantage....

I realize that Python has operator overloading and OOP so I'm not sure.

Any ideas? Any *evidence* one way or another?

If that means that I have to learn a new programming language for every
program I'd like to apply a minor fix/customization to: not a good idea.
Probably not just for the casual hacker like me, but also for the
maintainance phase of a project, when the former lead gurus lost interest
and/or employment.

--
Benjamin Niemann
Email: pink at odahoda dot de
WWW: http://www.odahoda.de/
Jul 21 '05 #2

P: n/a
Very hard to say.

LISP has OOP too, Google for CLOS.

Operator overloading is something to avoid anyway, IMHO, just like
static typing is something to avoid if you need fast development, on
schedule and the like.

LISP has one thing that Python does not have: LISP code is LISP data.
A thorough study comparing LISP and Python in this respect would be
welcome.

Jul 21 '05 #3

P: n/a
se******@spawar.navy.mil wrote:
I've been reading the beloved Paul Graham's "Hackers and Painters".
He claims he developed a web app at light speed using Lisp and lots
of macros.

It got me curious if Lisp
is inherently faster to develop complex apps in. It would seem if you
could create your own language in Lisp using macros that that would be
quite an advantage....

I realize that Python has operator overloading and OOP so I'm not sure.

Any ideas? Any *evidence* one way or another?


Well, his Viaweb company was founded in about '95, right? So he probably just
used Lisp because Python wasn't as well known yet. ;-)

IMO one of Python's strengths over Lisp is that it plays well with many other
technologies. It should be remembered that Graham's use of Lisp in Viaweb was in
building a web application, so that Lisp's main links to the "outside world"
were the filesystem and Apache. They didn't use a database, and Apache had to be
modified in order to work with Lisp.
Jul 21 '05 #4

P: n/a
Well, his Viaweb company was founded in about '95, right? So he probably just
used Lisp because Python wasn't as well known yet. ;-)


David

That is what I thought too. It makes sense but I wasn't sure. Still
ain't.
The problem is that questions like 'What lang is fastest to develop
in?'
are hard to answer definitively.

Chris

Jul 21 '05 #5

P: n/a
se******@spawar.navy.mil wrote:
The problem is that questions like 'What lang is fastest to develop
in?' are hard to answer definitively.


That's because the answer depends on lots of context such what is the
problem domain and who is the programmer. Really, it's an impossible
question to answer. Measuring two different programmers with two
different languages would give useless results, since you can't ensure
the two programmers are equally capable. Using the same programmer for
the same problem with two different languages doesn't work since she
would learn from doing it the first time and inevitably have advantages
in the second time through. Using two different problems is of course
pointless as well.

Ultimately, however, the question needs no answer, since "speed of
development" is not the only or even the most important factor in
development. Take into account issues of maintainability, quality of
code, performance and such, and you've muddied the question even more,
making this a religious question and one that has no meaningful answer,
nor a need to be answered in a simple way.

For *me*, Python has proven to be the fastest language to develop in, so
far, but it's quite possible to imagine another language in the future
which I might learn which would be -- for me -- even faster, at least
for certain types of problems. (But so what? :-) )

-Peter
Jul 21 '05 #6

P: n/a
"se******@spawar.navy.mil" <se******@spawar.navy.mil> writes:
I've been reading the beloved Paul Graham's "Hackers and Painters".
He claims he developed a web app at light speed using Lisp and lots
of macros.

It got me curious if Lisp
is inherently faster to develop complex apps in. It would seem if you
could create your own language in Lisp using macros that that would be
quite an advantage....
Well, for me, I was playing around with lisp and developing in python
for my little scripts until I finally hit something that could leverage
a lisp macro to create a new type of iterator. After that things moved
foward at a rapid speed. Another point in lisp's favor is that I prefer
nested s-expressions to the sometimes ugly mashup of functional and OO
calls that I end up creating in python.

On the other hand, python benefits from a much richer standard library,
so some of the things you take for granted in python such as
string.split(None,3) need to be found or created.
thanks!

Chris


--
Kirk Job-Sluder
"The square-jawed homunculi of Tommy Hilfinger ads make every day an
existential holocaust." --Scary Go Round
Jul 21 '05 #7

P: n/a
"se******@spawar.navy.mil" <se******@spawar.navy.mil> writes:
Well, his Viaweb company was founded in about '95, right? So he probably just
used Lisp because Python wasn't as well known yet. ;-)


David

That is what I thought too. It makes sense but I wasn't sure. Still
ain't.
The problem is that questions like 'What lang is fastest to develop
in?'
are hard to answer definitively.


True. You might start by asking which lets you write the fewest LOC,
as studies during the 70s showed that programmers tended to write the
same number of LOC/day, regardless of the language chosen.

The problem with the LOC measurement is that the most productive days
are the ones where you refactor and eliminate a thousand LOC. That
sort of throws the whole thing off.

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Jul 21 '05 #8

P: n/a
se******@spawar.navy.mil wrote:
I've been reading the beloved Paul Graham's "Hackers and Painters".
He claims he developed a web app at light speed using Lisp and lots
of macros.

It got me curious if Lisp
is inherently faster to develop complex apps in.

With Lisp or Forth, a master programmer has unlimited power and
expressiveness. With Python, even a regular guy can reach for the
stars.
Raymond

Jul 21 '05 #9

P: n/a
se******@spawar.navy.mil wrote:
The problem is that questions like 'What lang is fastest to develop
in?'
are hard to answer definitively.


FWIW, Google's answer to that question is C++, Java, and Python. For
any given problem, any of the three are acceptable. Each programmer or
engineering team gets to decide based on his or her language
expertise.*

Raymond
* Source: Greg Stein's keynote address at PyCon 2005.

Jul 21 '05 #10

P: n/a
So Lisp is for really good programmers, and Python is for mediocre
programmers ?

Best Regards,

Fuzzy
http://www.voidspace.org.uk/python

Jul 21 '05 #11

P: n/a
Fuzzyman:
So Lisp is for really good programmers, and Python is for
mediocre programmers ?

Python is *also* for mediocre programmers. I see this as a
strength, not as a weakness.

Michele Simionato

Jul 21 '05 #12

P: n/a
On 6 Jul 2005 00:30:34 -0700, Raymond Hettinger <py****@rcn.com> wrote:

With Lisp or Forth, a master programmer has unlimited power and
expressiveness. With Python, even a regular guy can reach for the
stars.


+1 QOTW
Jul 21 '05 #13

P: n/a
Fair enough ;-)

I'd like to discover the power of Lisp, but I have a limited amount of
time to sink into programming... so maybe I'm better off putting my
energies and imagination into Python.

*A language is a medium of expression.* - Paul Graham

All the best.

Fuzzy
http://www.voidspace.org.uk/python

Jul 21 '05 #14

P: n/a
Op 2005-07-06, Michele Simionato schreef <mi***************@gmail.com>:
Fuzzyman:
So Lisp is for really good programmers, and Python is for
mediocre programmers ?

Python is *also* for mediocre programmers. I see this as a
strength, not as a weakness.


But sometimes I get the impression people want it to evolve
so it is only for mediocre programmers.

--
Antoon Pardon
Jul 21 '05 #15

P: n/a
You don't say how long it took to develop the "macros" but
you should see what kind of website an experienced Zope/Plone
programmer can whip up in a few minutes.

Acceleration in programming has always been about the "Standard
Library" (not only Python's standard library but also your
standard library). I'm talking about stable, debugged,
documented macros, functions and classes that the programmer can
use to quickly do very complex tasks. I discovered this well
over 30 years ago and taught many young programmers and
University students this very important "trick". As you write
software you will eventually come across common routines that
are used in almost every software package (logging, reading
from CSV files, date/time manipulation, ...). If you have lots
of these to choose from in your library, you will produce code
10-100 times faster than those that start over every time AND
the code will be MANY times more reliable because you are
utilizing stable code that has been debugged over a long period
of time. You will also be producing code that is more
"maintainable". Discovered a bug in a library routine? Fix it
and then it is fixed in 100's (or 1000's) of existing programs
that use it.

-Larry Bates

se******@spawar.navy.mil wrote:
I've been reading the beloved Paul Graham's "Hackers and Painters".
He claims he developed a web app at light speed using Lisp and lots
of macros.

It got me curious if Lisp
is inherently faster to develop complex apps in. It would seem if you
could create your own language in Lisp using macros that that would be
quite an advantage....

I realize that Python has operator overloading and OOP so I'm not sure.

Any ideas? Any *evidence* one way or another?

thanks!

Chris

Jul 21 '05 #16

P: n/a
Larry Bates <lb****@syscononline.com> writes:
You don't say how long it took to develop the "macros" but
you should see what kind of website an experienced Zope/Plone
programmer can whip up in a few minutes.


Zope/Plone (as frameworks) represent exactly the kinds of DSLs people
have been building with Lisp for decades. Shoulders of giants, and all
that. Lisp has web app frameworks as well: Uncommon Web and BKNR, to
name two.

Zac
Jul 21 '05 #17

P: n/a
On Tue, 5 Jul 2005, Mike Meyer wrote:
"se******@spawar.navy.mil" <se******@spawar.navy.mil> writes:
Well, his Viaweb company was founded in about '95, right? So he
probably just used Lisp because Python wasn't as well known yet. ;-)


That is what I thought too. It makes sense but I wasn't sure. Still
ain't. The problem is that questions like 'What lang is fastest to
develop in?' are hard to answer definitively.


True. You might start by asking which lets you write the fewest LOC, as
studies during the 70s showed that programmers tended to write the same
number of LOC/day, regardless of the language chosen.

The problem with the LOC measurement is that the most productive days
are the ones where you refactor and eliminate a thousand LOC. That sort
of throws the whole thing off.


As in:

http://www.folklore.org/StoryView.py...es_Of_Code.txt

Perhaps the real question, then, is which language allows you to delete
lines of code most quickly.

tom

--
find porn apricot
Jul 21 '05 #18

P: n/a
Tom Anderson wrote:
Perhaps the real question, then, is which language allows you to delete
lines of code most quickly.


No, then the question becomes "which language allows you to quickly
write very many lines of code which then have to be deleted".

Of course, writing those lines manually would be silly if you could
automate the process. After all, the lines of code aren't required, so
they don't really have to do anything, do they?

So naturally Assembly would be the proper way to get maximum performance
out of your automatic code writing program.

Therefore Assembly is clearly the fastest development language.

-Peter
Jul 21 '05 #19

P: n/a
[Raymond Hettinger]
se******@spawar.navy.mil wrote:
It got me curious if Lisp is inherently faster to develop complex
apps in.
With Lisp or Forth, a master programmer has unlimited power and
expressiveness. With Python, even a regular guy can reach for the
stars.


A few years ago, I much hesitated between Scheme and Python as my next
day-to-day programming language.

My feeling at the time was that Scheme is a very fast language to write
into, and in which one can implement new concepts cleanly and compactly.
Maybe Python is a bit slower to write, but this is compensated by the
fact Python is more legible when it comes to later maintenance, or when
many people have to share work on a big set of sources.

There is some heaviness and complexity in Python internals, Scheme are
purer and simpler by comparison. On its bright side, Python has a nice
and comprehensive library, and an interesting community of users. These
probably make most of the difference.

--
François Pinard http://pinard.progiciels-bpi.ca
Jul 21 '05 #20

P: n/a
Raymond Hettinger wrote:
se******@spawar.navy.mil wrote:
The problem is that questions like 'What lang is fastest to develop
in?'
are hard to answer definitively.

FWIW, Google's answer to that question is C++, Java, and Python. For
any given problem, any of the three are acceptable. Each programmer or
engineering team gets to decide based on his or her language
expertise.*


Actually, Google's answer to that question is something called "ILOG
CPLEX", followed by Visual Basic, English as a second language, PHP, and
"Holt Software Associates". ;-)

http://www.google.com/search?hl=en&q...=Google+Search

Given this finding, I'm not sure I should put much weight into Google
search results anymore ...
Jul 21 '05 #21

P: n/a
On Wed, 06 Jul 2005 08:27:55 -0500,
Larry Bates <lb****@syscononline.com> wrote:

[ reusable, stable, debugged, and documented libraries are a Good
Thing ]

Absolutely.

Two related stories from my days working as a software engineer for a
large telecomm company. Both stories begin with the annual ritual of
management telling us that code reuse was the silver bullet of software
development.

1. We replied that we needed about 5 calendar years to design, develop,
debug, and document sufficient libraries to pay for the effort. Then
management would tell us that 5 years is too long, and the project(s)
would be scrapped. I worked there for 12 years, and was still watching
new hires argue over linked list code and build tools when I left.

2. Right after that (and often in the same speech), management would
also tell us that they would be measuring our productivity by (a) LOC
written rather than LOC reused, and (b) the number of new ideas and code
we submitted for patent. There is no better example of a Mixed Message.

(Not to mention that we did all or most of our coding in C and C++, and
every department and every project had its own method(s) of determining
what a Line Of Code looked like, but that's even farther off-topic....)

Regards,
Dan

--
Dan Sommers
<http://www.tombstonezero.net/dan/>
Jul 21 '05 #22

P: n/a
"se******@spawar.navy.mil" <se******@spawar.navy.mil> writes:
I've been reading the beloved Paul Graham's "Hackers and Painters".
He claims he developed a web app at light speed using Lisp and lots
of macros.
That was the original "yahoo store".

It got me curious if Lisp is inherently faster to develop complex
apps in.
For complex applications IMO/E there is no question that it is. But
that is due to a lot of reasons, not only macros.

It would seem if you could create your own language in Lisp using
macros that that would be quite an advantage....
Here's the story. It has long been known that "domain specific
languages" (DSL) are a significantly more potent means of producing
applications (or chunks of them) in their domains than any so called
"general purpose" language. This is true even if the DSL is not a
particularly great piece of work. There are several examples of this
that most everyone knows about (though they may not realize it), with
"regular expressions" and SQL being among the most obvious.

You can take this further to "application specific languages" (ASL)
which provide even more leverage (though even narrower focus).
Obvious examples of this sort of thing would include AutoCAD and the
"grammar languages" of LALR parser generators.

The reason these things are so much better (for what they do) than
hacking away in your general purpose language is that the abstractions
they provide are much closer to what you want to say. They are much
more _declarative_ than procedural. You say _what_ you want done,
instead of specifying a lot of how that will produce the what [1].

Lisp (by which I mean here Common Lisp) macros enable you to build
DSLs and ASLs directly into the base language. This has several
advantages beyond what the DSLs/ASLs themselves bring; some obvious
ones being:

* You don't have to write lexers and parsers, that part is provided to
you for "free" by the Lisp reader[2]. In particularly sophisticated
cases you may need to alter the reader behavior (via the readtables)
and/or build a code walker to analyze things. But that would be
several sigmas out of the norm.

* Better yet, you don't have to write backend code generators. The
expansion code of a macro just gets compiled by the Lisp compiler
(typically an optimizing native code generator).

* The DSL/ASL code can be seamlessly used with the base language (and
libraries) just like when you use proprietary class libraries you've
built from within the base language. Only here, you get a much
higher level of abstraction and expressive power. So, you can
freely use a DSL/ASL where it applies (and get all its advantages),
but can effortlessly move to the base language when stepping outside
its focus.

* Better yet, in highly complex application scenarios you can have a
number of DSLs/ASLs each bringing their own high expressive power
and move freely among them and the base language. This should all
work naturally together in concert.

* Most idioms can be abstracted away and the bugs associated with them
disappear as well. You don't have to remember sequences of "right,
in these cases I first have to do this, then I have to call this
that and the next thing in this order, and finally make sure I end
it all with this bit over here."

Their are a few standard red herings trotted out against all this.
For example, "you mean you have a different programming language for
each application! That's awful." or some variant.

If you think about it for a moment, this is complete nonsense. Why?
Because you need to do this anyway - building and learning a set of
class libraries for an applicaion or domain (along with all its idioms
as well) is actually much more work, more painful, and (typically)
buys you less. The point is, you need to learn the "vocabulary" of
application or domain code whether or not you use DSLs/ASLs. Worse,
without the DSL/ASL approach you also need to learn a number of idioms
of how to _procedurally_ make use of the resources to achieve _what_
you want.

Another red hering goes something like: "it is much harder to learn a
DSL/ASL than to simply use your base general purpose language". Most
programmer types espousing this are really weird, because in the next
breath they will be extolling the virtues of regular expressions, or
list comprehension or some other DSL that just happens to already be
embedded in their favorite language. Also, it makes no sense anyway -
DSLs and ASLs are exactly the kind of thing provided to lay people at
the user end of many application scenarios. Are they really somehow
that much superior to learning these things than programmers?

Another one is "fragmentation". This is really a kind of variant on
the first, but it is used so often that it deserves its own mention.
Basically the argument is that if you build DSLs and ASLs eventually
your base language "fragments" and you have a few dozen languages
instead. A few seconds thought and it is easy to see that this is no
different than having a number of class libraries and in both cases
the idea of "framenting" the base language is nonsense.
OTOH, there _are_ issues associated with the DSL/ASL approach and Lisp
macro programming generally. IMO, the _key_ thing is to realize that
you don't want to have joe/jane-avg-hack, building these things,
because they will likely *$*%! it up. You don't have to be a genius
or something, but you have to be a _good_ designer and someone who
knows how to keep ergonomics and elegance front and center in the
process. The other thing is (again IMO, others will definitely
disagree with this) that you should focus on getting people who
know something about language design and compilation/translation to do
this work. You certainly need a clear understanding of the
differences between compile time, load time and runtime and what is
going on at each of these stages to do the best work here.

The best way to structure this is to have a group solely devoted to
building the DSL/ASL, with input from the domain experts, other high
level developers, and even some from joe/jane-avg-hack. The result is
then used by the application developers proper, including
joe/jane-avg-hack. This can and probably should be a process of
continual refinement. The entire thing can even be collapsed into one
individual (for smaller projects), but you need to be keenly aware of
what hat you have on at any given point.

Even so, it should be fairly clear that this isn't that much different
from what you would want to do in building your applications core
class system. It just has different areas of emphasis and expertise.

I realize that Python has operator overloading and OOP so I'm not sure.
This is simply orthogonal to the whole issue. Lisp has the most
potent object system available in any extent programming language.
While "operator overloading" (aka "static dispatch" or "compile time
dispatch") is controversial in some circles, it is quite easy to
provide with some macrology as well.

Any *evidence* one way or another?


There's plenty of evidence, but as with any software productivity
issue, it's mostly anecdotal. Hard scientific evidence for such
things is basically non existent and the economics of such things
pretty much guarantee it is going to stay that way.

-----------------------------------

1. Someone recently remarked that good Lisp macros are basically
executable pseudo code. I think that is pretty much exactly right
and is a pretty good "sound bite" distillation of what it is all
about.

2. Or, coming at from another angle, you don't have to figure out how
to cobble together a bunch of extraneous applications (lexers,
parers generators, code generators, etc.) into the one you are
building.
/Jon

--
'j' - a n t h o n y at romeo/charley/november com
Jul 21 '05 #23

P: n/a
François Pinard wrote:
My feeling at the time was that Scheme is a very fast language to write
into, and in which one can implement new concepts cleanly and compactly.
Maybe Python is a bit slower to write, but this is compensated by the
fact Python is more legible when it comes to later maintenance, or when
many people have to share work on a big set of sources.

There is some heaviness and complexity in Python internals, Scheme are
purer and simpler by comparison. On its bright side, Python has a nice
and comprehensive library, and an interesting community of users. These
probably make most of the difference.


Well said. Writing speed is not everything; if it is, APL and Scheme
win (and the evil Perl for string processing).

--Scott David Daniels
Sc***********@Acm.Org
Jul 21 '05 #24

P: n/a
Hi.
Instead of listing the difference ..here are some things that are
COMMON to both common lisp and python :

1.Dynamic typing.
2.garbage collection
3.powerful data structures
4.good object systems. (here people from lisp usually claim that clos
is the most powerful object system...but i think python and lisp are
comparable with none of them being better than the other. they are
different than each other. and i consider clos without mop to be
inferior. mop stands for meta object protocol...a thing which hasnt
been specified in the ansi lisp standard but is provided by most
implementations)
5.functions and types as first class objects
6.interactive development.

The differences:

1.Macros : Macros are extremely powerful and a double edges sword. Dont
believe anyone (whether they praise them or abhor them). Go and learn
them and decide for yourself.

2.Readability : Python is generally believed to be far more readable
than ANY other language. (Lisp isnt particularly unreadable).

The only way to really find out which is better is to learn both and
decide yourself.

i personally like python , lisp and c. now c evokes derision from both
python and lisp folks sometimes and thats incorrect too.
rahul

se******@spawar.navy.mil wrote:
I've been reading the beloved Paul Graham's "Hackers and Painters".
He claims he developed a web app at light speed using Lisp and lots
of macros.

It got me curious if Lisp
is inherently faster to develop complex apps in. It would seem if you
could create your own language in Lisp using macros that that would be
quite an advantage....

I realize that Python has operator overloading and OOP so I'm not sure.

Any ideas? Any *evidence* one way or another?

thanks!

Chris


Jul 21 '05 #25

P: n/a
Rocco Moretti wrote:
Actually, Google's answer to that question is something called "ILOG
CPLEX",


We use this. It's a library / command line tool (not a language) for
doing optimization - linear programming, quadratic programming,
mixed-integer programming etc. Very cool and very, very scarey.
Jul 21 '05 #26

P: n/a
????

Almost sounds like a racist comment - sorry if I misunderstood
Antoon Pardon wrote:
Op 2005-07-06, Michele Simionato schreef <mi***************@gmail.com>:
Fuzzyman:
So Lisp is for really good programmers, and Python is for
mediocre programmers ?

Python is *also* for mediocre programmers. I see this as a
strength, not as a weakness.


But sometimes I get the impression people want it to evolve
so it is only for mediocre programmers.


Jul 21 '05 #27

P: n/a
Op 2005-07-07, Philippe C. Martin schreef <ph******@philippecmartin.com>:
????

Almost sounds like a racist comment - sorry if I misunderstood
I'll clarify. A lot of the time I hear arguments against
features that boils down to.

1) I don't need it.

2) Having the feature will make my job more difficult.

3) I don't understand the merrits of the feature or I
have difficulty understanding what it does when I
encounter it.

IMO these are arguments if followed sufficiently will lead to
a language that is only usefull for mediocre programmers.
Antoon Pardon wrote:
Op 2005-07-06, Michele Simionato schreef <mi***************@gmail.com>:
Fuzzyman:
So Lisp is for really good programmers, and Python is for
mediocre programmers ?
Python is *also* for mediocre programmers. I see this as a
strength, not as a weakness.


But sometimes I get the impression people want it to evolve
so it is only for mediocre programmers.

Jul 21 '05 #28

P: n/a

"jayessay" <no****@foo.com> wrote in message
news:m3************@rigel.goldenthreadtech.com...
1. Someone recently remarked that good Lisp macros are basically
executable pseudo code. I think that is pretty much exactly right
and is a pretty good "sound bite" distillation of what it is all
about.


Several years ago I remarked that Python reads like executable pseudocode.
I still think that that is pretty much right.

Googling, I discovered that the creators of some thing I had never heard of
said the same thing about *their* language a couple of years ago. I wish
web pages, like newgroup posts, were dated so one could better trace the
history of such usages.

Terry J. Reedy

Jul 21 '05 #29

P: n/a

"Antoon Pardon" <ap*****@forel.vub.ac.be> wrote in message
news:sl********************@rcpc42.vub.ac.be...
I'll clarify. A lot of the time I hear arguments against
features that boils down to.

1) I don't need it.

2) Having the feature will make my job more difficult.

3) I don't understand the merrits of the feature or I
have difficulty understanding what it does when I
encounter it.

IMO these are arguments if followed sufficiently will lead to
a language that is only usefull for mediocre programmers.


True. But these arguments did not stop expert-level features like
metaclasses, decorators, and (in 2.5) context-management blocks
(with-blocks).

TJR

Jul 21 '05 #30

P: n/a
Terry Reedy wrote:
"jayessay" <no****@foo.com> wrote in message
news:m3************@rigel.goldenthreadtech.com...
1. Someone recently remarked that good Lisp macros are basically
executable pseudo code. I think that is pretty much exactly right
and is a pretty good "sound bite" distillation of what it is all
about.


Several years ago I remarked that Python reads like executable pseudocode.
I still think that that is pretty much right.

Googling, I discovered that the creators of some thing I had never heard of
said the same thing about *their* language a couple of years ago. I wish
web pages, like newgroup posts, were dated so one could better trace the
history of such usages.


Trawling through http://web.archive.org might help.

--
Robert Kern
rk***@ucsd.edu

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

Jul 21 '05 #31

P: n/a
"Terry Reedy" <tj*****@udel.edu> writes:
"jayessay" <no****@foo.com> wrote in message
news:m3************@rigel.goldenthreadtech.com...
1. Someone recently remarked that good Lisp macros are basically
executable pseudo code. I think that is pretty much exactly right
and is a pretty good "sound bite" distillation of what it is all
about.


Several years ago I remarked that Python reads like executable pseudocode.
I still think that that is pretty much right.

Googling, I discovered that the creators of some thing I had never heard of
said the same thing about *their* language a couple of years ago. I wish
web pages, like newgroup posts, were dated so one could better trace the
history of such usages.


In the context discussed, the idea was the pseudo code was a _direct_
match to the description of the task in the _domain_. If your domain
is "algorithms" or some such, then I would agree Python would work as
a reasonably decent pseudo language, otherwise no. It's too low
level. Same with base CL. It's too low level.

/Jon

--
'j' - a n t h o n y at romeo/charley/november com
Jul 21 '05 #32

P: n/a
"Antoon Pardon" <ap*****@forel.vub.ac.be> wrote in message
news:sl********************@rcpc42.vub.ac.be...
I'll clarify. A lot of the time I hear arguments against
features that boils down to.
It seems that you've lost some of the intent during the boiling.
1) I don't need it.
Is that what you get out of the oft-used "What's your use case"?
That's an attempt to find out what problem the proposer thinks the
feature would help solve, so said solution can be evaluated in
comparison to possible existing solutions.
2) Having the feature will make my job more difficult.
Well, if the job is "writing programs" or "debugging programs", then
that's a *good* reason for not adding the feature. Those jobs are hard
enough as it is. Any feature that makes them noticably harder needs to
provide some serious advantages in order to be justified.
3) I don't understand the merrits of the feature or I
have difficulty understanding what it does when I
encounter it.
I don't think I've seen the first one used as an argument against a
feature. I may well have missed them, as I don't follow all such
discussion completely. The second one is a variation on #2, above.

Adding features just because they are "cool" is not the right way to
grow a language. New features need to enhance the language in a
clearly positive manner, while having as little negative impact as
possible. Point 1 and the first part of 3 are cases of people who
don't see a real enhancement to the language. Point 2 and the second
part of 3 are cases where people see a serious negative impact from a
feature.

When people *quit* pointing out those kinds of problems with
proposals, then I'll be worried. Python will be on it's way to
becoming Perl 6 or Common LISP, rather than the powerful, elegant
language I've come to love.

Bringing up such objections also gives the proposer a chance to
correct the problem, which is to everyones advantage. Witness the
recent (short) discussion of adding dynamically scoped variables. As
originally proposed, they can produce very obscure and hard-to-find
bugs. The fix for this made them no worse than global variables.
IMO these are arguments if followed sufficiently will lead to
a language that is only usefull for mediocre programmers.


Unless you're arguing that Python is already a language that is only
usefull for mediocre programmers, then this is sort of moot. Those are
arguments being advanced against *adding* features, not for removing
them (at least, I don't think I saw any of them in the ongoing
discusion re map/filter/reduce/lambda). Or are you arguing that Python
will somehow become less useful as new features are proposed and
rejected?

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Jul 21 '05 #33

P: n/a


se******@spawar.navy.mil schrieb:
I've been reading the beloved Paul Graham's "Hackers and Painters".
He claims he developed a web app at light speed using Lisp and lots
of macros.


Yes, Paul is a postmodern hero who reininvents himself and his language
every day and with every program:

"Experienced Lisp programmers divide up their programs differently. As
well as top-down design, they follow a principle which could be called
bottom-up design-- changing the language to suit the problem. In Lisp,
you don't just write your program down toward the language, you also
build the language up toward your program. As you're writing a program
you may think "I wish Lisp had such-and-such an operator." So you go
and write it. Afterward you realize that using the new operator would
simplify the design of another part of the program, and so on. Language
and program evolve together."

http://www.paulgraham.com/progbot.html

Remark: The same may be claimed about Forth.

This might be a great self experience for some "great hackers" but just
annoying for others who used to work with modular standard librarys and
think that the border of the language and an application should be
somehow fixed to enable those.

Kay

Jul 21 '05 #34

P: n/a
"Kay Schluehr" <ka**********@gmx.net> writes:
This might be a great self experience for some "great hackers" but just
annoying for others who used to work with modular standard librarys and
think that the border of the language and an application should be
somehow fixed to enable those.
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. 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.

Kay


--
Kirk Job-Sluder
"The square-jawed homunculi of Tommy Hilfinger ads make every day an
existential holocaust." --Scary Go Round
Jul 21 '05 #35

P: n/a


Kirk Job Sluder schrieb:
"Kay Schluehr" <ka**********@gmx.net> writes:
This might be a great self experience for some "great hackers" but just
annoying for others who used to work with modular standard librarys and
think that the border of the language and an application should be
somehow fixed to enable those.
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 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.

Kay

Jul 21 '05 #36

P: n/a
"Kay Schluehr" <ka**********@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
Jul 21 '05 #37

P: n/a
<se******@spawar.navy.mil> wrote in message
news:11**********************@g49g2000cwa.googlegr oups.com...
Well, his Viaweb company was founded in about '95, right? So he probably just used Lisp because Python wasn't as well known yet. ;-)


David

That is what I thought too. It makes sense but I wasn't sure. Still
ain't.
The problem is that questions like 'What lang is fastest to develop
in?'
are hard to answer definitively.


No it's not.

The answer is always whatever language you enjoy the most and know the best.

That's a somewhat redundant statement because if you enjoy a language, you
are highly motivated to use it often and learn it well.

An intimate knowledge of any particular language is *far* more important
than the syntactic and semantic arcana that people usually argue over.

So - what the question really boils down to is which language(s) have the
best balance of approachability (easy to learn!) and capability. Bear in
mind though, that if the language sacrifices capability in favor of being
easy, then the fun runs out of it too soon :-)

Thomas Bartkus


Jul 21 '05 #38

This discussion thread is closed

Replies have been disabled for this discussion.