"Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)

512 views
Skip to first unread message

Adam Warner

unread,
Sep 26, 2002, 5:35:30 AM9/26/02
to
That quotation from a December 1999 interview with RMS left an indelible
impression:
http://www.linuxcare.com/viewpoints/os-interviews/12-14-99.epl

I was dumbfounded that Richard Stallman himself was advocating using a
Scheme interpreter instead of Lisp.

Regards,
Adam

Dave Bakhash

unread,
Sep 26, 2002, 11:30:49 AM9/26/02
to
"Adam Warner" <use...@consulting.net.nz> writes:

I'm not dumbfounded about anything RMS says these days. What dumbfounds
me, though, is that people would rather use Guile that CL as an
embedded application and extension language.

Fortunately, there are numerous threads that you can read on this, both
here and in other newsgroups (e.g. comp.emacs.xemacs). Scheme/Guile
seems to be strongly advocated among many open-source developers and
projects. I think they've done a better job making Guile something that
can be bundled. I would also guess that CLISP can be just as easily
bundled.

There are lots of applications for which CL might have seemed like
overkill...but even for those, i think CL would be better. The greatest
loss, though, is in (X)Emacs. This is the very application that used
Lisp as an extension language in the first place, and is one of the
reason for Lisp's current popularity. Without Emacs, I don't know if
Lisp would have the the following that it does. Many Lisp programmers
get into Lisp by first editing their .eamcs files, modifying elisp
packages, and then eventually writing their own.

I don't think that the CL community realized the importance of a
complete version of Emacs done in CL, with the ability to process legacy
Emacs Lisp files. A version of Emacs, based on CLISP, would have done
wonders. The timing was right just before this aweful idea came up to
replacing elisp with Guile.

CL already has a nice package system that would solve a lot of the
namespace issues that Elisp has. Lexical scoping, an efficient object
system, a more complete set of built-in functions and constructs...would
together fix the problems that Elisp has now.

dave

Bruce Stephens

unread,
Sep 26, 2002, 11:57:54 AM9/26/02
to
Dave Bakhash <ca...@alum.mit.edu> writes:

> "Adam Warner" <use...@consulting.net.nz> writes:
>
>> That quotation from a December 1999 interview with RMS left an indelible
>> impression:
>> http://www.linuxcare.com/viewpoints/os-interviews/12-14-99.epl
>>
>> I was dumbfounded that Richard Stallman himself was advocating using a
>> Scheme interpreter instead of Lisp.
>
> I'm not dumbfounded about anything RMS says these days. What dumbfounds
> me, though, is that people would rather use Guile that CL as an
> embedded application and extension language.

This discussion started years ago, though. At the time, I'd guess CL
just looked too darn big, and probably the free implementations
weren't that mature (or amenable to embedding). At the time, if you
wanted a low-footprint very well-defined lisp, then Scheme was an
obviously good choice.

> Fortunately, there are numerous threads that you can read on this,
> both here and in other newsgroups (e.g. comp.emacs.xemacs).
> Scheme/Guile seems to be strongly advocated among many open-source
> developers and projects. I think they've done a better job making
> Guile something that can be bundled. I would also guess that CLISP
> can be just as easily bundled.

Yes, <http://ecls.sourceforge.net/index.html> looks attractive.

Inverting the problem a bit, rep's cool, too:
<http://librep.sourceforge.net/>. It's a dialect of lisp that's
fairly close to emacs-lisp, so it's easy to embed an emacs-lisp-like
interpreter into other applications (notably sawfish).

[...]

Dorai Sitaram

unread,
Sep 26, 2002, 12:15:21 PM9/26/02
to
In article <c29wup8...@no-knife.mit.edu>,

My how lugubriously you write.... One would think that
Emacs Lisp was being given up for a brace-semicolon
language or something. Guile is very Lisp-y, and has
all the things you mention, viz, namespace-discipline
mechanism, lexical scoping, object system, complete set
of builtins -- just not compatibly with CL. If it
weren't for the drawn knives here, I would simply let
down my guard and concede that Guile is a Lisp.

Dave Bakhash

unread,
Sep 26, 2002, 12:32:41 PM9/26/02
to
ds...@goldshoe.gte.com (Dorai Sitaram) writes:

> My how lugubriously you write.... One would think that Emacs Lisp was
> being given up for a brace-semicolon language or something.

may as well be.

> Guile is very Lisp-y, and has all the things you mention, viz,
> namespace-discipline mechanism, lexical scoping, object system,
> complete set of builtins -- just not compatibly with CL.

Remember that you should not forget that you're starting with Emacs
Lisp, and that this more closely resembles CL than Guile. That part of
the problem should not be downplayed.

Also, it's nice that CL is ANSI-standardized, and has a long track
record, and a pretty strong community. Sometimes it's better to go with
something that works than to start all over.

> weren't for the drawn knives here, I would simply let down my guard
> and concede that Guile is a Lisp.

Guile may be a Lisp. But so is Emacs Lisp. What is your point?

dave

Dorai Sitaram

unread,
Sep 26, 2002, 1:34:04 PM9/26/02
to
In article <c29ofak...@no-knife.mit.edu>,
Dave Bakhash <ca...@alum.mit.edu> wrote:

>ds...@goldshoe.gte.com (Dorai Sitaram) writes:
>> Guile is very Lisp-y, and has all the things you mention, viz,
>> namespace-discipline mechanism, lexical scoping, object system,
>> complete set of builtins -- just not compatibly with CL.
>
>Remember that you should not forget that you're starting with Emacs
>Lisp, and that this more closely resembles CL than Guile. That part of
>the problem should not be downplayed.

In the Lisp world where code is data, these things can
be downplayed.

>Also, it's nice that CL is ANSI-standardized, and has a long track
>record, and a pretty strong community. Sometimes it's better to go with
>something that works than to start all over.

Yes, a CL-based Emacs would also have been quite
interesting.

>> weren't for the drawn knives here, I would simply let down my guard
>> and concede that Guile is a Lisp.
>
>Guile may be a Lisp. But so is Emacs Lisp. What is your point?

Your message suggested that Emacs was tragically moving
away from Lisp by switching to Guile, so I
reassured you that it wasn't. Maybe I misread
what exactly you were being regretful about.

Tim Bradshaw

unread,
Sep 26, 2002, 1:49:58 PM9/26/02
to
* Dave Bakhash wrote:

> There are lots of applications for which CL might have seemed like
> overkill...but even for those, i think CL would be better. The greatest
> loss, though, is in (X)Emacs. This is the very application that used
> Lisp as an extension language in the first place, and is one of the
> reason for Lisp's current popularity. Without Emacs, I don't know if
> Lisp would have the the following that it does. Many Lisp programmers
> get into Lisp by first editing their .eamcs files, modifying elisp
> packages, and then eventually writing their own.

> I don't think that the CL community realized the importance of a
> complete version of Emacs done in CL, with the ability to process legacy
> Emacs Lisp files. A version of Emacs, based on CLISP, would have done
> wonders. The timing was right just before this aweful idea came up to
> replacing elisp with Guile.

I think it was discussed (among many other things...) when xemacs was
still lemacs. I used to be on the mailing list but I didn't keep
anything other than the most juicy stuff about great schism[1] so I
can't remember any details.

Personally I think the idea of replacing elisp by anything is (a)
insane and (b) incredibly unlikely to happen. XEmacs *ships* with
more than 2 million lines of emacs lisp[2], and I bet there is far
more than that in code that is either not bundled or is not
distributed at all (I have ~10,000 lines, I bet other people have as
much or more). No one is going to convert that stuff before hell
freezes over. So any replacement system has to *precisely* support
the semantics of elisp, including all the weird gotchas, and it has to
do it essentially for ever. And to what end? What will the huge win
be? Sure, elisp is bad, but it's not that bad. The stuff that holds
back big elisp systems isn't the terrible language or performance
(other than in a few cases), it's that they're big and complicated and
some of the emacs primitives suck. Easy wins would be adding proper
packages and proper structures - these could be added in mostly
transparently to old code. Gutting the system sounds like a vast
amount of work for some mistaken idea of purity. It works now, and it
works mostly really well, why does it need fixing so badly?

--tim

Footnotes:
[1] In real life I'm a tabloid journalist.

[2] Actually this isn't quite right: XEmacs + the most recent sumo
bundle (which is all the elisp packages, I think, or at least
it's all I ever fetch) is more than 2 million lines. I'm a
tabloid journalist, I'm allowed to lie.

Christopher Browne

unread,
Sep 26, 2002, 5:03:21 PM9/26/02
to
A long time ago, in a galaxy far, far away, Dave Bakhash <ca...@alum.mit.edu> wrote:
> CL already has a nice package system that would solve a lot of the
> namespace issues that Elisp has. Lexical scoping, an efficient object
> system, a more complete set of built-in functions and constructs...would
> together fix the problems that Elisp has now.

Bolting CLISP onto Emacs certainly has some attractive properties.

The one downside: CLISP doesn't support a threading system. If it
did, this would address the One Great Big Wishlist Item.
--
(concatenate 'string "aa454" "@freenet.carleton.ca")
http://www.ntlug.org/~cbbrowne/advocacy.html
Who's afraid of ARPA?

Dorai Sitaram

unread,
Sep 26, 2002, 5:30:55 PM9/26/02
to
In article <ey3smzw...@cley.com>, Tim Bradshaw <t...@cley.com> wrote:

>* Dave Bakhash wrote:
>
>> I don't think that the CL community realized the importance of a
>> complete version of Emacs done in CL, with the ability to process legacy
>> Emacs Lisp files. A version of Emacs, based on CLISP, would have done
>> wonders. The timing was right just before this aweful idea came up to
>> replacing elisp with Guile.
>
>I think it was discussed (among many other things...) when xemacs was
>still lemacs. I used to be on the mailing list but I didn't keep
>anything other than the most juicy stuff about great schism[1] so I
>can't remember any details.
>
>Personally I think the idea of replacing elisp by anything is (a)
>insane and (b) incredibly unlikely to happen.

The prevalence in the CL community of this quite
reasonable attitude, rather than any actual technical
barrier, may be why CL was able to successfully avoid
being considered as a candidate for successor to elisp.

>XEmacs *ships* with
>more than 2 million lines of emacs lisp[2], and I bet there is far
>more than that in code that is either not bundled or is not
>distributed at all (I have ~10,000 lines, I bet other people have as
>much or more). No one is going to convert that stuff before hell
>freezes over. So any replacement system has to *precisely* support
>the semantics of elisp, including all the weird gotchas, and it has to
>do it essentially for ever. And to what end? What will the huge win
>be? Sure, elisp is bad, but it's not that bad. The stuff that holds
>back big elisp systems isn't the terrible language or performance
>(other than in a few cases), it's that they're big and complicated and
>some of the emacs primitives suck. Easy wins would be adding proper
>packages and proper structures - these could be added in mostly
>transparently to old code. Gutting the system sounds like a vast
>amount of work for some mistaken idea of purity. It works now, and it
>works mostly really well, why does it need fixing so badly?

I find your reasoning quite understandable. Scheme is
only being used for something that the CL community
didn't want to touch anyway. This should answer
Dave Bakhash's unnecessarily regret-filled article.

Tim Bradshaw

unread,
Sep 26, 2002, 7:53:37 PM9/26/02
to
* Dorai Sitaram wrote:
> The prevalence in the CL community of this quite
> reasonable attitude, rather than any actual technical
> barrier, may be why CL was able to successfully avoid
> being considered as a candidate for successor to elisp.

> I find your reasoning quite understandable. Scheme is


> only being used for something that the CL community
> didn't want to touch anyway. This should answer
> Dave Bakhash's unnecessarily regret-filled article.

I think it's about wheel reinvention. I see that CL is a reasonable
wheel, and I'd rather get on and do stuff now. Similarly I consider
Emacs / Elisp a reasonable wheel, and I'd rather get on and do stuff
with it than gut the whole thing, yet again. I've watched the effects
of a much more minor gutting on emacs (the 18->19 transition and the
associated schism), and I'm pretty convinced that the much
larger change to a new lisp-dialect would be extremely traumatic.
Sometimes a wheel is good enough.

What is it with this endless desire to pull things to bits, again,
anyway, and the sneering at those who would rather do something else?
The IT/CS community needs to get its head round the fact that this
kind of thing can be *cripplingly* expensive, and that deciding not to
do it on grounds of cost is an absolutely *fine* reason. This stupid
`technical barrier' phrase is just so bloody *dumb*. It's like saying
there's no *technical* barrier to the US sending a manned mission to
Proxima Centuri. Sure, there isn't, but I guess most people in the
USA would kind of rather live in first world conditions rather than
blow the entire GDP of the country for the next hundred years on doing
it. Cost is a factor in engineering decisions and software used in
the real world, like it or not, is not some academic play thing.

The prevalence in the CL community of `this quite reasonable attitude'
is pretty much what I like about CL. It certainly isn't that CL is
some ultimate language: there probably are some parts of the language
that I wouldn't redesign if given a free hand, but I can't quite think
of any. But there's no such thing as a free hand in the real world:
redesign costs real money - lots and lots money. Even for CL,
incompatible changes would cost millions and millions of dollars.
Sometimes what you have is adequate to get real work done, and
stability is more important than reinvention.

Screwed-up initial design together with endless reinvention is why IT
is such a disaster. C not good enough for you? let's have C++, or
this other version of C++, or this one. No, let's reimplement in
Java. Or C#. Or Python. Perl. Ruby. SGML no good? Let's have XML.
Whoops, XML is no good, OK have these other standards which patch it.
Still not getting rich? Damn, have some more hacks. Your macro
system not hygenic? Have this one - just rewrite all those thousands
of lines of macros you've used for years. Upper case identifiers look
ugly? Use this incompatible hack. Don't like prefix syntax? Have
this similar-but-incompatible infix language - just rewrite your code,
why don't you? Just so long as we keep changing stuff fast enough and
waving our hands around *really fast* no one will notice how badly we
are screwing up and how much it is costing them.

Except, you know, they will. The 90s is over now, our hands have
finally parted company from our arms and the bubble has burst. Lots
of people spent billions of dollars on IT because it would transform
the economy and make everyone rich. Software would be too cheap to
meter: we would live in a `gift economy'. But somehow it didn't quite
happen - the economy is somehow untransformed, and all that money
seems to have vanished somewhere. 5% of e-commerce sites work, and 5%
of them ever made any money. But never fear, web services are here!
Just reinvent everything once again, use XML (it must work, it's so
big and complicated by now - how can anything that big not work), and
we'll all get rich this time. Right. Sure. I'll just do something
else, if you don't mind.

--tim

(my last post on this subject)

Kurt B. Kaiser

unread,
Sep 26, 2002, 9:03:37 PM9/26/02
to
Tim Bradshaw <t...@cley.com> writes:

> (my last post on this subject)

I doubt it. But that were a good 'un.

I refer to it my prediliction for sharpening tools instead of getting
work done, and I'm at _least_ as guilty as the next guy. Then there's
discussing the best way to sharpen tools....

You sharpen and sharpen, and the years go by....

KBK

Petr Swedock

unread,
Sep 27, 2002, 12:07:23 AM9/27/02
to
Tim Bradshaw <t...@cley.com> writes:

> * Dorai Sitaram wrote:
> > The prevalence in the CL community of this quite
> > reasonable attitude, rather than any actual technical
>

> I think it's about wheel reinvention. I see that CL is a reasonable
> wheel, and I'd rather get on and do stuff now. Similarly I consider
> Emacs / Elisp a reasonable wheel, and I'd rather get on and do stuff
> with it than gut the whole thing, yet again. I've watched the effects
> of a much more minor gutting on emacs (the 18->19 transition and the
> associated schism), and I'm pretty convinced that the much
> larger change to a new lisp-dialect would be extremely traumatic.
> Sometimes a wheel is good enough.
>
> What is it with this endless desire to pull things to bits, again,
> anyway, and the sneering at those who would rather do something else?

Why? Because the dialogue and the work, such as it is, is hijacked and
determined by the high priest of the church of recursive purity. RMS
isn't your regular 9to5 coder who owns a house, has a family, or even
a semblance of 'normal' life. He's a rather hedonistic monk with a
driven adolescent anti-hero ego AND all the free time that goes
with it... With the titular leadership of the open/free/whatever-
software movement solely because he's dedicated his full time to it.
The rest of us are out there earning money, worrying about rent,
having kids, etc; generally living a life not consumed by the politics
of code and the whims of an ascetic drive for perfection. He's a
MacArthur Genuis Grant gone horribly amok!

Stallman can re-invent the wheel as often as he likes because he's
got the luxury of that adolescent mentality and the support of people
who think his shit don't stink. And then there's the amen chorus
whe see RMS legitimating wheel-re-invention and become liberated
from doing actual work. Most code gets written by having one
person (the boss) direct requirements and specs at another person
(the coder). Not so with Stallman and by extension the FSF and
the question of cost doesn't even come into it.

One of the real problems in IT/CS/software is the un-sexy work that goes
un-done because many admins/engineers/coders lack discipline. RMS
exemplifies this. I've seen many a sysadmin, or network engineer, or
programmer who'd rather re-invent a dozen wheels, usually for the sake
of standing out or apart from the crowd, then to get the job done
right first, or by tweaking existing systems, or cleaning up prior
bad work: Stallman wants to replace Elisp with Guile because Elisp
has some problems that might not be there had he taken more care the
first time around.

Peace,

Petr

Friedrich Dominicus

unread,
Sep 27, 2002, 3:50:54 AM9/27/02
to
Petr Swedock <pe...@blade-runner.mit.edu> writes:
> Stallman wants to replace Elisp with Guile because Elisp
> has some problems that might not be there had he taken more care the
> first time around.
I agree with a lot you've written before but this is terrible
unfair. How often have you sit on code finding a first working
solution, but after that you polish it and it looks completly
different. You can put in as much effort as you want, you will always
find points after finishing that you consider bad done. Than you've to
decide
- fix it
- keep it

What I simply do not understand is that RMS has worked on Lisp
Machines, which do have had all the things in place like Packages, OO-Systems,
System development tools and and and, but nevertheless, he did not
keep that stuff in Emacs Lisp. I guess no-one will know what he has
thought about it while working on it I bet even he does not know any
longer.

It seems to me that Emacs Lisp falls even short behind the Lisps
available to that time. And that is what I can't understand.

Regards
Friedrich

Lars Brinkhoff

unread,
Sep 27, 2002, 2:43:26 AM9/27/02
to
Tim Bradshaw <t...@cley.com> writes:
> Personally I think the idea of replacing elisp by anything is (a)
> insane and (b) incredibly unlikely to happen. XEmacs *ships* with
> more than 2 million lines of emacs lisp, and I bet there is far more

> than that in code that is either not bundled or is not distributed
> at all (I have ~10,000 lines, I bet other people have as much or
> more). No one is going to convert that stuff before hell freezes
> over. So any replacement system has to *precisely* support the
> semantics of elisp, including all the weird gotchas, and it has to
> do it essentially for ever.

elisp.lisp in CLOCC seems to be a good start at loading elisp code
into a Common Lisp.

http://cvs.sf.net/cgi-bin/viewcvs.cgi/clocc/clocc/src/cllib/elisp.lisp?rev=2.10

--
Lars Brinkhoff http://lars.nocrew.org/ Linux, GCC, PDP-10,
Brinkhoff Consulting http://www.brinkhoff.se/ HTTP programming

Alain Picard

unread,
Sep 27, 2002, 6:08:04 AM9/27/02
to
ds...@goldshoe.gte.com (Dorai Sitaram) writes:

> Your message suggested that Emacs was tragically moving
> away from Lisp by switching to Guile, so I
> reassured you that it wasn't. Maybe I misread
> what exactly you were being regretful about.

You didn't misread him. He, and many others, think that
switching to Guile is moving away from lisp.

My only comfort is that I give them very long odds of success
with that project; there's just too damn much elisp code out
there.

Alain Picard

unread,
Sep 27, 2002, 6:11:04 AM9/27/02
to
Tim Bradshaw <t...@cley.com> writes:

> Easy wins would be adding proper
> packages and proper structures - these could be added in mostly
> transparently to old code.

Indeed. An emacs which efficiently implemented (require 'cl) out of the box
would be a nice start.

Getting more and more off topic, I noted that Xemacs can be compiled
with a whole bunch of different C libraries, to give (native) access to things
like databases, etc. A standardized elisp FFI? Anyone? :-)


Jeremy H. Brown

unread,
Sep 27, 2002, 11:58:19 AM9/27/02
to
Alain Picard <apicard+die...@optushome.com.au> writes:
> You didn't misread him. He, and many others, think that
> switching to Guile is moving away from lisp.

Can someone explain this to me? Seriously. What is it about Guile
that has less of the "True Lisp Essence" than Elisp?

Jeremy

Christopher Browne

unread,
Sep 27, 2002, 12:16:42 PM9/27/02
to
Quoth jhb...@ai.mit.edu (Jeremy H. Brown):

It's presumably some aspect of the "we despise Scheme" thing..
--
(reverse (concatenate 'string "moc.enworbbc@" "enworbbc"))
http://www.ntlug.org/~cbbrowne/x.html
JOHN CAGE (strapped to table): Do you really expect me to conduct this
antiquated tonal system?
LEONARD BERNSTEIN: No, Mr. Cage, I expect you to die!
[With apologies to music and James Bond fans the world over...]

Jeremy H. Brown

unread,
Sep 27, 2002, 12:23:54 PM9/27/02
to
Christopher Browne <cbbr...@acm.org> writes:
> It's presumably some aspect of the "we despise Scheme" thing..

If that's really all it is, I'll go back to bed now.

Jeremy

Friedrich Dominicus

unread,
Sep 27, 2002, 2:57:02 PM9/27/02
to

Don't ask such a question. You will get banned ;-) I guess I know some
of the answers, but I do not think that I agree with them. Anyway I do
not like Guile for diverse reasons. The most disturbing is that it's
full in spirit of NIH.

The re-invent things again and again and ...

Others mileage may vary but you will know for sure soon.

Regards
Friedrich

Thien-Thi Nguyen

unread,
Sep 27, 2002, 1:07:48 PM9/27/02
to
jhb...@ai.mit.edu (Jeremy H. Brown) writes:

> Can someone explain this to me? Seriously.

seems to be a (classic + recurrent => chronic) log[ix]or confusion:

(eval-in-context '(or guile elisp) 'human-language) => guile
(eval-in-context '(or guile elisp) 'GNU) => t

if a .el file needs to be changed that is almost certainly a bug. if people
don't follow future guidelines for new code that is a bug in the guidelines,
not the people. if people don't help form these guidelines that is a bug in
the process ultimately (giving rise to more bugs) concerning all the people.

for a wider interpretation:
s/a .el file/history/
s/guideline/law/
s/new code/day to day living/
s/process/society/
s/bug/misfortune/

you cannot harmonize the clans w/ logxor (although it is useful elsewhere,
like in screensavers and other cave-wall-watching exercises).

thi

ozan s yigit

unread,
Sep 27, 2002, 2:56:15 PM9/27/02
to
Friedrich Dominicus:

> The re-invent things again and again and ...

reminds me of a quote: "reinvention is commonplace in any field where
the inventors are amateurs."

oz
---
there is a fault in reality. do not adjust your minds. -- salman rushdie

Dorai Sitaram

unread,
Sep 27, 2002, 3:32:38 PM9/27/02
to
In article <86wup7n...@gondolin.local.net>,

Alain Picard <apicard+die...@optushome.com.au> wrote:
>He, and many others, think that
>switching to Guile is moving away from lisp.
>
>My only comfort is that I give them very long odds of success
>with that project; there's just too damn much elisp code out
>there.

What would you gain by their failure and/or what
would lose by their success?

Erik Naggum

unread,
Sep 27, 2002, 3:35:55 PM9/27/02
to
* Christopher Browne

| It's presumably some aspect of the "we despise Scheme" thing..

It is some aspect of the "let's discard all the community effort and start
over from scratch because we're smarter than everybody else" thing.

Each and every time someone in the Computer Science field has a Bright Idea,
the world had better be prepared to adapt, because Here Comes Genius and
everything everybody has done needs to be done differently from now on,
because This Genius Knows Best.

Gratuitous re-invention is very appealing to some people. It means that they
do not have to cope with anybody else's ideas. They may hope to garner
support behind them, but they sure are not going to be behind anybody else.

I have desired /longevity/ of things for as long back as I can remember. I
got involved with SGML because I thought it could help our data survive
beyond the application. (That was a mistake, of course. XML hit the fan and
now you cannot trust XML data any more than you trust binary files.) I have
been a strong fan of the 125-year-old Dewey Decimal Classification ever since
I learned it as a child from our school librarian. Such a large system that
has been both able to adapt and provide for long-range stability is no small
feat. I prefer a society based in the rule of law to groups of eager people
with bright ideas who ignore everything that has gone before them. It is not
only that I want some stability and predictability, I want to make sure that
we actually evolve. Computer Science is a field that shows some danger signs
of not evolving. Each and every Bright Idea is a revolution, and the primary
purpose of a revolusion is to throw away everything everybody had done up to
some point in time. Revolutions sometimes do work, but their cost in human
terms is /enormous/. Time and again we see that that which moves slowly from
here to there win and that which tries to make it across the incompatibility
abyss in one leap usually fall into it, instead.

The Novice has been the focus of an alarming amount of attention in the
computer field. It is not just that the preferred user is unskilled, it is
that the whole field in its application rewards novices and punishes experts.
What you learn today will be useless a few years hence, so why bother to
study and know /anything/ well? I think this is the main reason for the IT
winter we are now experiencing.

Of course, Scheme was /also/ a "let's have a revolution and make it better
this time" language, and as such is attractive to revolutionaries.

--
Erik Naggum, Oslo, Norway

Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.

Erik Naggum

unread,
Sep 27, 2002, 3:45:35 PM9/27/02
to
* Dorai Sitaram

| The prevalence in the CL community of this quite reasonable attitude, rather
| than any actual technical barrier, may be why CL was able to successfully
| avoid being considered as a candidate for successor to elisp.

Your paranoia only feeds those of us who think Scheme is dangerous.

| I find your reasoning quite understandable. Scheme is only being used for
| something that the CL community didn't want to touch anyway. This should
| answer Dave Bakhash's unnecessarily regret-filled article.

Your need to defend Scheme so hysterically must have some deeper causation
that makes sane people want to avoid Scheme after watching the Scheme
defenders in action. You do Scheme a great disservice. Then again, that
may be a good thing in the really big picture, so perhaps I should not ask
you to stop, after all. However, I think posting Scheme paranoia in this
newsgroup is also hurtful to Common Lisp. People will have reason to wonder
whether Common Lisp people are insane with regards to Scheme whether they
love it or hate it. That is not good for Common Lisp.

Jeremy H. Brown

unread,
Sep 27, 2002, 3:53:55 PM9/27/02
to
Erik Naggum <er...@naggum.no> writes:
> It is some aspect of the "let's discard all the community effort and start
> over from scratch because we're smarter than everybody else" thing.

If you actually went and read the emacs-guile description, you'd note
that the stated intent of that project (I won't speak to random RMS
statements in other places) is not to eliminate elisp, but rather to
integrate guile as another option. Nothing that has gone before is
lost. What is available to those who come after is more flexible than
before. Where's the harm?

Jeremy

Bulent Murtezaoglu

unread,
Sep 27, 2002, 4:29:03 PM9/27/02
to
>>>>> "EN" == Erik Naggum <er...@naggum.no> writes:
[...]
EN> Each and every time someone in the Computer Science field
EN> has a Bright Idea, the world had better be prepared to adapt,
EN> because Here Comes Genius and everything everybody has done
EN> needs to be done differently from now on, because This Genius
EN> Knows Best.

I don't know if "This Genius" himself is to blame for this. There
usually are other factors to consider. While I am fairly certain that
the geniuses (genii?) in question usually have the stuff to back up
their arrogance their marketing apparatus clearly lacks it. As do,
unfortunately, the targets of that marketing themselves.

EN> Gratuitous re-invention is very appealing to some people.
EN> It means that they do not have to cope with anybody else's
EN> ideas. They may hope to garner support behind them, but they
EN> sure are not going to be behind anybody else.

There's also some percieved economy in there, in a way. Reinvention
sometimes takes less time than understanding the state of the art. This
perception is usually misleading, but not always.

EN> I have desired /longevity/ of things for as long back as I
EN> can remember.

You are in good company. Knuth does also (re: TeX).

EN> I got involved with SGML because I thought it
EN> could help our data survive beyond the application. (That was
EN> a mistake, of course. XML hit the fan and now you cannot
EN> trust XML data any more than you trust binary files.) [...]

Am I wrong in assuming that with XML you are roughly as safe as you would
be with a _documented_ binary format?

[...]
EN> The Novice has been the focus of an alarming amount of
EN> attention in the computer field. It is not just that the
EN> preferred user is unskilled, it is that the whole field in its
EN> application rewards novices and punishes experts.

It is unclear what 'expert' means any more. The blind has been
leading the blind for so long that sight is becoming irrelevant in
signifacnt parts of the marketplace.

EN> What you
EN> learn today will be useless a few years hence, so why bother
EN> to study and know /anything/ well? [...]

It is _worse_ than that. The semantics of knowing anything well is
shifting. I am noticing that (and Tim B. sometimes reminds me) that
most of our grumpy observations (rants?) here are observations about
_literacy_. You are implying a conscious decision above -- I am not so
sure about that.

cheers,

BM

Erann Gat

unread,
Sep 27, 2002, 4:40:02 PM9/27/02
to
In article <32421441...@naggum.no>, Erik Naggum <er...@naggum.no> wrote:

> Of course, Scheme was /also/ a "let's have a revolution and make it better
> this time" language, and as such is attractive to revolutionaries.

This is revisionist history. Scheme was an accident, as related by
Sussman and Steele in [1]:

"Sometimes a judicious designer can sort through the accumulated set of
ideas, discard the less important ones, and produce a new design that is
small and clean. ... Scheme wasn't like that at all. We were actually
trying to build something complicated and discovered, serenedipitously,
that we had accidentally designed something that ... was much simpler than
we had intended."

Erann Gat
g...@jpl.nasa.gov

----
References

[1] Sussman and Steele, Journal of Higher Order and Symbolic Computation,
1, 399-404(1998).

Kurt B. Kaiser

unread,
Sep 27, 2002, 6:13:09 PM9/27/02
to
Erik Naggum <er...@naggum.no> writes:
[...]
> I have desired /longevity/ of things for as long back as I can
> remember. I got involved with SGML because I thought it could
> help our data survive beyond the application. (That was a
> mistake, of course. XML hit the fan and now you cannot trust XML
> data any more than you trust binary files.) I have been a strong
> fan of the 125-year-old Dewey Decimal Classification ever since I
> learned it as a child from our school librarian. Such a large
> system that has been both able to adapt and provide for long-range
> stability is no small feat.

I always thought it better than the Library of Congress system. When
they introduced that I was very young, but I remember thinking, "Who
needs that? Dewey is fine, and I know it! Why do I have to start
over?"

> I prefer a society based in the rule of law to groups of eager
> people with bright ideas who ignore everything that has gone
> before them. It is not only that I want some stability and
> predictability, I want to make sure that we actually evolve.
> Computer Science is a field that shows some danger signs of not
> evolving. Each and every Bright Idea is a revolution, and the
> primary purpose of a revolusion is to throw away everything
> everybody had done up to some point in time. Revolutions
> sometimes do work, but their cost in human terms is /enormous/.
> Time and again we see that that which moves slowly from here to
> there win and that which tries to make it across the
> incompatibility abyss in one leap usually fall into it, instead.

True, but I think people are realizing that the "bright ideas" are
over-hyped and don't pan out. You get burned out after a dozen or so.
The "solutions" are getting increasingly frothy and lightweight.

Object-oriented design is down to half a shelf at my local Borders,
and Java's decreasing markedly. C/C++ holding its own. .NET's coming
up. Whole sections on Web tools, Maya, etc., though. The
"programmers" are mostly just users these days.

Sadly, no Lisp books whatsoever most of the time.

> The Novice has been the focus of an alarming amount of attention
> in the computer field. It is not just that the preferred user is
> unskilled, it is that the whole field in its application rewards
> novices and punishes experts. What you learn today will be
> useless a few years hence, so why bother to study and know
> /anything/ well? I think this is the main reason for the IT
> winter we are now experiencing.

As soon as you learn Pearl there's Python, then hey, it's Ruby! HTML
begets XHTML, then we start again with XML. But most of the new stuff
is just applications to create end user content, or toolboxes to wire
up and maintain systems.

The alphabet soup in the job ads is astounding. Who has time to
become an expert before it all changes again?

> Of course, Scheme was /also/ a "let's have a revolution and make
> it better this time" language, and as such is attractive to
> revolutionaries.

That's true. OTOH, it predates CL by about eight years. Some of the
"revolutionary" Scheme concepts, like lexical scope, influenced the
design of CL.

And the revolutionaries have white hair by now and take laxatives :)

In the case of CL, it was "let's form a federation and resolve our
differences." Scheme is, for practical purposes, an academic language
(let them play, for heavens sake!!), while CL is by far our best
production language, even though it's a camel.

"The Evolution of Lisp" [0] has many interesting and amusing remarks
on the origin of CL (among other things) and gives a flavor of the era:

===========
[...]

"The MacLisp-descended groups came off in a way that can be best
demonstrated with an anecdote. Each group stood up and presented
where they were heading and why. Some questions arose about the
ill-defined direction of the MacLisp community in contrast to the
Interlisp community. Scott Fahlman said, "the MacLisp community is
not in a state of chaos. It consists of four well-defined groups
going in four well-defined directions." There was a moment's pause
for the laughter to subside.

Gabriel attended the Interlisp pow-wow the day before the ARP meeting,
and he also witnessed the spectacle of the MacLisp community at the
meeting. He didn't believe that the differences between the MacLisp
groups were insurmountable, so he began to try to sell the idea of
some sort of cooperation among the groups."

[this may be just Gabriel tooting his horn :-]

[...]

"After a day and a half of technical discussion, this group went off
to the Oakland Original, a greasy submarine sandwich place not far
from CMU. During and after lunch the topic of the name for the Lisp
came up, and such obvious names as NIL and SPICE Lisp were proposed
and rejected--as giving too much credit to one group and not enough to
others--and such non-obvious names as Yu-Hsiang Lisp were also
proposed and reluctantly rejected.
[...]
Later in E-mail, Moon referred to "whatever we call this common Lisp,"
and this time, amongst great sadness and consternation that a better
name could not be had, it was selected."

[...]

"The [draft of the manual], called the Swiss Cheese Edition--because it
was full of large holes--was partly a ballot in which various
alternatives and yes-no questions were proposed.
[...]
Three more drafts were made--the Colander Edition (July 29, 1982), the
Laser Edition (November 16, 1982), and the Mary Poppins Edition. The
cute names are explained by their subtitles:

Colander: Even More Holes Than Before--But They're Smaller!

Laser Edition: Supposed to be Completely Coherent

Mary Poppins Edition: Practically Perfect in Every Way

The final draft was the Excelsior Edition. Recall that "excelsior" is
not only a term of high praise but also the name for shredded paper
used as packing material."

===========

Some things don't change. After 20 years, we're still arguing. In
fact, we have a whole new generation of arguers! OTOH, both CL and
Scheme have been pretty stable (ossified?) over that period.

Surely CL isn't the last Lisp. I suspect that one of these days a
wholly new Lisp will pop up from somewhere and everyone will jump on
it. Until then, IMO, we should support the CL federation as the
practical solution for production work. Gradual change might be
practical for sparrows or English, but it's not going to work for
production Lisp.

(But I think they had more fun in the old days.)

KBK

[0] Gabriel and Steele, http://citeseer.nj.nec.com/steele93evolution.html

Christopher Browne

unread,
Sep 27, 2002, 6:35:26 PM9/27/02
to
After takin a swig o' grog, Bulent Murtezaoglu <b...@acm.org> belched out...:

>>>>>> "EN" == Erik Naggum <er...@naggum.no> writes:
> EN> I got involved with SGML because I thought it
> EN> could help our data survive beyond the application. (That was
> EN> a mistake, of course. XML hit the fan and now you cannot
> EN> trust XML data any more than you trust binary files.) [...]

> Am I wrong in assuming that with XML you are roughly as safe as you
> would be with a _documented_ binary format?

The problem with XML is that the W3C keeps on having to modify the
standards because people need one extension or another.

Pretty characteristic of this is to compare XML-RPC to SOAP.

SOAP keeps getting "extended" as companies lobby for one piece of
extended functionality or another. I'm currently editing/reviewing a
book on "Web Services Security," and am pretty nonplussed by the
tremendously frivolous set of security additions that people keep
making. By the time SOAP gets as aged as CORBA, it is unlikely that
anyone will be able to /imagine/ creating a "complete" SOAP
implementation.

And it's NOT 'changing subjects' for me to talk about SOAP rather than
'just XML.' The problems that occur with SOAP are likely to be pretty
nicely characteristic of /any/ "XML Application." Any of the
"interesting" XML Applications are fair game for the 'dueling
standards' game where different companies propose differing layered
standards at OASIS/IETF/W3C.

By the way, the specification for XML-RPC, which SOAP was based on,
fits on two pages. But none of the big companies are interested in
XML-RPC. It's probably comparable with SOAP in much the same manner
that "Algol60 was superior to many of its successors."


--
(reverse (concatenate 'string "moc.enworbbc@" "enworbbc"))

http://cbbrowne.com/info/
Sleep is a poor subsititute for caffeine. -Pat Dughi

ozan s yigit

unread,
Sep 27, 2002, 6:55:41 PM9/27/02
to
g...@jpl.nasa.gov (Erann Gat) writes:

> This is revisionist history. Scheme was an accident, as related by
> Sussman and Steele in [1]:

another paper that may provide insight into why, when, how etc. is
the excellent Steele/Gabriel "the evolution of lisp" paper from the
second HOPL in 1993. it is probably online someplace, though i doubt
it would include the presentation transcript and the assorted family
graphs. it may answer some questions for some people. the book that
was published after the conference is an indispensible reference
for PL types, if it is still in print.

oz
---
[1] Thomas J. Bergin and Richard G. Gibson (eds)
History of Programming Languages
Addison-Wesley, 1996
--

Bruce Stephens

unread,
Sep 27, 2002, 7:33:34 PM9/27/02
to
ozan s yigit <o...@blue.cs.yorku.ca> writes:

> g...@jpl.nasa.gov (Erann Gat) writes:
>
>> This is revisionist history. Scheme was an accident, as related by
>> Sussman and Steele in [1]:
>
> another paper that may provide insight into why, when, how etc. is
> the excellent Steele/Gabriel "the evolution of lisp" paper from the
> second HOPL in 1993. it is probably online someplace,

<http://citeseer.nj.nec.com/steele93evolution.html>

[...]

ozan s yigit

unread,
Sep 27, 2002, 8:45:10 PM9/27/02
to
Bruce Stephens <bruce+...@cenderis.demon.co.uk> writes:

> <http://citeseer.nj.nec.com/steele93evolution.html>

ah. since i have the book, i never bothered to search for it.

oz
--
take the long short cut. -- animation rule of thumb (richard williams)

Alain Picard

unread,
Sep 27, 2002, 9:14:35 PM9/27/02
to
ds...@goldshoe.gte.com (Dorai Sitaram) writes:

The answer to both questions is the same; what is at stake is not
having to learn yet another language; one, moreover, whose essence is
_less_ like what I want, rather than more (i.e., if anything, I want
elisp to be more like CL). I pretty much understand elisp; I can
read 3rd party extensions, see what they do, fix things which don't
work.

Am I lazy to not want to learn another language? You bet. The combined
laziness of myself and thousands of other elisp hackers should count for
something, it seems to me.

Pascal Costanza

unread,
Sep 27, 2002, 10:17:13 PM9/27/02
to
ozan s yigit wrote:
> g...@jpl.nasa.gov (Erann Gat) writes:
>
>>This is revisionist history. Scheme was an accident, as related by
>>Sussman and Steele in [1]:
>
>
> another paper that may provide insight into why, when, how etc. is
> the excellent Steele/Gabriel "the evolution of lisp" paper from the
> second HOPL in 1993. it is probably online someplace, though i doubt
> it would include the presentation transcript and the assorted family
> graphs.

Both the proceedings version and an uncut version are available at
http://www.dreamsongs.com/Essays.html; if you take a closer look at the
description of this paper you will also find a link to the downloadable
slides.

Pascal


John Paul Wallington

unread,
Sep 27, 2002, 11:23:59 PM9/27/02
to
jhb...@ai.mit.edu (Jeremy H. Brown) wrote:

> If you actually went and read the emacs-guile description, you'd note
> that the stated intent of that project (I won't speak to random RMS
> statements in other places) is not to eliminate elisp, but rather to
> integrate guile as another option.

Do you mean http://sourceforge.net/projects/gemacs/ ?

"Guile Emacs is a variant of Emacs which is integrating the
Guile Scheme interpreter as an extension language in addition to
Emacs Lisp."

Because that isn't Emacs.

Or do you mean http://www.mit.edu/~raeburn/guilemacs/ ?

Guile-based Emacs: "This project that I (Ken Raeburn) have started is
for converting GNU Emacs to use Guile as its programming
language. Backwards support for Emacs Lisp will continue to exist, of
course, but it'll be through translation and/or interpretation; the
Lisp engine itself will no longer be the core of the program."

--
John Paul Wallington

Erik Naggum

unread,
Sep 27, 2002, 11:31:26 PM9/27/02
to
* Jeremy H. Brown
| Where's the harm?

Have you ever tracked Emacs versions over an extended period of time and
seen how much Emacs Lisp changes in a five-year period? Have you ever
tracked anything that attempted to have two interfaces over an extended
period of time?

The definite harm is that Emacs Lisp and Guile /will/ diverge and that one
is more maintained than the other, but even so, the community effort that
goes into Emacs will need to be increased just to maintain status quo.

And where are all the /new/ users and developers for Emacs coming from?

Erik Naggum

unread,
Sep 27, 2002, 11:52:44 PM9/27/02
to
* Bulent Murtezaoglu

| Reinvention sometimes takes less time than understanding the state of the
| art. This perception is usually misleading, but not always.

Right now, I am working with project to evaluate the applicability of Dewey
for automated classification, compared to the Open Directory stunt. My main
objection to such stunts it that they get can easily get very enthusiastic
people at the start of the project, but over time need paid staff to maintain
them and it develops into the dreaded "committee work" when it becomes
successful. My take on this is actually deeply social: It is not successful
until it becomes a "democratic" committee project. The idiot individualist
with megalomania will think that others are his inferiors, that people who
work in groups never get anything done while he can get a lot done alone.

A system needs to be alive and workable even when other people than the first
enthusiasts start using it. Reinvention and revolution are enthusiast stuff.
Invention and evolution are engineering.

| Am I wrong in assuming that with XML you are roughly as safe as you would be
| with a _documented_ binary format?

It is a myth that XML is documented. You have no idea what the elements
/actually/ mean (and have warped into over time) until you see the source code
for the application. XML becomes /more/ application-dependent over time than
binary formats because it provides a false security and an appearance that
belies its true nature. XML /is/ a binary format, it is just that it is the
kind of binary formats that line printers and raw text editors can use, too,
and it is no less dependent on the exactness and precision that other binary
formats require. At least when you have a binary format, you know that you
need to have a version field and proper version management. People who think
SGML or XML will save them tend to forget version management and rely on
stupid human tendencies to believe that that which they can "read" must also
be understandable to the machine. The combination of ignorance of computing
principles and programming with the kind of fuzzy thinking we find in people
who have never paid attention to details is seriously deadly to information.

| It is unclear what 'expert' means any more. The blind has been leading the
| blind for so long that sight is becoming irrelevant in signifacnt parts of
| the marketplace.

It saddens me to find that I think this is very good summary of the situation.

| It is _worse_ than that. The semantics of knowing anything well is shifting.
| I am noticing that (and Tim B. sometimes reminds me) that most of our grumpy
| observations (rants?) here are observations about _literacy_. You are
| implying a conscious decision above -- I am not so sure about that.

You may be right. I am far more conscious in general than other people.
But with these saddening words, I shall go and be unconscious for a while.

Erik Naggum

unread,
Sep 27, 2002, 11:55:13 PM9/27/02
to
* Erann Gat
| This is revisionist history.

Really? What you quoted was not in any way contradicting what I said.

Erann Gat

unread,
Sep 28, 2002, 1:42:12 AM9/28/02
to
In article <32421741...@naggum.no>, Erik Naggum <er...@naggum.no> wrote:

> * Erann Gat
> | This is revisionist history.
>
> Really? What you quoted was not in any way contradicting what I said.

PETRUCHIO. I say it is the moon.
KATHERINA. I know it is the moon.
PETRUCHIO. Nay, then you lie; it is the blessed sun.
KATHERINA. Then, God be bless'd, it is the blessed sun;
But sun it is not, when you say it is not;
And the moon changes even as your mind.
What you will have it nam'd, even that it is,
And so it shall be so for all readers of comp.lang.lisp

E.

Erik Naggum

unread,
Sep 28, 2002, 9:53:29 AM9/28/02
to
* Erann Gat
[ typical Erann Gat response ]

Your lack of ability to argue for your case must be seen as agreement that
it was not in any way contradicting what I said. This is progress.

Erann Gat

unread,
Sep 28, 2002, 12:51:07 PM9/28/02
to
In article <32422100...@naggum.no>, Erik Naggum <er...@naggum.no> wrote:

> * Erann Gat
> [ typical Erann Gat response ]
>
> Your lack of ability to argue for your case must be seen as agreement that
> it was not in any way contradicting what I said. This is progress.

It is a lack of willingness, not a lack of ability (though you may
consider it progress nonetheless). I am sick and tired of arguing with
you. My intent in responding to your comment about Scheme was not to
start an argument, but to make other people who might be reading that
thread aware of a fairly obscure historical fact. I leave it up to them
to decide whether what I quoted contradicts what you said or not.

If you (or anyone else) want to know why I think that what I quoted does
contradict your position (as if it isn't blatantly obvious) then *ask* me,
and I'll be happy to answer. But if you simply want to state flat-out
that it doesn't, then fine, it is the blessed sun. I have had my fill of
pointless pissing matches.

E.

Erik Naggum

unread,
Sep 28, 2002, 2:56:06 PM9/28/02
to
* Erann Gat

| I am sick and tired of arguing with you.

You may wish to read an article I posted recently on the indecency of
flaunting your personal problems for others to care about in public.

If you are so sick and tired, the rational response is not to do what you are
so sick and tired of. Having to tell the whole world that you are sick and
tired only communicates to that world that you have such huge problems coping
with your own emotions that you need professional care to get over them and
start to take charge of your own life and take responsibility for your own
actions. /You/ and /only/ you are responsible for continuing to do what you
are so sick and tired of. Your immense lack of intelligent response to your
exasperation is not to your professional credit.

| I leave it up to them to decide whether what I quoted contradicts what you
| said or not.

No, you don't. You want to control other people's conclusions. Be honest.

| I have had my fill of pointless pissing matches.

If that were so, you would simply not engage in more of them, would you? So
it is simply not true. You want to blame the people you piss on for your own
stupid behavior. That is so disgusting that words fail to describe it. Quit!

Grow the hell up, Erann Gat. And, /please/ seek professional help with your
coping problems. This is not a good place to tell the whole world that you
are unable to act rationally on your disturbed emotions. I consider you to
be a disgusting disgrace to the community because you never seem to be able
to hold your emotions back from poisoning your interactions with others. You
rank near the top of the most /unprofessional/ people I have ever met.

And do us all a huge favor and shut the fuck up about how badly you feel.
/Do/ something to feel better, damnit!

--
Erik Naggum, Oslo, Norway Today, the sum total of the money I
would retain from the offers in the
more than 7500 Nigerian 419 scam letters received in the past 33 months would
have exceeded USD 100,000,000,000. You can stop sending me more offers, now.

ilias

unread,
Sep 28, 2002, 3:36:21 PM9/28/02
to

as i've said again: you are fascinating ungentle!

and i've never saw again so precise argumentation-lines against 'one-self'!

but i've to assimilate lisp.

-

cool down.

drink water.

Erann Gat

unread,
Sep 28, 2002, 4:19:11 PM9/28/02
to
In article <32422281...@naggum.no>, Erik Naggum <er...@naggum.no> wrote:

> you never seem to be able to hold your emotions back from poisoning your
> interactions with others

and

> Grow the hell up,

> shut the fuck up

Res ipsa loquitur.

But, sigh, we have had *this* conversation before too.

E.

Erik Naggum

unread,
Sep 28, 2002, 6:14:40 PM9/28/02
to
* Erann Gat

| But, sigh, we have had *this* conversation before too.

What is /wrong/ with you? Do you /have/ to keep pissing on me?

I am beginning to think you are about as toxic as ilias to this forum.

Tim Josling

unread,
Sep 28, 2002, 6:53:06 PM9/28/02
to
Erik Naggum wrote:
>
> It is a myth that XML is documented. You have no idea what the elements
> /actually/ mean (and have warped into over time) until you see the source code
> for the application. XML becomes /more/ application-dependent over time than
> binary formats because it provides a false security and an appearance that
> belies its true nature. XML /is/ a binary format, it is just that it is the
> kind of binary formats that line printers and raw text editors can use, too,
> and it is no less dependent on the exactness and precision that other binary
> formats require. At least when you have a binary format, you know that you
> need to have a version field and proper version management. People who think
> SGML or XML will save them tend to forget version management and rely on
> stupid human tendencies to believe that that which they can "read" must also
> be understandable to the machine. The combination of ignorance of computing
> principles and programming with the kind of fuzzy thinking we find in people
> who have never paid attention to details is seriously deadly to information.
>

XML is an encoding format, no more than that. It is a pretty good encoding
format because it is relatively simple and semi-human-readable, though
verbose. Compare with the alteratives - ad hoc binary formats or the IEEE's
binary format monstrosity whose name I forget.

But it is not a content model. It does not try to be a content model. It does
not define what any/every tag means. You have to define the content model.
Sometimes the tag name gives you an idea what the field means.

Content models all have problems:

Semantic drift - the meaning of fields gradually change.
Redefinition of tags e.g. if employee type is 'CEO' then salary is in millions
of dollars not dollars.
Dialects - different people use the message in different incompatible
undocumented ways.
Lack of clarity about which fields are optional and which are compulsary, and
what are the relationships between fields.

You can't blame this on XML. But nor does XML solve them, except in the
mendacious minds of marketing people.

Tim Josling

Erik Naggum

unread,
Sep 28, 2002, 10:28:24 PM9/28/02
to
* Tim Josling

| XML is an encoding format, no more than that.

You may find it illuminating to do a web search on my name and SGML.

| It is a pretty good encoding format because it is relatively simple and
| semi-human-readable, though verbose. Compare with the alteratives - ad hoc
| binary formats or the IEEE's binary format monstrosity whose name I forget.

As long as you actually believe that such are the alternatives, yes, XML is
better than the completely braindamaged. However, if you start to think
about the problem, XML starts to become an idiotic non-solution that only
creates more problems than it solves. It has all the disadvantages of an ad
hoc binary format, and none of the benefits -- namely compactness and
version sensitivity.

I am actually flabbergasted that anyone reading comp.lang.lisp would /not/
understand how to make something better than XML and even carp on this
"ad-hoc binary format" non-argument. You /do/ realize that Common Lisp
offers a ready-made data syntax, as well, do you not?

| But it is not a content model. It does not try to be a content model. It
| does not define what any/every tag means. You have to define the content
| model. Sometimes the tag name gives you an idea what the field means.

Again, do a quick search for the SGML bibliography. You may find that you
have embarrassed yourself, but if you have any new arguments that I have not
heard in the past 12 years, please feel free to present them after you have
familiarized yourself with what I have done in the SGML arena.

| You can't blame this on XML.

I can, and I do. Languages come with philosophies from which they cannot be
separated. The XML philosphy is stale, stupid, and counter-productive
relative to its own stated goals, among which the most important was supposed
to be the independence of data from the application, which is actually worse
with XML than even /your/ "alternatives".

--

ozan s yigit

unread,
Sep 28, 2002, 11:25:56 PM9/28/02
to
Tim Josling <t...@melbpc.org.au> writes:

> ... ad hoc binary formats or the IEEE's


> binary format monstrosity whose name I forget.

maybe you are thinking of ISO/OSI ASN.1... it is not really that
monstrous in its basic form, though it does have a macro system that
can make things very, very hairy...

oz
---

Tim Josling

unread,
Sep 29, 2002, 3:03:06 AM9/29/02
to
ozan s yigit wrote:
>
> Tim Josling <t...@melbpc.org.au> writes:
>
> > ... ad hoc binary formats or the IEEE's
> > binary format monstrosity whose name I forget.
>
> maybe you are thinking of ISO/OSI ASN.1... it is not really that
> monstrous in its basic form, though it does have a macro system that
> can make things very, very hairy...

Yes it is ASN.1. I personally prefer XML myself, but MYYV.

Tim Josling

Tim Josling

unread,
Sep 29, 2002, 3:22:17 AM9/29/02
to
Erik Naggum wrote:
>
> * Tim Josling
> | XML is an encoding format, no more than that.
>
> You may find it illuminating to do a web search on my name and SGML.
>
> | It is a pretty good encoding format because it is relatively simple and
> | semi-human-readable, though verbose. Compare with the alteratives - ad hoc
> | binary formats or the IEEE's binary format monstrosity whose name I forget.
>
> As long as you actually believe that such are the alternatives, yes, XML is
> better than the completely braindamaged. However, if you start to think
> about the problem, XML starts to become an idiotic non-solution that only
> creates more problems than it solves. It has all the disadvantages of an ad
> hoc binary format, and none of the benefits -- namely compactness and
> version sensitivity.
>

I keep my financial records in the form of a lisp object, so I understand that
lisp has an alternetive here. But it does not solve the problem of defining
the content model.

One project I worked on chose XML as the basis for the data format because

1. It is human readable and editable.
2. It is language and platform independent, more or less.
3. It is simple.
4. Vendor and tool support is good.

XML does not solve a lot of problems.

It does not define a content model. Until recently there was no standard
method to include binary data. Version control. So we added solutions to those
to our in house standard.

It has worked well. To me it has evident advantages that binary formats lack
i.e. ease of debugging. You can look at a message and see if it is OK which is
not possible e.g. with ASN.1. Free/cheap friendly editors exist.

> I am actually flabbergasted that anyone reading comp.lang.lisp would /not/
> understand how to make something better than XML and even carp on this
> "ad-hoc binary format" non-argument. You /do/ realize that Common Lisp
> offers a ready-made data syntax, as well, do you not?
>
> | But it is not a content model. It does not try to be a content model. It
> | does not define what any/every tag means. You have to define the content
> | model. Sometimes the tag name gives you an idea what the field means.
>
> Again, do a quick search for the SGML bibliography. You may find that you
> have embarrassed yourself, but if you have any new arguments that I have not
> heard in the past 12 years, please feel free to present them after you have
> familiarized yourself with what I have done in the SGML arena.
>

I found it but it is not evident to me what you are talking about. Searching
the sgml bib for your name produces 0 hits...

> | You can't blame this on XML.
>
> I can, and I do. Languages come with philosophies from which they cannot be
> separated. The XML philosphy is stale, stupid, and counter-productive
> relative to its own stated goals, among which the most important was supposed
> to be the independence of data from the application, which is actually worse
> with XML than even /your/ "alternatives".
>

My main beef with XML is that it is very oriented to 'text'. Thus the lack of
support for binary data, etc. That just reflects its origins. What do 'text
guys' care about binary data, or compaction for that matter?

If someone claimed XML makes data and applications independent, they were
lying. Unfortunately that it all too common in IT. We have found though that a
message passing architecture does help keep applications from becoming
pathologically coupled. However the determined programmer can still make it
happen if he wants to.

However I don't think anything known to date will solve the problem of making
programs data independent.

To do that would require creating a universal knowledge schema from which all
message types could be subclassed or otherwise derived.

Tim Josling

Erik Naggum

unread,
Sep 29, 2002, 3:43:57 AM9/29/02
to
* Tim Josling

| Yes it is ASN.1. I personally prefer XML myself, but MYYV.

Do you prefer XML to Common Lisp? Have you ever implemented anything that
talks ASN.1 in the native language compared to implementing something based
on DOM?

Knocking ASN.1 is common and accepted in some circles. I have yet to meet
one person who has been critical of ASN.1 who has any idea what it is like.
It has this property in common with Common Lisp -- it is usually attacked
only by people who have no idea what the language is like. It is an amazing
property of people who think they are so smart they do not need to know
something before they make pronouncement about it that they do not even
understand that their credibility is blown to bits. It is probably part of
the exaltation of illiteracy in the part of society that works with IT.

By the way, the SGML Document Interchange Format (ISO 9069) uses ASN.1 to
ship SGML documents around. I wrote an implementation of SDIF in three days.
Test runs showed that a major CALS application consumed approximately 40% of
the character count of the SGML file, and with the then commonly available
tools to parse and process SGML documents and ASN.1 processors, the SDIF data
stream took around 1/200th as much CPU time and about 75% of the memory to
reconstruct the identical in-memory version of the document. This experiment
was among the many data points that led me to conclude that SGML is insane
and that those who think it is rational to require parsing of character data
at each and every application interface are literally retarded and willfully
blind. Also, an SDIF data stream can only represent a validated document and
the kinds of errors you get when parsing ASN.1 are unforgiving. There is no
doubt in my mind that if SDIF had won over the insanely verbose text format,
even things like HTML would have been moderately sane. Not to mention the
fact that images could have been carried in the same data stream. The world
would have been a better place if SDIF had won over HTML, and if the nutjobs
who "invented" XML had been moderately in touch with reality, they would have
realized the insanity of requiring the verbose end-tags and the stupid syntax.
XML-RPC and SOAP and the like could have been fairly inexpensive things.
But, alas, people prefer buggy text formats that they can approximate rather
than precise binary formats that follow general rules that are make them as
easy to use as text formats. Rationality is not part of the SGML philosophy,
however, and SDIF was mainly an effort to keep the ODA and ODIF folks at bay
and was a purely political stunt, not intended to be implemented. When I
went ahead and did it, I was not exactly applauded for the effort. The fact
that it was /vastly/ more efficient in all respects than the stupid character
syntax was /most/ unwelcome by the community.

So, what is your actual experience with ASN.1?

--

Erik Naggum

unread,
Sep 29, 2002, 4:06:57 AM9/29/02
to
* Tim Josling
| [XML] does not define a content model.

Look, you are repeating this as if it is an argument. It is like saying that
Common Lisp does not define an application and shows a lack of insight.

| You can look at a message and see if it is OK which is not possible e.g.
| with ASN.1.

This is just plain wrong.

| Free/cheap friendly editors exist.

No difference from ASN.1 here.

| Searching the sgml bib for your name produces 0 hits...

Why make such a fool of yourself annoying people on purpose? What is /wrong/
with you? http://www.oasis-open.org/cover/biblio.html

| My main beef with XML is that it is very oriented to 'text'.

Wrong on this count, too. Do you have /any/ clue what you are talking about?

| Thus the lack of support for binary data, etc. That just reflects its
| origins. What do 'text guys' care about binary data, or compaction for that
| matter?

Enough to make very good to excellent support for it, given the framework.
XML's /origins/ were SGML and SGML has NOTATION declarations to communicate
the meaning of non-SGML data held in external entities. Most XML nuts do not
understand the entity structure in SGML so reinvent it badly, but generally
fail so miserably that they should feel ashamed.

You clearly are clueless and are not at all ashamed to demonstrate it.

| However I don't think anything known to date will solve the problem of making
| programs data independent. To do that would require creating a universal
| knowledge schema from which all message types could be subclassed or
| otherwise derived.

*SIGH* This does not even merit comment. You are in a /Lisp/ newsgroup, for
crying out loud! Why are you posting here? Did a google search for XML and
just had to chip in or something?

Tim Bradshaw

unread,
Sep 29, 2002, 6:30:07 AM9/29/02
to
* Erik Naggum wrote:

> Gratuitous re-invention is very appealing to some people. It means that they
> do not have to cope with anybody else's ideas. They may hope to garner
> support behind them, but they sure are not going to be behind anybody else.

This is a very interesting point, I think.

A related point, it seems to me, is that reinvention is more-or-less
inevitable if the existing art is so bad that coping with it is too
hard. So one escape from the wheel of reinvention is to try and come
up with systems that are well designed in the first place. This is
obvious of course, but it explains quite a lot.

Two concrete examples.

1. Anyone who's read my previous article(s?) in this thread knows I
think redoing emacs in scheme *or CL*[1] is insane. Well, the
underlying reason for that is that I think the existing system is
not too bad. Of course Emacs Lisp is far from perfect - I think
it's probably the worst Lisp in common use - but it's not *bad*,`
and the `API' to emacs is pretty usable. And there isn't some
enormous wall you have to climb before doing any programming of
emacs as far as I can see - people start by setting a few variables
and end up writing GNUS or something. So we have an acceptably good
system already - the desire to reinvent it indicates something bad.

2. Anyone who has read the drivel I write for a bit longer knows my
feelings about XML. Every time I have to do something for which
XML might seem suitable, I just invent something else, largely so
that I don't have to cope with the ideas behind XML - other
people's ideas. Am I falling into the trap Erik describes? Well,
yes, I am, but I think this is OK. XML and its encrustations seem
to me to be classic examples of the existing art being just too bad
to deal with. XML itself is essentially too simple to do anything
useful. On top of it there is now a huge mass of stuff, the great
majority of which is not well designed, which probably also fails
to solve my problems, or does it in a way which means that simply
dealing with the XML standards becomes about 90% of the code I need
to write - bloating the effort involved in solving the problem by a
factor of 10 over a reinvented solution.

So I think that in order to avoid endless reinvention it's *critical*
to use systems which are good enough[2] in the first place. There are
rather few of those around in IT, because they are *very* hard to
produce. The C/Unix pair is possibly one (but I think probably not),
Emacs/elisp is, I think, one. Common Lisp is the only system that I
am pretty sure is one.

--tim

Footnotes:
[1] That may not have been apparent to people I guess.

[2] Note that I use `good enough' quite deliberately. Perfection is
an unrealistic goal (and one that, if aimed for, will result in
endless reinvention): good enough is, well, enough.


Paolo Amoroso

unread,
Sep 29, 2002, 12:10:40 PM9/29/02
to
On 27 Sep 2002 15:53:55 -0400, jhb...@ai.mit.edu (Jeremy H. Brown) wrote:

> If you actually went and read the emacs-guile description, you'd note
> that the stated intent of that project (I won't speak to random RMS
> statements in other places) is not to eliminate elisp, but rather to

> integrate guile as another option. Nothing that has gone before is

So what was their point about Common Lisp being too large?


Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README

Erik Naggum

unread,
Sep 29, 2002, 1:04:58 PM9/29/02
to
* Tim Bradshaw

| A related point, it seems to me, is that reinvention is more-or-less
| inevitable if the existing art is so bad that coping with it is too hard.

This can be a good reason for re-invention, but then the smart re-inventor
knows the past and what he needs to be better than. If re-invention only
means that one treads the same old path all over again, it is very bad. And
of course knowing the past is going to be hard. That is why psychologists
have to study so many completely bogus psychological theories -- left to
their own devices, past psychologists have invented all these wacky ideas,
and future psychological inventors please take note: they were discarded.

| So one escape from the wheel of reinvention is to try and come up with
| systems that are well designed in the first place.

The force of genious lies behind a significant shift in perspective more
than in new ways to perform old tasks. We humans are pretty annoyingly
limited when it comes to getting stuck in a well-known pattern and those who
are not, tend to be more wacky than genius.

| 1. Anyone who's read my previous article(s?) in this thread knows I
| think redoing emacs in scheme *or CL*[1] is insane.

I once started down that path, but having spent a couple hundred hours on a
Common Lisp-based Emacs, decided that it was going to take a couple thousand
hours before I had a system I would use myself and would be able to attract
others to join in building. I still wonder what would have happened had I
not gotten fed up, but the better system would also be harder to maintain
than to build. Emacs moves on, and if I were to build another Emacs, would
have to duplicate a /lot/ of effort. It would, in brief, be what I would do
for the next few years.

| 2. Anyone who has read the drivel I write for a bit longer knows my feelings
| about XML. Every time I have to do something for which XML might seem
| suitable, I just invent something else, largely so that I don't have to
| cope with the ideas behind XML - other people's ideas.

What can I say? I wasted 6 years of my life on SGML and related technologies
only to find that when I wanted to translate my experience and knowledge and
significant grasp of this technology into a book that would teach what I had
found to others, I had to look real hard at all the braindamaged things that
I had been willing to sweep under the carpet and found, to my horror, that
SGML, once understood, could not possibly be worse implemented than SGML
itself -- if you get the very valuable core ideas behind SGML, SGML was self-
defeating because it had to cater to a huge number of idiotic requests and
requirements that took away from its ability to express what it wanted to
express, and it became such a horribly application-dependent language that
you would have to retarded to write anything worse. I could not publish this
in a book that would be a conceptual introduction to SGML and abandoned the
whole language and my investment in time. Once every two weeks or so, I get
mail from somebody else who have discovered the same thing after actually
having tried to use SGML for something other than a stupid markup language.

| XML and its encrustations seem to me to be classic examples of the existing
| art being just too bad to deal with.

I takes considerable time to understand this, however. If you do /not/ grasp
the core ideas behind SGML and XML, you will probabl invent something worse,
such as an ad-hoc binary format, and since most people would rather die than
think (in fact they do), XML is better than what a braindead ignorant fool
would invent from scratch.

| So I think that in order to avoid endless reinvention it's *critical* to use
| systems which are good enough[2] in the first place. There are rather few of
| those around in IT, because they are *very* hard to produce. The C/Unix pair
| is possibly one (but I think probably not), Emacs/elisp is, I think, one.
| Common Lisp is the only system that I am pretty sure is one.

I think Common Lisp is the only fundamental IT system that is better than
just Good Enough. I am, however, dismayed at what every single vendor does
with the language when it comes to presenting Common Lisp to "modern" stock
computers. For instance, the lack of the full range of hardware integers
really, really bugs me. I got a suggestion in the mail to look at the 8 new
xmm<n> (128-bit) and mm<n> (64-bit) registers in the IA32 platform, and found
that after spending a lot of time on programming specifically for these,
there is absolutely no reason to stick to 32-bit integers on IA32. The too
few legacy registers should be used for interaction with memory, and the mmx
registers should be used for integer arithmetic. Not doing this is not using
the Intel platform for what it's worth. However, this is not done in any of
the Common Lisps available for the Intel platform, although it would give the
compiler writer 8 64-bit integer registers and 8 128-bit numeric registers
that could both be split into smaller registers if need be, and this would
solve so many of the register starvation issues on that platform. This is
the kind of thing that bugs the hell out of me. Then there is the Unix
integration, which is abysmal and forces people to use other languages to do
anything resembling systems programming. Dsspite all I know about Unix and
Common Lisp, I do not feel that I write Common Lisp programs /under/ Unix.
It is as if the Common Lisp programs run on a separate machine somewhere.
And given that "feel", why not exploit the work in virtual machines and JIT
compilers and related efforts in the Java and even the .NET community and let
Common Lisp code become interchangeable and portable between all the
implementations so that there could be a component market and you could
actually develop on one platform and deploy on any number of others. These
are the developments in a significant part of the software market these days,
and it bugs the hell out of me that I have to choose whether to continue to
use Common Lisp if I want to be a part of this. The effort to make a JVM run
inside Common Lisp, for instance, is a really good idea. Now we need a CLVM
that actually supports CLOS. Notice that these are not "user land" things,
they require vendor support and just as much "develop a new system to use the
new ideas" as any other revolution, but at least the programming language
does not need to change, and we should be able to leverage off of all the
existing Common Lisp skills, the standard behind it, textbooks, courses, and
the long experience with the language to get things right. However, it takes
people who actually /like/ Common Lisp to do this and who are professional
enough to set aside their personal issues when implementing the standard
faithfully so others can trust that the specification will be sufficient and
they can concentrate on their application and not have to waste time on
subtle incompatibilities. This would be slightly more interesting than a
Common Lisp Emacs, but I actually think a Common Lisp Emacs would be so much
easier to build once such a system was in place.

Dave Bakhash

unread,
Sep 29, 2002, 5:04:22 PM9/29/02
to
ds...@goldshoe.gte.com (Dorai Sitaram) writes:

> I find your reasoning quite understandable. Scheme is only being used
> for something that the CL community didn't want to touch anyway. This
> should answer Dave Bakhash's unnecessarily regret-filled article.

You just can't seem to get it...that a sizeable chunk of the [Common]
Lisp community does not see things your way...does not like Scheme, and
considers it a significant step in a very different direction...not to
mention that they don't like it. I've seen some of your code that
facilitates inter-workings between Common Lisp and Scheme, and I think
it's great. However, your fundamental argument is not one you can
win...i.e. that Scheme is a good direction or replacement for Lisp-based
systems -- whether they be CL-based, elisp-based, etc.

(X)Emacs would improve if it adopted and incorporated CL as I mentioned
previously because

1) CL is a friendly, cleaner language to develop apps and extensions
in. (my own opinion, of course)
2) CL is well prepared for handling such a huge application, with so
many sub-units, sub-programs, features, and developers
3) CL is an ANSI-standardized language with a strong history and
excellent community.
4) CL would allow for a lot of simplification and performance gain
for the existing (X)Emacs distros. One would be the elimination of
(require 'cl), which (as you can see) many developers enjoy using.

It is important to note, on that last item, that (require 'cl) is (or at
least used to be) supported by GNU Emacs *only* in situations where
there were compile-time effects (i.e. macros). XEmacs allowed packages
to (require 'cl). GNU Emacs always seemed (to me) to shy away from CL.
I don't know too many details here, but I'm not terribly amazed that the
same community wanted Guile over CL. I've worked with a few Scheme guys
to dissociate them from the "Lisp" community. It's not just the
language definition...it's the mindset of the developers.

Of course, it would be ludicrous to have to go through wads of elisp
code, convirting it to something else. That was never an option. The
idea here was to provide additional programming interfaces into the
emacsen. I've seen some amazing feats in elisp of emulating
CL...everything from the 'cl package to a reasonable CL reader and an
implementation of CLOS. But these are all memory hogs, slow as hell,
and still lacking (i.e. not up to spec). A full CL is, in my opinion,
the right answer to the Emacs issue. Guile is something that would make
(X)Emacs *worse*. I think that is what you just don't get. So if you
think that I am unnecessarily remorseful, it is because of the
infectation of the Scheme/Guile community dealing with Lisp-related
issues. Keep diluting the already broad notion of what "Lisp" is with
Scheme Guile, and you just make the problem worse.

dave

Dave Bakhash

unread,
Sep 29, 2002, 5:07:55 PM9/29/02
to
jhb...@ai.mit.edu (Jeremy H. Brown) writes:

> Christopher Browne <cbbr...@acm.org> writes:
> > It's presumably some aspect of the "we despise Scheme" thing..
>
> If that's really all it is, I'll go back to bed now.

Sometimes, lying to yourself helps you sleep at nite.

It seems like this is one of those cases. In that case, good night and
sleep well.

dave

Dave Bakhash

unread,
Sep 29, 2002, 5:53:21 PM9/29/02
to
Alain Picard <apicard+die...@optushome.com.au> writes:

> ds...@goldshoe.gte.com (Dorai Sitaram) writes:
>
> > Your message suggested that Emacs was tragically moving away from
> > Lisp by switching to Guile, so I reassured you that it wasn't.
> > Maybe I misread what exactly you were being regretful about.
>
> You didn't misread him. He, and many others, think that switching to
> Guile is moving away from lisp.

This is correct. I'm glad that someone out there understands what I
meant to say, as well as tends to agree.

Scheme is a degenerate -- a mutation, if you will. There's enough
similarity to notice one of its ancestors, but more to show its
divergence (or deviance, d