Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Lisp: 4th Most Frequently Used Language in Debian GNU/Linux

48 views
Skip to first unread message

Emre Sevinc

unread,
Sep 14, 2005, 7:40:50 AM9/14/05
to

A detailed study shows that Lisp is the 4th most
common language used for software in
Debian Sarge GNU/Linux repository.

Debian GNU/Linux system includes 230 millions of SLOC and the
majority is written in C and C++. Shell programming ranks 3rd and
the 4th position is occupied by Lisp which beath languages
like Perl, Python and Java.

The story appears on FM Int:

http://www.fazlamesai.net/int/?a=article&sid=15


--
Emre Sevinc

eMBA Software Developer Actively engaged in:
http:www.bilgi.edu.tr http://ileriseviye.org
http://www.bilgi.edu.tr http://fazlamesai.net
Cognitive Science Student http://cazci.com
http://www.cogsci.boun.edu.tr

Edi Weitz

unread,
Sep 14, 2005, 7:59:11 AM9/14/05
to
On Wed, 14 Sep 2005 14:40:50 +0300, Emre Sevinc <em...@bilgi.edu.tr> wrote:

> A detailed study shows that Lisp is the 4th most common language
> used for software in Debian Sarge GNU/Linux repository.
>
> Debian GNU/Linux system includes 230 millions of SLOC and the
> majority is written in C and C++. Shell programming ranks 3rd and
> the 4th position is occupied by Lisp which beath languages like
> Perl, Python and Java.
>
> The story appears on FM Int:
>
> http://www.fazlamesai.net/int/?a=article&sid=15

Of course, this got to be mostly Emacs Lisp and other dialects that
aren't Common Lisp... :(

--

Lisp is not dead, it just smells funny.

Real email: (replace (subseq "spam...@agharta.de" 5) "edi")

Andras Simon

unread,
Sep 14, 2005, 7:58:48 AM9/14/05
to
Emre Sevinc <em...@bilgi.edu.tr> writes:

> A detailed study shows that Lisp is the 4th most
> common language used for software in
> Debian Sarge GNU/Linux repository.
>
> Debian GNU/Linux system includes 230 millions of SLOC and the
> majority is written in C and C++. Shell programming ranks 3rd and
> the 4th position is occupied by Lisp which beath languages
> like Perl, Python and Java.

I'm pretty sure the emacs is the culprit.

Andras

Frank Buss

unread,
Sep 14, 2005, 8:24:47 AM9/14/05
to
Emre Sevinc wrote:

> A detailed study shows that Lisp is the 4th most
> common language used for software in
> Debian Sarge GNU/Linux repository.

there are many different Lisp distributions like clisp, cmucl, sbcl etc. in
Debian, which comes with source code and implements the Lisp itself instead
of for example shell scripts, which are used for other tasks than building
shell script interpreters :-)

--
Frank Buß, f...@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

LuisGLopez

unread,
Sep 14, 2005, 8:42:21 AM9/14/05
to
Excuse this off-topic:

> Debian GNU/Linux system includes 230 millions

Did I read *230 millions*???? ¿¿¿¿230,000,000?????
¿¿¿¿¿¿¿¿230e6??????????

*That's* a lot...

Rob Thorpe

unread,
Sep 14, 2005, 9:24:12 AM9/14/05
to
Emre Sevinc wrote:
> A detailed study shows that Lisp is the 4th most
> common language used for software in
> Debian Sarge GNU/Linux repository.
>
> Debian GNU/Linux system includes 230 millions of SLOC and the
> majority is written in C and C++. Shell programming ranks 3rd and
> the 4th position is occupied by Lisp which beath languages
> like Perl, Python and Java.
>
> The story appears on FM Int:
>
> http://www.fazlamesai.net/int/?a=article&sid=15

I'm most impressed by the amount of code, 230 million lines!

I think some of the results for lisp come from duplication, much emacs
lisp is common between XEmacs and GNU Emacs, but I expect they counted
both separately. Also, many languages include their emacs modes in
their source distributions.

The results for shell may not be accurate either since it's often
generated automatically. I think sloccount (which they used) knows
about some of these ways, but not all of them.

Duane Rettig

unread,
Sep 14, 2005, 11:20:49 AM9/14/05
to
Emre Sevinc <em...@bilgi.edu.tr> writes:

> A detailed study shows that Lisp is the 4th most
> common language used for software in
> Debian Sarge GNU/Linux repository.
>
> Debian GNU/Linux system includes 230 millions of SLOC and the
> majority is written in C and C++. Shell programming ranks 3rd and
> the 4th position is occupied by Lisp which beath languages
> like Perl, Python and Java.
>
> The story appears on FM Int:
>
> http://www.fazlamesai.net/int/?a=article&sid=15

Now why do I get the distinct feeling that people are going
to jump all over this thing and tell us how invalid it is?

Already you are getting responses that are attributing it to
emacs-lisp. So what? Lisp is lisp. Until 1984, there were
many lisps around, all disjoint and not counted as one at all.
Now we have two or three that call themselves Lisp, and that
should be good enough. But rest assured someone will find a
way to discount the study for one reason or another...

--
Duane Rettig du...@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

alex...@gmail.com

unread,
Sep 14, 2005, 11:35:43 AM9/14/05
to
Emre Sevinc wrote:
> A detailed study shows that Lisp is the 4th most
> common language used for software in
> Debian Sarge GNU/Linux repository.
>
> Debian GNU/Linux system includes 230 millions of SLOC and the
> majority is written in C and C++. Shell programming ranks 3rd and
> the 4th position is occupied by Lisp which beath languages
> like Perl, Python and Java.
>
> The story appears on FM Int:
>
> http://www.fazlamesai.net/int/?a=article&sid=15

C is almost, but not entirely a proper subset of C++. Interestingly,
they are in separate groups, but Emacs Lisp, Scheme and Common Lisp are
in one.

--
"Or maybe you shouldn't bring me every little piece of trash you happen
to pick up" - Narrator

Kenny Tilton

unread,
Sep 14, 2005, 11:32:55 AM9/14/05
to

Duane Rettig wrote:
> Emre Sevinc <em...@bilgi.edu.tr> writes:
>
>
>>A detailed study shows that Lisp is the 4th most
>>common language used for software in
>>Debian Sarge GNU/Linux repository.
>>
>>Debian GNU/Linux system includes 230 millions of SLOC and the
>>majority is written in C and C++. Shell programming ranks 3rd and
>>the 4th position is occupied by Lisp which beath languages
>>like Perl, Python and Java.
>>
>>The story appears on FM Int:
>>
>>http://www.fazlamesai.net/int/?a=article&sid=15
>
>
> Now why do I get the distinct feeling that people are going
> to jump all over this thing and tell us how invalid it is?

What part of "there is no such thing as bad publicity" do you not
understand?! :)

We should hope for a huge, badmouthing, anti-Lisp flamewar if we really
want to build mindshare. As a software sales guy said after a disastrous
presentation in which the client totally reamed him, "If you are not
getting shot at, then you are not over the target."

--
Kenny

Why Lisp? http://wiki.alu.org/RtL_Highlight_Film

"I've wrestled with reality for 35 years, Doctor, and I'm happy to state
I finally won out over it."
Elwood P. Dowd, "Harvey", 1950

Tayssir John Gabbour

unread,
Sep 14, 2005, 11:49:39 AM9/14/05
to
Duane Rettig wrote:
> Emre Sevinc <em...@bilgi.edu.tr> writes:
>
> > A detailed study shows that Lisp is the 4th most
> > common language used for software in
> > Debian Sarge GNU/Linux repository.
> >
> > Debian GNU/Linux system includes 230 millions of SLOC and the
> > majority is written in C and C++. Shell programming ranks 3rd and
> > the 4th position is occupied by Lisp which beath languages
> > like Perl, Python and Java.
> >
> > The story appears on FM Int:
> >
> > http://www.fazlamesai.net/int/?a=article&sid=15
>
> Now why do I get the distinct feeling that people are going
> to jump all over this thing and tell us how invalid it is?

There seems to be nothing invalid about the statistics. However,
statistics are notorious for tricking people into drawing false
conclusions. Any stat should be (politely) scrutinized.

Assuming almost all of it is Emacs Lisp, I think the proper conclusion
is that Emacs has historically been a fairly successful platform, much
more so than Common Lisp. (But I think it also means there shouldn't be
a deep technical barrier to Common Lisp's success.)

Further, as I think well-macroed Lisps are far more concise than many
other languages, Emacs Lisp does even better than at first glance.


Tayssir

Duane Rettig

unread,
Sep 14, 2005, 12:02:05 PM9/14/05
to
Kenny Tilton <kti...@nyc.rr.com> writes:

> Duane Rettig wrote:
>> Emre Sevinc <em...@bilgi.edu.tr> writes:
>>
>>> A detailed study shows that Lisp is the 4th most common language
>>> used for software in Debian Sarge GNU/Linux repository.
>>>
>>> Debian GNU/Linux system includes 230 millions of SLOC and the
>>> majority is written in C and C++. Shell programming ranks 3rd and
>>> the 4th position is occupied by Lisp which beath languages like
>>> Perl, Python and Java.
>>>
>>>The story appears on FM Int:
>>>
>>>http://www.fazlamesai.net/int/?a=article&sid=15
>> Now why do I get the distinct feeling that people are going
>> to jump all over this thing and tell us how invalid it is?
>
> What part of "there is no such thing as bad publicity" do you not
> understand?! :)

What part of "there is no such thing as bad publicity" do you not
understand?! :)

Two responses to my complaint within 5 minutes. I think that's
pretty good :-)

Duane Rettig

unread,
Sep 14, 2005, 12:21:34 PM9/14/05
to

In my younger days, I used to participate in gymnastics, track, and
swimming teams. We would compete, and I was never very good, although
I did improve and I believe am in much better shape nowadays because of
these sports than I would have been without them. These sports are
individual sports, but the meets were team-oriented anyway. I noticed
two different kinds of participants at those meets: there were individuals
who competed for all of the glory, and who went home surrounded by a dark
cloud if they didn't win first place in their event (even if they had
bettered their times over their last competition), and there were
individuals who, whether they did well or not, would root for their
teammates, and who would leave a meet happy if their team had won, even
if they had not. And although coaches had a tendency to dote over their
star athletes, they also tried to inspire the latter kind of attitude,
where team spirit were important enough to be counted as a sign of
good character.

I'd prefer that we Common Lispers look at emacs-lisp in the same way,
as a teammate who has helped our team to do well at a meet, rather than
as a competitor who has stolen glory away from us. And as long as
we are bettering ourselves (i.e. our language) wrt where it has
been before, we should not be going home in a dark cloud of self-loathing
(not that you're doing this, of course; this just fits into my story and
is something I'd want others to avoid doing).

Message has been deleted

Christopher C. Stacy

unread,
Sep 14, 2005, 1:17:51 PM9/14/05
to
alex...@gmail.com writes:

> Emre Sevinc wrote:
> > A detailed study shows that Lisp is the 4th most
> > common language used for software in
> > Debian Sarge GNU/Linux repository.
> >
> > Debian GNU/Linux system includes 230 millions of SLOC and the
> > majority is written in C and C++. Shell programming ranks 3rd and
> > the 4th position is occupied by Lisp which beath languages
> > like Perl, Python and Java.
> >
> > The story appears on FM Int:
> >
> > http://www.fazlamesai.net/int/?a=article&sid=15
>
> C is almost, but not entirely a proper subset of C++. Interestingly,
> they are in separate groups, but Emacs Lisp, Scheme and Common Lisp are
> in one.

There's statistics, damn statistics, and LOC statistics.

Robert Uhl

unread,
Sep 14, 2005, 6:37:14 PM9/14/05
to
Duane Rettig <du...@franz.com> writes:
>
> I'd prefer that we Common Lispers look at emacs-lisp in the same way,
> as a teammate who has helped our team to do well at a meet, rather
> than as a competitor who has stolen glory away from us.

Anyone know why Scheme was chosen over Common Lisp for the future of
emacs (not that it looks as though it'll ever come to fruition...)? A
quick Googling didn't turn anything up.

--
Robert Uhl <http://public.xdi.org/=ruhl>
In Faerie one can indeed conceive of an ogre who possesses a castle as
hideous as a nightmare (for the evil of the ogre wills it so), but one
cannot conceive of a house built with a good purpose--an inn, a hostel
for travellers, the hall of a virtuous and noble king--that is yet
sickeningly ugly. At the present day it would be rash to hope to see
one that was not--unless it was built before our time. --J.R.R. Tolkien

Christopher C. Stacy

unread,
Sep 14, 2005, 6:49:14 PM9/14/05
to
Robert Uhl <eadm...@NOSPAMgmail.com> writes:
> Anyone know why Scheme was chosen over Common Lisp for the future of
> emacs (not that it looks as though it'll ever come to fruition...)?
> A quick Googling didn't turn anything up.

I am sure that it's partly due to the fact that Scheme
comes from the group that houses RMS's office; by contrast,
RMS doesn't ever use Common Lisp. Scheme has a history of
being used as a scripting language, and someone already did
a thesis on porting GNU Emacs to Scheme (well enough to run
the "gnus" newsreader in it). And finally, someone has
already written the Scheme ("Guile") interpreter and made
it available under licensing terms that RMS can accept.

Meanwhile on the technical front, at the time the decision was made,
free Common Lisp systems may not have been quite up to the task.
Certainly GCL was not. A lot of improvements in functionality
and bugs and ANSI conformance have been made to the various
non-commercial CL implementations, very recently.

Maybe Lisp newbies would also find it easier to write (very small)
Guile programs than to understand and extend full-blown CL programs.

You could always ask RMS; the above is just my guessing.

Matthew D Swank

unread,
Sep 14, 2005, 8:59:10 PM9/14/05
to
On Wed, 14 Sep 2005 22:49:14 +0000, Christopher C. Stacy wrote:

> Robert Uhl <eadm...@NOSPAMgmail.com> writes:
>> Anyone know why Scheme was chosen over Common Lisp for the future of
>> emacs (not that it looks as though it'll ever come to fruition...)?
>> A quick Googling didn't turn anything up.
>

...

> You could always ask RMS; the above is just my guessing.

from the emacs wiki (http://www.emacswiki.org/cgi-bin/wiki/CommonLisp):

RichardStallman has chosen not to adopt CommonLisp. He said in this
post, 2003-08-31 on the emacs-devel mailing list, when asked to include
a large part of the cl package into the EmacsLisp core:

I am willing to consider a small number of functions for inclusion
as standard parts of Emacs. I don't have time to consider a large
number, and I can't agree to them without considering them.

I do not like the Common Lisp style of using keyword arguments
for many common functions. I basically do not have a very high
opinion of many of the decisions that were made in Common Lisp.


--
"You do not really understand something unless you can
explain it to your grandmother." — Albert Einstein.

Robert Strandh

unread,
Sep 14, 2005, 11:54:25 PM9/14/05
to
Robert Uhl <eadm...@NOSPAMgmail.com> writes:

> Anyone know why Scheme was chosen over Common Lisp for the future of
> emacs (not that it looks as though it'll ever come to fruition...)? A
> quick Googling didn't turn anything up.

Yes, the idea was to translate other scripting languages into the one
chosen. Therefore, in order to make translation easy, the one chosen
had to be at least as powerful as the ones to be translated. It was
thought that Scheme, with first-class functions and first-class
continuations could easily express most constructs, including things
like exceptions, in other scripting languages.
--
Robert Strandh

Tim X

unread,
Sep 15, 2005, 12:15:20 AM9/15/05
to
Robert Uhl <eadm...@NOSPAMgmail.com> writes:

> Duane Rettig <du...@franz.com> writes:
> >
> > I'd prefer that we Common Lispers look at emacs-lisp in the same way,
> > as a teammate who has helped our team to do well at a meet, rather
> > than as a competitor who has stolen glory away from us.
>
> Anyone know why Scheme was chosen over Common Lisp for the future of
> emacs (not that it looks as though it'll ever come to fruition...)? A
> quick Googling didn't turn anything up.
>
> --

From memory, a while ago it was decided that guile would become the
official "extension language" for all GNU sponsored projects that
incorporated some form of extensibility. However, it was soon realised
that there was just way too much useful functional elisp out there to
replace it all with guile and that elisp wold need to be supported for
a long time even if guile was added as another extension language to
emacs.

So, I think we may still see a guile based plugin for emacs, but
wouldn't expect elisp to be desupported for a long time (if ever). On
one level, I can see the rationale behind GNU supporting and
maintaining just one type of lisp and having a standardised way for
all their official projects to be extended etc, but I think this may
be a case of trying to get the toothpaste back intot he tube - just a
bit late.

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!

Ulrich Hobelmann

unread,
Sep 15, 2005, 4:52:29 AM9/15/05
to
Matthew D Swank wrote:
> from the emacs wiki (http://www.emacswiki.org/cgi-bin/wiki/CommonLisp):
>
> RichardStallman has chosen not to adopt CommonLisp. He said in this
> post, 2003-08-31 on the emacs-devel mailing list, when asked to include
> a large part of the cl package into the EmacsLisp core:
>
> I am willing to consider a small number of functions for inclusion
> as standard parts of Emacs. I don't have time to consider a large
> number, and I can't agree to them without considering them.

That's RMS the maximo lider that has to approve everything :D

> I do not like the Common Lisp style of using keyword arguments
> for many common functions. I basically do not have a very high
> opinion of many of the decisions that were made in Common Lisp.

And I don't like it that RMS rejects design decisions that obviously he
didn't even have the time to consider or understand. I suspect he
prefers Java-style ten-functions-for-one-purpose then.

--
My mouth says the words, my brain is thinking monstertrucks.
Joey (Friends)

Hrvoje Blazevic

unread,
Sep 15, 2005, 5:21:11 AM9/15/05
to
Ulrich Hobelmann wrote:

> Matthew D Swank wrote:
>
> That's RMS the maximo lider that has to approve everything :D
>
>> I do not like the Common Lisp style of using keyword arguments
>> for many common functions. I basically do not have a very high
>> opinion of many of the decisions that were made in Common Lisp.
>
>
> And I don't like it that RMS rejects design decisions that obviously he
> didn't even have the time to consider or understand. I suspect he
> prefers Java-style ten-functions-for-one-purpose then.
>

That's slightly bellow the belt. Maybe he prefers simplicity of Scheme?
(Although that's probably not true either :-)

Anyway, finally a kindred spirit when talking about keyword arguments. I
too would prefer, say foldr foldr1 foldl foldl1, instead of ceaseless
checking for keyword arguments to REDUCE in CLTL.

-- Hrvoje

Edi Weitz

unread,
Sep 15, 2005, 5:27:37 AM9/15/05
to
On Thu, 15 Sep 2005 11:21:11 +0200, Hrvoje Blazevic <hrv...@despammed.com> wrote:

> Anyway, finally a kindred spirit when talking about keyword
> arguments. I too would prefer, say foldr foldr1 foldl foldl1,

Looks like Scheme is for you...

> instead of ceaseless checking for keyword arguments to REDUCE in
> CLTL.

Have you ever tried SLIME?

Cheers,
Edi.

Hrvoje Blazevic

unread,
Sep 15, 2005, 5:42:57 AM9/15/05
to
Edi Weitz wrote:
> On Thu, 15 Sep 2005 11:21:11 +0200, Hrvoje Blazevic <hrv...@despammed.com> wrote:
> Looks like Scheme is for you...
>
>
>>instead of ceaseless checking for keyword arguments to REDUCE in
>>CLTL.
>
>
> Have you ever tried SLIME?
>

Yes I have, but never got as far as actually reading the manual. I guess
then that SLIME can automate searching through CLTL?

-- Hrvoje

Edi Weitz

unread,
Sep 15, 2005, 6:11:30 AM9/15/05
to
On Thu, 15 Sep 2005 11:42:57 +0200, Hrvoje Blazevic <hrv...@despammed.com> wrote:

> Yes I have, but never got as far as actually reading the manual. I
> guess then that SLIME can automate searching through CLTL?

SLIME can automatically look up entries in the CLHS for you. But
that's not what I meant. Just type "(reduce", then press the space
bar, and the argument list for REDUCE will be shown in the mini buffer
- no reason to look up anything.

Ulrich Hobelmann

unread,
Sep 15, 2005, 6:28:54 AM9/15/05
to

A actually agree there, because the folds are all somewhat different
(I'd make the start value (the 1) optional, though).

In many cases, however, I think that just having Java overloading or
scheme &rest parameter lists is too much work to express very simple
variations and parametrisations in a given function.

Oh, and you can always DEFUN fold to be reduce with whatever keywords
you like... Getting keyword convenience in elisp or Scheme would be harder.

Förster vom Silberwald

unread,
Sep 15, 2005, 6:37:53 AM9/15/05
to

Duane Rettig wrote:

> Now why do I get the distinct feeling that people are going
> to jump all over this thing and tell us how invalid it is?
>
> Already you are getting responses that are attributing it to
> emacs-lisp. So what? Lisp is lisp. Until 1984, there were
> many lisps around, all disjoint and not counted as one at all.
> Now we have two or three that call themselves Lisp, and that
> should be good enough. But rest assured someone will find a
> way to discount the study for one reason or another...

You must see it from this perspective: nobody will call Emacs
programmers genuine programmers. However, it is not wrong to call
CommonLisp programmers real programmers.

It is sometimes how people are recognised and acknowledged. Would you
call Mathemtica or Matlab programmers programmers?

Schneewittchen
PS: Oh yes I for one woul call Emacs, Matlab, Mathematica, etc.
programmer programmers.

Hrvoje Blazevic

unread,
Sep 15, 2005, 7:00:28 AM9/15/05
to
Edi Weitz wrote:
> SLIME can automatically look up entries in the CLHS for you. But
> that's not what I meant. Just type "(reduce", then press the space
> bar, and the argument list for REDUCE will be shown in the mini buffer
> - no reason to look up anything.

Neat.

-- Hrvoje

Hrvoje Blazevic

unread,
Sep 15, 2005, 7:13:32 AM9/15/05
to
Ulrich Hobelmann wrote:
> Oh, and you can always DEFUN fold to be reduce with whatever keywords
> you like... Getting keyword convenience in elisp or Scheme would be
> harder.
>

True. However, this is just a matter of aesthetics. There's a fine line
between this kind of convenience, and syntax burden.

-- Hrvoje

Duane Rettig

unread,
Sep 15, 2005, 11:09:39 AM9/15/05
to
"Förster vom Silberwald" <chain...@hotmail.com> writes:

> Duane Rettig wrote:
>
>> Now why do I get the distinct feeling that people are going
>> to jump all over this thing and tell us how invalid it is?
>>
>> Already you are getting responses that are attributing it to
>> emacs-lisp. So what? Lisp is lisp. Until 1984, there were
>> many lisps around, all disjoint and not counted as one at all.
>> Now we have two or three that call themselves Lisp, and that
>> should be good enough. But rest assured someone will find a
>> way to discount the study for one reason or another...
>
> You must see it from this perspective: nobody will call Emacs
> programmers genuine programmers. However, it is not wrong to call
> CommonLisp programmers real programmers.
>
> It is sometimes how people are recognised and acknowledged. Would you
> call Mathemtica or Matlab programmers programmers?

What does the question of whether a person is a programmer have to
do with this discussion?

> Schneewittchen
> PS: Oh yes I for one woul call Emacs, Matlab, Mathematica, etc.
> programmer programmers.

Then why did you set this strawman argument up, only to knock it
down again? To what purpose?

Richard Fateman

unread,
Sep 15, 2005, 11:12:01 AM9/15/05
to
alex...@gmail.com wrote:
>
> <snip>

> C is almost, but not entirely a proper subset of C++. Interestingly,
> they are in separate groups, but Emacs Lisp, Scheme and Common Lisp are
> in one.
>

So is your point that
if one groups C and C++ as "the same language",
then Lisp comes in 3rd instead of 4th?

Förster vom Silberwald

unread,
Sep 15, 2005, 12:20:14 PM9/15/05
to
Duane Rettig wrote:

> What does the question of whether a person is a programmer have to
> do with this discussion?

Whether a person feels like a programmer is irrelevant. However, what
counts: whether a person actually is recognised as a programmer.

Have you ever seen a book: "Learn programming by means of Emacs" -
haven't you?

Neither Lisp nor Scheme (my favorite language) are big players under
Linux, even. Truth is ...

First, one should check whether he counts Emacs as a real programming
language. It is a straw-man argument saying Lisp and Scheme play a
dominant role among Unix/Linux platforms since that particular Lisp is
based on Emacs-Lisp.

Schneewittchen

Kent M Pitman

unread,
Sep 15, 2005, 12:21:50 PM9/15/05
to

Funny. I think that keywords will one day be seen as one of the very
important features of CL. They provide redundancy of information,
lessening syntax errors. They are statically compilable, so they
don't reduce speed. And they permit flexible re-ordering of arguments
in order to manage side-effects.

This is also not the first time I've seen someone fail to take good
ideas from something just to make what seems to amount to a political
point. Good ideas are good ideas regardless of their source. To
dismiss all aspects of a past effort you don't like just because you
don't like its totality seems silly. There may be individual reasons
to dismiss each and every design decision of CL, and that's fine. But
dismissing something in bulk isn't very scientific...

Personally, I think what Stallman doesn't like about CL is that he
didn't design it. And I'd have more respect for him if he just said
that plainly, since then it could at least be addressed head on. But
making something gratuitously incompatible when it's "in range" seems
an exercise in ego foisted upon a community of users which seems to
feel obliged to tolerate it. If I were them, in response to what he
says, I would take the source and make it ANSI CL compatible anyway,
and just leave him behind. Isn't that the whole point of open source?
Why is what he is willing to consider even relevant?

Duane Rettig

unread,
Sep 15, 2005, 12:59:38 PM9/15/05
to
"Förster vom Silberwald" <chain...@hotmail.com> writes:

> Duane Rettig wrote:
>
>> What does the question of whether a person is a programmer have to
>> do with this discussion?
>
> Whether a person feels like a programmer is irrelevant. However, what
> counts: whether a person actually is recognised as a programmer.
>
> Have you ever seen a book: "Learn programming by means of Emacs" -
> haven't you?

But you just finished saying that you yourself believe that emacs
lisp is a programming language (i.e. its programmers are indeed
programmers). And since I also believe this, where's the disagreement?

> Neither Lisp nor Scheme (my favorite language) are big players under
> Linux, even. Truth is ...

Ah, keep things separate, eh? Every language dialect must stand
on its own, or fall?

> First, one should check whether he counts Emacs as a real programming
> language. It is a straw-man argument saying Lisp and Scheme play a
> dominant role among Unix/Linux platforms since that particular Lisp is
> based on Emacs-Lisp.

Look up what a "straw man argument" is. It's certainly not me that
is putting up that argument as a strawman; I believe the argument. Lisp
is lisp, and I refuse to denegrate emacs-lisp just because it overshadows
my own favorite Lisp (which happens to be Common Lisp).

Lars Brinkhoff

unread,
Sep 15, 2005, 1:41:54 PM9/15/05
to
Kent M Pitman <pit...@nhplace.com> writes:
> If I were them, in response to what he says, I would take the source
> and make it ANSI CL compatible anyway, and just leave him behind.
> Isn't that the whole point of open source? Why is what he is
> willing to consider even relevant?

I believe RMS has the final say over any change to GNU Emacs, and the
developers seem happy with this. Or, it's my impression that if there
is a group of developers that want to break off and create their own
fork, they either aren't very interested in Common Lisp, or they are
too few to get the work done.

Harald Hanche-Olsen

unread,
Sep 15, 2005, 3:28:29 PM9/15/05
to
+ Lars Brinkhoff <lars...@nocrew.org>:

Indeed the cost of forking a project can be prohibitive. And if
you're not willing to pay that cost, you have to go along with whoever
owns the project. Erik Naggum started a project to common-lispify
emacs a number of years ago, but gave up on it. I don't know how much
time he spent on it, or how far he got. But the obvious lesson is
that this is a non-trivial undertaking.

--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Debating gives most of us much more psychological satisfaction
than thinking does: but it deprives us of whatever chance there is
of getting closer to the truth. -- C.P. Snow

Pascal Costanza

unread,
Sep 15, 2005, 5:19:44 PM9/15/05
to
Kent M Pitman wrote:

> Funny. I think that keywords will one day be seen as one of the very
> important features of CL. They provide redundancy of information,
> lessening syntax errors. They are statically compilable, so they
> don't reduce speed. And they permit flexible re-ordering of arguments
> in order to manage side-effects.

Furthermore, they allow you to evolve code by extending an argument list
without affecting all call sites. You can then only change the call
sites that actually need the new argument. (I think the advantages you
mention are good points, but this one is something that buys you a real
technical advantage IMHO.)


Pascal

--
OOPSLA'05 tutorial on generic functions & the CLOS Metaobject Protocol
++++ see http://p-cos.net/oopsla05-tutorial.html for more details ++++

Pascal Costanza

unread,
Sep 15, 2005, 5:25:32 PM9/15/05
to
Harald Hanche-Olsen wrote:
> + Lars Brinkhoff <lars...@nocrew.org>:
>
> | Kent M Pitman <pit...@nhplace.com> writes:
> | > If I were them, in response to what he says, I would take the source
> | > and make it ANSI CL compatible anyway, and just leave him behind.
> | > Isn't that the whole point of open source? Why is what he is
> | > willing to consider even relevant?
> |
> | I believe RMS has the final say over any change to GNU Emacs, and the
> | developers seem happy with this. Or, it's my impression that if there
> | is a group of developers that want to break off and create their own
> | fork, they either aren't very interested in Common Lisp, or they are
> | too few to get the work done.
>
> Indeed the cost of forking a project can be prohibitive. And if
> you're not willing to pay that cost, you have to go along with whoever
> owns the project. Erik Naggum started a project to common-lispify
> emacs a number of years ago, but gave up on it. I don't know how much
> time he spent on it, or how far he got. But the obvious lesson is
> that this is a non-trivial undertaking.

Don't forget about the projects that reimplement Emacs from scratch in
Common Lisp. There is some noticeable progress being made there.

Kent M Pitman

unread,
Sep 15, 2005, 7:58:48 PM9/15/05
to
Harald Hanche-Olsen <han...@math.ntnu.no> writes:

> + Lars Brinkhoff <lars...@nocrew.org>:
>
> | Kent M Pitman <pit...@nhplace.com> writes:
> | > If I were them, in response to what he says, I would take the source
> | > and make it ANSI CL compatible anyway, and just leave him behind.
> | > Isn't that the whole point of open source? Why is what he is
> | > willing to consider even relevant?
> |
> | I believe RMS has the final say over any change to GNU Emacs, and the
> | developers seem happy with this. Or, it's my impression that if there
> | is a group of developers that want to break off and create their own
> | fork, they either aren't very interested in Common Lisp, or they are
> | too few to get the work done.
>
> Indeed the cost of forking a project can be prohibitive. And if
> you're not willing to pay that cost, you have to go along with whoever
> owns the project. Erik Naggum started a project to common-lispify
> emacs a number of years ago, but gave up on it. I don't know how much
> time he spent on it, or how far he got. But the obvious lesson is
> that this is a non-trivial undertaking.

I think this is true, but it's interesting that free software is often
"sold" on the basis of the availability of this as an option. So it's
interesting to see that even when no money is at stake, the phenomenon
of "marketingspeak" is in play...

(In case that's too vague a remark, I'll add a strawman definition of
marketingspeak as the use of statements that are almost always true,
and yet just as often irrelevant, incomplete, out-of-context, or
otherwise misleading usually not for what they say but what they omit.)

Dave Roberts

unread,
Sep 15, 2005, 10:31:02 PM9/15/05
to

"Tayssir John Gabbour" <tayss...@yahoo.com> writes:

> Assuming almost all of it is Emacs Lisp, I think the proper conclusion
> is that Emacs has historically been a fairly successful platform, much
> more so than Common Lisp. (But I think it also means there shouldn't be
> a deep technical barrier to Common Lisp's success.)

I had a thought the other day that Lisp Machines never really
died. Oh, sure, the hardware went away. We just replaced them with
Unix systems running Emacs instead. ;-) Seriously, it's interesting
how good old elisp-based Emacs has grown way beyond text editing. I
used to joke with a friend who is an Emacs freak (to the point of
virtually living for days in a single Emacs session) that Unix is just
the Emacs boot-loader.

--
Dave Roberts
dave -remove- AT findinglisp DoT com
http://www.findinglisp.com/

Pascal Bourguignon

unread,
Sep 15, 2005, 10:43:27 PM9/15/05
to
Dave Roberts <dave-...@remove-findinglisp.com> writes:
> I had a thought the other day that Lisp Machines never really
> died. Oh, sure, the hardware went away. We just replaced them with
> Unix systems running Emacs instead. ;-) Seriously, it's interesting
> how good old elisp-based Emacs has grown way beyond text editing. I
> used to joke with a friend who is an Emacs freak (to the point of
> virtually living for days in a single Emacs session) that Unix is just
> the Emacs boot-loader.

What do you mean? You can use it for something else?
http://www.informatimago.com/linux/emacs-on-user-mode-linux.html

--
__Pascal Bourguignon__ http://www.informatimago.com/
I need a new toy.
Tail of black dog keeps good time.
Pounce! Good dog! Good dog!

Kent M Pitman

unread,
Sep 16, 2005, 12:00:38 AM9/16/05
to
Pascal Costanza <p...@p-cos.net> writes:

> Kent M Pitman wrote:
>
> > Funny. I think that keywords will one day be seen as one of the very
> > important features of CL. They provide redundancy of information,
> > lessening syntax errors. They are statically compilable, so they
> > don't reduce speed. And they permit flexible re-ordering of arguments
> > in order to manage side-effects.
>
> Furthermore, they allow you to evolve code by extending an argument
> list without affecting all call sites. You can then only change the
> call sites that actually need the new argument. (I think the
> advantages you mention are good points, but this one is something that
> buys you a real technical advantage IMHO.)

Yes, I think this is one of the reasons Paul Graham seems to be a big
fan of them.

Note, too, apropos a related thread, that keywords are among the things
that are natural-language-like about CL. They are very like prepositional
guide words. "Give the ball to John".

Harlequin had a product called WebMaker that translated FrameMaker MIF
format files to HTML using a rule language. I implemented an
extension to that language that allowed you to name arguments and
still also use them positionally, so that you could implement the full
set of
Give John the ball.
Give to John the ball.
Give the ball to John.
by basically first processing keywords and then coming back and filling
in keywords. e.g.,

(defun give (&key direct-obj to) ...)

(give ball :to john) ; keyword :to only, one positional arg
(give :to john ball) ; keyword :to only, one positional arg
(give :to john :direct-obj ball) ; keywords :to and :direct-obj
(give :direct-obj ball :to john) ; keywords :to and :direct-obj

It's perhaps tricky to compile, but it was cool to use.

It's possible that some additional constraint such as not allowing args
to evaluate to keywords would help, but one has to be careful not to lock
out the ability to use APPLY to merge keyword lists that come from two
different places, so it's not quite as simple as that. Nevertheless, I
consider it a virtue of Lisp that it's willing to dive into an area like
this, get some user experience, and then evolve.

Incidentally, while I'm listing things I would do differently with keywords,
the other things on my list are:

&key should be :key. The whole presence of &keywords in CL is needless.
(We fixed this in ISLISP, which takes :rest and :optional.)

I pushed during the early design of CL to have keywords be a different
datatype, not symbols. It never happened, in spite of promises from
some at the time that we would reconsider this issue later. I've come
to the belief that the right datatype is STRING. That is, that
keywords should be what I think Java calls "canonical
strings"--immutable strings that are possible to compare with EQ.
A thing that has often troubled me is "symbol proliferation", that is,
that there are a zillion keywords whose only purpose is to serve as the
guide words for same-named variables. When you do &key x, you implicitly
also create :x. It's not a huge deal, but it would be cool if
(eq (symbol-name 'x) :x), since it would save space. It would also mean
:rest and :optional in keyword lists could be recognized by their
stringness, not by being "also symbols, just ones that happen to be
in the keyword package" (a kind of weirdness that harkens back to the
days of CLTL1, and earlier, when lists whose car was LAMBDA were
counted as FUNCTIONP).

Perhaps the above are some fun things people who have their own lisps
percolating could give a try with...

Joe Marshall

unread,
Sep 16, 2005, 12:06:55 AM9/16/05
to
Kent M Pitman <pit...@nhplace.com> writes:

> That is, that keywords should be what I think Java calls "canonical

> strings" --- immutable strings that are possible to compare with EQ.

Er, isn't that usually called a `symbol'? Yeah, there are some other
fields generally associated with a symbol, but being immutable,
interned, and symbolic (human readable) are the essence of symbolhood.

Kent M Pitman

unread,
Sep 16, 2005, 12:14:48 AM9/16/05
to
Joe Marshall <jmar...@alum.mit.edu> writes:

Scheme might call it a symbol, but no CL.

Symbols have plists, value cells, and function cells.
I think it would be useful to have an intermediate datatype.

Kent M Pitman

unread,
Sep 16, 2005, 12:17:49 AM9/16/05
to

Oops. A little voice in my head was saying "four" and I could only
think of three things. Packages. Symbols also have packages.
Moreover, you can shadow normal symbols. You can't shadow keywords.
Hence the remark about Scheme, which has no real way to package and
shadow symbols, and consequently a need for separate facilities to
manage macro hygiene (which is handled implicitly in other ways in CL).

Thomas F. Burdick

unread,
Sep 16, 2005, 2:28:11 AM9/16/05
to
Kent M Pitman <pit...@nhplace.com> writes:

> Pascal Costanza <p...@p-cos.net> writes:
>
> > Kent M Pitman wrote:
> >
> > > Funny. I think that keywords will one day be seen as one of the very
> > > important features of CL. They provide redundancy of information,
> > > lessening syntax errors. They are statically compilable, so they
> > > don't reduce speed. And they permit flexible re-ordering of arguments
> > > in order to manage side-effects.
> >
> > Furthermore, they allow you to evolve code by extending an argument
> > list without affecting all call sites. You can then only change the
> > call sites that actually need the new argument. (I think the
> > advantages you mention are good points, but this one is something that
> > buys you a real technical advantage IMHO.)
>
> Yes, I think this is one of the reasons Paul Graham seems to be a big
> fan of them.
>
> Note, too, apropos a related thread, that keywords are among the things
> that are natural-language-like about CL. They are very like prepositional
> guide words. "Give the ball to John".

When you put it that way, it raises another posibility. Instead of
using keywords, we could just decline a function's arguments. That
would make it easier to pass along keywords. Instead of

(defun give (obj &key to)
(if (far-away-p to)
(throw obj :to to)
(hand obj :to to)))

we'd have

(defun give ((obj direct-object) (to indirect-object))
(if (far-away-p to)
(throw to obj)
(hand obj to)))

Not that I really want to write

(give (decline *ball* 'indirect-object) (decline *dog* 'direct-object))

But I do think it's a cut idea to allow the keyword that an argument
is associated with to tag along with the argument itself.

--
/|_ .-----------------------.
,' .\ / | Free Mumia Abu-Jamal! |
,--' _,' | Abolish the racist |
/ / | death penalty! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'

Thomas F. Burdick

unread,
Sep 16, 2005, 2:35:22 AM9/16/05
to
Pascal Bourguignon <sp...@mouse-potato.com> writes:

> Dave Roberts <dave-...@remove-findinglisp.com> writes:
> > I