"Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Adam Warner
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
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
> "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
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
> 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
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
> 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
> 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
>* 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
> 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
> (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
> * 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
> 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.
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
> Personally I think the idea of replacing elisp by anything is (a)
> insane and (b) incredibly unlikely to happen. XEmacs *ships* with
> 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
> 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
> 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
> 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
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
> 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
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
> 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
> 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
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
| 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
| 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
> 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
[...]
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
> 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
> 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
>>>>>> "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
> 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
> 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
> <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
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
> 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
> 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
| 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
| 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
| This is revisionist history.
Really? What you quoted was not in any way contradicting what I said.
Erann Gat
> * 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
[ 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
> * 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
| 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
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
> 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
| 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
>
> 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