From: ·······@gmail.com
Subject: Wondering if you guys would like to comment on this
Date: 
Message-ID: <1115342979.274966.293660@z14g2000cwz.googlegroups.com>
I posted this quote from Practical Common Lisp on my blog this
afternoon:
"    DOLIST is similar to Perl's foreach or Python's for. Java
added a similar kind of loop construct with the "enhanced" for loop
in Java 1.5, as part of JSR-201. Notice what a difference macros make.
A Lisp programmer who notices a common pattern in their code can write
a macro to give themselves a source-level abstraction of that pattern.
A Java programmer who notices the same pattern has to convince Sun that
this particular abstraction is worth adding to the language. Then Sun
has to publish a JSR and convene an industry-wide "expert group" to
hash everything out. That process-according to Sun-takes an average of
18 months. After that, the compiler writers all have to go upgrade
their compilers to support the new feature. And even once the Java
programmer's favorite compiler supports the new version of Java, they
probably still can't use the new feature until they're allowed to
break source compatibility with older versions of Java. So an annoyance
that Common Lisp programmers can resolve for themselves within five
minutes plagues Java programmers for years.
    -Peter Seibel "

and had a very interesting response,
""So an annoyance that Common Lisp programmers can resolve for
themselves within five minutes plagues Java programmers for years."
...which is great, until someone else has to use your code. Have you
ever tried using someone's highly customized EMACS setup? Maybe
they've made it more like Wordstar, or changed the exit key. Maybe
their meta is their control key, and their control key is their caps
lock key. The result is that you not only have to be used to reading
someone's algorithms, you have to be used to reading their dialect.
As such, I have the same rules on LISP programming that I do with perl
- I hate it unless I wrote it."

After reading a few other threads here, it seems like this does present
a bit of problem and was wondering if any of the Lisp veterans would
care to comment. Practical Common Lisp is my first exposure to the
langauge and I was wondering if anyone would care to comment?

Thanks,
PJ

From: ···············@yahoo.com
Subject: Re: Wondering if you guys would like to comment on this
Date: 
Message-ID: <1115345860.709703.90540@z14g2000cwz.googlegroups.com>
Good Java programmers write functions that are easy to read.  Good Lisp
programmers write functions and macros that are easy to read.
From: Barry Margolin
Subject: Re: Wondering if you guys would like to comment on this
Date: 
Message-ID: <barmar-F7A292.22363505052005@comcast.dca.giganews.com>
In article <·······················@z14g2000cwz.googlegroups.com>,
 ···············@yahoo.com wrote:

> Good Java programmers write functions that are easy to read.  Good Lisp
> programmers write functions and macros that are easy to read.

Right.

There are a number of stylistic conventions and idioms that have become 
common in Lisp.  If your own macros conform to these conventions, other 
programmers should have little problem understanding what you're doing.

There are exceptions.  For instance, when people first created the LOOP 
macro, it was unlike anything already in Lisp.  But it was designed to 
look like Algol-style languages (which experienced programmers all 
knew), and used well-known English verbs and prepositions, so it wasn't 
really too confusing.  Also, this was a time when most of the 
conventions I refer to were still being developed, so there wasn't as 
much existing style to conform to -- we were a pretty small, close-knit 
community and word of new ideas spread quickly (most Lisp programmers in 
the 70's were at MIT, Stanford, and CMU, which all had Arpanet 
connections).

-- 
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
From: ·······@gmail.com
Subject: Re: Wondering if you guys would like to comment on this
Date: 
Message-ID: <1115354815.033180.76090@z14g2000cwz.googlegroups.com>
Are there any websites where those conventions are defined? That would
be useful for a Lisp newbie such as myself. Even with my limited
exposure, I am quite enthralled with the language. The syntax is such a
180 from what I'm used to with Java & C++, it's going to take some time
to get adjusted.
From: Pascal Bourguignon
Subject: Re: Wondering if you guys would like to comment on this
Date: 
Message-ID: <871x8k1w83.fsf@thalassa.informatimago.com>
·······@gmail.com writes:

> Are there any websites where those conventions are defined? That would
> be useful for a Lisp newbie such as myself. Even with my limited
> exposure, I am quite enthralled with the language. The syntax is such a
> 180 from what I'm used to with Java & C++, it's going to take some time
> to get adjusted.

http://math.bu.edu/misc/DOCSERVER/raw/Good-Lisp-Style.pdf
http://www.cs.cmu.edu/afs/cs.cmu.edu/project/ai-repository/ai/html/faqs/lang/lisp/part1/faq-doc-4.html


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
Kitty like plastic.
Confuses for litter box.
Don't leave tarp around.
From: Edi Weitz
Subject: Re: Wondering if you guys would like to comment on this
Date: 
Message-ID: <upsw4r50c.fsf@agharta.de>
On 5 May 2005 21:46:55 -0700, ·······@gmail.com wrote:

> Are there any websites where those conventions are defined? That
> would be useful for a Lisp newbie such as myself. Even with my
> limited exposure, I am quite enthralled with the language. The
> syntax is such a 180 from what I'm used to with Java & C++, it's
> going to take some time to get adjusted.

  <http://www.norvig.com/luv-slides.ps>

Edi.

-- 

Lisp is not dead, it just smells funny.

Real email: (replace (subseq ·········@agharta.de" 5) "edi")
From: Matthias
Subject: Re: Wondering if you guys would like to comment on this
Date: 
Message-ID: <36wd5s4u1yu.fsf@hundertwasser.ti.uni-mannheim.de>
Barry Margolin <······@alum.mit.edu> writes:

> In article <·······················@z14g2000cwz.googlegroups.com>,
>  ···············@yahoo.com wrote:
> 
> > Good Java programmers write functions that are easy to read.  Good Lisp
> > programmers write functions and macros that are easy to read.
> 
> Right.
> 
> There are a number of stylistic conventions and idioms that have become 
> common in Lisp.  If your own macros conform to these conventions, other 
> programmers should have little problem understanding what you're doing.
> 
> There are exceptions.  For instance, when people first created the LOOP 
> macro, it was unlike anything already in Lisp.  But it was designed to 
> look like Algol-style languages (which experienced programmers all 
> knew), and used well-known English verbs and prepositions, so it wasn't 
> really too confusing.  

While I agree with the general statement, I think that LOOP could also
be seen as a case where (presumably experienced) macro programmers got
it wrong: For my taste it's too complex and "overdesigned",
esp. regarding how different LOOP statements interact with each other.
While simple use cases of LOOP are great, easy to understand, clear
and concise (I use them a lot!) I _really_ don't want to spend days
until I understand how LOOP works in the more complicated cases.

But then: This may just be me, and, as FORMAT proves, you can
overdesign languages even without the help of macros.
From: Alexander Schreiber
Subject: Re: Wondering if you guys would like to comment on this
Date: 
Message-ID: <slrnd7m8sr.o1b.als@mordor.angband.thangorodrim.de>
···············@yahoo.com <···············@yahoo.com> wrote:
> Good Java programmers write functions that are easy to read.  Good Lisp
> programmers write functions and macros that are easy to read.

See, you are making it just too hard for the average programmer.
The average untrained coder is working hard to write _functions_ that do
_something_, let alone something mostly right. Writing readable
functions is extremly hard work for those hardworking people.

And now you expect functions _and_ macros that are easy to read?
Clearly, Lisp is just an evil elitist tool to make the average
programmer feel bad and should be banned for it.

SCNR,
   Alex.
-- 
"Opportunity is missed by most people because it is dressed in overalls and
 looks like work."                                      -- Thomas A. Edison
From: Andreas Thiele
Subject: Re: Wondering if you guys would like to comment on this
Date: 
Message-ID: <d5f8ms$fiv$04$2@news.t-online.com>
<···············@yahoo.com> schrieb im Newsbeitrag
····························@z14g2000cwz.googlegroups.com...
> Good Java programmers write functions that are easy to read.  Good Lisp
> programmers write functions and macros that are easy to read.
>

I'd agree, but when reading sources length or verbosity matters. I
definitely have a favorite :))

Andreas
From: Tayssir John Gabbour
Subject: Re: Wondering if you guys would like to comment on this
Date: 
Message-ID: <1115349120.307692.291450@z14g2000cwz.googlegroups.com>
·······@gmail.com wrote:
> I posted this quote from Practical Common Lisp on my blog
> this afternoon:
> "    DOLIST is similar to Perl's foreach or Python's for. Java
> added a similar kind of loop construct with the "enhanced" for loop
> in Java 1.5, as part of JSR-201. Notice what a difference macros
> make. A Lisp programmer who notices a common pattern in their code
> can write a macro to give themselves a source-level abstraction of
> that pattern. A Java programmer who notices the same pattern has to
> convince Sun that this particular abstraction is worth adding to
> the language. Then Sun has to publish a JSR and convene an
> industry-wide "expert group" to hash everything out. That
> process-according to Sun-takes an average of 18 months. After that,
> the compiler writers all have to go upgrade
> their compilers to support the new feature. And even once the Java
> programmer's favorite compiler supports the new version of Java,
> they probably still can't use the new feature until they're allowed
> to break source compatibility with older versions of Java. So an
> annoyance that Common Lisp programmers can resolve for themselves
> within five minutes plagues Java programmers for years.
>     -Peter Seibel "
>
> and had a very interesting response,
> ""So an annoyance that Common Lisp programmers can resolve for
> themselves within five minutes plagues Java programmers for years."
> ...which is great, until someone else has to use your code. Have
> you ever tried using someone's highly customized EMACS setup?
> Maybe they've made it more like Wordstar, or changed the exit
> key. Maybe their meta is their control key, and their control key
> is their caps lock key. The result is that you not only have to be
> used to reading someone's algorithms, you have to be used to
> reading their dialect. As such, I have the same rules on LISP
> programming that I do with perl - I hate it unless I wrote it."
>
> After reading a few other threads here, it seems like this does
> present a bit of problem and was wondering if any of the Lisp
> veterans would care to comment. Practical Common Lisp is my
> first exposure to the langauge and I was wondering if anyone would
> care to comment?

Ernst van Waning had a good talk on this topic, with the appropriate
cautions and tradeoffs.
http://lisp.tech.coop/lisp-user-meeting-amsterdam-april-2004#macros-and-codewalkers

Macros are generally meant to make your program clearer. Without
macros, people often write creaky spaghetti code, always having to
remember to close some resource in a FINALLY block and whatnot. I
really doubt people can pull off readable code without macros, except
in toy programs where the language already expresses the domain very
well.

When writing macros, it's often important to have helpful error
messages which point out when it's being used incorrectly. Be kind to
the schmoe using your code.

Many (certainly most?) macros people use aren't their own. For example,
with-open-file and loop were baked into the spec after (presumably) a
lot of use and demand. Like any democratizing element, macros sound
quite scary to the uninitiated; responsibility and education are indeed
vital for it to work.

At a workshop, a Symbolics guy mentioned his team's policy towards
macros. It was something along the lines of, "Functions are always ok.
Macros require a fair amount of scrutiny and justification. Read-macros
REALLY require justification." (I hope I didn't totally butcher his
point.)
http://ll2.ai.mit.edu/

I'm sure your respondent's nightmare scenario happened somewhere. In
any language, people write loops that don't terminate (but should),
intricate functions thousands of lines along, etc. I certainly abused
macros when starting out, in order to learn how to use them, just as
I've abused OOP and whatnot.
From: Tayssir John Gabbour
Subject: Re: Wondering if you guys would like to comment on this
Date: 
Message-ID: <1115408965.756020.163410@f14g2000cwb.googlegroups.com>
Tayssir John Gabbour wrote:
> ·······@gmail.com wrote:
> > After reading a few other threads here, it seems like this does
> > present a bit of problem and was wondering if any of the Lisp
> > veterans would care to comment. Practical Common Lisp is my
> > first exposure to the langauge and I was wondering if anyone would
> > care to comment?
>
> Ernst van Waning had a good talk on this topic, with the appropriate
> cautions and tradeoffs.
>
http://lisp.tech.coop/lisp-user-meeting-amsterdam-april-2004#macros-and-codewalkers
>
> Macros are generally meant to make your program clearer. Without
> macros, people often write creaky spaghetti code, always having to
> remember to close some resource in a FINALLY block and whatnot. I
> really doubt people can pull off readable code without macros, except
> in toy programs where the language already expresses the domain very
> well.
>
> When writing macros, it's often important to have helpful error
> messages which point out when it's being used incorrectly. Be kind to
> the schmoe using your code.

Incidentally, I hope I didn't make macros sound like drudgery. I mainly
use Lisp for personal things which are then converted to other
languages. So it's not like I ever think about error messages. If I
were releasing a complex, nonidiomatic macro to others though...

It is like any other tool. Fire burns, knives cut; once we're used to
some simple caveats, we can build societies with them.
From: Matthias Buelow
Subject: Re: Wondering if you guys would like to comment on this
Date: 
Message-ID: <3e0163Fh3vbU2@news.dfncis.de>
·······@gmail.com wrote:

>""So an annoyance that Common Lisp programmers can resolve for
>themselves within five minutes plagues Java programmers for years."
>...which is great, until someone else has to use your code. Have you
>ever tried using someone's highly customized EMACS setup? Maybe

Why should he want to do that?  Is he arguing against configurable
software?

>they've made it more like Wordstar, or changed the exit key. Maybe
>their meta is their control key, and their control key is their caps
>lock key. The result is that you not only have to be used to reading

The man's a bit declued.. control/meta/capslock are (on X11)
configured in the X server, via xmodmap etc.  What's emacs got
to do with that?  [for my convenience, I have made capslock an
additional control key, for example.. should I not be allowed to
do that?]

>someone's algorithms, you have to be used to reading their dialect.
>As such, I have the same rules on LISP programming that I do with perl
>- I hate it unless I wrote it."

One can write weird rubbish in about every language.
I don't really understand what he's arguing for.. removing all
extensibility from Lisp?  Or what's he trying to say?

mkb.
From: Ulrich Hobelmann
Subject: Re: Wondering if you guys would like to comment on this
Date: 
Message-ID: <3e1afrFmgojU2@individual.net>
Matthias Buelow wrote:
> One can write weird rubbish in about every language.
> I don't really understand what he's arguing for.. removing all
> extensibility from Lisp?  Or what's he trying to say?

I think so.  After all, any macro that you have to use or maintain 
should be documented, so use shouldn't be a problem any less than 
reusing a class or function written by someone else.

The belief is that making everybody equally weak and powerless 
will somehow prevent the stupid from making mistakes, or from 
being trampled over by an army of programmer gurus. ;D

-- 
No man is good enough to govern another man without that other's 
consent. -- Abraham Lincoln
From: Christopher Koppler
Subject: Re: Wondering if you guys would like to comment on this
Date: 
Message-ID: <pan.2005.05.06.13.55.00.292254@chello.at>
On Fri, 06 May 2005 08:41:15 -0500, Ulrich Hobelmann wrote:

> The belief is that making everybody equally weak and powerless 
> will somehow prevent the stupid from making mistakes, or from 
> being trampled over by an army of programmer gurus. ;D

Finally, an army I'd join straight away! Where's boot camp? :-)

-- 
Christopher
From: Paolo Amoroso
Subject: Re: Wondering if you guys would like to comment on this
Date: 
Message-ID: <874qdgto0h.fsf@plato.moon.paoloamoroso.it>
Christopher Koppler <········@chello.at> writes:

> On Fri, 06 May 2005 08:41:15 -0500, Ulrich Hobelmann wrote:
>
>> The belief is that making everybody equally weak and powerless 
>> will somehow prevent the stupid from making mistakes, or from 
>> being trampled over by an army of programmer gurus. ;D
>
> Finally, an army I'd join straight away! Where's boot camp? :-)

You can read the admission instructions here:

  http://www.gigamonkeys.com/book


Paolo
-- 
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (see also http://clrfi.alu.org):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
From: Christopher Koppler
Subject: Re: Wondering if you guys would like to comment on this
Date: 
Message-ID: <pan.2005.05.06.15.50.38.460097@chello.at>
On Fri, 06 May 2005 16:41:50 +0200, Paolo Amoroso wrote:

> Christopher Koppler <········@chello.at> writes:
> 
>> On Fri, 06 May 2005 08:41:15 -0500, Ulrich Hobelmann wrote:
>>
>>> The belief is that making everybody equally weak and powerless 
>>> will somehow prevent the stupid from making mistakes, or from 
>>> being trampled over by an army of programmer gurus. ;D
>>
>> Finally, an army I'd join straight away! Where's boot camp? :-)
> 
> You can read the admission instructions here:
> 
>   http://www.gigamonkeys.com/book
> 

Hey, my dead-tree edition just arrived this Tuesday, it's great. I'd
consider On Lisp as 'guru' boot camp however, I still don't get half of it ;-)

-- 
Christopher
From: Steven M. Haflich
Subject: Re: Wondering if you guys would like to comment on this
Date: 
Message-ID: <FpYee.14016$J12.11469@newssvr14.news.prodigy.com>
Ulrich Hobelmann wrote:

> I think so.  After all, any macro that you have to use or maintain 
> should be documented
And given the power of Lisp macros it is easy to enforce this
requirement:

(defmacro deafmacro (name lambda-list &body body)
   `(defmacro ,name ,lambda-list
      "This macro is otherwise undocumented."
      ,@body))

Before anyone accuses me of criticusing Lisp, spend a few minutes
trying to figure out a Java class from its JavaDoc.  It is usually
easier and faster to read clear, well-written, convention-obeying
code than it is to read documentation about less-well-written code.

The only advantage of documentation is that it can make clear which
aspects of the interface are guaranteed and which are mere accidents
of implementation.

But remember Haflich's Fourth Corollary of Coding:  "Accidents of
implementation in well-written algorithmic code are not accidents."
From: Ulrich Hobelmann
Subject: Re: Wondering if you guys would like to comment on this
Date: 
Message-ID: <3e4nvvF17bs7U2@individual.net>
Steven M. Haflich wrote:
> Before anyone accuses me of criticusing Lisp, spend a few minutes
> trying to figure out a Java class from its JavaDoc.  It is usually
> easier and faster to read clear, well-written, convention-obeying
> code than it is to read documentation about less-well-written code.

I don't think so.  It distracts me, and I much prefer to just read 
the interface docs, like Sun's excellent online Javadocs, or Unix 
manpages.

> The only advantage of documentation is that it can make clear which
> aspects of the interface are guaranteed and which are mere accidents
> of implementation.

In my experience most "official" (Sun, or BSD) docs are very clear.

-- 
No man is good enough to govern another man without that other's 
consent. -- Abraham Lincoln
From: Coby Beck
Subject: Re: Wondering if you guys would like to comment on this
Date: 
Message-ID: <Xasfe.31229$0X6.13269@edtnps90>
"Ulrich Hobelmann" <···········@web.de> wrote in message 
···················@individual.net...
> Steven M. Haflich wrote:
>> Before anyone accuses me of criticusing Lisp, spend a few minutes
>> trying to figure out a Java class from its JavaDoc.  It is usually
>> easier and faster to read clear, well-written, convention-obeying
>> code than it is to read documentation about less-well-written code.
>
> I don't think so.  It distracts me, and I much prefer to just read the 
> interface docs, like Sun's excellent online Javadocs, or Unix manpages.
>
>> The only advantage of documentation is that it can make clear which
>> aspects of the interface are guaranteed and which are mere accidents
>> of implementation.
>
> In my experience most "official" (Sun, or BSD) docs are very clear.

This comparison is inappropriate and misses the point.  Hyperspec standard 
CL macros are also very clearly and thouroughly documented.  The criticism 
at the top of this thread is about user defined macros , so you must compare 
them to user defined classes and methods.

The fundamental nature of the advantages of defining and the dangers of 
using your own domain/application specific constructs are identical for all 
of methods, functions, classes, variables and macros so all the arguments 
about documentation and readability can not justly be applied only to 
macros.

The only supportable argument that is specific to macros is the one that 
centers on their relative power versus classes and methods.  Thus the 
dangers perhaps really are greater, in proportion to the advantages and such 
an argument is always at the root of the anti-lisp-macro attacks.

It is hard to argue against it, because it is fear based, so I won't bother 
now.  But the interesting thing to note is that it is almost always advanced 
by people with no real Lisp background.  It is also worth noting that if it 
were true there should be some empirical evidence.

-- 
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")
From: Ulrich Hobelmann
Subject: Re: Wondering if you guys would like to comment on this
Date: 
Message-ID: <3e72vsF1hoimU1@individual.net>
Coby Beck wrote:
> "Ulrich Hobelmann" <···········@web.de> wrote in message 
> ···················@individual.net...
> 
>>Steven M. Haflich wrote:
>>
>>>Before anyone accuses me of criticusing Lisp, spend a few minutes
>>>trying to figure out a Java class from its JavaDoc.  It is usually
>>>easier and faster to read clear, well-written, convention-obeying
>>>code than it is to read documentation about less-well-written code.
>>
>>I don't think so.  It distracts me, and I much prefer to just read the 
>>interface docs, like Sun's excellent online Javadocs, or Unix manpages.
>>
>>
>>>The only advantage of documentation is that it can make clear which
>>>aspects of the interface are guaranteed and which are mere accidents
>>>of implementation.
>>
>>In my experience most "official" (Sun, or BSD) docs are very clear.
> 
> 
> This comparison is inappropriate and misses the point.  Hyperspec standard 
> CL macros are also very clearly and thouroughly documented.  The criticism 
> at the top of this thread is about user defined macros , so you must compare 
> them to user defined classes and methods.

What I meant is that I prefer reading usage documentation to 
reading code by other people, because all that code distracts from 
the usage info that's all I want.

Therefore I expect a macro (especially since it is more powerful 
than a function) to be well-documented.

> The fundamental nature of the advantages of defining and the dangers of 
> using your own domain/application specific constructs are identical for all 
> of methods, functions, classes, variables and macros so all the arguments 
> about documentation and readability can not justly be applied only to 
> macros.

Yep.  What applies to Java class documentation also usually works 
for macros.  I don't care what the macro code looks like internally.

-- 
No man is good enough to govern another man without that other's 
consent. -- Abraham Lincoln
From: David Steuber
Subject: Re: Wondering if you guys would like to comment on this
Date: 
Message-ID: <87vf5tdyfd.fsf@david-steuber.com>
Ulrich Hobelmann <···········@web.de> writes:

> What I meant is that I prefer reading usage documentation to reading
> code by other people, because all that code distracts from the usage
> info that's all I want.
> 
> Therefore I expect a macro (especially since it is more powerful than
> a function) to be well-documented.

What do you do when your expectations are not met?

-- 
An ideal world is left as an excercise to the reader.
   --- Paul Graham, On Lisp 8.1
No excuses.  No apologies.  Just do it.
   --- Erik Naggum
From: Ulrich Hobelmann
Subject: Re: Wondering if you guys would like to comment on this
Date: 
Message-ID: <3e7q6cF1kiqbU1@individual.net>
David Steuber wrote:
> Ulrich Hobelmann <···········@web.de> writes:
> 
> 
>>What I meant is that I prefer reading usage documentation to reading
>>code by other people, because all that code distracts from the usage
>>info that's all I want.
>>
>>Therefore I expect a macro (especially since it is more powerful than
>>a function) to be well-documented.
> 
> 
> What do you do when your expectations are not met?
> 

The same I'd do if Sun had crappy documentation, or anyone else: 
tell the programmer.  If he isn't around anymore (and if I have 
the code and have to maintain it), take time to decipher the macro 
code and document it.  Maybe the original coder can be reached by 
email and answer questions, too.

Still, documentation is important.  Reading code can only tell 
you, *how* stuff is done, not always why.

-- 
No man is good enough to govern another man without that other's 
consent. -- Abraham Lincoln
From: Tim X
Subject: Re: Wondering if you guys would like to comment on this
Date: 
Message-ID: <87psw37588.fsf@tiger.rapttech.com.au>
Matthias Buelow <···@incubus.de> writes:

> ·······@gmail.com wrote:
>
>>""So an annoyance that Common Lisp programmers can resolve for
>>themselves within five minutes plagues Java programmers for years."
>>...which is great, until someone else has to use your code. Have you
>>ever tried using someone's highly customized EMACS setup? Maybe
>
> Why should he want to do that?  Is he arguing against configurable
> software?

No, I don't think so. I've had the same experience with perl that he
seems to be referencing. One of the big 'selling points' of perl was
the idea of letting you do it your way. I've found this can be a
problem when working on a large perl project with multiple developers
- often, it takes a lot of work to begin to read someone elses perl
style when it is very different to your own style. While this can be a
problem with any programming language, perl tends to make it worse
because it supports such a large set of styles, plus it makes such
extensive use of 'hidden' or default variables.There tends to be a
slight tendency in some quarters of the perl community to show off how
clever you are by writing code with the minimal amount of characters
and using a lot of the default variables and side effects etc. I've
seen bits of code which really look like 'machine noise' I use to
sometimes see when working with serial ports connected to other
hardware. 

I don't see this sort of problem with CL. For a start, CL has a much
more consistent syntax than perl - well perl's syntax is consistent,
but it has multiple ways of writing exactly the same thing - with
brackets or whitout, explicit loop variables or implicit ones,
multiple ways of representing subroutine arguements - with prototypes,
without, functions which behave differently depending on the context
they are called in - maybe return a scalar, maybe return a list etc. 

I also think the person who wrote the review didn't really understand
macros in CL nd how they are used. I get the impression he feels that
people would use/abuse the macros to create a new language which
anyone having to maintain the system would have to learn before being
able to work with it. While this could be done, in practice, people
usually only use the macros when there is a need and tend to use them
in a way which is consistent with how the language works/looks. 

>>they've made it more like Wordstar, or changed the exit key. Maybe
>>their meta is their control key, and their control key is their caps
>>lock key. The result is that you not only have to be used to reading
>
> The man's a bit declued.. control/meta/capslock are (on X11)
> configured in the X server, via xmodmap etc.  What's emacs got
> to do with that?  [for my convenience, I have made capslock an
> additional control key, for example.. should I not be allowed to
> do that?]

Actually, in emacs, you can rebind pretty much any key. Xmodmap is a
lower level operation. Often, you do both. For example, emacs has the
convention of binding some functions to the 'meta' key. Some keyboards
and operating systems can/do view 'meta' and 'alt' as different keys,
while others dn't have a 'meta' key, just alt. On some platforms,
emacs would view left alt as meta and write alt as alt. I often use
different X keyboard maps and xmodmap to define things like the
'windows' key as meta etc. I then bind various functions within emacs
to these keys. 

The original authors arguemnt is still however very flawed or an
exageration of a real problem. I've had to use other peoples emacs
from time to time and all you have to do is use the various command
line arguments to bypass their configuration so taht everything goes
back to the default settings - so its not a 'real' problem. You can
even tell emacs which configuration file to use, so you could even
point it at your own .emacs and have all your own config options. 


>>someone's algorithms, you have to be used to reading their dialect.
>>As such, I have the same rules on LISP programming that I do with perl
>>- I hate it unless I wrote it."
>
> One can write weird rubbish in about every language.
> I don't really understand what he's arguing for.. removing all
> extensibility from Lisp?  Or what's he trying to say?

Agreed - you can write rubbish in anything. I've also found it is
usual to have to spend some time to get to know someone elses style no
matter what the language is. As mentioned, perl is the worst I've come
across. CL could be bad if the original coder was one of those
developers who insists in trying to redefine the language rather than
working with it - for example, imagine a C programmer coming to CL,
learning macros, writing a heap of macros to essentially create a
language like C inside CL. Now, you get a job to maintain this system
and you are told its written in CL. However, when you open the first
source file, you see something which looks like a mutated C and you
wonder what the hell is going on. However, the problem here is not
with the language, its with how it was used and any tool can be
abused. Possibly the only justified criticism whoule be to say the
language is too powerful - but that somehow seems to be a silly thing
to say!

-- 
Tim Cross
The e-mail address on this message is FALSE (obviously!). My real e-mail is
to a company in Australia called rapttech and my login is tcross - if you 
really need to send mail, you should be able to work it out!
From: Pascal Bourguignon
Subject: Re: Wondering if you guys would like to comment on this
Date: 
Message-ID: <87vf5vxor6.fsf@thalassa.informatimago.com>
Tim X <····@spamto.devnul.com> writes:
> [...] There tends to be a
> slight tendency in some quarters of the perl community to show off how
> clever you are by writing code with the minimal amount of characters
> and using a lot of the default variables and side effects etc. I've
> seen bits of code which really look like 'machine noise' I use to
> sometimes see when working with serial ports connected to other
> hardware. 

Imagine all these valuable programs we lost when we watched modems handshake!

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
In deep sleep hear sound,
Cat vomit hairball somewhere.
Will find in morning.
From: William Bland
Subject: Re: Wondering if you guys would like to comment on this
Date: 
Message-ID: <pan.2005.05.06.02.16.41.840978@abstractnonsense.com>
On Thu, 05 May 2005 18:29:39 -0700, pjhyett wrote:

> I posted this quote from Practical Common Lisp on my blog this
> afternoon:
[snip]
> 
> and had a very interesting response,
> ""So an annoyance that Common Lisp programmers can resolve for
> themselves within five minutes plagues Java programmers for years."
> ...which is great, until someone else has to use your code.

Yup, I completely agree with this.  It's a complete pain to understand
anyone's code when they use macros.  I'm considering using Lisp for more
projects, but we certainly won't be using macros.  I don't want to spend
hours each time I see a macro finding out what it does.

Likewise, I'm probably going to ban the use of functions - they're just as
bad.  Each time I see a function in a piece of Lisp code it takes me
*ages* to find out what it's supposed to do.  I'm going to disallow them
and make people write out the code in full - they're just trying to be too
clever and lazy when they write functions.  Variables are awful too.  I
keep seeing references to variables and having to find their definitions
and read the comments to find out what they do.  I think I'm going to ban
them as well.  Once I've laid out these ground rules though, I think I'm
going to end up with some great software!

Cheers,
	Bill.
From: Brad Anderson
Subject: Re: Wondering if you guys would like to comment on this
Date: 
Message-ID: <D0Bee.1451$7U.1267@newssvr30.news.prodigy.com>
William Bland wrote:
>>and had a very interesting response,
>>""So an annoyance that Common Lisp programmers can resolve for
>>themselves within five minutes plagues Java programmers for years."
>>...which is great, until someone else has to use your code.
> 
> 
> Yup, I completely agree with this.  It's a complete pain to understand
> anyone's code when they use macros.  I'm considering using Lisp for more
> projects, but we certainly won't be using macros.  I don't want to spend
> hours each time I see a macro finding out what it does.
> 
> Likewise, I'm probably going to ban the use of functions - they're just as
> bad.  Each time I see a function in a piece of Lisp code it takes me
> *ages* to find out what it's supposed to do.  I'm going to disallow them
> and make people write out the code in full - they're just trying to be too
> clever and lazy when they write functions.  Variables are awful too.  I
> keep seeing references to variables and having to find their definitions
> and read the comments to find out what they do.  I think I'm going to ban
> them as well.  Once I've laid out these ground rules though, I think I'm
> going to end up with some great software!
> 
> Cheers,
> 	Bill.

Some around here and on other Lisp-phobic sites 
*cough*slash*cough*dot*cough seem to not like parentheses, so in 
addition to the measures outlined above, I will further omit parentheses 
from the approved tool arsenal.  And as for text files to actually hold 
the code ... well, that's one helluva can of worms.  ASCII, UTF-8, \n or 
\r\n - who knows what you're going to get.  Better to just have them 
type directly into the REPL.

BA
From: Alexander Schreiber
Subject: Re: Wondering if you guys would like to comment on this
Date: 
Message-ID: <slrnd7m8m3.o1b.als@mordor.angband.thangorodrim.de>
Brad Anderson <····@dsource.org> wrote:
> William Bland wrote:
>>>and had a very interesting response,
>>>""So an annoyance that Common Lisp programmers can resolve for
>>>themselves within five minutes plagues Java programmers for years."
>>>...which is great, until someone else has to use your code.
>> 
>> 
>> Yup, I completely agree with this.  It's a complete pain to understand
>> anyone's code when they use macros.  I'm considering using Lisp for more
>> projects, but we certainly won't be using macros.  I don't want to spend
>> hours each time I see a macro finding out what it does.
>> 
>> Likewise, I'm probably going to ban the use of functions - they're just as
>> bad.  Each time I see a function in a piece of Lisp code it takes me
>> *ages* to find out what it's supposed to do.  I'm going to disallow them
>> and make people write out the code in full - they're just trying to be too
>> clever and lazy when they write functions.  Variables are awful too.  I
>> keep seeing references to variables and having to find their definitions
>> and read the comments to find out what they do.  I think I'm going to ban
>> them as well.  Once I've laid out these ground rules though, I think I'm
>> going to end up with some great software!
>> 
>> Cheers,
>> 	Bill.
> 
> Some around here and on other Lisp-phobic sites 
> *cough*slash*cough*dot*cough seem to not like parentheses, so in 
> addition to the measures outlined above, I will further omit parentheses 
> from the approved tool arsenal.  And as for text files to actually hold 
> the code ... well, that's one helluva can of worms.  ASCII, UTF-8, \n or 
> \r\n - who knows what you're going to get.  Better to just have them 
> type directly into the REPL.

But what are you going to do for documentation and archiving of code?
You need to put it into some kind of files. But simple text files are
just too messy, you are right. Better use some industry standard file
format like Microsoft Word .doc files. That way, even the boos can read
the code and check for superfluous nonsense - like wasting lines of code
with checking for errors that he knows will never happen.

HTH,
  Alex.
-- 
"Opportunity is missed by most people because it is dressed in overalls and
 looks like work."                                      -- Thomas A. Edison
From: Tim X
Subject: Re: Wondering if you guys would like to comment on this
Date: 
Message-ID: <87ll6r74vi.fsf@tiger.rapttech.com.au>
Alexander Schreiber <···@usenet.thangorodrim.de> writes:

>> 
>> Some around here and on other Lisp-phobic sites 
>> *cough*slash*cough*dot*cough seem to not like parentheses, so in 
>> addition to the measures outlined above, I will further omit parentheses 
>> from the approved tool arsenal.  And as for text files to actually hold 
>> the code ... well, that's one helluva can of worms.  ASCII, UTF-8, \n or 
>> \r\n - who knows what you're going to get.  Better to just have them 
>> type directly into the REPL.
>
> But what are you going to do for documentation and archiving of code?
> You need to put it into some kind of files. But simple text files are
> just too messy, you are right. Better use some industry standard file
> format like Microsoft Word .doc files. That way, even the boos can read
> the code and check for superfluous nonsense - like wasting lines of code
> with checking for errors that he knows will never happen.
>
No - MS Word is a closed format. We need something open - like XML!
All we have to do is agree on a standard DTD for representing CL code
- that shouldn't be too hard.

Tim
-- 
Tim Cross
The e-mail address on this message is FALSE (obviously!). My real e-mail is
to a company in Australia called rapttech and my login is tcross - if you 
really need to send mail, you should be able to work it out!
From: Ulrich Hobelmann
Subject: Re: Wondering if you guys would like to comment on this
Date: 
Message-ID: <3e4o6kF17bs7U3@individual.net>
Tim X wrote:
>>But what are you going to do for documentation and archiving of code?
>>You need to put it into some kind of files. But simple text files are
>>just too messy, you are right. Better use some industry standard file
>>format like Microsoft Word .doc files. That way, even the boos can read
>>the code and check for superfluous nonsense - like wasting lines of code
>>with checking for errors that he knows will never happen.
>>
> 
> No - MS Word is a closed format. We need something open - like XML!
> All we have to do is agree on a standard DTD for representing CL code
> - that shouldn't be too hard.

I think using .doc was meant with a bit of irony.  Anyway, XML is 
only a metaformat, just like ASCII (or rather s-exprs).

Wrapping CL code (s-exprs) in XML is the most perverted thing I've 
ever heard. ;)

I hope your post is irony, too :D

-- 
No man is good enough to govern another man without that other's 
consent. -- Abraham Lincoln
From: Alexander Schreiber
Subject: Re: Wondering if you guys would like to comment on this
Date: 
Message-ID: <slrnd7qetl.ach.als@mordor.angband.thangorodrim.de>
Ulrich Hobelmann <···········@web.de> wrote:
> Tim X wrote:
>>>But what are you going to do for documentation and archiving of code?
>>>You need to put it into some kind of files. But simple text files are
>>>just too messy, you are right. Better use some industry standard file
>>>format like Microsoft Word .doc files. That way, even the boos can read
>>>the code and check for superfluous nonsense - like wasting lines of code
>>>with checking for errors that he knows will never happen.
>>>
>> 
>> No - MS Word is a closed format. We need something open - like XML!
>> All we have to do is agree on a standard DTD for representing CL code
>> - that shouldn't be too hard.
>
> I think using .doc was meant with a bit of irony.

No, it wasn't.

It was meant with a metric ton of irony. The "industry standard" should
have been a dead giveaway. Looks like should have sprinkled some smilies
onto the posting ...

> Wrapping CL code (s-exprs) in XML is the most perverted thing I've 
> ever heard. ;)

Then you haven't seen a lot of modern software, I suppose. There _must_
be a competition about who can build the most peverse system. I'm damn
sure about it because that is the only _optimistic_ explanation for all
the crap I've seen so far. The other explanation is probably closer to
the truth: that there are plenty of "programmers" out there who need to
have their fingers broken - all of them, just to make sure they'll
never touch a keyboard (or mouse, for that matter) again.

Regards,
      Alex.
-- 
"Opportunity is missed by most people because it is dressed in overalls and
 looks like work."                                      -- Thomas A. Edison
From: Tim X
Subject: Re: Wondering if you guys would like to comment on this
Date: 
Message-ID: <87y8aq58bm.fsf@tiger.rapttech.com.au>
Ulrich Hobelmann <···········@web.de> writes:

> Tim X wrote:
>>>But what are you going to do for documentation and archiving of code?
>>>You need to put it into some kind of files. But simple text files are
>>>just too messy, you are right. Better use some industry standard file
>>>format like Microsoft Word .doc files. That way, even the boos can read
>>>the code and check for superfluous nonsense - like wasting lines of code
>>>with checking for errors that he knows will never happen.
>>>
>> No - MS Word is a closed format. We need something open - like XML!
>> All we have to do is agree on a standard DTD for representing CL code
>> - that shouldn't be too hard.
>
> I think using .doc was meant with a bit of irony.  Anyway, XML is only
> a metaformat, just like ASCII (or rather s-exprs).
>
> Wrapping CL code (s-exprs) in XML is the most perverted thing I've
> ever heard. ;)
>
> I hope your post is irony, too :D
>

No, its my evil plan to subvert management and get CL in through the
back door by claiming its based on XML - you see, all you need to do
to get a new product accepted these days is state that its XML based
and your away......

hehehehehehehe, ummmm i mean

<laugh type='evil'>hehehehehehehe</laugh>


-- 
Tim Cross
The e-mail address on this message is FALSE (obviously!). My real e-mail is
to a company in Australia called rapttech and my login is tcross - if you 
really need to send mail, you should be able to work it out!
From: Kenny Tilton
Subject: Re: Wondering if you guys would like to comment on this
Date: 
Message-ID: <doDee.18503$mp6.3510125@twister.nyc.rr.com>
William Bland wrote:
> On Thu, 05 May 2005 18:29:39 -0700, pjhyett wrote:
> 
> 
>>I posted this quote from Practical Common Lisp on my blog this
>>afternoon:
> 
> [snip]
> 
>>and had a very interesting response,
>>""So an annoyance that Common Lisp programmers can resolve for
>>themselves within five minutes plagues Java programmers for years."
>>...which is great, until someone else has to use your code.
> 
> 
> Yup, I completely agree with this.  It's a complete pain to understand
> anyone's code when they use macros.  I'm considering using Lisp for more
> projects, but we certainly won't be using macros.  I don't want to spend
> hours each time I see a macro finding out what it does.
> 
> Likewise, I'm probably going to ban the use of functions - they're just as
> bad.  Each time I see a function in a piece of Lisp code it takes me
> *ages* to find out what it's supposed to do.  I'm going to disallow them
> and make people write out the code in full - they're just trying to be too
> clever and lazy when they write functions.  Variables are awful too.  I
> keep seeing references to variables and having to find their definitions
> and read the comments to find out what they do.  I think I'm going to ban
> them as well.  Once I've laid out these ground rules though, I think I'm
> going to end up with some great software!

Dream on. You have banned neither defclass nor defmethod. Have you no 
idea of the confusion and obfuscation resulting from the amount of 
semantics that can be hidden behind those tools of Satan?

Good for you, though, on pointing out the hazards of variables. I missed 
that one. From now on it's all literals all the time for me.

kenny

-- 
Cells? Cello? Cells-Gtk?: http://www.common-lisp.net/project/cells/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film

"Doctor, I wrestled with reality for forty years, and I am happy to 
state that I finally won out over it." -- Elwood P. Dowd
From: Rob Warnock
Subject: Re: Wondering if you guys would like to comment on this
Date: 
Message-ID: <KKidncgZi8MP2ubfRVn-rQ@speakeasy.net>
Kenny Tilton  <·······@nyc.rr.com> wrote:
+---------------
| William Bland wrote:
| > Variables are awful too.  I keep seeing references to variables
| > and having to find their definitions and read the comments to find
| > out what they do.  I think I'm going to ban them as well.
...
| Good for you, though, on pointing out the hazards of variables.
| I missed  that one. From now on it's all literals all the time for me.
+---------------

Actually, I think Bill Wulf first pointed out that one, in a classic
little CACM(?) article, "Global Variable Considered Harmful" [published
after and in the style o fDijkstra's "GOTO Considered Harmful", yes],
in which he pointed out that no matter how "structured" your code was,
a single global variable and a single loop with a single CASE statement
could implement an arbitrary spaghetti nest of GOTOs. That is, there's a
direct and simple mapping between an arbitrarily-complex TAGBODY and this:

	(let ((state 'start))
	  (loop
	    (case state
	      ...{lots of cases that (SETF state {something})}...)))


-Rob

-----
Rob Warnock			<····@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607
From: ···············@yahoo.com
Subject: Re: Wondering if you guys would like to comment on this
Date: 
Message-ID: <1115399228.389004.113560@o13g2000cwo.googlegroups.com>
> From now on it's all literals all the time for me.

>From May 6 1:37 a.m. on it's all literals all the time for Kenny
Tilton.
From: Kenny Tilton
Subject: Re: Wondering if you guys would like to comment on this
Date: 
Message-ID: <BmOee.16382$n93.10870@twister.nyc.rr.com>
···············@yahoo.com wrote:
>>From now on it's all literals all the time for me.
> 
> 
>>From May 6 1:37 a.m. on it's all literals all the time for Kenny
> Tilton.

"May" should be 5.

:)

kt

-- 
Cells? Cello? Cells-Gtk?: http://www.common-lisp.net/project/cells/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film

"Doctor, I wrestled with reality for forty years, and I am happy to 
state that I finally won out over it." -- Elwood P. Dowd
From: Espen Vestre
Subject: Re: Wondering if you guys would like to comment on this
Date: 
Message-ID: <kwsm10a1er.fsf@merced.netfonds.no>
Kenny Tilton <·······@nyc.rr.com> writes:

> Dream on. You have banned neither defclass nor defmethod. Have you no
> idea of the confusion and obfuscation resulting from the amount of
> semantics that can be hidden behind those tools of Satan?
>
> Good for you, though, on pointing out the hazards of variables. I
> missed that one. From now on it's all literals all the time for me.

Are you looking for consultancy work in an Amish community ;)?
-- 
  (espen)
From: Steven M. Haflich
Subject: Re: Wondering if you guys would like to comment on this
Date: 
Message-ID: <%PYee.2377$X21.803@newssvr21.news.prodigy.com>
Kenny Tilton wrote:

> Good for you, though, on pointing out the hazards of variables. I missed 
> that one. From now on it's all literals all the time for me.

It is only special variables that are evil, not lexical variables.

Years ago I declared a policy at my company that anyone wanting to add
a new special variable could do so provided he first eliminates two
other special variables.  "Think globally, act locally."  Since then
this policy has been completely ignored, of course.

(I believe I extrapolated this policy from an early proposal for
nuclear disarmament:  If those countries in possession of thermonuclear
weapons agreed to ban production of tritium -- tritium being an
essential component of a fusion weapon and having a half life of 12.3
years -- that would enforce a halving of usable fusion weapons every
12.3 years.  This would be a speed that wuold achieve gradual
disarmament without destabilizing step function changes.)

The problem in CL is that several areas of the language are
intrinsically tied to special variables -- especially the several
stream variables.  I've wondered what would be a good fix for this
language misfeature.  Perhaps requiring the stream variable to the
I/O functions always be passed explicitly and disallowing an optional
with a default *standard-input*/*standard-output* value?  This would
break nearly all existing code, of course...

These are the defined special variables in ANSI CL (exclusing
constant variables):

*
**
***
*break-on-signals*
*compile-file-pathname*
*compile-file-truename*
*compile-print*
*compile-verbose*
*debug-io*
*debugger-hook*
*default-pathname-defaults*
*error-output*
*features*
*gensym-counter*
*load-pathname*
*load-print*
*load-truename*
*load-verbose*
*macroexpand-hook*
*modules*
*package*
*print-array*
*print-base*
*print-case*
*print-circle*
*print-escape*
*print-gensym*
*print-length*
*print-level*
*print-lines*
*print-miser-width*
*print-pprint-dispatch*
*print-pretty*
*print-radix*
*print-readably*
*print-right-margin*
*query-io*
*random-state*
*read-base*
*read-default-float-format*
*read-eval*
*read-suppress*
*readtable*
*standard-input*
*standard-output*
*terminal-io*
*trace-output*
+
++
+++
-
/
//
///
From: Duane Rettig
Subject: Re: Wondering if you guys would like to comment on this
Date: 
Message-ID: <4wtqblcao.fsf@franz.com>
"Steven M. Haflich" <···@alum.mit.edu> writes:

> Kenny Tilton wrote:
> 
> > Good for you, though, on pointing out the hazards of variables. I
> > missed that one. From now on it's all literals all the time for me.
> 
> 
> It is only special variables that are evil, not lexical variables.
> 
> Years ago I declared a policy at my company that anyone wanting to add
> a new special variable could do so provided he first eliminates two
> other special variables.  "Think globally, act locally."  Since then
> this policy has been completely ignored, of course.

That's because it's so hard to think up a new one every time you
remove a couple.  We just can't keep up!

-- 
Duane Rettig    ·····@franz.com    Franz Inc.  http://www.franz.com/
555 12th St., Suite 1450               http://www.555citycenter.com/
Oakland, Ca. 94607        Phone: (510) 452-2000; Fax: (510) 452-0182   
From: Pascal Bourguignon
Subject: Re: Wondering if you guys would like to comment on this
Date: 
Message-ID: <87zmv7y31b.fsf@thalassa.informatimago.com>
"Steven M. Haflich" <···@alum.mit.edu> writes:

> Kenny Tilton wrote:
>
>> Good for you, though, on pointing out the hazards of variables. I
>> missed that one. From now on it's all literals all the time for me.
>
> It is only special variables that are evil, not lexical variables.
>
> Years ago I declared a policy at my company that anyone wanting to add
> a new special variable could do so provided he first eliminates two
> other special variables.  "Think globally, act locally."  Since then
> this policy has been completely ignored, of course.
>
> (I believe I extrapolated this policy from an early proposal for
> nuclear disarmament:  If those countries in possession of thermonuclear
> weapons agreed to ban production of tritium -- tritium being an
> essential component of a fusion weapon and having a half life of 12.3
> years -- that would enforce a halving of usable fusion weapons every
> 12.3 years.  This would be a speed that wuold achieve gradual
> disarmament without destabilizing step function changes.)
>
> The problem in CL is that several areas of the language are
> intrinsically tied to special variables -- especially the several
> stream variables.  I've wondered what would be a good fix for this
> language misfeature.  Perhaps requiring the stream variable to the
> I/O functions always be passed explicitly and disallowing an optional
> with a default *standard-input*/*standard-output* value?  This would
> break nearly all existing code, of course...
>
> These are the defined special variables in ANSI CL (exclusing
> constant variables):

;; Be happy:

(defpackage "COMMON-LISP-NO-SPECIAL"
  (:nickname "CL-NO-SPECIAL")
  (:use-package "COMMON-LISP"))

(in-package "COMMON-LISP-NO-SPECIAL")

(defun list-external-symbols (package &key (sorted t))
  (let ((pack (find-package package)))
    (if pack
      (let ((sl '())) (do-external-symbols (s pack) (push s sl))
           (if sorted (sort sl (function string<)) sl))
      (error "No package ~S" package))))

(export (set-difference (list-external-symbols "COMMON-LISP")   
                        '(
                          *
                          **
                          ***
                          *break-on-signals*
                          *compile-file-pathname*
                          *compile-file-truename*
                          *compile-print*
                          *compile-verbose*
                          *debug-io*
                          *debugger-hook*
                          *default-pathname-defaults*
                          *error-output*
                          *features*
                          *gensym-counter*
                          *load-pathname*
                          *load-print*
                          *load-truename*
                          *load-verbose*
                          *macroexpand-hook*
                          *modules*
                          *package*
                          *print-array*
                          *print-base*
                          *print-case*
                          *print-circle*
                          *print-escape*
                          *print-gensym*
                          *print-length*
                          *print-level*
                          *print-lines*
                          *print-miser-width*
                          *print-pprint-dispatch*
                          *print-pretty*
                          *print-radix*
                          *print-readably*
                          *print-right-margin*
                          *query-io*
                          *random-state*
                          *read-base*
                          *read-default-float-format*
                          *read-eval*
                          *read-suppress*
                          *readtable*
                          *standard-input*
                          *standard-output*
                          *terminal-io*
                          *trace-output*
                          +
                          ++
                          +++
                          -
                          /
                          //
                          ///
                          )))

(defpackage "COMMON-LISP-NO-SPECIAL-USER"
  (:nickname "CL-NO-SPECIAL-USER")
  (:use-package "COMMON-LISP-NO-SPECIAL"))

(in-package "COMMON-LISP-NO-SPECIAL-USER")


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
You're always typing.
Well, let's see you ignore my
sitting on your hands.
From: Stefan Nobis
Subject: Re: Wondering if you guys would like to comment on this
Date: 
Message-ID: <87acn8pwmf.fsf@snobis.de>
William Bland <·······@abstractnonsense.com> writes:

> Yup, I completely agree with this.  It's a complete pain to
> understand anyone's code when they use macros.  I'm considering
> using Lisp for more projects, but we certainly won't be using
> macros.  I don't want to spend hours each time I see a macro
> finding out what it does.

Then you should forbid functions, too. Or do you want spend hours
each time you see a funcall finding out what it does?

I agree, with macros it seems easier to write hard to understand
code, but that's possible in every language with any control
structures. And it's also possible even with macros to write clear
and easy to understand code (i would say: it's even easier).

-- 
Stefan.
From: Wade Humeniuk
Subject: Re: Wondering if you guys would like to comment on this
Date: 
Message-ID: <C2Bee.68992$3V3.66311@edtnps89>
·······@gmail.com wrote:

> 
> After reading a few other threads here, it seems like this does present
> a bit of problem and was wondering if any of the Lisp veterans would
> care to comment. Practical Common Lisp is my first exposure to the
> langauge and I was wondering if anyone would care to comment?
> 

It's the same mentality as a person hating kids playing on their lawn...
....
All that FUN and PLAYING!  And then they speak in that slang, can't
understand a word they are saying. They have to speak in my
language!  How dare they make up words!  And they are so LOUD.
I also saw their spelling the other day, atrocious!

...

I am thankful Lisp programmers are a more adaptable than that.
This problem is way less in Lisp, since if you stick with a
Lispy syntax the extensions (macros) look like Lisp.

Perhaps some people would dig up some un-understandable code
for some specific comments??

Just the other day I coded up a time syntax in cl-yacc.  is this
an example of obtuse code?  (FWIW it took me a good day of
staring at the cl-yacc examples to determine what was going
on.  But I persevered and I think it was well worth it.  This
will useful in the future)
My simple answer to the complaint is that the person is lazy
and his brain has hardened up.

With thanks to Juliusz Chroboczek for writing cl-yacc

(yacc:define-parser *time-parser*
   (:start-symbol time)
   (:terminals (num \: h m s))

   (time colon-time hms-time)
   (sec (num (lambda (s) (list :s s))))

   (colon-time |h:m:s| |m:s| sec) ;; e.g 1:34:21.2

   (|m:s|
    (\:         (lambda (c)     (list :m 0 :s 0)))
    (\: sec     (lambda (c s)   (cons :m (cons 0 s))))
    (num \:     (lambda (m c)   (list :m m :s 0)))
    (num \: sec (lambda (m c s) (cons :m (cons m s)))))

   (|h:m:s|
    (\: |m:s|     (lambda (c m)   (cons :h (cons 0 m))))
    (num \: |m:s| (lambda (h c m) (cons :h (cons h m)))))

   (hms-time |hms| |ms| |s|) ;; e.g 1h34m21.2s

   (|s|
    (num s    (lambda (s i) (list :s s))))

   (|ms|
    (num m        (lambda (m i)   (list :m m :s 0)))
    (num m sec    (lambda (m i s) (cons :m (cons m s))))
    (num m |s|    (lambda (m i s) (cons :m (cons m s)))))

   (|hms|
    (num h        (lambda (h i)   (list :h h :m 0 :s 0)))
    (num h num    (lambda (h i m) (list :h h :m m :s 0)))
    (num h |ms|   (lambda (h i m) (cons :h (cons h m))))
    (num h |s|    (lambda (h i s) (list :h h :m 0 :s (cadr s))))))


Wade
From: Ulrich Hobelmann
Subject: Re: Wondering if you guys would like to comment on this
Date: 
Message-ID: <3e1gqcFo5ncU1@individual.net>
Wade Humeniuk wrote:

> It's the same mentality as a person hating kids playing on their lawn...
> ....
> All that FUN and PLAYING!  And then they speak in that slang, can't
> understand a word they are saying. They have to speak in my
> language!  How dare they make up words!  And they are so LOUD.
> I also saw their spelling the other day, atrocious!

Well, their spelling is really just stupid ;)

Or do you thinc that sp3ll1ng wordz with funny l3tterz iz c0ul?

-- 
No man is good enough to govern another man without that other's 
consent. -- Abraham Lincoln
From: Wade Humeniuk
Subject: Re: Wondering if you guys would like to comment on this
Date: 
Message-ID: <H3Tee.69187$3V3.21021@edtnps89>
Ulrich Hobelmann wrote:
> Wade Humeniuk wrote:
> 
>> It's the same mentality as a person hating kids playing on their lawn...
>> ....
>> All that FUN and PLAYING!  And then they speak in that slang, can't
>> understand a word they are saying. They have to speak in my
>> language!  How dare they make up words!  And they are so LOUD.
>> I also saw their spelling the other day, atrocious!
> 
> 
> Well, their spelling is really just stupid ;)
> 
> Or do you thinc that sp3ll1ng wordz with funny l3tterz iz c0ul?
> 

CL-USER 1> (check-type '(Or do you thinc that sp3ll1ng wordz with funny l3tterz iz c0ul?)
                        'c0ul-sp3ll1ng)
N1L
TRUUEE

CL-USER 2>

Hmm, seems already built into my system.

Wade
From: Duane Rettig
Subject: Re: Wondering if you guys would like to comment on this
Date: 
Message-ID: <4d5s3j25o.fsf@franz.com>
Wade Humeniuk <··················@telus.net> writes:

> Ulrich Hobelmann wrote:
> > Wade Humeniuk wrote:
> >
> 
> >> It's the same mentality as a person hating kids playing on their lawn...
> >> ....
> >> All that FUN and PLAYING!  And then they speak in that slang, can't
> >> understand a word they are saying. They have to speak in my
> >> language!  How dare they make up words!  And they are so LOUD.
> >> I also saw their spelling the other day, atrocious!
> > Well, their spelling is really just stupid ;)
> 
> > Or do you thinc that sp3ll1ng wordz with funny l3tterz iz c0ul?
> 
> >
> 
> 
> CL-USER 1> (check-type '(Or do you thinc that sp3ll1ng wordz with funny l3tterz iz c0ul?)
>                         'c0ul-sp3ll1ng)
> N1L
> TRUUEE
> 
> CL-USER 2>
> 
> Hmm, seems already built into my system.

Yeah, but it's a down-level version;  check out my implementation:

CL-USER(1): (subtypep '(Or do you thinc that sp3ll1ng wordz with funny l3tterz iz c0ul?)
                      'c0ul-sp3ll1ng)
N1L
DOOHD!
CL-USER(2): 

-- 
Duane Rettig    ·····@franz.com    Franz Inc.  http://www.franz.com/
555 12th St., Suite 1450               http://www.555citycenter.com/
Oakland, Ca. 94607        Phone: (510) 452-2000; Fax: (510) 452-0182   
From: Ulrich Hobelmann
Subject: Re: Wondering if you guys would like to comment on this
Date: 
Message-ID: <3e2dahFsgg2U2@individual.net>
Wade Humeniuk wrote:
> CL-USER 1> (check-type '(Or do you thinc that sp3ll1ng wordz with funny 
> l3tterz iz c0ul?)
>                        'c0ul-sp3ll1ng)
> N1L
> TRUUEE
> 
> CL-USER 2>
> 
> Hmm, seems already built into my system.

Lispworks says:
Error: (QUOTE C0UL-SP3LL1NG) is an illegal type specifier.

-- 
No man is good enough to govern another man without that other's 
consent. -- Abraham Lincoln
From: William Bland
Subject: Re: Wondering if you guys would like to comment on this
Date: 
Message-ID: <pan.2005.05.06.23.47.57.645141@abstractnonsense.com>
On Fri, 06 May 2005 23:27:35 +0000, Wade Humeniuk wrote:

> Ulrich Hobelmann wrote:
>> Wade Humeniuk wrote:
>> 
>>> It's the same mentality as a person hating kids playing on their lawn...
>>> ....
>>> All that FUN and PLAYING!  And then they speak in that slang, can't
>>> understand a word they are saying. They have to speak in my
>>> language!  How dare they make up words!  And they are so LOUD.
>>> I also saw their spelling the other day, atrocious!
>> 
>> 
>> Well, their spelling is really just stupid ;)
>> 
>> Or do you thinc that sp3ll1ng wordz with funny l3tterz iz c0ul?
>> 
> 
> CL-USER 1> (check-type '(Or do you thinc that sp3ll1ng wordz with funny l3tterz iz c0ul?)
>                         'c0ul-sp3ll1ng)
> N1L
> TRUUEE
> 
> CL-USER 2>
> 
> Hmm, seems already built into my system.
> 
> Wade

Mine too, but it seems to have different rules.

CL-USER 1> (check-type '(Or do you thinc that sp3ll1ng wordz with funny l3tterz iz c0ul?)
                        'c0ul-sp3ll1ng)
>>  3rr0r:  Unc00l 5p311ing d3t3ct3d d00d!
>>  T0 c0ntinu, typ3 :C0NTINU f0l0w3d bi 4N 0pti0n numb3r:
>>   1: I 4M n0w a c00l h4k0r
>>   2: R3turn t0 Li5p T0pl3v3l.

CL-USER 2>

Perhaps we need to start a CLRFI to standardise this?

Cheers,
	Bill.
From: Juliusz Chroboczek
Subject: Comments about CL-Yacc [was: Wondering...]
Date: 
Message-ID: <7iu0lc42zx.fsf_-_@lanthane.pps.jussieu.fr>
Wade Humeniuk:

> (FWIW it took me a good day of staring at the cl-yacc examples to
> determine what was going on.

I'm always grateful for contributions to the CL-Yacc manual.  (Darcs
patches preferred, plain patches gratefully accepted.)

> With thanks to Juliusz Chroboczek for writing cl-yacc

A pleasure.

(Actually, writing the code was a pleasure, it was deciphering the
Dragon book that was a chore.)

Just a minor comment about your parser.

>   (|hms|
>    (num h        (lambda (h i)   (list :h h :m 0 :s 0)))
>    (num h num    (lambda (h i m) (list :h h :m m :s 0)))
>    (num h |ms|   (lambda (h i m) (cons :h (cons h m))))
>    (num h |s|    (lambda (h i s) (list :h h :m 0 :s (cadr s)))))

A limitation of the current version of CL-Yacc is that if you write an
action as a lambda expression, it will be interpreted at runtime.
(Have a look at how the MAKE-LOAD-FORM method for actions works, and
how it interacts with PARSE-GRAMMAR.)

So if the above is performance critical, put the actions in separate
DEFUNs, and EVAL-WHEN them at compile time (or put them in a different
file).

I'm not quite sure what to do about that, by the way.  The simple fix
would be to call COMPILE on the actions at load time, but that would
make loading compiled parsers slower, and I'm not sure that's a
reasonable tradeoff (opinions?).  A longer-term fix would be to add
the ability to dump a parser into a Lisp file that then goes through
the Lisp compiler; but I'm working on more urgent stuff right now.

                                        Juliusz
From: Wade Humeniuk
Subject: Re: Comments about CL-Yacc [was: Wondering...]
Date: 
Message-ID: <uusge.61534$tg1.52968@edtnps84>
Juliusz Chroboczek wrote:

> A limitation of the current version of CL-Yacc is that if you write an
> action as a lambda expression, it will be interpreted at runtime.
> (Have a look at how the MAKE-LOAD-FORM method for actions works, and
> how it interacts with PARSE-GRAMMAR.)
> 
> So if the above is performance critical, put the actions in separate
> DEFUNs, and EVAL-WHEN them at compile time (or put them in a different
> file).
> 
> I'm not quite sure what to do about that, by the way.  The simple fix
> would be to call COMPILE on the actions at load time, but that would
> make loading compiled parsers slower, and I'm not sure that's a
> reasonable tradeoff (opinions?).  A longer-term fix would be to add
> the ability to dump a parser into a Lisp file that then goes through
> the Lisp compiler; but I'm working on more urgent stuff right now.
> 

My first suggestion would be to create a macro that generates
specific parsing functions that would be similar to cl-yacc:parse-with-lexer.
Right now parse-with-lexer takes a parser which is made up of
of a control strucures (gotos and actions)...

Using one of my simple examples,

(yacc:define-parser *distance-parser*
   (:start-symbol distance)
   (:terminals (id int float))
   (num int float)
   (distance
    (num id)
    (num (lambda (num) (list num nil)))))

I use this parser by calling

(yacc:parse-with-lexer (lambda () (distance-lexer stream)) *distance-parser*)


So instead I would do something like

1->>
(yacc:define-parser-function distance-parser
   (:start-symbol distance)
   (:terminals (id int float))
   (num int float)
   (distance
    (num id)
    (num (lambda (num) (list num nil)))))

which expand to something like

(defun distance-parser () ;; creates a initialized state closure to parse with a lexer
   (let ((stack (list 0))
         (state 0)
         .. other state stuff)
     (lambda (lexer) ;; this function would have the functionality of parse-with-lexer, but
                     ;; with inlined actions and gotos.
        (loop for (lexer-symbol value) = (multiple-value-list (funcall lexer))
           ...........
	  (etypecase (action state lexer-symbol)
              ....
              (#:reduce-action-2 ; corresponds to num
	       set some state stuff, manipulate the stack
                (funcall (lambda (num) (list num nil)) value)) ;;anonynous action-form from
                                                               ;;above
              ... other actions
        ))))

When this distance parser is compiled the anonymous action-forms
would be compiled along with it.  To dump one of these parsers to a source file
you could keep the entire 1->> form for that purpose (or the parse tree generated by
cl-yacc:make-parser).  The define-parser-function could first make the parsing tree by
using cl-yacc:make-parser and then use that structure based parser to generate the
specific function.

Then parsing would be by

(yacc:parse-with-lexer-by-function (lambda () (distance-lexer stream)) #'distance-parser))

where

(defun yacc:parse-with-lexer-by-function (lexer parser-function)
    (funcall (funcall parser) lexer))

Wade
From: Peter Seibel
Subject: Re: Wondering if you guys would like to comment on this
Date: 
Message-ID: <m3ekcldkfu.fsf@gigamonkeys.com>
·······@gmail.com writes:

> I posted this quote from Practical Common Lisp on my blog this
> afternoon:
> "    DOLIST is similar to Perl's foreach or Python's for. Java
> added a similar kind of loop construct with the "enhanced" for loop
> in Java 1.5, as part of JSR-201. Notice what a difference macros make.
> A Lisp programmer who notices a common pattern in their code can write
> a macro to give themselves a source-level abstraction of that pattern.
> A Java programmer who notices the same pattern has to convince Sun that
> this particular abstraction is worth adding to the language. Then Sun
> has to publish a JSR and convene an industry-wide "expert group" to
> hash everything out. That process-according to Sun-takes an average of
> 18 months. After that, the compiler writers all have to go upgrade
> their compilers to support the new feature. And even once the Java
> programmer's favorite compiler supports the new version of Java, they
> probably still can't use the new feature until they're allowed to
> break source compatibility with older versions of Java. So an annoyance
> that Common Lisp programmers can resolve for themselves within five
> minutes plagues Java programmers for years.
>     -Peter Seibel "
>
> and had a very interesting response,
> ""So an annoyance that Common Lisp programmers can resolve for
> themselves within five minutes plagues Java programmers for years."
> ...which is great, until someone else has to use your code. Have you
> ever tried using someone's highly customized EMACS setup? Maybe
> they've made it more like Wordstar, or changed the exit key. Maybe
> their meta is their control key, and their control key is their caps
> lock key. The result is that you not only have to be used to reading
> someone's algorithms, you have to be used to reading their dialect.
> As such, I have the same rules on LISP programming that I do with perl
> - I hate it unless I wrote it."
>
> After reading a few other threads here, it seems like this does present
> a bit of problem and was wondering if any of the Lisp veterans would
> care to comment. Practical Common Lisp is my first exposure to the
> langauge and I was wondering if anyone would care to comment?

Well, I'm not someone else but I have a response nonetheless: macros
are just another way of creating abstractions. If you create good
abstractions it makes your code clearer. If you make bad abstractions
it obfuscates your code. And the analogy to Emacs seems inapt; the
reason it's painful to try and use someone else's highly-customized
Emacs is because they have used the same keys to do different things
and all the key combos you've trained into muscle memory don't do what
you expect. But with macros the name space is much larger (even
ignoring packages) so it's not all that common that someone else will
have written a macro with the same name as a macro you use but that
does something completely different. At worst you'll see some use of a
macro and have to figure out what it does, ether from documentation,
by looking at the source, or, as a last resort from macro expanding
it.

Now it's possible that moving between code bases there may be
similarly named macros with subtly different behaviors but the same
can be said of functions or classes or any other kind of abstraction.

-Peter

P.S. What's the URL of your blog?

-- 
Peter Seibel                                     ·····@gigamonkeys.com

         Lisp is the red pill. -- John Fraser, comp.lang.lisp
From: ·······@gmail.com
Subject: Re: Wondering if you guys would like to comment on this
Date: 
Message-ID: <1115360506.946138.126690@o13g2000cwo.googlegroups.com>
http://pjh.gotdns.com

soon to be pjhyett.com, but the dns hasn't been sorted out yet I
believe.
From: Barry Margolin
Subject: Re: Wondering if you guys would like to comment on this
Date: 
Message-ID: <barmar-012508.08583206052005@comcast.dca.giganews.com>
In article <··············@gigamonkeys.com>,
 Peter Seibel <·····@gigamonkeys.com> wrote:

> Now it's possible that moving between code bases there may be
> similarly named macros with subtly different behaviors but the same
> can be said of functions or classes or any other kind of abstraction.

This also was something that happened in the early days.  There were 
competing designs for the IF macro -- some allowed multiple 
else-clauses, some had explicit THEN or ELSE keywords, etc.  And even 
now, if you have to switch frequently between Common Lisp and Emacs Lisp 
you have to change mindsets a bit, since many of the same function and 
macro names work slightly differently.

But minor details like this shouldn't bother "real programmers".  It's 
like an American going to London and dealing with the slight differences 
in vocabulary between the two English languages.

-- 
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
From: Pascal Costanza
Subject: Re: Wondering if you guys would like to comment on this
Date: 
Message-ID: <3e0lv2Fihk8U1@individual.net>
·······@gmail.com wrote:

> and had a very interesting response,
> ""So an annoyance that Common Lisp programmers can resolve for
> themselves within five minutes plagues Java programmers for years."
> ...which is great, until someone else has to use your code. Have you
> ever tried using someone's highly customized EMACS setup? Maybe
> they've made it more like Wordstar, or changed the exit key. Maybe
> their meta is their control key, and their control key is their caps
> lock key. The result is that you not only have to be used to reading
> someone's algorithms, you have to be used to reading their dialect.
> As such, I have the same rules on LISP programming that I do with perl
> - I hate it unless I wrote it."
> 
> After reading a few other threads here, it seems like this does present
> a bit of problem and was wondering if any of the Lisp veterans would
> care to comment. Practical Common Lisp is my first exposure to the
> langauge and I was wondering if anyone would care to comment?

The comment about Emacs keybindings is unrelated.

The hardest problem about reading someone else's code is to understand 
the problem that is solved and how it is solved. Good Lisp macros allow 
you to express a solution in a way that is closer to the concepts of the 
problem domain. In other languages (without such domain-oriented 
programming facilities), the original programmer had to translate 
everything into the fixed set of abstractions of the language, and in 
order to understand that code, you have to reverse that translation. I 
think that's harder, especially for complex problems.

For Lisp newbies, Lisp code can be hard to read, and it is a natural 
reaction to try to find something to blame. Since Lisp macros are rather 
unusual, it's tempting to blame them.


Pascal

-- 
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
From: Holger Schauer
Subject: Re: Wondering if you guys would like to comment on this
Date: 
Message-ID: <yxzpsw0qdet.fsf@gimli.holgi.priv>
On 4265 September 1993, Pascal Costanza wrote:
> ·······@gmail.com wrote:

>> and had a very interesting response,
[...]
> The comment about Emacs keybindings is unrelated.

No, it's not. I think, what the guy is really up to is expectations
and missing them.

> The hardest problem about reading someone else's code is to understand
> the problem that is solved and how it is solved. Good Lisp macros
> allow you to express a solution in a way that is closer to the
> concepts of the problem domain.

I see the original problem as a typical newcomer problem. 

> For Lisp newbies, Lisp code can be hard to read, and it is a natural
> reaction to try to find something to blame. Since Lisp macros are
> rather unusual, it's tempting to blame them.

Typically, when starting to program in a new language, you learn all
the basic building blocks in a language. Just like you learn the basic
keystrokes of your editor. The gap between the abstractions that
someone experienced may build (or how an experienced Emacs user
modifies Emacs behaviour to his preferred style) and what you are able
to grasp with your new basic knowledge might be huge. If the
abstractions are done well (and as you rightly said, CL provides
probably the best ways for that), bridging the gap is just the next
step on the learning curve. 

However, I believe the guy is missing a serious point that is
absolutely unrelated to the language used. Such problems arise if
there is no coding convention or when encountering a coding convention
you're not used to or which you dislike. 

When I was new to Lisp, I was wondering, why did that silly programmer
invented toy wrappers that just expanded to car/cdr or other "simple"
operators?  Only until later I found out that I was missing the
abstractions, that were there for a reason. I simply had the
expectation that everything should just use those basic building
blocks, and obviously, I was very wrong. Perhaps the guy has never
worked on a larger program, in which building abstractions is the only
way to survive.

There might be another reason for the guys reaction, however. In most
languages, the usage of macros may be really painful. I remember
staring a lot of time on C code in which lots of functionality relied
on many macros, too. Debugging that code was a sheer nightmare.
Perhaps the guy is simply missing macroexpand-1?

Holger

-- 
---          http://www.coling.uni-freiburg.de/~schauer/            ---
"Mit C++ kann man objektorientiert programmieren."
               -- Aus "Wie starte ich einen Endlosthread ?", Teil 815
From: Andreas Thiele
Subject: Re: Wondering if you guys would like to comment on this
Date: 
Message-ID: <d5f8ms$fiv$04$1@news.t-online.com>
<·······@gmail.com> schrieb im Newsbeitrag
·····························@z14g2000cwz.googlegroups.com...
...
> The result is that you not only have to be used to reading
> someone's algorithms, you have to be used to reading their dialect.
> As such, I have the same rules on LISP programming that I do with perl
> - I hate it unless I wrote it."
...
I can only repeat my very first experience with lisp which I came across in
2003 after programming since about 1978. After learning lisp in my spare
time for about 4 month a startet a job on a lisp software. I found it
utterly easy to read the lisp sources. Even mistakes other programmers did
where relatively obvious to me. I think lisp is the best language if you
have to read foreign code.

Regarding macros I think there are two different kinds of lisp programmers.
Programmers with little experience use macros seldomly. So their code is not
very proprietary. Well experienced programmers make good use of macros, so
the code also is readable. I only found those extremes :)

Andreas
From: Lars Rune Nøstdal
Subject: Re: Wondering if you guys would like to comment on this
Date: 
Message-ID: <pan.2005.05.06.08.37.24.675905@gmail.com>
On Thu, 05 May 2005 18:29:39 -0700, pjhyett wrote:

> and had a very interesting response,
> ""So an annoyance that Common Lisp programmers can resolve for
> themselves within five minutes plagues Java programmers for years."
> ...which is great, until someone else has to use your code. Have you
> ever tried using someone's highly customized EMACS setup? Maybe
> they've made it more like Wordstar, 

if i'm coming from a Wordstar-background, this wouldn't be so bad, would
it?

i have the ability to create it more familiar (if i want) than with
for instance java?

what's the problem? i could just choose not to use this setup; there
are plenty to choose from .. 
or as he said; it takes 5 min. to create stuff yourself .. 

yeah, this sucks - i'll use java/whatever instead (and "wait years")

i don't understand what the problem is - we want freedom, but when we
have it; we say that our neighbours are "too free", or something ..

-- 
mvh,
Lars Rune Nøstdal
http://lars.nostdal.org/
From: Ulrich Hobelmann
Subject: Re: Wondering if you guys would like to comment on this
Date: 
Message-ID: <3e1hdlFob4oU1@individual.net>
Lars Rune N�stdal wrote:
> i don't understand what the problem is - we want freedom, but when we
> have it; we say that our neighbours are "too free", or something ..

This pervades society at all levels.  People envy those who drive 
big cars, but they don't want to work 60 hours a week.

They envy you for your good grades, but they don't want to spend 
their free time studying.

People don't want anybody to have it better than them, most of all 
because that would mean that maybe they should have listened to 
those people who told them to study more and watch less TV.  I 
guess it sucks to have made the wrong decisions, so they try to 
punish you by removing that freedom that pays off for you in the 
long run, but not for them, because they chose the easy short-term 
investment.

-- 
No man is good enough to govern another man without that other's 
consent. -- Abraham Lincoln
From: Alan Crowe
Subject: Re: Wondering if you guys would like to comment on this
Date: 
Message-ID: <86mzr85duz.fsf@cawtech.freeserve.co.uk>
P J Hyett worried about macros:
> The result is that you not only have to be used to reading
> someone's algorithms, you have to be used to reading their
> dialect.

This is a fundamental problem with programmable programming
languages. X3J13, the committee that wrote the ANSI Common
Lisp standard seem to have been aware of the issue, and I
argue that they have solved it successfully.

One fascinating piece of history can be read in this note
from the committee:

http://www.lisp.org/HyperSpec/Issues/iss130-writeup.html

The sentence that caught my eye was

      Our charter effectively dictates that where feasible
      we should try to head off the widespread development
      of uselessly different variants of commonplace tools.

This is the key that unlocks understanding of much of Common
Lisp. Once you have DEFMACRO the concept of a commonplace
tool inflates dramatically. If the designers of CL had left
out CLOS or LOOP, programmers would have used macros to put
them back in. Worse, they would have taken the opportunity
of writing their own versions to indulge their whims,
creating uselessly different variants.

If you are designing a programmable programming language,
you have to design a large language with good versions of
all the commonplace tools, or else programmers will use the
programmability to create dialects.

Notice that you cannot get away with minimalist versions of
the tools. JAVA has gone back to the old message passing
model for objects. If the designers of CL had tried to made
that decision for CLOS, they would have provoked users of
generic functions to rebel and write their own object
system, splitting the language into two dialects. Similarly
with multiple inheritance.

The way to avoid the creation of dialects of a programmable
programming language is to design a large language with good
versions of the commonplace tools for general purpose
programming present in the language standard, even though
users could use the programmability to create those tools
themselves. Indeed one might say /especially/ because users
could use the programmability to create those tools
themselves.

Common Lisp is a great success.	I've been through a phase of
creating macros for general purposes and then failing to use
them. Common Lisp is a full feature general purpose
language, right out of the box. There are no real gaps to
fill that justify writing any macros for general purposes.

Note the repetition of the phrase "general purpose". Once
you ask: what would be useful for my application, everything
changes. For example, suppose you are planning on doing a
fair bit of matrix bashing. 

dolist is convenient for processing a list

loop for x across ... is convenient for processing vectors

What about processing the diagonal of a matrix?
One could use an idiom such as

dotimes (i n) ... (aref m i i)

but it would be much nicer to have a dodiagonal

(defvar m #2a((1 2 3)(4 5 6)(7 8 9)))

(defun matrix-trace (matrix)
    (let ((trace 0))
      (dodiagonal (x matrix trace) (incf trace x))))

(matrix-trace m) => 15

and it is easily provided

(defmacro dodiagonal ((variable square-matrix
				  &optional result-form)
			&body code)
    (let ((index-var (make-symbol "INDEX"))
	  (matrix-holder (make-symbol "MATRIX")))
      `(let ((,matrix-holder ,square-matrix))
	 (assert (and  (= (array-rank ,matrix-holder) 2)
		       (= (array-dimension ,matrix-holder 0)
			  (array-dimension ,matrix-holder 1))))
	 (let (,variable)
	   (dotimes (,index-var (array-dimension ,matrix-holder 0)
				,result-form)
	       (setf ,variable (aref ,matrix-holder ,index-var ,index-var))
	       ,@code)))))

(macroexpand-1 '(dodiagonal (x #2a((1 2)(3 4))) (print x)))
=> 
(LET ((#:MATRIX #2A((1 2) (3 4))))
  (ASSERT
   (AND (= (ARRAY-RANK #:MATRIX) 2)
        (= (ARRAY-DIMENSION #:MATRIX 0) (ARRAY-DIMENSION #:MATRIX 1))))
  (LET (X)
    (DOTIMES (#:INDEX (ARRAY-DIMENSION #:MATRIX 0) NIL)
      (SETF X (AREF #:MATRIX #:INDEX #:INDEX))
      (PRINT X))))

This kind of thing is clearly a huge win. Nevertheless, it
is worth pondering why this is so very different to creating
a dialect by writing your own version of DOTIMES or LOOP.
Their are two reasons.

1)It is grounded in the application. You only write
  dodiagonal because your application calls for
  it. Obviously you decide the details (such as checking
  that the matrix is indeed square) to suit your
  application. Maintenance programmers can take it on trust
  that it does the right thing, and guess what that thing
  is, because they are familiar with the application

2)The alternative is an idiom, not an individual language
  construct. The alternative to a construct called
  dodiagonal is an idiomatic use of several constructs in a
  pattern that the maintainers will learn to recognise. It
  is much easier to read code by reading identifiers that
  express domain specific intent than it is to read code by
  recognising coding cliches.

Unfortunately, it is always possible to sabotage a
programming project written in Common Lisp by using DEFMACRO
to create your own dialect and writing in that.

Fortunately, you can easily avoid doing this by
accident. You simply accept the commonplace tools provided
by CL for your general purpose programming. When a concept
in your application domain is giving rise to a coding
cliche, you capture that concept in a macro, and you name
the macro after the domain concept. Readers of your code
will encounter names for language constructs that are not
part of the Common Lisp standard. If they were the names of
constructs in a general purpose dialect of Lisp they would
be unfamiliar and confusing, but they are not. They are
named after the domain concepts they implement, so the names
are familiar to those working in your application
domain. Problem solved!

Alan Crowe
Edinburgh
Scotland
From: Steven M. Haflich
Subject: Re: Wondering if you guys would like to comment on this
Date: 
Message-ID: <tuYee.14017$J12.47@newssvr14.news.prodigy.com>
·······@gmail.com wrote:

> and had a very interesting response,
> ""So an annoyance that Common Lisp programmers can resolve for
> themselves within five minutes plagues Java programmers for years."

On the other hand, there are other things in ANSI Common Lisp that
have plagued me far longer than Java has even existed.
From: M Jared Finder
Subject: Re: Wondering if you guys would like to comment on this
Date: 
Message-ID: <8pidnfvxEd59wOHfRVn-jA@speakeasy.net>
Steven M. Haflich wrote:
> ·······@gmail.com wrote:
> 
>> and had a very interesting response,
>> ""So an annoyance that Common Lisp programmers can resolve for
>> themselves within five minutes plagues Java programmers for years."
> 
> On the other hand, there are other things in ANSI Common Lisp that
> have plagued me far longer than Java has even existed.

Such as...?  Without any examples, this feels more like a troll than 
anything else.

   -- MJF
From: Thomas Gagne
Subject: Re: Wondering if you guys would like to comment on this
Date: 
Message-ID: <MsSdndVOuJgLIB3fRVn-rA@wideopenwest.com>
There are a host of languages that appeal to programmers looking for 
limitations to save them from themselves and others.  Java falls into 
this category.

There are other languages like Lisp and Smalltalk (I also include C 
here) that appeal to another set of programmers because they get out of 
the programmer's way.  Lisp and Smalltalk are in an interesting 
category, alluded to earlier, where the languages' syntax is so simple 
that new behaviors can be added without having to modify syntax.  This 
is one of the greatest drawbacks to many languages that have built-in 
obstacles to their extension.  Because their capabilities are defined by 
syntax they can only be extended by modifying syntax, which requires new 
documentation, new compilers, etc.

For some reason this apparently appeals to /most/ programmers.

As mentioned by Paul Graham, Lisp (and Smalltalk) are self-selecting 
languages.  Anyone attracted to them has separated themselves from the 
pack, and I look for it on resumes.