From: Adam Warner
Subject: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <amukd2$9fmn0$1@ID-105510.news.dfncis.de>
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
From: Dave Bakhash
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <c29wup8wyxi.fsf@no-knife.mit.edu>
"Adam Warner" <······@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.
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
From: Dorai Sitaram
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <amvbqp$33u$1@news.gte.com>
In article <···············@no-knife.mit.edu>,
Dave Bakhash <·····@alum.mit.edu> wrote:
>"Adam Warner" <······@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.
>
>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.
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.
From: Dave Bakhash
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <c29ofakww2e.fsf@no-knife.mit.edu>
····@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
From: Dorai Sitaram
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <amvgec$35m$1@news.gte.com>
In article <···············@no-knife.mit.edu>,
Dave Bakhash <·····@alum.mit.edu> wrote:
>····@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.
From: Alain Picard
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <86wup7n3sr.fsf@gondolin.local.net>
····@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.
From: Jeremy H. Brown
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <uv64rcbh1b8.fsf@suspiria.ai.mit.edu>
Alain Picard <·······················@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
Quoth ·······@ai.mit.edu (Jeremy H. Brown):
> Alain Picard <·······················@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?
It's presumably some aspect of the "we despise Scheme" thing..
--
(reverse (concatenate 'string ·············@" "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...]
From: Jeremy H. Brown
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <uv6u1kbflk5.fsf@suspiria.ai.mit.edu>
Christopher Browne <········@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
From: Dave Bakhash
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <c29wup4tsgk.fsf@nerd-xing.mit.edu>
·······@ai.mit.edu (Jeremy H. Brown) writes:
> Christopher Browne <········@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
From: Erik Naggum
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <3242144155107453@naggum.no>
* 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.
In article <················@naggum.no>, Erik Naggum <····@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
···@jpl.nasa.gov
----
References
[1] Sussman and Steele, Journal of Higher Order and Symbolic Computation,
1, 399-404(1998).
From: ozan s yigit
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <vi4adm3qbyq.fsf@blue.cs.yorku.ca>
···@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
--
there is a fault in reality. do not adjust your minds. -- salman rushdie
From: Bruce Stephens
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <87znu3j9dd.fsf@cenderis.demon.co.uk>
ozan s yigit <··@blue.cs.yorku.ca> writes:
> ···@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>
[...]
From: ozan s yigit
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <vi4elbfc57t.fsf@blue.cs.yorku.ca>
Bruce Stephens <············@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)
ozan s yigit wrote:
> ···@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
From: Erik Naggum
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <3242174113416477@naggum.no>
* Erann Gat
| This is revisionist history.
Really? What you quoted was not in any way contradicting what I said.
--
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.
From: Erann Gat
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <gat-2709022242570001@192.168.1.51>
In article <················@naggum.no>, Erik Naggum <····@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.
From: Erik Naggum
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <3242210009461648@naggum.no>
* 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.
--
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.
From: Erann Gat
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <gat-2809020951530001@192.168.1.51>
In article <················@naggum.no>, Erik Naggum <····@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.
From: Erik Naggum
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <3242228166365080@naggum.no>
* 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.
From: Erann Gat
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <gat-2809021319570001@192.168.1.51>
In article <················@naggum.no>, Erik Naggum <····@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.
From: Erik Naggum
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <3242240080475585@naggum.no>
* 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.
--
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.
From: ilias
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <an4vqu$318$2@usenet.otenet.gr>
Erik Naggum wrote:
> * 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!
>
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.
From: Jeremy H. Brown
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <uv6fzvv5hv0.fsf@suspiria.ai.mit.edu>
Erik Naggum <····@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
From: Erik Naggum
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <3242172686385318@naggum.no>
* 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, 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.
·······@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
From: Paolo Amoroso
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <GeSWPXpnK9Qyd68yPng=7me6qdpO@4ax.com>
On 27 Sep 2002 15:53:55 -0400, ·······@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
From: Bulent Murtezaoglu
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <8765wri3dm.fsf@acm.org>
>>>>> "EN" == Erik Naggum <····@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
After takin a swig o' grog, Bulent Murtezaoglu <··@acm.org> belched out...:
>>>>>> "EN" == Erik Naggum <····@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 ·············@" "enworbbc"))
http://cbbrowne.com/info/
Sleep is a poor subsititute for caffeine. -Pat Dughi
From: Erik Naggum
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <3242173964750774@naggum.no>
* 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, 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.
From: Tim Josling
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <3D9632D2.474BC115@melbpc.org.au>
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
From: ozan s yigit
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <vi4smztv5mj.fsf@blue.cs.yorku.ca>
Tim Josling <···@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
---
there is a fault in reality. do not adjust your minds. -- salman rushdie
From: Tim Josling
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <3D96A5AA.449D79A9@melbpc.org.au>
ozan s yigit wrote:
>
> Tim Josling <···@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
From: Erik Naggum
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <3242274237190594@naggum.no>
* 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, 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.
From: Tim Josling
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <3D982EB7.3F663550@melbpc.org.au>
Erik Naggum wrote:
>
> * Tim Josling
> | Yes it is ASN.1. I personally prefer XML myself, but MYYV.
>
> <...rant...>
> So, what is your actual experience with ASN.1?
>
I wrote some code to create and parse some asn.1 messages. I read the spec and
read people's comments about it.
Tim Josling
From: Erik Naggum
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <3242255304507299@naggum.no>
* 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".
--
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.
From: Tim Josling
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <3D96AA29.6B4D8ACD@melbpc.org.au>
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
From: Erik Naggum
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <3242275617011718@naggum.no>
* 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?
--
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.
From: Tim Josling
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <3D984156.550838C7@melbpc.org.au>
Erik Naggum wrote:
> ...(you are wrong... you are an idiot)...
Happy to learn that I am wrong, but it helps to be more specific.
As an example, pointing to a URL with a broken search engine does not help.
Google finds some text by EN, but it is mostly more of the same type of
material we are unfortunately already so familiar with.
I don't think anyone has anything to gain from continuing this discussion.
Anyway, XML verus ASN.1 or SGML is not really relevant to lisp, except by way
of analogy. In some ways it is similar to Lisp versus C as in the "Worse is
Better" paper.
Tim Josling
From: Erik Naggum
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <3242378820299416@naggum.no>
* Tim Josling
| As an example, pointing to a URL with a broken search engine does not help.
Geez, you really are retarded. Such rank incompetence at finding
information is simply not possible in this day and age. Your laziness and
dishonesty speaks volume about your character.
Since you need to be speoon-fed and need assistance finding your own butt,
try <http://www.oasis-open.org/cover/bib-mn.html>, a link found on the very
same page you incompetently could not read. If you know how to avail
yourself of the search function in the browser, use it.
Jesus Christ, the idiots that storm the Net with their opinions these days.
| I don't think anyone has anything to gain from continuing this discussion.
The people who hire you need might gain from it.
--
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.
From: Dorai Sitaram
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <ana13i$9a0$1@news.gte.com>
In article <··············@acm.org>, Bulent Murtezaoglu <··@acm.org> wrote:
> 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).
Well, do Common Lispers really like TeX? Do they truly
appreciate it for being a rock of reliability? I
rather got the impression that they felt that the
"longevity by fiat" that DeK imposed on it was an
unfortunate thing, because he prevented himself and
others from going beyond the constraints of an
older era...
····@goldshoe.gte.com (Dorai Sitaram) writes:
> In article <··············@acm.org>, Bulent Murtezaoglu <··@acm.org> wrote:
> > 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).
>
> Well, do Common Lispers really like TeX?
This one does. If I want to have absolute, 100% control over
everything, I don't use TeX, I use PostScript. But TeX is intended
for setting type, and at that, I haven't found it deficient.
> Do they truly appreciate it for being a rock of reliability? I
> rather got the impression that they felt that the "longevity by
> fiat" that DeK imposed on it was an unfortunate thing, because he
> prevented himself and others from going beyond the constraints of an
> older era...
What "constraints of an older era" are you referring to? I use it all
the time to make hyperlinked PDFs, so if you meant something in that
area, it's all good. Honestly, I don't feel like I'm being held back
in time at all, when using it[*].
[*] Says the man who writes his papers using Emacs and LaTeX on Unix ;)
On the other hand, MS Word users never hear, "I really liked your
exposition of such-and-such a point in this paper ... and it's so
*pretty*, what did you write it in?"
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
In article <············@news.gte.com>, ····@gte.com wrote:
>In article <··············@acm.org>, Bulent Murtezaoglu <··@acm.org> wrote:
>> 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).
>
>Well, do Common Lispers really like TeX? Do they truly
>appreciate it for being a rock of reliability? I
>rather got the impression that they felt that the
>"longevity by fiat" that DeK imposed on it was an
>unfortunate thing, because he prevented himself and
>others from going beyond the constraints of an
>older era...
On pp. xviii-xix of CLtL, Steele thanks Knuth for TEX,
Leslie Lamport for LATEX, and Blue Sky Research for
their Macintosh implementation of TEX. This is in 1989.
I also recall reading that Steele was one of the early
adopters of TEX many years before, but I have no
reference for this.
From: Vassil Nikolov
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <kzbn0pyydbh.fsf@panix2.panix.com>
····@vanderbilt.edu (sv0f) writes:
[...]
> On pp. xviii-xix of CLtL, Steele thanks Knuth for TEX,
> Leslie Lamport for LATEX, and Blue Sky Research for
> their Macintosh implementation of TEX. This is in 1989.
IIRC, that was CLtL2, which also said that the source of the first
edition, written in Scribe, was converted into LaTeX by a throwaway
program.
---Vassil.
From: Lieven Marchand
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <877kh2dq8t.fsf@wyrd.be>
····@vanderbilt.edu (sv0f) writes:
> I also recall reading that Steele was one of the early
> adopters of TEX many years before, but I have no
> reference for this.
Knuth, Digital Typography, p. 648
In the 70s, I had a negative reaction to software that tried to be all
things to all people. Every system I looked at had its own universal
Turing machine built into it somehow, and everybody's machine was a
little different from everybody else's. So I thought, "Well, I'm not
going to design a programming language; I want to have just a
typesetting language." Little by little, however, I needed more
features and so the programming constructs grew. Guy Steele began
lobbying for more capabilities early on, and I put many such things
into the second version of TeX, TeX82, because of his urging.
--
Hai koe, zei de stier,
Kom mee met mij in de wei,
Dan zijn we tweezaam.
Lieven Marchand <···@wyrd.be>
In article <··············@wyrd.be>, Lieven Marchand <···@wyrd.be> wrote:
>····@vanderbilt.edu (sv0f) writes:
>
>> I also recall reading that Steele was one of the early
>> adopters of TEX many years before, but I have no
>> reference for this.
>
>Knuth, Digital Typography, p. 648
>
>In the 70s, I had a negative reaction to software that tried to be all
>things to all people. Every system I looked at had its own universal
>Turing machine built into it somehow, and everybody's machine was a
>little different from everybody else's. So I thought, "Well, I'm not
>going to design a programming language; I want to have just a
>typesetting language." Little by little, however, I needed more
>features and so the programming constructs grew. Guy Steele began
>lobbying for more capabilities early on, and I put many such things
>into the second version of TeX, TeX82, because of his urging.
The collective memory of the group is a wonderful thing. Thanks.
From: Kurt B. Kaiser
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <m33crvt72j.fsf@float.attbi.com>
Erik Naggum <····@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
From: Tim Bradshaw
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <ey31y7d1428.fsf@cley.com>
* 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.
From: Erik Naggum
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <3242307898188612@naggum.no>
* 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.
--
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.
In the "replace EMACS LISP with Guile" thread,
Erik Naggum <····@naggum.no> wrote:
+---------------
| * Tim Bradshaw
| | XML and its encrustations seem to me to be classic examples of the
| | existing art being just too bad to deal with.
|
| It takes considerable time to understand this, however. If you do /not/
| grasp the core ideas behind SGML and XML, you will probably invent
| something worse, such as an ad-hoc binary format...
+---------------
I'm very interested in learning what these "core ideas" are, since I
suspect I am missing something significant (and/or obvious!), and
would appreciate a pointer to any available literature (including
any of your articles archived at <URL:http://www.oasis-open.org/> or
<URL:ftp://ftp.ifi.uio.no/pub/SGML> or elsewhere). Even just a set of
"bullet items" (one-liners) would be appreciated as hints for what to
go look for.
I assume you're *not* talking about trivial stuff like "<tag>foo</tag>"
syntax [which to me is just verbose way of externally representing
(serializing) trees (though not DAGs or more complex structures),
and which S-exprs do a much better job of (especially if you allow
"#n=" & "#n#" for the more complex graphs)], but about one or more
deeper issues that you've hinted at several times but that (not having
studied SGML per se) I don't have the context to follow up on without
more explicit pointers.
Thanks in advance,
-Rob
-----
Rob Warnock, PP-ASEL-IA <····@rpw3.org>
627 26th Avenue <URL:http://www.rpw3.org/>
San Mateo, CA 94403 (650)572-2607
* Rob Warnock
| I'm very interested in learning what these "core ideas" are, since I
| suspect I am missing something significant (and/or obvious!)
To someone familiar with (Common) Lisp, it is much easier to grasp, and may
indeed appear obvious or trivial. These concepts are central:
� declarative elements with contents (not commands).
� hierarchical element structure.
� element structure validation (to a content model).
� element structure normalization (default values).
� element identity and referencing.
� declared entities with uniform references.
� declared notations.
� (abstract) public (entity and notation) identifiers
� a syntactic layer between entity and application.
� an access layer between file systems (networked, etc) and entity
Less central, but still important with respect to the processing model:
� separate specification of position-in-hierarchy-dependent information.
� possible specification of parent, child and left and right sibling relations.
� dynamic inheritance of processing information.
� complete mapping between document and processing element hierarchies.
� marked sections with conditional inclusion.
Things that the SGML community think are important, but which only detract
from the real issues and confuse people tremendously:
� attributes to elements, notations, entities.
� attribute types
� character entities.
� parameter entities.
� marked sections with special syntax for contents.
� elements with special syntax for contents.
� tag minimization and omission.
� the actual syntax.
Neither list should be deemed exhaustive.
| I assume you're *not* talking about trivial stuff like "<tag>foo</tag>"
| syntax [which to me is just verbose way of externally representing
| (serializing) trees (though not DAGs or more complex structures), and which
| S-exprs do a much better job of (especially if you allow "#n=" & "#n#" for
| the more complex graphs)]
The rank incompetence of SGML and XML aficionados has led people to believe
that the syntax cannot represent anything more complex than simple trees.
This is just as wrong as claiming that Common Lisp cannot express circular
lists and other forms of reused objects to preserve identity throughout the
printed form of a structured. Using ID and IDREF is exactly analogous to
using #n= and #n#. (And just as they have special syntax in Common Lisp,
they should have special syntax in an attribute-free SGML. It is the only
thing that /needs/ attributes in the SGML syntax.)
--
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.
Erik Naggum <····@naggum.no> replied:
+---------------
| [...nicely bulleted list...]
+---------------
Thank you! That was exactly the sort of terse overview I was hoping for.
+---------------
| Things that the SGML community think are important, but which only
| detract from the real issues and confuse people tremendously:
|
| � attributes to elements, notations, entities.
| � attribute types
+---------------
Well, this list has certainly talked about *that* one enough before. ;-}
Clearly, since a DTD can specify that some subset of sub-elements (in
arbitrary order) *must* come before all the other permitted sub-elements,
then "attributes" could just as easily be expressed as sub-elements
with restrictions on order, much like declarations and documentation
strings in CL, yes?
+---------------
| | ...verbose way of externally representing (serializing) trees
| | (though not DAGs or more complex structures), and which S-exprs
| | do a much better job of (especially if you allow "#n=" & "#n#" ...)
|
| The rank incompetence of SGML and XML aficionados has led people to believe
| that the syntax cannot represent anything more complex than simple trees.
| This is just as wrong as claiming that Common Lisp cannot express circular
| lists and other forms of reused objects to preserve identity throughout the
| printed form of a structured. Using ID and IDREF is exactly analogous to
| using #n= and #n#.
+---------------
Aha! That's what I get for not having read the actual SGML specs, I guess.
+---------------
| (And just as they have special syntax in Common Lisp, they should have
| special syntax in an attribute-free SGML. It is the only thing that
| /needs/ attributes in the SGML syntax.)
+---------------
I need to think about that one a bit more (and maybe go read some more).
At the moment, it's certainly plausible to me that IDREF might need
special syntax, but it seems like one might to be able to provide ID
(albeit rather awkwardly!) with attribute-free elements [as above].
Anyway, thanks again for the concise summary,
-Rob
-----
Rob Warnock, PP-ASEL-IA <····@rpw3.org>
627 26th Avenue <URL:http://www.rpw3.org/>
San Mateo, CA 94403 (650)572-2607
* Rob Warnock
| Thank you! That was exactly the sort of terse overview I was hoping for.
Happy to oblige, but I think I should whip up a web page on this now that
I think I got it reasonably right. The standing-on-one-leg stunt is hard.
| Clearly, since a DTD can specify that some subset of sub-elements (in
| arbitrary order) *must* come before all the other permitted sub-elements,
| then "attributes" could just as easily be expressed as sub-elements with
| restrictions on order, much like declarations and documentation strings
| in CL, yes?
There is a crucial difference between attributes and subelements today
that needs to be taken care of in an attribute-free SGML. Attributes are
local to their element and therefore can be the same name as an element.
They could also differ in type from element to element, which translates
to a different content model or notation as an element.
| | Using ID and IDREF is exactly analogous to using #n= and #n#.
|
| Aha! That's what I get for not having read the actual SGML specs, I guess.
But you may need to know #n= and #n# and that they are analogous to see
this because the application gets to maintain its own table of IDs and
map the IDREFs back to them, which is kind of unfortunate. Grasping that
this can be used for circular structures is apparently hard for SGMLers
when they have only learned to think of them in "See Figure 1" terms.
| I need to think about that one a bit more (and maybe go read some more).
| At the moment, it's certainly plausible to me that IDREF might need
| special syntax, but it seems like one might to be able to provide ID
| (albeit rather awkwardly!) with attribute-free elements [as above].
One curious effect of moving from attributes to elements is that quite
often, the best design is to let the attribute become a superelement
instead of a subelement.
--
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 <····@naggum.no> wrote:
+---------------
| * Rob Warnock
| | "attributes" could just as easily be expressed as sub-elements with
| | restrictions on order, much like declarations and documentation strings
| | in CL, yes?
|
| There is a crucial difference between attributes and subelements today
| that needs to be taken care of in an attribute-free SGML. Attributes are
| local to their element and therefore can be the same name as an element.
| They could also differ in type from element to element, which translates
| to a different content model or notation as an element.
+---------------
Good point. And also, as Tim Bradshaw pointed out in a parallel
reply <························@cley.com>, attributes are not
permitted to have sub-structure[1], while sub-elements may.
[1] Well, not *standard*, DTD-defined sub-structure, that is, though
as Tim noted, one can always hack up an ad-hoc serialization of
the sub-structure into the string value of an attribute... (*ugh!*)
+---------------
| | | Using ID and IDREF is exactly analogous to using #n= and #n#.
| |
| | Aha! That's what I get for not having read the actual SGML specs, I guess.
|
| But you may need to know #n= and #n# and that they are analogous to see
| this because the application gets to maintain its own table of IDs and
| map the IDREFs back to them, which is kind of unfortunate.
+---------------
Do you mean that the application is allowed to merge (remapping as needed)
IDs/IDREFs from *multiple* documents? ...or *across* multiple docs?
[Otherwise I don't see where any "table" or "mapping" is needed, other
than just the one necessary for #n=/#n# processing during the READ.]
Hmmm... The corresponding thing in CL might be trying to reference the
same #n=/#n# numbers across multiple occurrences of READ. Normally,
that wouldn't be a problem (because it's not possible), but my twisted
little brain just started wondering about how #n= & #n# might interact
with #. in pathological cases, as in:
(foo #1=bar #.(read-from-string "(a #1=b c #1# d)") gorp #1# blah)
Well, maybe that's not a good example -- both CLISP & CMUCL handle it,
yielding (FOO BAR (A B C B D) GORP BAR BLAH) -- but *this* one, maybe:
#1=(foo bar #.(read-from-string "#1=(a b c #1# d)") gorp #1# blah)
CLISP handles it this way [assuming (setq *print-circle* t), else it
core-dumps]:
> '#1=(foo bar #.(read-from-string "#1=(a b c #1# d)") gorp #1# blah)
#1=(FOO BAR #2=(A B C #2# D) GORP #1# BLAH)
>
While CMUCL complains:
Reader error at 3 on #<String-Input Stream>:
Multiply defined label: #1=
O.k., CLHS "2.4.8.15 Sharpsign Equal-Sign" says:
The scope of the label is the expression being read by the
outermost call to read; within this expression, the same label
may not appear twice.
So perhaps in CLISP's case the READ-FROM-STRING instance causes a
completely different instance of READ (and thus the two #1= aren't
"the same") and in CMUCL's case READ-FROM-STRING "knows" it's inside
an active READ and (legitmately) tosses an error.
But then why does CMUCL *accept* the first form at all?!? They both
have the same "outermost call to read"...
+---------------
| Grasping that this can be used for circular structures is apparently
| hard for SGMLers when they have only learned to think of them in
| "See Figure 1" terms.
+---------------
*ROTFLMAO!* Yes, I know what you mean, but... Does "See Figure 1"
have the same alternate meaning for you guys over there as it does
around here?!? ;-} ;-}
<URL:http://www.tuxedo.org/~esr/jargon/html/entry/See-figure-1.html>
<URL:http://www.things.org/~jym/fun/see-figure-1.html>
+---------------
| | I need to think about that one a bit more (and maybe go read some more).
| | At the moment, it's certainly plausible to me that IDREF might need
| | special syntax, but it seems like one might to be able to provide ID
| | (albeit rather awkwardly!) with attribute-free elements [as above].
|
| One curious effect of moving from attributes to elements is that quite
| often, the best design is to let the attribute become a superelement
| instead of a subelement.
+---------------
Yeah, I was starting to think in that direction, since it reduces the
number of levels of nesting you need in the common case of only one
attribute. It's much like CL WITH-XXX macros, in that way. (And why
am I suddenly thinking of CLOS "around" methods, too? ;-} )
-Rob
-----
Rob Warnock, PP-ASEL-IA <····@rpw3.org>
627 26th Avenue <URL:http://www.rpw3.org/>
San Mateo, CA 94403 (650)572-2607
* Rob Warnock
| Good point. And also, as Tim Bradshaw pointed out in a parallel reply
| <························@cley.com>, attributes are not permitted to have
| sub-structure[1], while sub-elements may.
Well, actually, you can provide a NOTATION argument for attribute values.
This would indicate the standard or other document specifying the syntax
of the value, and the application would presumably know how to deal with
this. Also, there are actually some attribute types that require a flat
list of whitespace-separated values in the actually attribute value.
| Do you mean that the application is allowed to merge (remapping as
| needed) IDs/IDREFs from *multiple* documents? ...or *across* multiple
| docs?
ID and IDREF have many conflated uses. IDREF can only refer to IDs in
the same document instance, but with other mechanisms, you can refer to
elements with a given ID.
| The corresponding thing in CL might be trying to reference the same
| #n=/#n# numbers across multiple occurrences of READ. Normally, that
| wouldn't be a problem (because it's not possible), but my twisted little
| brain just started wondering about how #n= & #n# might interact with
| #. in pathological cases, as in:
I would have thought it fairly obvious that (list #.(foo #1=bar) #1#)
must fail, and it did not appear any less obvious that (list #1=foo
#.(foo #1#)) must fail. However, this is wrong. They work fine in
Allegro CL, CLISP and CMUCL (and SBCL). Hmm.
However, when you call a `read� function without a true `recursive-p�
argument, that should mean that it establishes a new #n# context.
| +---------------
| | Grasping that this can be used for circular structures is apparently
| | hard for SGMLers when they have only learned to think of them in
| | "See Figure 1" terms.
| +---------------
|
| *ROTFLMAO!* Yes, I know what you mean, but... Does "See Figure 1"
| have the same alternate meaning for you guys over there as it does
| around here?!? ;-} ;-}
Yes, and it was intentional. (I always appreciate it when people "get"
such jokes.) I initially wrote "See Chapter 42" but that was hackneyed
and not entertaining at all.
--
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.
From: Tim Bradshaw
Subject: Re: Core ideas behind SGML and XML
Date:
Message-ID: <ey3u1k6uyv1.fsf@cley.com>
* Rob Warnock wrote:
> Well, this list has certainly talked about *that* one enough before.
> ;-} Clearly, since a DTD can specify that some subset of
> sub-elements (in arbitrary order) *must* come before all the other
> permitted sub-elements, then "attributes" could just as easily be
> expressed as sub-elements with restrictions on order, much like
> declarations and documentation strings in CL, yes?
We have had various fights with clients about just this kind of
thing. We have a system where define `modules', which are essentially
conceptual units of <something> in a build system. Modules have
various parameters such as dependencies, names, and so on. The native
syntax is completely regular and looks like:
(idl-files
(:name "f1"
...)
...)
And lo and behold this ends up as something like:
(let ((m (make-instance 'idl-files :name "f1" ...)))
(loop for b in body
do (add-item-for m b))
m)
(in fact it's a lot more complex than this, but this is the idea).
So of course the `natural' XML version of this is:
<idl-files name="f1">...</idl-files>
So people complained bitterly when we did this as:
<idl-files>
<parameters>
<parameter>...</parameter>
...
</parameters>
...
</idl-files>
So why did we do it like that? Because XML attributes can't have
structured data, so if you want, say, a list of things in an
attribute, you have to write your own little parser, oh joy. And (not
in the examples above) we *do* have structured data.
What we ended up with was a hack that looked for XML attributes and
translated them to parameters with stringy values.
--tim
On Mon, 30 Sep 2002 08:34:08 -0000, ····@rpw3.org (Rob Warnock) wrote:
> In the "replace EMACS LISP with Guile" thread,
> Erik Naggum <····@naggum.no> wrote:
[...]
> | It takes considerable time to understand this, however. If you do /not/
> | grasp the core ideas behind SGML and XML, you will probably invent
> | something worse, such as an ad-hoc binary format...
> +---------------
>
> I'm very interested in learning what these "core ideas" are, since I
Erik also answered a similar question by me. See the comp.lang.lisp article
with Message-ID <················@naggum.no>.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
From: Tim Bradshaw
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <ey3adlzzpm9.fsf@cley.com>
* Erik Naggum wrote:
> 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.
I think this is right. I must admit though I sometimes cop out and
work on the basis of manual-inches to perform some trivial task -
usually something that I already know how to do in some other way. In
fact my metric is more complex than this, since I also look at the
first differential of manual-inches with time. Things like CORBA
clearly have a fairly large manual-inch count, but the rate of change
of manual-inches is not too bad, and if you look at what CORBA needs
to do (such as support COBOL...) then it's fairly clear why it's quite
big, even if it's pretty frustrating to use. XML though now has
really large manual-inches and a rate of change which seems to be
proportional to the manual-inches, with all that implies in the way of
collapsing floors. And whenever I look at doing something in XML I
could do it more easily with sexps, and this seems to be independent
of the manual-inch count.
Manual-inches, incidentally, is the best known unit. Some people have
suggested things like manual-words but this is not enough as it
ignores typographical issues - manuals with too few words per inch are
typically very hard to use as the density of information is so low.
Unfortunately even manual-inches has some problems as it encourages
very small type sizes and long lines...
--tim
From: Erik Naggum
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <3242392313780400@naggum.no>
* Tim Bradshaw
| Manual-inches, incidentally, is the best known unit.
I tend to measure things by the weight and thickness of the paper and the
spaciousness of the typography of the books you find on the market about
something. I have seen books on Visual Basic with the same page count as
books on C but with 3 times the shelf space. I have seen books on HTML with
same amount of contents as books on Ada with 9 times the volume. I have come
to believe that large print, thick and heavy paper, and wide margins and
oversize leading is indicative of the expected intelligence of the reader.
If the reader is expected to be unable to concentrate or experiences mental
fatigue just by looking at a page of text without oceans of whitespace, the
material is probably geared towards people whose reading skills plateaued
before they entered high school. Compare children's books and books on Web
Duhsign or other X-in-21-days books. If the reading level of a specification
is below college level, chances are the people behind it are morons and the
result morose.
If typography and reading level are comparable, manual-inches is probably a
good measure, but a children's specification for something may be thinner
than a solid work of engineering that it would actually take less time to
grasp because it is so hard to sink to the level of children who need to be
told things over and over and usually do not remeber subtle differences from
repetition to repetion like reasonably smart people do. (At least I find
that I cannot read material written by people who are too stupid. This was,
incidentally, how I first began to understand that sports in the newsmedia is
/intended/ to keep people in a semi-comatose, non-thinking state of mind
where cheering for some idiot gang of testosterone bombs could be regarded as
recreationally rewarding.)
--
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.
From: Tim Bradshaw
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <ey3ptuv8lfd.fsf@cley.com>
* Erik Naggum wrote:
> I tend to measure things by the weight and thickness of the paper and the
> spaciousness of the typography of the books you find on the market about
> something.
Yes, this (including the elided stuff) is a much better summary than
mine. Thinking about it, I tend to judge things on whether they look
like a *book* rather than something else. I'm going to just fail to
define what I mean by `look like a book' because I probably can't
produce a decent definition without, aha, writing a book. But to
oversimplify horribly, I think that book design (including technical
book design) is something that has got fairly well sorted out after a
few hundred years of it, and it's quite hard to come up with a (paper[1])
presentation of something that is better than how well-designed books
look. So anything that looks too different (and lots of the
x-in-21-days `books' look very different) is either badly designed or
well-designed but trying to do something other than get information
across.
--tim
Footnotes:
[1] In fact, this is true (for me) for other media too. In
particular I really hate things that have too many (hyper)links
instead of giving a coherent presentation of something.
Obviously linking can be well done (something like a reference
manual or specification clearly needs a fair number of links) but
too often it is just an excuse to avoid structuring a document
well, or at all.
From: ozan s yigit
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <vi4n0pydcat.fsf@blue.cs.yorku.ca>
Tim Bradshaw [on judging books]:
> ... So anything that looks too different (and lots of the
> x-in-21-days `books' look very different) is either badly designed or
> well-designed but trying to do something other than get information
> across.
i should mention a couple of books [assuming the topics are of any interest]
that may get dropped on the floor because of their look, dimensions, title,
typefaces, line spacing, grade of paper, illustrations, dumb icons and
other non-content problems:
The Cartoon Guide to Statistics
Larry Gonick and Woollcott Smith
Harperparennial, 1993.
[probably one of the finest books on statistics ever written
and i even own a first edition freedman/pisani/purves...]
The Complete Idiot's Guide to Publishing Science Fiction
Cory Doctorow and Karl Schroeder
Alpha Books, 2000
[a very sharp, must-read book on becoming an SF writer and
publishing what you write.]
[nothing in my CS shelves jump at me right now, though i think meyer's
2nd ed may have given a fluffier impression to an innocent browser than
it actually is. on the other side, hopcroft/motwani/ullman "introduction
to automata theory [etc]" is a money-making exercise with much reduced
theory literacy and should be avoided while holding nose...]
oz
--
the balance of the programmed signal. -- mark v. shaney
From: Thien-Thi Nguyen
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <kk9ptuzfjiz.fsf@glug.org>
·······@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
From: Friedrich Dominicus
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <87adm3ntvl.fsf@fbigm.here>
·······@ai.mit.edu (Jeremy H. Brown) writes:
> Alain Picard <·······················@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?
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
From: ozan s yigit
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <vi4d6qzp8hc.fsf@blue.cs.yorku.ca>
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
From: Dorai Sitaram
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <an2bom$51g$1@news.gte.com>
In article <··············@gondolin.local.net>,
Alain Picard <·······················@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?
From: Alain Picard
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <86ofaincec.fsf@gondolin.local.net>
····@goldshoe.gte.com (Dorai Sitaram) writes:
> In article <··············@gondolin.local.net>,
> Alain Picard <·······················@optushome.com.au> wrote:
> >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?
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.
From: Dorai Sitaram
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <an9l0c$942$1@news.gte.com>
In article <··············@gondolin.local.net>,
Alain Picard <·······················@optushome.com.au> wrote:
>····@goldshoe.gte.com (Dorai Sitaram) writes:
>
>> In article <··············@gondolin.local.net>,
>> Alain Picard <·······················@optushome.com.au> wrote:
>> >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?
>
>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.
I quite understood the inertia argument for elisp.
What seems strange is that you expressed a desire for
something the near opposite of what you actually
needed. If the Guile-Emacs people succeed, you get to
negotiate it with your familiar elisp. If, OTOH, they
fail -- even if you keep the current non-Scheme Emacs
around -- you may have to willy-nilly deal with the new
Emacs's Scheme-like extension language, which would be
a waste of time for you.
>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.
Well said. I personally wouldn't mind a little or even
huge tracts of failure in the Guile simulation of
elisp, because I never really developed a dependence on
emacs, let alone elisp. I use another editor purely
because of the vagaries of my job -- and like
you, I'm probably too lazy to shift too --, and
when I do use emacs for its convenient shelling
capabilities, I tend to stick to what used to be called
coke-bottle sequences. But clearly there are armies of
power users of emacs. It is imperative to get elisp
working perfectly or abandon (or at least rename) the
new emacs project altogether. I think we agree on that
one at least.
Editors are some of the most commonly created software
artifacts, and they always seem to find users. A
Scheme-based editor that is almost exactly like Emacs
would almost certainly find a considerable niche,
what with the Scheme users around. Of course, it
doesn't have to be The replacement for Emacs.
From: Alain Picard
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <868z1i7gmb.fsf@gondolin.local.net>
····@goldshoe.gte.com (Dorai Sitaram) writes:
> Editors are some of the most commonly created software
> artifacts, and they always seem to find users. A
> Scheme-based editor that is almost exactly like Emacs
> would almost certainly find a considerable niche,
> what with the Scheme users around. Of course, it
> doesn't have to be The replacement for Emacs.
I admitted to laziness, so now, I'll admit to selfishness
as well: I'd rather that people write more elisp modules
(or enhance existing ones) from which _I_ can benefit than
re-implement existing functionality in yet another editor.
Ooooh, I'm so _bad_. 8-)
From: Fred Gilham
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <u7smzqi31k.fsf@snapdragon.csl.sri.com>
Dorai Sitaram wrote:
> Editors are some of the most commonly created software
> artifacts, and they always seem to find users. A
> Scheme-based editor that is almost exactly like Emacs
> would almost certainly find a considerable niche,
> what with the Scheme users around. Of course, it
> doesn't have to be The replacement for Emacs.
Somehow the word `edwin' keeps coming to mind. Wasn't that virtually
an emacs clone in scheme? How complete was it? I thought it ran
elisp.
--
Fred Gilham ······@csl.sri.com || GOVERNMENT: A large charity
organization with a coercive fund-raising arm. PUBLIC SCHOOLS:
Government-run (see above) schools with coercive admissions
departments.
In an attempt to throw the authorities off his trail, Fred Gilham <······@snapdragon.csl.sri.com> transmitted:
> Dorai Sitaram wrote:
>> Editors are some of the most commonly created software artifacts,
>> and they always seem to find users. A Scheme-based editor that is
>> almost exactly like Emacs would almost certainly find a
>> considerable niche, what with the Scheme users around. Of course,
>> it doesn't have to be The replacement for Emacs.
>
> Somehow the word `edwin' keeps coming to mind. Wasn't that
> virtually an emacs clone in scheme? How complete was it? I thought
> it ran elisp.
"This chapter describes how to start Edwin, the MIT Scheme text
editor. Edwin is very similar to GNU Emacs -- you should refer to
the GNU Emacs manual for information about Edwin's commands and key
bindings --- except that Edwin's extension language is MIT Scheme,
while GNU Emacs extensions are written in Emacs Lisp. This manual
does not discuss customization of Edwin."
Edwin is "sufficiently complete" that it will read your existing Info
configuration, and can browse Info files.
There does not appear to be any guide to writing extensions.
<http://www.cs.colorado.edu/~main/manuals/scheme/user_66.html>
Missing Subsystems
The following documented subsystems are implemented by Emacs but not
by Edwin.
* abbrev mode (edwin has dynamic abbreviations)
* emulation modes: edt, vi, vip
* file locks
* language modes: emacs-lisp, fortran, lisp, modula-2, prolog
* overwrite mode
* picture mode
* slow terminal incremental search
* spelling
* tab stops
* text formatter modes: nroff, scribe, tex, latex
It /does/ have modes for C and Scheme, so the "lack of language modes"
is about the notion of it not having Great Gobs of Modes.
--
(concatenate 'string "cbbrowne" ·@cbbrowne.com")
http://www3.sympatico.ca/cbbrowne/spreadsheets.html
Would-be National Mottos:
Switzerland: "You wouldn't hit a country that's neutral, would you?"
From: Dorai Sitaram
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <anc7gt$b2p$1@news.gte.com>
In article <··············@gondolin.local.net>,
Alain Picard <·······················@optushome.com.au> wrote:
>
>I admitted to laziness, so now, I'll admit to selfishness
>as well: I'd rather that people write more elisp modules
>(or enhance existing ones) from which _I_ can benefit than
>re-implement existing functionality in yet another editor.
TANSTAAFL.
From: Dave Bakhash
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <c29r8fctqcu.fsf@nerd-xing.mit.edu>
Alain Picard <·······················@optushome.com.au> writes:
> ····@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, depending on how you see it).
It's just as in biology: most mutations are bad, though some are good.
Scheme is a bad one. But like a cancer, it grows, feeding mostly on the
vast pool of beginners who think it's easy and elegant. Unfortunately,
it has grown into this newsgroup, as well as into applications some of
us care about.
Dorai can knock me all [s]he wants. But it won't change the fact that
Scheme is viewed as a perversion, lacking some of the best features of
Lisp-family languages, and adding little useful.
dave
From: ozan s yigit
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <vi465wokvtx.fsf@blue.cs.yorku.ca>
Dave Bakhash [on scheme]:
> ... Unfortunately,
> it has grown into this newsgroup, as well as into applications some of
> us care about.
i wrote a spec-compliant implementation of the language some thirteen years
ago with the sincere intention to replace elisp with scheme. when i was done
emacs was not as important, and the implementation ended up as an extension
language for one of the popular sgml editors of the time. so you see, there
has already been years of scheming in applications some of us cared about
and you may not even know anything about it.
oz
---
don't count your chickens in glass houses until the cows come home.
-- david vestal
From: Dave Bakhash
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <c291y7bn930.fsf@no-knife.mit.edu>
ozan s yigit <··@blue.cs.yorku.ca> writes:
> i wrote a spec-compliant implementation of the language some thirteen
> years ago with the sincere intention to replace elisp with
> scheme. when i was done emacs was not as important, and the
> implementation ended up as an extension language for one of the
> popular sgml editors of the time. so you see, there has already been
> years of scheming in applications some of us cared about and you may
> not even know anything about it.
Sometimes it's important to recall the original problem, or goal. Emacs
is an editor. It came with an extension language (Emacs Lisp) which was
powerful enough so that over a score or so people have been able to
contribute mounds of useful add-ons providing mailers, news readers,
IDEs, games, etc.
However, Emacs Lisp is slow, and also ugly in several respects. This
became apparent when things like web browsers were attempted in elisp.
To cope with the problem, and to make programming more sophisticated
applications inside Emacs that would not require diving into C caused
serious discussion about how to make Emacs more easily programmable,
execute extension code more efficiently, and yet provide a clean
interface to legacy Emacs Lisp code.
There were many proposals. Two were CL and Guile, and I'd say that
within each of these are pros and cons. For me, the pros for the CL
camp were obvious:
o excellent CL compilers exist in the open source community
o CL is powerful and general enough to handle processing Emacs Lisp
o CL is more in the spirit of the original Emacs Lisp language
o CL is an ANSI-standardized language, and already had an impact
on literally thousands of Emacs Lisp programs, meaning that by
using CL, you are not turning your backs on the vast pool of
existing elisp contributors. You are giving them *more* rather than
something completely different.
I can go on for many pages about all of the features of CL that I think
are useful, and would make adding to Emacs a joy, but some of the main
reasons are the few above.
If you wanted to start an Emacs-like editor from scratch, without
understanding the history, the elisp developer community, and the elisp
language features and existing codebase, then yeah...sure...do it in
Scheme or whatever language you want for that matter (several people
have already). But we were talking about Emacs, and that's much more
than just an application at this point.
dave
From: Tim Bradshaw
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <ey3k7l3y8e8.fsf@cley.com>
* Dave Bakhash wrote:
> However, Emacs Lisp is slow, and also ugly in several respects. This
> became apparent when things like web browsers were attempted in elisp.
I think the only web browser I know of in elisp (namely emacs w3) is
slow for reasons that a profiler would help with a whole lot more than
a new language. Other than w3, whenever I've profiled emacs I've
discovered that it spends about 90% of its time in redisplay, in C
code.
--tim
From: Dave Bakhash
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <c29zntzpei7.fsf@nerd-xing.mit.edu>
Tim Bradshaw <···@cley.com> writes:
> * Dave Bakhash wrote:
>
> > However, Emacs Lisp is slow, and also ugly in several respects. This
> > became apparent when things like web browsers were attempted in elisp.
>
> I think the only web browser I know of in elisp (namely emacs w3) is
> slow for reasons that a profiler would help with a whole lot more than
> a new language. Other than w3, whenever I've profiled emacs I've
> discovered that it spends about 90% of its time in redisplay, in C
> code.
yeah...I think that I once read that XEmacs (and I think Emacs too) uses
its own redisplay engine. But I don't think that this is the problem
with w3. w3 spends a vast amount of time parsing the HTML, and then
another displaying it. The display engine runs through the parse tree,
building the page as it goes. But the part that hurts is not in the C
world AFAIK, because watching how many times XEmacs GC's while trying to
display a page suggests some very inefficient garbage
collection...another area where using a CL with a more efficient GC
would do wonders.
Of course, then there's the question of how efficient the w3 code is.
dave
From: Tim Bradshaw
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <ey3heg7wa73.fsf@cley.com>
* Dave Bakhash wrote:
> Of course, then there's the question of how efficient the w3 code is.
yes, that was my point. I looked at it (briefly), and it's not good.
--tim
From: Dave Bakhash
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <c29it0j16ta.fsf@no-knife.mit.edu>
Tim Bradshaw <···@cley.com> writes:
> * Dave Bakhash wrote:
> > Of course, then there's the question of how efficient the w3 code is.
>
> yes, that was my point. I looked at it (briefly), and it's not good.
Now, as I recall, there is a Web browser that was out a couple of years
ago, written in CL (I think under ACL). If Emacs could handle CL, then
it could actually just plug in. That would have been nice.
Does anyone recall this CL browser? Anyone ever use it?
dave
From: Timmy Douglas
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <873crn3vcm.fsf@r41h31.res.gatech.edu>
Dave Bakhash <·····@alum.mit.edu> writes:
> Tim Bradshaw <···@cley.com> writes:
>
>> * Dave Bakhash wrote:
>> > Of course, then there's the question of how efficient the w3 code is.
>>
>> yes, that was my point. I looked at it (briefly), and it's not good.
>
> Now, as I recall, there is a Web browser that was out a couple of years
> ago, written in CL (I think under ACL). If Emacs could handle CL, then
> it could actually just plug in. That would have been nice.
>
> Does anyone recall this CL browser? Anyone ever use it?
I think it was called closure, but I never used it. Got this link from
google:
www.uni-karlsruhe.de/~unk6/closure/
It looks like it has it's own gui so I'm not sure if it would simply
plug into emacs.
From: Daniel Barlow
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <87lm5e7g3c.fsf@noetbook.telent.net>
Timmy Douglas <·······@mail.gatech.edu> writes:
> Dave Bakhash <·····@alum.mit.edu> writes:
>> Does anyone recall this CL browser? Anyone ever use it?
>
> I think it was called closure, but I never used it. Got this link from
> google:
Current versions of closure are considerably changed from what you see
on that web page: it's now CLIM-based, and Gilbert Baumann (the
author) is also hacking on McCLIM (a.k.a FreeCLIM). Gilbert gave a
presentation on it at the Libre Software Meeting 2002, and there are a
few screenshots of it at http://ww.telent.net/cliki/Screenshots
> It looks like it has it's own gui so I'm not sure if it would simply
> plug into emacs.
I'm not sure why you'd want to plug a web browser into emacs any more
than you'd want to plug, say, a mua or usenet reader into emacs.
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
From: Alain Picard
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <863crmy14m.fsf@gondolin.local.net>
Daniel Barlow <···@telent.net> writes:
> I'm not sure why you'd want to plug a web browser into emacs any more
> than you'd want to plug, say, a mua or usenet reader into emacs.
The reason for all these is the same: when composing messages,
articles, form fields in web forms, etc, you have the most
powerful editor at your command. In this respect, emacs users
have had the true IDE all along, and don't need to remember
27 ways of doing the same thing in 27 different applications.
From: Daniel Barlow
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <87elb676bx.fsf@noetbook.telent.net>
Alain Picard <·······················@optushome.com.au> writes:
> Daniel Barlow <···@telent.net> writes:
>
>> I'm not sure why you'd want to plug a web browser into emacs any more
>> than you'd want to plug, say, a mua or usenet reader into emacs.
>
> The reason for all these is the same: when composing messages,
> articles, form fields in web forms, etc, you have the most
> powerful editor at your command. In this respect, emacs users
> have had the true IDE all along, and don't need to remember
> 27 ways of doing the same thing in 27 different applications.
I think I knew that. What I was getting at, though (and obviously
didn't make clear) is that "plug $foo into your text editor" is
essentially an inside-out view of the world, and as a general concept
I would far rather be able to plug my text editor into $foo.
Of course, this is emacs we're talking about, so the argument for
doing it in this inside-out fashion is usually more compelling. It
isn't the text editor as such you want to embed in, it's the rich
dynamic environment (GC, runtime typing, interactive evaluation) which
is (a) better than anything Unix typically offers, (b) rather too
"heavyweight" to blithely embed into another application without
feeling some twinge of guilt. And of course, (c) allows you to edit
text with _all_ your favourite gestures (a curse on whichever Mozilla
developer thought it would be funny to support C-k but not C-y ...)
In this specific case, though, we're talking about a Lisp app as the
other partner in this symbiosis. Closure runs in a _really_ rich (and
heavyweight) dynamic environment with generational GC, threading, CLX,
CLIM, etc (I believe that the McCLIM text editing component is
destined to end up looking pretty emacsy). So all I'm saying, really,
is "let's pause for a minute to consider which component is on top in
this relationship"
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
From: Alain Picard
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <86u1k1wgm1.fsf@gondolin.local.net>
Daniel Barlow <···@telent.net> writes:
> I think I knew that. What I was getting at, though (and obviously
> didn't make clear) is that "plug $foo into your text editor" is
> essentially an inside-out view of the world, and as a general concept
> I would far rather be able to plug my text editor into $foo.
I guess there's always export EDITOR=emacsclient for that.
> In this specific case, though, we're talking about a Lisp app as the
> other partner in this symbiosis. [snip] So all I'm saying, really,
> is "let's pause for a minute to consider which component is on top in
> this relationship"
Yes, but the earlier context of this was that we might be talking about
an emacs whose lisp was CL (hence the desire to embed closure instead
of the (slow) w3 code). If I misunderstood, my apologies.
From: Dave Bakhash
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <c29ptumt628.fsf@nerd-xing.mit.edu>
Alain Picard <·······················@optushome.com.au> writes:
> Yes, but the earlier context of this was that we might be talking
> about an emacs whose lisp was CL (hence the desire to embed closure
> instead of the (slow) w3 code). If I misunderstood, my apologies.
no. you got it right. The bottom line, and the key point, is that the
wads of elisp code don't suddenly break. You want to support all that
legacy stuff. So, for example, you could go to Xanalys, add some
features to their editor to support Emacs Lisp, and Emacs features, and
that would be a solution. Or you can go to (X)Emacs, rip out the Emacs
Lisp engine and replace it with an embeddable CL. It's really the same
difference.
I think the cleanest way is to start from scratch, which in the CL world
means starting from the CL environment. One would have to implement the
basics of what (X)Emacs has (windows, buffers, etc.)
Am I wrong, or is it not a good idea to start from the CL side, throwing
away a lot of the C code that's now part of (X)Emacs?
dave
From: Dorai Sitaram
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <ansuao$lm3$1@news.gte.com>
In article <···············@nerd-xing.mit.edu>,
Dave Bakhash <·····@alum.mit.edu> wrote:
>Alain Picard <·······················@optushome.com.au> writes:
>
>> Yes, but the earlier context of this was that we might be talking
>> about an emacs whose lisp was CL (hence the desire to embed closure
>> instead of the (slow) w3 code). If I misunderstood, my apologies.
>
>no. you got it right. The bottom line, and the key point, is that the
>wads of elisp code don't suddenly break. You want to support all that
>legacy stuff. So, for example, you could go to Xanalys, add some
>features to their editor to support Emacs Lisp, and Emacs features, and
>that would be a solution. Or you can go to (X)Emacs, rip out the Emacs
>Lisp engine and replace it with an embeddable CL. It's really the same
>difference.
>
>I think the cleanest way is to start from scratch, which in the CL world
>means starting from the CL environment. One would have to implement the
>basics of what (X)Emacs has (windows, buffers, etc.)
>
>Am I wrong, or is it not a good idea to start from the CL side, throwing
>away a lot of the C code that's now part of (X)Emacs?
Didn't Tim Bradshaw among others only recently state,
earlier on in this very thread, that there were
enormous economic barriers against this (in reply to my
observation that there was no technical barrier)?
I thought you were agreeing with Tim then.
····@goldshoe.gte.com (Dorai Sitaram) wrote in message news:<············@news.gte.com>...
> In article <···············@nerd-xing.mit.edu>,
> Dave Bakhash <·····@alum.mit.edu> wrote:
> >Am I wrong, or is it not a good idea to start from the CL side, throwing
> >away a lot of the C code that's now part of (X)Emacs?
>
> Didn't Tim Bradshaw among others only recently state,
> earlier on in this very thread, that there were
> enormous economic barriers against this (in reply to my
> observation that there was no technical barrier)?
> I thought you were agreeing with Tim then.
I said it, and I stand by it. There are so many things that are more
useful to do than reimplement Emacs. There's not even the Linux
justification that it isn't free already.
--tim
From: Joe Marshall
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <fzvfviqf.fsf@ccs.neu.edu>
··········@tfeb.org (Tim Bradshaw) writes:
> There are so many things that are more useful to do than reimplement
> Emacs.
Alas there are also many things that are *less* useful to do than
reimplement Emacs, but people are doing them.
From: Dave Bakhash
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <c29it09oc5w.fsf@no-knife.mit.edu>
··········@tfeb.org (Tim Bradshaw) writes:
> > Didn't Tim Bradshaw among others only recently state, earlier on in
> > this very thread, that there were enormous economic barriers against
> > this (in reply to my observation that there was no technical
> > barrier)? I thought you were agreeing with Tim then.
>
> I said it, and I stand by it. There are so many things that are more
> useful to do than reimplement Emacs. There's not even the Linux
> justification that it isn't free already.
first off, the argument of how something would, should, and could be
done has little to do with whether or not to do it at all. However, on
this note, I do think that it's probably worthwhile to redo the Emacs
thing, and do it right...i.e. with CL. Just my $0.02
Since I live inside Emacs, an Emacs that I could program with CL would
eventually subsume almost all of the applications I use. Not to mention
that using CL instead of the broken Emacs Lisp that doesn't really allow
for multiprocessing is painful. It's slow, and it's a memory beast. I
think seeing a CL-based Emacs as a useless project is short-sighted. To
me, even a moderately deep knowledge of Emacs and its shortcomings would
unveil the potential benefits of a rewrite in CL...on so many levels.
dave
Dave Bakhash <·····@alum.mit.edu> wrote in message news:<···············@no-knife.mit.edu>...
>
> first off, the argument of how something would, should, and could be
> done has little to do with whether or not to do it at all. However, on
> this note, I do think that it's probably worthwhile to redo the Emacs
> thing, and do it right...i.e. with CL. Just my $0.02
>
I'm not sure I understand this. If you're trying to argue that there
is some domain of theoretical possibility which is different from the
enginerring domain where cost matters: well, yes there is, of course.
But I live in a world where money and time matters, and so I'm pretty
interested in spending my time sensibly: as I argued before, the US
can technically send people to pluto, but you might not want to pay
70% tax for 10 years to do so, especially when there are other things
competing for your time & money.
> Since I live inside Emacs, an Emacs that I could program with CL would
> eventually subsume almost all of the applications I use. Not to mention
> that using CL instead of the broken Emacs Lisp that doesn't really allow
> for multiprocessing is painful. It's slow, and it's a memory beast. I
> think seeing a CL-based Emacs as a useless project is short-sighted. To
> me, even a moderately deep knowledge of Emacs and its shortcomings would
> unveil the potential benefits of a rewrite in CL...on so many levels.
>
Well, I guess we have to differ on that - I have a moderately deep
knowledge of Emacs, and I just disagree. (The memory beast thing is
just unambiguously false unless you live on really old HW - XEmacsen
that have been running VM for many weeks with many tens of large mail
files open seem to grow to about 30-40Mb. I guess this is a lot of
memory if you live in 1990). If there was nothing else left to do int
he world, then sure, rewrite emacs. But there are other things
competing for time & money in fact, and some of them might just be
more useful. (I hope the stupid myth that there is infinite time &
money has died with the stupid dot-com myth that spawned it...)
This is really my last word on this.
--tim
From: Paolo Amoroso
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <qyunPVnlfNXA1QO=orEyqUok5Tq2@4ax.com>
On 11 Oct 2002 03:50:50 -0700, ··········@tfeb.org (Tim Bradshaw) wrote:
> interested in spending my time sensibly: as I argued before, the US
> can technically send people to pluto, but you might not want to pay
In the meantime, they are sending Pluto--and Mickey Mouse--to them :)
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
From: Thien-Thi Nguyen
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <kk9ptugx3v9.fsf@glug.org>
Dave Bakhash <·····@alum.mit.edu> writes:
> To me, even a moderately deep knowledge of Emacs and its shortcomings would
> unveil the potential benefits of a rewrite in CL...on so many levels.
it is good to have understanding. next, find some time to take action.
thi
From: Paolo Amoroso
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <DfWdPS0UmkKbRu5AygMwxw4bhzMc@4ax.com>
On 03 Oct 2002 18:44:17 -0400, Dave Bakhash <·····@alum.mit.edu> wrote:
> Now, as I recall, there is a Web browser that was out a couple of years
> ago, written in CL (I think under ACL). If Emacs could handle CL, then
> it could actually just plug in. That would have been nice.
>
> Does anyone recall this CL browser? Anyone ever use it?
Do you mean Closure by Gilbert Baumann? It is still maintained, and it is
based on CLIM and runs fine also with McCLIM.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
From: Hannah Schroeter
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <ao0q85$c27$2@c3po.schlund.de>
Hello!
Tim Bradshaw <···@cley.com> wrote:
>[...]
>I think the only web browser I know of in elisp (namely emacs w3) is
>slow for reasons that a profiler would help with a whole lot more than
>a new language. Other than w3, whenever I've profiled emacs I've
>discovered that it spends about 90% of its time in redisplay, in C
>code.
gnus entering a newsgroup with many articles? Things where you wait
an eternity for gnus, while trn just flies? *g*
Kind regards,
Hannah.
From: Stig Hemmer
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <ekv7kgpzylu.fsf@lizard.pvv.ntnu.no>
Dave Bakhash <·····@alum.mit.edu> writes:
> Scheme is a degenerate -- a mutation, if you will.
[...]
> It's just as in biology: most mutations are bad, though some are good.
The goodness or badness of a mutation can depend heavily on the
organisms environment.
Scheme is good for what the Scheme community wants to do and
Common Lisp is good for what the CL community wants to do.
Trying to merge these two communities and create a compromise Lisp
that everybody can use is bound to be a failure.
Rather than posting negative views of the other groups icon, you
should just accept that they are happy with what they have. Leave
them be.
Stig Hemmer,
Jack of a Few Trades.
From: Bruce Stephens
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <87adm468vx.fsf@cenderis.demon.co.uk>
Dave Bakhash <·····@alum.mit.edu> writes:
> "Adam Warner" <······@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).
[...]
From: Tim Bradshaw
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <ey3smzw3ak9.fsf@cley.com>
* 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.
From: Dorai Sitaram
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <amvuaf$3ai$1@news.gte.com>
In article <···············@cley.com>, Tim Bradshaw <···@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.
From: Tim Bradshaw
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <ey3y99o1f5q.fsf@cley.com>
* 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)
From: Petr Swedock
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <861y7grs78.fsf@blade-runner.mit.edu>
Tim Bradshaw <···@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
From: Friedrich Dominicus
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <87ofajrhup.fsf@fbigm.here>
Petr Swedock <····@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
From: Dave Bakhash
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <c29wup3ltr5.fsf@no-knife.mit.edu>
Friedrich Dominicus <·····@q-software-solutions.com> writes:
> 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.
I think this is what the poster meant when he said:
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 this fully. But then again, I don't think that RMS really
knew what a phenomenon Emacs would become to care enough to do things
the right way. I get a strong feeling that RMS has some hacker
tendencies. That, coupled with 20/20 hindsight of what Emacs Lisp
should have been, can sometimes hurt his image a bit. It's the part
about RMS supporting Guile as the evolution of Emacs Lisp that gets me.
dave
From: Thien-Thi Nguyen
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <kk91y7bfrjc.fsf@glug.org>
Dave Bakhash <·····@alum.mit.edu> writes:
> I get a strong feeling that RMS has some hacker tendencies.
what would those be?
thi
From: Kurt B. Kaiser
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <m3vg4sutue.fsf@float.attbi.com>
Tim Bradshaw <···@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
From: Erik Naggum
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <3242144735836601@naggum.no>
* 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.
--
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.
From: Dave Bakhash
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <c291y7cv76x.fsf@nerd-xing.mit.edu>
····@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
From: Dorai Sitaram
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <an9n5h$94s$1@news.gte.com>
In article <···············@nerd-xing.mit.edu>,
Dave Bakhash <·····@alum.mit.edu> wrote:
>····@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.
I wasn't aware I was trying to win anything. For some
reason you seem to think I'm championing
Guile-Emacs over CL-Emacs, despite my explicit
statement to you that the latter would be very nice
indeed.
As an individual, I am just trying to deal with
reality too, and am observing that since you made an
explicit laundry-list of goodies (which you should be
thanked for), that you will find that you can deal with
Guile-Emacs if it happens.
Software is not always about what we want exactly how
we want it -- there is a large social component
to it. I am trying to find good points that I can deal
with. Yes, I think Guile-Emacs will be "good enough",
to use another poster's phrase. It will be dealable
with.
Do I personally absolutely want Guile-Emacs? No. Will
I use it if it came about? I'll probably have to, if I
want to keep in touch with the rest of the (not just
Lisp-) world. Is it really worth my while to
spend extraordinary amounts of negative energy putting
it down? I'd say not.
You say you've looked at my inter-language code.
That should tell you something at least about my
pragmatism in these matters.
--d
From: Lars Brinkhoff
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <85u1kcyltd.fsf@junk.nocrew.org>
Tim Bradshaw <···@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
From: Alain Picard
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <86smzvn3nr.fsf@gondolin.local.net>
Tim Bradshaw <···@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? :-)
A long time ago, in a galaxy far, far away, Dave Bakhash <·····@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?
> I was dumbfounded that Richard Stallman himself was advocating using a
> Scheme interpreter instead of Lisp.
All the guile/emacs projects make it clear that there'll be backwards
compatability, because they're not suicidal.
No doubt CL is a better technical choice, but scheme has a lower
learning-curve initially. Maybe RMS wants to compete against the Dr.
Scheme folks...
Greg Neumann
From: Raymond Toy
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <4nptudt09v.fsf@rtp.ericsson.se>
>>>>> "Greg" == Greg Neumann <············@yahoo.com> writes:
Greg> No doubt CL is a better technical choice, but scheme has a lower
Greg> learning-curve initially. Maybe RMS wants to compete against the Dr.
Greg> Scheme folks...
Having started with elisp and later CL, learning scheme was actually
rather difficult because it looks like lisp but it isn't. Things like
Lisp-1 vs Lisp-2, lots of functions that I'd become accustomed to
having available aren't, etc., etc., etc.
If I didn't know either, and came from a C/C++ world, I think Lisp
would be easier since C/C++ are "Lisp-2" languages since functions and
variables are different. In some very rough sense.
I find it extremely odd to use scheme for elisp when elisp is closer
to Lisp than scheme....
Ray
From: Erik Naggum
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <3243597445478547@naggum.no>
* Greg Neumann
| No doubt CL is a better technical choice, but scheme has a lower
| learning-curve initially.
This is not the fact you want it to appear to be.
--
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 <····@naggum.no> wrote in message news:<················@naggum.no>...
> This is not the fact you want it to appear to be.
I have no want in the matter. For anyone intereted in my bias, here's
a link to my current understanding to the issues:
http://groups.google.com/groups?dq=&hl=en&lr=&ie=UTF-8&oe=UTF-8&safe=off&selm=44d4f61c.0210140549.1861cdeb%40posting.google.com
When I talk to a software vendor about my thoughts as a user, I expect
her to second guess me if she really is an expert. But I also expect
her to listen and not think I'm attacking.
If you think my words are wrong or dangerous, and you think this
perception is widespread enough to affect things you like badly, maybe
it's time to think about correcting that perception in an effective
way. I so far have no reason to think that Scheme has a worse initial
learning curve than Lisp, because Scheme was designed for this. Maybe
it's a Visual Basic, but VB has been useful for many.
I don't know what to say. I have a copy of Graham's ANSI CL, have
read many of the Pitman posts (which is 3/4 of what I read here), and
I still prefer Scheme. You all have mused about this subject longer
than I.
Anyway, if you want to correct this perception and find out what
madness lies in the mind of a Schemer, feel free to ask. But there
are profs more knowledgeable than I...
Greg Neumann
From: Erik Naggum
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <3243679770900362@naggum.no>
* Greg Neumann
| Anyway, if you want to correct this perception
I would greatly prefer if such "perceptions" did not have to be corrected
all the time from relative beginners in Scheme who have only picked up
its serious attitude problem when they do /actually/ not start to learn
Common Lisp. (Amazing response to my one-line, btw.)
--
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.
Hi Greg Neumann,
> I don't know what to say. I have a copy of Graham's ANSI CL, have read
> many of the Pitman posts (which is 3/4 of what I read here), and I still
> prefer Scheme. You all have mused about this subject longer than I.
That you still prefer Scheme is not the issue Greg. The issue is your
(innocent and offhand) comment that "scheme has a lower learning-curve
initially." I would like to understand how this could be the case.
All I see is a lower plateau that requires a new programmer to quickly
move to implementation-specific constructs (in ways that are slow and bug
prone). How can it be easier for a new programmer to have to go off and
build what is already available in CL?
How is it easier that a new programmer must learn CAR, CADR, CADDR and CDR
instead of FIRST, SECOND, THIRD and REST?
How is it easier for a new programmer to be continually told that what
they are trying to achieve is not in the specification, and implementation
X does it one way while implementation Y does it another?
To put the question less abstractly, where does the extra functionality of
CL get in the way of a new programmer learning CL compared to learning
Scheme?
Regards,
Adam
Hi Adam. I've looked through my code to see what makes me feel
uncomfortable with Lisp. It was mostly having to remember again that
you need to funcall/quote this and defun that... And my defuns didn't
stay local to their environment, unlike in Python and Scheme. (A
purely elisp issue?) Little things. Maybe superficial, but when you
introduce to a beginner, these little things are so huge.
How many people will write huge scripts in emacs? Less than the
number who write tiny ones. Everyone has some tiny need they want to
fulfill that the bigger packages don't.
"Adam Warner" <······@consulting.net.nz> wrote in message news:<·····························@consulting.net.nz>...
> All I see is a lower plateau that requires a new programmer to quickly
> move to implementation-specific constructs (in ways that are slow and bug
> prone). How can it be easier for a new programmer to have to go off and
> build what is already available in CL?
Yup, Scheme isn't a "comes with batteries" language. But keep in mind
that a lot of what many programmers want to do is access platform
APIs, like Java or Cocoa. Not so much on the serverside, but on the
client. So with lisp you're already at the mercy of impl-dependent
constructs.
I like that Scheme can be ported quickly to Java. (Admittedly this is
a bit confusing to me though, since I'd think a lot of lisp is in
lisp...) And the scheme community is a bit more promiscuous, so
there's always someone porting Scheme to the craziest thing.
But again, if porting elisp to CL is a great improvement, I'm all for
it. There should be a Bothner or Norvig to do it.
Greg Neumann
From: Paul Dietz
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <3DAC3A55.4AA4DB11@motorola.com>
Greg Neumann wrote:
>
> Hi Adam. I've looked through my code to see what makes me feel
> uncomfortable with Lisp. It was mostly having to remember again that
> you need to funcall/quote this and defun that... And my defuns didn't
> stay local to their environment, unlike in Python and Scheme. (A
> purely elisp issue?) Little things. Maybe superficial, but when you
> introduce to a beginner, these little things are so huge.
Superficial, yes, in the sense that if you had not learned Scheme
first these would have been non-issues. Why exactly did you want
to use DEFUN for local functions anyway? Do you use DEFVAR for
local variables?
Paul
Paul Dietz <············@motorola.com> wrote in message news:<·················@motorola.com>...
> if you had not learned Scheme
> first these would have been non-issues. Why exactly did you want
> to use DEFUN for local functions anyway? Do you use DEFVAR for
> local variables?
There is no labels keyword in elisp. There are convoluted
workarounds, but after a reasonable search through the elisp ref I
don't see a clean way. (correct me if I missed something.)
I tried to pawn it off as an elisp problem, but would you listen?
Noooo... :)
Greg Neumann
From: Brian Palmer
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <0whu1jm4f0o.fsf@rescomp.Stanford.EDU>
············@yahoo.com (Greg Neumann) writes:
> Paul Dietz <············@motorola.com> wrote in message news:<·················@motorola.com>...
> > if you had not learned Scheme
> > first these would have been non-issues. Why exactly did you want
> > to use DEFUN for local functions anyway? Do you use DEFVAR for
> > local variables?
>
> There is no labels keyword in elisp. There are convoluted
> workarounds, but after a reasonable search through the elisp ref I
> don't see a clean way. (correct me if I missed something.)
Hmm. Xemacs 21.4.8, in library cl-macs, has a labels macro that claims
to be "fully compliant with the Common Lisp standard."
--
If you want divine justice, die.
-- Nick Seldon
From: Piers Cawley
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <84wuoiivle.fsf@despairon.bofh.org.uk>
············@yahoo.com (Greg Neumann) writes:
> Paul Dietz <············@motorola.com> wrote in message news:<·················@motorola.com>...
>> if you had not learned Scheme
>> first these would have been non-issues. Why exactly did you want
>> to use DEFUN for local functions anyway? Do you use DEFVAR for
>> local variables?
>
> There is no labels keyword in elisp. There are convoluted
> workarounds, but after a reasonable search through the elisp ref I
> don't see a clean way. (correct me if I missed something.)
Correct me if I'm going mad, but don't you want letrec?
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Piers Cawley <········@bofh.org.uk> wrote in message news:<··············@despairon.bofh.org.uk>...
> Correct me if I'm going mad, but don't you want letrec?
Hmm, could be. In fact, I was clearly wrong earlier -- for some
reason I didn't think of the cl package. That needs to go into my
startup.
Greg Neumann
From: Piers Cawley
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <848z0yifbs.fsf@despairon.bofh.org.uk>
Piers Cawley <········@bofh.org.uk> writes:
> ············@yahoo.com (Greg Neumann) writes:
>
>> Paul Dietz <············@motorola.com> wrote in message news:<·················@motorola.com>...
>>> if you had not learned Scheme
>>> first these would have been non-issues. Why exactly did you want
>>> to use DEFUN for local functions anyway? Do you use DEFVAR for
>>> local variables?
>>
>> There is no labels keyword in elisp. There are convoluted
>> workarounds, but after a reasonable search through the elisp ref I
>> don't see a clean way. (correct me if I missed something.)
>
> Correct me if I'm going mad, but don't you want letrec?
Ah... I *am* going mad. You said 'elisp', I read 'scheme'. I'll just
wander out into the snow now.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
The world rejoiced as Piers Cawley <········@bofh.org.uk> wrote:
> Piers Cawley <········@bofh.org.uk> writes:
>
>> ············@yahoo.com (Greg Neumann) writes:
>>
>>> Paul Dietz <············@motorola.com> wrote in message news:<·················@motorola.com>...
>>>> if you had not learned Scheme
>>>> first these would have been non-issues. Why exactly did you want
>>>> to use DEFUN for local functions anyway? Do you use DEFVAR for
>>>> local variables?
>>>
>>> There is no labels keyword in elisp. There are convoluted
>>> workarounds, but after a reasonable search through the elisp ref I
>>> don't see a clean way. (correct me if I missed something.)
>>
>> Correct me if I'm going mad, but don't you want letrec?
>
> Ah... I *am* going mad. You said 'elisp', I read 'scheme'. I'll just
> wander out into the snow now.
It's not February 29th, so, um, well, I guess that one's a far too
Canadian reference for most people to get...
(Late former Prime Minister Pierre Trudeau "took his walk in the
snow," retiring from politics, on February 29th. At the time, his
popularity was at an ebb, and it was speculated that the date was
chosen so it couldn't be turned into a national holiday :-).)
--
(concatenate 'string "cbbrowne" ·@ntlug.org")
http://www3.sympatico.ca/cbbrowne/canada.html
When you awake, you will remember nothing of what I have told you.
From: Tim Bradshaw
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <ey3wuoi9rtk.fsf@cley.com>
* Christopher Browne wrote:
>>
>> Ah... I *am* going mad. You said 'elisp', I read 'scheme'. I'll just
>> wander out into the snow now.
> It's not February 29th, so, um, well, I guess that one's a far too
> Canadian reference for most people to get...
I don't think it's a Canadian reference! It's obviously a reference
to Captain Oats' famous `I'm just going outside, I may be some time',
isn't it?
In fact I wonder if Trudeau was half-quoting Oats?
--tim
From: Piers Cawley
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <84wuoiglwz.fsf@despairon.bofh.org.uk>
Tim Bradshaw <···@cley.com> writes:
> * Christopher Browne wrote:
>>>
>>> Ah... I *am* going mad. You said 'elisp', I read 'scheme'. I'll just
>>> wander out into the snow now.
>
>> It's not February 29th, so, um, well, I guess that one's a far too
>> Canadian reference for most people to get...
>
> I don't think it's a Canadian reference! It's obviously a reference
> to Captain Oats' famous `I'm just going outside, I may be some time',
> isn't it?
Actually, the walk in the snow is a reference to a (possibly mythical)
eskimo practice when, once old folks felt they'd become too great a
burden on their family they went out for a walk in the snow.
> In fact I wonder if Trudeau was half-quoting Oats?
More likely the eskimo thing.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
From: Friedrich Dominicus
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <87of9uw9ha.fsf@fbigm.here>
············@yahoo.com (Greg Neumann) writes:
> Paul Dietz <············@motorola.com> wrote in message news:<·················@motorola.com>...
> > if you had not learned Scheme
> > first these would have been non-issues. Why exactly did you want
> > to use DEFUN for local functions anyway? Do you use DEFVAR for
> > local variables?
>
> There is no labels keyword in elisp. There are convoluted
> workarounds, but after a reasonable search through the elisp ref I
> don't see a clean way. (correct me if I missed something.)
You are missing labels. It's there you just have to use it
(defun foo-1 ()
(labels ((foo-2 (i)
(when (< i 10)
(princ i)
(foo-2 (incf i)))))
(foo-2 5)))
Works quite fine here
>
> I tried to pawn it off as an elisp problem, but would you listen?
I assume yes.
> Noooo... :)
Why not. Just you better had visited comp.emacs or
comp.emacs.xemacs
Regards
Friedrich
From: Erik Naggum
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <3243697436237941@naggum.no>
* Greg Neumann
| I've looked through my code to see what makes me feel uncomfortable with
| Lisp.
Do you have a zero position in your comfortable/uncomfortable system of
evaluating things? I am curious because you are so ignorant, so arrogant
in your belief that what you already know should carry you through what
you do not know, and so willing to switch to negative terms when all you
have the absence of some emotional quality like "comfort". I have seen a
lot of people recently, or, rather, I have begun noticing them, who lack
the ability to "return to neutral" once they have made up their mind to
feel something. They are either for or against something, with no means
to stop and think and conclude that they really should not be either. I
have never quite understood such people. It is as if the only purpose of
acquiring any knowledge at all is to be for or against something, and if
they have a non-zero amount of knowledge, they get the right to be for or
against something in the package deal. How curiously anti-intellectual.
| Maybe superficial, but when you introduce to a beginner, these little
| things are so huge.
But you are not a beginner. You have some experience from a very, very
bad environment. You are wounded, a victim of the assault on mind and
spirit from bad programming languages. Scheme can be really, really bad
for a great number of people, namely those who do not stop to think and
evaluate what they hear. Brainwashing and menticide are words that come
to mind when I watch the poor Scheme victims. It is not that Scheme is
bad per se. Neither is falling from the sky, but if you are a fledgling
who gets thrown out of your loving parent's nest 50 feet above the ground
in the misguided notion that you will learn to fly before you hit the
ground, there will be victims and there will be people who learn the
wrong thing from the experience and their survival tactics really cripple
them for the rest of their (programming) life.
| And the scheme community is a bit more promiscuous, so there's always
| someone porting Scheme to the craziest thing.
Please realize that the /one/ thing that the Scheme community is known
for is implementing Scheme. There is close to one Scheme implementation
per Scheme programmer. The charm of the language is indeed that it is
perceived to be so easy to implement. While there are few implementations
of Common Lisp, they are actually /used/ to do useful work and produce
significant values for their users. Note that none of the idiot exercises
from your university course on programming languages about hacking up
lists is ever going to help you. Handling complexity of thought is not
taught -- it is an acquired skill after having been exposed to complex
problems over a long time. Mankind has yet to find a better way to teach
people to think than to drag a large number of people to the top of some
vast tower of abstraction only to push them off and see how many go
*splat* on the exam. If you did not walk away from this exercise with
fully-fledged wings, it is really is nothing to boast about, but many an
average student appears to think that having been thrown off enough such
towers is a mark of endurance and give them bragging rights. It does not.
The whole point with education is to force people who are smart enough to
be much better than their peers to be forced to deal with people they are
/not/ smarter than so long that they finally grasp that even though they
were geniuses at some particular subject in high school and could whiz
through without doing their homework and paying attention, life is work,
and it takes much longer to make smart people realize they have to work
hard than less smart people. By putting people in institutions of higher
learning for a decade longer than those who went off to be plumbers and
carpenters, they should hopefully have learned the value of hard work,
but if you let them out before they have realized that nothing worth
having really comes for free, such as happens with people who are smart
enough to believe they have learned Scheme well in no time, they will be
arrogant ignorants who display a great disdain for other people, who they
still believe are as dumb as the peers they were smarter than in school.
Life is not about finding things you are good at so you can only excel at
things that are easy to you. Life is about finding the things you can be
good at when the easy things are all done and out of the way.
--
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 <····@naggum.no> wrote in message news:<················@naggum.no>...
> Do you have a zero position in your comfortable/uncomfortable system of
> evaluating things? I am curious because you are so ignorant, so arrogant
> in your belief that what you already know should carry you through what
> you do not know, and so willing to switch to negative terms when all you
Actually, I am curious. Are you so unable to read, and so arrogant to
believe that I assigned a huge value to my comfort? I was telling you
& Adam that I was happy to open my mind so you can see what Broken
people like me thought.
If you don't want to know this, then I will stop. I thought it would
have been useful to you. But the realization that I am trying to show
you what a proponent of oversimplified software is thinking, has just
set off your moron alarms so hard that you search now to repair me.
> I have begun noticing them, who lack the ability to "return to neutral"
> once they have made up their mind to feel something. They are either
> for or against something, with no means to stop and think and conclude
> that they really should not be either. I have never quite understood
> such people.
Yes, deeeeep into my mind you go, seeing the inner hurt of me
searching for only a comfort, something that does not make me (my
GOD!) change my PERSPECTIVE *sob*. I must not be of two minds, or the
universes will collide!!
Now you listen. I am giving you the opportunity to study a creature
like me, in private mail or here. Do with it what you wish. I am
capable of writing until I believe you understand.
> Life is not about finding things you are good at so you can only excel at
> things that are easy to you. Life is about finding the things you can be
> good at when the easy things are all done and out of the way.
There are people I've met who think they understood my life, and
rather arrogantly tried to Teach Me What It's Like. I will try
telling you now that you underestimate me and my experiences. I think
you too will continue to have your mental model of me, but I never
know.
But we can bring this into personal email if you happen to be curious.
I want to try to stay ontopic here, and my point with this entire
letter is that we both see that I have a wrong model of lisp. Your
degree of seeing "wrong" is more than mine. But I'm just beginning to
have the experiences that lead me to this point of view (I just can't
take your word for it, can I?).
I mean thanks, but you're not telling me anything I don't know, and
I'm more self-observant than I let on. Your pursuit of my personal
mind makes me think it's somehow a useful subject, and I'll need
someone on this forum reality-checking me if it's not. I'll take
silence as a tacit answer and be done here.
Greg Neumann
From: Erik Naggum
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <3243730461574299@naggum.no>
* Greg Neumann
| Actually, I am curious.
You communicate curiosity extremely poorly.
| Are you so unable to read, and so arrogant to believe that I assigned a
| huge value to my comfort?
Those are the choices I get? And you are /curious/? You continue to make
a very strong impression as a judgmental type who has a serious disability
when it comes to listening to other people and deferring judgment until
you know enough to avoid making easily preventable mistakes which you
will compound by going on to defend after you made them.
| But the realization that I am trying to show you what a proponent of
| oversimplified software is thinking, has just set off your moron alarms
| so hard that you search now to repair me.
You assume way too much about other people. Do not guess, do not assume,
think, ask, listen. You only set off my "moron alarm" with this response.
| Yes, deeeeep into my mind you go, seeing the inner hurt of me searching
| for only a comfort, something that does not make me (my GOD!) change my
| PERSPECTIVE *sob*. I must not be of two minds, or the universes will
| collide!!
Seek professional help. Today.
| Now you listen.
You seem to be of the arrogant opinion that this command would entice a
change of state. I am not as close-minded and judgmental as you are. I
always listen. Even if you in particular do not deserve it. I always
listen for the sound of a thinking mind. You do not emit that sound.
| There are people I've met who think they understood my life, and rather
| arrogantly tried to Teach Me What It's Like. I will try telling you now
| that you underestimate me and my experiences. I think you too will
| continue to have your mental model of me, but I never know.
I do not have a mental model of you. This is why I asked if you had a
"zero state" in your value system, but you have confirmed my initial
suspicion that you do not even have the concept of a "zero state" and you
demonstrate that you expect people to be for or against you, which means
that you do not have "absence of comfort" as different from "presence of
discomfort" leading to your being "uncomfortable" with Common Lisp when
you simply do not know how it works. You see, before people invented the
zero, they did stupid things like have year 1 AD follow year 1 BC. The
invention of zero was a stroke of genius that seems not to register with
many people. Therefore, absence of good is not just absence of good, it
is presence of bad -- like the other guy here who has not invented the
zero, yet: neutral language means absence of warmth means cold language.
It is just fascinating that people can go through a couple decades of
life on this planet and not grasp "zero", but I see it happen, so it must
be a really difficult concept to fully understand.
Please note that I do not care enough about /you/ to even consider it
worth my time to determine if you really are a moron. I do not think you
are because I do not think about you at all. I respond to your articles
as you choose to post them and what you /write/. I do not have the
stupid tendency many people have of filling in the blanks in order to
deal with a "person". Having mental models of people is retarded, as it
reduces your ability and capacity to be surprised by what people do. If
you have to check first with your mental model, you become a judgmental
asshole even if you do not try. If you respond to what they /write/, you
have no need for the mental model unless the writing is unclear, but even
then, the presumption of knowing what somebody will say based on what
they have said is anathema to /thinking/. Even if your prediction should
be 100% accurate, the guy could have talked to a friend and changed his
mind on something the minute before he wrote the article -- he could even
have read the article he responds to (what a concept!) and got the point,
which invalidates your accurate prediction /because he could think/. If
you are non-thinking idiot and prefer to deal with other people as non-
thinking idiots, predicting their behavior on past occurrences is easy
and very useful. If you intend to be a thinking person and want to deal
with other people as thinking persons, /you do not presume to know what
they will have thought about since last time you talked with them/.
You have chosen to show me a small handful of written articles, and there
cannot possibly be grounds for a mental model based on those articles.
If you choose to present yourself as a nutjob like you chose to do a
couple paragraphs up, I do not even want to know why you did it (but just
think that if this is how you react, you /clearly/ need professional help),
and I am likely to forget that you did if you make another, better choice
how to present yourself the next time around. You have a choice all the
time, every time you respond to someone. The ultimate insult to a human
being is to presume that he cannot or will not engage his brain enough to
consider new evidence, or to presume that he has not thought carefully
about what he presents to you. Many people here are this kind of moron,
and some of the most unthinking idiots I have ever come across are the
ones who write me to ask "I don't know what to make of you", as if I
could possibly care what they make of me, other than that a person has to
be really dysfunctional to begin with to want to make something out of
other people. What could he possibly /do/ with that information? The
only answer I can come up with is that if you have made up your mind
about somebody else, you can stop thinking about what they write. Why
waste the time to make up your mind about someone if all you can do is
stop really /interacting/ with them in the future? So the whole thing
does appear incredibly irrational by all my standards.
The focus of your articles to this newsgroup should be to ask questions
and collect responses that are useful to yourself. You should have stuck
to the soup questions. If you cannot deal with technical corrections and
arguments, the touchy-feely guys will be available to help you shortly.
Please stay on the line.
| But we can bring this into personal email if you happen to be curious.
I am not curious about you. I wanted to make you think. It did not work.
| I want to try to stay ontopic here, and my point with this entire letter
| is that we both see that I have a wrong model of lisp.
You presume to speak for me. Please do not do that even when you think
are right about it, because that is the core problem. You are /never/
right about what other people think /because they can change their mind/
without having any obligation to let you know they did. It is useless to
believe you know what other people think. You should confine yourself to
precisely and solely what they actually said, and in response to what.
This is a written forum, with excellent history functions so you can look
up exactly what people wrote in response to exactly what other people
wrote. Your fuzzy memory and impressions of people does not help you
here, even if it helps in real life, because the little you see of people
on the Net is not sufficient even to presume that you know /anything/
they will do in the future.
Severely judgmental people have real problems with this and think that
they could not exist in a universe as unpredictable as I say this is, but
that is because their level of involvement in other people is much too
deep for the actual bandwidth the signals travel on. Even if I have
shouted "shut the fuck up, you moron" to every single person before you
who have done something you think is exactly the same as you have done,
it was an independent decision each and every time, and your judgmental
attitude problem does not give you the right to "prepare" for such a
reaction. This means that you make a grave mistake by behaving in a way
that would cause the response you dread. But judgmental people like
little boxes they can put things and people in. There is some evidence
that the jugdmental personality disorder is /way/ more common than the
open-minded who is willing to ignore everything he has ever experienced
before if the new experiences defy prediction based on his previous ones.
Related to all of intelligence and creativity and surprisability, the
mind that is capable of processing information without force-fitting it
into pre-existing little boxes is also able to understand new things and
new situations without forcing them to look like something else because
it is easier to deal with it as if it were something else.
Your reaction to Common Lisp from a Scheme point of view does not give
you much hope of coming across as intelligent, creative, surprisable, and
open-minded and willing to listen, but now you have a choice in those
matters. Instead of going non-linear like you did a few paragraphs up.
| Your degree of seeing "wrong" is more than mine. But I'm just beginning
| to have the experiences that lead me to this point of view (I just can't
| take your word for it, can I?).
Please see another article I posted today about believing my word. The
idea is to encourage you to think. You only feel, and defend yourself
from the feelings you think I caused. Both are fairly stupid things to
do in a written medium where the intelligent approach is to stick to the
points that are important and valuable to yourself.
| I mean thanks, but you're not telling me anything I don't know, and I'm
| more self-observant than I let on.
I am not interested in you. Despite your own deep interest in yourself,
you are not interesting as a person simply because you write something
fairly nutty to a newsgroup and keep it up with ranting and raving. You
would in all likelihood never become interesting to me as a person. Such
touchy-feely stuff is for people-people like Pascal Costanza who want to
hold your hand instead of trying to understand what you think about.
| Your pursuit of my personal mind
You are really gravely mistaken about what I wrote, dude. Please read it
again and see if you can engage your brain this time instead of defending
your stupid feelings. You are not under attack, because you are not even
interesting enough to be worth attacking. What you /wrote/ is under
attack, because it is fairly stupid and annoying. Grasp the difference!
| I'll take silence as a tacit answer and be done here.
So many assumptions. So little thought. What on earth ticked you off?
You might be interested in an observation I have made about different
types of people and which programming language they prefer. People who
display a strongly judgmental character prefer Scheme over Common Lisp.
People who display a strong sense of open-mindedness and willingness to
listen to other people (which is why you get a response from me at all),
tend to prefer Common Lisp over Scheme. Those who think they know what
is right and want to impress their opinion on other people seldom find a
willing audience in this newsgroup. More often than not, these people
have made up their mind that Scheme is the right thing before they come
to this newsgroup. The huge friction between Scheme and Common Lisp is
not the programming language, but the inability of open-minded people to
work well with judgmental people. You seem, so far, as if you would be a
great member of the Scheme community and would benefit from as little
thought as possible about /how/ and /why/ you chose your values.
--
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 <····@naggum.no> wrote in message news:<················@naggum.no>...
> Please see another article I posted today about believing my word. The
> idea is to encourage you to think. You only feel, and defend yourself
> from the feelings you think I caused. Both are fairly stupid things to
> do in a written medium where the intelligent approach is to stick to the
> points that are important and valuable to yourself.
Well, I do not think then I can appear intelligent in your metric
because at this point I'm back to my old strategy of writing cute
little elisp programs. Because there is not much for me to contribute
to others here, and I only have the odd questions designed to help me
not waste my time in learning this stuff.
Thanks for the responses. It has been interesting, I have no idea
what you're getting at, and maybe the most interesting things are the
least rational.
Greg Neumann
Hi Greg Neumann,
> Hi Adam. I've looked through my code to see what makes me feel
> uncomfortable with Lisp. It was mostly having to remember again that
> you need to funcall/quote this and defun that... And my defuns didn't
> stay local to their environment, unlike in Python and Scheme. (A purely
> elisp issue?) Little things. Maybe superficial, but when you introduce
> to a beginner, these little things are so huge.
>
> How many people will write huge scripts in emacs? Less than the number
> who write tiny ones. Everyone has some tiny need they want to fulfill
> that the bigger packages don't.
Emacs Lisp is not usually discussed in c.l.l. There are specific Emacs
groups for that. I will try to address your points given my current
knowledge of ANSI Common Lisp.
Anonymous functions are defined using lambda and local functions are
defined using flet or labels. macrolet allows local macros to be created.
As you have realised, due to separate namespaces it is necessary to signal
which namespace is being accessed. #' is an abbreviation for function. For
example (mapcar #'(lambda (x) (1+ x)) '(1 2 3)) returns (2 3 4).
Note that (mapcar (lambda (x) (1+ x)) '(1 2 3)) also works, because lambda
returns a function.
But if you tried to do this with a regular function:
(defun test (x) (1+ x))
(mapcar test '(1 2 3))
*** - EVAL: variable test has no value
Then you tried to access the non-function namespace, which is currently
undefined. We have to make sure the function namespace is accessed:
(mapcar #'test '(1 2 3))
Or longhand:
(mapcar (function test) '(1 2 3))
[what is the official term for the non-function namespace? Variable
namespace?]
> "Adam Warner" <······@consulting.net.nz> wrote in message
> news:<·····························@consulting.net.nz>...
>> All I see is a lower plateau that requires a new programmer to quickly
>> move to implementation-specific constructs (in ways that are slow and
>> bug prone). How can it be easier for a new programmer to have to go off
>> and build what is already available in CL?
>
> Yup, Scheme isn't a "comes with batteries" language. But keep in mind
> that a lot of what many programmers want to do is access platform APIs,
> like Java or Cocoa. Not so much on the serverside, but on the client.
> So with lisp you're already at the mercy of impl-dependent constructs.
Still, the core of identical functionality is significantly larger--it's a
question of degree. There are also a number of platform-independent
interfaces to functionality such as sockets:
http://clocc.sourceforge.net/dist/port.html
I want to start using path.lisp to help make my code portable across
implementations.
> I like that Scheme can be ported quickly to Java. (Admittedly this is a
> bit confusing to me though, since I'd think a lot of lisp is in lisp...)
> And the scheme community is a bit more promiscuous, so there's always
> someone porting Scheme to the craziest thing.
http://schemers.org/Documents/FAQ/#implementations
There sure are a significant number of implementations.
I don't see the point of such a small language given continued
improvements in computer resources. But with decent libraries Scheme will
go far. I've just been looking at the enormous SLIB library:
http://swissnet.ai.mit.edu/~jaffer/SLIB.html
This appears to implement a lot of Common Lisp. It even provides t and
nil, which was removed from Scheme in R4RS!
1.5.6.2 Legacy
The following procedures were present in Scheme until R4RS (see section
\Language changes " in Revised(4) Scheme). They are provided by all
SLIB implementations.
t Constant
Defined as #t.
nil Constant
Defined as #f.
I bet there's one heck of a story behind that.
Regards,
Adam
From: Marco Antoniotti
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <y6csmz6xxws.fsf@octagon.valis.nyu.edu>
"Adam Warner" <······@consulting.net.nz> writes:
> Hi Greg Neumann,
>
...
>
> I don't see the point of such a small language given continued
> improvements in computer resources. But with decent libraries Scheme will
> go far. I've just been looking at the enormous SLIB library:
> http://swissnet.ai.mit.edu/~jaffer/SLIB.html
>
> This appears to implement a lot of Common Lisp.
It's the "G" word again :)
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
715 Broadway 10th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
············@yahoo.com (Greg Neumann) wrote in message news:<···························@posting.google.com>...
> > I was dumbfounded that Richard Stallman himself was advocating using a
> > Scheme interpreter instead of Lisp.
>
> All the guile/emacs projects make it clear that there'll be backwards
> compatability, because they're not suicidal.
>
> No doubt CL is a better technical choice, but scheme has a lower
> learning-curve initially.
Binary code has a lower initial learning curve too: there are just two
symbols to learn. And look how adding two numbers reduces to simple
logical operations that can be represented by tiny truth tables; it's
so *pure*! Why doesn't the whole world just ditch its alphabets and
digits 2 through 9?
Could it be that taking out the complexity from something really just
pushes it elsewhere? Taking out the complexity from a programming
language pushes it into the program. Moving complexity from one place
to another, in itself, wouldn't be a problem, if it were not the case
that there is a class-instance relationship between a notation and
utterances in that notation. Countless instances of utterances have to
contain individual instantiations of the extra complexity that was
factored out from the notation.
···@ashi.footprints.net (Kaz Kylheku) wrote in message news:<····························@posting.google.com>...
> > No doubt CL is a better technical choice, but scheme has a lower
> > learning-curve initially.
[snip...]
> Could it be that taking out the complexity from something really just
> pushes it elsewhere?
I think you're basically elaborating on my point. My point was abouu
taking the complexity from one place and putting it elsewhere.
> Moving complexity from one place
> to another, in itself, wouldn't be a problem, if it were not the case
> that there is a class-instance relationship between a notation and
> utterances in that notation.
Well, I'm sure elisp will always be there for you as a backwards
compat layer. Maybe neither Lisp nor Latin will save the world, but
beautiful things have been written in them. And I don't even see the
transition to Scheme as even a greatly desirable thing for Gnu. Is
this the best place to focus efforts? Are enough programmers even
motivated to tackle this relatively unsexy project?
If you sense a disconnect between us, it's that in this case my
thoughts are about what is best for Emacs, not solely the technical
aspects. There are a few issues at hand:
1) integration with Guile means a better UI for users of other
Guile-extended packages -- and Guile is the big gnu-supported
scripting language
2) scheme has very good free educational materials, which strive to
teach more than just scheme
3) lisp users will probably find the transition to scheme no more
jarring than the schemer's transition to lisp
4) it's free software, so emacs can be forked whether or not rms wants
it to
5) this is a gnu project, and presumably they like to use scheme, so
they should work on what they like. Plus rms just might know a thing
or two about emacs, lisp and scheme.
Greg Neumann
From: Erik Naggum
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <3243680935954446@naggum.no>
* Greg Neumann
| 3) lisp users will probably find the transition to scheme no more jarring
| than the schemer's transition to lisp
So much approximation and so many statements without foundation...
Most Scheme users at least have attained a level of precision in the
regular communication.
This is not so, either. From Scheme to Common Lisp is like a refugee
from very rural Pakistan who gets relocated to Oslo, Norway, and still
thinks that he could make better food if he were only allowed to light a
fire in his living room instead of using that complex electric stove.
(This is a real news item. Every now and then, landlords discover indoor
fireplaces and occasionally the "newbies" to civilization burn down the
building.) While it may seem "jarring" to the newbie to learn the ropes
of a society that has evolved at least a thousand years further than what
they left, it would not be the same for us to try out their lifestyle.
| 4) it's free software, so emacs can be forked whether or not rms wants it
| to
Wrong. The illusion of freedom with supposedly free software is blinding
to people who have never tried to make use of it.
| 5) this is a gnu project, and presumably they like to use scheme, so they
| should work on what they like. Plus rms just might know a thing or two
| about emacs, lisp and scheme.
Why does he need you to be a go-between to the Common Lisp community?
Please remove some of your attitude and listen a little more.
--
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.
From: Steven E. Harris
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <87y98zr8pp.fsf@harris.sdo.us.ray.com>
Erik Naggum <····@naggum.no> writes:
> The illusion of freedom with supposedly free software is blinding to
> people who have never tried to make use of it.
Is "it" here referring to use of the software itself, or of the
freedom this software promises? You're hinting at some trouble
here. Please elaborate.
--
Steven E. Harris :: ········@raytheon.com
Raytheon :: http://www.raytheon.com
From: Erik Naggum
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <3243694824668424@naggum.no>
* Erik Naggum
| The illusion of freedom with supposedly free software is blinding to
| people who have never tried to make use of it.
* Steven E. Harris
| Is "it" here referring to use of the software itself, or of the freedom
| this software promises? You're hinting at some trouble here.
The freedom. If you think you can use the freedom to make changes that
the owner of the sources does not like, you end up with a maintenance
nightmare as long as you keep a separate branch version that you try to
merge into the maintained version. If you think that splitting off a new
version is /not/ that kind of separate branch version, you have never
tried. Successful splits therefore means breaking away and taking with
you a sizeable chunk of the developers and users. Unsuccessful splits
waste enormous amounts of effort in competing for voluntary effort,
repetitive reimplementation of features from competitors simply to keep
abreast of the development, and unhappy users who see that the total
energy available for software development is sharply reduced by this
warring between factions. The Emacs/XEmacs split was very nasty, very
messy, and very typical of splits, as it has turned out.
I wonder if you have used the supposed freedom for anything and have a
different view, or if you have never used it but think I exaggerate or
even invent the negative aspects. Others have argued against my use of
"supposedly free" with what amounts to little more than ideology and how
they feel, which I tend to discount as the byproducts of thought at best,
so there is perhaps a dearth of actual information on how successful the
supposed freedom has actually been.
--
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.
From: Steven E. Harris
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <874rbns7ks.fsf@harris.sdo.us.ray.com>
Erik Naggum <····@naggum.no> writes:
> The freedom.
Thank you for the clarification.
> I wonder if you have used the supposed freedom for anything and have
> a different view, or if you have never used it but think I
> exaggerate or even invent the negative aspects.
I have not had the occasion to use that freedom, and I don't think you
exaggerate the point. Your view - rarely stated - is more pragmatic
and holistic. That is, you're not only taking into account what is
/permitted/ but what is sensible.
The negative aspects you mention aren't problems with a particular
license; they're social problems with any collaborative effort. That
the GPL encourages personal modification endeavors only makes these
social problems more manifest.
> Others have argued against my use of "supposedly free" with what
> amounts to little more than ideology and how they feel
Perhaps they didn't take the time to probe what you meant. You're
offering a spare lure with "supposedly free." Maybe you could ask,
"Even though you have a legal right to take this software and make it
your own, do you expect to be able to build a separate user base and
developer community around your effort?"
Most people are first concerned with having rights and later with
actually using them. Your argument hinges on the latter, and perhaps
your opponents focus only on the possibility of success - if not the
likelihood - enabled by having this right.
> there is perhaps a dearth of actual information on how successful
> the supposed freedom has actually been.
Are we looking for some derivative project that wound up in court
where the GPL saved the day, or just a fork that lived on and
attracted a healthy following?
--
Steven E. Harris :: ········@raytheon.com
Raytheon :: http://www.raytheon.com
From: Erik Naggum
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <3243710825281983@naggum.no>
* Steven E. Harris
| The negative aspects you mention aren't problems with a particular
| license; they're social problems with any collaborative effort.
On one level, this is true...
| That the GPL encourages personal modification endeavors only makes these
| social problems more manifest.
... but another level, the question is indeed whether the GPL is an
enabling legal framework or a disabling legal framework. There are many
other enabling legal frameworks and many proponents of free software
would benefit greatly from real insight into copyright and contract law.
All too frequently, they believe in myths and what they believe is better
is only better than what they believe the opposition believes, but when
the opposition does not actually believe it and the benefits are only
better than some imaginary, not better than any real alternatives.
Many other contracts have worked very well in the history of mankind, and
the legal framework within which most business is conducted is far better
at their job than the GPL is when it comes to sharing knowledge. The
myth that the GPL is freedom and everything else is not is a bad one.
| Perhaps they didn't take the time to probe what you meant. You're
| offering a spare lure with "supposedly free."
Interesting imagery, but far more flowery than "supposedly free" was ever
intended to communicate. My point is quite simply that it is supposed to
be free, but when you look closely and carefully at it, it is restricting
and confining.
| Maybe you could ask, "Even though you have a legal right to take this
| software and make it your own, do you expect to be able to build a
| separate user base and developer community around your effort?"
It is the "make it your own" part that is what the freedom should have
been about. This is where Free Software actually fails. You are free to
donate your work to the community, but not to make it your own. A huge
aspect of the social framework we have erected in the Western world is
that we both want people to help maintain society, but also to reward
people for their work and encourage those who can improve it. The Free
Software model encourages people to maintain the society created by Free
Software, but they are not rewarded for their work and those who want to
build on what they have been taught in order to build a better mousetrap,
find that their investment of time in Free Software is detrimental to
their ability to be rewarded for their inventions. When we as a society
are willing to pay taxes and force children to get an education and not
only work for their living as soon as they can, the point is to raise the
baseline of human endeavors and encourage people to work together over
the years to raise it even more. This is where Free Software does not
deliver, but real education and research and commercial intellectual
property rights actually do their job pretty darn well. However, as is
typical in the computer industry, people are so unskilled in social and
legal frameworks that they favor revolutionary over evolutionary progress.
| Most people are first concerned with having rights and later with
| actually using them.
I find this a very odd statement, but it is perhaps what happens when not
even your parents had to fight for these rights and they become so
abstract that "having rights" is worth something by itself, as opposed to
what your grandparents wanted to do with them.
| Your argument hinges on the latter, and perhaps your opponents focus only
| on the possibility of success - if not the likelihood - enabled by having
| this right.
My argumet is that success is not enabled by these rights, but is harder
to obtain with them than without them.
| Are we looking for some derivative project that wound up in court where
| the GPL saved the day, or just a fork that lived on and attracted a
| healthy following?
The GPL has never really been tested in court as far as I know, but I
have not kept track of that aspect, but more important to me is that the
GPL community has been much better at /not/ forking than actually making
use of the supposed freedom, to the point where forks are /fought/.
--
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.
You made various claims about free software that I wish to clarify
while I'm here. You wrote a 1-liner to me that I didn't respond to,
but you make big claims here that should be responded to.
For people who don't want to read all of this, mainly Erik considers
free software to be a failure. Well, Microsoft, Sun, and IBM don't
particularly think so. And I claim that his arguments against forks
are straw men.
So what goal does Erik think free software failed in? Compensation of
the programmer, most likely. The old critique. That's the muddled,
hard part. Steve Ballmer of Microsoft claims that this is doable only
if the computer industry moves to a service/support model, and so
perhaps it's not a matter of free software fitting in nicely with the
world. Rather it needs to change the economics of software dev in
order to succeed.
Erik Naggum <····@naggum.no> wrote in message news:<················@naggum.no>...
> All too frequently, they believe in myths and what they believe is better
> is only better than what they believe the opposition believes, but when
> the opposition does not actually believe it and the benefits are only
> better than some imaginary, not better than any real alternatives.
Happens everywhere where belief is an issue. But even the Slashdot
community is becoming sophisticated -- they question and argue instead
of blindly accepting as they did during the internet boom.
> The GPL has never really been tested in court as far as I know, but I
Eben Moglen: "'Look,' I say, 'at how many people all over the world
are pressuring me to enforce the GPL in court, just to prove I can. I
really need to make an example of someone. Would you like to
volunteer?"
To this date, I have only heard of close calls. There was a threat
this beginning of summer, but I've heard nothing more about it.
Publicizing violations is a last resort:
http://www.gnu.org/philosophy/enforcing-gpl.html
> the GPL community has been much better at /not/ forking than actually
> making use of the supposed freedom, to the point where forks are /fought/.
Amiable forks are quieter than the nasty ones. Stackless Python seems
to be a case study where it turned out to be that a fork was better
for the programmer's life:
http://groups.google.com/groups?dq=&hl=en&lr=&ie=UTF-8&oe=UTF-8&safe=off&selm=mailman.1032118518.24990.python-list%40python.org&prev=/groups%3Fq%3Dg:thl699927315d%26dq%3D%26hl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26safe%3Doff%26selm%3Dmailman.1032118518.24990.python-list%2540python.org
Instead of desperately getting something into the main distro that
people didn't quite understand, he eventually forked and now has a
company paying him part-time to work on Stackless mostly at home.
People are still feeling around how to maneuver with free software.
Linux has many amiable forks. I believe User-Mode Linux is one, which
recently merged into Linus' tree when it proved itself.
There are a few points here, some of which you raise:
1) sourceforge
You point out that maintaining a fork is hard work. True, but there
are increasing tools to ease this burden, such as sourceforge, gnu
savannah, and the subversion rcs. And consider the burden is relative
-- is it harder than forking a commercial project? Do all companies
listen to their users' requests and patches? Do some companies have
licenses shutting off your use of the software after a certain time?
2) maintainers needs
Sometimes the maintainers simply can't merge your patches. In the
Stackless example, the python maintainers did not want some addition
that made python harder to port or maintain, for a dubious furthering
of the language's goals. Often maintainers must have the courage to
say No to patches. To keep focus. This is a well-known phenomenon in
project management that saying No is a vital job.
3) newness
To many of its participants, free software is new. Maybe the issues
are not new to academia, but many don't have access to those lessons.
So a lot of mistakes and learning have to be made.
4) some teams are just worse, and hatred of forking naive
I don't think many people believe that Stallman is the world's best
project menager. I've heard mumblings about this from Icaza, maybe
Jim Blandy, and a few others who feel a bit burned. I read all the
emails on jwz's site about the XEmacs schism. I don't think Stallman
was capable of communicating himself to the Lucid team, though I
personally rooted for him.
With the OpenBSD split, it looks like deRaadt was working with bozos
who did silly things like announce a new version of their OS during
the Q&A of a talk of his. Obviously deRaadt is another extreme
personality, so the situation was no doubt too convoluted to care, but
was it the fork that was the important detail, or the project
management?
Knowing that many companies simply die because of management problems,
is free software so badly off in this sense?
5) money
Yup, that's the hard part. I hope that free software is young enough
that sponsorship slowly is being learned. But then there are people
like Tom Lord who are penniless, for every Linus, Alan Cox, or Tismer.
And not everyone is willing to be a Stallman working at McDonalds to
code during spare time.
This is definitely a downfall to free software, meaning that life is
again hard and complex. But there are companies which develop free
software under a GPL-like license, like BerkeleyDB, and use the
exceptions clause heavily. They are just not brash
superbowl-advertising companies.
http://www.winterspeak.com/columns/102901.html
> I find this a very odd statement, but it is perhaps what happens when not
> even your parents had to fight for these rights and they become so
> abstract that "having rights" is worth something by itself, as opposed to
> what your grandparents wanted to do with them.
It's like saving money for a rainy day. I think a grandparent who
fought for these rights should smack you over the head
(metaphorically) for not guarding your resources. Don't be
unnecessarily dependent. Be sustainable and deal with others as
economic equals.
Greg Neumann
Oops! ············@yahoo.com (Greg Neumann) was seen spray-painting on a wall:
> You made various claims about free software that I wish to clarify
> while I'm here. You wrote a 1-liner to me that I didn't respond to,
> but you make big claims here that should be responded to.
>
> For people who don't want to read all of this, mainly Erik considers
> free software to be a failure. Well, Microsoft, Sun, and IBM don't
> particularly think so. And I claim that his arguments against forks
> are straw men.
>
> So what goal does Erik think free software failed in? Compensation of
> the programmer, most likely. The old critique. That's the muddled,
> hard part. Steve Ballmer of Microsoft claims that this is doable only
> if the computer industry moves to a service/support model, and so
> perhaps it's not a matter of free software fitting in nicely with the
> world. Rather it needs to change the economics of software dev in
> order to succeed.
>
>
> Erik Naggum <····@naggum.no> wrote in message news:<················@naggum.no>...
>> All too frequently, they believe in myths and what they believe is better
>> is only better than what they believe the opposition believes, but when
>> the opposition does not actually believe it and the benefits are only
>> better than some imaginary, not better than any real alternatives.
>
> Happens everywhere where belief is an issue. But even the Slashdot
> community is becoming sophisticated -- they question and argue instead
> of blindly accepting as they did during the internet boom.
I thought the Slashdot community had pretty much fallen into the
combination of people that:
a) Blindly cheer against whatever seems to be pro-Microsoft;
b) Blindly cheer against whatever appears to be pro-Linux;
c) Try to set up web "bugs" to get readers to visit the "goats.ex" web
site (showing off something supremely ugly);
d) Breathing heavy about Natalie Portman ("Princess Amidala" in the
Star Wars prequels)
>> The GPL has never really been tested in court as far as I know, but I
> Eben Moglen: "'Look,' I say, 'at how many people all over the world
> are pressuring me to enforce the GPL in court, just to prove I
> can. I really need to make an example of someone. Would you like to
> volunteer?"
The absence of the fabled court case certainly leaves things a bit
nebulous, but it is by no means obvious that a court decision in a
specific case would actually resolve any of the perceived "problems of
it being nebulous."
I don't think a court case would do anything more than shift the
arguments to slightly different points.
> With the OpenBSD split, it looks like deRaadt was working with bozos
> who did silly things like announce a new version of their OS during
> the Q&A of a talk of his. Obviously deRaadt is another extreme
> personality, so the situation was no doubt too convoluted to care,
> but was it the fork that was the important detail, or the project
> management?
That one's a clear example of "sometimes forks are necessary because
some people can't work together."
--
(concatenate 'string "cbbrowne" ·@cbbrowne.com")
http://cbbrowne.com/info/spiritual.html
"I doubt this language difference would confuse anybody unless you
were providing instructions on the insertion of a caffeine enema."
-- On alt.coffee
From: Erik Naggum
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <3243739656876897@naggum.no>
* Greg Neumann
| You made various claims about free software that I wish to clarify while
| I'm here.
You cannot clarify what I have said. Acquire precision in communication.
| You wrote a 1-liner to me that I didn't respond to, but you make big
| claims here that should be responded to.
It appears less than likely that you have been willing to think about
them.
| For people who don't want to read all of this, mainly Erik considers free
| software to be a failure.
People can read what I wrote just fine on their own. But it is quite
interesting to see that you have missed the point so completely. The
point here is not some absolutist "success" vs "failure" mode. The point
here is to encourage people to think about the successfulness in light of
its actual achievements. You fail to address that point, but think that
listing success stories is all it takes to rebut some non-argument about
failure that nobody ever made. You mention "straw man", so there is some
reason to suspect that you know what you have just erected and shot down
entirely on your own. The question is whether it /helps/ anyone that
software is "free". This is not rebuttable with a few simple examples.
I would have thought that such should be fairly obvious, but apparently
not.
| So what goal does Erik think free software failed in? Compensation of
| the programmer, most likely. The old critique.
The extent of your failure to exercise your brain is quite alarming. If
I hooked up electronics and sensors to it to test its activity, the
result could most probably only be used to calibrate the equipment.
| People are still feeling around how to maneuver with free software.
This much is true.
| And consider the burden is relative -- is it harder than forking a
| commercial project? Do all companies listen to their users' requests and
| patches? Do some companies have licenses shutting off your use of the
| software after a certain time?
The point was to encourage people to think about such questions. Instead
you just ask and do not think. Oddly amusing.
| To many of its participants, free software is new. Maybe the issues are
| not new to academia, but many don't have access to those lessons. So a
| lot of mistakes and learning have to be made.
One point is precisely that free software is not better than many of the
extant alternatives. Having to learn every lesson from scratch because
people are ignorant does not seem to be a winning counter-argument.
| I don't think many people believe that Stallman is the world's best
| project menager. I've heard mumblings about this from Icaza, maybe Jim
| Blandy, and a few others who feel a bit burned. I read all the emails on
| jwz's site about the XEmacs schism. I don't think Stallman was capable
| of communicating himself to the Lucid team, though I personally rooted
| for him.
You do seem to have a curious knack for discussing people instead of
ideas.
| Knowing that many companies simply die because of management problems, is
| free software so badly off in this sense?
My question is whether it actually /helps/ and /solves any problems/. If
it is no better than the alternatives it is supposedly better than, that
is a clear symptom of missing the boat or at least exaggerated claims.
| Yup, that's the hard part.
I was not talking about money. I talked about rewards. It is curious
indeed that you do not seem to know of any other rewards than money.
Part of the charm with free software is its capacity for non-taxable means
of reward which would essentially double the value of the reward. This
part is underexplored, to put it mildly.
| It's like saving money for a rainy day. I think a grandparent who fought
| for these rights should smack you over the head (metaphorically) for not
| guarding your resources. Don't be unnecessarily dependent. Be
| sustainable and deal with others as economic equals.
But does free software /help/ or /hinder/ in applying this sage advice?
/That/ is the question I would like you to think about. Again, I can
only regret that it did not seem to work very well.
--
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.
Steven E. Harris <········@raytheon.com> wrote in
···················@harris.sdo.us.ray.com:
> Erik Naggum <····@naggum.no> writes:
>
>> The freedom.
>
> Thank you for the clarification.
>
>> I wonder if you have used the supposed freedom for anything and have
>> a different view, or if you have never used it but think I
>> exaggerate or even invent the negative aspects.
>
> I have not had the occasion to use that freedom, and I don't think you
> exaggerate the point. Your view - rarely stated - is more pragmatic
> and holistic. That is, you're not only taking into account what is
> /permitted/ but what is sensible.
>
> The negative aspects you mention aren't problems with a particular
> license; they're social problems with any collaborative effort. That
> the GPL encourages personal modification endeavors only makes these
> social problems more manifest.
No they are in large part licence issues. Public Domain and the mit,bsd
licences allow me to share the results of my work, by selling them for
instance, but allow me to keep the work private. This allows me to
leverage what has been done to provide a new product. As a small player
in this market I really like that. The gpl/lgpl licence places my work
at risk as soon as I release a binary. I personelly feel that the
lgpl/gpl is hostile and dangerious to small busniess, my 1 man part-time
shop. Look at the new CL sceener(sp?), the one based on cmucl. If they
used [l]gpled code there customers would have the right to all the code
that produced the touched part of the binary distrabution. This would
add a lot more risk to the new venture, possibly killing it before it
began.
>
>> Others have argued against my use of "supposedly free" with what
>> amounts to little more than ideology and how they feel
>
> Perhaps they didn't take the time to probe what you meant. You're
> offering a spare lure with "supposedly free." Maybe you could ask,
> "Even though you have a legal right to take this software and make it
> your own, do you expect to be able to build a separate user base and
> developer community around your effort?"
>
> Most people are first concerned with having rights and later with
> actually using them. Your argument hinges on the latter, and perhaps
> your opponents focus only on the possibility of success - if not the
> likelihood - enabled by having this right.
>
>> there is perhaps a dearth of actual information on how successful
>> the supposed freedom has actually been.
>
> Are we looking for some derivative project that wound up in court
> where the GPL saved the day, or just a fork that lived on and
> attracted a healthy following?
>
If you want to see something that I think is shaping up to be a very
interesting mess look at the use of patented algorithims in gpled/bsd/pd
software. Look at the openssl use of Suns's donated but still patented
software. Here is free code if you use it we can sue you. This could
be an over simplification, but I just do not know.
marc
Steven E. Harris <········@raytheon.com> wrote:
> Erik Naggum <····@naggum.no> writes:
> > The freedom.
> Thank you for the clarification.
> > I wonder if you have used the supposed freedom for anything and have
> > a different view, or if you have never used it but think I
> > exaggerate or even invent the negative aspects.
> I have not had the occasion to use that freedom, and I don't think you
> exaggerate the point. Your view - rarely stated - is more pragmatic
> and holistic. That is, you're not only taking into account what is
> /permitted/ but what is sensible.
> The negative aspects you mention aren't problems with a particular
> license; they're social problems with any collaborative effort. That
> the GPL encourages personal modification endeavors only makes these
> social problems more manifest.
I think it all depends on what you intend. If you intend to modify the
code for your own purposes and don't care about forking away from the
original, or attracting a following, then it is free enough.
It seems like this is largely a political issue. If you want to make
changes to the code, and you want to do this in a way that your changes
get incorporated (as an option) into the standard distribution, and you
want anyone making future changes to the system to consider the fact
that you have written this modification package, then GNU is not where
you want to do this, because FSF is strongly political and controlling
about its projects.
I'm not sure that makes Gnu software only "supposedly free". That's
true only to the extent that your goals are political, involving *their*
software, as well as technical.
That's also assuming you don't intend every to sell what you do to it
yourself, or that they're using the lesser GPL. I can definitely agree
that the GPL itself makes software licensed under it not truly free, as
it hamstrings what you can do with it -- "Whatever you want, as long as
rms thinks it's kosher".
Michael
--
Michael Sullivan
Business Card Express of CT Thermographers to the Trade
Cheshire, CT ·······@bcect.com
From: Johannes Grødem
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <lzelarcw3c.fsf@unity.copyleft.no>
* Erik Naggum <····@naggum.no>:
> The freedom. If you think you can use the freedom to make changes that
> the owner of the sources does not like, you end up with a maintenance
> nightmare as long as you keep a separate branch version that you try to
> merge into the maintained version. [...]
Well, yes, it's not always practical, but at least it's possible,
unlike with proprietary software, where it's essentially impossible.
(At least in the case where you don't have access to the source.)
That it's free means that you can change it, it doesn't mean that you
are necessarily able to, or that it is practical.
I thought people understood this, but you've experienced otherwise?
Or is your point that the free software movement is trying to make
free software look better than it really is?
--
Johannes Gr�dem <OpenPGP: 5055654C>
From: Erik Naggum
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <3243708171567859@naggum.no>
* Johannes Gr�dem
| Well, yes, it's not always practical, but at least it's possible, unlike
| with proprietary software, where it's essentially impossible.
This is actually the worst kind of nonsense -- a massive lack of insight
into business leads people to believe things like this and it is hard for
them to get out of this mindset over time.
| (At least in the case where you don't have access to the source.)
Purchase it, contract with the owners to do what you want.
| That it's free means that you can change it, it doesn't mean that you are
| necessarily able to, or that it is practical.
When it is supposedly free, you believe you have freedoms that you find
that you actually cannot use because of the restrictions on a number of
other freedoms that you signed away. Many people in the business
community shake their heads in disbelief about the often staggeringly
misguided ideas that proponents of supposedly free software cling to like
a religion or an ideology that would crumble immediately upon serious
contact with reality. It therefore becomes necessary to avoid getting
into a position where money can buy you freedom, and this is obviously
very attractive to young people and students, who have no money and feel
better in the short term if they believe this is not a situation that can
be fixed. The really sad thing is that you do not need to get filthy
rich to purchase more freedom, but if you give away what other people
would have been willing to give you something in exchange for, and you
keep doing this for a long time, you get stuck in that position. This is
not good for anyone in the long term. And we live in the long term. Had
we lived in the short term that the supposedly free software community
favors, dying before 30 would have been the norm. And unsurprisingly,
few people "survive" in the free software "market" beyond that age. Many
regret all the time they just gave away instead of working for money.
| I thought people understood this, but you've experienced otherwise?
I have experienced the freedom of doing business, too. Those who are so
confused as to believe that the choice is only between "proprietary = I
can't get at it" and "supposedly free = I can get at it" /completely/
miss the point. I was a strong proponent of free software because I
thought that available source code would be educational and would help
make programming a real profession by making its products available for
study by new practitioners in the field, and I worked on Emacs because
what I had done with it helped me in so many ways. However, open source
is not educational -- few people read source code, and what is produced
is generally of extremely poor quality, providing some evidence that the
value of education through source code access never materialized.
| Or is your point that the free software movement is trying to make free
| software look better than it really is?
No. People who are led by how things appear deserve whatever they get.
My purpose when writing is not to convince people of my view or to make
them believe me, but to encourage them to think about something I have
thought about and to provide me with their thoughts in return. I believe
that this is what human communication can do at its best. The tendency
to believe things, or worse, people, instead of thinking about what one
has read or heard, causes nothing but problems. I tend to get pissed off
by believers and those who do not want to think because they are afraid
of being "convinced" of something new, because they are like talking to
people who are in a coma. Maybe they can wake up and remember it and
maybe they have thought about a lot in their comatose state, but that is
generally a losing bet. Still, waking them up seems like a good idea and
making people think does appear to be beneficial no matter how late in
life they start to think about more than they can believe in, because the
desire to believe is the worst enemy of independent thought there can be,
not because people believe in the so-called "irrational" or "mystical",
on which I have no opinion, but because independent thought has to work
with ideas and undeveloped thoughts that /should not be believed/ until
they have been thought about much more and much longer. So if your first
reaction is "I do not believe", indicating that you must believe before
you can proceed, you are in a coma as far as I am concerned. It appears
that some people are unable to think about, discuss,or consider things
possible, if they do not also believe in them to some degree, and thus
cannot read, cannot listen to, cannot /understand/ arguments that go
against their beliefs at any given time and primarily respond with "I
don't believe it", or even less intelligently, "I don't believe you". I
still believe (!) that the only way to make people wake up and think is
to present them with lots of things that are worth thinking about. Many
people seem to wake up when there is no way they can remain in a comatose
state without actually realizing that they have turned themselves off.
It appears that the belief in the benefits of supposedly free software is
remarkably resistant to independent thought.
--
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.
On 15 Oct 2002, Erik Naggum wrote:
[regarding forking]
> * Johannes Grødem
> | Well, yes, it's not always practical, but at least it's possible, unlike
> | with proprietary software, where it's essentially impossible.
>
> This is actually the worst kind of nonsense -- a massive lack of insight
> into business leads people to believe things like this and it is hard for
> them to get out of this mindset over time.
>
> | (At least in the case where you don't have access to the source.)
>
> Purchase it, contract with the owners to do what you want.
>
Erik, I don't understand your argument. The whole rationale of forking is
that the owner (or leader, or manager) disagrees that your idea is the way
the product should evolve. If I have a new idea for Windows and Microsoft
doesn't like the idea, what am I to do? If I have a new idea for Linux
and Linus doesn't like it, I can fork the linux kernel and still do it.
You are right, maintenance, bookkeeping, finding users, etc. make this
option almost impossible a lot of the time.
--
Nathan Whitehead
From: Erik Naggum
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <3243715978755380@naggum.no>
* Nathan Whitehead
| The whole rationale of forking is that the owner (or leader, or manager)
| disagrees that your idea is the way the product should evolve.
Quite so.
| If I have a new idea for Windows and Microsoft doesn't like the idea,
| what am I to do?
The same thing you do if you have a better idea for anything else in any
other industry: Decide if you think the market for your improvement may
be big enough that it is worth your time to build a competitor. People
have actually done this very frequently in every other industry. I have
no idea why people consider software so hard that they could not develop
something better with their own money and source base. Perhaps the lack
of working intellectual property mechanisms (e.g., patents, which are
horribly unfit in their current application) in the software industry
makes it so much harder to build on the past, but I fear that the real
reason is that we all know how shoddy most software products are and how
little /real/ value is produced in software development. Microsoft's
crap would never have gotten off the ground in a market where the
customers were competent to judge the quality of their products. It was
all about enticing ignorant people in "future" gains. The belief in the
rosier future confused the financial markets for a long time, too. I
marvel at the sheer evil of the manipulativeness and propaganda skills of
those who could actually lie to so many investors about the ability to
make money with the investments they sought. Microsoft has been built on
deception and fraud from the get-go. Their incompetence and the amazing
manipulativeness of the marketing nonsense around their inability to get
a working version of Windows on the market when promised should have been
enough for anyone with half a brain to realize that this swindling outfit
was slated for DoJ investigations if not criminal proceedings not too far
down the line, but, no, people bought MSFT shares and their products.
What /appears/ to be true, therefore, is that if you have a better idea
for the software, that is wholly irrelevant with such a fraudulent gang
of incompetents as "market leader" -- what matters in software is how
many people you can con for how long, or so people think. This may not
even be possible to change with a really much better software idea, but
mostly because Microsoft has convinced so many people that to produce
even their crapware, you need /many/ billions of dollars and nothing
short of hundreds of thousands of man-years. The Open Source world has
not disproved this point at all: counting the amount of effort that goes
into the Linux kernel and the GNU software suite alone is intractable.
So if you sit there with an idea you think you could realize with a few
months' worth of effort at most, there is nothing to build on that would
make it possible to do this without practically infinite amounts of
money. But this belief is actually very, very wrong. It is perhaps the
single most successful deception that Microsoft has foisted upon us:
Software is so hard to get right that even they cannot do it. This is
the one point where the Common Lisp community knows better, but how can
we tell people this when they are deluged with viruses and their source
of trust, the very same Microsoft, says that they cannot fix the problems
and that malevolent people take advantage of their desire to help users
work smarter and more efficiently? (The latter is also wrong. Very few
administrative tasks in the running of any business costs less than they
did two decades ago.)
The question I ask is therefore: Why do you think you could succeed any
better if you had the source code?
| If I have a new idea for Linux and Linus doesn't like it, I can fork the
| linux kernel and still do it. You are right, maintenance, bookkeeping,
| finding users, etc. make this option almost impossible a lot of the time.
Some of the Linux distributions have used deviant Linux kernels and some
weird versions of GNU utilities, such as the GNU C compiler. This is a
source of nothing but trouble and much hostility in the Linux community.
It is partly because of the idiot waste of effort and lack of ability to
cooperate in the Linux community that I consider free software less able
to succeed in its stated goal than commercial software development.
The important thing to remember is that there is more commercial software
than Microsoft. Being better than Microsoft in software quality is easy.
Being better than any of the other small companies that are better than
Microsoft is not that easy. Microsoft holds the whole industry hostage
with their own incompetence and the almost religious faith in Microsoft's
ability to cater to market needs has made it very, very hard to succeed
for the *huge* number of small companies who can do better than them.
Had Microsoft not been so incompetent at software development, their
competitors would have been fewer, stronger, and better, and thus more
able to succeed in competing with them. It is not the first time in our
modern industrial history that low quality and good marketing has been a
strong winning bet. The only solution to this problem is good education
and people who have /learned/ to think long-term. Since our business
schools are not exactly churning out that kind of leaders at this time,
we are not likely to come out of the "IT winter" any time soon, but my
bet is that some small company that just does /much/ better than the
idiot behemoth will take the world by storm.
--
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.
From: Steven E. Harris
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <87k7kjqn0s.fsf@harris.sdo.us.ray.com>
Erik Naggum <····@naggum.no> writes:
> However, open source is not educational -- few people read source
> code, and what is produced is generally of extremely poor quality,
> providing some evidence that the value of education through source
> code access never materialized.
For me, as a programmer, education has been the most valuable facet of
open source software. Saving money on it isn't as valuable as learning
from it. I can afford to buy, say, an editor or compiler if necessary,
but I don't become a better programmer as a result. If I am allowed to
study others' source code, though, I learn from both their skill and
their mistakes. Without broad access to others' source code, I would
be limited to my textbooks, or perhaps to my peers' work at my current
employer.
I agree that not all open-source code is worth learning from. Then
again, neither is all of the in-house code I have access to. Having
more examples - both positive and negative - available for study
provides vicarious experience and helps refine one's taste.
As a shining example, consider Boost�. Much of my C++ knowledge is
built atop techniques and style exhibited in these libraries.
Footnotes:
� http://www.boost.org
--
Steven E. Harris :: ········@raytheon.com
Raytheon :: http://www.raytheon.com
From: Erik Naggum
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <3243717585684194@naggum.no>
* Steven E. Harris
| For me, as a programmer, education has been the most valuable facet of
| open source software. Saving money on it isn't as valuable as learning
| from it.
I am happy to see this, and if it was not sufficiently clear from what I
wrote, I favor sharing source code because I have learned this way myself
and because most other industries let people share the accumulated skills
of the trade. Software vendors have a potential to keep things secret
that is perhaps unique, much unlike respectable trades like medicine,
law, engineering, architecture, etc. It was certainly legitimate to rebel
against the desire to hide everything and force everybody to start their
own development efforts much "earlier" than the state of the art, but the
new method of the rebels is not better than what they rebel against.
| Without broad access to others' source code, I would be limited to my
| textbooks, or perhaps to my peers' work at my current employer.
This is where I think people go wrong. Truly vast applications and
billions of lines of code has been developed at universities. Most, if
not all, of this is available to practitioners in the field. The one big
gripe against "university code" is that it is not itself intended to be
the main winning point -- getting some degree is. This changes the value
system of software development. Commercial development has another value
system entirely, and free software development yet another. It is not
obvious which one would succeed if industry wanted plug'n'play employees,
but the commercial model did not exactly get an opportunity to show
itself before it was denounced on largely misguided terms.
| I agree that not all open-source code is worth learning from. Then
| again, neither is all of the in-house code I have access to. Having more
| examples - both positive and negative - available for study provides
| vicarious experience and helps refine one's taste.
But then there is the time cost of learning...
| As a shining example, consider Boost. Much of my C++ knowledge is built
| atop techniques and style exhibited in these libraries.
I have heard much good about this, and if I had an interest in C++, I
would have looked closely at it from the great reviews alone.
Perhaps to the point, C++ is just the kind of language (and community)
that produces heaps and heaps of incredibly rotten code in a language
that is implemented and understood poorly, so I have quipped that life is
too long to be good at C++ -- if you had spent all that time to become
good at it, you would essentially have to work with it, too, to get back
the costs, and that would just be some long, drawn-out torture. I gave
up on C++ in 1994 but have good friends who tell me that I really miss
out on major developments. Unlike most here, it seems, I happen to think
Java is a serious improvement on what went before it and should be known,
perhaps mostly for its rich community and libraries and its adaptability.
The code you do not have to write should be worth a lot to you -- and if
it comes in the shape of supported libraries from a good vendor, I think
that is much better than relying on community-developed software of
dubious quality and little commitment.
On that tangent, it is probably the lack of commitment and follow-through
that bothers me with the "free" software, and nobody can take it and make
a serious buck on improving it to be fully polished products because they
/have/ to "share" their changes. Maintenance, quality assurance, etc,
are very expensive processes, but the result is indistinguishable, qua
copyable files, from shoddy code. So "the boring part" of the software
cycle never gets completed or even really started by unpaid people.
In the much-lamentable Old Days, when fewer programmers could get at the
source code, it had higher quality and was better to learn from. As more
people with less commitment to quality and much less attention to detail
got involved in writing it, its educational value diminished, too. It is
like going to a library full of books that took 50 man-years to produce
each, inventing a way to cut down the costs to a few man-months per book
by copying and randomly improving on other books, and then wondering why
nobody thinks your library full of these cheaper books is an inspiration
to future authors. Like Microsoft was a once-in-a-civilization thing and
could not be repeated by anyone now that we have seen how much damage can
be done by such people, I believe Free Software is another once-in-a-
civilization thing that must be declared to have won or failed, and then
we move on to something better. Once a good thing, it has survived the
achievement of its goals and now produces more problems than alternatives
it was intended to fight. This happens to a lot of mediocre ideas.
--
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.
Hmm, these are actually sober views. I'm now falling into the trap of
pointlessly nitpicking, like I felt others were. I'll stop posting
here unless I have straightforward questions. This is indeed a weird
place, and that's not a bad thing... Gotta wear blinders or fall into
the bog.
Eh, forget what I wrote about free software.
Greg Neumann
From: Thien-Thi Nguyen
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <kk9zntewzly.fsf@glug.org>
············@yahoo.com (Greg Neumann) writes:
> Eh, forget what I wrote about free software.
better to think about it (perhaps in low-priority cycles), and then write some
free software if you feel your principles are supported by doing so. ideas
and spew (such is usenet) are easily ridiculed, but even a ridiculous program
can also aspire to be useful.
yes, some programs don't believe in users and their faithless drudgery in
forcing their dominion over other programs deprives the sky of the i/o signal.
cursed and recursed, this abstracted interception; hearsed and rehearsed, this
purposeless interdiction. byte written but bit rotten, will your free program
be so misbegotten? what is good and what is not good?!!!
thi
Erik Naggum <····@naggum.no> writes:
> Unlike most here, it seems, I happen to think Java is a serious
> improvement on what went before it and should be known, perhaps
> mostly for its rich community and libraries and its adaptability.
> The code you do not have to write should be worth a lot to you --
> and if it comes in the shape of supported libraries from a good
> vendor, I think that is much better than relying on
> community-developed software of dubious quality and little
> commitment.
Out of curiosity, have you used Java much? It's true that it comes
with a rich complement of well-done libraries, but they come with APIs
that I find so atrocious as to be almost unusable. Maybe the Java way
is a worse fit to my brain than it is to most peoples, but I find the
standard libraries sometimes get in the way to the extent that it
might be easier to just reimplement what I want in a less-crazy
manner.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: Erik Naggum
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <3243780812018665@naggum.no>
* Thomas F. Burdick
| Out of curiosity, have you used Java much?
Not for production purposes. I do not think I will want to do that. I
would rather hire cheap programmers who can write Java code than do it
myself, but I actually believe it is a good language for its purposes and
I have read a lot on Java. I want to program in Common Lisp, not Java,
myself, but if I were to hire a bunch of people to get something done, I
would want them to use something that was not braindamaged like C++ and
which I could be reasonably sure was not all buggy like C programs are.
| Maybe the Java way is a worse fit to my brain than it is to most peoples,
| but I find the standard libraries sometimes get in the way to the extent
| that it might be easier to just reimplement what I want in a less-crazy
| manner.
Well, people should not use tools that do not fit the way they think.
--
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.
From: Steven E. Harris
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <87k7kip3y2.fsf@harris.sdo.us.ray.com>
Erik Naggum <····@naggum.no> writes:
> if I were to hire a bunch of people to get something done, I would
> want them to use something that was not braindamaged like C++ and
> which I could be reasonably sure was not all buggy like C programs
> are.
Having worked mostly with C++ and some with Java, I observed a
relationship that must exist between any two languages or systems with
similar intent.
Since the Java language is easier to learn than C++, less skilled
people can get involved more quickly. The average Java programmer may
be less skilled than the average C++ programmer, but since it's harder
to make grave mistakes in Java, the danger balances out.
Conversely, the C++ language is harder to learn than Java, so it takes
a greater commitment and more time to get involved. The average C++
programmer may be more skilled than the average Java programmer, but
it's easier to make grave mistakes in C++, so the gain balances out.
I prefer C++'s difficulty because intense attention to detail can
ensure a safe and correct program, but with Java there's a higher
level of non-beneficial abstraction (the VM) below which one cannot
penetrate. If I write a seemingly-correct Java program and it doesn't
perform properly, there is less I can do about it. (Or, maybe, I don't
know the tools well enough to investigate and overcome problems with
the libraries and VM.)
Also, the "knowledge ceiling" with C++ is higher than with Java. After
programming in Java for a couple of years, I felt that there wasn't
much left to learn about it apart from cataloging its ever-growing
libraries. I couldn't do much to become a better Java /programmer/; I
could only become a better Java /librarian/. C++ invites seemingly
perpetual investment and does reward this effort.
Arguably my preference is based more on the desire to learn than to
"just get work done." It's depressing to start learning about
something new, only to find too quickly that there's nothing left to
learn. That is, hitting that "knowledge ceiling" too soon only leads
to boredom and disinterest. C++ keeps my interest where Java could
not. Common Lisp appears to offer a similarly high "ceiling" (perhaps
with much earlier reward). Hence my interest here.
--
Steven E. Harris :: ········@raytheon.com
Raytheon :: http://www.raytheon.com
From: Erik Winkels
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <87bs5uf96t.fsf@xs4all.nl>
Steven E. Harris <········@raytheon.com> wrote:
>
> I prefer C++'s difficulty because intense attention to detail can
> ensure a safe and correct program,
I prefer to be very drunk with my hands tied behind my back because
the need to concentrate harder and make no typing mistakes can ensure
a safe and correct program.
From: Steven E. Harris
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <871y6qp1zn.fsf@harris.sdo.us.ray.com>
Erik Winkels <·······@xs4all.nl> writes:
> I prefer to be very drunk with my hands tied behind my back because
> the need to concentrate harder and make no typing mistakes can
> ensure a safe and correct program.
I knew this something like this was coming. Nicely put, nonetheless.
--
Steven E. Harris :: ········@raytheon.com
Raytheon :: http://www.raytheon.com
From: Joe Marshall
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <hefm5ctu.fsf@ccs.neu.edu>
Erik Winkels <·······@xs4all.nl> writes:
> Steven E. Harris <········@raytheon.com> wrote:
> >
> > I prefer C++'s difficulty because intense attention to detail can
> > ensure a safe and correct program,
>
> I prefer to be very drunk with my hands tied behind my back...
Kinky.
From: Erik Naggum
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <3243796678973331@naggum.no>
* Steven E. Harris
| It's depressing to start learning about something new, only to find too
| quickly that there's nothing left to learn.
Definitely true. Look at it this way: If people hit the ceiling without
having to invest enormous amounts of time on idiotic stunts like C++
forces you to, they have an incentive to move to a different language
instead of wasting away at the braindamage that I still think C++ is at
the level where it could become most interesting.
| That is, hitting that "knowledge ceiling" too soon only leads to boredom
| and disinterest.
But you have acquired skills and an interest in improving your condition
that is much more beneficial than staying with a language that exhibits
diminishing returns for a constant increase in effort.
| C++ keeps my interest where Java could not. Common Lisp appears to offer
| a similarly high "ceiling" (perhaps with much earlier reward). Hence my
| interest here.
This is excellent! I am truly happy to see this and your rationale for
it. But it also tells me that Java is a better language than C++ because
you /did/ leave for greener pastures instead of staying in C++.
If a field gives you a feeling that "I can do better than this" and lets
you move on, it gives you freedom. If you get stuck there with a feeling
that "with only a little more work, I can improve on this", it is only
restricting and confining. Therefore, I would much rather give people
Java and tell them to call me when they are exhausted than give them C++
and never hear from them because they vanish into a maze of templates and
meta-class programming and whatnot. People who are happy to become the
best carpenter in town are a different breed than those who want more and
go on to become architects and hire lots of other carpenters and do new
and exciting things. I tend to think that it cannot hurt to spend a few
years actually building houses if you want to become an architect, and if
you get credits for your experience when you want to return to school,
that is the most beneficial way to reward real experience.
Do you have an alternative model?
--
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.
From: Charlton Wilbur
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <878z0mzlaw.fsf@mithril.chromatico.net>
>>>>> "EN" == Erik Naggum <····@naggum.no> writes:
EN> But you have acquired skills and an interest in improving
EN> your condition that is much more beneficial than staying with
EN> a language that exhibits diminishing returns for a constant
EN> increase in effort.
But the realities of needing to eat make this impossible. I'm bored
with the web, and with Java, and to a lesser extent with Perl (mainly
because the problems I solve with it are so repetitive, and I've
already automated them as far as I can). I would love to find
interesting problems to solve, and learn new things to solve them
with. I would love to jump ship and find a job where I got new
problems to solve on a regular basis, rather than solving the same old
tired problem repeatedly, or having to play political games to solve
the problem correctly. But every approach to doing so involves a
tradeoff I'm not willing to make, and so at this point, given what
I've observed of the state of the industry, my plan at this point is
to get out as soon as possible.
And I don't expect there *are* solutions, the psychology of business
beign what it is. Cheap mediocrity coupled with buzzword-compliance
always seems to win in the end.
Charlton
Charlton Wilbur <·······@mithril.chromatico.net> writes:
> >>>>> "EN" == Erik Naggum <····@naggum.no> writes:
>
> EN> But you have acquired skills and an interest in improving
> EN> your condition that is much more beneficial than staying with
> EN> a language that exhibits diminishing returns for a constant
> EN> increase in effort.
>
> But the realities of needing to eat make this impossible. I'm bored
> with the web, and with Java, and to a lesser extent with Perl (mainly
> because the problems I solve with it are so repetitive, and I've
> already automated them as far as I can).
This, IMO, is one major problem with the way your average,
high-lines-of-code production programmer is trained. I've put
together systems that automate some class of tasks, and reduce the
effort needed to do the task by an order of magnitude or more. One
system would create entire web sites based on interactive prompting
that took about two hours -- add another three hours to finish the
job, and you've got the site up in one day, with plenty of time to
read mail and usenet. To put up one of these sites by hand, basing it
on the code for a similar site, would take a "hot-shot" programmer two
weeks or so. Others would take 3-4. I documented the hell out of
this system, including both in-depth and introductory documentation.
Did anyone but me use it? I'll let you guess :-(. For some reason,
people who consider themselves programmers don't mind being trained
users of complex systems where most of the work has already been done,
like Java or Perl -- but if the system doesn't have an O'Reilly book,
they won't go for it.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> on the code for a similar site, would take a "hot-shot" programmer two
> weeks or so. Others would take 3-4. I documented the hell out of
> this system, including both in-depth and introductory documentation.
> Did anyone but me use it? I'll let you guess :-(. For some reason,
Is you code available?
Chris
Chris Beggy <······@kippona.com> writes:
> ···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
> > on the code for a similar site, would take a "hot-shot" programmer two
> > weeks or so. Others would take 3-4. I documented the hell out of
> > this system, including both in-depth and introductory documentation.
> > Did anyone but me use it? I'll let you guess :-(. For some reason,
>
> Is you code available?
No, I wrote it, but it was work-for-hire. Besides, it wasn't factored
very well (I was trying to get it done in the expected 2-2.5 weeks),
so it would only be good for creating things that compete fiarly
directly with the company I wrote it for. It was 75% elisp, though,
which made all the difference. (Wow, look at that, the topic came
full circle).
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: Erik Naggum
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <3244563425575049@naggum.no>
* Thomas F. Burdick
| I documented the hell out of this system, including both in-depth and
| introductory documentation.
:
| For some reason, people who consider themselves programmers don't mind
| being trained users of complex systems where most of the work has already
| been done, like Java or Perl -- but if the system doesn't have an O'Reilly
| book, they won't go for it.
Call Tim and get an animal and their formatting guidelines and produce a
mock-up of an O'Reilly book using your documentation that you can give to
people who consider themselves programmers but refuse to use your system.
--
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 <····@naggum.no> writes:
> * Thomas F. Burdick
> | I documented the hell out of this system, including both in-depth and
> | introductory documentation.
> :
> | For some reason, people who consider themselves programmers don't mind
> | being trained users of complex systems where most of the work has already
> | been done, like Java or Perl -- but if the system doesn't have an O'Reilly
> | book, they won't go for it.
>
> Call Tim and get an animal and their formatting guidelines and produce a
> mock-up of an O'Reilly book using your documentation that you can give to
> people who consider themselves programmers but refuse to use your system.
Heh, that's not a bad idea for the next time I run into this. I'm
very prone to automating tasks, because I find it less mind-numbing,
and occasionally such systems are useful to people other than me, so I
run into this on a semi-regular basis. I'll just have to be sure to
use the typeface(s) that O'Reilly uses, and resist the tempatation to
set the type in a face more appropriate for the engravings.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Erik Naggum <····@naggum.no> wrote in ·····················@naggum.no:
> * Thomas F. Burdick
>| I documented the hell out of this system, including both in-depth and
>| introductory documentation.
>:
>| For some reason, people who consider themselves programmers don't
>| mind being trained users of complex systems where most of the work
>| has already been done, like Java or Perl -- but if the system doesn't
>| have an O'Reilly book, they won't go for it.
>
> Call Tim and get an animal and their formatting guidelines and
> produce a mock-up of an O'Reilly book using your documentation that
> you can give to people who consider themselves programmers but
> refuse to use your system.
>
Well you could go to Dover Press and not have to bother Tim, O'Reilly
gets there cover art from Dover clipart.
Just had to plug Dover Press, great books at great prices.
marc
ps there is an O'Reilly cover maker some where on line, don't have the
link handy.
marc
From: ······@panix.com
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <lhrlm4mcebl.fsf@panix2.panix.com>
Marc Spitzer <········@optonline.net> writes:
> ps there is an O'Reilly cover maker some where on line,
> don't have the link handy.
http://www.ilbbs.com/oracovers
Just tried it out and it works great. Only seven animals
to choose from however.
harley.
From: ozan s yigit
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <vi4hefaaqz9.fsf@blue.cs.yorku.ca>
······@panix.com writes:
> http://www.ilbbs.com/oracovers
>
> Just tried it out and it works great. Only seven animals
> to choose from however.
i'm disappointed that the dodo image (pp 124, #543) is not amongst
the seven animals chosen. i don't recall seeing it on any o'reilly
cover...
oz
From: Vassil Nikolov
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <uk7k5sy2a.fsf@poboxes.com>
On 25 Oct 2002 22:11:54 -0400, ozan s yigit <··@blue.cs.yorku.ca> said:
osy> i'm disappointed that the dodo image (pp 124, #543) is not amongst
osy> the seven animals chosen. i don't recall seeing it on any o'reilly
osy> cover...
Because, as Genesis sang, `the dodo must die'...
---Vassil.
--
For an M-person job assigned to an N-person team, only rarely M=N.
From: ozan s yigit
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <vi4hefaw0mj.fsf@blue.cs.yorku.ca>
Marc Spitzer:
> Well you could go to Dover Press and not have to bother Tim, O'Reilly
> gets there cover art from Dover clipart.
indeed. it is
Animals: 1419 Copyright-Free Illustrations of
Mammals, Birds, Fish, Insects etc
A Pictorial Archive from Nineteenth-Century Sources
Selected by Jim Harter
Dover Publications, 1979.
0-486-23766-4
camel on pp. 59, image 241.
llama on pp. 60, image 242.
python on pp 178, image 800.
:)
oz
---
if you couldn't find any weirdness, maybe
we'll just have to make some! -- hobbes
Marc Spitzer wrote:
> Well you could go to Dover Press and not have to bother Tim, O'Reilly
> gets there cover art from Dover clipart.
Not all of it, by any means. They employ an artist to do new
animals for them. (I think her name is Lorrie Somethingorother;
the all-knowing Google will doubtless tell you more.)
--
Gareth McCaughan ················@pobox.com
.sig under construc
From: ozan s yigit
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <vi4bs5iwmwa.fsf@blue.cs.yorku.ca>
Charlton Wilbur:
> ... I would love to jump ship and find a job where I got new
> problems to solve on a regular basis, rather than solving the same old
> tired problem repeatedly, ...
become a large-installation sysadmin.
read burgess et al "Selected Papers" [1] for a large number of problems
people attacked in the past.
have fun. :)
oz
---
[1] Eric Anderson, Mark Burgess, Alva Couch (Eds)
Selected Papers in Network and System Administration
John Wiley & Sons, Jan 2002.
ISBN: 0470843853
--
if you do not work on important problems
how can you expect to do important work? -- richard w. hamming
From: Tim Bradshaw
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <ey3k7k1ig23.fsf@cley.com>
* ozan s yigit wrote:
> become a large-installation sysadmin.
I agree. System admin is one of the last bastions of smart, rational
people in IT (CL is another, at least sometimes). Large-systems admin
is particularly good. Of course, I would say that because it's klind
of what I do...
--tim
Tim Bradshaw <···@cley.com> wrote in ····················@cley.com:
> * ozan s yigit wrote:
>
>> become a large-installation sysadmin.
>
> I agree. System admin is one of the last bastions of smart, rational
> people in IT (CL is another, at least sometimes). Large-systems admin
> is particularly good. Of course, I would say that because it's klind
> of what I do...
>
> --tim
Well production SA's do not get the same lead time that programmers do. SA
mistakes generaly show up that day and in public. This provides us with
feedback, sometimes in the form of lynch mobs in suits. Another word for
this is motovation.
:)
marc
From: ozan s yigit
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <vi4smymskbp.fsf@blue.cs.yorku.ca>
Tim Bradshaw <···@cley.com> writes:
> > become a large-installation sysadmin.
>
> I agree. System admin is one of the last bastions of smart, rational
> people in IT (CL is another, at least sometimes). Large-systems admin
> is particularly good. Of course, I would say that because it's klind
> of what I do...
when i look at the current state of computing in large installations, all
i see is interesting and only partially solved problems (system admins are
famous for underestimating the complexity of the problems they solve) and
opportunities to do good computer science. [see the kind of work a friend
is doing[1] at university college oslo, for instance, and the related
book].
oz
--
[1] http://www.iu.hio.no/~mark/research/computing.html]
also: mark burgess
principles of network and system administration
john wiley and sons, 2000 0-471-82303-1
--
narrowness of imagination leads to narrowness of experience.
From: Tim Bradshaw
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <ey3r8e68vnq.fsf@cley.com>
* ozan s yigit wrote:
> when i look at the current state of computing in large
> installations, all i see is interesting and only partially solved
> problems
Well, yes. Do you see anything else when you look at *any*
engineering area? Areas with a high proportion of uninteresting
and/or solved problems tend not to be places where smart people want
to work.
--tim
ozan s yigit said the following on 10/31/2002 3:24 PM:
> (system admins are famous for underestimating the complexity of the
> problems they solve)
Hmmm. There are two reasons for this. Much sysadmin is done as signed
up member of the New Jersey school. Also, in my experience programmers
deploying code are famous for not understanding the differences
between the development, test and live environments and overestimating
the telepathic ability of sysadmins.
> ...and opportunities to do good computer science.
With the current state of the art, surely an oxymoron? Or perhaps
several...
;)w
From: Erik Naggum
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <3244550031398439@naggum.no>
* Charlton Wilbur
| my plan at this point is to get out as soon as possible.
You will not be the first. Many good people have left, already. Some
claim that all the really bright people have already left the IT industry.
| Cheap mediocrity coupled with buzzword-compliance always seems to win in
| the end.
Not on the end. When mediocrity takes over, it is because it can. Like,
if a herd of grazing animals got sick and could no longer outrun their
predators, even the most incompetent predator could catch some, but when
the herd was all eaten, the end result is that all but the best predators
die of starvation as the best predators would have gone elsewhere. The
sad part is that if this process takes too long, the best also get lazy.
--
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.
In an attempt to throw the authorities off his trail, Steven E. Harris <········@raytheon.com> transmitted:
> I prefer C++'s difficulty because intense attention to detail can
> ensure a safe and correct program, but with Java there's a higher
> level of non-beneficial abstraction (the VM) below which one cannot
> penetrate. If I write a seemingly-correct Java program and it doesn't
> perform properly, there is less I can do about it. (Or, maybe, I don't
> know the tools well enough to investigate and overcome problems with
> the libraries and VM.)
I quite like the notion of putting a long, sharp spike in the middle
of the steering column on automobiles.
This mandates that the driver apply intense attention to the details
of driving, as any mistake leading to rapid deceleration leads to the
spike being driven through the driver's skull, with attendant
likelihood of pain, injury, or even death.
Overly uncareful and aggressive drivers would thereby be removed from
the "gene pool" and the public roads, thereby assuring improved safety
for all those that remain.
Does that not sound like a wonderful idea?
--
(concatenate 'string "cbbrowne" ·@cbbrowne.com")
http://www.ntlug.org/~cbbrowne/rdbms.html
If you stand in the middle of a library and shout "Aaaaaaaaargh" at
the top of your voice, everyone just stares at you. If you do the same
thing on an aeroplane, why does everyone join in?
From: Erik Naggum
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <3243811256135660@naggum.no>
* Christopher Browne
| Does that not sound like a wonderful idea?
Is there a single problem that would not be solved by removing people?
--
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.
On 17 Oct 2002 02:40:56 +0000, ····@naggum.no said...
> * Christopher Browne
> | Does that not sound like a wonderful idea?
>
> Is there a single problem that would not be solved by removing people?
Underpopulation.
From: Vassil Nikolov
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <uu1jke1mw.fsf@poboxes.com>
On 17 Oct 2002 02:40:56 +0000, Erik Naggum <····@naggum.no> said:
EN> Is there a single problem that would not be solved by removing people?
Well, there's even a famous quote:
There is a man---there is a problem.
There is no man---there is no problem.
---Vassil.
--
Non-googlable is googlable.
Christopher Browne wrote in message ...
>In an attempt to throw the authorities off his trail, Steven E. Harris
<········@raytheon.com> transmitted:
>> I prefer C++'s difficulty because intense attention to detail can
>> ensure a safe and correct program, but with Java there's a higher
>> level of non-beneficial abstraction (the VM) below which one cannot
>> penetrate. If I write a seemingly-correct Java program and it doesn't
>> perform properly, there is less I can do about it. (Or, maybe, I don't
>> know the tools well enough to investigate and overcome problems with
>> the libraries and VM.)
>
>I quite like the notion of putting a long, sharp spike in the middle
>of the steering column on automobiles.
>
>This mandates that the driver apply intense attention ...
Thank you.I have never before been able to make out why I like hanging by
one finger from the front of the Uptown IRT Express as it hurtles from Times
Square to 72nd Street. Focuses the mind, I tell you, almost as good as the
prospect of getting shot at in two weeks.
k,c
Kenny Tilton <·······@nyc.rr.com> wrote:
> Thank you.I have never before been able to make out why I like hanging by
> one finger from the front of the Uptown IRT Express as it hurtles from Times
> Square to 72nd Street. Focuses the mind, I tell you, almost as good as the
> prospect of getting shot at in two weeks.
As opposed to one week?
Michael
--
Michael Sullivan
Business Card Express of CT Thermographers to the Trade
Cheshire, CT ·······@bcect.com
From: Steven E. Harris
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <87n0pcna8c.fsf@harris.sdo.us.ray.com>
Christopher Browne <········@acm.org> writes:
> Does that not sound like a wonderful idea?
Oh, you guys are having a blast with this one.
Let me try to restate the point. If everything in a system is made
"simple" and "easy" but it still doesn't work, one can't do anything
about it. If a system allows more under-the-hood tinkering, and one
encounters problems, one can delve deeper and perhaps effect
change. So long as my job depends upon me producing a working system,
I choose C++ over Java because with it I have greater control over my
success.
The preference is related more to the Not-Invented-Here syndrome than
to masochism.
--
Steven E. Harris :: ········@raytheon.com
Raytheon :: http://www.raytheon.com
From: Joe Marshall
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <y98y5h4h.fsf@ccs.neu.edu>
Erik Naggum <····@naggum.no> writes:
> * Thomas F. Burdick
> | Out of curiosity, have you used Java much?
>
> Not for production purposes. I do not think I will want to do that. I
> would rather hire cheap programmers who can write Java code than do it
> myself, but I actually believe it is a good language for its purposes and
> I have read a lot on Java. I want to program in Common Lisp, not Java,
> myself, but if I were to hire a bunch of people to get something done, I
> would want them to use something that was not braindamaged like C++ and
> which I could be reasonably sure was not all buggy like C programs are.
Comparing *anything* to C++ will give an artifically favorable
impression. I suspect that you would very quickly develop a much less
charitable opinion of Java if you had to write some production code in
it.
From: Erik Naggum
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <3243796050059484@naggum.no>
* Joe Marshall
| Comparing *anything* to C++ will give an artifically favorable
| impression.
This is unfair. If I want to make something, /anything/, look great, I
would take Perl, HTML, sendmail.cf, George W. Bush, Microsoft, etc, and
voil�! it is great. Since I have good friends (or at least one) who has
claimed quite strongly that C++ is not as bad as it was when I made a
serious effort to learn it back in 1993/4 and then made a serious effort
to build a second carreer as a writer just to make sure that if I should
be "forced" to program in C++, I would at least have a way out, I refuse
to go below "braindamaged" for C++. The other things listed above are
willfully evil and destructive. I want to say "well, at least it is not
braindamaged" instead of "well, at least it is not evil".
| I suspect that you would very quickly develop a much less charitable
| opinion of Java if you had to write some production code in it.
Part of the point with Java is that it is supposed to be a good language
for average programmers. I think most of its detractors forget that you
sometimes have to hire mediocre people. Just by watching our excellent
forum here, I have to conclude that if you are less than a great thinker,
you will only do serious damage in Common Lisp. The people who voice
their concerns here are probably /way/ above the average of those who are
likely to play with Common Lisp. I could perhaps hire the people who
have spent less than three months shedding their Scheme attitude, their
arrogance, their unwillingness to actually /learn/ something new, and
their unwillingness to work hard at making themselves better. But I have
no great hopes for the ability to hire a /bunch/ of people from some funny
farm with academic credentials. The crop of "computer scientists" these
days has been drawn from the middle of the Gauss curve, with so little
sign of excellence and real talent that it would simply be /wrong/ to base
an operation on intelligent, thinking, creative, /good/ programmers.
Java is the blue-collar programming language, much more successfully so
than C++, which had strong aspirations in that direction, but is much too
complex for its intended users. Java can only be judged on those terms,
and when you do that, two things become clear: If you are smarter than
the target audience, you will hate the language and miss an opportunity
to make use of the enormous number of lesser people who can be told what
to do and actually accomplish it, and if you are in the target audience,
it may be the first programming language that is actually intended to be
understood by your "grade" of people and all the educational material is
squarly directed at your group.
Furthermore, you can now determine if a university or vocational college
is going to produce brilliant or only educated average people by looking
at their choice in programming language. It used to be relatively stupid
languages like Pascal and relatively smart languages like Scheme, but now
we can know beforehand if they believe they can do something great with
any potentially brilliant student who decides to attend. If they choose
to base their education on Java, they will at best produce highly skilled
workers, not thinkers. But highly skilled programmers is much better
than poorly skilled thinkers. There are significant benefits to actually
having had to use a language for average programmers, even if you can do
much better, just as we force even bright kids through schools intended
to feed factories with average workers. This may sound brutal, but I have
yet to see any alternatives that have a significant chance of success.
/Really/ good people tend to "discover" Common Lisp quite independently
of their formal education, but my take on this is that you cannot acquire
the foundation to appreciate Common Lisp in today's programming world if
you have not gone through a lot of drudgery.
Also, if you can make do with average people, you should be /thrilled/!
It is a mark of maturity in an industry when average people can operate
tools and accomplish something. Java offers something important here.
If you want to solve really hard problems, get the really good people and
give them Common Lisp. They will be equally /thrilled/ to get away from
Java, if the sentiments here are accurate.
The only problem I can see is that people cannot get programming work
that is commensurate with their intelligence and skills. This, however,
is not Java's fault.
--
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.
From: Charlton Wilbur
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <87bs5izlnf.fsf@mithril.chromatico.net>
>>>>> "EN" == Erik Naggum <····@naggum.no> writes:
EN> The crop of "computer scientists" these days has been drawn
EN> from the middle of the Gauss curve, with so little sign of
EN> excellence and real talent that it would simply be /wrong/ to
EN> base an operation on intelligent, thinking, creative, /good/
EN> programmers.
EN> /Really/ good people tend to "discover" Common Lisp quite
EN> independently of their formal education, but my take on this
EN> is that you cannot acquire the foundation to appreciate Common
EN> Lisp in today's programming world if you have not gone through
EN> a lot of drudgery.
EN> The only problem I can see is that people cannot get
EN> programming work that is commensurate with their intelligence
EN> and skills. This, however, is not Java's fault.
The sad thing is, I'm an outlier in the Gauss curve. I *can't* find
work commensurate with my intelligence and skills, at least not
anywhere I have looked, and not in any quantity sufficient to support
myself, and I am bone-tired of the sort of relentless mediocrity that
the culture of Java encourages.
This is not to say that Java is a bad language; I think it's probably
one of the better languages in broad use today. But I've seen a team
of mediocre Java programmers take two man-years to do what I could do
myself in Perl in approximately two weeks; C probably would have taken
me closer to a month. (Yes, Erik, I know of your differences with
Perl. We differ on that; until I can work in LISP, Perl will simply
have to do.) How is it in any way wise for business to hire a team of
six Java-enabled consultants at double to triple what they're paying
me (considered hourly), and pay them for two-man years, instead of
paying me for a month? And then I get to support the broken Java code
and the broken Java application server on top of it all, and the
support costs of that are substantially higher than they would be for
a Perl- or C-based solution for this particular problem.
Mediocre programmers are mediocre programmers, regardless of the
language. Far, far better for business to hire intelligent people who
use efficient and powerful tools than to hire mediocrities who attack
all problems with Java -- especially because *this* non-mediocre
programmer is being driven out of the field entirely by boredom and
frustration. Create a culture favorable to mediocre people and
hostile to smart ones, and mediocre people will be the only ones who
can stand it.
Charlton
From: Erik Naggum
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <3244549553450379@naggum.no>
* Charlton Wilbur <·······@mithril.chromatico.net>
| How is it in any way wise for business to hire a team of six Java-enabled
| consultants at double to triple what they're paying me (considered
| hourly), and pay them for two-man years, instead of paying me for a
| month?
They can /find/ the six Java-enabled consultants with significantly less
energy than they would spend to find you. They can understand what the
Java people spend their time on. They can replace one of them at very
low marginal costs. They can replace all of them at very low cost. But
above all, mediocre people are much more managable then smart people.
| And then I get to support the broken Java code and the broken Java
| application server on top of it all, and the support costs of that are
| substantially higher than they would be for a Perl- or C-based solution
| for this particular problem.
Why not reimplement it, then? Show them your new and improved solution
and charge them a lot of money for /not/ needing expensive support on it.
| Mediocre programmers are mediocre programmers, regardless of the
| language. Far, far better for business to hire intelligent people who
| use efficient and powerful tools than to hire mediocrities who attack all
| problems with Java -- especially because *this* non-mediocre programmer
| is being driven out of the field entirely by boredom and frustration.
But it is not the other mediocre programmers who are at fault for this.
This is entirely and solely a managerial problem, and it is partly based
in the belief that programming is "risky" and hiring controllable people
will help reduce the risk. People buy insurance because they want to
lower their risks, and it is far from uncommon to choose paths that are
more expensive but safer than alternatives. You have to realize that a
manager needs to feel on top of things at all times and "trust me" does
not work as often as one would expect or hope. Being right is not enough
-- other people need to discover it and trust their findings, too.
| Create a culture favorable to mediocre people and hostile to smart ones,
| and mediocre people will be the only ones who can stand it.
This has already happened to the managers. Mediocre people are often
afraid of smart people. A smart manager is not afraid to hire someone
smarter than himself because his self-confidence is sufficiently stable
that he cannot suddenly feel like an inferior human being because he does
not grasp what his employees are doing.
It appears to me that once you get above a certain intelligence level,
like two standard deviations from the average, our society has done
enough to hone various aspects of your personality to be confident in
your ability to deal with a complex reality. I do not have any evidence
to suggest that this is "innate", but it does appear that the average
intelligence of human beings is much too low when we see how people are
utterly unable to deal with their own situation, and much less anything
bigger than their immediate personal needs. It is a miracle that smart
people got into sufficiently powerful positions that they could impose
the rule of law on the masses who would much prefer to take revenge on
whoever passes for scapegoat than achieve justice. Equally gigantic is
the invention of /history/ as a field of study, as opposed to myths and
heroic tales, where the facts of historic events was considered superior
to the moronic "the winner writes the history" myth-spinning nonsense
that conflated "story" and "history". Our modern times have apparently
evolved faster than the average in human intelligence has evolved with
it, because now history is replaced by political correctness and facts by
marketing and propaganda, mistakes of the past are no longer there to be
studied and learned from, they are to be denied. All this suggests that
the mediocre have regained the power they had in pre-civilized times,
before rule of law, history, and science, where the need to "feel good
now" is vastly more important than improving your condition.
The above should suggest that I think the Revenge of Mediocrity is upon
us, that the day of philosophers and thinkers and the really intelligent
is basically over. From the election of George W. Bush (which heralded
the end of the United States and its dominant role in world politics) to
the anti-technological, anti-intelligence, anti-science, anti-prosperity
crap about global warming being our fault, the mediocre have gained so
much power that anyone who would be have the mental wherewithal to go
against the majority viewpoint to do something that would really improve
the human condition (like the bravery of the real statesmen who fought to
abolish slavery in the United States and who are now all but destroyed by
the idiots who want reparations for the slavery that the people they want
the reparations from fought to abolish) would never achieve that power,
and if they did, the majority would successfully fight them.
Our entire Western culture /is/ favorable to mediocre people and hostile
to smart ones. The worst aspect of anti-intelligence is mass marketing,
which has driven the most anti-intellectual of all aspects of human
existence: the entertainment industry, especially TV, which makes people
lose concentration on their work so they can rush home and watch TV and
which gives people who want to avoid work a reason to bask in laziness.
Why should running businesses or programming computers be any different?
The Western hemisphere will not recover from its current problems until
it destroys the notion that marketing must be a push technology. The
Internet may in fact be the facilitator for a cultural change that rivals
the industrial revolution in magnitude for human existence, by /undoing/
the damage that has been done to our world by pushing mass marketing on
people. The transition from push to pull marketing has already started,
but it will take many years to produce the ground-breaking results I
expect it to have, and it will require massive resources to do it, but
people are already fed up with push marketing and those who work with
pull marketing technology have already made significant inroads into the
traditional push markets -- one particular area that has seen so much
change that newspapers suffer greatly, is job ads, where Internet-based
job-matching services are so much more efficient and cost-effective.
When the end of push marketing comes -- it should take less than 20 years
from now -- it will have transformed our culture like nothing else in
recent memory, and society will no longer be so heavily optimized for the
average but will allow niches to work for individual needs both well
below and well above average and we will see life change from demanding
the same results for everyone (a desire that is a direct result of mass
marketing that has only resulted in everybody being unhappy) to actually
fulfilling real needs, which are already so diverse that the mass market
is unable to fulfill all the real needs of /anyone/ in particular.
It may be too late for many of us, but I believe those who want to get a
taste of the future must jump off the mass-marketing bandwagon that got
us the prosperity we have today and which enables us to get even richer
with pull technology. Powerful computers running powerful software will
be the cornerstone of the pull marketing strategy. The software needed
to build and run this new and better world cannot be written by mediocre
people today because the mediocre can only solve already solved problems.
The really smart can yet stop the Revenge of Mediocrity from destroying
human civilization by reverting to short-range, non-thinking brutality.
--
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.
From: Thien-Thi Nguyen
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <kk9hefauztw.fsf@glug.org>
Erik Naggum <····@naggum.no> writes:
> The really smart can yet stop the Revenge of Mediocrity from
> destroying human civilization by reverting to short-range,
> non-thinking brutality.
i find this sentence ambiguous. please clarify: who is to
promulgate this brutality, the mediocre or the would-be really
smart? the former is consistent w/ the rest of the post, but the
latter is indicated given normal binding patterns for "by".
thi
From: Erik Naggum
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <3244563919110042@naggum.no>
* Erik Naggum
| The really smart can yet stop the Revenge of Mediocrity from
| destroying human civilization by reverting to short-range,
| non-thinking brutality.
* Thien-Thi Nguyen
| i find this sentence ambiguous. please clarify: who is to promulgate
| this brutality, the mediocre or the would-be really smart? the former is
| consistent w/ the rest of the post, but the latter is indicated given
| normal binding patterns for "by".
Strange. It is self-contradictory when it is read as "stop by", and does
have pretty clear meaning when it is read as "destroy by". Yes, it is
ambiguous the same way "time flies like a banana" is, but if you already
noted the consistency part, what could have been ambiguous? Is it
because the Revenge of Mediocrity is not an agent in your view that you
think actions can be taken only by the really smart, which obviously are
an agent? Would it have changed meaning in your eyes if it had been "the
Revenge of the Mediocre", like that expression went when it was written
but before editing and posting?
--
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.
From: Thien-Thi Nguyen
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <kk9adl2uv2n.fsf@glug.org>
Erik Naggum <····@naggum.no> writes:
> but if you already noted the consistency part, what could have
> been ambiguous?
sometimes to counter a force you can use the force "in kind". if
medocrity results in unthinking brutality, unthinking brutality is
perhaps a tactic useful to counter mediocrity. civilization is
not destroyed by this, but only by mis-application of this. (it
is possible to be excellent and unthinkingly brutal all at once,
to the benefit of civilization, basically.)
> Is it because the Revenge of Mediocrity is not an agent in
> your view that you think actions can be taken only by the
> really smart, which obviously are an agent? Would it have
> changed meaning in your eyes if it had been "the Revenge of
> the Mediocre", like that expression went when it was written
> but before editing and posting?
no. noun-phrase construction variance is within my understanding
of human expression, usually.
thi
From: Jason Kantz
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <wk7kg1xn5q.fsf@kantz.com>
Erik Naggum <····@naggum.no> writes:
> * Charlton Wilbur <·······@mithril.chromatico.net>
> | How is it in any way wise for business to hire a team of six Java-enabled
> | consultants at double to triple what they're paying me (considered
> whoever passes for scapegoat than achieve justice. Equally gigantic is
> the invention of /history/ as a field of study, as opposed to myths and
> heroic tales, where the facts of historic events was considered superior
> to the moronic "the winner writes the history" myth-spinning nonsense
> that conflated "story" and "history". Our modern times have apparently
speaking of myth-spun history ...
http://www.washingtontimes.com/national/20021028-78905499.htm
From: Thien-Thi Nguyen
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <kk9k7k6v0fn.fsf@glug.org>
Charlton Wilbur <·······@mithril.chromatico.net> writes:
> Create a culture favorable to mediocre people and hostile to
> smart ones, and mediocre people will be the only ones who can
> stand it.
i think this follows from the peter principle.
your quest, then, is to become a boss w/ clue
(and hire some lisp programmers, thanks in advance)
in order to aim for the jugular (see "generalized
peter principle").
thi
On Fri, 25 Oct 2002, Charlton Wilbur wrote:
> The sad thing is, I'm an outlier in the Gauss curve. I *can't* find
> work commensurate with my intelligence and skills, at least not
> anywhere I have looked, and not in any quantity sufficient to support
> myself, and I am bone-tired of the sort of relentless mediocrity that
> the culture of Java encourages.
That's why they _pay_ you: Because you wouldn't do it otherwise.
Now there's no reason why you should LIKE that state of affairs. And you
may well not be paid as much as you like. Welcome to Planet Earth!
Have you ever been a janitor? (I mean a real janitor, not a "systems
janitor" as we call ourselves here ;). Have you ever worked in a
fast-food "kitchen"? Have you ever worked at a punch-press or other
industrial machinery? Probably not. Because if you had, you'd understand
why half the human race would murder in order to have a job like the ones
you reject.
It's a sad state of affairs, but it will take something more than
replacing Java with Language-X to fix it (substitute lisp, Prolog, C++,
Eiffel, Python, whateveryoulike....for X).
> Charlton
* Nick Geovanis
| IT Computing Svcs Computing's central challenge:
| Northwestern Univ How not to make a mess of it.
| ··········@nwu.edu -- Edsger Dijkstra
+------------------->
Charlton Wilbur <·······@mithril.chromatico.net> wrote in message news:<··············@mithril.chromatico.net>...
> The sad thing is, I'm an outlier in the Gauss curve. I *can't* find
> work commensurate with my intelligence and skills, at least not
> anywhere I have looked, and not in any quantity sufficient to support
> myself, and I am bone-tired of the sort of relentless mediocrity that
> the culture of Java encourages.
Are you allowed to use Jython?
Greg Neumann
From: Hannah Schroeter
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <apmds6$srs$2@c3po.schlund.de>
Hello!
Erik Naggum <····@naggum.no> wrote:
>[...]
> On that tangent, it is probably the lack of commitment and follow-through
> that bothers me with the "free" software, and nobody can take it and make
> a serious buck on improving it to be fully polished products because they
> /have/ to "share" their changes.
This is not completely right. There's in fact quite some free software
with liberal licences like MIT, X11, BSD style. So at least they allow
to have commercial derivatives, and if those have significant advantages
over the free sources, that could even be worthwhile in some cases.
>[...]
Kind regards,
Hannah.
······@schlund.de (Hannah Schroeter) wrote in
·················@c3po.schlund.de:
> Hello!
>
> Erik Naggum <····@naggum.no> wrote:
>>[...]
>
>> On that tangent, it is probably the lack of commitment and
>> follow-through that bothers me with the "free" software, and nobody
>> can take it and make a serious buck on improving it to be fully
>> polished products because they /have/ to "share" their changes.
>
> This is not completely right. There's in fact quite some free software
> with liberal licences like MIT, X11, BSD style. So at least they allow
> to have commercial derivatives, and if those have significant
> advantages over the free sources, that could even be worthwhile in
> some cases.
I do not think they were included in the "free" (not free, no quotes) Erik
was talking about. I read it to mean gpl and its fellows. You can make a
product out of cmucl but not out of clisp, because with cmucl you can keep
your code private. The only way I can think of to get around gpl issuse,
other then the patent mess, is to add a clause in the sales contract that
the customer agrees never to request the source of the product. I have no
idea if it would hold up in court though.
Yes I know about GNAT, but they are a service company not a product
company, from what I hav read on comp.lang.ada.
marc
From: Peter Seibel
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
Date:
Message-ID: <m3y98g1ipu.fsf@localhost.localdomain>
Marc Spitzer <········@optonline.net> writes:
> The only way I can think of to get around gpl issuse, other then the
> patent mess, is to add a clause in the sales contract that the
> customer agrees never to request the source of the product. I have
> no idea if it would hold up in court though.
Er, if I understand you correctly, you're suggesting that you could
distribute code that was GPL'd to someone under a contract in which
they agree not to request the source. I'm pretty sure this would
violate clause 6 of the GPL:
6. Each time you redistribute the Program (or any work based on the
Program), the recipient automatically receives a license from the
original licensor to copy, distribute or modify the Program subject
to these terms and conditions. You may not impose any further
restrictions on the recipients' exercise of the rights granted
herein. You are not responsible for enforcing compliance by third
parties to this License.
That is the clause in the contract that prohibts requesting the source
would be a "further restriction". Once you violate the GPL you would
have no right to redistribute the code. Unless you are the copyright
holder, in which case you can distribute it however you wanted without
the GPL coming into play.
-Peter
--
Peter Seibel
·····@javamonkey.com
Peter Seibel <·····@javamonkey.com> wrote in
···················@localhost.localdomain:
> Marc Spitzer <········@optonline.net> writes:
>
>> The only way I can think of to get around gpl issuse, other then the
>> patent mess, is to add a clause in the sales contract that the
>> customer agrees never to request the source of the product. I have
>> no idea if it would hold up in court though.
>
> Er, if I understand you correctly, you're suggesting that you could
> distribute code that was GPL'd to someone under a contract in which
> they agree not to request the source. I'm pretty sure this would
> violate clause 6 of the GPL:
drat foiled again.
marc
Erik Naggum <····@naggum.no> wrote in message news:<················@naggum.no>...
> Please remove some of your attitude and listen a little more.
Hmm yes, I wrote a response to Adam that has yet to be posted by
googlegroups, where I probably was mitigating some of his points which
were actually strong. But I got the impression he clinically wanted
to know what my impressions were.
In fact, maybe the biggest thing that CLers see is "mitigation." Most
people say, "Well, Guile at least ain't TCL!" which is probably the
scripting alternative to Guile.
From your tone about Free Software, I assume that people already tried
integrating CL well into Emacs... I hear that esr actually called Gnu
a cathedral of development instead of a bazaar, so no doubt there is
much to be disenchanted with Emacs development. I'll look into that.
Greg Neumann
From: Erik Naggum
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <3243712400608096@naggum.no>
* Greg Neumann
| From your tone about Free Software, I assume that people already tried
| integrating CL well into Emacs...
The one really useful thing about the Net is that you can ask people
questions and not have to assume based on "tone" and other factors. Many
still behave as if Usenet consisted of published papers where the author
had gone fishing. Do not guess. Do not assume. Think and ask. Listen
and learn. Voice your concerns directly. It takes too much time to read
news already if one shall not also have to counter-act assumptions and
all kinds of weird guesses based on feelings and tones. This may be a
virtual reality of sorts, but it still consists only of what we verbalize.
| I hear that esr actually called Gnu a cathedral of development instead of
| a bazaar, so no doubt there is much to be disenchanted with Emacs
| development. I'll look into that.
FWIW, you should find my name on a large number of changelog entries and
some packages. I sort of dropped out when MULE was dropped on the feet
of all the Emacs developers. Many other long-time developers found that
they had a very limited taste for the MULE team's doing and especially
the undoing of previously working support for 8-bit character sets. The
MULE team was sufficiently incompetent and destructive that I published a
"multibyte survival kit" for Emacs 20.2. RedHat distributed it, but I
think it was a sufficiently strong eye-opener that many problems got
fixed. That was, in effect, a threat of secession and split based on the
ill will and incompetence of a team that was widely believed to think
that only the Japanese way to large character sets would work. To this
day, the MULE-based Emacs really, really sucks at Unicode support. I
have quit working with Emacs entirely and only use it, but what pushed me
to this conclusion was the rank arrogance of the incompetent Japanese
team. I had worked with character sets in ISO since before Unicode, but
was met with what would probably be perceived as polite, but amazingly
arrogant Japanese know-it-alls who probably did not understand English
well enough to grasp what people were talking about, but too afraid to
show their incompetence by asking questions, instead destroyed years of
effort to make Emacs work well in Europe, too. It was an interesting
experience in international cooperation and politics. It shall be fun to
see if they ever manage to make Emacs truly Unicode-conformant and able
to accept input from X with its rich support for many character sets.
Emacs 21.2 is still, amazingly, unable to understand most X events that
other "modern" X applications accept without problems, including a UTF-8-
enabled xterm. There is, in my experienced view, not much hope for any
/real/ improvements to Emacs unless they get rid of much braindamage,
both people and code.
I also wanted to build a Common Lisp-based Emacs and still have the
domain name "clemacs.org", but found that after a couple months of
spare-time work on it that the sheer amount of duplication of effort was
going to kill the project before it was born, so I aborted the mission.
None of the free Common Lisp were up to the task, either, by the way.
--
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.
From: Johannes Grødem
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <lzsmz7da1f.fsf@unity.copyleft.no>
* Erik Naggum <····@naggum.no>:
> Wrong. The illusion of freedom with supposedly free software is blinding
> to people who have never tried to make use of it.
I'm sorry, do you mean the illusion of freedom with GPLed free
software? You wouldn't say that CMUCL isn't free, would you?
(Still free as in freedom, not in cost.) Or is there something I'm
not getting here?
--
Johannes Gr�dem <OpenPGP: 5055654C>
From: Will Deakin
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <aohe8e$9js$1@knossos.btinternet.com>
Johannes Gr�dem wrote:
> You wouldn't say that CMUCL isn't free, would you?
Before making statments like this it might be useful look carefully at
the cmucl license.
> Or is there something I'm not getting here?
Yes.
From: Mario S. Mommer
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <fzu1jnu18d.fsf@cupid.igpm.rwth-aachen.de>
Will Deakin <···········@hotmail.com> writes:
> Johannes Gr�dem wrote:
> > You wouldn't say that CMUCL isn't free, would you?
> Before making statments like this it might be useful look carefully at
> the cmucl license.
From the manual:
public domain: free, with full source code and no strings attached
(and no warranty).
> > Or is there something I'm not getting here?
> Yes.
I don't get it either.
Mario S. Mommer
From: Will Deakin
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <aohfnn$78s$1@paris.btinternet.com>
To restate the case:
Johannes Gr�dem wrote:
> I'm sorry, do you mean the illusion of freedom with GPLed free
> software? You wouldn't say that CMUCL isn't free...
Mario S. Mommer wrote:
> From the [cmucl] manual:
> public domain: free, with full source code and no strings attached
> (and no warranty).
My point exactly. There is a yawning chasm between cmucl and GPL.
:)w
From: Johannes Grødem
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <lzit03cwpw.fsf@unity.copyleft.no>
* Will Deakin <···········@hotmail.com>:
>> public domain: free, with full source code and no strings attached
>> (and no warranty).
> My point exactly. There is a yawning chasm between cmucl and GPL.
Incidentally, this was also my point exactly. (But when I look at my
message, I realize that it was unclear. My mistake.)
--
Johannes Gr�dem <OpenPGP: 5055654C>
From: Erik Naggum
Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)
Date:
Message-ID: <3243697916240853@naggum.no>
* Erik Naggum
| Wrong. The illusion of freedom with supposedly free software is blinding
| to people who have never tried to make use of it.
* Johannes Gr�dem
| I'm sorry, do you mean the illusion of freedom with GPLed free software?
GPLed software is only supposedly free. When objects are supposedly
free, people are actually not.
| You wouldn't say that CMUCL isn't free, would you?
CMUCL is actually free.
--
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.
Hi Greg Neumann,
>> I was dumbfounded that Richard Stallman himself was advocating using a
>> Scheme interpreter instead of Lisp.
>
> All the guile/emacs projects make it clear that there'll be backwards
> compatability, because they're not suicidal.
>
> No doubt CL is a better technical choice, but scheme has a lower
> learning-curve initially. Maybe RMS wants to compete against the Dr.
> Scheme folks...
How can Scheme have a lower learning curve when it forces you to learn
many of its idiosyncrasies straight away?
I discovered Scheme shortly before ANSI Common Lisp and found I was
fighting it at every turn. Why can't I use a variable named list? Why do I
need to use the apparently redundant keyword lambda in every function
definition? Why do I have to fake iteration using recursion? Why aren't
the most elementary constructs built into the language? Does it have to be
this slow? Why does this only feel suitable for scripting?
It soon became apparent that I was fighting the Scheme ethos of conceptual
elegance and simplicity. To put it a less polite way you dump most of the
work onto the programmer and let them deal with all the inconsistencies
between implementations.
To a schemer this may be amusing:
http://schemers.org/Documents/FAQ/#d0e96
It is much smaller than Common Lisp; the language specification is
about 50 pages, compared to Common Lisp's 1300 page draft standard.
Advocates of Scheme often find it amusing that the entire Scheme
standard is shorter than the index to Guy Steele's “Common Lisp: the
Language, 2nd Edition”. Unlike the Scheme standard, the Common Lisp
standard has a large library of utility functions, a standard
object-oriented programming facility (CLOS), and a sophisticated
condition handling system.
(Comparing the size of the Scheme specification with the ANSI CL Loop
specification may also provide amusement).
So much has been left out of the Scheme specification that you cannot even
rely upon an implementation to evaluate arguments from left to right:
http://groups.google.co.nz/groups?selm=uk8j4xp8e.fsf%40alum.mit.edu
ARRRGGGHHH!!! I've been caught by a newbie error!
I did make the effort to at least *try* the code I posted, and it
worked just as I said it did, on MIT Scheme.
What's the difference? MzScheme evaluates left-to-right and MIT Scheme
evaluates right-to-left.
This is the kind of error that that even professions shouldn't need to
avoid when attempting to create portable code. Plus there is no standard
package specification for building large projects without naming
conflicts.
What this amounts to is that Guile Scheme cannot possibly solve the
problem of replacing Emacs Lisp with a less idiosyncratic implementation.
You will end up having to know the idiosyncrasies of a particular Scheme
implementation just like currently happens with Emacs Lisp.
It's a squandered opportunity to extend Emacs in a way that would allow
people to apply their learning of a well specified standard directly to
Emacs, regardless of the particular ANSI Common Lisp implementation that
programmers use.
Regards,
Adam
"Adam Warner" <······@consulting.net.nz> wrote in message
···································@consulting.net.nz...
> I discovered Scheme shortly before ANSI Common Lisp and found I was
> fighting it at every turn. Why can't I use a variable named list? Why do I
> need to use the apparently redundant keyword lambda in every function
> definition? Why do I have to fake iteration using recursion?
For the sake of accuracy, I should point out that all three of these are
false.
1. You can rebind/redefine the identifier 'list' to mean whatever you want
it to, you simply can't, within the scope of that binding, refer to the
predefined 'list' by its original name.
This might seem like quibbling, but the next two points are not
quibbling.
The original points are solidly false.
2. There is no need to use 'lambda' in function definitions. See section 5.2
of r5rs.
3. There is a built-in iteration syntax in scheme: 'do'. See section 4.2.4
of r5rs.
-James Russell
Hi J L Russell,
> "Adam Warner" <······@consulting.net.nz> wrote in message
> ···································@consulting.net.nz...
>> I discovered Scheme shortly before ANSI Common Lisp and found I was
>> fighting it at every turn. Why can't I use a variable named list? Why
>> do I need to use the apparently redundant keyword lambda in every
>> function definition? Why do I have to fake iteration using recursion?
The complete list was my impressions as a newbie to Scheme. Your
clarifications are helpful.
> For the sake of accuracy, I should point out that all three of these are
> false.
> 1. You can rebind/redefine the identifier 'list' to mean whatever you
> want it to, you simply can't, within the scope of that binding, refer to
> the predefined 'list' by its original name. This might seem like
> quibbling, but the next two points are not quibbling.
Yes it's quibbling because you cannot use the essential function list
(which almost certainly has no place being redefined) at the same time.
The response was directed to Greg who seems to believe that Scheme is
easier to learn than Lisp. The fact that any newbie who creates a symbol
called list will soon discover that their code breaks is a reason that
Scheme isn't easier to learn.
I'm at two minds about multiple namespaces: While it allows greater
expressiveness and it helps to futureproof code against specification
expansion (because future function names won't sit badly with current
variables using the same name) parsing the code seems harder. You have to
understand the forms being used to determine which namespace is being
accessed.
> 2. There is no need to use 'lambda' in function definitions. See section
> 5.2 of r5rs.
http://www.swiss.ai.mit.edu/~jaffer/r5rs_7.html#SEC44
(define (<variable> <formals>) <body>) <Formals> should be either a
sequence of zero or more variables, or a sequence of one or more
variables followed by a space-delimited period and another variable (as
in a lambda expression). This form is equivalent to
(define <variable>
(lambda (<formals>) <body>)).
Ah, so this syntax trick is the way to distinguish between a function
definition and a variable definition. So Scheme does have two different
definition mechanisms: (define (<variable> <formals>) <body>)
could have been expressed as (defun <variable> (<formals>) <body>).
> 3. There is a built-in iteration syntax in scheme: 'do'. See section
> 4.2.4 of r5rs.
Thanks. I'm guilty as charged:
http://www.swiss.ai.mit.edu/~jaffer/r5rs_6.html#SEC36
(let ((x '(1 3 5 7 9)))
(do ((x x (cdr x))
(sum 0 (+ sum (car x))))
((null? x) sum)))
I was thinking of something along the lines of:
(loop for x in '(1 3 5 7 9) sum x)
Regards,
Adam