From: Janosch Zwerensky
Subject: Beginner question: performance problems with a simple program
Date:
Message-ID: <a0cc4p$u16$03$1@news.t-online.com>
Hi all,
I've just started learning Common Lisp and as a simple exercise of what I've
learned so far I thought I might write a program that allows one to play around
a bit with Collatz sequences.
I thus produced the following program:
(defun coll-step (n)
(if (= (mod n 2) 0) (/ n 2) (+ 1 (* 3 n))))
(defun coll-max (n)
"Computes the maximum of the collatz sequence starting with its argument"
(coll-max-iter n n n))
(defun coll-max-iter (n a b)
(if (< n a) b (coll-max-iter (coll-step n) a (max b n))))
(defun max-lst (n)
"prints out all n up to its argument which have the property that
coll-max(m)>=coll-max(n) ==> m >= n"
(max-lst-iter 3 n (coll-max 3)))
(defun max-lst-iter (n range mx)
(if (> n range) mx
(max-lst-iter (+ n 4) range (next n (coll-max n) mx))))
(defun next (n am mx)
(if (> am mx) (toscreen n am) mx))
(defun toscreen (n am)
(write (list n am))
am)
The program works fine, except for the fact that I am not feeling well about
its performance speed-wise. Does anyone on this group have any tips to offer
regarding improvements in this respect? (I am working with Allegro Common
Lisp).
Regards,
Janosch.
From: Barry Margolin
Subject: Re: Beginner question: performance problems with a simple program
Date:
Message-ID: <CemW7.6$Mv6.27810@burlma1-snr2>
In article <···············@news.t-online.com>,
Janosch Zwerensky <·········@nahoo.de> wrote:
>Hi all,
>
>I've just started learning Common Lisp and as a simple exercise of what I've
>learned so far I thought I might write a program that allows one to play around
>a bit with Collatz sequences.
>I thus produced the following program:
>
>(defun coll-step (n)
> (if (= (mod n 2) 0) (/ n 2) (+ 1 (* 3 n))))
Why not use EVENP here?
>The program works fine, except for the fact that I am not feeling well about
>its performance speed-wise. Does anyone on this group have any tips to offer
>regarding improvements in this respect? (I am working with Allegro Common
>Lisp).
Did you remember to compile it?
--
Barry Margolin, ······@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
From: Janosch Zwerensky
Subject: Re: Beginner question: performance problems with a simple program
Date:
Message-ID: <a0dgeb$cga$07$1@news.t-online.com>
Hi,
>>(defun coll-step (n)
>> (if (= (mod n 2) 0) (/ n 2) (+ 1 (* 3 n))))
>
>Why not use EVENP here?
Using evenp here doesn't hurt nor help, performancewise, here. I agree though
that evenp looks more natural.
>Did you remember to compile it?
Of course I did. I might have little experience with lisp so far, but I am not
stupid. Still, the program seems to be around 10 times slower than an
algorithmically equivalent C program, which is a larger speed loss than what I
would have expected just from Lisp doing BigInteger arithmetics vs. the long
long int calculations one does in C.
Regards,
Janosch.
From: Barry Margolin
Subject: Re: Beginner question: performance problems with a simple program
Date:
Message-ID: <36sW7.19$Mv6.41773@burlma1-snr2>
In article <···············@news.t-online.com>,
Janosch Zwerensky <·········@nahoo.de> wrote:
>Hi,
>
>>>(defun coll-step (n)
>>> (if (= (mod n 2) 0) (/ n 2) (+ 1 (* 3 n))))
>>
>>Why not use EVENP here?
>
>Using evenp here doesn't hurt nor help, performancewise, here. I agree though
>that evenp looks more natural.
I didn't think it would, it was just a style comment.
>>Did you remember to compile it?
>
>Of course I did. I might have little experience with lisp so far, but I am not
>stupid.
I never said you were. There have been plenty of times when people posted
questions about performance and it turned out that they weren't compiling,
so most of the problem was in the interpreter's overhead. It's not
stupidity, just inexperience.
> Still, the program seems to be around 10 times slower than an
>algorithmically equivalent C program, which is a larger speed loss than what I
>would have expected just from Lisp doing BigInteger arithmetics vs. the long
>long int calculations one does in C.
Declarations can often help with heavily numeric code. Without them, lots
of runtime type dispatching has to take place. Although if you can't limit
your numbers to fixnums, it may still have to do type checks to switch
between fixnum and bignum versions of functions.
Try using the TIME macro to see if you're consing alot. If your Lisp
implementation has a profiling feature, try using that to see where the
bottleneck is.
--
Barry Margolin, ······@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
What's the opposite of a flame? Barry Margolin once again demonstrates how
to post respectfully & irenically. Thanks, Barry for your fine example.
Will Fitzgerald
"Barry Margolin" <······@genuity.net> wrote in message
·······················@burlma1-snr2...
> In article <···············@news.t-online.com>,
> Janosch Zwerensky <·········@nahoo.de> wrote:
> >Hi,
> >
> >>>(defun coll-step (n)
> >>> (if (= (mod n 2) 0) (/ n 2) (+ 1 (* 3 n))))
> >>
> >>Why not use EVENP here?
> >
> >Using evenp here doesn't hurt nor help, performancewise, here. I agree
though
> >that evenp looks more natural.
>
> I didn't think it would, it was just a style comment.
>
> >>Did you remember to compile it?
> >
> >Of course I did. I might have little experience with lisp so far, but I
am not
> >stupid.
>
> I never said you were. There have been plenty of times when people posted
> questions about performance and it turned out that they weren't compiling,
> so most of the problem was in the interpreter's overhead. It's not
> stupidity, just inexperience.
>
> > Still, the program seems to be around 10 times slower than an
> >algorithmically equivalent C program, which is a larger speed loss than
what I
> >would have expected just from Lisp doing BigInteger arithmetics vs. the
long
> >long int calculations one does in C.
>
> Declarations can often help with heavily numeric code. Without them, lots
> of runtime type dispatching has to take place. Although if you can't
limit
> your numbers to fixnums, it may still have to do type checks to switch
> between fixnum and bignum versions of functions.
>
> Try using the TIME macro to see if you're consing alot. If your Lisp
> implementation has a profiling feature, try using that to see where the
> bottleneck is.
>
> --
> Barry Margolin, ······@genuity.net
> Genuity, Woburn, MA
> *** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to
newsgroups.
> Please DON'T copy followups to me -- I'll assume it wasn't posted to the
group.
From: David Sletten
Subject: Re: Beginner question: performance problems with a simple program
Date:
Message-ID: <3C2A9BB6.30705@home.com>
Will Fitzgerald wrote:
> What's the opposite of a flame? Barry Margolin once again demonstrates how
> to post respectfully & irenically. Thanks, Barry for your fine example.
>
> Will Fitzgerald
>
Would that be a 'douse'? Or is it 'Preparation H' to prevent a
hemorrhoid from flaring up?
David Sletten
From: Janosch Zwerensky
Subject: Re: Beginner question: performance problems with a simple program
Date:
Message-ID: <a0epu6$g81$04$1@news.t-online.com>
Hi,
>(...) There have been plenty of times when people posted
>questions about performance and it turned out that they weren't compiling,
>so most of the problem was in the interpreter's overhead.
Ok, I didn't know that.
Call it, uhm, inexperience regarding this newsgroup ;).
>
>> Still, the program seems to be around 10 times slower than an
>>algorithmically equivalent C program, which is a larger speed loss than what
I
>>would have expected just from Lisp doing BigInteger arithmetics vs. the long
>>long int calculations one does in C.
>
>Declarations can often help with heavily numeric code.
I know this, since I have done programming in Scheme before.
I assume, then, that I can't do much about the performance of my program if
Lisp doesn't have a number type that suits my problem better than general
bignums (it is my understanding that this was the case in MIT-Scheme)?
>(...) Although if you can't limit
>your numbers to fixnums,
Exactly my problem :(.
> it may still have to do type checks to switch
>between fixnum and bignum versions of functions.
>
>Try using the TIME macro to see if you're consing alot. If your Lisp
>implementation has a profiling feature, try using that to see where the
>bottleneck is.
I think I know where the bottleneck is anyway, but I'll nonetheless follow that
advice.
Regards,
Janosch.
·········@nahoo.de (Janosch Zwerensky) writes:
> Hi,
>
> >(...) There have been plenty of times when people posted
> >questions about performance and it turned out that they weren't compiling,
> >so most of the problem was in the interpreter's overhead.
>
> Ok, I didn't know that.
> Call it, uhm, inexperience regarding this newsgroup ;).
>
> >
> >> Still, the program seems to be around 10 times slower than
> >>an algorithmically equivalent C program, which is a larger speed
> >>loss than what I would have expected just from Lisp doing
> >>BigInteger arithmetics vs. the long long int calculations one does
> >>in C.
> >
> >Declarations can often help with heavily numeric code.
>
> I know this, since I have done programming in Scheme before.
I don't remember Scheme having declarations.
> I assume, then, that I can't do much about the performance of my program if
> Lisp doesn't have a number type that suits my problem better than general
> bignums (it is my understanding that this was the case in MIT-Scheme)?
>
> >(...) Although if you can't limit
> >your numbers to fixnums,
>
> Exactly my problem :(.
If your calculation can be done without using a bignum-like facility
in your machine's assembly language, your Lisp implementation may be
able to do it without bignums. This is very implementation-dependant,
but then optimizing numerics is in any language. long long ints are
64-bit integers, right? Using block compilation, you should be able
to do what you want using CMUCL, I think. It might need some messing
with the compiler, but I think you should be able to do what you want
without bignums.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: Janosch Zwerensky
Subject: Re: Beginner question: performance problems with a simple program
Date:
Message-ID: <a0hrca$3ku$02$1@news.t-online.com>
>I don't remember Scheme having declarations.
MIT-Scheme allows one to declare a few things, although it isn't comparable to
CL in that respect. It does have, however, specialized operations for fixnums,
the use of which of course leads to big speedups when possible.
Regards,
Janosch
In article <···············@news.t-online.com>, Janosch Zwerensky wrote:
>
>>I don't remember Scheme having declarations.
>
>MIT-Scheme allows one to declare a few things, although it isn't comparable to
>CL in that respect. It does have, however, specialized operations for fixnums,
MIT Scheme is not comparable to CL because it is an *implementation*,
whereas CL is an internationally standardized programming *language*.
From: ········@cc.hut.fi
Subject: Re: Beginner question: performance problems with a simple program
Date:
Message-ID: <m3vgenpr9t.fsf@mu.nonexistent>
···@ashi.footprints.net (Kaz Kylheku) writes:
> MIT Scheme is not comparable to CL because it is an *implementation*,
> whereas CL is an internationally standardized programming *language*.
Is CL actually standardized internationally, or only in the USA?
Hannu
From: Lieven Marchand
Subject: Re: Beginner question: performance problems with a simple program
Date:
Message-ID: <m3u1u7pd8w.fsf@localhost.localdomain>
········@cc.hut.fi writes:
> ···@ashi.footprints.net (Kaz Kylheku) writes:
>
> > MIT Scheme is not comparable to CL because it is an *implementation*,
> > whereas CL is an internationally standardized programming *language*.
>
> Is CL actually standardized internationally, or only in the USA?
Common Lisp is an ANSI standard. There is an ISO standard for another
language in the lisp family, ISLISP.
--
Lieven Marchand <···@wyrd.be>
She says, "Honey, you're a Bastard of great proportion."
He says, "Darling, I plead guilty to that sin."
Cowboy Junkies -- A few simple words
········@cc.hut.fi writes:
> ···@ashi.footprints.net (Kaz Kylheku) writes:
>
> > MIT Scheme is not comparable to CL because it is an *implementation*,
> > whereas CL is an internationally standardized programming *language*.
>
> Is CL actually standardized internationally, or only in the USA?
It is an American National Standard. There is an international Lisp
standard, which is ISO ISLISP, but it's not code-compatible and its
deployment is comparatively tiny. ANSI CL is _sold_ world-wide,
though. Is there a reason that isn't enough?
In article <···············@shell01.TheWorld.com>, Kent M Pitman wrote:
>········@cc.hut.fi writes:
>
>> ···@ashi.footprints.net (Kaz Kylheku) writes:
>>
>> > MIT Scheme is not comparable to CL because it is an *implementation*,
>> > whereas CL is an internationally standardized programming *language*.
>>
>> Is CL actually standardized internationally, or only in the USA?
>
>It is an American National Standard. There is an international Lisp
>standard, which is ISO ISLISP, but it's not code-compatible and its
>deployment is comparatively tiny. ANSI CL is _sold_ world-wide,
>though. Is there a reason that isn't enough?
Really, if your local member body of ISO doesn't have its own version
of a ANSI standard, that ANSI standard is effectively international.
What usually happens is that the other member bodies accept an ANSI
standard with little or no change. E.g. when the ANSI C standard was
approved by ISO, they just renumbered the sections.
In my limited understanding, the work is done, and the rest is largely
just rubber stamping, so in principle we could have an ISO Common Lisp.
From: Aleksandr Skobelev
Subject: Re: Beginner question: performance problems with a simple program
Date:
Message-ID: <tbbs0a.ar.ln@hermit.athome>
Kaz Kylheku <···@ashi.footprints.net> wrote:
> In article <···············@shell01.TheWorld.com>, Kent M Pitman wrote:
>>········@cc.hut.fi writes:
>>
>>> ···@ashi.footprints.net (Kaz Kylheku) writes:
>>>
>>> > MIT Scheme is not comparable to CL because it is an *implementation*,
>>> > whereas CL is an internationally standardized programming *language*.
>>>
>>> Is CL actually standardized internationally, or only in the USA?
>>
>>It is an American National Standard. There is an international Lisp
>>standard, which is ISO ISLISP, but it's not code-compatible and its
>>deployment is comparatively tiny. ANSI CL is _sold_ world-wide,
>>though. Is there a reason that isn't enough?
>
> Really, if your local member body of ISO doesn't have its own version
> of a ANSI standard, that ANSI standard is effectively international.
>
> What usually happens is that the other member bodies accept an ANSI
> standard with little or no change. E.g. when the ANSI C standard was
> approved by ISO, they just renumbered the sections.
>
> In my limited understanding, the work is done, and the rest is largely
> just rubber stamping, so in principle we could have an ISO Common Lisp.
"Most of the work is done" might be more correctly to speak. IMHO ANSI CL
standard is lacking in support for locales/charsets. So any non-Latin-1
user might encounter with some problems/inconviniences ever with
commercial realisations (such as Allegro 6.?, Lispwork 4.1.20). And when I
think about some funny features in the language like YES-OR-NO-P or ~R in
FORMAT, I understand that they were designed with English taken in
consideration only.
Aleksandr Skobelev <·········@mail.ru> writes:
> Kaz Kylheku <···@ashi.footprints.net> wrote:
>
> > Really, if your local member body of ISO doesn't have its own version
> > of a ANSI standard, that ANSI standard is effectively international.
Well, maybe not as a matter of country-level diplomacy, but probably as
a matter of informal, de facto commercial practice, yes.
> > What usually happens is that the other member bodies accept an ANSI
> > standard with little or no change. E.g. when the ANSI C standard was
> > approved by ISO, they just renumbered the sections.
But IMO one doesn't do this analysis on the basis of how things have
run in the past. One does this on the basis of what people are
clamoring for and what the reason is for going into the standards
process. We asked around a while back when considering pushing this
to ISO and the wisdom was, "unless you want a specific change, do not
open the option for change". With respect to global acceptance of
ANSI CL, there is nothing broken. If there is a push for an ISO CL,
it will come from abroad. But I would hope that, if possible, people
push instead for layered standards, either at the national lavel (ANSI,
BSI, AFNOR, etc.) or the international level (ISO).
> > In my limited understanding, the work is done, and the rest is largely
> > just rubber stamping, so in principle we could have an ISO Common Lisp.
What you say would e true if everyone worldwide took the same position as you,
but any committee takes on a life of its own when these things start, and
it's just not wise to assume the latter. I think instead I would stick to
how you summarized it above: ANSI CL operates similarly an ISO CL already,
and it is best not to divert large resources to solving non-problems.
> IMHO ANSI CL
> standard is lacking in support for locales/charsets. So any non-Latin-1
> user might encounter with some problems/inconviniences ever with
> commercial realisations (such as Allegro 6.?, Lispwork 4.1.20). And when I
> think about some funny features in the language like YES-OR-NO-P or ~R in
> FORMAT, I understand that they were designed with English taken in
> consideration only.
Certainly you are right if you mean that it is lacking service
functions for locales and charsets, but we made the design pretty
general in a way that I think doesn't fight an implementation that
wants to pursue these issues. If you find that's not so, it would be
an interesting topic of discussion to hear what specific
representational requirements are keeping you from having what you
want.
Individual implementations may indeed fall short, but before blaming
the spec for this, you should try to find the place in the spec that
REQUIRES such implementations to fall short. It's possible to happen,
in principle, but I think it's not there in most cases...
As to the issue of English bias, I think this: Because English is the
international interchange language (we're speaking it now, after all),
there is some reason to indulge some accomodations to it. If I were
to propose fixing things, it would mostly be to remove the offending
features, not to internationalize them. The problem is that those
features are mostly weak even for their support of English, and are
probably just bad ideas. They were in there as accomodations to
history, since old code used them. And the cost of ignoring them is
small.
IMO, proper support of these things for international purposes (to
include proper support for English) would be better to proceed as a
layered library standard, and I don't see any representational nor
protocol barrier to doing such things in an implementation that
commercially favors an international market.
The Japanese national body presented a report to the US just prior to
our putting out the standard, asking for a small number of detailed
changes to accomodate their internationalization needs. The US rushed
to fully accomodate their list of minimal necessary changes. I have
never heard a subsequent complaints that the changes we made were
insufficient. CLEARLY, there was work left to implementations and to
other layered standards, but IMO it's important to understand that
that will always happen.
So I'm not trying to assert that there are no bugs in CL that would be
a problem to internationalization. I'm trying to say that I try to
listen when people raise this issue because I USED TO think that CL
was enough deficient in this are that we would be forced to fix it at
some point. But over time I have come to the belief that the core
design is good enough that it can probably stand, at least for now.
And I'm asking you to do two things, Aleksandr, in order to be most
helpful here:
* Make your criticisms more precise so that those of us who don't
experience the day-to-day issues that you do can better understand
what you are up against. Many of us suffer from lack of day-to-day
familiarity with the problems at all and have to stretch our brains
to know what you're up against. Although I can imagine a problem with
YES-OR-NO-P in Russian, it's not obvious to me what that is. I imagine
(yes-or-no-p "Exit?") or (yes-or-no-p "Salir?") or ... to work in
just about any language; I don't see any internationalization issue
here that is different than (format t "~&Exit?~%") vs
(format t "~&Salir?~%"). [Pardon my use of Spanish as an example,
I don't speak Russian.] THe only problem I can even imagine is that
a pop-up dialog might need to know whether to put clickboxes that said
[Yes]/[No] or [Si']/[No] and in order to know this, it would need to
intuit the language that the query was presented in, so as not to have
the question asked in one language but the answer offered in another.
This is a problem, but again I can't see how it's much different than the
overall problem that CL uses inline strings in code rather than
references to resource vectors of translatable strings. I don't see that
problem as YES-OR-NO-P specific. So maybe you could help us by working
an example for each such thing you complain about. Thanks...
* Distinguish in your criticisms between omission and bad foundation.
A feature which is merely omitted (and there are many) can be added
compatibly. If our design is a bad foundation, then something about
an existing requirement must be fixed first to move on, correcting a
hill-climbing problem.
Thanks for your help in keeping the discussion focused.
From: Duane Rettig
Subject: Re: Beginner question: performance problems with a simple program
Date:
Message-ID: <4sn9qgfef.fsf@beta.franz.com>
Kent M Pitman <······@world.std.com> writes:
> Aleksandr Skobelev <·········@mail.ru> writes:
>
> > IMHO ANSI CL
> > standard is lacking in support for locales/charsets. So any non-Latin-1
> > user might encounter with some problems/inconviniences ever with
> > commercial realisations (such as Allegro 6.?, Lispwork 4.1.20). And when I
> > think about some funny features in the language like YES-OR-NO-P or ~R in
> > FORMAT, I understand that they were designed with English taken in
> > consideration only.
[ ... ]
> ... But over time I have come to the belief that the core
> design is good enough that it can probably stand, at least for now.
> And I'm asking you to do two things, Aleksandr, in order to be most
> helpful here:
>
> * Make your criticisms more precise so that those of us who don't
> experience the day-to-day issues that you do can better understand
> what you are up against. ...
>
> * Distinguish in your criticisms between omission and bad foundation.
> ...
I second Kent's request and agree with his assessment of the generality
of the ANSI CL spec. Furthermore, I offer Allegro CL 6.0 as an
example of how the spec has in fact been used without change to
incorporate international character sets and most international
external-formats, and Allegro CL 6.1 as an example of extending
the spec seamlessly to implement some of the important locale
categories of the POSIX locale specification. See
http://www.franz.com/support/documentation/6.1/doc/iacl.htm#localization-1
As for yes-or-no-p et al, it is true that we have not implemented the
LC_MESSAGES category, but it is entirely possible. And I may be wrong,
but my reading of the definition of yes-or-no-p in the spec doesn't
preclude an implementor from basing either the message string or the
actual "yes"/"no" responses on the locale.
As for the ~R format directive, I do agree that it is awkward to extend
individual pieces of format; we decided to make our locale extentions
general, using ~/ as our extension mechanism. The fact that ~/ was
available is to CL's credit re its extensibility.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
From: Erik Naggum
Subject: Re: Beginner question: performance problems with a simple program
Date:
Message-ID: <3218920202329027@naggum.net>
* Duane Rettig <·····@franz.com>
| As for yes-or-no-p et al, it is true that we have not implemented the
| LC_MESSAGES category, but it is entirely possible. And I may be wrong,
| but my reading of the definition of yes-or-no-p in the spec doesn't
| preclude an implementor from basing either the message string or the
| actual "yes"/"no" responses on the locale.
Fixing yes-or-no-p in the locale is the wrong place to do it. This is
clearly a user-interface function that depends on a particular mode of
user interaction with specific programmer and user expectations. Making
it more general is a mistake. A more elaborate user interface would need
more than just yes-or-no-p and y-or-n-p. _If_ these functions match the
user interface needs, they will be used, and then all parties involved
expect them to be exactly as they were when they got into the language.
If they are not satisfactory for user interaction, some other functions
will be written and used in their place. Please do not bother making
"localized" versions of these functions.
I work in two languages all the time -- have been since I were a kid, and
I consider myself fluent in both. I am constantly deeply annoyed by the
incompetence of the fools who think they can translate movies and books,
and can only imagine what kind of mistakes are made in translations of
languages I cannot read in the original. Not many years ago, fluency in
several European languages were common among academics and the lingua
franca (!) was Latin _long_ after that language had ceased to be spoken.
It is somewhat unfortunate that computer science uses a living language
for its lingua franca, in contrast to law and medicine, which are both
firmly based in much older languages and cultures, because that makes a
lot of people who fail to grasp the function of a common language think
it is a natural language and can be replaced by another, particularly
those who speak it naturally and are overcome with political correctness
and think they should be guilty of the fact that historic accidents
favored their language. The common language is, however, _not_ a natural
language except by accident, and it cannot be replaced by another natural
language without replacing the whole culture with it. Those who think
_their_ natural language should be the common language should just get
over their egoistic provincialism and learn to deal with reality.
And speaking as a user of Norwegian software, I do not accept some
two-bit "translation". If I have to translate the incompetent Norwegian
back to what I think the natural English would have been in order to
understand what the Norwegian probably means, all parties involved would
have been better off with the original. Like the other day, I saw "IP
header compression" translated on a cell phone to what best translates
back to "reduced headlines". I think translation between English and
Norwegian is important enough that I contribute to dictionaries and try
to help companies who pay their translators basically nothing to write
the local version of text that somebody else paid a large sum of money to
get just right in English. Thankfully, however, original-language
paperbacks in British and American English are now outselling translated
versions, and several major film releases are available in original
versions, so there is hope for this undersized country. English is now
taught from the first grade.
The more I have worked with software in these two different languages,
the more I am convinced that message catalogs is one of the worst
non-solutions. It works OK only if you have a primary language and
subordinate languages that you do not care if suffer from stilted
expression and phony flow of logic. We have to realize that the logic
flow of the primary language is deeply engrained in the program itself
and that "translating" what appears to be a step-by-step procedure in one
language may require fewer or more steps and with a different order in
another language, like in which order you provide the components of your
name and postal address, etc. The whole user interface/experience needs
to be tailored to each culture and language. "Translation" must be done
by programming.
This naturally leads to the conclusion that software should not speak
natural languages to users, but formalized protocols to user interface
engines. In other words, yes-or-no-p would be a protocol element, not a
_specific_ user interaction in my view.
///
--
From: Duane Rettig
Subject: Re: Beginner question: performance problems with a simple program
Date:
Message-ID: <4ofkdh4o0.fsf@beta.franz.com>
Erik Naggum <····@naggum.net> writes:
> * Duane Rettig <·····@franz.com>
> | As for yes-or-no-p et al, it is true that we have not implemented the
> | LC_MESSAGES category, but it is entirely possible. And I may be wrong,
> | but my reading of the definition of yes-or-no-p in the spec doesn't
> | preclude an implementor from basing either the message string or the
> | actual "yes"/"no" responses on the locale.
>
> Fixing yes-or-no-p in the locale is the wrong place to do it. This is
> clearly a user-interface function that depends on a particular mode of
> user interaction with specific programmer and user expectations. Making
> it more general is a mistake. A more elaborate user interface would need
> more than just yes-or-no-p and y-or-n-p. _If_ these functions match the
> user interface needs, they will be used, and then all parties involved
> expect them to be exactly as they were when they got into the language.
> If they are not satisfactory for user interaction, some other functions
> will be written and used in their place. Please do not bother making
> "localized" versions of these functions.
Right. As I said, we have not implemented them. My argument is purely
one for possibility, and not for practicality or desirability. I agree
that a programmer who wants a specific si/no or ja/nein or oui/non
interface can write their own functionality to do just that. I am only
saying that the CL spec doesn't preclude such responses from an
implementation.
> I work in two languages all the time -- have been since I were a kid, and
> I consider myself fluent in both. I am constantly deeply annoyed by the
> incompetence of the fools who think they can translate movies and books,
> and can only imagine what kind of mistakes are made in translations of
> languages I cannot read in the original.
A gripe I used to have as an English speaker was when I would buy a
Japanese (or other nationality) bicycle and get instructions purportedly
in English, and which indeed used only English words, but in such a way
as to be unintelligible. I still buy products from other countries, and
still receive instructions in English, but fortunately they are much better
written nowadays, since companies have learned that their products sell
better when proper translations of instructions are done.
> Not many years ago, fluency in
> several European languages were common among academics and the lingua
> franca (!) was Latin _long_ after that language had ceased to be spoken.
> It is somewhat unfortunate that computer science uses a living language
> for its lingua franca, in contrast to law and medicine, which are both
> firmly based in much older languages and cultures, because that makes a
> lot of people who fail to grasp the function of a common language think
> it is a natural language and can be replaced by another, particularly
> those who speak it naturally and are overcome with political correctness
> and think they should be guilty of the fact that historic accidents
> favored their language. The common language is, however, _not_ a natural
> language except by accident, and it cannot be replaced by another natural
> language without replacing the whole culture with it.
A good example of this is music; as a musician, I do know a few words
of Italian (including Allegro! :-) Translation of these musical terms
into English are usually not done; when they are attempted, the music
is usually rejected as not authentic.
> Those who think
> _their_ natural language should be the common language should just get
> over their egoistic provincialism and learn to deal with reality.
Well, as a native English speaker, I understand that English is an
important language used in computer science, but for the very reason you
cite I do not want to assume too much. Whether non-native-English speakers
(or more importantly, whether non-English speakers) accept English-only
interfaces is going to be up to you/them. And the acceptability of such
English-only interfaces are likely to vary according to the audience;
whether to the programmer or to the end-user. To use my music analogy,
it takes some understanding of Italian terms (piano, forte, pizzicato,
cresendo, etc) to play written music, but it takes no such knowledge
to listen nd enjoy the same music.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
From: Erik Naggum
Subject: Re: Beginner question: performance problems with a simple program
Date:
Message-ID: <3218954908969001@naggum.net>
* Duane Rettig <·····@franz.com>
| Well, as a native English speaker, I understand that English is an
| important language used in computer science, but for the very reason you
| cite I do not want to assume too much.
Each field has only one common language. Any attempt to add more will
split the field. It is already a problem that research published in
French and German are unavailable to the rest of the computer science
community.
| Whether non-native-English speakers (or more importantly, whether
| non-English speakers) accept English-only interfaces is going to be up to
| you/them.
Fluency in English is a sine qua non in computer science. Programmers
who want translated software tools and programming languages in their
native tongue will forever remain incompetent tinkerers. Only one
company on the planet thinks this is a good idea.
| And the acceptability of such English-only interfaces are likely to vary
| according to the audience; whether to the programmer or to the end-user.
End-users should _obviously_ be served with natural language interfaces.
I do not see how what I have said could be construed to have been arguing
against natural-language end-user interfaces. Quite the contrary, I have
made several points about how software that needs to talk to real users
must be tailor-made in each language. How could this possibly be taken
to mean that we should _not_ make natural-language interfaces for users?
///
--
From: Duane Rettig
Subject: Re: Beginner question: performance problems with a simple program
Date:
Message-ID: <47kr03a03.fsf@beta.franz.com>
Erik Naggum <····@naggum.net> writes:
> * Duane Rettig <·····@franz.com>
> | Well, as a native English speaker, I understand that English is an
> | important language used in computer science, but for the very reason you
> | cite I do not want to assume too much.
>
> Each field has only one common language. Any attempt to add more will
> split the field. It is already a problem that research published in
> French and German are unavailable to the rest of the computer science
> community.
Unless they are translated. My view about language commonality is that
if there is a field developing in more than one language, either they will
develop separately in parallel (with possible diversity) or they will
converge with cooperative efforts. And if specific research in one group
is important enough for the other group, it will eventually get translated
to the other group's language. Perhaps one group will become stronger than
the other, thus apparently "winning" and shutting out the other group (an
unfortunate consequence). An example of such a successful effort is the
US and Russian space programs, which have after all developed largely in
parallel, with only limited cooperation, and with different emphases, and
yes, of course, with much redundant effort, but also with no clear winner,
because the emphases have been different.
> | Whether non-native-English speakers (or more importantly, whether
> | non-English speakers) accept English-only interfaces is going to be up to
> | you/them.
>
> Fluency in English is a sine qua non in computer science. Programmers
> who want translated software tools and programming languages in their
> native tongue will forever remain incompetent tinkerers. Only one
> company on the planet thinks this is a good idea.
I won't make this assumption, again due to my own English-centeredness.
However, for as long as my Company has existed we have had requests,
especially in Japanese and French communities, to provide the kinds of
things we're discussing here. The requests vary widely, from simple
character-set capabilities to message translation tools. I don't remember
anyone ever having asked for actual CL name translations, but most of the
example problem descriptions we receive which were developed in a non-English
country are written with objects and predicates matching that country's
native language. And several of our developers have had to learn Japanese
in order to make any in-roads into the Japanese markets. We even have a
salesperson who is Japanese who also serves as a translator between our
Japanese customers and us.
The above paragraph is not intended to refute or question a claim of _use_
of English in computer science, but only a need for _fluency_ in it.
All of our customers use "cdr" and "cons" just like the rest of us (are those
English words? :-), and the real problem is in communicating the programming
concepts within the communities within which these programmers are
operating. If a Japanese programmer decides to name a function with Kanji
characters, do we force him to translate the name to English in order to
help him solve a bug? The question is not rhetorical; every vendor has to
answer it for themselves. If the answer is "yes", then some of that market
is shut out. If the answer is "no", then the vendor must learn at least
the characterset of the customer's language. We chose the "no" answer.
> | And the acceptability of such English-only interfaces are likely to vary
> | according to the audience; whether to the programmer or to the end-user.
>
> End-users should _obviously_ be served with natural language interfaces.
> I do not see how what I have said could be construed to have been arguing
> against natural-language end-user interfaces. Quite the contrary, I have
> made several points about how software that needs to talk to real users
> must be tailor-made in each language. How could this possibly be taken
> to mean that we should _not_ make natural-language interfaces for users?
I am agreeing with your points. What I think we may disagree on is whether
a programmer can be an end-user as well. Contrary to what I have heard
others say on this newsgroup about CL being a programming language which
requires an elite group of programming skills, I have seen a wide
spectrum of users within our customer base, with widely varying degrees
of fluency in English as well. So I view the spectrum of programmer to
end-user not as a dichotomy, but as a continuum, with a small number of the
"elite" programmers who know the CL spec intimately, a larger group of
users who might look at a screen-saver or play a game without even knowing
that they were using CL, and a larger still group of programmer/user types
who fall somewhere in the middle.
So the real point of issue is within this center of the spectrum, where
we might ask the question "How much do we require the average programmer
to know English in order to program in Common Lisp?" I think that the
current answer is "They must know English", but I think also that it
_should_ be the case that "They need not know English, only Common Lisp".
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
From: Janos Blazi
Subject: Re: Beginner question: performance problems with a simple program
Date:
Message-ID: <3c349ea0_5@news.newsgroups.com>
> Each field has only one common language. Any attempt to add more will
> split the field. It is already a problem that research published in
> French and German are unavailable to the rest of the computer science
> community.
Regarding the fact that we are giving up German at the moment (and are
substituting it with bad English) I do not believe that are any research
papers in any field written in German.
J.B.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
Check out our new Unlimited Server. No Download or Time Limits!
-----== Over 80,000 Newsgroups - 19 Different Servers! ==-----
From: Nils Goesche
Subject: Re: Beginner question: performance problems with a simple program
Date:
Message-ID: <lkheq2kkbc.fsf@pc022.bln.elmeg.de>
"Janos Blazi" <······@hotmail.com> writes:
[ Erik Naggum wrote: ]
> > Each field has only one common language. Any attempt to add
> > more will split the field. It is already a problem that
> > research published in French and German are unavailable to the
> > rest of the computer science community.
Are they? Why? I guess it's because most or all significant CS
literature has always been in English, so people just aren't used to
reading papers in other languages. In mathematics, however, the
situation is different (for historical reasons, I guess). Originally,
everything was in Latin (and ancient Greek, maybe). Then German and
French became most important. Later came also English and Russian.
Nowadays, English is most important, but lots of contemporary papers
are published in all kinds of languages, even very freaky dialects of
already rarely spoken languages.
The American Mathematical Society (AMS) regularly publishes the
`Mathematical Review', full of reviews of new mathematical papers in
every language you can imagine, with a summary and some judgement on
the importance of the paper. And if some paper /is/ important for
you, heck, you'll read it just because it's worth the effort.
Learning enough of a language so you can read a scientific paper isn't
hard at all and often takes only a few hours. (Although Japanese or
Chinese probably aren't as easy ;-). I could read complicated texts
like general newspapers or novels only in German or English, maybe
also Russian, but I have read mathematical papers and textbooks
without much effort also in French, Italian, Russian, and Latin (some
Gauss :-).
People in comp.lang.functional and elsewhere always complain about the
lack of an English translation of OReilly's OCaml book - but
apparently none of them simply tried to read the French version. It's
easy, even if you don't speak French (I don't).
> Regarding the fact that we are giving up German at the moment (and
> are substituting it with bad English)
Seems so, unfortunately. Remember who started it? First thing I
remember was some SPD bitch I can't remember the double-name of, who
always said `in 1986' instead of just `1986'... For years, she was
the only one, now virtually everybody says `in 1986'. Or `in
Deutsch'. Both the government and state companies like the so called
`Deutsche Bahn AG' invent stupid anglicisms all the time. Or the
idiotic ``Starter Kit''.
> I do not believe that are any research papers in any field written
> in German.
This is often claimed but not true.
Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x42B32FC9
Kent M Pitman <······@world.std.com> writes:
> Although I can imagine a problem with YES-OR-NO-P in Russian,
> it's not obvious to me what that is. I imagine
> (yes-or-no-p "Exit?") or (yes-or-no-p "Salir?") or ... to work in
> just about any language; I don't see any internationalization
> issue here that is different than (format t "~&Exit?~%") vs
> (format t "~&Salir?~%"). [Pardon my use of Spanish as an
> example, I don't speak Russian.] THe only problem I can even
> imagine is that a pop-up dialog might need to know whether to put
> clickboxes that said [Yes]/[No] or [Si']/[No] and in order to
> know this, it would need to intuit the language that the query
> was presented in, so as not to have the question asked in one
> language but the answer offered in another. This is a problem,
> but again I can't see how it's much different than the overall
> problem that CL uses inline strings in code rather than
> references to resource vectors of translatable strings. I don't
> see that problem as YES-OR-NO-P specific. So maybe you could
> help us by working an example for each such thing you complain
> about. Thanks...
Actually, your s�/no example made me think of one where yes-or-no-p
won't work in French. Of course, it's confusing in English, but in
French, the implementation would need to be able to understand the
language to do the right thing. Say the user has told the application
to quit without finishing some task:
[I'm imagining here that this program uses something akin to GNU
gettext for its internationalization, with a dynamic variable bound to
the current locale, and a read macro defined for _ to translate the
upcoming string]
(let ((finishp (yes-or-no-p _"Finish?")))
(unless finishp
;; Make sure they really mean it!
(setf finishp (yes-or-no-p _"You do not want to finish?")))
...)
I'd expect that to do:
English:
Finish? (yes/no) no
You don't want to finish? (yes/no)
French:
Finir? (oui/non) non
Vous ne voulez pas finir? (si/non)
French has the oppositional adverb "si", which must be used in this
case. "Si, I *do* want to finish!" or "Non, I do not want to finish".
We might avoid this situation like the plague in English because it's
confusing (though not actually ambiguous), but other languages don't
necessarily have that problem. The work around is to just not ask
negated questions with yes-or-no-p, or to define it as only ever
asking "oui" or "non", but that says to me that it shouldn't be in the
language (or should be removed from a hypothetical ISO CL).
I would expect there to be other languages with more words in this
area, since, although there's technically no ambiguity in English
here, we avoid this situation like the plague in actual usage because
it feels ambiguous.
On the other hand, French isn't exactly a secret code known by only a
few initiates, so I wonder if this came up during the design of CL. I
was curious if Le-Lisp had anything like yes-or-no-p, but there
doesn't seem to be anything much about it on the web (that I can find,
anyhow). All I know about it is that it was from INRIA and apparently
was CL-like. I'm guessing from the fact they don't have it for
download that it wasn't free. Was it the only French-designed lisp?
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Duane Rettig <·····@franz.com> writes:
> As for yes-or-no-p et al, it is true that we have not implemented the
> LC_MESSAGES category, but it is entirely possible. And I may be wrong,
> but my reading of the definition of yes-or-no-p in the spec doesn't
> preclude an implementor from basing either the message string or the
> actual "yes"/"no" responses on the locale.
I don't think the spec requires it, though how it would know what
language it was in is slightly problematic. You have to know what
language the question is being asked in OR you have to accept
responses in multiple languages. If you're taking one-letter
responses, it's not hard to imagine how a letter might have
conflicting meanings depending on the language, though I don't know if
that happens in practice.
> As for the ~R format directive, I do agree that it is awkward to extend
> individual pieces of format; we decided to make our locale extentions
> general, using ~/ as our extension mechanism. The fact that ~/ was
> available is to CL's credit re its extensibility.
Part of the problem isn't just the desire to extend but the fact that
what some people mean by "extend" is "redefine". Even if you knew a program
was being run in a certain country by a certain user who needed certain
interfaces localized, you don't know if ~R is being called for reasons
relevant to where the program is run or independent of that. One should
not confuse the notion of "providing a function that is known to vary in
effect with localization" with the notion of "providing a function that
someone WISHES had varied with localization but that programmers have
already used in the full knowledge that it is not going to do that".
"Upgrading" a program of the latter kind is really just "breaking" it.
You're right that ~/ is the right answer; ~R is not only hard to extend
but I think it would be improper to extend it. Better to just ignore it
if you don't like it just as it's spec'd now.
From: Duane Rettig
Subject: Re: Beginner question: performance problems with a simple program
Date:
Message-ID: <43d1o39e4.fsf@beta.franz.com>
Kent M Pitman <······@world.std.com> writes:
> Duane Rettig <·····@franz.com> writes:
>
> > As for yes-or-no-p et al, it is true that we have not implemented the
> > LC_MESSAGES category, but it is entirely possible. And I may be wrong,
> > but my reading of the definition of yes-or-no-p in the spec doesn't
> > preclude an implementor from basing either the message string or the
> > actual "yes"/"no" responses on the locale.
>
> I don't think the spec requires it, though how it would know what
> language it was in is slightly problematic. You have to know what
> language the question is being asked in OR you have to accept
> responses in multiple languages. If you're taking one-letter
> responses, it's not hard to imagine how a letter might have
> conflicting meanings depending on the language, though I don't know if
> that happens in practice.
My guess is that it does not. I'd be interested in knowing whether there
is any language out there whose "one-character representation" for "yes"
and "no" are the same letter. So _if_ y-or-n-p were set up to obey
localities, there would be no conflict.
However, are you saying that a "y" in one language is the same as the
equivalent "n" of another language? This would be consistent with your
statement that multiple-languages would need to be acceptible as
input. (I happen to disagree with this; it violates rules of least
surprise - if I accidentally hit the "s" key and that got accepted as
"yes" (via "si") then I would become pretty angry at such suprising
behavior).
> > As for the ~R format directive, I do agree that it is awkward to extend
> > individual pieces of format; we decided to make our locale extentions
> > general, using ~/ as our extension mechanism. The fact that ~/ was
> > available is to CL's credit re its extensibility.
>
> Part of the problem isn't just the desire to extend but the fact that
> what some people mean by "extend" is "redefine". Even if you knew a program
> was being run in a certain country by a certain user who needed certain
> interfaces localized, you don't know if ~R is being called for reasons
> relevant to where the program is run or independent of that. One should
> not confuse the notion of "providing a function that is known to vary in
> effect with localization" with the notion of "providing a function that
> someone WISHES had varied with localization but that programmers have
> already used in the full knowledge that it is not going to do that".
> "Upgrading" a program of the latter kind is really just "breaking" it.
> You're right that ~/ is the right answer; ~R is not only hard to extend
> but I think it would be improper to extend it. Better to just ignore it
> if you don't like it just as it's spec'd now.
We had these same conversations at Franz, and our conclusions were the
same. And as for CL functions that might be candidates for
locale-sensitivity (STRING<, for example), we added new functionality
rather than try to extend the CL functions (thus, for example, our version
of STRING< remains ASCII centric).
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
Duane Rettig <·····@franz.com> writes:
> Kent M Pitman <······@world.std.com> writes:
>
> > Duane Rettig <·····@franz.com> writes:
> >
> > > As for yes-or-no-p et al, it is true that we have not implemented the
> > > LC_MESSAGES category, but it is entirely possible. And I may be wrong,
> > > but my reading of the definition of yes-or-no-p in the spec doesn't
> > > preclude an implementor from basing either the message string or the
> > > actual "yes"/"no" responses on the locale.
> >
> > I don't think the spec requires it, though how it would know what
> > language it was in is slightly problematic. You have to know what
> > language the question is being asked in OR you have to accept
> > responses in multiple languages. If you're taking one-letter
> > responses, it's not hard to imagine how a letter might have
> > conflicting meanings depending on the language, though I don't know if
> > that happens in practice.
>
> My guess is that it does not. I'd be interested in knowing whether there
> is any language out there whose "one-character representation" for "yes"
> and "no" are the same letter. So _if_ y-or-n-p were set up to obey
> localities, there would be no conflict.
>
> However, are you saying that a "y" in one language is the same as the
> equivalent "n" of another language?
Yes, this was the case I worried about.
> This would be consistent with your
> statement that multiple-languages would need to be acceptible as
> input. (I happen to disagree with this; it violates rules of least
> surprise - if I accidentally hit the "s" key and that got accepted as
> "yes" (via "si") then I would become pretty angry at such suprising
> behavior).
Well, perhaps. But it's already common for Space to be accepted as a
'y' substitute, and Rubout/Delete for 'n'. I certainly agree with your
concern, but I also thiuk the issue is orthogonal and that implementations
might reasonably have separate degrees and mechanisms for controlling
such safeguarding.
From: Aleksandr Skobelev
Subject: Re: Beginner question: performance problems with a simple program
Date:
Message-ID: <kj811a.c41.ln@hermit.athome>
Duane Rettig <·····@franz.com> wrote:
>
> ...
>
> We had these same conversations at Franz, and our conclusions were the
> same. And as for CL functions that might be candidates for
> locale-sensitivity (STRING<, for example), we added new functionality
> rather than try to extend the CL functions (thus, for example, our version
> of STRING< remains ASCII centric).
>
So, any non-English string won't be compared correctly?
From: Duane Rettig
Subject: Re: Beginner question: performance problems with a simple program
Date:
Message-ID: <4lmffhh9d.fsf@beta.franz.com>
Aleksandr Skobelev <·········@mail.ru> writes:
> Duane Rettig <·····@franz.com> wrote:
> >
> > ...
> >
> > We had these same conversations at Franz, and our conclusions were the
> > same. And as for CL functions that might be candidates for
> > locale-sensitivity (STRING<, for example), we added new functionality
> > rather than try to extend the CL functions (thus, for example, our version
> > of STRING< remains ASCII centric).
> >
>
> So, any non-English string won't be compared correctly?
Actually, the 8-bit Allegro CL images coallate via latin-1 (a superset of
ASCII) and the 16-bit images coallate via Unicode. Essentially STRING<
and STRING> compare the char-codes of each character. But since ASCII or
Unicode ordering may not be precisely what you want, we provide
functionality to aid in user-customizable orderings. See
http://www.franz.com/support/documentation/6.1/doc/iacl.htm#collation-1
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
From: Erik Naggum
Subject: Re: Beginner question: performance problems with a simple program
Date:
Message-ID: <3219063429863038@naggum.net>
* Aleksandr Skobelev <·········@mail.ru>
| So, any non-English string won't be compared correctly?
_Please_ try to understand there is no _one_ correct way to compare
strings. Monoculturalism is simply wrong. That is why one chooses
technical specifications that have arbitrary, but very predictable
results. Making string< attempt to do culturally sensitive string
comparisons would _always_ be wrong, because it is not specified to do
that, was never intended to do that, and should never be intended or
specified to do that if language designers do their job. The only
reasonable way to do string< is to do it with repeated char<, which can
only be done as < on char-code of the two characters (in practice, with
machine less-than operations on the internal representation of the
character object). In Common Lisp, that is precisely what it does.
The only _correct_ way to do culturally sensitive sorting is to maintain
a collation information string in addition to the "data" string. If you
are unwilling to do this work, whoever employed you should get a refund,
and if you did not know, whoever you paid for your education should be
prepared to give you a refund, unless he demonstrated that you failed to
do what you were told.
So here is a hint: If you want to compare two strings with culturally
sensitive contents, you need to know: which language both are in, how to
convert strings of that language into collation information strings, and
then compare the result with string<. Do _not_ try to roll this into one
function or make assumptions about the language in use. And _please_
note that string< does not work for English, either. English is _not_
spelled correctly only using ASCII.
Why are you behaving as if you are _envious_ of the fact that Common Lisp
happened to be defined in the United States? Nobody forces you to use
the functions that do not fill your needs. Please quit making it anybody
else's problems -- just go implement what you think is right. (Whether
you share it with others afterwards is not for me to suggest, but if you
are concerned with the proper sorting of your natural language, it would
seem reasonable to expect you to publish it, for pay or not.)
///
--
Aleksandr Skobelev <·········@mail.ru> writes:
> Duane Rettig <·····@franz.com> wrote:
> >
> > ...
> >
> > We had these same conversations at Franz, and our conclusions were the
> > same. And as for CL functions that might be candidates for
> > locale-sensitivity (STRING<, for example), we added new functionality
> > rather than try to extend the CL functions (thus, for example, our version
> > of STRING< remains ASCII centric).
> >
>
> So, any non-English string won't be compared correctly?
Heh. Is there a requirement that a string contain valid language?
What's an example of a "non-English string"?
I thought locales were an abstraction about the context in which a given
set of characters were to be interpreted, not a representational issue.
Failing to do it thus would, I think, leave you in a serious quandary
about how to deal with a string containing multiple languages in the
same string, such as the hyphenated last name of a person whose parents
are from different (linguistically incompatible) countries.
STRING< and friends are intended to compare strings in a
natural-language-independent way, according to an arbitrary sort order
that is constrained only by the A-Z/0-9 constraints enumerated the
spec. From an internationalization point of view, this is all
subprimitive and to be ignored.
Proper internationalization would, IN ANOTHER PACKAGE, offer the right
meaning.
My understanding is that a properly localized string ordering function
for a number of locales would require multi-char strings like
"MacDonald" to sort ahead of "Maas" because "Mac" has some special
priority in some locales. The definition of STRING< in the ANSI CL
spec does not permit this because it requires the comparisons to go
character-wise, not in groups.
From: Duane Rettig
Subject: Re: Beginner question: performance problems with a simple program
Date:
Message-ID: <43d1nbbq8.fsf@beta.franz.com>
Kent M Pitman <······@world.std.com> writes:
> Aleksandr Skobelev <·········@mail.ru> writes:
>
> > Duane Rettig <·····@franz.com> wrote:
> > >
> > > ...
> > >
> > > We had these same conversations at Franz, and our conclusions were the
> > > same. And as for CL functions that might be candidates for
> > > locale-sensitivity (STRING<, for example), we added new functionality
> > > rather than try to extend the CL functions (thus, for example, our version
> > > of STRING< remains ASCII centric).
> > >
> >
> > So, any non-English string won't be compared correctly?
>
> Heh. Is there a requirement that a string contain valid language?
> What's an example of a "non-English string"?
Although the english :-) in his statement wasn't quite correct, I
took it to be just a slip and read it as "non-ascii". His slip was
made over the rotten bannana I threw, where I said "ASCII centric"
rather than a more appropriate term (Latin-1 centric for our 8-bit
lisps, and Unicode centric for our 16-bit lisps).
> I thought locales were an abstraction about the context in which a given
> set of characters were to be interpreted, not a representational issue.
One of the categories of the POSIX locale specification is LC_CTYPE,
which does abstract the actual representation of the characters.
Other categories such as LC_MONETARY, LC_NUMERIC, LC_TIME, and
LC_COLLATE abstract the context within which the selected character
set will be used.
> Failing to do it thus would, I think, leave you in a serious quandary
> about how to deal with a string containing multiple languages in the
> same string, such as the hyphenated last name of a person whose parents
> are from different (linguistically incompatible) countries.
We chose not to deal with this - instead we ignore LC_CTYPE and use
the entire Unicode (actually, a subset: UTF-16) character set in our
16-bit lisp, which indeed does allow multiple languages to be represented
at once. This also includes characters that can't be encoded by ASCII,
such as European language characters with extra glyphs on them, as well
as Asian alphabets, Greek, Armenian, Arabic, etc., and even strange
symbols such as traffic signs and other oddities. I thumbed through
the Unicode book our I18n expert has, and it is at least an inch and a
half thick and contains only the character sets...
> STRING< and friends are intended to compare strings in a
> natural-language-independent way, according to an arbitrary sort order
> that is constrained only by the A-Z/0-9 constraints enumerated the
> spec. From an internationalization point of view, this is all
> subprimitive and to be ignored.
>
> Proper internationalization would, IN ANOTHER PACKAGE, offer the right
> meaning.
We chose instead to still use STRING< and STRING> as the basic
comparison tool, and to target it with a collation converter
(obviously, in a different package). The EXCL:STRING-SORT-KEY
function
http://www.franz.com/support/documentation/6.1/doc/pages/operators/excl/string-sort-key.htm
accepts a string and a "ucet" object (for Unicode Collation Element
Table) and returns a string which can be passed to STRING< or STRING>
along with another STRING-SORT-KEY-processed string. A default ucet
object exists which allows for normal Unicode ordering, or the user
can use EXCL:PARSE-UCET to create a new ucet-object:
http://www.franz.com/support/documentation/6.1/doc/pages/operators/excl/parse-ucet.htm
> My understanding is that a properly localized string ordering function
> for a number of locales would require multi-char strings like
> "MacDonald" to sort ahead of "Maas" because "Mac" has some special
> priority in some locales. The definition of STRING< in the ANSI CL
> spec does not permit this because it requires the comparisons to go
> character-wise, not in groups.
This known problem is actually handled by the "Unicode Technical Standard #10"
(sorry, I don't have a url for it). We touch on it briefly in
http://www.franz.com/support/documentation/6.1/doc/iacl.htm#collation-1
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
From: Will Deakin
Subject: Re: Beginner question: performance problems with a simple program
Date:
Message-ID: <3C3461D2.3070408@hotmail.com>
Kent M Pitman wrote:
> My understanding is that a properly localized string ordering function
> for a number of locales would require multi-char strings like
> "MacDonald" to sort ahead of "Maas" because "Mac" has some special
> priority in some locales. The definition of STRING< in the ANSI CL
> spec does not permit this because it requires the comparisons to go
> character-wise, not in groups.
(sigh). Speaking from personal experience -- this is an absolute
nightmare if you try and compile things like telephone books.
:)w
Will Deakin <···········@hotmail.com> writes:
> Kent M Pitman wrote:
>
> > My understanding is that a properly localized string ordering function
> > for a number of locales would require multi-char strings like
> > "MacDonald" to sort ahead of "Maas" because "Mac" has some special
> > priority in some locales. The definition of STRING< in the ANSI CL
> > spec does not permit this because it requires the comparisons to go
> > character-wise, not in groups.
>
> (sigh). Speaking from personal experience -- this is an absolute
> nightmare if you try and compile things like telephone books.
Not to mention if you try to USE such a telephone book.
All that work just to confuse people...
Kent M Pitman <······@world.std.com> writes:
> Will Deakin <···········@hotmail.com> writes:
>
> > Kent M Pitman wrote:
> >
> > > My understanding is that a properly localized string ordering function
> > > for a number of locales would require multi-char strings like
> > > "MacDonald" to sort ahead of "Maas" because "Mac" has some special
> > > priority in some locales. The definition of STRING< in the ANSI CL
> > > spec does not permit this because it requires the comparisons to go
> > > character-wise, not in groups.
> >
> > (sigh). Speaking from personal experience -- this is an absolute
> > nightmare if you try and compile things like telephone books.
>
> Not to mention if you try to USE such a telephone book.
>
> All that work just to confuse people...
Well, only if you don't understand the sort order. Honestly, I'd be
annoyed if I had to look through a phone book that was 1/3 "D" entries
because someone had sorted the "de Somthing" family names under D in a
French phone book. Same with Mc, Mac, O'/�, di, etc, in the
appropriate countries.
Bookstores are much more of a pain, because they tend to be
inconsistent, which is when you can't find things.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Aleksandr Skobelev <·········@mail.ru> writes:
> Well, I don't think that there is need to intuit the language of the query
> to interpret replies properly in YES-OR-NO-P. Probably, it is enough just
> to allow to set strings for yes/no replies (for example through some
> specail variables called *yes-reply*, *no-reply*...) and leave the problem
> of language synchronization in query/reply for programmer.
I don't agree that this would make the language stronger.
First, you are failing to distinguish, as I asked you do, things that the
language keeps from happening from things the language merely does not
force to happen. The language definition does not say an implementation
should not do this. HOWEVER, if the language definition *did* do this,
it would be a weaker language. You appear to be assuming (in both cases
incorrectly) BOTH that (1) YES-OR-NO-P cannot accept such responses now
and (2) YES-OR-NO-P works by textual typein. As to point 1, a conforming,
correctly localized implementation of Lisp, is already permitted to do what
you say. That is, what stands between you and success is not the language
definition but your vendor's choice of how to render the language spec into
a language implementation. But as to point 2, some vendors work by asking
a textual query in which "yes" or "da" might be 'yes' answers *already*
and "no" or "nyet" might be 'no' answers *already*. Now, if the language
required so simple an interface as you provide, *yes-reply* could only
contain one value, not many, and so you'd be eliminating valid replies.
At minimum, you'd want a list of yes replies. But then in that case, the
implementations where it was a dialog would not know what to do. In that
case, how would you distinguish between whether (yes-or-no-p "Exit?")
and (yes-or-no-p "Salir?") producing:
Exit? Salir?
vs
[Yes] [No] [Si'] [No]
(english) (spanish)
The heuristic guessing of language (especially based on a small number of
letters) would be impossible to do reliably. Certainly it would not be
able to tell whether to do even something like:
Comer? Comer?
vs
[Si'] [No] [Sim] [Na~o]
(spanish) (portuguese)
much less someting like this :) ...
42? 42?
vs
[Yes] [No] [HIja'] [ghobe']
(federation standard) (klingon)
The thing to understand is that these are *interface* issues and that such
issues are explicitly not something that Common Lisp seeks to address in the
base level of its standard. These were left to vendors and were
intended to be the subject of separated (perhaps layered) standards. They
are INAPPROPRIATE to standardize in a context where the space of interface
concerns cannot be known because each such interface concern creates a nuance
that cannot, a priori, be known.
In the future, there will also be voice and visual gesture interfaces,
and CL does not address those either. If you have Star Trek movies
over there, think of YES-OR-NO-P as an antique interface, like Scotty
uses in Star Trek IV, to talk to the bootstrap version of a system, in
order to get it into application mode where other interfaces, not
defined by the base layer, are available. It is IMPORTANT that Common Lisp
does not pretend to address those other layers because it will SURELY FAIL
to do them right and may trick implementors into thinking it has an answer
that works, when it does not... just as you have already been tricked into
thinking that YES-OR-NO-P is ever going to be the answer to the kinds of
issues you are raising.
I say again: The correct solution to this problem is simply to IGNORE the
presence of YES-OR-NO-P except for simple applications written in "federation
standard" (i.e., English), the like-it-or-not interchange language of the
modern world.
> So, I think, YES-OR-NO-P in its current state is not very useful in any
> program which intended for non-English user, who works with non-English
> keyboard mainly.
Yes, certainly. But that does not call for it to be fixed. It calls for it
to be deprecated. The space of tools required to really address the
non-English user is a space probably as large as the present language in its
entirety.
> IMHO it is not convinient, at least, because such user
> need to switch the keyboard to English and back every time he/she need
> reply on YES-OR-NO-P query.
This is just a bug in your implementation, brought on by your specific vendor
not caring about your locale. The language does NOT require this. PLEASE
distinguish LANGUAGE from IMPLEMENTATION. These are utterly different things.
> It is, of course, is not a problem, because
> such functionality can be implemented very easy. It is just a little
> inconvenience.
Yes, but once we start to address that, it only opens the question: what if
I want yes, no, or maybe? What if I want to answer "boy" or "girl" instead
of "yes" or "no"? What if I want to have option1/option2/Cancel? What if
I need voice input? What if I need it to handle 7bit ascii Russian? (I was
going to paste in some Russian but my newsreader doesn't have the characters
to do it... I might want to write Espa~nol or Fran,cais ... should we clutter
the language with support for these? It's very helpful to accept them.)
There are a LOT of issues one must address in order to have good LANGUAGE
support for Russian or even a much more English-like language such as German
or Spanish. It is fine for an application writer to shrug and say "well, I
don't really need all that extra" but it is not fine for a language writer
to do that. Probably that means we should have just left these things out of
CL, but it's been a "learning experience" for all of us, and we didn't do
everything personally. You and I just presently disagree on what the right
way to fix that is.
> If we spoke about an implementation of "international" functionality of ~R
> directive, I would try to offer a some leverage with ability to pass a
> list of user arguments to ~R that then could be passed to some callback
> function (that could be set by a programmer) to get a proper form for ordinal
> number.
This would get very messy, to the point that just using ~A or ~/ and
giving the right information would be better. Those capabilities
are already there.
And before considering Russian, consider even the simple mess that the
British and the Americans don't entirely agree on the meaning of the "English"
word "billion" so that detecting whether an error has occurred is
extraordinarily hard if you ever even hint that ~R's purpose might be
to satisfy localization constraints.
> Again, I don't speak that this functionality is needed. I think this
> is just some convenient tools in the language. If they were absent, nobody
> told about them. But, on the other hand, if they were added, why didn't they
> have done more extendable?
Because it was understood from the outset that (a) the language was not
seeking to be a translation tool and (b) doing it Right is very hard.
Doing translation is an art or a heuristic, but is not a deterministic
activity. CL is a language, and so seeks to be deterministic. These goals
come into conflict if the meaning of the linguistic terms is not simple.
There may even have been some US-bias in the design. For that I
apologize. But in fairness, the US *did* design the language and our
culture is, I think, due some small historical accomodation to keeping
its programs running while stretching to embrace the new global
market. It's not like the present definition of ~R really breaks existing
programs when compiled in Russian. Existing programs were ALREADY broken
because they do things like: (write-string "Hello World") instead of
_ _
(write-string "| |p|/|BeT M|/|pOBo| O"), even without worrying about what
the world is going to say in response. [Sorry about the character set
problem there. And I hope I didn't say anything offensive--I was just
working from online phrasebooks. :-]
> The more important thing is, of course from my point of view, ability to
> set a proper charset.
Again, an implementation issue. The standard cannot require this. Even in
a properly internationalized implementation, there are some very complex
issues about how to trade off true generality for efficiency. If we required
Unicode (or better), we might be keeping some implementations that don't
seek that market from being efficient. Even the input we saw from the
Japanese standards groups seemed to me to indicate that they were not going
to rush to make every implementation take their full pictogram character
set in every circumstance. I don't think we yet have the global agreement
to know what the right way to handle this is. In my opinion, and I'll even
say it stronger here because I do believe this strongly, in my considered
professional opinion, one must FIRST see some successful vendor-specific
attempts at this AND one must observe that all the vendors agree on a common
way of doing this before we go saying "this is the right way" and "this is
the wrong way" by putting something like this in the standard. At this
stage of our global-community-shared-cultural-understanding of this complex
situation, I believe we do not have the wisdom to lock in a single way to do
this and it would be VERY BAD to do so. This is NOT to say that I don't
understand your need. I'm just saying you are criticizing the wrong people
and so working against your own need. Talk to your VENDOR (by which I mean
either whoever sold you your lisp or whoever made the lisp, if it was "free").
It is their responsibility to help you at this point. The responsibility of
the language at this point is merely to not do things that would make a vendor
implementation non-conforming merely for wanting to help you.
> Without that functions for manipulating strings and
> characters don't work properly. So STRING-UPCASE for example doesn't not
> work with Russian in Lispwork 4.1.20 Personal Edition, CMUCL. There is
> SET-LOCALE function in Lispwork but only "C", "POSIX" and "*.ISO-8859-1"
> locales exist.
Tedious as it is, these are problems to report to individual vendors.
If this went to a language standards committee right now, you might get a
common definition, but it might be wrong. And that might mean everyone
diverged from the standard. And that would hurt the standard's credibility.
The process of consensus making is NOT fast. It is frustratingly slow
sometimes. But if you want it to go fast, make a layered standard that can
be discarded (if it's found to be wrong) without perturbing the underlying
CL standard. There is no motivation for the entire language to take on the
risk of someone calling the base language "bankrupt" just because someone gets
overly aggressive about addressing this complex issue and then later finds
they've made a mistake. But that doesn't mean no standard can arise. It
just means you shouldn't try to put everything under one label. No more so
than you should try to store all the data in your file system in a single file.
The file system is there so you can separate one program's data from another's.
Multiple layerable language standards are possible just so you can separate
one set of concerns from another.
> If my memory serves me, there are same situation in Allegro
> 6.x (i.e. SETLOCALE exists but number of localies is limited by
> C/POSIX/*.ISO-8859-1)? But because I don't have Allegro on my computer
> now, I can make a mistake here.
Again, vendor issues. And then once resolved, the community has to go get
the vendors to agree. But if you make them agree prematurely, some vendor
will be mad that it didn't get to pursue how it thought things should work.
As a consequence, it may feel commercially discriminated against. As a
further consequence, it may decide CL is no longer worth caring about as a
spec. And that result would be very very bad--worse even than the very
real problem you are having now.
> Again, It might be not a problem but just a little inconvenience.
> Because, I suspect that correspondent localies can be added to both
> Lispwork and Allegro. And it is not a very hard ever for such a beginner
> as me to implement a basic SETLOCALE functionality in CMUCL using existing
> Alien interface.
>
> I don't blame anybody or anything. I think that a great job was done with
> the standard. I can understand vendors who probably have had most of their
> customers in English-spoken countries. So there were not value reasons for
> them to harry up with implementation of functionality that was not part of
> the standard.
>
> Thank you and all others senders who reply on my message. I have been
> reading this newsgroup regulary enough and I have never seen before a
> discussion of that topic. But these little problems with locales were the
> one of the first thing which I had encountered at the very begining of my
> CL voyage. :) I sent my message driven by intention just to attract
> community's attention to this topic, but didn't blame anybody.
I think you've done an excellent job of doing this. I don't want you
to feel that I don't think you have a valid concern. I just want you to
direct your energies toward the place where they should go so that it does
the most good. Contacting each vendor and making sure they are on track to
do the right thing is a good idea. Creating a discussion group among users
and vendors about this issue might be good. There are many ways you could
proceed constructively. Don't assume people are not listening or caring.
But do be tactical about how to force this very slow process forward the
right way, rather than wishing the process were different.
> And excuse me, please, for my ... not very good English. :(
Your English is quite understandable and has not been a problem for me.
Even English speakers sometimes complain that my English is too verbose,
so I'll also apologize for MY not very good English in case it's a problem
for you to translate back. The problem may not be at your end. ;)
Thanks again for raising this issue, and I hope you'll feel free to cite
more examples for discussion. Even just knowing which functions and
functionalities are broken in Lisp by language issues (even if we don't
plan to fix them) is a service to the community...
Disclaimer: Of course, none of what I say should or should not be
fixed is the official statement of any committee. I used to be on the
(X3)J13 committee but no longer am. Even when I was on the committee,
I was not its spokesperson, and I most definitely am not now its
spokesperson. These are just my personal views throughout, and not the
official position of anyone but me... maybe not even always that.
From: Aleksandr Skobelev
Subject: Re: Beginner question: performance problems with a simple program
Date:
Message-ID: <he811a.c41.ln@hermit.athome>
Kent M Pitman <······@world.std.com> wrote:
> Aleksandr Skobelev <·········@mail.ru> writes:
>
>> Well, I don't think that there is need to intuit the language of
>> the query to interpret replies properly in YES-OR-NO-P. Probably,
>> it is enough just to allow to set strings for yes/no replies (for
>> example through some specail variables called *yes-reply*,
>> *no-reply*...) and leave the problem of language synchronization in
>> query/reply for programmer.
>
> I don't agree that this would make the language stronger.
I'm not sure that I understand well what it means "to make language
stronger". But if there is possibility for seting a query string in
YES-OR-NO-P why don't add possibility for setting a reply string? At
least, it looks more regular and consistent for me. It is a far too
much simpler than to leave for vendor to guess how will "yes"/"no"
replies look like. And it is give to programmer a more freedom.
So, I must admit here that I don't understand your adherence to the
"vendor's generated replies" variant.
> First, you are failing to distinguish, as I asked you do, things that the
> language keeps from happening from things the language merely does not
> force to happen. The language definition does not say an implementation
> should not do this. HOWEVER, if the language definition *did* do this,
> it would be a weaker language.
It might be. I'm not sure that I understood your query in your
previous message and I'm not sure that I understand it now. If return
back ang use "omission"/"bad foundation" terminology then I don't see
any "bad foundations" in ANSI CL standard which concerned localisation
problem. But I think that there are some "omissions" in the standard
(that could be done intentionally). (I don't tell about YES-OR-NO-P or
~R here. They both can be left just for historical reasons and there
is ~/ directive also as you wrote below.) IMHO the current version of
the standard just leave to a vendor the decision to support
international languages or not. Below is just a quote from
http://www.xanalys.com/software_tools/reference/HyperSpec/Body/13_aa.htm:
"Common Lisp ALLOWS an implementation to provide support for
international language characters as well as characters used in
specialized arenas (e.g., mathematics)."
I would think that international standard should REQUIRE such
behaviour, because any vendor now has right don't support
international languages and still claims that his implementation is
conformed with ANSI CL standard. Am I wrong?
> You appear to be assuming (in both cases incorrectly) BOTH that (1)
> YES-OR-NO-P cannot accept such responses now and (2) YES-OR-NO-P works
> by textual typein. As to point 1, a conforming, correctly localized
> implementation of Lisp, is already permitted to do what you say. That
> is, what stands between you and success is not the language definition
> but your vendor's choice of how to render the language spec into a
> language implementation. But as to point 2, some vendors work by asking
> a textual query in which "yes" or "da" might be 'yes' answers *already*
> and "no" or "nyet" might be 'no' answers *already*. Now, if the
> language required so simple an interface as you provide, *yes-reply*
> could only contain one value, not many, and so you'd be eliminating
> valid replies. At minimum, you'd want a list of yes replies. But then
> in that case, the implementations where it was a dialog would not know
> what to do. In that case, how would you distinguish between whether
> (yes-or-no-p "Exit?") and (yes-or-no-p "Salir?") producing:
>
> Exit? Salir?
> vs
> [Yes] [No] [Si'] [No]
>
>
> (english) (spanish)
>
> The heuristic guessing of language (especially based on a small number of
> letters) would be impossible to do reliably. Certainly it would not be
> able to tell whether to do even something like:
>
> Comer? Comer?
> vs
> [Si'] [No] [Sim] [Na~o]
>
>
> (spanish) (portuguese)
>
> much less someting like this :) ...
>
> 42? 42?
> vs
> [Yes] [No] [HIja'] [ghobe']
>
> (federation standard) (klingon)
>
Isn't the follow simpler?
(setf *yes-reply* '("Si'" "si'" "s"))
(setf *no-reply* '("No"))
...
(when (yes-or-no-p "Salir?") (exit))
* Salir? (Si'/No) No
...
(setf *yes-reply* '("Yes" "yes" "yep"))
...
(when (yes-or-no-p "Exit?") (exit))
* Exit? (Yes/No) Yes
No need in any heuristics here. Well, only one is needed: which word
from yes/no-replies list do we print in our query. I offer to print
first. :)
> The thing to understand is that these are *interface* issues and
> that such issues are explicitly not something that Common Lisp seeks
> to address in the base level of its standard. These were left to
> vendors and were intended to be the subject of separated (perhaps
> layered) standards. They are INAPPROPRIATE to standardize in a
> context where the space of interface concerns cannot be known
> because each such interface concern creates a nuance that cannot, a
> priori, be known.
>
> In the future, there will also be voice and visual gesture
> interfaces, and CL does not address those either. If you have Star
> Trek movies over there, think of YES-OR-NO-P as an antique
> interface, like Scotty uses in Star Trek IV, to talk to the
> bootstrap version of a system, in order to get it into application
> mode where other interfaces, not defined by the base layer, are
> available. It is IMPORTANT that Common Lisp does not pretend to
> address those other layers because it will SURELY FAIL to do them
> right and may trick implementors into thinking it has an answer that
> works, when it does not... just as you have already been tricked
> into thinking that YES-OR-NO-P is ever going to be the answer to the
> kinds of issues you are raising.
>
You want too much from such a simple function as YES-OR-NO-P. :)
> I say again: The correct solution to this problem is simply to
> IGNORE the presence of YES-OR-NO-P except for simple applications
> written in "federation standard" (i.e., English), the like-it-or-not
> interchange language of the modern world.
>
>> So, I think, YES-OR-NO-P in its current state is not very useful in
>> any program which intended for non-English user, who works with
>> non-English keyboard mainly.
>
> Yes, certainly. But that does not call for it to be fixed. It
> calls for it to be deprecated. The space of tools required to
> really address the non-English user is a space probably as large as
> the present language in its entirety.
>
>> IMHO it is not convinient, at least, because such user need to
>> switch the keyboard to English and back every time he/she need
>> reply on YES-OR-NO-P query.
>
> This is just a bug in your implementation, brought on by your
> specific vendor not caring about your locale. The language does NOT
> require this. PLEASE distinguish LANGUAGE from IMPLEMENTATION.
> These are utterly different things.
Is it a bug or just behaviour allowed by the standard? I'm not sure.
> ...
>> If we spoke about an implementation of "international"
>> functionality of ~R directive, I would try to offer a some leverage
>> with ability to pass a list of user arguments to ~R that then could
>> be passed to some callback function (that could be set by a
>> programmer) to get a proper form for ordinal number.
>
> This would get very messy, to the point that just using ~A or ~/ and
> giving the right information would be better. Those capabilities
> are already there.
Aga! I have missed the ~/!
>
> And before considering Russian, consider even the simple mess that
> the British and the Americans don't entirely agree on the meaning of
> the "English" word "billion" so that detecting whether an error has
> occurred is extraordinarily hard if you ever even hint that ~R's
> purpose might be to satisfy localization constraints.
>
>> Again, I don't speak that this functionality is needed. I think
>> this is just some convenient tools in the language. If they were
>> absent, nobody told about them. But, on the other hand, if they
>> were added, why didn't they have done more extendable?
>
> Because it was understood from the outset that (a) the language was
> not seeking to be a translation tool and (b) doing it Right is very
> hard. Doing translation is an art or a heuristic, but is not a
> deterministic activity. CL is a language, and so seeks to be
> deterministic. These goals come into conflict if the meaning of the
> linguistic terms is not simple.
>
> There may even have been some US-bias in the design. For that I
> apologize.
No need in any apologize here. It is very explainable and naturally.
> But in fairness, the US *did* design the language and
> our culture is, I think, due some small historical accomodation to
> keeping its programs running while stretching to embrace the new
> global market. It's not like the present definition of ~R really
> breaks existing programs when compiled in Russian. Existing
> programs were ALREADY broken because they do things like:
> (write-string "Hello World") instead of
> _ _
> (write-string "| |p|/|BeT M|/|pOBo| O"), even without worrying about
> what the world is going to say in response. [Sorry about the
> character set problem there. And I hope I didn't say anything
> offensive--I was just working from online phrasebooks. :-]
Nothing offensive. I must admit that I didn't understand at the first
glance. Only when I looked at it more carefully. :) It should be
_
(write-string "| |p|/|BeT, M|/|p!")
or with transliterating with 7-bit ASCII ('i' as in "keep")
(write-string "Privet, Mir!") :)
>
>> The more important thing is, of course from my point of view, ability to
>> set a proper charset.
>
> Again, an implementation issue. The standard cannot require
> this. Even in a properly internationalized implementation, there are
> some very complex issues about how to trade off true generality for
> efficiency. If we required Unicode (or better), we might be keeping
> some implementations that don't seek that market from being
> efficient. Even the input we saw from the Japanese standards groups
> seemed to me to indicate that they were not going to rush to make
> every implementation take their full pictogram character set in
> every circumstance. I don't think we yet have the global agreement
> to know what the right way to handle this is. In my opinion, and
> I'll even say it stronger here because I do believe this strongly,
> in my considered professional opinion, one must FIRST see some
> successful vendor-specific attempts at this AND one must observe
> that all the vendors agree on a common way of doing this before we
> go saying "this is the right way" and "this is the wrong way" by
> putting something like this in the standard. At this stage of our
> global-community-shared-cultural-understanding of this complex
> situation, I believe we do not have the wisdom to lock in a single
> way to do this and it would be VERY BAD to do so. This is NOT to
> say that I don't understand your need. I'm just saying you are
> criticizing the wrong people and so working against your own need.
> Talk to your VENDOR (by which I mean either whoever sold you your
> lisp or whoever made the lisp, if it was "free"). It is their
> responsibility to help you at this point. The responsibility of the
> language at this point is merely to not do things that would make a
> vendor implementation non-conforming merely for wanting to help you.
I don't think that standard can't require from implementations an
existence of leverage for manipulating with charsets and other
locales' settings. There is setlocale() API in POSIX.1 standard. IMO
it works well enough. If we talk about efficiency then I think that the
COMPLEX and BIGNUM types are not very efficient ones but they are in
standard because, as I understand, it is convinient and a "right
thing".
I'm not criticizing anybody. A great job has been done with the
standard. But there are some "omissions" in the one, which (from my
point of view) don't allow to call it "a true international standard"
just because it give vendors a right to ignore needs of
"international" users. But because this standard doesn't prevent
vendors to provide a support for international languages, I would
offer to call it "A SOFT INTERNATIONAL STANDARD". :)
After all the language is really wonderful (ever it is not an
ideal). :) So, lets talk with vendors...
> ...
Aleksandr Skobelev <·········@mail.ru> writes:
> Aleksandr Skobelev <·········@mail.ru> wrote:
> > ... Below is just a quote from
> > http://www.xanalys.com/software_tools/reference/HyperSpec/Body/13_aa.htm:
>
> Proper link is
> http://www.xanalys.com/software_tools/reference/HyperSpec/Body/sec_13-1-1.html
The "Body/13_aa.htm" reference is the more compact URL used by
versions 5 and up of the CLHS, all names for which work even in an DOS
file system. (Section numbers never went above 26, so I used a for .1,
b for .2, etc. so 13_aa is 13.1.1 ...)
But you're right, Xanalys has a pre-v5 CLHS on its web site.
From: Rob Warnock
Subject: later CLHS [was: Re: Beginner question: performance...]
Date:
Message-ID: <a1454a$uhp0$1@fido.engr.sgi.com>
Kent M Pitman <······@world.std.com> wrote:
+---------------
| The "Body/13_aa.htm" reference is the more compact URL used by
| versions 5 and up of the CLHS, all names for which work even in an DOS
| file system. (Section numbers never went above 26, so I used a for .1,
| b for .2, etc. so 13_aa is 13.1.1 ...)
|
| But you're right, Xanalys has a pre-v5 CLHS on its web site.
+---------------
So... Where does one get a more recent version of the CLHS?
-Rob
-----
Rob Warnock, 30-3-510 <····@sgi.com>
SGI Network Engineering <http://www.meer.net/~rpw3/>
1600 Amphitheatre Pkwy. Phone: 650-933-1673
Mountain View, CA 94043 PP-ASEL-IA
[Note: ·········@sgi.com and ········@sgi.com aren't for humans ]
From: Dr. Edmund Weitz
Subject: Re: later CLHS [was: Re: Beginner question: performance...]
Date:
Message-ID: <vgeinwtq.fsf@agharta.de>
····@rigden.engr.sgi.com (Rob Warnock) writes:
> Kent M Pitman <······@world.std.com> wrote:
> +---------------
> | The "Body/13_aa.htm" reference is the more compact URL used by
> | versions 5 and up of the CLHS, all names for which work even in an DOS
> | file system. (Section numbers never went above 26, so I used a for .1,
> | b for .2, etc. so 13_aa is 13.1.1 ...)
> |
> | But you're right, Xanalys has a pre-v5 CLHS on its web site.
> +---------------
>
> So... Where does one get a more recent version of the CLHS?
You've got to download the trial version of LispWorks from Xanalys'
website. See
<http://groups.google.com/groups?selm=sfwvgftux7g.fsf%40shell01.TheWorld.com>.
Edi.
From: Erik Naggum
Subject: Re: Beginner question: performance problems with a simple program
Date:
Message-ID: <3219064036755833@naggum.net>
* Aleksandr Skobelev <·········@mail.ru>
| But if there is possibility for seting a query string in YES-OR-NO-P why
| don't add possibility for setting a reply string? At least, it looks
| more regular and consistent for me. It is a far too much simpler than to
| leave for vendor to guess how will "yes"/"no" replies look like. And it
| is give to programmer a more freedom. So, I must admit here that I don't
| understand your adherence to the "vendor's generated replies" variant.
Just define a new function that does what you think it should do. Why is
this so hard for you to accept? Why must you complain that somebody else
has done something that is satisfactory for them?
Just _do_ it! Quit your useless whining and write specifications for the
functions you need, then implement them. That you cannot get it for free
is not anybody else's problem.
If the conclusion is that Common Lisp is unsuitable for international
applications without _additional_ localization support, that would be a
point from which we could progress. If people complain endlessly that
what it does is _wrong_, we have no point from which progress can be
made, because some people are happy with what it does and do _not_ think
it is doing anything wrong, so you would effectively secede in order to
get _your_ natural-language support. This is insane.
Write a white paper on how to write properly localized Common Lisp code
if you are _actually_ concerned about this, not just about hearing
yourself whine in public. Deliver a paper at a conference, get people
who have worked in this field for years to help you if you want to have
the work done. Be prepared to see that your particular culture becomes
"one of many" without privileges, and be prepared to understand that
American English is _not_ privileged today, either. There is nothing
here to whine about, just useful work that needs to be done. Just Do It.
If you do not want to do the work, please let us know. A good way to do
this would be keep whining uselessly about things you do not understand.
///
--
From: Aleksandr Skobelev
Subject: Re: Beginner question: performance problems with a simple program
Date:
Message-ID: <43p11a.bk.ln@hermit.athome>
Aleksandr Skobelev <·········@mail.ru> wrote:
> ... Below is just a quote from
> http://www.xanalys.com/software_tools/reference/HyperSpec/Body/13_aa.htm:
Proper link is
http://www.xanalys.com/software_tools/reference/HyperSpec/Body/sec_13-1-1.html
Aleksandr Skobelev <·········@mail.ru> writes:
> "Common Lisp ALLOWS an implementation to provide support for
> international language characters as well as characters used in
> specialized arenas (e.g., mathematics)."
>
> I would think that international standard should REQUIRE such
> behaviour, because any vendor now has right don't support
> international languages and still claims that his implementation is
> conformed with ANSI CL standard. Am I wrong?
People will differ on how to answer this, but I think the most light will
be shed on this complex issue if I take the most extreme point of view, so
I will just boldly and for purposes of a friendly argument say:
Yes.
I don't know if it will help or hurt to allude to the cultural divide
between the capitalist/libertarian state and the socialist/communist state,
but I'm going to try to allude to this just in case. It MAY actually be
that because of the historical difference between your country and ours,
you see this issue differently than we do. I'm not going to try to assert
rightness or wrongness of either system here, but rather use the differences
in point of view to show how, in context (i.e., in a situation where you take
the rightness of one or the other world model as an axiomatic given),
the answer to your question above might come out different.
I sometimes refer to the language design community as the "benevolent state"
making all kinds of rules for how people should behave. But rules are not
implementations. Making a rule that says "everyone will be fed" does not
make them fed. What makes them fed is feeding them. Rules do get broken.
And when you make a rule that all CL implementations must provide feature X,
SOMETIMES you get a lot of implementations with feature X, and other times you
get SOME conforming implementations with feature X and some non-conforming
(i.e., would-be conforming) implementations without feature X.
Certainly we tried in the design of the language to require a LOT of vendors.
We though this would stretch the set of things vendors would do. But we
could not, through our votes, make vendors have infinite money/patience,
and so there is a limit to what we can do.
For what it's worth, I call this model of language design, where the people
expect all implementations to implement the standard, and the standard is
dictated by philosophically inclined people without regard to to cost, the
"socialist" design principle. I think it has traditionally worked, but mostly
because it used to be that vendors had large amounts of money and the bulk
of programmer resources. Over time, the wealth and programmer talent has
moved a lot to the market. Increasingly, over time, I have felt that users
should look not to governmental bodies but to the entreprenuerial marketplace
for solutions. I call this a "capitalist" design principle.
The good thing about the socialist model is that everyone doing CL has
certain properties. The bad thing is you ahve created a bar so high
that not everyone can do a CL. The good thing about the capitalist model
is that more people are offering CL, but the bad thing is that there are
more differences in what that means.
I like the capitalist model better these days, though I'm glad we went
through the other model getting to where we are because it gives us a large
base to build upon. I think the capitalist model acknowledges that some
parts of the market don't NEED all that might be required, and so it allows
partial implementations to compete in places where they match features offered
with features requiresd.
Suppose we *did* require every CL implementation to have international
char set support and suppose I had an application that didn't need it.
I might *still* buy the same lisp to do it, the only thing that would
be changed is that it wouldn't be marketed as a conforming CL under
your proposed standard because it had no support for the feature I
didn't need. By contrast, if I need international char set support
now and some implementations don't have it, I don't just buy the
deficient implementation EVEN IF it satisfies the spec. An
implementation, to get bought by me, needs to satsify not only
standards but MY requirements.
So when the dust all settles, I think the only question which materially
remains is this: to what extent are vendors encouraged by the withholding
of the word "conforming" if you increase the set of requirements vs. to what
extent is the community fragmented by denying the word "conforming" in cases
where it will not be met.
For example, we do not require a compiler right now in CL. Most
implementations provide one but it's left to the market. We could
require one. But what would that serve but to tie the hands of
vendors? A vendor who has enough customers without a compiler might
as well continue in that market if they're happy. It steals nothing
from anyone else, and the sense of community size is enlarged by our
embracing that activity. To make an ivory tower that no one can climb
might raise our level of respect among some, but it might exclude
others. I just don't see doing it. But I can understand how another
might think differently. In the end, I think it has to come down to
differences of political theories about how to motivate people. Just
as in business the Theory X/Theory Y debate rages about whether
carrots held in front of employees or sticks waved behind them are
better ways to motivate good work. The fact is that there is no clear
answer. At least with employees, you can come up with solutions on a
case-by-case basis. With standards, the complication is that you
either do or don't conform...
- - - -
Moving on, my words are the double-indented ones here:
> > In that case, how would you distinguish between whether
> > (yes-or-no-p "Exit?") and (yes-or-no-p "Salir?") producing:
> >
> > Exit? Salir?
> > vs
> > [Yes] [No] [Si'] [No]
> >
> >
> > (english) (spanish)
> >
> > The heuristic guessing of language (especially based on a small number of
> > letters) would be impossible to do reliably. Certainly it would not be
> > able to tell whether to do even something like:
> >
> > Comer? Comer?
> > vs
> > [Si'] [No] [Sim] [Na~o]
> >
> >
> > (spanish) (portuguese)
> >
> > much less someting like this :) ...
> >
> > 42? 42?
> > vs
> > [Yes] [No] [HIja'] [ghobe']
> >
> > (federation standard) (klingon)
> >
>
> Isn't the follow simpler?
>
> (setf *yes-reply* '("Si'" "si'" "s"))
> (setf *no-reply* '("No"))
> ...
> (when (yes-or-no-p "Salir?") (exit))
> * Salir? (Si'/No) No
> ...
> (setf *yes-reply* '("Yes" "yes" "yep"))
> ...
> (when (yes-or-no-p "Exit?") (exit))
> * Exit? (Yes/No) Yes
>
> No need in any heuristics here. Well, only one is needed: which word
> from yes/no-replies list do we print in our query. I offer to print
> first. :)
Actually, the part about what to print is the whole thing I was trying
to get to. It's more complex than that. You're again assuming that the
choices are only "print" / "don't print". What if another interface
shows all the choices? That is, it shows
To reply yes, enter one of: Si', si, s
To reply no, enter one of: No, n
In some cases, people would want to provide a different list if they thought
someone would see it than if they didn't. For example, I might use
(... "si", "si'", "s'i" ...)
if it were not to be presented, but (a) some users would be offended/confused
to see these stupid presentations of accents and I might want to suppress
them (allowing fewer possible responses) if I thought they would be seen
than if I thought not, and (b) some users would be very confused by "si" since
it means "if". A lazy user might write "si" to mean "si'" if prompted for
"si'" or "no", but no user would want to see "si" because it would suggest
that you were saying "reply yes (or if) or no".
So what I'm saying is that your remark about "print" is the only
question to be asked, and I'm assuming it's a more complex space.
That is, that the question of what to print in a dialog is only the
tip of the iceberg. Rather than patch the TITANIC-YES-OR-NO-P
function to ferry passengers another day, I'd rather it sink in the
icy waters of the north atlantic (though, of course I'd send someone
to pick up the people lifeboats) and that a better replacement be
built.
> > In the future, there will also be voice and visual gesture
> > interfaces, and CL does not address those either. If you have Star
> > Trek movies over there, think of YES-OR-NO-P as an antique
> > interface, like Scotty uses in Star Trek IV, to talk to the
> > bootstrap version of a system, in order to get it into application
> > mode where other interfaces, not defined by the base layer, are
> > available. It is IMPORTANT that Common Lisp does not pretend to
> > address those other layers because it will SURELY FAIL to do them
> > right and may trick implementors into thinking it has an answer that
> > works, when it does not... just as you have already been tricked
> > into thinking that YES-OR-NO-P is ever going to be the answer to the
> > kinds of issues you are raising.
> >
>
> You want too much from such a simple function as YES-OR-NO-P. :)
And here I thought the same of you. :)
> >> IMHO it is not convinient, at least, because such user need to
> >> switch the keyboard to English and back every time he/she need
> >> reply on YES-OR-NO-P query.
> >
> > This is just a bug in your implementation, brought on by your
> > specific vendor not caring about your locale. The language does NOT
> > require this. PLEASE distinguish LANGUAGE from IMPLEMENTATION.
> > These are utterly different things.
>
> Is it a bug or just behaviour allowed by the standard? I'm not sure.
It is a conforming behavior.
However, it is still a bug in the vendor implementation.
Not because of the standard, but because of common sense (in the absence
of a standard that requires you not to use common sense).
> Aga! I have missed the ~/!
:-)
> ...
> > But in fairness, the US *did* design the language and
> > our culture is, I think, due some small historical accomodation to
> > keeping its programs running while stretching to embrace the new
> > global market. It's not like the present definition of ~R really
> > breaks existing programs when compiled in Russian. Existing
> > programs were ALREADY broken because they do things like:
> > (write-string "Hello World") instead of
> > _ _
> > (write-string "| |p|/|BeT M|/|pOBo| O"), even without worrying about
> > what the world is going to say in response. [Sorry about the
> > character set problem there. And I hope I didn't say anything
> > offensive--I was just working from online phrasebooks. :-]
>
> Nothing offensive. I must admit that I didn't understand at the first
> glance. Only when I looked at it more carefully. :) It should be
> _
> (write-string "| |p|/|BeT, M|/|p!")
>
> or with transliterating with 7-bit ASCII ('i' as in "keep")
> (write-string "Privet, Mir!") :)
Yes, I figured there was some kind of transliteration one could do but I
couldn't find a dictionary of character mappings. Thanks.
So the name of the space station "Mir" means "World" then?
> > Again, an implementation issue. The standard cannot require
> > this. Even in a properly internationalized implementation, there are
> > some very complex issues about how to trade off true generality for
> > efficiency. If we required Unicode (or better), we might be keeping
> > some implementations that don't seek that market from being
> > efficient. Even the input we saw from the Japanese standards groups
> > seemed to me to indicate that they were not going to rush to make
> > every implementation take their full pictogram character set in
> > every circumstance. I don't think we yet have the global agreement
> > to know what the right way to handle this is. In my opinion, and
> > I'll even say it stronger here because I do believe this strongly,
> > in my considered professional opinion, one must FIRST see some
> > successful vendor-specific attempts at this AND one must observe
> > that all the vendors agree on a common way of doing this before we
> > go saying "this is the right way" and "this is the wrong way" by
> > putting something like this in the standard. At this stage of our
> > global-community-shared-cultural-understanding of this complex
> > situation, I believe we do not have the wisdom to lock in a single
> > way to do this and it would be VERY BAD to do so. This is NOT to
> > say that I don't understand your need. I'm just saying you are
> > criticizing the wrong people and so working against your own need.
> > Talk to your VENDOR (by which I mean either whoever sold you your
> > lisp or whoever made the lisp, if it was "free"). It is their
> > responsibility to help you at this point. The responsibility of the
> > language at this point is merely to not do things that would make a
> > vendor implementation non-conforming merely for wanting to help you.
>
> I don't think that standard can't require from implementations an
> existence of leverage for manipulating with charsets and other
> locales' settings. There is setlocale() API in POSIX.1 standard. IMO
> it works well enough.
Not that CL requires the use of Posix.
> If we talk about efficiency then I think that the
> COMPLEX and BIGNUM types are not very efficient ones
Are you comparing them to FIXNUMs and FLOATs, which are faster because they
require less, or are you comparing them to other languages that have better
ways of managing complex numbers of arbitrary precision integers. I count
efficiency as meaningful only in the context of "same computational goal".
Saying that it takes longer to add 100000000000000000000000000 and
100000000000000000000000000 than it does to add 1+1 is certainly true.
Saying, though, that such a bignum addition is inefficient doesn't seem fair
unless your offering a way of computing that same value more efficiently.
> but they are in standard because, as I understand, it is convinient
> and a "right thing".
It's provided to allow a flexibility that Lisp was already used to offering
and that it might as well satisfy. I have no real problem with BIGNUM, but
I do think the problem with COMPLEX is that it's cartesian, and that leads
to a few minor glitches becuase it precludes other solutions. Oh well.
> I'm not criticizing anybody. A great job has been done with the
> standard. But there are some "omissions" in the one, which (from my
> point of view) don't allow to call it "a true international standard"
> just because it give vendors a right to ignore needs of
> "international" users. But because this standard doesn't prevent
> vendors to provide a support for international languages, I would
> offer to call it "A SOFT INTERNATIONAL STANDARD". :)
You could look at ISO ISLISP. I don't recall it having any more strong a
requirement and, by the way, it was produced by an international
committee, much more recently. ;)
> After all the language is really wonderful (ever it is not an
> ideal). :) So, lets talk with vendors...
I'm sure when you get done with them, they'll see reason.
Aleksandr Skobelev <·········@mail.ru> writes:
> Kent M Pitman <······@world.std.com> wrote:
>
> > You could look at ISO ISLISP. I don't recall it having any more strong a
> > requirement and, by the way, it was produced by an international
> > committee, much more recently. ;)
> >
>
> Heh. We are telling here how international is ANSI CL, aren't we?
> So, don't deviate from the subject. :)
Hey, I wasn't deviating. I was citing "similarity with an ISO
standard" as [weak] "proof" that ANSI CL does what you'd get form an
international standard for Lisp....
From: Aleksandr Skobelev
Subject: Re: Beginner question: performance problems with a simple program
Date:
Message-ID: <fe241a.tr3.ln@hermit.athome>
Kent M Pitman <······@world.std.com> wrote:
> Aleksandr Skobelev <·········@mail.ru> writes:
>
>> Kent M Pitman <······@world.std.com> wrote:
>
> Hey, I wasn't deviating. I was citing "similarity with an ISO
> standard" as [weak] "proof" that ANSI CL does what you'd get form an
> international standard for Lisp....
Sorry, it was my fault. I haven't read your message carefully.
I've found Working Draft 20.3 dated the 31 March 1997.
I must admit that it contains far less requirements pertaining to support
for international languages than ANSI CL standard (to speak frankly, I
didn't find any mention about it).
By the way, it looks like ISLISP had have some influence with Dylan. They
both use <> for class names.
Aleksandr Skobelev <·········@mail.ru> writes:
> Kent M Pitman <······@world.std.com> wrote:
> > Aleksandr Skobelev <·········@mail.ru> writes:
> >
> >> Kent M Pitman <······@world.std.com> wrote:
> >
> > Hey, I wasn't deviating. I was citing "similarity with an ISO
> > standard" as [weak] "proof" that ANSI CL does what you'd get form an
> > international standard for Lisp....
>
> Sorry, it was my fault. I haven't read your message carefully.
>
> I've found Working Draft 20.3 dated the 31 March 1997.
> I must admit that it contains far less requirements pertaining to support
> for international languages than ANSI CL standard (to speak frankly, I
> didn't find any mention about it).
I had mostly mentioned this for humor value. Not that ISLISP is not a serious
standard, but I was just trying to get an ironic chuckle out of you when you
realized ANSI CL offered you better "support" (and I use the term lightly,
for the reasons you have cited) than does ISO ISLISP.
HOWEVER, it does make an important point or two about standards
committees. One might assume that such a committee will have certain
interests just because one *imagines* that they are part of the
international community and they imagine such a committee would
represent all interests. But there are some things to learn here:
- There were no Russians on the committee. So your interests specifically
had no voice. (In fairness, I think the process began in 1988 when it
might have been tough for you to either show up at meetings or to care
about Lisp at all. But it didn't get standardized until 1997, I think,
and most of the real work was in the last year or two before that. We
started over a number of times before that, never reaching consensus
on a charter.)
- Standards bodies have minds of their own. Even IF there had been
someone from Russia on that committee, he might not have gotten his way
on all things. I know, as then-US representative, the US didn't get
its way on all things. And I would bet every other organization would
say likewise. That is veritably the definition of "committee work" or
"democracy".
So if it seems odd that those of us who have not been directly involved in the
process are always calling for "more standards" and those of us who have been
involved in the process are always calling for "use of other non-standards
processes", it's probably because we who were involved are intensely aware
of how long and unpredictable a process standards work is.
And, I also subscribe to a belief someone told me a long time ago in reference
to the US Constitution and people's repeated calls for a "Second Constitutional
Convention" to "fix" its observed problems:
This person alleged that important documents which dictate how things shall
be have only one time to be written, while people are wildy idealistic and
starry-eyed, blinded to the direct consequences of what they do. [Perhaps
novices to a community afterward mistake their own starry-eyedness for
everyone's, and don't realize that others lurk who have become cynical and
selfish and divisive, even if they cannot be seen by all.] The point being
that once the cards are dealt and everyone has a stake in the game, you can't
go back and, by democracy, rewrite the rules. Because at that point, people
are no longer just trying to determine a fair playing field that will suit
them independent of their position in the new game, but they are also trying
to determine what rules will suit them personally.
It may be that in the US we have some things that we would want to make subtle
fixes to the first or second or fourth or ninth amendments to our constitution.
Maybe to the constitution as a whole. But one cannot open discussion on jsut
those questions and no other, because ther is no one to judge even why just
those questions matter, nor to judge whether a given proposal oversteps just
those questions.
With respect ot Lisp, we cannot open the standard for change on the
provision that only internationalism would change. The anti-LOOP
forces would come out, and the pro-SERIES folks, and the face of
iteration might utterly change, perhaps for the better, or perhaps
just being randomized with no better outcome--who's even fit to say?
The Lisp1/Lisp2 people would come out and insist on considering the
breaking of something. The macro hygiene people, regardless of the
Lisp1/Lisp2 outcome would probably insist that macros be reconsiderd.
Someone would probably say Lisp's parentheses need fixing and couldn't
we do infix like Dylan? People who wanted only tiny changes to this
or that arglist would come out, thinking other changes were evil, but
they wouldn't stop those other changes, they'd just add to the mess.
And eventually an almost-randomly determined subset of these
(depending on who was awake, who made the right argument, who paid to
attend, who understood the rules best and could invoke the right
procedural moves, who spoke the most compellingly just before a vote,
whose proposal had the coolest name, etc.--all those factors which
collectively we group together under the title of "democratic
fairness" ;-) would succeed. And the language would be changed "in some
way", MAYBE to include those things you wanted added when you asked the
process be opened up.
Or you could do a layered standard, clean and neat ... perhaps not even
a consensus standard. Perhaps just a document titled "This is how Aleksandr
wants it" (and I'm not meaning to suggest that would necessarily even be
bad) and you could work one by one through the vendors, getting consensus
and adoption. Personally, I'd say that this approach is cheaper, more
manageable, less error prone, more capable of responding to legitimate
needs of those you're getting consensus with, etc.
I hope this somewhat fanciful account of the standards process helps
illustrate the world as we poor, tired, no-fun standards veterans see
things and why we always seem to be raining on everyone's parade. As I
count the hands being raised, people seem to like a "standards process"
as a solution in a manner that is sort of reverse-correlated to how close
they were to the process at the time. It is easy to interpret this as
"we got it the way we want it and people who didn't get to play now want
their say", but it's hard to tell if that's really true (which it could be),
or whether it's more like "we feel like we were lucky to get out of there
with as much consensus as we got, and with any companies still having money
left after all the expense, and now people who don't understand the risk
and expense are confusing 'successful outcome once' with 'no risk ever' and
asking us to do it a second time." That could also be a proper reading,
and I have no way to tell you which is right. But my money's on the second.
And, FWIW, I have seen this same recommendation of caution come from other
vets of other standards processes, too.
> By the way, it looks like ISLISP had have some influence with Dylan. They
> both use <> for class names.
Yes, I think the similarity sort of stops there. There might be one or
two other similarities, but such would mostly be superficial.
Aleksandr Skobelev <·········@mail.ru> writes:
> >> By the way, it looks like ISLISP had have some influence with Dylan. They
> >> both use <> for class names.
> >
> > Yes, I think the similarity sort of stops there. There might be one or
> > two other similarities, but such would mostly be superficial.
> >
>
> So, it might have been only things that Dylan-representatives were able to
> get included in ISO standard? :)
Yes, perhaps.
Though I was US representative, and Dylan work is primarily in the US,
and my charter was to represent the Lisp camp, not the Dylan camp.
As it happened, in my discretionary role as a technical participant, I
voted AGAINST that particular feature you cite. I would have voted in
favor of either names in the variable namespace named by <classname>
holding classes OR a subform naming another namespace with
(class classname), but I thought it foolish (and still do) to
require that you do all of: (a) put (class ...) around the name,
(2) name the class with angle brackets, as <classname>, and (3) give it
a separate namespace. That seemed redudant and ugly to me.
········@acm.org writes:
> Aleksandr Skobelev <·········@mail.ru> writes:
> > Kent M Pitman <······@world.std.com> wrote:
> > >> By the way, it looks like ISLISP had have some influence with
> > >> Dylan. They both use <> for class names.
>
> > > Yes, I think the similarity sort of stops there. There might be
> > > one or two other similarities, but such would mostly be
> > > superficial.
>
> > So, it might have been only things that Dylan-representatives were
> > able to get included in ISO standard? :)
>
> No, more likely they decided to pick <> for similar reasons. It does
> not mandate that there was any conscious communication between the
> makers of the respective "standards" about the issue.
Could be, but I'm pretty sure <>'s were picked because Dylan had used them
and someone thought it looked cool. Dylan does not, however, require one
to write class(#"<integer>") in order to obtain the integer class object,
though, which IMO defeats the coolness, just as doing (class <integer>)
in ISLISP does. Mostly I think ISLISP is fairly aesthetic, even though
terribly spartan. But this is a place I think it goofed.
From: Aleksandr Skobelev
Subject: Re: Beginner question: performance problems with a simple program
Date:
Message-ID: <ei651a.8c1.ln@hermit.athome>
Kent M Pitman <······@world.std.com> wrote:
...
> I hope this somewhat fanciful account of the standards process helps
> illustrate the world as we poor, tired, no-fun standards veterans see
> things and why we always seem to be raining on everyone's parade.
...
At least it was very interesting. Thanks.
>> By the way, it looks like ISLISP had have some influence with Dylan. They
>> both use <> for class names.
>
> Yes, I think the similarity sort of stops there. There might be one or
> two other similarities, but such would mostly be superficial.
>
So, it might have been only things that Dylan-representatives were able to
get included in ISO standard? :)
Aleksandr Skobelev <·········@mail.ru> writes:
> Kent M Pitman <······@world.std.com> wrote:
> >> By the way, it looks like ISLISP had have some influence with
> >> Dylan. They both use <> for class names.
> > Yes, I think the similarity sort of stops there. There might be
> > one or two other similarities, but such would mostly be
> > superficial.
> So, it might have been only things that Dylan-representatives were
> able to get included in ISO standard? :)
No, more likely they decided to pick <> for similar reasons. It does
not mandate that there was any conscious communication between the
makers of the respective "standards" about the issue.
--
(concatenate 'string "aa454" ·@freenet.carleton.ca")
http://www3.sympatico.ca/cbbrowne/rdbms.html
Never put off until tomorrow what you can put off indefinitely.
From: Aleksandr Skobelev
Subject: Re: Beginner question: performance problems with a simple program
Date:
Message-ID: <i6321a.771.ln@hermit.athome>
Kent M Pitman <······@world.std.com> wrote:
>
> ...
>
> I don't know if it will help or hurt to allude to the cultural divide
> between the capitalist/libertarian state and the socialist/communist state,
> but I'm going to try to allude to this just in case.
...
[
Here were thoughts about socialist/capitalist models of language
development. I removed them after very long thoughts because of their
size.
Definitly, Kent, you should write a short resume after every such a tale
which resume could be used in replies by yours correspondents.
] :)
It was very interesting.
OK. I see your point. I can not tell that I agree with it absolutly (may
be I have to read it again) but I admit that it at least have a right for
a life. :)
...
>>
>> Isn't the follow simpler?
>>
>> (setf *yes-reply* '("Si'" "si'" "s"))
...
>>
>> No need in any heuristics here. Well, only one is needed: which word
>> from yes/no-replies list do we print in our query. I offer to print
>> first. :)
>
> Actually, the part about what to print is the whole thing I was trying
> to get to. It's more complex than that. You're again assuming that the
> choices are only "print" / "don't print". What if another interface
> shows all the choices? That is, it shows
>
...
> So what I'm saying is that your remark about "print" is the only
> question to be asked, and I'm assuming it's a more complex space.
> That is, that the question of what to print in a dialog is only the
> tip of the iceberg. Rather than patch the TITANIC-YES-OR-NO-P
> function to ferry passengers another day, I'd rather it sink in the
> icy waters of the north atlantic (though, of course I'd send someone
> to pick up the people lifeboats) and that a better replacement be
> built.
OK. Let it sink. :)
Definitly, you, Kent, are a Partisan of "The Right Thing". :)
But might be "worse is better"?
>
...
>> You want too much from such a simple function as YES-OR-NO-P. :)
>
> And here I thought the same of you. :)
OK. Draw. :)
>
...
>
> So the name of the space station "Mir" means "World" then?
I think the name means "Peace" which is an other meaning for "Mir".
I wrote "think" because the correct meaning might be given by people only
who named the station.
>
...
>
>> If we talk about efficiency then I think that the
>> COMPLEX and BIGNUM types are not very efficient ones
>
> Are you comparing them to FIXNUMs and FLOATs, which are faster because they
> require less, or are you comparing them to other languages that have better
...
I'm comparing them to FIXNUMs and FLOATs.
...
>
> You could look at ISO ISLISP. I don't recall it having any more strong a
> requirement and, by the way, it was produced by an international
> committee, much more recently. ;)
>
Heh. We are telling here how international is ANSI CL, aren't we?
So, don't deviate from the subject. :)
From: Aleksandr Skobelev
Subject: Re: Beginner question: performance problems with a simple program
Date:
Message-ID: <gnsu0a.h31.ln@hermit.athome>
Kent M Pitman <······@world.std.com> wrote:
> Aleksandr Skobelev <·········@mail.ru> writes:
> ...
>
>> IMHO ANSI CL
>> standard is lacking in support for locales/charsets. So any non-Latin-1
>> user might encounter with some problems/inconviniences ever with
>> commercial realisations (such as Allegro 6.?, Lispwork 4.1.20). And when I
>> think about some funny features in the language like YES-OR-NO-P or ~R in
>> FORMAT, I understand that they were designed with English taken in
>> consideration only.
>
> Certainly you are right if you mean that it is lacking service
> functions for locales and charsets, but we made the design pretty
> general in a way that I think doesn't fight an implementation that
> wants to pursue these issues. If you find that's not so, it would be
> an interesting topic of discussion to hear what specific
> representational requirements are keeping you from having what you
> want.
>
> Individual implementations may indeed fall short, but before blaming
> the spec for this, you should try to find the place in the spec that
> REQUIRES such implementations to fall short. It's possible to happen,
> in principle, but I think it's not there in most cases...
>
> As to the issue of English bias, I think this: Because English is the
> international interchange language (we're speaking it now, after all),
> there is some reason to indulge some accomodations to it. If I were
> to propose fixing things, it would mostly be to remove the offending
> features, not to internationalize them. The problem is that those
> features are mostly weak even for their support of English, and are
> probably just bad ideas. They were in there as accomodations to
> history, since old code used them. And the cost of ignoring them is
> small.
>
> IMO, proper support of these things for international purposes (to
> include proper support for English) would be better to proceed as a
> layered library standard, and I don't see any representational nor
> protocol barrier to doing such things in an implementation that
> commercially favors an international market.
>
> The Japanese national body presented a report to the US just prior to
> our putting out the standard, asking for a small number of detailed
> changes to accomodate their internationalization needs. The US rushed
> to fully accomodate their list of minimal necessary changes. I have
> never heard a subsequent complaints that the changes we made were
> insufficient. CLEARLY, there was work left to implementations and to
> other layered standards, but IMO it's important to understand that
> that will always happen.
>
> So I'm not trying to assert that there are no bugs in CL that would be
> a problem to internationalization. I'm trying to say that I try to
> listen when people raise this issue because I USED TO think that CL
> was enough deficient in this are that we would be forced to fix it at
> some point. But over time I have come to the belief that the core
> design is good enough that it can probably stand, at least for now.
> And I'm asking you to do two things, Aleksandr, in order to be most
> helpful here:
>
> * Make your criticisms more precise so that those of us who don't
> experience the day-to-day issues that you do can better understand
> what you are up against. Many of us suffer from lack of day-to-day
> familiarity with the problems at all and have to stretch our brains
> to know what you're up against. Although I can imagine a problem with
> YES-OR-NO-P in Russian, it's not obvious to me what that is. I imagine
> (yes-or-no-p "Exit?") or (yes-or-no-p "Salir?") or ... to work in
> just about any language; I don't see any internationalization issue
> here that is different than (format t "~&Exit?~%") vs
> (format t "~&Salir?~%"). [Pardon my use of Spanish as an example,
> I don't speak Russian.] THe only problem I can even imagine is that
> a pop-up dialog might need to know whether to put clickboxes that said
> [Yes]/[No] or [Si']/[No] and in order to know this, it would need to
> intuit the language that the query was presented in, so as not to have
> the question asked in one language but the answer offered in another.
> This is a problem, but again I can't see how it's much different than the
> overall problem that CL uses inline strings in code rather than
> references to resource vectors of translatable strings. I don't see that
> problem as YES-OR-NO-P specific. So maybe you could help us by working
> an example for each such thing you complain about. Thanks...
>
> * Distinguish in your criticisms between omission and bad foundation.
> A feature which is merely omitted (and there are many) can be added
> compatibly. If our design is a bad foundation, then something about
> an existing requirement must be fixed first to move on, correcting a
> hill-climbing problem.
>
> Thanks for your help in keeping the discussion focused.
Well, I don't think that there is need to intuit the language of the query
to interpret replies properly in YES-OR-NO-P. Probably, it is enough just
to allow to set strings for yes/no replies (for example through some
specail variables called *yes-reply*, *no-reply*...) and leave the problem
of language synchronization in query/reply for programmer.
So, I think, YES-OR-NO-P in its current state is not very useful in any
program which intended for non-English user, who works with non-English
keyboard mainly. IMHO it is not convinient, at least, because such user
need to switch the keyboard to English and back every time he/she need
reply on YES-OR-NO-P query. It is, of course, is not a problem, because
such functionality can be implemented very easy. It is just a little
inconvenience.
If we spoke about an implementation of "international" functionality of ~R
directive, I would try to offer a some leverage with ability to pass a
list of user arguments to ~R that then could be passed to some callback
function (that could be set by a programmer) to get a proper form for ordinal
number.
Again, I don't speak that this functionality is needed. I think this
is just some convenient tools in the language. If they were absent, nobody
told about them. But, on the other hand, if they were added, why didn't they
have done more extendable?
The more important thing is, of course from my point of view, ability to
set a proper charset. Without that functions for manipulating strings and
characters don't work properly. So STRING-UPCASE for example doesn't not
work with Russian in Lispwork 4.1.20 Personal Edition, CMUCL. There is
SET-LOCALE function in Lispwork but only "C", "POSIX" and "*.ISO-8859-1"
locales exist. If my memory serves me, there are same situation in Allegro
6.x (i.e. SETLOCALE exists but number of localies is limited by
C/POSIX/*.ISO-8859-1)? But because I don't have Allegro on my computer
now, I can make a mistake here.
Again, It might be not a problem but just a little inconvenience.
Because, I suspect that correspondent localies can be added to both
Lispwork and Allegro. And it is not a very hard ever for such a beginner
as me to implement a basic SETLOCALE functionality in CMUCL using existing
Alien interface.
I don't blame anybody or anything. I think that a great job was done with
the standard. I can understand vendors who probably have had most of their
customers in English-spoken countries. So there were not value reasons for
them to harry up with implementation of functionality that was not part of
the standard.
Thank you and all others senders who reply on my message. I have been
reading this newsgroup regulary enough and I have never seen before a
discussion of that topic. But these little problems with locales were the
one of the first thing which I had encountered at the very begining of my
CL voyage. :) I sent my message driven by intention just to attract
community's attention to this topic, but didn't blame anybody.
And excuse me, please, for my ... not very good English. :(
From: Erik Naggum
Subject: Re: Beginner question: performance problems with a simple program
Date:
Message-ID: <3218979212046865@naggum.net>
* Aleksandr Skobelev <·········@mail.ru>
| So, I think, YES-OR-NO-P in its current state is not very useful in any
| program which intended for non-English user, who works with non-English
| keyboard mainly.
Why, then, did you write the call to that function in the first place?
I see another case of blaming the language for failing to be convenient
_enough_ and trying to blame some cultural artifact that the _programmer_
has not been able to figure out is not going to do what he wants.
It is great that Common Lisp is usable by us "furriners", but when I was
faced with the inability of Allegro CL 4.3 to deal with case issues in
ISO 8859-1, I spent some time fixing this problem locally, and repeated
this for Allegro CL 5.0 so it would work in my application, which used
and required ISO 8859-1 to work properly. It was not particularly hard.
However, I did not attempt to make format control ~P work for Norwegian.
I did not use yes-or-no-p in the Norwegian user interface. I did not
expect a language I have learned and studied suddenly to become plastic
and turn into something it is not just because I wished for it.
I actually find it completely incredulous that otherwise seemingly smart
programmers suddenly get a case of "wishful thinking syndrome" and fail
to understand that a programming language is what it is. If the language
does not fulfull your childhood dreams, at least try to figure out if it
is actually blocking you from realizing them _with_ it. If so, drop it
and find another language that does not block your dreams. If, however,
the language just falls short of some egoistic "ideal" that you think you
have right to complain that the world does not fulfull for you, you have
a _much_ bigger problem than the failure of yes-or-no-p to speak Russian.
Programming is about making new things possible, about realizing dreams,
about _creating_ dreams. I get so fucking _tired_ of the whining losers
who expect languages and environments and computers in general to relieve
them of having to exert any effort at all to get what they want, and who
get _sore_ when the languages refuse to do their bidding. Sore losers
who fail to grasp that they world does not owe them a thing come out as
exceptionally demanding assholes who cannot tolerate that they have to do
some of the work themselves.
Common Lisp is one of the languages in the world that offer programmers
_so_ much for free already, but what happens? Again and again, whining
losers gang up on it for not offering them enough. Even thinking about
making something useful on their own instead of whining is beyond these
people, so it is all fault-finding instead of doing something new and
useful. This is probably the biggest difference between the Common Lisp
community and the Perl community: Give people a shitty language and they
expect nothing, so create what they need, but give people a great
language and they expect everything, so only pine for what they miss.
Internationalization and _real_ localization is very hard work. It is
not something you tack on as an afterthought, any more than security and
qualit is. If some standard function named yes-or-no-p does not satisfy
a Russian user, the only surprise should be that someone could even come
up with the idea that it should have.
If you have a problem with missing functionality in a programming
environment, there is actually a name for the solution to your problem:
It is called _programming_.
///
--
From: Erik Naggum
Subject: Re: Beginner question: performance problems with a simple program
Date:
Message-ID: <3218911701617481@naggum.net>
* Aleksandr Skobelev <·········@mail.ru>
| "Most of the work is done" might be more correctly to speak. IMHO ANSI
| CL standard is lacking in support for locales/charsets.
ANSI CL is also lacking in support for printing the new Euro notes on
ordinary office laser printers, another would-be useful thing that is
outside the scope of the standard.
If you have actually tried using locales to achieve localizability and
still think they serve a useful purpose beyond marketing rhetoric, I
would like to see your code.
| So any non-Latin-1 user [...]
ANSI Common Lisp is not even defined for ISO Latin 1, but for a character
set that closely matches ASCII or ISO 646 IRV. However, that is only a
minimum requirement -- the implementation is obliged to document what it
actually supports. Several Common Lisp implementations support a 16-bit
Unicode. Note that there is no standard way to add case information to
the supported character set, so if you want to depend on the language
support for case conversion, you are SOOL if what you want it is not
supported, especially if the char-up/downcase functions are inlined as
tests for a-z so you cannot even redefine them. (E.g., this is still a
problem in Allegro CL's 8-bit-character version despite excellent support
for character sets in the 16-bit-character version.)
| And when I think about some funny features in the language like
| YES-OR-NO-P or ~R in FORMAT, I understand that they were designed with
| English taken in consideration only.
This is a good thing. If it were designed by the usual "international"
tactics, it would lack a lot of useful features because some rinkydink
language with a few hundred speakers could not support it, like plurals.
The fact that you react to these things with some hosility is a good sign
that Common Lisp would have suffered had it been intended to placate all
the sourpusses in the world who envy the United States is position and
who loathe the role that English has acquired -- instead of French or
German, both or either which "deserve" it much more than English does, if
you poll several large segments of the European population.
Fortunately, I can say all these things because I am _not_ American, but
happen to come from and live in a rinkydink country with three official
languages for less than 5 million people, one of which is a pathetic
rural rebellion against national standards set by the cities and which
today differ much less than British and American English. Just how hard
do you have to lose to think such a stunt is a good idea for the _same_
people? Right! So pardon me while I think "locales" and supporting
loser dialects is a Bad Idea.
///
--
Erik Naggum <····@naggum.net> writes:
> * Aleksandr Skobelev <·········@mail.ru>
> | "Most of the work is done" might be more correctly to speak. IMHO ANSI
> | And when I think about some funny features in the language like
> | YES-OR-NO-P or ~R in FORMAT, I understand that they were designed with
> | English taken in consideration only.
>
> This is a good thing. If it were designed by the usual "international"
> tactics, it would lack a lot of useful features because some rinkydink
> language with a few hundred speakers could not support it, like plurals.
Hmm, I'd hardly call Japanese a rinkydink language.
> The fact that you react to these things with some hosility is a good sign
> that Common Lisp would have suffered had it been intended to placate all
> the sourpusses in the world who envy the United States is position and
> who loathe the role that English has acquired -- instead of French or
> German, both or either which "deserve" it much more than English does, if
> you poll several large segments of the European population.
>
> Fortunately, I can say all these things because I am _not_ American, but
> happen to come from and live in a rinkydink country with three official
> languages for less than 5 million people, one of which is a pathetic
> rural rebellion against national standards set by the cities and which
> today differ much less than British and American English. Just how hard
> do you have to lose to think such a stunt is a good idea for the _same_
> people? Right! So pardon me while I think "locales" and supporting
> loser dialects is a Bad Idea.
Certainly the idea of locales can be (and is) taken to a silly
extreme. However, there are a few languages that are really
important, and being able to deliver applications in them is
important. English, Spanish, maybe French, Arabic, Chinese, and
Japanese, should all be usable. We should be able to assume that all
programmers have at least basic English skills, but the same is not
true of users.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: Erik Naggum
Subject: Re: Beginner question: performance problems with a simple program
Date:
Message-ID: <3218921950422847@naggum.net>
* Thomas F. Burdick
| Certainly the idea of locales can be (and is) taken to a silly extreme.
| However, there are a few languages that are really important, and being
| able to deliver applications in them is important. English, Spanish,
| maybe French, Arabic, Chinese, and Japanese, should all be usable. We
| should be able to assume that all programmers have at least basic English
| skills, but the same is not true of users.
Well, you cannot write a program that works in English, Spanish, French,
Arabic, Chinese and Japanese unless you know _all_ these languages and
_prepare_ for the translation.
The only way to make a program work in more than one language is to make
it work in _none_: formalize a protocol and write user-interface front-
ends to it. Let those who understand the application _and_ the target
language write that user-interface front-end.
English happens to be the _common_ language of the field of computer
science. It no longer has the role of a natural language in computer
science. That this leaves a large number of people "handicapped" by
being misled to believe that _their_ language is the common language, is
nothing but unfortunate.
Forget the whole locale business and write software that speaks about
objects and units and internal stuff, and let several user-interface guys
handle the user-interface portion that talks to people in various
cultures. This is not hard at all, once you get past the misguided
notion that all computer programs should talk directly to users.
///
--
Erik Naggum wrote:
> The fact that you react to these things with some hosility is a good
> sign that Common Lisp would have suffered had it been intended to
> placate all the sourpusses in the world who envy the United States is
> position and who loathe the role that English has acquired -- instead of
> French or German, both or either which "deserve" it much more than
> English does, if you poll several large segments of the European
> population.
>
> Fortunately, I can say all these things because I am _not_ American, but
> happen to come from and live in a rinkydink country with three official
> languages for less than 5 million people, one of which is a pathetic
> rural rebellion against national standards set by the cities and which
> today differ much less than British and American English. Just how hard
> do you have to lose to think such a stunt is a good idea for the _same_
> people? Right! So pardon me while I think "locales" and supporting
> loser dialects is a Bad Idea.
My English is far from being good, but I finally came to the opinion that I
don't see German the language as very important. I read all CS literature in
English even if German translations are available because if I want to
discuss this topics I will have to do it in English and will have to know
the English terms and not the German translations. I even tend to read
romans in English because I think it will help me to improve my language
skills and because I really like the language. More and more often I catch
me that I at least partially think in English or that I only know a term in
English but do not have a direct German translation at hand.
Compared to German, English seems to be a very "fuzzy" language with many
ambiguities that get resolved through context. Some English authors make
use of this fact to express multiple things in the same part of sentence
depending on how you look at it. German makes those things much more
explicit which makes it a rather boring language.
So I think _I_ could certainly live with computer programs that only
support English as language...
ciao,
Jochen
--
http://www.dataheaven.de
From: Jean-Fran=?ISO-8859-1?B?5w==?=ois Brouillet
Subject: Re: Beginner question: performance problems with a simple program
Date:
Message-ID: <B857F838.3485%verec@mac.com>
Erik Naggum
# So pardon me while I think "locales" and supporting loser dialects
# is a Bad Idea.
Only an arrogant moron, living in a loser country could utter such loser
sentences. If that half brain that this lower life has rented were still
half working [we're talking 25% of full regime here, if you can't do the
math yourself] we would be spared such loser posts which don't bring any
value _at all_ to that thread.
Jochen Schmidt
# My English is far from being good, but I finally came to the opinion
# that I don't see German the language as very important.
I would agree too...if my native language were German that is ;-)
It turns out that my English is far better, and that my French is near
perfection. If I had more time, I would certainly learn more winner
languages (Russian and Arabic spring to mind).
# More and more often I catch me that I at least partially think
# in English
No you don't. Only mono-linguists can argue they do, until proven wrong.
When you utter some sentence (in any language) you know, ahead of the
words coming out of your mouth, what the sentence is going to affirm.
(that is, unless you are a politician of course ;-). Yet those words
that will appear in the near future, are not _verbalized_ yet, and are
only _translated_ to your utterance language as your tongue makes some
progress.
While, according to Bergson, the language is the support of the thought,
it is _not_ the thought itself, even though a given language _shapes_ the
way you think.
Multiplying the languages you know can only give you more perspectives,
and ways of thinking. Reducing their number can only lead you to an
impoverished mental landscape, where entire areas of human thought will
simply never flourish.
Finally, this idea that a given language has "won" is utter non-sense.
French had "won" two centuries ago. Where is it today? Give me a break
and go by some more brain cells. At any point in time, there is a dominant
language. Latin two thousand years ago, Chinese in the next decade. And
so what?
So what?
The issue is that way too often, this kind of decision (whether and how
to support non dominant languages) is left to computer specialists, the
vast majority of whom are _anything else_ illiterate. This includes art,
poetry, literature, and most forms of human expressions that do not appeal
to those "computer morons".
If a shoe helps you walk, a computer is meant to help you think. No matter
what uneducated, university degrees loaded psychopaths would love you to
believe.
"Ouf! Depuis le temps que j'attendais �a, je me suis pay� le Naggum!"
--
Jean Fran�ois Brouillet
^
+--- this letter is called "Fuck You! Loser"
Jean-Fran�ois Brouillet <·····@mac.com> writes:
> "Ouf! Depuis le temps que j'attendais �a, je me suis pay� le Naggum!"
Yow, until I got here, I was quite confused by the inexplicably
violent response in this article. Well, good explanation or not, it's
no longer inexplicable. Ouf, indeed.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: Erik Naggum
Subject: Re: Beginner question: performance problems with a simple program
Date:
Message-ID: <3218955132298566@naggum.net>
* Jean-Fran�ois Brouillet <·····@mac.com>
| Only an arrogant moron, living in a loser country could utter such loser
| sentences. If that half brain that this lower life has rented were still
| half working [we're talking 25% of full regime here, if you can't do the
| math yourself] we would be spared such loser posts which don't bring any
| value _at all_ to that thread.
:
| --
| Jean Fran�ois Brouillet
| ^
| +--- this letter is called "Fuck You! Loser"
What an _interesting_ display of personality problems. Get help, OK?
///
--
On 2/1/02 10:12, in article ················@naggum.net, "Erik Naggum"
<····@naggum.net> wrote:
> * Jean-Fran�ois Brouillet <·····@mac.com>
> | Only an arrogant moron, living in a loser country could utter such loser
> | sentences. If that half brain that this lower life has rented were still
> | half working [we're talking 25% of full regime here, if you can't do the
> | math yourself] we would be spared such loser posts which don't bring any
> | value _at all_ to that thread.
> :
> | --
> | Jean Fran�ois Brouillet
> | ^
> | +--- this letter is called "Fuck You! Loser"
>
> What an _interesting_ display of personality problems. Get help, OK?
Why Naggum thinks that my renaming of the "c" with "cedilla" letter
as an attack against Naggum himself is any _interesting_ at all is pure
mystery to me.
Why would attacking Naggum be _interesting_ ? To whom ?
If attacking Naggum only came from the "bile-overflow" department, then
people may sympathise, but then simply move on. Is Naggum such an important
<plug-some-emphatic-title> that the whole 21st century has to be grateful
forever for having been blessed by the smallest Naggum thought?
| Naggun standard canned reply to this is going to be along the
| lines that _I_ need medical treatment because _I_'m exposing
| personality disorders. And saying <whatever, your-call> about
| him is simply a sign of me being <brain-under-powered> or whatever
| he fancies those days.
|
| Isn't this entire Naggum-thing pathetic?
Naggum, of all your posts, about 10% have real value. And I mean _real_.
Unfortunatenly, the other 90% is utter non-sense, bullshitting arrogance
of the clever among the cleverest who deigns blessing the poor crowd
with his infinite wisdom.
Naggum, enough is too much. There are real contributors to c.l.l, and
your signal/noise ratio is way too low. Nobody _cares_ about how you
feel, and whether such sub-population deserves to live/die/flourish/perish
according to St Naggum.
Make us a favor: give us a break: stop posting 10 times a day to c.l.l
(as if you had no other useful work to do). By restraining yourself to
core issues, and avoiding raw, unwarranted, blunt, uncalled-for opinions
you will contribute to making c.l.l a better place.
I, for one, would have happily carried on lurking c.l.l for quite a while
if it werent' for this and the previous message.
> Get help, OK?
How much do I owe you, Doctor, for such an amazing diagnostic?
Do you accept Euros ?
> ///
--
Jean-Fran�ois Brouillet
On Thu, 03 Jan 2002 01:11:36 +0000, Jean-François Brouillet
<·····@mac.com> wrote:
>Naggum, enough is too much. There are real contributors to c.l.l, and
>your signal/noise ratio is way too low. Nobody _cares_ about how you
>feel, and whether such sub-population deserves to live/die/flourish/perish
>according to St Naggum.
There are two effective ways to deal with St Naggum
1. Ignore all his messages or kill file him
2. Annoy him enough that he kill files you.
I have chosen the latter option since some of St Naggum's posts are
deliciously funny.
For example, the post in which he accused you of belligerence ( and
misspelled the word to boot ! ) was wonderful. That is like the blast
furnace calling the cigar smoky !
* irt <········@antispamoptushome.com.au>
| For example, the post in which he accused you of belligerence [...]
Oh, so Jean-Fran�ois Brouillet and "MJ Ray" are the same person. That
explains a lot. Thank you for this information -- I did not know.
///
--
"Erik Naggum" <····@naggum.net> wrote:
> * irt <········@antispamoptushome.com.au>
> | For example, the post in which he accused you of belligerence [...]
>
> Oh, so Jean-Fran�ois Brouillet and "MJ Ray" are the same person. That
> explains a lot. Thank you for this information -- I did not know.
Oh! You're so disappointing, my clear-sighting Naggum!
Truth be told, I don't know who "MJ Ray" is, and I'm not even sure
I remember any of his posts. But yours...
In fact, I don't even need to remember anything, Naggum, you're
so predictable. Where's the fun with you? You're a way too easy target...
BUT A DEAD BORING ONE
Naggum: open your eyes, and close your mouth. That's the best advice
you'll have for free in years. Leave c.l.l. in peace, and I promise to
step down from my soapbox.
> ///
--
Jean-Fran�ois Brouillet
* irt <········@antispamoptushome.com.au>
| For example, the post in which he accused you of belligerence [...]
* Erik Naggum
> Oh, so Jean-Fran�ois Brouillet and "MJ Ray" are the same person. That
> explains a lot. Thank you for this information -- I did not know.
* Jean-Fran�ois Brouillet <·····@mac.com>
| Oh! You're so disappointing, my clear-sighting Naggum!
I was sarcastically pointing out that Israel Ray Thomas is unable to keep
track of anything, not even what he enjoys, which is a very useful thing
to know about him. I also enjoy seeing that you are unable to detect
sarcasm, as that is very consistent with your character. And the reason
you think I am so predictable is that you see only what you want to see
and you cannot even _imagine_ anything but one-dimensional personalities,
another very consistent trait for your particular kind. If you believe
that _you_ bring anything new to this forum, try again. Hateful scum
like you have been coming and going for years, having exposed yourself in
ways that will embarrass yourself and your family for years to come, in
full public view. Some of you recover, but you will not get that chance.
| Leave c.l.l. in peace, and I promise to step down from my soapbox.
Within the next 48 hours, you will die in a car accident, so there is no
need for you to make these sorts of silly threats. I shall remember you
as you chose to present yourself to me. Good riddance to you.
///
--
Naggum: I have only one answer: YOU'RE A DEAD FUCKING POLITICIAN
You spend your time answering to problems that you invent, and
not addressing the crux of the matter. That's a very skilled side-tracking
technique which I recognize even from a distance.
In case I'm still alive in 48 hours, I will endeavour to do the
following:
Each further day that God still allows me to live ;-), and assuming
Cretin-Naggum didn't grow any further brain cell atom on that day, and
tried by one post or another to either inhibit or ridicule some poster
idea, I will post an empty message to c.l.l reading:
AND YET ANOTHER DAY HAS PASSED AND NAGGUM STILL ANNOYS AN ENTIRE COMMUNITY
(or some variation thereof)
And I thought I knew what "diehard" meant ;-(
You're pass� Naggum. There's no hope for you. Do yourself a favour:
shut up. Is it because I'm younger than you and can see things that
your senility prevents you from understanding? Is it because I'm
older than you and your youth hasn't taught you any of the core values
in life?
But even cockroaches seems to be much more decent creatures.
You're an intellectual parasite, Naggum, a Trojan horse using c.l.l
to spread doom and gloom. No one _needs_ you.
Since I'm very prompt to sympathise, I find it very sad to understand
what kind of loneliness you find yourself with, but I'm really sorry for
you, Naggum, there's no cure for that one. Too bad that your genes have
built you in such a way that you'll never understand, but please, for
them, don't raise children, they might otherwise inherit that terrible
disease.
--
Jean-Fran�ois Brouillet
On 3/1/02 22:42, in article ················@naggum.net, "Erik Naggum"
<····@naggum.net> wrote:
> * irt <········@antispamoptushome.com.au>
> | For example, the post in which he accused you of belligerence [...]
>
> * Erik Naggum
>> Oh, so Jean-Fran�ois Brouillet and "MJ Ray" are the same person. That
>> explains a lot. Thank you for this information -- I did not know.
>
> * Jean-Fran�ois Brouillet <·····@mac.com>
> | Oh! You're so disappointing, my clear-sighting Naggum!
>
> I was sarcastically pointing out that Israel Ray Thomas is unable to keep
> track of anything, not even what he enjoys, which is a very useful thing
> to know about him. I also enjoy seeing that you are unable to detect
> sarcasm, as that is very consistent with your character. And the reason
> you think I am so predictable is that you see only what you want to see
> and you cannot even _imagine_ anything but one-dimensional personalities,
> another very consistent trait for your particular kind. If you believe
> that _you_ bring anything new to this forum, try again. Hateful scum
> like you have been coming and going for years, having exposed yourself in
> ways that will embarrass yourself and your family for years to come, in
> full public view. Some of you recover, but you will not get that chance.
>
> | Leave c.l.l. in peace, and I promise to step down from my soapbox.
>
> Within the next 48 hours, you will die in a car accident, so there is no
> need for you to make these sorts of silly threats. I shall remember you
> as you chose to present yourself to me. Good riddance to you.
>
> ///
On Thu, 03 Jan 2002 23:13:22 +0000, Jean-François Brouillet
<·····@mac.com> wrote:
>In case I'm still alive in 48 hours, I will endeavour to do the
>following:
Erik has probably sent out the ninja teams already...
You will recognise them.
They are the ones with the body odour and who keep saying "setf",
"cons" .
Just a last one, to prove how Naggum is completely confused
in his head and can't tell a consequent from a cause.
I wrote (to Naggum):
> Leave c.l.l. in peace, and I promise to step down from my soapbox.
He then replied:
> [...] so there is no
> need for you to make these sorts of silly threats.
What threat? Does Naggum feel threatened that I step down from my soapbox?
Is it a threat to him that I stop embarrassing him in public?
Or is he referring to the fact that I'm hinting at continuing-nagging
him-if-he-weren't-to-stop-annoying-everybody as a threat?
In the latter case he got his rhetoric classes (if he had any)
all mixed up. Since I've already starting nagging him, there's no
actual _threat_ but there is an ongoing _attack_. Can't he tell one
from the other? Since I'm suggesting that, under certain conditions
I might stop the attack, I'm not making any _threat_ (either new or
old) but a _promise_. Can't Naggum tell a _threat_ from a _promise_
either?
In the former case, this would be a public admission that Naggum
is a masochist and enjoys being bitten in a public place.
In none of those cases do we get a very sane picture of the Naggum.
And then what about this:
> Within the next 48 hours, you will die in a car accident
Isn't this a real threat? Or even worse, a dark prophecy?
Remind me, just in case I was about to forget, who needs medical
treatment ?
Naggum: how many times do I need to tell you to shut up?
Naggum: how many people do you need to ask you to shut up to
actually shut up?
Whether we are the morons and you are the only genius is irrelevant:
_we_ are the community. _you_ alone are against us.
Is this so hard to understand?
--
Jean-Fran�ois Brouillet
On Fri, 04 Jan 2002 01:04:10 +0000, Jean-François Brouillet
<·····@mac.com> wrote:
>In none of those cases do we get a very sane picture of the Naggum.
>And then what about this:
>> Within the next 48 hours, you will die in a car accident
Look just don't waste any mental energy on Naggum.
Over the years I have seen him ( among other things )
1. Ask someone to commit suicide
2. Wish that someone living close to X would kill X.
Erik doesn't mean these things ( I hope :-) ).
He is probably just very impulsive and emotionally immature.
Don't worry, just learn Lisp.
There are plenty of others ( Ken Pitman comes to mind ) who can help
with any queries you have.
"Jean-Fran�ois Brouillet" <·····@mac.com> wrote in message
························@mac.com...
>
> * Erik Naggum
> > Within the next 48 hours, you will die in a car accident
>
> Isn't this a real threat? Or even worse, a dark prophecy?
>
CL-USER 14 > (defun |Jean-Fran�ois Brouillet|()
(car "accident"))
|Jean-Fran�ois Brouillet|
CL-USER 15 > (|Jean-Fran�ois Brouillet|)
Error: "accident" is not of type CONS.
1 (abort) Return to level 0.
2 Return to top loop level 0.
Type :b for backtrace, :c <option number> to proceed, or :? for other options
Oops! |Jean-Fran�ois Brouillet| seems to have died in the car, can we drop
this thread now?
I make a passing reference to Hitler. :-)
--
Geoff
On Fri, 04 Jan 2002 14:55:55 GMT, "Geoff Summerhayes"
<·············@hNoOtSmPaAiMl.com> wrote:
>Oops! |Jean-Fran�ois Brouillet| seems to have died in the car, can we drop
>this thread now?
>
>I make a passing reference to Hitler. :-)
Naggum's Law /prov./ [Usenet] "As a discussion in c.l.l grows longer, the
probability of a Erik asking his opponent to kill himself or threatening to
murder him approaches one."
Once this occurs, that thread is over, and Erik automatically loses whatever
argument was in progress. Naggum's Law thus practically guarantees the
existence of an upper bound on thread length in this group.
Considering Naggum's Law, this thread is already over, so let's please move
on.
--
Fernando Rodr�guez
frr at wanadoo dot es
--
(Bon, je fais un paquet cadeau, tir group�, et je me casse!)
To all those of you who have shown more irritability than
understanding, I'm going to define a few words for your perusal,
so that maybe you'll reach enlightenment ;-)
- We. Means "I" + some others that are not defined. Obviously,
the set of people belonging to the group "we" refers to,
varies with the individual making use of the pronoun.
In the context I used it, I can name more than one individual
who has posted here, recently or not, and who shares at least
partially my indignation with some of the writings of Naggum.
Do you still need more trivia ?
- lurker One of the `silent majority' in an electronic forum;
one who posts occasionally or not at all but is known
to read the group's postings regularly.
(The Jargon File)
So yes, I've just been "delurking".
- Naggum a brilliant mind...with a pathological ethos.
Too bad he can't control himself. Some refer to him as bug
or a feature, he's more of a waste of potential. That's very
sad, for him in the first place, and for the lurkers like me
who are tired of the constant flaming he ignites.
Now for the most common themes:
- Lurker Thou Are, Lurker Thou Shall Stay.
Nope. Stop polluting my daily reads, and I'll stop complaining.
That simple.
- Hey! Brouillet, you didn't write anything of value, your
posts are content free.
Well spotted! Next?
- (decf we)
See above, and: (incf *maggum-wannabe*) !
To all the lurkers that are more annoyed by this state of affairs,
please write me, and I'll collect your names. If the number warrants
it, I may even post the list here, as Naggum ejects more and more
people from c.l.l.
To all the other mere coders, have a nice week-end and see you (not)
on Monday.
--
Jean-Fran�ois Brouillet
On 4/1/02 14:55, in article ···················@news3.calgary.shaw.ca,
"Geoff Summerhayes" <·············@hNoOtSmPaAiMl.com> wrote:
>
> "Jean-Fran�ois Brouillet" <·····@mac.com> wrote in message
> ························@mac.com...
>>
>> * Erik Naggum
>>> Within the next 48 hours, you will die in a car accident
>>
>> Isn't this a real threat? Or even worse, a dark prophecy?
>>
>
> CL-USER 14 > (defun |Jean-Fran�ois Brouillet|()
> (car "accident"))
> |Jean-Fran�ois Brouillet|
>
> CL-USER 15 > (|Jean-Fran�ois Brouillet|)
>
> Error: "accident" is not of type CONS.
> 1 (abort) Return to level 0.
> 2 Return to top loop level 0.
>
> Type :b for backtrace, :c <option number> to proceed, or :? for other options
>
> Oops! |Jean-Fran�ois Brouillet| seems to have died in the car, can we drop
> this thread now?
>
> I make a passing reference to Hitler. :-)
>
> --
> Geoff
>
>
>
>
>
Rajappa Iyer wrote:
>
> Jean-Fran�ois Brouillet <·····@mac.com> writes:
>
> > - (decf we)
> >
> > See above, and: (incf *maggum-wannabe*) !
>
> Actually, I'm perennially amazed at the blind eyes and deaf ears that
> many c.l.l. regulars display when it comes to Erik's rants. While it
> is their privilege to ignore the unsavory portion of Erik's
> net.persona, I wonder why a similar indifference is not extended to
> people complaining about the same. After all, if Erik's rants don't
> bother you or do not warrant a response, neither do the complaints
> about the same. What's sauce for the goose...
It's a little tricky, but here goes. A c.l.l. regular is:
(1) necessarily a Usenet regular, so flamewars do not get much
attention; and
(2) probably a Lisper and thus highly logical, so the inconsistency of
threatening someone with daily harrassment as a way of improving the
tone of an n.g. has naturally drawn some comment.
Reacting to such comment with allegations of conspiracy only enhances
our fascination with the messenger, who needs to heed their own message:
talk about Lisp, not personalities.
kenny
clinisys
* Rajappa Iyer <···@panix.com>
| Well, one could reasonably argue that Erik's rants are harassment too and
| he has stated that his diatribes are aimed at improving the quality of
| exchange in the group. Logically, there is little if any difference
| between the two approaches.
Not to you, but you are part of the problem, not the solution, by your
own admission. Why does it surprise you that you do not get the point?
About 1 in 20 people go _mental_ when criticized in an unexpected way.
(I have the empirical data to support this number. Trust me.) They are
probably psychologically _unable_ to deal with unexpected disagreement,
since they usually come up with "you attack everyone you disagree with"
(which is what they do, and nobody else). Some people react hysterically
to any experience of cognitive dissonance, and would rather die than have
to change their mind on something they are not specifically prepared to.
This is _very_ easy to detect when you know what to look for and it tells
me that most of what else they believe is utter hogwash, as they have a
real _effort_ to reject everything that could contradict their beliefs.
That impression has to date _not_ been refuted by a single specimen of
the non-thinking subhumans. To think (specifically, to concentrate) or
not is perhaps the only choice about which we have free will, but some
people never actually make that choice -- they somehow manage not to die
at a young age even while being wastes of space, parasites on society
like a non-hunting member of predator flock. The basic thinking skill
that involves the ability to recognize _intellectually_ that some of
one's tacit assumptions has been challenged, instead of reacting with the
primitive emotion of fear, uncertainty, and doubt, is a _requirement_ for
public discourse. If you feel under attack because something you hold to
be true is challenged or even potentially challenged, you should go hide
in some dark basement and certainly not be out in public, where, unless
you surround yourself with nincompoops who all agree with you and exhibit
no shred of a new idea or a controversial opinion, you _will_ experience
such challenges. USENET in particular is a place where every single
assumption you hold _will_ become challenged at one time or another.
The other 19 will at the very least not react irrationally hostile to a
challenge. Admittedly, only 1 out of 4 react intellectually and will
always be curious at first, while at least half the normal population
will _disregard_ any contradictory information to their existing beliefs
until they have heard it often enough, at which point they unthinkingly
just adopt it as the new thing they do not recognize is being challenged.
The remaining 1 out of 5 become _irritated_ by what they think is false
information but only occasionally act on it. The consequence of this is
that a large number of people are only comfortable when people around
them keep echoing what they all already believe, usually at several
levels. This is a waste of bandwidth on the Net (the stupid "me too"
response is thankfully mostly gone, but it was so common from AOL users a
few years ago that many people still write "AOL" when they mean "me too"
in an electronic forum), but several people still hang around on the Net
mostly to have their assumptions unchallenged because their idea of
stability and safety and even _identity_ is that things do not change.
These are polite, friendly people who communicate _nothing_: no new
ideas, so no wrong ideas, no controversial opinions, so no mistakes,
nothing worth saying, so nothing worth disagreeing with, either. These
are the small-town people who cannot handle the big city where people
bump into eachother with controversial opinions and attitudes all the
time. If they have to have people around them agree with them, stay the
hell off the Net -- they will get seriously bruised, not by other people,
but by their own lack of ability to cope with unexpected disagreements
with what they think is the only right answer. Pathologically provincial
people who are unable to come to terms with other people's opinions, but
think they must enforce a single, right answer for everyone, do _not_
belong in public fora. When that "single, right answer" is either simply
wrong or at least not the _only_ right answer, other people need to be
able to know this. This is when the nutballs crack open and all hell
breaks loose. You should be able to figure out how it happens and then
to see if it actually does happen that way, now.
If you take the time to be fair, and I suspect that you will never learn
what this even _means_, you will see that the party that _first_ goes
personal is _not_ me. But because of shit-for-brains like yourself and
that French parasite you have taken sides with, it is somehow OK to
attack me. I do not appreciate that. This also happens because these 1
in 20 are so _bad_ persons that they are so afraid of any criticism of
their person that they immediately defend themselves when their _actions_
or opinions are criticized -- since bad people recognize a threat, they
think that everything I do is threaten bad people. I do not, bad people
find their way to attack me _all_ on their own. These bad people do not
even _understand_ that only their actions and opinions can be criticized
-- and indeed they never make the discintion in what they criticize -- so
they believe that just because they feel hurt, it must have been personal
and since they are being criticized for not exercising their thinking
skills, they react all emotionally, like those people who have so little
blood supply to their brain they cannot think and feel at the same time.
That pile of French dung, as well as several before him, accuse me of
being so "predictable", but I think I create cognitive dissonance in
pathologically provincial, utterly simple people -- people whose lives
depend on a bunch of misguided assumptions _will_ defend themselves when
they are faced with someone who considers no assumption worth protecting.
Now, I do not speak unless I have something I think is worth saying,
which _excludes_ platitudes and whatever people agree on. If people
already agree, there is absolutely no need to keep repeating it. And in
all likelihood, it is _false_ if everybody keep saying it, so as to
convince themselves. Therefore, what I say is usually controversial. To
some people, that makes me interesting. To other people, a lethal threat
to their personal identities. But neither of these opinions are anybody
else's business. You choose to read what you choose to read. Why so
many of you fucking losers have to read what I post and work yourself up
like cats in heat, and then ask _me_ not to post as opposed to they not
reading what they do not like, I have not figured out. I think it is
because their sense of ethics is always concerned with what _other_
people should do. You know the kind -- so hypocritical two of them would
give off enough hot air to balloon around the globe.
I repeat, for the benefit your limited mental capacity: This is not a
forum for venting your personal feelings about anyone. Grow a clue, now,
and _mature_. If you have to see me as a symbol of cognitive dissonance,
your learning to deal with me is what will make you a man, little runt.
Now, if you keep being a stupid little turd with aspirations of becoming
as big and stinky as that French sewer you admire so much, keep it to
yourself. Stink up your own place, do _not_ shit any more in public.
That French septic tank is beyond hope and he will not recover, but you
appear to have some remnants of a brain that could be recovered if you do
not let yourself sink to his level.
///
--
Erik Naggum <····@naggum.net> writes:
> About 1 in 20 people go _mental_ when criticized in an unexpected way.
> (I have the empirical data to support this number. Trust
> They are probably psychologically _unable_ to deal with unexpected
> disagreement,since they usually come up with "you attack everyone you
> disagree with" (which is what they do, and nobody else).
Trying to be delicate, I'd suggest the 1 in 20 number drops a bit if the
error of their ways is pointed out diplomatically. If I were lost in the
Swiss Alps and wishing for a cask of brandy, I'll grab it more eagerly from
a smiling St. Bernard than I will a growling Rottweiler.
Those who'd rather have wine instead of brandy. . .well, the St. Bernard
has other hikers to find and the winers will either acquire a taste for
brandy or starve. Hell, presented correctly, a cheerful St. Bernard might
even convince a winer to grudgingly taste (just this once; wink, wink,
nudge,nudge) the brandy.
> to any experience of cognitive dissonance, and would rather die than have
> to change their mind on something they are not specifically prepared to.
I'm probably not invested enough, but I don't get why things often get
so exercised on c.l.l. To use a recent example, there was a long argument
about how a non-standard macro made a company appear like it was trying to
"destroy the standard." Maybe I over-estimate the viability of the
Common Lisp community or the specification, but I don't see how public
fighting (and a fine scrap it was, eh, Seamus) over something like protects
the Common Lisp community or the standard.
Or, more succinctly, if you're fightin' about something so trivial, you're
either already dead or your vigorously, wonderously alive. Or, you've
perhaps discussing academic politics.
As I wrote this, I was reminded of the letter Lincoln wrote General Meade
after he squandered an opportunity to attack a General Lee trapped on a
swollen Potomac.
My dear General,
I do not believe you appreciate the magnitude of the misfortune
involved in Lee's escape. He was within our easy grasp, and to
have closed upon him would, in conneciton with our other successes,
have ended the war. As it is, the ware will be prolonged
indefinitely. If you could not safely attack Lee last Monday, how
can you possibly do so south of the riverm, when you can take with
you very few--no more than two-thirds of the force you then had in
hand? It would be unreasonable to expect and I do not expect that
you can now effect much. Your golden opportunity is gone, and I
am distressed immeasurably because of it.
Meade had nothing to say about the letter. . .'cause Lincoln never
mailed it.
--Brad
>>>>> "BK" == Brad Knotwell <········@ix.netcom.com> writes:
[... apt posting deleted ...]
BK> Meade had nothing to say about the letter. . .'cause Lincoln
BK> never mailed it.
Bet you _writing_ it helped him some though.
cheers,
BM
* Brad Knotwell <········@ix.netcom.com>
| Trying to be delicate, I'd suggest the 1 in 20 number drops a bit if the
| error of their ways is pointed out diplomatically. If I were lost in the
| Swiss Alps and wishing for a cask of brandy, I'll grab it more eagerly
| from a smiling St. Bernard than I will a growling Rottweiler.
You, too, seem to make the mistake of believing that I start these
fights. I do not. If you take the time to be fair in your judgment,
which you have not up to now, you will discover that I _am_ polite to
people when pointing out factual errors, etc. _This_ is what blows some
people's mind if they were not specifically prepared to be wrong on that
particular point.
Do you consider the fact that you exhibit a severe case of prejudice as a
problem? If not, could you explain how you think to me and tell me how
your response is possible unless you actually believe that I attack
people out of the blue? If you do believe that, what _facts_ could alter
your "impression" when _fact_ did not enter into it to to begin with?
| I'm probably not invested enough, but I don't get why things often get
| so exercised on c.l.l.
Precisely.
| Maybe I over-estimate the viability of the Common Lisp community or the
| specification, but I don't see how public fighting (and a fine scrap it
| was, eh, Seamus) over something like protects the Common Lisp community
| or the standard.
Do you think fights in Congress, in the media, etc, over the wide-ranging
anti-terrorist bills protects the freedom of Americans? Have you seen
how nasty those fights got? I am a nice little puppy compared to those
who have (in my view, rightfully) compared some of the measures to a
giant step towards a police state, with "the only way to protect our
freedom is to destroy it" as a line invoked several times. These are not
simple little things like programming languages, but policies that affect
billions of people, ultimately, trillions of tax dollars, etc.
Have you learned that an important war was fought in North America over
the freedom of certain people? Do you think they would have been better
off if that war had not been fought? Etc.
We have a company among us who exhibits an extremely ambivalent attitude
towards the standard, with at least one very vocal employee who spends
his time writing code in a style that predates Common Lisp the Language
from 1984, possibly even the start of that standardization effort,
because he wrote a Lisp system even longer ago. He argues that people
should not use some parts of the standard and rejects code offered to him
that does, because he has invented something else that he did not even
publish either specification or source code to for _months_, even while
publishing code using it. Precisely what you allude to in your "why
can't we all get along"-style first paragraph, _his_ attack on the users
and creators of the standard alike in an obscure little piece grandiously
entitled "Lisp Coding Standard" was simply _vicious_ and so hostile to
those it was aimed at that they stopped working with him long before _he_
erupted here on USENET accusing those who wanted the standard behavior to
be "religious" and lots of worse things. Calling people who made a
standard on which his company bases its promise to deliver products to
its customers _braindamaged_ tends to annoy people who more than anything
want to feel good about giving them their their money and basing their
own livelihood on that choices. If you call a party you do not think
exhibits any thnking ability "braindamaged" in a debate here, that is one
thing, but doing so on a company-sponsored web page entitled "Lisp Coding
Standard" and leaving no room for argument means that the company has
sanctioned his attitude towards those customers who want standard
behavior. This is not only an insult to very smart people around the
world, it is suicidal by a company that has up to now been profitable
because of its high quality product and excellent customer support. Add
to the "braindamage" and "religion" that I expected much more and that my
_disappointment_ with both company and person became very pronounced
after this. As opposed to previously betting several hundred thousand
dollars of my own income and several million dollars of revenue at the
company I worked for on their product, I find myself in doubt that
recommending their product to others or entering new projects with them
will be good for _me_. How hard am I willing to fight for a company that
has a senior scientist who has called me braindamaged and religious
because I want that company to adhere to the specification that I went to
them to purchase a product that conformed to? Tell me, if you hired an
architect to draw your dream house, and loved the result, and you went to
a contracter who said he would build it, but when delivered, it was
different in many important ways and the contractor's chief engineer
called the design you loved and the contractor had agreed to build
"braindamaged" and muttered "religious" when you protest that you had
actually entered a working relationship based on the drawings, no matter
what anyone's _personal_ feelings about the result would be, I am hard
pressed to see any other result than a lawsuit that the contractor would
lose because the contractor refused to back down. The last part is
probably more important than anything else. What this exercise showed,
was that the person _and_ the company in question is not trustworthy,
that at any time in the future, one might find that "disagreement" over
the specification will result in a similar failure to obtain a sensible
result. There is already so much legal work to get into licensing with
them that it scares people off, but when you cannot even get binding
agreement on the specification they are supposed to implement for you,
the amount of legal involvement to use their product _skyrockets_. Some
people are so inexperienced with legal matters that they do not even
understand that a standard is a legal document. Serious disrespect for
vital components of the legal instruments that control the interaction
between companies is _really_ moronic, and the inability to _understand_
that somebody is arguing about the legal framework of contracts one might
enter with their company, even to the point where nobody in that company
could find it worth their time to teach him, signals a fundamental
disregard for the common legal structure of business transactions. In
other words, those who _want_ legal frameworks to function properly will
not want to deal with this company. Who is to tell which parts of an
entered contract they will not secretely consider "braindamaged" and you
"religious" for wanting to adhere to and when you push it, they will not
back down from so you have to go to court after having paid them a god-
awful lot of money and taking a huge and costly risk of failure. But is
this because they had a rogue programmer who had invented his own macro?
No. It is because he chose to be extremely stupid about how to market
it, accidentally showing in the process his disrespect for the standard
and those who wrote it and agreed to it, and not realizing how bad and
stupid this was. It was about the annoyingly silly macro for about two
exchanges until the underlying and _real_ feelings about the standard
emerged. If you still think it is about the macro, you have completely
failed to _read_ the discussion or you have bought the rogue programmer's
version, which was that the standard does not matter, only his personal
likes and dislikes do, and you do not see that this is destructive in a
setting where people hammer out a fragile agreement over many years.
What we learned from the exercise was that some people and companies
within out community do not value building a society upon the standard,
but rather only on their product. Some of us think that this modus
operandi belongs in jail together with Bill Gates and his evil empire,
who have made their billions on saying they implement a specification
only to show that what they really wanted was to destroy it by tricking
everybody to think they would continue to adhere to it, but it was at
best a snapshot of two bodies in motion with very different momentum and
destination with only incidental overlap in position for a short while.
This problem has been apparent to a lot of people for a really long time
when it comes to this company, but I thought I could trust their desire
to work with me towards better conformance. That trust was fragile to
begin with, but it did not survive the frontal assault on the concept of
standardization that their chief scientist undertook in order to defend
his little macro. Given the obvious difference in prioritization of a
pretty stupid macro and the future of his company's revenue and a
community based on a significant point of agreement, those who want the
stupid macro can go to them, while those who want an implementation of
the ANSI standard Common Lisp should go elsewhere. Since their product
cannot be used to build competing products, and _they_ reserve the right
to determine what that means, they have in effect already departed from
the Common Lisp community to rebuild their own from the past, before
Common Lisp. This would not matter to me at all if they at least had the
basic integrity and honesty to say so, but _no_, even with a number of
conscious deviations from the standard, they still call it Common Lisp,
and this violates basic "truth in marketing" principles just for
starters. Their products does not even differ in the *features* list
despite serious differences in features, so the standard way of
communicating different versions is not employed, forcing people to use
other ways to find out what kind of environment the program executes in
that in all likelihood do not work in other implementations unless that
code is itself protected with standard measures. All in all, they may
speak about the importance of conformance, but in the end, their heart is
so far elsewhere that their conformance is only _incidental_, and with so
many signs telling everybody that their first choice is not to conform,
the inability to bring their rogue programmer into line becomes important
to those who want to estimate their momentum and destination.
It appears to me that you are simply inexperienced in public debate.
Many people are. Many engineers seem to believe that they do not need to
know about politics or legal matters and some are so staggeringly
unintelligent and ignorant and stupid that they think "politician" or
"lawyer" is an insult because they mostly feel powerless about all the
weird decisions they never bothered to understand how their superiors
could make.
All it tells more informed people is that they
are freeloaders on the complex infrastructure known as "society" and
cannot be expected to do the right thing unless somebody more informed
keeps them in check with a cattle prod. What we learned in the heated
exchange that begain with that silly little macro was that all the
measures available to us on USENET were insufficient to make this company
and their rogue programmer fall into line. That does not bode well for
what it requires to make the company and their rogue programmer behave
according to any _other_ instruments of agreement, either.
However, a lot of people do not have the slightest problem dealing with
Microsoft, either, shelling out exorbitant amounts of money for licenses
and not knowing whether the information entrusted to their bogus binary
formats will survive a version or how many viruses they must be prepared
to deal with, so clearly, a lot of people are completely devoid of such
concerns as I have about these things. However, watching the way their
people respond to serious criticism about their practices makes our local
incident pales in comparison. Microsoft's people really believe they are
at war with their own customers and use more propaganda techniques than
were employed by their teacher in propaganda, Joseph Goebbels, to keep
their own customers happy with a most favorable impression of themselves
while the rest of the world are extremely conscious of what it means that
so many people are so easily duped by an increasingly destructive force.
However, some of us do not deal with organized crime, terrorists, mafia,
Microsoft, dictatorships, or companies known to defraud customers, and it
would be very nice if we did not similarly have to avoid a company in the
Common Lisp community just because they have a rogue programmer who is
not smart enough to figure out the importance of legal instruments of
agreement and how valuable it is to adhere to and respect a specification,
but I fear that it is more than that one rogue programmer. Finding the
source of something like this and resecting it is not a simple task, as
most people work very hard to conceal their true motives and objectives,
even when it is painfully obvious to everyone else, as was the case here
-- starting with a stupid rejection of standard features in favor of a
silly old macro a rogue programmer refused to let go of. Sometimes, we
learn most about people from what they will not back down from.
///
--
Erik Naggum wrote:
> Microsoft's people really believe they are
> at war with their own customers and use more propaganda techniques than
> were employed by their teacher in propaganda, Joseph Goebbels, to keep
> their own customers happy with a most favorable impression of themselves
> while the rest of the world are extremely conscious of what it means that
> so many people are so easily duped by an increasingly destructive force.
If you throw in Goebbels and the Nazis here then in turn there is really no hope
for you...grow up!
>
> However, some of us do not deal with organized crime, terrorists, mafia,
> Microsoft, dictatorships, or companies known to defraud customers, and it
> would be very nice if we did not similarly have to avoid a company in the
> Common Lisp community just because they have a rogue programmer who is
> not smart enough to figure out the importance of legal instruments of
> agreement and how valuable it is to adhere to and respect a specification,
> but I fear that it is more than that one rogue programmer.
That is the reason why Sun Microsystems is charging about twice the prices in
Europe for their products; okay we in Austria here get everything from Sun for
free (and gratis, even).
S. Gonzi
* Siegfried Gonzi <···············@kfunigraz.ac.at>
| If you throw in Goebbels and the Nazis here then in turn there is really
| no hope for you...grow up!
No, _you_ threw in the Nazis here, Siegfried Gonzi. Please realize this,
and it will indeed aid you in that very hard and painful process of
growing up and getting the hell _over_ your stupid psychological hangups.
Did anyone understand what I said about 1 in 20 people blowing their
fuses when they encounter a challenge to their tacit assumptions? Please
let me know how this Siegfried Gonzi shit could fail to understand the
context of what I said to be strictly restricted to _propaganda_? Shall
we be forced to speak about only those things which will not inflame some
retarded little fuck from a culture that has yet _understand_ how it
collectively turned to the dark side of the Force? I _expect_ that
people get over the harsh experiences of life.
Understanding how so many people could believe something so bad and feel
happy about it so long is _vitally_ important, but the people who need it
most are the most reluctant. However, it can happen in any country and
in any culture at any time. It is the nature of the propaganda and of
the psychology of men that determines how this works. The psychology of
propaganda discovered and exercised first by Josepth Goebbels is not even
_remotely_ related to the specific politics that employed it, but I guess
it takes people who _have_ grown up to realize these things. So go play
in traffic, you distasteful, hypersensitive, little piece of shit who
dares bring in the Nazis to a serious discussion among mature adults!
The fact that you run screaming to your Mom whenever someone pushes your
Nazi button is something you should talk about with a mature adult with
experience in untangling such mental knots, Siegfried Gonzi. Get help!
///
--
Erik Naggum wrote:
> * Siegfried Gonzi <···············@kfunigraz.ac.at>
> | If you throw in Goebbels and the Nazis here then in turn there is really
> | no hope for you...grow up!
>
> No, _you_ threw in the Nazis here, Siegfried Gonzi. Please realize this,
> and it will indeed aid you in that very hard and painful process of
> growing up and getting the hell _over_ your stupid psychological hangups.
Okay, your knowing of history is not that good. Sorry, I forget your only
knowledge is Lisp and some pseudo-knowledge of psychology! I am used to
discuss with intelligent people; if I want to listen to clowns I turn on the
television...
Please: Could anybody tell me (per private mail) how I can use my killfile and
Netscape. I often tried (seriously) to put in Naggum there but it does not work
(Netscape 4.7); the plan not reading Naggum-Clown is often hard to resist; a
killfile (he is irrelevant for my person, I will not miss anything) could help,
because then he is out of my mind (okay posts which handles about Naggum are
another problem). I prefer Netscape, because Outlook express cannot show
messages as Netscape does.
S. Gonzi
In article <·················@kfunigraz.ac.at>,
Siegfried Gonzi wrote:
> Please: Could anybody tell me (per private mail) how I can use my
> killfile and Netscape.
Is it because you can use your killfile and netscape that you came
to me?
> I often tried (seriously) to put in Naggum there but it does not work
> (Netscape 4.7);
Does it bother you that it does not work netscape 4 7?
> the plan not reading Naggum-Clown is often hard to resist;
Why do you say that?
> a killfile (he is irrelevant for my person, I will not miss anything)
> could help, because then he is out of my mind (okay posts which
> handles about Naggum are another problem).
When did you first know that then he is out of your mind?
> I prefer Netscape, because Outlook express cannot show
> messages as Netscape does.
Is the fact that outlook express cannot show messages as netscape
does the real reason?
--
<keke at mac com>
····@ma.ccom (Takehiko Abe) writes:
> In article <·················@kfunigraz.ac.at>,
> Siegfried Gonzi wrote:
>
> > Please: Could anybody tell me (per private mail) how I can use my
> > killfile and Netscape.
>
> Is it because you can use your killfile and netscape that you came
> to me?
Is it because I can use my killfile and netscape that I came to you
that you came to me?
--
--Ed Cashin integrit file-verification system:
·······@terry.uga.edu http://integrit.sourceforge.net/
Note: If you want me to send you email, don't munge your address.
* Siegfried Gonzi <···············@kfunigraz.ac.at>
| Okay, your knowing of history is not that good. Sorry, I forget your
| only knowledge is Lisp and some pseudo-knowledge of psychology! I am
| used to discuss with intelligent people; if I want to listen to clowns I
| turn on the television...
I could not ask for a better example than you if I wanted an illustration
of how the nutballs out there fail to deal with challenges to their tacit
assumptions. Thank you. You have been an exceptionally useful idiot.
///
--
Rajappa Iyer wrote:
>
> Kenny Tilton <·······@nyc.rr.com> writes:
>
> > talk about Lisp, not personalities.
>
> If this criteria were applied consistently and without regard to the
> author, then ... Why the blind eye?
(a) the archives do not support the "blind eye" assertion; no c.l.l.
flamer goes unchallenged, and (b) JFB has been dealt with gently given
his posts. So there is no inconsistency, or at worst none that cannot be
explained by what JFB (to his credit) has conceded: he has contributed
no signal, only noise.
Look, I gotta get our Lisp app's friggin' scroll grid working...
kenny
clinisys
* Rajappa Iyer <···@panix.com>
| Like Jean-Fran�ois, I've been lurking in c.l.l. for a long time and I,
| for one, feel that Erik's posts have become increasingly
| content-free... so much so that it may not be a bad thing for either
| him personally or c.l.l. if he were to take a break from posting.
Perhaps it has something to do with the amazingly irritating habit of
fucks like that frog-eating vermin and possibly yourself to do nothing
but annoy me, talk about me, flame me, etc? You offer us _nothing_ of
value whatsoever, destroy any there might be, and you have the _gall_ to
complain about somebody else's contributions? Fuck you.
Just contribute intelligently and constructively on Common Lisp, you
goddamn asswipes! The more you pathetic losers whine, the less _worthy_
you are of anybody's thoughts on anything. Do not be surprised that you
do not receive much useful input from people and communities _you_ choose
to attack. Might I remind you retards that I have done _none_ of you
guys _anything_ at all and that there is _nothing_ I can do to prevent
you specimens from going mental the way you do? Shit-for-brains like
that French fuck come out of the blue with _no_ constructive purpose
whatsoever. This is _unique_ to those who attack me. This is why you
scumbags are much less tolerated than anyone else ever will be.
I would actually appreciate a moderated comp.lang.lisp. It would keep
the fucking retards out, and removing the source of irritation removes
the reactions to the irritants. People like you with the mental capacity
of bird droppings do not understand their own role but blame someone else
for their very own behavior. This is why you are _serious_ irritants.
This is _not_ a forum for your personal feelings about anybody else.
That you insufferable idiots do not understand this is perhaps the root
cause of your incessant need to bother the world with your coping
problems. If you cannot cope with the reality you live in, just go die,
do not bother other people with it so they are forced to cope with you.
And before you judge me yet again, take a good look at how this year has
started. If you think I get disappointed and hurt because yet another
despicable asshole chose to stage a fight here with me, you are quite
right. If you think a reeking French moron inspires me to help you guys
with anything and post insightful messages or share code with you, _do_
think again. _You_ are the problem. _You_ keep coming back to attack me
out of the blue for nothing in particular. _You_ use this newsgroup as a
sounding board for your _insane_ hatred of me. Get the fuck out of here
and think about what you are doing! You have absolutely no business even
_considering_ complaining about anybody else here or elsewhere. The fact
that you behave the way you do _validates_ and _approves_ my behavior for
the whole next millennium. If you really do not like what I do, THINK IT
THROUGH, and find a way to inspire me to want to be helpful to you. Do
you do that? No, you choose to attack, which is precisely what you think
is _wrong_! Instead, you tell me that it is correct and proper to attack
you pricks for _your_ behavior.
But worse, you are not even smart enough to make it part of a reasonably
on-topic response that ties the reaction to a _specific_ action! You are
_only_ hateful terrorists on a mission from your deity to pillage and
rape the community you invade, like throwbacks to a time of non-thinking
cave-dwelling brutes, which you are and mistake everybody else for, too.
I react to what people do in terms of clearly invalid logic, opinionated
ignorance and the arrogance that goes with it, posting lies and other
false information, insisting on destroying what other people do, etc, and
I confine myself to precisely that which that person does. When that
person starts thinking (yes, it happens, but you would never notice it,
because you _cannot_ think, and do not detect it when it happens), or
simply goes away, so does my criticism. You pussballs, however, attack
_only_ the person, there is no way to appease you, and you do not quit.
The sheer stupidity and amazing lack of intelligence displayed by those
who attack me here reaches record lows for mankind. Congratulations! I
do not think you can do better, quite unlike ever other person here that
I have ever criticized for anything, and most of those improve. The sick
fucks who come to comp.lang.lisp only to attack me, or indeed anyone,
prove to the whole planet that you are poster boys for abortion rights,
and none of you ever "recover" from your deeply ingrained personality
disorders that made you post your stenching filth in the first place.
Go ahead, prove my point!
///
--
Erik Naggum <····@naggum.net> writes:
> frog-eating
It turns out, actually, that the French don't eat frogs' legs much any
more... certainly it's hard to find them in Paris.
The only time I have ever eaten frogs' legs was in a Chinese
Restaurant in the Luxembourg.
FWIW :)
Christophe
--
Jesus College, Cambridge, CB5 8BL +44 1223 510 299
http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)
Christophe Rhodes <·····@cam.ac.uk> writes:
> Erik Naggum <····@naggum.net> writes:
>
> > frog-eating
>
> It turns out, actually, that the French don't eat frogs' legs much any
> more... certainly it's hard to find them in Paris.
Yeah, I commented on this once, and hypothesized that maybe it was a
result of Anglo and American teasing, and my (Parisian) cousin rolled
her eyes at me.
> The only time I have ever eaten frogs' legs was in a Chinese
> Restaurant in the Luxembourg.
During that same vacation, I had grenouilles a` la provenc,ale
prepared by this same cousin's grandmother, so I suspect the more
countrified French will still be eating them for a while (kinda like
chitterlings in the US). It always has mystified how people who
... how to say this delicately ... aren't exactly known for their fine
cuisine, say, anglos, scandinavians, germans, etc., are so prone to
making fun of the food of the French, Italians, Africans, Chinese,
etc. I've always told myself it's jealousy :)
> FWIW :)
Probably about the same as a centime in a few months :)
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@apocalypse.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> It always has mystified how people who
> ... how to say this delicately ... aren't exactly known for their fine
> cuisine, say, anglos, scandinavians, germans, etc., are so prone to
> making fun of the food of the French, Italians, Africans, Chinese,
> etc. I've always told myself it's jealousy :)
Hello - what's this? Scandinavians not known for their fine
cuisine? Have you never heard of rakefisk (trout left to rot in a
barrel for a few weeks), smalahove (sheep's head, served whole with
the eyes in place), lutefisk (saltwater fish marinated in lye), etc?
All of these are quite common in Norway...
With delicacies like these, Norwegians have *no* reason to be
jealous of their southern-European neighbours.
--
Raymond Wiker Mail: ·············@fast.no
Senior Software Engineer Web: http://www.fast.no/
Fast Search & Transfer ASA Phone: +47 23 01 11 60
P.O. Box 1677 Vika Fax: +47 35 54 87 99
NO-0120 Oslo, NORWAY Mob: +47 48 01 11 60
Try FAST Search: http://alltheweb.com/
On 05 Jan 2002 20:14:37 +0100, Raymond Wiker <·············@fast.no> wrote:
>barrel for a few weeks), smalahove (sheep's head, served whole with
>the eyes in place),
My goodness... I thought that only in Bolivia people ate that! ;-) BTW, they
call it 'rostro asado' which means 'roasted face'! };-D
--
Fernando Rodr�guez
frr at wanadoo dot es
--
Raymond Wiker <·············@fast.no> writes:
> Hello - what's this? Scandinavians not known for their fine
> cuisine? Have you never heard of rakefisk (trout left to rot in a
> barrel for a few weeks), smalahove (sheep's head, served whole with
> the eyes in place), lutefisk (saltwater fish marinated in lye), etc?
> All of these are quite common in Norway...
Completely OT, but there is a very amusing passage about norwegian
food habits in the hilariously funny book "Three in Norway", first
published in 1882 and written by "Two of Them", two of the three
brave englishmen that explored the wild mountains and strange food
of inner Norway at a time when off-the-beaten-track tourism was
very uncommon.
Seems to available at:
https://secure.ffcl.com/book.asp?id=84
--
(espen)
···@apocalypse.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> Yeah, I commented on this once, and hypothesized that maybe it was a
> result of Anglo and American teasing, and my (Parisian) cousin rolled
> her eyes at me.
You rolled them back, I trust?
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
Daniel Barlow <···@telent.net> writes:
> ···@apocalypse.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
> > Yeah, I commented on this once, and hypothesized that maybe it was a
> > result of Anglo and American teasing, and my (Parisian) cousin rolled
> > her eyes at me.
>
> You rolled them back, I trust?
no transaction involving organic matter is ever unsuccessful in
France. (or was it China?)
--
This is Usenet. Why in the name of **blue starry-eyed fuck** do you
need reality?
-- Mike Dickson, in r.m.p.
On Sat, 05 Jan 2002 00:29:41 GMT, Erik Naggum <····@naggum.net> wrote:
> ... fucks like that frog-eating vermin ...
> ...Fuck you....
> ... Shit-for-brains ...
> ...that French fuck ...
> ...scumbags...
> ... the fucking retards...
> ...just go die...
> ...reeking French moron ...
> ...Get the fuck out of here...
> ...you pricks ...
> ...pussballs...
> ...sick fucks ...
> ...stenching filth ...
You are becoming repetitive.
How about some nice norwegian swear words ?
Erik Naggum <····@naggum.net> writes:
...
> I would actually appreciate a moderated comp.lang.lisp.
That sounds like a real time-saver.
There's a lot of noise right now, but it's worth it for the gems I
find here: insightful views on internationalization; interesting
points on software licensing; historical tidbits; ...
comp.lang.c.moderated has a great moderator, and the information
density in that newsgroup is very nice, but who would moderate
comp.lang.lisp.moderated?
--
--Ed Cashin integrit file-verification system:
·······@terry.uga.edu http://integrit.sourceforge.net/
Note: If you want me to send you email, don't munge your address.
On 1/5/02 22.22, in article ·················@terry.uga.edu, "Ed L Cashin"
<·······@terry.uga.edu> wrote:
> That sounds like a real time-saver.
It would also preclude many posts from a number of popular participants
under any sane moderation scheme. Why have a moderated group if it admits
discussion of the GPL and posts with 10 lines of lisp content and 90
covering something else entirely?
> There's a lot of noise right now, but it's worth it for the gems I
> find here: insightful views on internationalization; interesting
> points on software licensing; historical tidbits; ...
Of the three topics you mention, one would be wildly off-topic if the
charter were similar to comp.lang.c.moderated.
Killfiles are easier to implement and require no discussion.
^L
Louis Theran <······@cs.umass.edu> writes:
> On 1/5/02 22.22, in article ·················@terry.uga.edu, "Ed L Cashin"
> <·······@terry.uga.edu> wrote:
...
> > There's a lot of noise right now, but it's worth it for the gems I
> > find here: insightful views on internationalization; interesting
> > points on software licensing; historical tidbits; ...
>
> Of the three topics you mention, one would be wildly off-topic if the
> charter were similar to comp.lang.c.moderated.
>
>
> Killfiles are easier to implement and require no discussion.
But killfiles do not distinguish between posts about lisp (and related
tangents) and posts that quibble over personal attacks.
--
--Ed Cashin integrit file-verification system:
·······@terry.uga.edu http://integrit.sourceforge.net/
Note: If you want me to send you email, don't munge your address.
[ Ed L Cashin ]
> But killfiles do not distinguish between posts about lisp (and related
> tangents) and posts that quibble over personal attacks.
As you use a new Gnus you can do much more than simple killfiling. I'd
probably settle for killing articles from a few select posters, those
crossposted to comp.lang.{scheme,prolog} (and possibly some more), and
those with "Naggum" or other tell-tale words in subject, and then use
adaptive scoring to remove threads I see won't have any more useful
content.
Martin
--
"An ideal world is left as an exercise to the reader."
-Paul Graham, On Lisp
* Louis Theran <······@cs.umass.edu>
| It would also preclude many posts from a number of popular participants
| under any sane moderation scheme. Why have a moderated group if it admits
| discussion of the GPL and posts with 10 lines of lisp content and 90
| covering something else entirely?
Moderation is used to keep people in moderate touch with reality. We
have already seen that some people think this newsgroup is _about_ their
personal feelings for other people as such, but that is not the case.
E.g., you would never see articles by Janos Blazi or Israel Ray Thomas or
Jean-Fran�ois Brouillet were this a moderated forum. Good moderation
does not keep the flames out -- it keeps the _irritants_ out so there is
no need for flames.
| Of the three topics you mention, one would be wildly off-topic if the
| charter were similar to comp.lang.c.moderated.
There should be no danger of that. Few moderated newsgroups are alike,
just as few newsgroups are alike.
| Killfiles are easier to implement and require no discussion.
What is the point with the perfect killfile if you cannot tell anyone?
///
--
"Erik Naggum" <····@naggum.net> wrote:
> E.g., you would never see articles by Janos Blazi or Israel Ray Thomas or
> Jean-Fran�ois Brouillet were this a moderated forum.
E X A C T L Y ! -- That's my main point.
(But I don't speak for the other two persons)
--
Jean-Fran�ois Brouillet (who, incidentally, failed to die in a car
accident, some 20 hours ago ;-(
In article <···················@mac.com>, Jean-Fran�ois Brouillet wrote:
> "Erik Naggum" <····@naggum.net> wrote:
>
>> E.g., you would never see articles by Janos Blazi or Israel Ray Thomas or
>> Jean-Fran�ois Brouillet were this a moderated forum.
>
> E X A C T L Y ! -- That's my main point.
>
> (But I don't speak for the other two persons)
>
> --
> Jean-Fran�ois Brouillet (who, incidentally, failed to die in a car
> accident, some 20 hours ago ;-(
>
I could not find the article you quoted, next time please use the
article id so I double checl my self. But with that said if I
remember correctly the full text of the message boiled down to Erik
would not get droped and you would. If this is what you want you can
achieve this by simply not posting any more.
marc
Marc,
you'll find below the entire article (usenet refs included) I
was quoting from.
Now, re: your answer.
I will stay calm, but you just simply admitted that you didn't understand
what I wrote.
There's this whole idea of cause and effect that you seem to not grasp
very easily.
So let's resort to boolean logic here:
IF comp.lang.lisp was moderated THEN
IF Naggum was posting inflammatory messages THEN
The moderator would not post them
(or edit them himself, or return them to Naggum for editing)
THEREFORE
Jean-Fran�ois Brouillet (and others) would happily
*not* post in reaction to Naggum's trashing.
The thing that you completely missed is that Naggum's
> you would never see articles by [...]
can be explained by two UNRELATED causes, namely:
a) JFB posts trash and gets moderated down (your ONLY understanding)
b) JFB *has nothing to react against* and doesn't bother even reacting
to a non-existent piece of Naggum trash.
Is it clearer now, or should I start over again ?
Your call.
--
Jean-Fran�ois Brouillet
On 6/1/02 22:54, in article ···················@oscar.eng.cv.net, "Marc
Spitzer" <····@oscar.eng.cv.net> wrote:
> In article <···················@mac.com>, Jean-Fran�ois Brouillet wrote:
>> "Erik Naggum" <····@naggum.net> wrote:
>>
>>> E.g., you would never see articles by Janos Blazi or Israel Ray Thomas or
>>> Jean-Fran�ois Brouillet were this a moderated forum.
>>
>> E X A C T L Y ! -- That's my main point.
>>
>> (But I don't speak for the other two persons)
>>
>> --
>> Jean-Fran�ois Brouillet (who, incidentally, failed to die in a car
>> accident, some 20 hours ago ;-(
>>
>
> I could not find the article you quoted, next time please use the
> article id so I double checl my self. But with that said if I
> remember correctly the full text of the message boiled down to Erik
> would not get droped and you would. If this is what you want you can
> achieve this by simply not posting any more.
>
> marc
Xref: news.demon.co.uk comp.lang.lisp:55284
Path:
news.demon.co.uk!demon!dispose.news.demon.net!demon!xara.net!gxn.net!easynet
-monga!easynet.net!newsfeed.esat.net!nslave.kpnqwest.net!nloc.kpnqwest.net!n
master.kpnqwest.net!nreader3.kpnqwest.net.POSTED!not-for-mail
Newsgroups: comp.lang.lisp
Subject: Re: moderation (was Re: Nagging Naggum)
References: <···············@news.t-online.com>
<···············@shell01.TheWorld.com>
<······················@news2.calgary.shaw.ca> <············@hermit.athome>
<················@naggum.net> <············@rznews2.rrze.uni-erlangen.de>
<···················@mac.com> <················@naggum.net>
<···················@mac.com> <··································@4ax.com>
<················@naggum.net> <···················@mac.com>
<················@naggum.net> <···················@mac.com>
<···················@news3.calgary.shaw.ca> <···················@mac.com>
<···············@panix1.panix.com> <················@naggum.net>
<·················@terry.uga.edu> <····················@cs.umass.edu>
Mail-Copies-To: never
From: Erik Naggum <····@naggum.net>
Message-ID: <················@naggum.net>
Organization: Naggum Software, Oslo, Norway
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Date: Sun, 06 Jan 2002 12:01:33 GMT
X-Complaints-To: ··········@KPNQwest.no
X-Trace: nreader3.kpnqwest.net 1010318493 193.71.66.49 (Sun, 06 Jan 2002
13:01:33 MET)
NNTP-Posting-Date: Sun, 06 Jan 2002 13:01:33 MET
Lines: 26
* Louis Theran <······@cs.umass.edu>
| It would also preclude many posts from a number of popular participants
| under any sane moderation scheme. Why have a moderated group if it admits
| discussion of the GPL and posts with 10 lines of lisp content and 90
| covering something else entirely?
Moderation is used to keep people in moderate touch with reality. We
have already seen that some people think this newsgroup is _about_ their
personal feelings for other people as such, but that is not the case.
E.g., you would never see articles by Janos Blazi or Israel Ray Thomas or
Jean-Fran�ois Brouillet were this a moderated forum. Good moderation
does not keep the flames out -- it keeps the _irritants_ out so there is
no need for flames.
| Of the three topics you mention, one would be wildly off-topic if the
| charter were similar to comp.lang.c.moderated.
There should be no danger of that. Few moderated newsgroups are alike,
just as few newsgroups are alike.
| Killfiles are easier to implement and require no discussion.
What is the point with the perfect killfile if you cannot tell anyone?
///
--
In article <···················@mac.com>, Jean-Fran�ois Brouillet wrote:
> Jean-Fran�ois Brouillet (and others) would happily
> *not* post in reaction to Naggum's trashing.
You don't need a parental figure to control your behavior. Why can't you
just *not* post in reaction, all by yourself?
"Kaz Kylheku" <···@accton.shaw.ca> wrote:
> In article <···················@mac.com>, Jean-Fran�ois Brouillet wrote:
>> Jean-Fran�ois Brouillet (and others) would happily
>> *not* post in reaction to Naggum's trashing.
>
> You don't need a parental figure to control your behavior. Why can't you
> just *not* post in reaction, all by yourself?
(using my didactic hat, and sighing...)
in article ···················@mac.com, I <·····@mac.com> wrote:
> Naggum, enough is too much. [...]
So, I'm sorry I have to elevate the debate and go to the rhetoric section,
but the question you ask "Why can't you ..." has *already* been answered
even before you asked.
There are times when I start to wonder whether Naggum is not right, after
all, and if the people in this NG actually understand anything to anything.
Being personally involved in those threads give them a totally different
flavor than when I was merely lurking; but if (Kylheku Spitzer) are really
representative of the c.l.l. folks, I might as well drop the ball and let it
go. CL might be an interesting language/environment, CL'ers on c.l.l. seem
to be an entirely different story. This is certainly no excuse for Naggum
for being rude, but an explanation for what he finds so irritating.
Please, please, please. UNDERSTAND what you read before replying. That way
YOU WON'T WASTE bandwidth and WON'T FORCE ME EITHER to reply.
--
Jean-Fran�ois Brouillet, A more and more annoyed ex-lurker who'd prefer
to lurk back again.
In article <···················@mac.com>, Jean-Fran�ois Brouillet wrote:
> "Kaz Kylheku" <···@accton.shaw.ca> wrote:
>
>> In article <···················@mac.com>, Jean-Fran�ois Brouillet wrote:
>>> Jean-Fran�ois Brouillet (and others) would happily
>>> *not* post in reaction to Naggum's trashing.
>>
>> You don't need a parental figure to control your behavior. Why can't you
>> just *not* post in reaction, all by yourself?
>
> (using my didactic hat, and sighing...)
>
> in article ···················@mac.com, I <·····@mac.com> wrote:
>
>> Naggum, enough is too much. [...]
>
> So, I'm sorry I have to elevate the debate and go to the rhetoric section,
> but the question you ask "Why can't you ..." has *already* been answered
> even before you asked.
>
> There are times when I start to wonder whether Naggum is not right, after
> all, and if the people in this NG actually understand anything to anything.
>
> Being personally involved in those threads give them a totally different
> flavor than when I was merely lurking; but if (Kylheku Spitzer) are really
> representative of the c.l.l. folks, I might as well drop the ball and let it
> go. CL might be an interesting language/environment, CL'ers on c.l.l. seem
> to be an entirely different story. This is certainly no excuse for Naggum
> for being rude, but an explanation for what he finds so irritating.
>
> Please, please, please. UNDERSTAND what you read before replying. That way
> YOU WON'T WASTE bandwidth and WON'T FORCE ME EITHER to reply.
>
Wait a minute, you made a statement that you were the blameless victim
of a foul attack by Erik, correct? I said that this goes against what
I have observed of Erik's behavior so I do not agree with you and if
you want me to agree with you please present some proof. what is
unreasonable?
I have come to the conclusion that you have a closed mind because you
refuse or are unable to discuse this in a reasonable manner. Because
this might prove your claims of unwarented vile abuse just might not
be so unwarented after all.
marc
> --
> Jean-Fran�ois Brouillet, A more and more annoyed ex-lurker who'd prefer
> to lurk back again.
>
so go lurk already
* ···@accton.shaw.ca (Kaz Kylheku)
| You don't need a parental figure to control your behavior. Why can't you
| just *not* post in reaction, all by yourself?
With all due respect, I think you are missing his point. The whole point
that Jean-Fran�ois Brouillet is making is that it is my fault that he and
other lunatics like him have to post insane flames and expose themselves
as deranged morons when they experience a serious failure to cope with
the reality they live in. If these people were at all capable of being
responsible for their own behavior to begin with, they would never have
had the personality disorders they have. The desire to _attack_ someone
because you have built up anger against them even though you have never
been hurt directly is perhaps not insane in itself, but lacking the self-
control to stop yourself from acting on it _is_. Since most people are
well aware of just how insane it is to attack someone else unprovoked by
anything they have actually done, those who really _are_ deranged will
resort to "you made me do it", discarding every shred of mental stability
in the process, as we see when they think people are "clones" of the
enemy they have chosen to attack, and they are even so out of control
that they attack innocent people and blame what somebody else have done
to them for it. Just watch Jean-Fran�ois Brouillet and how he makes all
of his behavioral and personality problems _my_ fault. In his view, he
is a puppet and I hold the strings. The fact that he is out of control
is obvious to anyone, but I hold no strings. Instead of realizing just
how insane it is to become so emotionally worked up about something you
start to attack people and seeking help to get over his problems, he is
the kind of person that goes from private insane rage to public insane
attacks. Ever noticed how actual discussions heat up slowly, but how
Jean-Fran�ois Brouillet come out of nowhere screaming and with his gun
blazing? Ever noticed how these insane attackers _always_ behave this
way? They are _not_ party to the discussion, they never have a real
argument to offer, and they enter with guns blazing. Nobody else do
that: those that these insane attackers attack, spend a considerable
amount of time trying to get the other party to understand what is at
stake, because they usually want something constructive and are deeply
frustrated by the other party, but these insane attackers have nothing to
offer _anyone_ -- they are just out to attack their enemy for no reason
other than their own personal insanity. They cannot be told to quit,
either, because _they_ are not controlling their own behavior, their
chosen enemy has all the fault for their raging insanity. There is in
fact _nothing_ that this enemy can do, either -- if there were, these
people would have suggested it _before_ becoming insanely enraged.
One can understand that people who are in a fight may get worked up while
defending themselves (but attacking innocent bystanders it indefensible).
The sheer insanity of Jean-Fran�ois Brouillet and his like cannot be
explained with reference to normal people; suggestions that work on
normal people do not work on them. You _have_ to refer people who react
the way he and those like him do to the medical profession. Whether they
were once "triggered" by something that happened outside of their own
fantasy world or not is immaterial by the time they chose to attack and
blame someone else for their behavior. This is simply not something
people who have a healthy mental state do. In my view, when somebody has
done what Jean-Fran�ois Brouillet has done, they have proven to the whole
world that they lack impulse control and thus are _dangerous_. Who can
tell what will drive them to attack someone next? They came out of
nowhere and they had become insanely enraged while watching something
from afar. Being a public figure, which I guess I am, means that some
things like Jean-Fran�ois Brouillet this will seek me out, and he has
also shown us his deep hatred for politicians, another prime target for
the really insane nutjobs out there. If he keeps it up, I think there is
ample reason to alert the local police of the powder-keg in their midst,
who has already demonstrated that he blows up and is out of control.
Now, let us have another display of the fireworks known as Jean-Fran�ois
Brouillet blowing up and being completely out of control. These folks
are as predictable as time bombs and never figure out that they can just
seize control over their irrational rage -- if they could, they would not
have blown up to begin with, and such a personality trait is not cured by
reasoning with them.
///
--
In article <················@naggum.net>, Erik Naggum wrote:
>* ···@accton.shaw.ca (Kaz Kylheku)
>| You don't need a parental figure to control your behavior. Why can't you
>| just *not* post in reaction, all by yourself?
>
> With all due respect, I think you are missing his point. The whole point
> that Jean-Fran�ois Brouillet is making is that it is my fault that he and
> other lunatics like him have to post insane flames and expose themselves
> as deranged morons when they experience a serious failure to cope with
> the reality they live in.
Ah yes; in fact there was something like that in his followup to my above
posting, like ``why do you FORCE me to reply''? Brouillet seems to be believe
that a mysterious force emanates from a Usenet article which irresistibly
draws a followup from a disagreeing reader. ;)
In article <················@naggum.net>, Erik Naggum wrote:
>* ···@accton.shaw.ca (Kaz Kylheku)
>| You don't need a parental figure to control your behavior. Why can't you
>| just *not* post in reaction, all by yourself?
>
> With all due respect, I think you are missing his point. The whole point
> that Jean-Fran�ois Brouillet is making is that it is my fault that he and
> other lunatics like him have to post insane flames and expose themselves
> as deranged morons when they experience a serious failure to cope with
> the reality they live in.
Ah yes; in fact there was something like that in his followup to my
above posting.
The exact words are: ``UNDERSTAND what you read before replying. That way
YOU WON'T WASTE bandwidth and WON'T FORCE ME EITHER to reply.''
Brouillet seems to be believe that a mysterious force emanates from a
Usenet article which irresistibly draws a followup from a disagreeing
reader.
The only solution is to moderate the original article, thereby suppressing
the force.
Heh.
On Mon, 07 Jan 2002 13:18:33 GMT, Erik Naggum <····@naggum.net> wrote:
>* ···@accton.shaw.ca (Kaz Kylheku)
>| You don't need a parental figure to control your behavior. Why can't you
>| just *not* post in reaction, all by yourself?
{ the usual multi-page tirade from Naggum deleted }
This demonstrates yet again that like a spoilt child, he either
cannot or will not control himself.
As to why... who knows, who cares.
In article <···················@mac.com>, Jean-Fran�ois Brouillet wrote:
> Marc,
>
> you'll find below the entire article (usenet refs included) I
> was quoting from.
thank you
>
> Now, re: your answer.
>
> I will stay calm, but you just simply admitted that you didn't understand
> what I wrote.
I was commenting on what was quoted in your message and how you
said it was a good idea. I just said how to go about obtaining
your requested goal, to be moderated out of existince in cll,
without having to do a lot of work(getting the group moderated)
And it is misleading to post half a thought as a quote, my reply
included the other half.
>
> There's this whole idea of cause and effect that you seem to not grasp
> very easily.
>
I grasp the idea of cause and effect. Do you grasp the idea that
you could be the cause? And Erik the effect?
Erik has been very consistant from what I have seen here. He does
not start these things and he does finish them. He wastes a huge
amount of time finishing them. And from what I have seen of his
posts vs. yours, he is much better at this then you are( or me).
> So let's resort to boolean logic here:
>
> IF comp.lang.lisp was moderated THEN
>
> IF Naggum was posting inflammatory messages THEN
What happens if you post something inflamatory first?
your message gets junked and no problem.
>
> The moderator would not post them
> (or edit them himself, or return them to Naggum for editing)
>
> THEREFORE
>
> Jean-Fran�ois Brouillet (and others) would happily
> *not* post in reaction to Naggum's trashing.
Erik does not go personal first, from what I have seen.
>
> The thing that you completely missed is that Naggum's
>
>> you would never see articles by [...]
>
> can be explained by two UNRELATED causes, namely:
>
> a) JFB posts trash and gets moderated down (your ONLY understanding)
> b) JFB *has nothing to react against* and doesn't bother even reacting
> to a non-existent piece of Naggum trash.
>
"A" is not my only understanding. But I have not seen start these
things. The only thing I can say is he does sometimes take things
wrong way and respond in kind. I think that that may be because he
does get attacked here a lot by a significant group of people here.
I am not saying that is what is or is not happening here, just that
it happens. Nor am I saying this is Erik's reason, just my own
oppinion of what his reason might be.
> Is it clearer now, or should I start over again ?
>
Well feel free. But to convince me you will have to prove
to me you are correct and you have not done that. You have
not proven that it is all Erik's fault at all. What I would
suggest you do to make this case is reread the first few posts
in this thread find what caused Erik to return fire and explain
how this was either:
1: A mistake on his part, and show how your words were
unreasonably misinterpreted by Erik.
2: A error of french->english tranlation that lead to
this misunderstanding.
3: something else that you are not the root cause of.
Please attach all the messages you are going to quote from so
we can discuse this in a reasonable manner. If you continue
to proclaim your innocence with out any documentation I will
still not agree with you.
marc
> Your call.
> --
> Jean-Fran�ois Brouillet
>
>
> On 6/1/02 22:54, in article ···················@oscar.eng.cv.net, "Marc
> Spitzer" <····@oscar.eng.cv.net> wrote:
>
>> In article <···················@mac.com>, Jean-Fran�ois Brouillet wrote:
>>> "Erik Naggum" <····@naggum.net> wrote:
>>>
>>>> E.g., you would never see articles by Janos Blazi or Israel Ray Thomas or
>>>> Jean-Fran�ois Brouillet were this a moderated forum.
>>>
>>> E X A C T L Y ! -- That's my main point.
>>>
>>> (But I don't speak for the other two persons)
>>>
>>> --
>>> Jean-Fran�ois Brouillet (who, incidentally, failed to die in a car
>>> accident, some 20 hours ago ;-(
>>>
>>
>> I could not find the article you quoted, next time please use the
>> article id so I double checl my self. But with that said if I
>> remember correctly the full text of the message boiled down to Erik
>> would not get droped and you would. If this is what you want you can
>> achieve this by simply not posting any more.
>>
>> marc
>
>
>
>
> Xref: news.demon.co.uk comp.lang.lisp:55284
> Path:
> news.demon.co.uk!demon!dispose.news.demon.net!demon!xara.net!gxn.net!easynet
> -monga!easynet.net!newsfeed.esat.net!nslave.kpnqwest.net!nloc.kpnqwest.net!n
> master.kpnqwest.net!nreader3.kpnqwest.net.POSTED!not-for-mail
> Newsgroups: comp.lang.lisp
> Subject: Re: moderation (was Re: Nagging Naggum)
> References: <···············@news.t-online.com>
> <···············@shell01.TheWorld.com>
> <······················@news2.calgary.shaw.ca> <············@hermit.athome>
> <················@naggum.net> <············@rznews2.rrze.uni-erlangen.de>
> <···················@mac.com> <················@naggum.net>
> <···················@mac.com> <··································@4ax.com>
> <················@naggum.net> <···················@mac.com>
> <················@naggum.net> <···················@mac.com>
> <···················@news3.calgary.shaw.ca> <···················@mac.com>
> <···············@panix1.panix.com> <················@naggum.net>
> <·················@terry.uga.edu> <····················@cs.umass.edu>
> Mail-Copies-To: never
> From: Erik Naggum <····@naggum.net>
> Message-ID: <················@naggum.net>
> Organization: Naggum Software, Oslo, Norway
> User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1
> MIME-Version: 1.0
> Content-Type: text/plain; charset=iso-8859-1
> Content-Transfer-Encoding: 8bit
> Date: Sun, 06 Jan 2002 12:01:33 GMT
> X-Complaints-To: ··········@KPNQwest.no
> X-Trace: nreader3.kpnqwest.net 1010318493 193.71.66.49 (Sun, 06 Jan 2002
> 13:01:33 MET)
> NNTP-Posting-Date: Sun, 06 Jan 2002 13:01:33 MET
> Lines: 26
>
> * Louis Theran <······@cs.umass.edu>
> | It would also preclude many posts from a number of popular participants
> | under any sane moderation scheme. Why have a moderated group if it admits
> | discussion of the GPL and posts with 10 lines of lisp content and 90
> | covering something else entirely?
>
> Moderation is used to keep people in moderate touch with reality. We
> have already seen that some people think this newsgroup is _about_ their
> personal feelings for other people as such, but that is not the case.
> E.g., you would never see articles by Janos Blazi or Israel Ray Thomas or
> Jean-Fran�ois Brouillet were this a moderated forum. Good moderation
> does not keep the flames out -- it keeps the _irritants_ out so there is
> no need for flames.
>
> | Of the three topics you mention, one would be wildly off-topic if the
> | charter were similar to comp.lang.c.moderated.
>
> There should be no danger of that. Few moderated newsgroups are alike,
> just as few newsgroups are alike.
>
> | Killfiles are easier to implement and require no discussion.
>
> What is the point with the perfect killfile if you cannot tell anyone?
>
> ///
> --
>
Marc, if you're so inclined, can we move this whole thing to private emails?
For the record, I never accused Naggum of _starting_ attacks, but of being
way too rude in his _answers_. Check all the threads if you wish and prove
me wrong!
(This whole thing is so boring now)
> You have
> not proven that it is all Erik's fault at all. What I would
> suggest you do to make this case is reread the first few posts
> in this thread find what caused Erik to return fire and explain
> how this was either:
> 1: A mistake on his part, and show how your words were
> unreasonably misinterpreted by Erik.
> 2: A error of french->english tranlation that lead to
> this misunderstanding.
> 3: something else that you are not the root cause of.
I didn't expect Naggum to stay silent at all. I wished he would; see
the world of difference?
The only (huge) mistake of Naggum is his language. And probably the
fact that he can't control his bile.
But this is the wrong thread.
Write me a private email if you wish, but it is not my desire to add any
more noise than strictly necessary to this NG.
--
Jean-Fran�ois Brouillet
* Jean-Fran�ois Brouillet <·····@mac.com>
| I didn't expect Naggum to stay silent at all. I wished he would; see
| the world of difference?
Do you even remember how I responded to your insane outburst of
uncontrolled rage? Shall I refresh your memory a little?
What an _interesting_ display of personality problems. Get help, OK?
Do you remember this? What was _your_ response? Do you need another
memory refresh? It was a new thread with subject "Nagging Naggum" in
which you proved that you are irrecovably _psychotic_. If you think you
will recover honorably from this episode, rest assured that I have a
rather long memory when it comes to asswipes like you. People who make
mistakes or believe something too strongly but who fix them or get
convinced of the rationality of the opposing view (without necessarily
agreeing with it), I forgive and forget, and the same seems to be true of
most other reasonably rational people. I think it is vitally important
that past mistakes not be used against people who have made a reasonable
effort to correct them. But those who stage massive attacks because they
are enraged by what they do not understand, have already shown such an
incredible lack of sound judgment that one must expect it to show up
again at some point and nobody should trust such a person to grow a brain.
People who think critically about the world they live in are full of
surprises, but since most of the hypotheses we come up with on our own
are wrong, just like you can extrapolate in any direction from a single
data point, it is important to expose one's ideas to the world. What
differentiates a rational and critical thinker from an irrational nutjob
is that the thinker seeks and embraces counter-information -- stuff that
can offer an alternative view or invalidate what one believes. Now, as
it turns out, viewing information one receives this way causes a lot of
waste of time because most of the people who have unusual information are
nutjobs who have not exposed _their_ ideas to others for their critical
comments or who have never sought any of the available counter-evidence
or ignored all that which floated their way. The argument you usually
hear from the nutjobs is that other people cannot deal with disagreement
-- because that is what makes _them_ the most queasy, and which they
think they cope with by trying not to disagree with others -- but the
problem is that most people do not deal well with challenges to their
_unstated_ beliefs.
| The only (huge) mistake of Naggum is his language. And probably the fact
| that he can't control his bile.
On the contrary, you and things like Israel Ray Thomas cannot control
your bile. I do control my bile very much, thank you. Dealing with
psychos like you requires intimate control over my own reactions. The
fact that I am measured and precise in how I exact my retribution is what
drives _you_ wild, is it not? The fact that I am _right_ about you is
what makes you erupt in even more flames. I think the only proper
reaction to an insane nutjob like yourself is to push you to and
optionally over the brink. There is a word for this: brinkmanship.
Take a look at how you erupted here. _That_ is evidence of your not even
being _able_ to control you bile.
| Write me a private email if you wish, but it is not my desire to add any
| more noise than strictly necessary to this NG.
You are still mistaken in what you believe in necessary.
///
--
On Sun, 06 Jan 2002 22:17:59 +0000, Jean-François Brouillet
<·····@mac.com> wrote:
>Jean-François Brouillet (who, incidentally, failed to die in a car
> accident, some 20 hours ago ;-(
Well, you'll just have to try again, won't you ?
:-)
Ed L Cashin <·······@terry.uga.edu> wrote in message news:<·················@terry.uga.edu>...
> comp.lang.c.moderated has a great moderator, and the information
> density in that newsgroup is very nice, but who would moderate
> comp.lang.lisp.moderated?
I would nominate Kent Pittman or Barry Margolin. Both are quite
knowlegable about Common Lisp. Both have proven quite moderate in
their comments, even when attacked. Of course, neither may have the
time or desire to moderate - it could be a fair piece of work.
Raf
·······@mediaone.net (Raffael Cavallaro) writes:
> Ed L Cashin <·······@terry.uga.edu> wrote in message news:<·················@terry.uga.edu>...
>
> > comp.lang.c.moderated has a great moderator, and the information
> > density in that newsgroup is very nice, but who would moderate
> > comp.lang.lisp.moderated?
>
> I would nominate Kent Pittman or Barry Margolin. Both are quite
> knowlegable about Common Lisp. Both have proven quite moderate in
> their comments, even when attacked. Of course, neither may have the
> time or desire to moderate - it could be a fair piece of work.
Yes, indeed, that would be a "fair piece of work," and would involve
the moderators having to cope with any incoming "crap" that people
thrust at them.
Note that that would include not just the usual spam, but also the
(doubtless to arise) accusations of unfair dealings.
"Wah. My post was rejected. You suck."
It's not evident that there's such a problem that it is necessary to
try to wrestle someone into the "moderator" position, not that there
are necessarily any applicants...
--
(concatenate 'string "cbbrowne" ·@ntlug.org")
http://www3.sympatico.ca/cbbrowne/lisp.html
"My mom said she learned how to swim. Someone took her out in the lake
and threw her off the boat. That's how she learned how to swim. I
said, 'Mom, they weren't trying to teach you how to swim.' "
-- Paula Poundstone
·······@mediaone.net (Raffael Cavallaro) writes:
> Ed L Cashin <·······@terry.uga.edu> wrote in message news:<·················@terry.uga.edu>...
>
> > comp.lang.c.moderated has a great moderator, and the information
> > density in that newsgroup is very nice, but who would moderate
> > comp.lang.lisp.moderated?
>
> I would nominate Kent Pittman or Barry Margolin. Both are quite
> knowlegable about Common Lisp. Both have proven quite moderate in
> their comments, even when attacked. Of course, neither may have the
> time or desire to moderate - it could be a fair piece of work.
Yes, indeed, that would be a "fair piece of work," and would involve
the moderators having to cope with any incoming "crap" that people
thrust at them.
Note that that would include not just the usual spam, but also the
(doubtless to arise) accusations of unfair dealings.
"Wah. My post was rejected. You suck."
It's not evident that there's such a problem that it is necessary to
try to wrestle someone into the "moderator" position, not that there
are necessarily any applicants...
--
(concatenate 'string "cbbrowne" ·@ntlug.org")
http://www3.sympatico.ca/cbbrowne/lisp.html
"My mom said she learned how to swim. Someone took her out in the lake
and threw her off the boat. That's how she learned how to swim. I
said, 'Mom, they weren't trying to teach you how to swim.' "
-- Paula Poundstone
·······@mediaone.net (Raffael Cavallaro) writes:
> Ed L Cashin <·······@terry.uga.edu> wrote in message news:<·················@terry.uga.edu>...
>
> > comp.lang.c.moderated has a great moderator, and the information
> > density in that newsgroup is very nice, but who would moderate
> > comp.lang.lisp.moderated?
>
> I would nominate Kent Pittman or Barry Margolin. Both are quite
("Pitman". I think there is a "Pittman" on this newsgroup of late,
but he's not me. If it helps you remember, the extra "t" that you might
consider putting in my last name is the one that belongs on the end of my
first name; that is, people are also always calling me "Ken" instead
of "Kent".)
> knowlegable about Common Lisp. Both have proven quite moderate in
> their comments, even when attacked. Of course, neither may have the
> time or desire to moderate - it could be a fair piece of work.
I don't mind "occasionally" contributing here but it's at my own discretion.
I couldn't possibly sign up for such work. PLUS I'd probably let through
stuff that is exactly the reason other people wanting moderation would
want to exclude.
There seem to be two competing, utterly incompatible theories of what it is
to make "constrcutive commentary" in the world...
Theory A. Anything that is said in a pleasant tone and is absent
a certain "bad list" of words is regarded as constructive. Anything
said in an angry tone or involving a certain "bad list" of words
is regarded as unconstructive.
Theory B. Anything that plainly identifies the difference between an
initial state and a goal state, and that identifies operators for
getting usefully from the initial to goal state is regarded as
constructive, regardless of its presentation. Anything, however
politely worded, that offers the reader no sense of how to move from
an initial state to a goal state, is not constructive.
I am a Theory B person.
As nearly as I can tell, all .moderated lists are about separating things
by theory A.
Pity.
I will probably hear back from this that someone will say, "yes, fine for
you, but not everyone wants to read all that bad stuff". What those people
will have not heard in so replying is that I also would like to leave out
"all that bad stuff". I just disagree as to which is the bad stuff.
In article <···············@shell01.TheWorld.com>, Kent M Pitman
<······@world.std.com> wrote:
> There seem to be two competing, utterly incompatible theories of what it is
> to make "constrcutive commentary" in the world...
>
> Theory A. Anything that is said in a pleasant tone and is absent
> a certain "bad list" of words is regarded as constructive. Anything
> said in an angry tone or involving a certain "bad list" of words
> is regarded as unconstructive.
>
> Theory B. Anything that plainly identifies the difference between an
> initial state and a goal state, and that identifies operators for
> getting usefully from the initial to goal state is regarded as
> constructive, regardless of its presentation. Anything, however
> politely worded, that offers the reader no sense of how to move from
> an initial state to a goal state, is not constructive.
>
> I am a Theory B person.
Really? Consider these responses:
Response 1: Why do you believe that these two theories are "utterly
incompatible"? They seem quite compatible to me. Why is it impossible to
have "theory C" which says that constructive commentary should conform to
both theories A and B?
Response 2: Initial state: Kent Pitman is a clueless moron. Goal state:
make Kent Pitman obtain a clue. Operators: call Kent Pitman a clueless
moron until the pain inflicted motivates him to obtain a clue.
It seems to me that response 1 is constructive according to theory A, and
2 is constructive according to theory B. Are you then really "a theory B
person" (which I take to mean that you prefer dialog that is constructive
according to theory B)? Is commentary 2 really the best way for me to
make the point that is disagree with your claim that theories A and B are
"utterly incompatible"?
I'm a theory C person: constructive commentary should be constructive in
the sense of theory B *and* it should be civil in tone. See comp.risks
(and Kent Pitman's posts to comp.lang.lisp :-) for excellent and ongoing
examples of constructive commentary according to theory C.
E.
* ···@jpl.nasa.gov (Erann Gat)
| Response 2: Initial state: Kent Pitman is a clueless moron. Goal state:
| make Kent Pitman obtain a clue. Operators: call Kent Pitman a clueless
| moron until the pain inflicted motivates him to obtain a clue.
Why would anyone want to attack a person for being constructive? That is
not how things work. That you assume constructive people would attack
other constructive people and assume that people who adhere to theory B
would offend your pathetic sensibilities if everybody else also adhered
to theory B, is highly offensive. It explains _why_ you need polite form
so much and do not understand that the worst personal attacks are given
in the most polite form. The more you just assume that other people are
bad, the harder it is to answer such an attack. This is what happens in
polite fora. Just look at how astonishingly evil the British upper class
can be -- so repressed that all hostility must be delivered "nicely" so
those who do not think things through do not understand what is going on.
Amazingly, this is considered an ideal by people who do not understand it.
| I'm a theory C person: constructive commentary should be constructive in
| the sense of theory B *and* it should be civil in tone. See comp.risks
| (and Kent Pitman's posts to comp.lang.lisp :-) for excellent and ongoing
| examples of constructive commentary according to theory C.
You are a theory C person because you think people attack each other when
they are constructive. That says _way_ too much about the way you think.
PS: You are not constructive when you blithely assume that other people
than yourself would be wantonly destructive. The implicit attack on
those who disagree with you is expressed in typical Erann Gat style.
///
--
In article <················@naggum.net>, Erik Naggum <····@naggum.net> wrote:
> * ···@jpl.nasa.gov (Erann Gat)
> | Response 2: Initial state: Kent Pitman is a clueless moron. Goal state:
> | make Kent Pitman obtain a clue. Operators: call Kent Pitman a clueless
> | moron until the pain inflicted motivates him to obtain a clue.
>
> Why would anyone want to attack a person for being constructive?
I don't know. Why don't you tell us? You do it all the time.
> | I'm a theory C person: constructive commentary should be constructive in
> | the sense of theory B *and* it should be civil in tone. See comp.risks
> | (and Kent Pitman's posts to comp.lang.lisp :-) for excellent and ongoing
> | examples of constructive commentary according to theory C.
>
> You are a theory C person because you think people attack each other when
> they are constructive. That says _way_ too much about the way you think.
No, that is not why I am a theory C person, but since you have
demonstrated an astonishing inability to consider the possibility that you
could be wrong about something I'm not going to waste the effort to try
and explain this to you.
> PS: You are not constructive when you blithely assume that other people
> than yourself would be wantonly destructive. The implicit attack on
> those who disagree with you is expressed in typical Erann Gat style.
You really should get over this idea that anyone who expresses an opinion
that is contrary to your worldview is attacking you. Despite the fact the
people occasionally get fed up with you and vent their frustrations on
this newsgroup, the world is not nearly as obsessed with you as you like
to imagine that it is.
The last time we exchanged messages you said you were giving up on me. If
you could be right about anything, please make it that.
E.
* Erann Gat
| I don't know. Why don't you tell us? You do it all the time.
So the personal attack comes out in the open, but I guess that it is a
good thing, because I do not, Erann. Just because you think so, does not
make it so, but you will probably never grasp this distiction if you have
not until now. When you have this bizarre need to make me much worse
than I could ever be, I conclude that what I actually do is insufficient
for any substantial criticism, you have just made up your mind that I am
the Devil or something, and then you draw your bizarre conclusions from
that instead of from observable reality. Using exaggerations like that
means that you are out of control and need an imaginary monster to attack
in order to defend your reactions to yourself. Demonization is well
known to happen to people who completely fail to cope with something they
do not like. It would appear that you are _frightened_ of me. This is
simply not healthy.
| No, that is not why I am a theory C person, but since you have
| demonstrated an astonishing inability to consider the possibility that
| you could be wrong about something I'm not going to waste the effort to
| try and explain this to you.
No, I have demonstrated an astonishing inability to consider the
possibility that something that you believe, which _is_ wrong, is right,
and therefore you confuse the two. The problem is, again, that you judge
people as you see yourself. This conflict would never happen if _you_
could consider that what you believe is wrong, but Erann is so right that
facts shall be subordinated to his will. We have had this discussion,
Erann, and I have made it very, very clear that I work hard to acquire
information that can update or alter or contradict my views, and also
present information to others in the same spirit, and the fact that I
change my mind about _something_ or other very frequently, should be very
clear evidence against your deluded attacks on me, and they get more and
more deluded as time goes on, to the point where they are so far from the
truth I fully expect _everybody_ to see how fantastically silly they are.
When was the last time you were even _right_ about anything you say about
me? How have you responded to contradictions to your beliefs? Just have
just been ever more aggressive in maintaining what you believe. I find
that to be very clear evidence of a serious lack of mental stability.
| You really should get over this idea that anyone who expresses an opinion
| that is contrary to your worldview is attacking you.
I have never had that idea, Erann, and you know it, too. But what I said
did predict _exactly_ what you started your article with: an attack based
on your misguided assumption that I or anyone else attack people who are
constructive, so why are you doing that if I am wrong? When you behave
exactly as I have predicted _and_ told you, one must wonder what is wrong
with you who cannot see it and at least control your behavior long enough
to _appear_ to be of a sound mind. You are in _fact_ attacking me, Erann
Gat. Can you get this through your deluded mind, please? You are not
"expressing an opinion contrary to my worldview" when you are telling
insane lies about me to support your own need for your demonization to be
true, you are quite simply attacking me. No excuses like difference of
opinion can hide this fact, Erann. Please mature a bit and understand
this, will you?
| Despite the fact the people occasionally get fed up with you and vent
| their frustrations on this newsgroup, the world is not nearly as obsessed
| with you as you like to imagine that it is.
Where do you _get_ all this insanity, Erann? I thought you had talked to
people and gotten over your problems, already. Apparently not. Chill!
And, despite your delusions of grandeur, Erann, _your_ obvious obsession
with me does not make you "the world". A few people, such as yourself,
have nothing better to do than attack me, and this is actually the very
definition of obsession. It is all you do around here, these days, since
you no longer actually use Common Lisp for anything. I guess that, too,
is my fault, so now you need to take it out on me, again, or you would
simply have been able to remain a theory C person and be polite _and_
constructive at the same time. But no, let's just _chuck_ theory C and
attack me, again. That is Erann Gat for you.
| The last time we exchanged messages you said you were giving up on me.
| If you could be right about anything, please make it that.
Geez, you really are nuts. You need serious amounts of counseling,
Erann. This is not the place to help you get over your problems.
I thought you wanted to make the impression that you were a theory C guy.
Should you not be both polite and constructive, then Why are you such an
insane little fuck who writes so much idiotic drivel about me when you
think this is _wrong_ of you to do? Do I control your behavior, too?
Are you, too, blaming me for your coping problems, Erann? Please see a
therapist, Erann. You obviously have some _serious_ issues to work out.
///
--
On Tue, 08 Jan 2002 10:19:33 GMT, Erik Naggum <····@naggum.net> wrote:
> It would appear that you are _frightened_ of me. This is
> simply not healthy.
Have you considered the alternative ?
That we consider your immoderate outbursts wildly funny ?
> Are you, too, blaming me for your coping problems, Erann? Please see a
> therapist, Erann. You obviously have some _serious_ issues to work out.
Physician, heal thyself.
* Jean-Fran�ois Brouillet <·····@mac.com>
| Whatever anyone disagreeing with you say, you will send the argument
| back, screaming loudly a "Not all, it's you" (only in a far less polite
| way)
[ Rant omitted. ]
| Get over it, and stop the rants.
Do you _really_ wonder why you get your "argument" back in your face?
Whatever happened to your "politeness and courtesy are not an option"?
When _are_ you going to start practicing what you preach?
I was just watching live coverage of the Milosevic trial on CNN. The
_very_ patient judge, Richard May, has the unwelcome task of telling this
idiot that it is irrelevant what he thinks about the international war
crimes tribunal. "Mr. Milosevic, this is not the time to make speeches."
I did not know that Mr. Milosevic was an active USENET contributor.
///
--
Erik Naggum <····@naggum.net> writes:
> I was just watching live coverage of the Milosevic trial on CNN. The
> _very_ patient judge, Richard May, has the unwelcome task of telling this
> idiot that it is irrelevant what he thinks about the international war
> crimes tribunal. "Mr. Milosevic, this is not the time to make speeches."
> I did not know that Mr. Milosevic was an active USENET contributor.
The judge also has a "kill" button. Audio only (so far).
Erik Naggum <····@naggum.net> writes:
...
> to theory B, is highly offensive. It explains _why_ you need polite form
> so much and do not understand that the worst personal attacks are given
> in the most polite form.
I'm used to people being impolite on usenet.
I just think it would be nice if comp.lang.lisp.moderated existed,
because it would be an easier place to find lisp-related issues.
--
--Ed Cashin integrit file-verification system:
·······@terry.uga.edu http://integrit.sourceforge.net/
Note: If you want me to send you email, don't munge your address.
"Kent M Pitman" <······@world.std.com> wrote in message
····················@shell01.TheWorld.com...
> There seem to be two competing, utterly incompatible theories of what it is
> to make "constrcutive commentary" in the world...
>
> Theory A. Anything that is said in a pleasant tone and is absent
> a certain "bad list" of words is regarded as constructive. Anything
> said in an angry tone or involving a certain "bad list" of words
> is regarded as unconstructive.
>
> Theory B. Anything that plainly identifies the difference between an
> initial state and a goal state, and that identifies operators for
> getting usefully from the initial to goal state is regarded as
> constructive, regardless of its presentation. Anything, however
> politely worded, that offers the reader no sense of how to move from
> an initial state to a goal state, is not constructive.
>
I don't think you've fairly described either camp (of course, dividing any
spectrum of opinions into two parts is by its nature unfair to all individual
opinions)
I would say Theory A considers tone and language important and Theory B
considers it irrelevant. Neither really comment on content (ie it is
orthogonal to A people's and B people's disagreement). (other issues come up,
eg the further disagreement on the appropriateness of even discussing
presentation, but I think they spring from this initial disagreement.)
Your Theory B won't really help identify constructive and non-constructive
posts, it simply shifts the grey area into what constitutes an "operator for
getting usefully from the initial to goal state" ie. Is "grow a fucking
clue, you moron" such an operator? I don't believe the answer is objective or
clear. Whereas it clearly involves insult and obscenity. But if one refuses
to consider tone and language relevant, this judgment criterion could be
dismissed as looking for a lost object where the light is good rather than
where it was dropped (ie beside the point!)
> I am a Theory B person.
Your own writings definitely fall into Erann Gat's Theory C category. (This
also means they satisfy your A *and* B)
> As nearly as I can tell, all .moderated lists are about separating things
> by theory A.
>
> Pity.
I have no personal experience with moderated groups though if you are correct,
I agree, that is a pity.
I am not eager to have a moderated c.l.l. I do also believe in freedom. It
is just unfortunate that people do not accept the responsibility that is a part
of it. Such is life.
--
Coby
(remove #\space "coby . beck @ opentechgroup . com")
* "Coby Beck" <·····@mercury.bc.ca>
| Your Theory B won't really help identify constructive and non-constructive
| posts, it simply shifts the grey area into what constitutes an "operator for
| getting usefully from the initial to goal state" ie. Is "grow a fucking
| clue, you moron" such an operator?
What is it in response to? Would such a response result in response to
an already posted article according to theory B? I think not. However,
a _polite_ message with destructive or anti-social contents _would_
receive such a response, so theory A produces flames from non-flames,
because it allows destructive morons to get through, while theory B does
not produce flames from non-flames, because the non-constructive would be
kept out to begin with.
///
--
"Erik Naggum" <····@naggum.net> wrote in message
·····················@naggum.net...
> * "Coby Beck" <·····@mercury.bc.ca>
> | Your Theory B won't really help identify constructive and non-constructive
> | posts, it simply shifts the grey area into what constitutes an "operator
for
> | getting usefully from the initial to goal state" ie. Is "grow a fucking
> | clue, you moron" such an operator?
>
> What is it in response to? Would such a response result in response to
> an already posted article according to theory B? I think not. However,
> a _polite_ message with destructive or anti-social contents _would_
> receive such a response, so theory A produces flames from non-flames,
> because it allows destructive morons to get through, while theory B does
> not produce flames from non-flames, because the non-constructive would be
> kept out to begin with.
>
Firstly, I rejected both Theory A and Theory B division as presented by Kent
for, among other reasons, the scenario you are describing. It is quite
possible (and often much more destructive) to be polite and still deliver
insults and passive agression or to be polite and completely devoid of content
or way off topic (or be a polite clueless moron).
Conversation between people can be very subtle and open to many
interpretations. This is one reason I don't advocate for a moderator here and
if there were one I would want the criteria for rejection to be very narrow and
as objective as possible. Who started it is usually a grey area, but once the
line is crossed, wherever it was, things are generally much clearer. That's
when discussions are pointless. Anyway...why is it important who started it?
Why is it more important to make a "clueless moron" see things differently than
it is to show a little maturity?
(yes, that was a "when did you stop beating your wife" question, feel free to
lambast it)
--
Coby
(remove #\space "coby . beck @ opentechgroup . com")
PS As much as a hate the way you treat those people you have decide are
sub-human, I would love to see you have at a particular troll I have come
across in another group recently...do you ever visit rec.music.classical? ;-)
* "Coby Beck" <·····@mercury.bc.ca>
| It is quite possible (and often much more destructive) to be polite and
| still deliver insults and passive agression or to be polite and
| completely devoid of content or way off topic (or be a polite clueless
| moron).
We are in violent agreement here. A requirement to be polite turns bad
people into _much_ worse people than they were if they were allowed to
let the steam out naturally.
///
--
"Coby Beck" <·····@mercury.bc.ca> writes:
> Your Theory B won't really help identify constructive and non-constructive
> posts, it simply shifts the grey area into what constitutes an "operator for
> getting usefully from the initial to goal state" ie. Is "grow a fucking
> clue, you moron" such an operator? I don't believe the answer is objective
> or clear.
Sure it is: It's an annoyed way of saying that you don't yet know what you
don't know [go do your homework].
In article <·················@terry.uga.edu>,
Ed L Cashin <·······@terry.uga.edu> wrote:
>but who would moderate
>comp.lang.lisp.moderated?
I am a reluctant hero, but I admit that I am probably
the best choice for moderator for comp.lang.lisp.
Alas, my various other responsibilities require
me to nobly walk away from the limelight.
--d
The whole moderation thing... Moderation worked very well in
comp.lang.perl.moderated; i think they have software that does the
bulk of the work.
However, i don't think the volume in comp.lang.lisp is so much that it
would require moderation. If you don't want to read the flamewars,
just skip them. If you want to participate, be my guest --- but know
that i won't be reading the flames you post. :-)
g
"Rajappa Iyer" <···@panix.com> wrote in message
····················@panix1.panix.com...
> Actually, I'm perennially amazed at the blind eyes and deaf ears that
> many c.l.l. regulars display when it comes to Erik's rants
I do find Erik's style disgraceful to the extreme. But what would you have
anyone do about it? He is free to post as he choses. Do you really think
people cannot judge very well for themselves how to feel about what he writes?
Give people more credit.
I wish he would shut his foul mouth and only post his technical insights. But
that's not the nature of usenet. I have participated in plenty of
naggum-bashing threads but ultimately it does nothing but add to the pollution.
You're free to post your objections, as am I (and I do from time to time) but
that is all that is in your power. Don't keep the flames going and don't
expect some virtual uprising that will somehow silence him for ever.
I have decided to only say anything when it seems likely his latest target
doesn't have the maturity or strength of character to take it in stride and to
make sure people realize he does not speak for everyone here (though this
should be obvious, for sociological reasons it needs to be said occasionally)
> . While it
> is their privilege to ignore the unsavory portion of Erik's
> net.persona, I wonder why a similar indifference is not extended to
> people complaining about the same. After all, if Erik's rants don't
> bother you or do not warrant a response, neither do the complaints
> about the same. What's sauce for the goose...
>
I have not seen too many people complaining about Jean-Francois and he is quite
out of line. Plus he called me a "poor little shitty thing" and a naggum clone
just for objecting to what he was doing. This is hardly behaviour worth
defending....what was that line about sauce and water fowl again....
--
Coby
(remove #\space "coby . beck @ opentechgroup . com")
On 5/1/02 6:12, "Coby Beck" <·····@mercury.bc.ca> wrote:
> I have not seen too many people complaining about Jean-Francois and
> he is quite out of line. Plus he called me a "poor little shitty thing"
> and a naggum clone just for objecting to what he was doing. This is
> hardly behaviour worth defending....what was that line about sauce
> and water fowl again....
I apologize publicly about this. I got carried away by the tone of some
other private emails I received. Plus, what Coby wrote didn't bear any
context, so I had to make one up, and I chose the wrong one.
My apologies again, and thanks for having been more clever than me, and
not having escalated the whole thing into a whole email vendetta.
--
Jean-Fran�ois Brouillet
"Jean-Fran�ois Brouillet" <·····@mac.com> wrote in message
························@mac.com...
> On 5/1/02 6:12, "Coby Beck" <·····@mercury.bc.ca> wrote:
>
> > I have not seen too many people complaining about Jean-Francois and
> > he is quite out of line. Plus he called me a "poor little shitty thing"
> > and a naggum clone just for objecting to what he was doing. This is
> > hardly behaviour worth defending....what was that line about sauce
> > and water fowl again....
>
> I apologize publicly about this. I got carried away by the tone of some
> other private emails I received.
Accepted. No grudges held :-)
--
Coby
(remove #\space "coby . beck @ opentechgroup . com")
> Actually, I'm perennially amazed at the blind eyes and deaf ears that
> many c.l.l. regulars display when it comes to Erik's rants. While it
> is their privilege to ignore the unsavory portion of Erik's
> net.persona, I wonder why a similar indifference is not extended to
> people complaining about the same. After all, if Erik's rants don't
> bother you or do not warrant a response, neither do the complaints
> about the same. What's sauce for the goose...
I think, this is not surprising. I have seen Erik fighting some people who
had no genuine understanding of Lisp like me but he also fought some very
clever guys, like Erann Gat, John Foderaro, Bruno Haible who are experts.
I have observed that Erik is sometimes supported against the first group but
not against the second (i.e. nobody will tell Erann Gat, "Go away"). The
people who support him do not care for moral and social manners but want to
have technical advice and the end justifies the means. I do not think it is
necessary to qualify this attitude. It is wonderful that you can take really
deep looks in the characcter of some people.
J.B.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
Check out our new Unlimited Server. No Download or Time Limits!
-----== Over 80,000 Newsgroups - 19 Different Servers! ==-----
"Janos Blazi" <······@hotmail.com> writes:
> I think, this is not surprising. I have seen Erik fighting some people who
> had no genuine understanding of Lisp like me but he also fought some very
> clever guys, like Erann Gat, John Foderaro, Bruno Haible who are experts.
> I have observed that Erik is sometimes supported against the first group but
> not against the second (i.e. nobody will tell Erann Gat, "Go away").
That's right. Especially on Usenet, people are everything from polite
and patient, to short-fused, to flaming jackasses, and everything in
between and off that spectrum. The point of the comp.* groups is, in
fact, technical discussion. If people contribute to the community of
the group, they're generally tolerated; if people contribute to a high
level of technical discussion, the same is true. Those filled with
venom who do none of the above, are generally not viewed in a very
pleasant light. This should come as no surprise.
> The people who support him do not care for moral and social manners
> but want to have technical advice and the end justifies the means.
This statement can only come from a lack of understanding what Usenet,
and comp.* newsgroups in particular are about. Certain places are
defined primarily by their mission, and this is no exception. This
ain't a local community bbs.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
> This statement can only come from a lack of understanding what Usenet,
> and comp.* newsgroups in particular are about. Certain places are
> defined primarily by their mission, and this is no exception. This
> ain't a local community bbs.
I think we are saying the same thing here. You are saying "this is all right
as we are on Usenet" and this is exactly what I meant. This is the attitude
I utterly disdain (is this the right word here?). In my opinion the same
rules, the same moral principles must apply everywhere.
J.B.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
Check out our new Unlimited Server. No Download or Time Limits!
-----== Over 80,000 Newsgroups - 19 Different Servers! ==-----
* "Janos Blazi" <······@hotmail.com>
| It is wonderful that you can take really deep looks in the characcter of
| some people.
Yes, it is surprising how much you can only learn about people after you
poke their eyes in, stab them the back, rape their children, kill their
cat, burn down their homes, etc. You could almost mistake people for
normal until you take a _deep_ look into their character this way.
It is much easier with the very shallow: They are exactly the same all
the way down, and they _really_ believe everyone else is, too, and that
you actully learn something useful about other people by teasing them.
There are few so shallow people. Most of them cannot even _understand_
what it means to feel passionately about anything, least of all flakey
stuff like freedom, rule of law, standards, trust, or, indeed, agreement,
which they think is the same as truce.
///
--
> Yes, it is surprising how much you can only learn about people after you
> poke their eyes in, stab them the back, rape their children, kill their
> cat, burn down their homes, etc. You could almost mistake people for
> normal until you take a _deep_ look into their character this way.
>
> It is much easier with the very shallow: They are exactly the same all
> the way down, and they _really_ believe everyone else is, too, and that
> you actully learn something useful about other people by teasing them.
> There are few so shallow people. Most of them cannot even _understand_
> what it means to feel passionately about anything, least of all flakey
> stuff like freedom, rule of law, standards, trust, or, indeed,
agreement,
> which they think is the same as truce.
I admit to being guilty of teasing you. But I do not know if I understand
you correctly. Do you really feel such a pain when being teased or attacked?
I am really not a very passionate person, Erik so it is not easy for me to
understand this.
(In my last posting you are responding to you were not meant at all. I meant
your alleged cronies. Of course in my opinion your postings are often not in
order but there are mitigating circumstances (this is how I see things). But
there are no mitigating circumstances for that "the end justifies the means"
attitude I was talking about. You could make feel me pain once (with that
grandparents-posting of yours) but that has passed.)
J.B.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
Check out our new Unlimited Server. No Download or Time Limits!
-----== Over 80,000 Newsgroups - 19 Different Servers! ==-----
In article <···········@news.newsgroups.com>, Janos Blazi wrote:
>> Actually, I'm perennially amazed at the blind eyes and deaf ears that
>> many c.l.l. regulars display when it comes to Erik's rants. While it
>> is their privilege to ignore the unsavory portion of Erik's
>> net.persona, I wonder why a similar indifference is not extended to
>> people complaining about the same. After all, if Erik's rants don't
>> bother you or do not warrant a response, neither do the complaints
>> about the same. What's sauce for the goose...
>
> I think, this is not surprising. I have seen Erik fighting some people who
> had no genuine understanding of Lisp like me but he also fought some very
> clever guys, like Erann Gat, John Foderaro, Bruno Haible who are experts.
> I have observed that Erik is sometimes supported against the first group but
> not against the second (i.e. nobody will tell Erann Gat, "Go away"). The
> people who support him do not care for moral and social manners but want to
> have technical advice and the end justifies the means. I do not think it is
> necessary to qualify this attitude. It is wonderful that you can take really
> deep looks in the characcter of some people.
>
> J.B.
>
Well I have told John Foderaro to go away and several other things.
And I am in no way shape or form an expert on CL. If you want to read
what John and I said to each other read cll for the last week of
Aug and the first week of sept 2001. I have also gotten both barrels
from Erik in the past. The thing is when read Erik's reply and found
out that I had not done my home work, I apologized that was the end
of it. I have not had any problems with him or him with me since.
All in all I wish there were more "Eriks" in this and the other
groups that I read. And that John F. has demonstrated that he behaves
as a coward and a thug.
marc
>
>
>
> -----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
> http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
> Check out our new Unlimited Server. No Download or Time Limits!
> -----== Over 80,000 Newsgroups - 19 Different Servers! ==-----
In article <···········@news.newsgroups.com>, "Janos Blazi"
<······@hotmail.com> wrote:
> I think, this is not surprising. I have seen Erik fighting some people who
> had no genuine understanding of Lisp like me but he also fought some very
> clever guys, like Erann Gat, John Foderaro, Bruno Haible who are experts.
> I have observed that Erik is sometimes supported against the first group but
> not against the second (i.e. nobody will tell Erann Gat, "Go away").
Heh! Thanks for the compliment, Janos, although I don't really consider
myself an expert as measured against John and Bruno. I'm just a humble
(l)user. (Actually, I'm now an ex-user, not having done any Lisp
programming in over two years.)
E.
On Sat, 05 Jan 2002 22:56:35 -0800, ···@jpl.nasa.gov (Erann Gat) wrote:
>In article <···········@news.newsgroups.com>, "Janos Blazi"
><······@hotmail.com> wrote:
>
>> I think, this is not surprising. I have seen Erik fighting some people who
>> had no genuine understanding of Lisp like me but he also fought some very
>> clever guys, like Erann Gat, John Foderaro, Bruno Haible who are experts.
>> I have observed that Erik is sometimes supported against the first group but
>> not against the second (i.e. nobody will tell Erann Gat, "Go away").
>
>Heh! Thanks for the compliment, Janos, although I don't really consider
>myself an expert as measured against John and Bruno. I'm just a humble
>(l)user. (Actually, I'm now an ex-user, not having done any Lisp
>programming in over two years.)
I think I saw in your webpage that you were working at google. If that's true,
what's taking you and Peter Norvig so long to convert all googlers to The True
Faith? ;-)
--
Fernando Rodr�guez
frr at wanadoo dot es
--
In article <··································@4ax.com>, Fernando
Rodr�guez <·······@must.die> wrote:
> I think I saw in your webpage that you were working at google. If that's true,
> what's taking you and Peter Norvig so long to convert all googlers to The True
> Faith? ;-)
I worked at Google for a year. Now I'm back at JPL. (ObDisclaimer: I do
not speak for the Laboratory.)
Working at Google was a very humbling and educational experience. I used
to think I was a pretty bright guy until I went to work there. One of the
things I learned came as a great shock to me: not all people who choose to
program in languages other than Lisp are idiots.
This came as a hard lesson for me because when I went to Google I was an
Apostle of the True Faith. I've been a Lisp programmer for twenty years.
I started in high school on an Apple II (I recently cleared out a bunch of
old junk from my parents' house and found the original 5-inch floppy disk
with my Lisp on it!) Throughout my career I found I could do things in
Lisp in hours that took my colleagues (who at first were using Pascal,
then C, and now C++ and Java) days and weeks. I particularly remember my
graduate school compilers course, which I was fortunate enough to take
from a very enlightened instructor who allowed us to do our assignments in
any language we chose. I used Lisp (Franz Lisp running on a Vax 11/780),
everyone else used C (K&R in those days) or Pascal (this was in 1986).
Everyone else in the class produced programs whose printouts were many
inches thick. Mine was about twenty pages including comments. I got an
A.
So I got to be pretty smug about Lisp (and my own abilities). With the
advantages of Lisp being so obvious (to me) and so enormous I spent a lot
of time puzzling over why everyone didn't use it. I came to the
conclusion that people who didn't use Lisp did so simply because they
didn't know about how wonderful it was, and so I set off on a ten-year
crusade to enlighten the heathen, with mixed results. The story of that
crusade makes an interesting tale in and of itself but would take us far
afield here. The point is, I went to Google fully intending to convert
them to the True Faith.
Instead, I lost my faith. There were two main reasons for this. First, I
got to see firsthand what a group of smart people working together can
accomplish even when they aren't using Lisp. It's an awesome thing. I
don't believe it would be possible to reproduce Google in Lisp.
Second, I learned that Lisp is not as great as I thought it was.
Certainly twenty years ago, and even ten years ago, there was nothing that
could touch it. But the world has been slowly catching up while Lisp has
been largely stagnant for a decade. The list of features that Lisp offers
that aren't found in other languages has grown shorter and shorter. The
list of useful library functions found in other languages and not in Lisp
has grown longer. It's the old story of the tortoise and the hare. Lisp
has been napping for ten years, and the rest of the world is catching up.
(In some areas it has already caught up, or even passed us.)
As to why Peter hasn't converted Google, well, you'd have to ask him. But
you can get some clues from his Web page.
E.
In article <····················@eglaptop.jpl.nasa.gov>, ···@jpl.nasa.gov
(Erann Gat) wrote:
>Instead, I lost my faith. There were two main reasons for this.
"I find your lack of faith disturbing."
(see http://www.trilogysounds.f2s.com/html/vader.html for this and
other strangely relevant sound bites ;-)
>First, I
>got to see firsthand what a group of smart people working together can
>accomplish even when they aren't using Lisp. It's an awesome thing.
I envy you for your experiences. It would be great if you could
separate for us what you learned about JPL versus Google as organizations
and what you learned about Lisp versus non-Lisp languages. (I think
most would agree that smart people can do wonderful things with just
about any tool -- witness the A team.)
>Second, I learned that Lisp is not as great as I thought it was.
>Certainly twenty years ago, and even ten years ago, there was nothing that
>could touch it. But the world has been slowly catching up while Lisp has
>been largely stagnant for a decade. The list of features that Lisp offers
>that aren't found in other languages has grown shorter and shorter. The
>list of useful library functions found in other languages and not in Lisp
>has grown longer. It's the old story of the tortoise and the hare. Lisp
>has been napping for ten years, and the rest of the world is catching up.
>(In some areas it has already caught up, or even passed us.)
Other languages seem to be zooming past Common Lisp as far as
the standard libraries they offer; this appears to be what you're
getting at. But what about the unique features of Lisp -- the
interactive style of program development, pervasive and effortless
use of macros, etc.? Did you find these capabilities duplicated
in the languages you used at Google, or did you accept trading
them for special features of these languages unavailable in Lisp?
In article <······························@129.59.212.53>,
·············@vanderbilt.edu (Sashank Varma) wrote:
> I envy you for your experiences. It would be great if you could
> separate for us what you learned about JPL versus Google as organizations
> and what you learned about Lisp versus non-Lisp languages.
I actually wrote up my JPL experiences a while back in response to another
thread, but it turned out to be many pages long and I decided it was too
wordy for usenet. I'll see about getting it into a publishable state and
putting it on the Web. (Since I'm now working at JPL I have to be a
little careful about what I say.)
> (I think
> most would agree that smart people can do wonderful things with just
> about any tool -- witness the A team.)
Well, I'd be a little hesitant to cite a television show (particularly the
A team) as support for my position, but that's essentially correct. It's
not the tools, it's the teamwork. The example that came to my mind was
the Egyptian pyramids (or, if you prefer, contemporary re-creations of
pyramid building techniques).
> Other languages seem to be zooming past Common Lisp as far as
> the standard libraries they offer; this appears to be what you're
> getting at. But what about the unique features of Lisp -- the
> interactive style of program development, pervasive and effortless
> use of macros, etc.? Did you find these capabilities duplicated
> in the languages you used at Google, or did you accept trading
> them for special features of these languages unavailable in Lisp?
A little of both. Back in the Good Old Days (late 80's, early 90's) Lisp
had a whole slew of features that no other languages available then had:
automatic memory management, an extensive library (back then people used
to criticise CL for being too big and bloated), incremental
compilation/interactive development, and macros. Today the only feature
that remains unique to Lisp is macros. Macros are certainly useful, but
they are not by themselves an advantage that dominates all other
considerations.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> In article <······························@129.59.212.53>,
> ·············@vanderbilt.edu (Sashank Varma) wrote:
>
[...]
>> Other languages seem to be zooming past Common Lisp as far as
>> the standard libraries they offer; this appears to be what you're
>> getting at. But what about the unique features of Lisp -- the
>> interactive style of program development, pervasive and effortless
>> use of macros, etc.? Did you find these capabilities duplicated
>> in the languages you used at Google, or did you accept trading
>> them for special features of these languages unavailable in Lisp?
>
> A little of both. Back in the Good Old Days (late 80's, early 90's) Lisp
> had a whole slew of features that no other languages available then had:
> automatic memory management, an extensive library (back then people used
> to criticise CL for being too big and bloated), incremental
> compilation/interactive development, and macros. Today the only feature
> that remains unique to Lisp is macros. Macros are certainly useful, but
> they are not by themselves an advantage that dominates all other
> considerations.
>
Don't forget metaprogramming. AFAICT, metaprogramming is *much* easier
in most Lisps than in other languages (in fact, I'm not convinced that
it's at all feasible to do metaprogramming in most other languages).
> E.
--
BPT <···@tunes.org> /"\ ASCII Ribbon Campaign
backronym for Linux: \ / No HTML or RTF in mail
Linux Is Not Unix X No MS-Word in mail
Meme plague ;) ---------> / \ Respect Open Standards
Brian P Templeton <···@tunes.org> wrote in message news:<··············@tunes.org>...
> Don't forget metaprogramming. AFAICT, metaprogramming is *much* easier
> in most Lisps than in other languages (in fact, I'm not convinced that
> it's at all feasible to do metaprogramming in most other languages).
In Lisp you can also do meta-unprogramming, with Meta-Ctrl-K.
In article <··············@tunes.org>, Brian P Templeton <···@tunes.org> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
> > Today the only feature
> > that remains unique to Lisp is macros. Macros are certainly useful, but
> > they are not by themselves an advantage that dominates all other
> > considerations.
> >
> Don't forget metaprogramming. AFAICT, metaprogramming is *much* easier
> in most Lisps than in other languages (in fact, I'm not convinced that
> it's at all feasible to do metaprogramming in most other languages).
Metaprogramming is easier in Lisp *because* of macros. In fact, I'd say
that metaprogramming is not a feature of the language, but an application
(perhaps the only application) of macros. As for metaprogramming being
infeasible in other languages, I'd agree that's the case today. But that
situation is only one bright idea away from changing.
E.
Erann Gat wrote:
> Metaprogramming is easier in Lisp *because* of macros. In fact, I'd say
> that metaprogramming is not a feature of the language, but an application
> (perhaps the only application) of macros. As for metaprogramming being
> infeasible in other languages, I'd agree that's the case today. But that
> situation is only one bright idea away from changing.
And how many years have we been waiting for this "bright idea"? Maybe
that's because this bright idea actually IS the one that code has an easily
representable form as data? And that, in order to be easily usable (thus
useFUL), this form must be extremely simple and manipuable? Seems to me
that once we've acknowledged that, we cut out a lot of formerly proposed
"bright ideas".
faa
In article <····················@eglaptop.jpl.nasa.gov>, Erann Gat wrote:
>(perhaps the only application) of macros. As for metaprogramming being
>infeasible in other languages, I'd agree that's the case today. But that
>situation is only one bright idea away from changing.
Erann, if these language designers are so smart, why don't they just
skip ahead to the end and put all the features in? They don't even have
to come up with the bright ideas; that is already done for them. They just
have to work it into a design and there it is! So why don't they?
The answer is likely to be one of these reasons:
- The designer is too incompetent to conduct basic research to find out
what has been done before. In that case, the designer is unlikely to be
competent enough to reinvent those ideas, and almost certainly won't
conceive of them in their present, refined form.
- The designer knows what has been done before, but has some vested
interest in creating a gadget-loaded attraction for hordes of naive
programmers: if the attraction succeeds, the designer will be a renowned
guru, who will be able to just go around the world giving talks.
And possibly make money from becoming a tools vendor, or selling the
brand, and the like.
- The designer knows what has been done before, but rejects some ideas
because they are hard to implement, or other pragmatic reasons. The
designer wants a hacked down language with specific features for his or her
own specific use, perhaps non-interactive programming of small embedded
systems, etc. The language accidentally escapes and becomes popular.
Designers who ignore prior research will forever remain just outside
of the reach of existing ideas. They will not pass their knowledge down
to the next generation of like-minded designers, who will in turn ignore
the research of their predecessors and so on.
One thing you should not overlook is that while languages do acquire
some things that *look* like Lisp features, when you really have a
close look, you find that these features are often pale imitations.
That last nine yards between the pale imitation and the Real Thing can
make all the difference in the world!
Another thing to be considered: is there any *single* language that
appears to be acquiring the features of Lisp? That, say, one language
gets closures, another one gets restartable conditions and a third one
gets special variables doesn't mean anything. You need these to be in
*one* language.
Now, so what if something surpasses Lisp? If it has decent
implementations, and has the same low impedance to programming, I will
just use it rather than sit around unproductively lamenting the passing
of Lisp. To surpass Lisp, it will have to have all the characteristics.
There is a design reason why many things are the way they are in Lisp,
and duplicating the success requires duplicating the design. At least at
some conceptual level, not necessarily in the details. Common Lisp is
not the only possible good language. Anything isomorphic to it at some
meaningful level is equally good. (But of course, one important benefit
is standardization; something good and standard is better than something
that is merely good).
Lastly, any programming language you use today is becoming obsolete.
It will either wane away, or will be replaced by another language based
on it which bears the same name. One must be prepared to adjust to either
event.
···@accton.shaw.ca (Kaz Kylheku) writes:
> Another thing to be considered: is there any *single* language that
> appears to be acquiring the features of Lisp?
OCaml and Erlang have most of the good features of Lisp, including macros
(with camlp4 and parse_transform), and they also have good features that
Lisp never had: rich static strong typing and a higher-order module system
for OCaml, support for building robust massively concurrent systems for
Erlang.
[ Fran�ois-Ren� �VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
[ TUNES project for a Free Reflective Computing System | http://tunes.org ]
There's no worse blasphemy than to claim to know what pleases or displeases
God. Hence prophets and priests are the most impious men on earth.
Francois-Rene Rideau <···········@tunes.org> writes:
> they also have good features that Lisp never had:
[...]
> support for building robust massively concurrent systems for Erlang.
I certainly never had any experience with Lisp*, but I'd be surprised
if it failed here
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@apocalypse.OCF.Berkeley.EDU (Thomas F. Burdick) writes on comp.lang.lisp:
> Francois-Rene Rideau <···········@tunes.org> writes:
>
>> they also have good features that Lisp never had: [...]
>> support for building robust massively concurrent systems for Erlang.
>
> I certainly never had any experience with Lisp*, but I'd be surprised
> if it failed here
Maybe you mean *LISP, the language for the Connection Machine;
but AFAIK, it wasn't exactly a LISP,
just a language metaprogrammed from LISP.
So it was used to build massively concurrent systems,
but was very idiosyncratic with the CM, kind of SIMD,
and didn't survive to the demise of Thinking Machines.
I don't think it was designed for robustness, either.
Other LISPs with concurrency (threads) are kind of nice,
but not really built for massively concurrent systems:
the global garbage-collected shared-memory model of LISP
strongly limits the scalability such systems, and
their robustness when faced with fault-containment problems.
Also, no concurrent LISP extension correctly handles
problems of synchronization of interrupted threads with
application-defined invariants - see for instance the problems
that Joe Marshall had with interrupted transactions.
(LISP here is not worse than Java,
but JOCaml and Erlang can do much better).
Of course, it is possible to build distributed systems
atop of LISP (just like you can atop any language), but
then (just like you would have in any such setting), it means
that you have a fight a multi-level programming system
that imposes arbitrary constraints on your programming style
and forces you to make arbitrary early low-level implementation
choice as to which problem will be treated at which level.
LISP's metaprogramming abilities can help you factor a lot,
so you will be better with LISP than with anything else,
but if you take this approach seriously, you will but end up
reimplementing Erlang or JOCaml in LISP, and the idiosynchrasies
of LISP systems (designed around a global namespace) will end up
getting in the way, whether you try to emulate them (expensive
runtime distributed coherence enforcement) or avoid them
(difficult to trace inconsistent behaviour when they are mistakenly used).
Erlang, on the other hand, is a generic tool for building robustp
concurrent systems. It does not depend on the idiosynchrasies of
any particular hardware architecture. Its model of internally pure
communicating processes easily scales to building large distributed systems,
while allowing for real-time behaviour (soft-real-time in practice;
but nothing in theory prevents a hard-real-time implementation if needed).
and provides a framework for fault-containment as well
as for asynchronous interruption handling, and more.
It is actually used in mission-critical telecom switch systems,
in services using internet-standard protocols, etc.
I don't mean that it would be impossible to design a LISP so as to be
as good for concurrent programming as Erlang is. But it would require
deep changes to the language and its implementations, and the end-result
wouldn't quite be like Common Lisp. For instance, instead of global
namespaces and am implicit global object heap, it might have something
like first-class name-spaces and first-class object-spaces;
the behaviour of primitives of the language in face of concurrency
would have to be clarified -- maybe by introducing a linear type system.
Yours freely,
[ Fran�ois-Ren� �VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
[ TUNES project for a Free Reflective Computing System | http://tunes.org ]
How would the certainty of the near end of the world affect Ethics?
Francois-Rene Rideau <···········@tunes.org> wrote in message news:<·················@Samaris.tunes.org>...
>
> Maybe you mean *LISP, the language for the Connection Machine;
> but AFAIK, it wasn't exactly a LISP,
> just a language metaprogrammed from LISP.
> So it was used to build massively concurrent systems,
> but was very idiosyncratic with the CM, kind of SIMD,
> and didn't survive to the demise of Thinking Machines.
> I don't think it was designed for robustness, either.
I think it was a Lisp, but I think you're also correct in that it
wasn't really to do with concurrent systems in the way erlang is. It
has all sorts of stuff to support the kind of SIMD stuff that the
early connection machines had, and I'm not even sure if it lasted
until the later CMs, which I think were much less pure SIMD machines
(if they were SIMD at all, I think they were likely actually MIMD by
the end, wasn't the CM5 made of SPARCs?).
You used to be able to get a *Lisp simulator - whether that still
exists I have no idea.
I think the xapping stuff in CLtL2 is about *Lisp.
--tim
From: Erik Winkels
Subject: Re: LISP for Concurrent Systems
Date:
Message-ID: <873d169yn2.fsf@xs4all.nl>
Hi,
··········@tfeb.org (Tim Bradshaw) writes:
>
> You used to be able to get a *Lisp simulator - whether that still
> exists I have no idea.
There was a similar question a few months ago:
http://groups.google.com/groups?hl=en&frame=right&th=899cb9287d64396d&seekm=877ku4fspf.fsf%40xs4all.nl#link8
Erik.
In article <····························@posting.google.com>,
Tim Bradshaw <··········@tfeb.org> wrote:
>Francois-Rene Rideau <···········@tunes.org> wrote in message
>news:<·················@Samaris.tunes.org>...
>>
>> Maybe you mean *LISP, the language for the Connection Machine;
>> but AFAIK, it wasn't exactly a LISP,
>> just a language metaprogrammed from LISP.
>> So it was used to build massively concurrent systems,
>> but was very idiosyncratic with the CM, kind of SIMD,
>> and didn't survive to the demise of Thinking Machines.
>> I don't think it was designed for robustness, either.
>
>I think it was a Lisp, but I think you're also correct in that it
>wasn't really to do with concurrent systems in the way erlang is. It
>has all sorts of stuff to support the kind of SIMD stuff that the
>early connection machines had, and I'm not even sure if it lasted
>until the later CMs, which I think were much less pure SIMD machines
>(if they were SIMD at all, I think they were likely actually MIMD by
>the end, wasn't the CM5 made of SPARCs?).
Yes, but it was still programmed as a SIMD array, so *Lisp, C*, and CM
Fortran were used in pretty much the same way that they were used on the
earlier CM's that used custom processors. The main MIMD thing you could do
with the CM-5 was partition it into multiple groups of processors, which
each acted as an independent SIMD computer.
>I think the xapping stuff in CLtL2 is about *Lisp.
No, that's CM-Lisp, a more advanced paradigm. It was a great idea, but
never fully implemented, because it required much more smarts in the
implementation. *Lisp required you to use special macros to bind parallel
variables (e.g. LET*), and these would do a code walk to rewrite all the
references to the variable into commands to the CM; CM-Lisp used the
xapping data type, and expected that ordinary functions like + and * would
be generic and parallelized automatically when they received these arguments.
--
Barry Margolin, ······@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Francois-Rene Rideau <···········@tunes.org> writes:
> ···@accton.shaw.ca (Kaz Kylheku) writes:
> > Another thing to be considered: is there any *single* language that
> > appears to be acquiring the features of Lisp?
>
> OCaml and Erlang have most of the good features of Lisp, including
> macros (with camlp4 and parse_transform), and they also have good
> features that Lisp never had: rich static strong typing
Common Lisp has strong dynamic typing, by design, so Lisp has some
good features that OCaml and Erlang never had.
> and a higher-order module system
Common Lisp might not have (never had?) a module system, but it has
packages, which are first-class objects.
> for OCaml, support for building robust massively concurrent systems for
> Erlang.
Common Lisp has support for building robust massive systems (not
limited to concurrent systems).
And -- did you want to reinforce the above statement of Kaz Kylheku?
--
Janis Dzerins
Eat shit -- billions of flies can't be wrong.
Janis Dzerins <·····@latnet.lv> writes:
> Francois-Rene Rideau <···········@tunes.org> writes:
>
> > ···@accton.shaw.ca (Kaz Kylheku) writes:
> > > Another thing to be considered: is there any *single* language that
> > > appears to be acquiring the features of Lisp?
> >
> > OCaml and Erlang have most of the good features of Lisp, including
> > macros (with camlp4 and parse_transform), and they also have good
> > features that Lisp never had: rich static strong typing
>
> Common Lisp has strong dynamic typing, by design, so Lisp has some
> good features that OCaml and Erlang never had.
Actually, Erlang is dynamically typed too. I'm not sure from where
Francois-Rene got "static strong typing". And Erlang macros are
basically C macros, not Common Lisp macros (alas :-).
Best,
Thomas
--
ftl Thomas Lindgren
@acm.org
I'd rather write programs that write programs than write programs-[R. Sites]
Thomas Lindgren <···@***.***> writes:
> Actually, Erlang is dynamically typed too. I'm not sure from where
> Francois-Rene got "static strong typing".
If you read my message instead of the reply, you'll see that I clearly
state that OCaml has static strong typing, while Erlang allows to build
robust massively concurrent systems.
> And Erlang macros are basically C macros, not Common Lisp macros (alas :-).
Indeed they are. But Erlang parse_transform feature is more like CL macros.
> ftl Thomas Lindgren
> @acm.org
> I'd rather write programs that write programs than write programs-[R. Sites]
Nice.
[ Fran�ois-Ren� �VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
[ TUNES project for a Free Reflective Computing System | http://tunes.org ]
Reisner's Rule of Conceptual Inertia:
If you think big enough, you'll never have to do it.
Janis Dzerins <·····@latnet.lv> writes:
> Francois-Rene Rideau <···········@tunes.org> writes:
>
> > ···@accton.shaw.ca (Kaz Kylheku) writes:
> > > Another thing to be considered: is there any *single* language that
> > > appears to be acquiring the features of Lisp?
> >
> > OCaml and Erlang have most of the good features of Lisp, including
> > macros (with camlp4 and parse_transform), and they also have good
> > features that Lisp never had: rich static strong typing
>
> Common Lisp has strong dynamic typing, by design, so Lisp has some
> good features that OCaml and Erlang never had.
Bad form of me to comment this twice, but I happened to see that
Francois-Rene _didn't_ claim Erlang had static typing. So I shouldn't
ascribe that view to him. Sorry about the confusion.
Best,
Thomas
--
ftl Thomas Lindgren
@acm.org
I'd rather write programs that write programs than write programs-[R. Sites]
On 15 Jan 2002, Janis Dzerins wrote:
> Francois-Rene Rideau <···········@tunes.org> writes:
>
> > ···@accton.shaw.ca (Kaz Kylheku) writes:
> > > Another thing to be considered: is there any *single* language that
> > > appears to be acquiring the features of Lisp?
> >
> > OCaml and Erlang have most of the good features of Lisp, including
> > macros (with camlp4 and parse_transform), and they also have good
> > features that Lisp never had: rich static strong typing
>
> Common Lisp has strong dynamic typing, by design, so Lisp has some
> good features that OCaml and Erlang never had.
[snip]
The "they also have" is collective, not distributive for the example of
rich static strong typing. I.e., in the set of langauges {OCaml, Erlang}
there arise features that Lisp doesn't have: for exmaple, OCaml has rich
strong static typing; erlang has builtin cool concurrancy (niether has
both).
It was a misleading formulation, to be sure. Erlang is dynamically typed
and its designers and main advocates are quite adament about it being a
virtue they prize.
There are some experimental type stuff for Erlang that might be
interesting for Lisp, though Erlang has far fewer langauge features than
Common Lisp (thus may be more tractable). It's still a nice system,
though. Lots of cool libraries.
Erlang evolved out of, and was initially implemented, in Prolog, so shares
some syntax and semantic tropes.
FWIW, I think Erlang is a good model to study for Lisp. While not holding
huge marketshare, no one bashes it. Maybe it doesn't have a high enough
profile, but really, I'm hard pressed to find any big flame bashfests over
it. Even functional language competiters like ML and Haskell, which are in
the Static camp don't hammer Erlang (it being a bit of the industrial
poster child).
Cheers,
Bijan Parsia.
In article
<··········································@login6.isis.unc.edu>, Bijan
Parsia wrote:
>On 15 Jan 2002, Janis Dzerins wrote:
>
>> Francois-Rene Rideau <···········@tunes.org> writes:
>>
>> > ···@accton.shaw.ca (Kaz Kylheku) writes:
>> > > Another thing to be considered: is there any *single* language that
>> > > appears to be acquiring the features of Lisp?
>> >
>> > OCaml and Erlang have most of the good features of Lisp, including
>> > macros (with camlp4 and parse_transform), and they also have good
>> > features that Lisp never had: rich static strong typing
>>
>> Common Lisp has strong dynamic typing, by design, so Lisp has some
>> good features that OCaml and Erlang never had.
>[snip]
>
>The "they also have" is collective, not distributive for the example of
>rich static strong typing. I.e., in the set of langauges {OCaml, Erlang}
>there arise features that Lisp doesn't have: for exmaple, OCaml has rich
>strong static typing; erlang has builtin cool concurrancy (niether has
>both).
Also, ``rich'' simply means that there is a proliferation of something,
with positive connotations. It would be odd to say, for instance
``rich selection of poisons to to do away with oneself'', unless the
intended effect is irony. But a proliferation of something isn't always
beneficial; using a word with positive connotations for that proliferation
doesn't make it so.
Janis Dzerins <·····@latnet.lv> writes:
> Francois-Rene Rideau <···········@tunes.org> writes:
>
>> ···@accton.shaw.ca (Kaz Kylheku) writes:
>> > Another thing to be considered: is there any *single* language that
>> > appears to be acquiring the features of Lisp?
>>
>> OCaml and Erlang have most of the good features of Lisp, including
>> macros (with camlp4 and parse_transform), and they also have good
>> features that Lisp never had: rich static strong typing
>
> Common Lisp has strong dynamic typing, by design, so Lisp has some
> good features that OCaml and Erlang never had.
>
>> and a higher-order module system
>
> Common Lisp might not have (never had?) a module system, but it has
> packages, which are first-class objects.
>
Maybe MAKE:DEFSYSTEM satisfies your definition of module.
>> for OCaml, support for building robust massively concurrent systems for
>> Erlang.
>
> Common Lisp has support for building robust massive systems (not
> limited to concurrent systems).
>
>
> And -- did you want to reinforce the above statement of Kaz Kylheku?
>
> --
> Janis Dzerins
>
> Eat shit -- billions of flies can't be wrong.
--
BPT <···@tunes.org> /"\ ASCII Ribbon Campaign
backronym for Linux: \ / No HTML or RTF in mail
Linux Is Not Unix X No MS-Word in mail
Meme plague ;) ---------> / \ Respect Open Standards
In article <··············@tunes.org>, Brian P Templeton wrote:
>Janis Dzerins <·····@latnet.lv> writes:
>> Francois-Rene Rideau <···········@tunes.org> writes:
>>> and a higher-order module system
>>
>> Common Lisp might not have (never had?) a module system, but it has
>> packages, which are first-class objects.
>>
>Maybe MAKE:DEFSYSTEM satisfies your definition of module.
I think that PROVIDE and REQUIRE give you modules. They take care that
things are loaded in the proper order. If A requires B, then B must be
loaded before A. Because in Lisp you have access to the language at load
time, B can do whatever it takes to initialize set up its global state
at that time. Constructs like DEFCONSTANT, DEFVAR and DEFPARAMETER
provide more than enough variety for that.
So you don't need anything like Modula 2 modules which have an anonymous
function for global initialization and all that, with the compiler
run-time calling these anonymous functions in the correct dependency
order.
I think it's a mistake to conflate modules and packages. They are
logically separate things.
Modules are physical units of the program; packages are namespaces for
symbols.
Forcing any relationship between them is counterproductive. A package
may simply be too large to fit into one module. It's not uncommon to
want to write a large, complex library consisting of many modules,
and put all of its symbols into one package.
The whole idea of having one source file where you declare a module's
interface and define its implementation as well as dependencies on other
modules, is too anally retentive to be taken seriously.
Also, in particular, any idea of conflating a filename and a package name
is completely idiotic, and must not be considered in any incarnation. If
someone wants to import symbols from a *package* FOO, and the language
implementation therefore looks for a *file* called FOO.def or something,
that is sheer lunacy.
Brian P Templeton <···@tunes.org> writes:
> Janis Dzerins <·····@latnet.lv> writes:
>
...
> > Common Lisp might not have (never had?) a module system, but it has
> > packages, which are first-class objects.
> >
> Maybe MAKE:DEFSYSTEM satisfies your definition of module.
No it cannot. It is not what MAKE:DEFSYSTEM is. Note that there is
nothing in *ml modules that implies that you need to load or compile a
file before or after something else.
What the *ml module system gives you is a nice way to do what
'generic' in Ada does and what templates almost do in C++. In the
first sense they support "separate compilation".
What you need in CL would be something like
(defpackage* "MATRIX" (:use "COMMON-LISP")
(:export ("MATRIX" :type :class))
(:export ("*" :of-type (function ((or number matrix)
(or number matrix))
(or number matrix)))))
Of course there are several caveats. Can you see the problem in the
DEFPACKAGE* form, should the above be implemented naively? :)
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th 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'.
Francois-Rene Rideau <···········@tunes.org> writes:
> ···@accton.shaw.ca (Kaz Kylheku) writes:
> > Another thing to be considered: is there any *single* language that
> > appears to be acquiring the features of Lisp?
> OCaml and Erlang have most of the good features of Lisp, including macros
> (with camlp4 and parse_transform), and they also have good features that
> Lisp never had: rich static strong typing and a higher-order module system
> for OCaml, support for building robust massively concurrent systems for
> Erlang.
I have looked into OCaml because of a local advocate. I agree that
some of the features of OCaml are very interesting. But I fail to
understand what the OCaml module system buys you (except as a nice
single place for interface declarations).
Could you elaborate about how the OCaml module system helps you and
to what lengths you have to go to achieve the same effects in Common
Lisp.
Cheers
PS. 3 + 3.14 should yield 6.14!
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th 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'.
Marco Antoniotti <·······@cs.nyu.edu> writes:
> Could you elaborate about how the OCaml module system helps you and
> to what lengths you have to go to achieve the same effects in Common
> Lisp.
It's difficult to say.
One role of the Module system is to allow for separate compilation.
There is nothing in standardized CL that really does it, even less that way.
Another role is to declare invariants at interfaces between modules,
that will be enforced by the system. While the type system of OCaml
can be argued to sometimes lack expressiveness (doesn't allow to express
some freedom or some constraint) in its system-enforceable invariants,
Common Lisp doesn't even have such thing, and you must face the advent
of runtime invariant failures, and pay the price of coping with them
(either implementing checks and handlers, or enforce and debug manually).
Packages in CL can fake the role of modules, but apart from the fact that
they are unable to provide with the capability-model of access restriction
of ML modules, they most importantly don't scale in presence of higher-order
modules ("functors").
Functors allow to build generic code taking types and other functors
as parameters; the resulting code can be quite elaborate, and in ML,
static typing is very useful in assessing that module combinations
are done right. Functors could theoretically be implemented as a very
sophisticated set of macros. Indeed, MzScheme has a first-class
module system that can do the equivalent of ML's functors, and also solves
the global namespace problem of Scheme (that has no packages).
In CL, the choice of namespace management technique for functors in CL
would be "interesting": Would you rather dynamically generate new packages?
Generate new symbols? Generate some first-class namespace objects holding
new meanings for existing symbols? Generate code that calls higher-order
functions with additional explicit parameters? Would you use the CL class
system and generate new classes? Or generate new generic functions?
Or generate new objects of a same class, that contain the type and functor
parameters as additional runtime data? It isn't all quite clear to me what
is the Right Thing(TM) to do that in CL. It seems to me that CL programmers
have just learnt to live without the equivalent of higher-order modules
and cope up in a case-by-case basis. The fact that CL won't statically
enforce much any invariant restricts the pressure to define clean module
interfaces, anyway.
> PS. 3 + 3.14 should yield 6.14!
Or maybe it should yield a compile-time error.
Dynamic type conversion induces precision issues,
and it the cost of requiring the programmer to assert
his taking responsibility for them with an explicit conversion
might be lower than the cost of handling all of dynamic type-checks,
type-errors and precision issues.
Moreover, as far as numbers are concerned, in your next operation
(lambda (x) (sqrt (- x))), are you considering x as a complex number?
as a real? an approximated real? as a member of such of such Ring?
Do you want both results, or just one? in the latter case, which?
Or do you want all (or some) of these meanings at the same time,
and let a further enclosing operation decide between them?
If to you, numbers are a low-level concept, then implicit conversions
are mostly something that forces decreased performance upon you;
and if to you, they are a high-level concept, then you like having a way
to specify you actual high-level intent, and implicit conversion will
seldom do what you really want unless you have an AI-complete DWIM feature.
[ Fran�ois-Ren� �VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
[ TUNES project for a Free Reflective Computing System | http://tunes.org ]
You cannot teach a man anything; you can only help him find it for himself.
In article <··············@Samaris.tunes.org>, Francois-Rene Rideau wrote:
> ···@accton.shaw.ca (Kaz Kylheku) writes:
>> Another thing to be considered: is there any *single* language that
>> appears to be acquiring the features of Lisp?
> OCaml and Erlang have most of the good features of Lisp, including macros
> (with camlp4 and parse_transform),
Do they? I don't know about Erlang, but I had believed the hype and
tried for a whole year to become as productive in OCaml as I used to
be in Common Lisp. It didn't work. Macros? Sure, camlp4 certainly
gives that functionality, but... it is so hard to use that I doubt
that anybody uses it in his everyday programming like I use defmacro in
Common Lisp.
> and they also have good features that
> Lisp never had: rich static strong typing and a higher-order module system
> for OCaml, support for building robust massively concurrent systems for
> Erlang.
At first I thought, too, that static typing was a great feature. I don't
anymore. You get used to it and after a while learn to write code that
contains practically no type errors in the first place. Then, the
remaining use of the type checker is only to annoy you because it isn't
perfect and rejects correct code all the time. There are lots of things
that you could just write down in a dynamically typed language but in
OCaml or SML you'd first have to fight the type checker for *hours*,
until you finally find a both ingenious and totally braindamaged way
to satisfy him. For an example just look up how to write an Y-combinator
in the ML FAQ. Or recall the endless discussions of ``phantom types''
in that community. All this type theory is indeed interesting and fun,
but I don't think that it really helps in practice. Rather the opposite.
Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x42B32FC9
Nils Goesche <······@cartan.de> writes:
[...]
> There are lots of things that you could just write down in a
> dynamically typed language but in OCaml or SML you'd first have to
> fight the type checker for *hours*, until you finally find a both
> ingenious and totally braindamaged way to satisfy him. For an
> example just look up how to write an Y-combinator in the ML FAQ.
Sure, but how often do you use the Y combinator in real programs?
> Or recall the endless discussions of ``phantom types'' in that
> community.
Phantom types are a feature, not a problem, of statically typed
languages! They enable you to use the type system to express (and
automatically verify, at type-checking time) some invariants using
types.
For a nice (and very practical) application of phantom types, see e.g.
"No-Longer-Foreign: Teaching an ML compiler to speak C natively." by
Matthias Blume, available there:
http://cm.bell-labs.com/who/blume/papers/nlffi-entcs.pdf
Or an interesing message of the OCaml list, with several examples:
http://caml.inria.fr/archives/200109/msg00097.html
Michel.
In article <················@lamppc21.epfl.ch>, Michel Schinz wrote:
> Nils Goesche <······@cartan.de> writes:
>
>> There are lots of things that you could just write down in a
>> dynamically typed language but in OCaml or SML you'd first have to
>> fight the type checker for *hours*, until you finally find a both
>> ingenious and totally braindamaged way to satisfy him. For an
>> example just look up how to write an Y-combinator in the ML FAQ.
>
> Sure, but how often do you use the Y combinator in real programs?
Never. But that doesn't change the fact that the Y combinator is an
/example/ for something that is trivially written down in Lisp and
extremely hard to write in ML. There are other examples. Who knows,
maybe it's just my programming style that keeps me finding one
example after another for this when writing in OCaml/SML, but so what?
A programming language should allow me to write valid code whenever
I want to instead of giving me a ``Hm. I don't understand what the
programmer is up to here, so I better signal an error.'' attitude.
When I realized that every OCaml program I (and other people) wrote
started with hundreds of lines defining union types and trivial
operations on those, whose only purpose is to reintroduce dynamic
typing once again, I began to understand that dynamic typing
is actually a /feature/ itself, not a lack of a feature. And all
those days I spent fighting and outsmarting the type checker,
particularly the module type checker (grrrr), were nothing but
totally wasted time.
Sure, being able to prove that languages like ML won't have any
run-time type errors is an impressive theoretical result. I
like reading books about the typed lambda calculus myself, just
for fun. But the fact that we have this nice theory does /not/
automatically imply that we all have to immediately switch to ML
like languages now. It wasn't so long ago when everybody said
that we all had to switch to Haskell, because it was so
mathematically pleasing at the time. Now it apparently suffices
to use impure languages like SML or OCaml, heaven knows, why.
And maybe when the static typing hype is over, it'll all of a
sudden be politically correct again to use dynamically typed
languages. I'll be waiting there until then :-)
Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x42B32FC9
Nils Goesche <······@cartan.de> writes:
> Sure, being able to prove that languages like ML won't have any
> run-time type errors is an impressive theoretical result. /.../
But you still can get runtime errors in ML. Just rely on some property
that ML can't check, like "x is always greater than zero" or
something. Then use the wrong x to do 1/x, or index into an array, or
whatever, and you get an ML exception.
Best,
Thomas
--
ftl Thomas Lindgren
@acm.org
I'd rather write programs that write programs than write programs-[R. Sites]
Nils Goesche <······@cartan.de> wrote in message news:<··············@ID-125440.news.dfncis.de>...
> In article <················@lamppc21.epfl.ch>, Michel Schinz wrote:
> > Nils Goesche <······@cartan.de> writes:
> >
> >> There are lots of things that you could just write down in a
> >> dynamically typed language but in OCaml or SML you'd first have to
> >> fight the type checker for *hours*, until you finally find a both
> >> ingenious and totally braindamaged way to satisfy him. For an
> >> example just look up how to write an Y-combinator in the ML FAQ.
> >
> > Sure, but how often do you use the Y combinator in real programs?
>
> Never. But that doesn't change the fact that the Y combinator is an
> /example/ for something that is trivially written down in Lisp and
> extremely hard to write in ML. There are other examples. [etc.]
For the OCaml system as implemented a few months ago, it doesn't need
to be something deep and twisty like a Y combinator. Just mutual
recursion among different types of data structures and functions
using them gets very hairy very fast. (If you look on the ocaml mailing
list last year, you'll find someone showing me the standard trick
to help with this this. But I'm not sure it solves everything, and
it sure does gets messy for bigger problems.)
Would you like to have a class C, one of whose slots is a collection
of objects of type C? If the collection is a list, of course, that's
fine. But if the collection is a hash table, things start to get
painful. Fast. Just to mix things between non-object types (definitions
starting with "type") and object types (definitions with "class" and
"object") requires a nonobvious workaround which gets very messy when
applied to multiple types and classes and slots.
And with modules, it gets worse. The idea of functors is great, and I'm
quite grateful to the ML people for expressing it so well in compilers,
so I could learn a lot about how to think about it by playing with it.
But when I tried to use functors for real problems, the implementation got
in the way. I found the typing problems above, plus some absolute limits
on mutually recursive modules, just got worse and worse
as I tried to use functors to express anything complex containing
mutually recursive relationships.
So, I've said what I particularly wanted to say. Hard-to-statically-type
expressions don't arise only in contrived problems.
Now, I'll remark on a few other ML/typing things from a Lisper's perspective.
First, someone wrote about how they always ended up writing a bunch
of union types to simulate dynamic typing in ML. I didn't. Maybe
I'm a statically typed programmer at heart? The only place I felt "I miss
dynamic typing here" was that I did miss upcasting objects,
especially when I was trying to figure out how to work
around the lack of multiple dispatch in OCaml. But mostly
my big problem was not things that fundamentally need to be
dynamically typed, it was things that are fundamentally type-safe that
OCaml couldn't understand.
Second, after all that I understand better why there would be so much
academic interest in strong typing. Partly, the theory is just neat.
But also, it would be extremely nice if all the
mutual recursion and functors and whatnot *could* be statically
typechecked by a real compiler. For a large part of a program I've
worked on, it would be so nice that I'd likely give up the other advantages
of Lisp for that problem (macros, especially, and also multiple dispatch
and typically better integration between the debugger and the REPL)
and working in ML.
Third, I think some of the static-typing arguments contain
an interesting echo of something we hear and say in the Lisp world.
When we say something could be done "by a sufficiently smart compiler", we're
being intentionally ironic, making only a weak statement about what can be
done in the real Lisp world. In reality, it takes
many man-years and many calendar years for Lisp compilers to get smart,
and in many cases they never become sufficiently smart. Similarly, I
think, if something could be statically type-checked by a sufficiently
smart compiler...
Nils Goesche <······@cartan.de> writes:
> At first I thought, too, that static typing was a great feature. I don't
> anymore. You get used to it and after a while learn to write code that
> contains practically no type errors in the first place. Then, the
> remaining use of the type checker is only to annoy you because it isn't
> perfect and rejects correct code all the time.
Yes ... A bit like a spell-checker, isn't it? But you can't turn
it off.
Best,
Thomas
--
ftl Thomas Lindgren
@acm.org
I'd rather write programs that write programs than write programs-[R. Sites]
Thomas Lindgren <···@***.***> writes:
> Nils Goesche <······@cartan.de> writes:
>
>> At first I thought, too, that static typing was a great feature. I don't
>> anymore. You get used to it and after a while learn to write code that
>> contains practically no type errors in the first place. Then, the
>> remaining use of the type checker is only to annoy you because it isn't
>> perfect and rejects correct code all the time.
>
> Yes ... A bit like a spell-checker, isn't it? But you can't turn
> it off.
>
I disagree.
First, when building large software and reusing modules from other
people, a static typesystem is nice in enforcing invariants that you don't
have in mind, because you wrote them long ago, or didn't write them at all.
It takes a lot of trouble off your mind so you can focus on things
that matter. This kind of problem mightn't be as big when programming
in the small, and you have all the invariants in mind anyway.
As I see it, the problem would rather be the fact that typesystems are
often not expressive enough, and that making the system seamlessly support
more elaborate typesystems is usually considered a difficult problem.
As for turning it off, language implementations usually provide some means
to escape static typing. For instance, Obj.magic in OCaml escapes
typechecking, and then you have dynamic typing. However, the runtime system
of OCaml notably lacks the runtime type introspection that would be useful
when manipulating (and particularly importing or exporting) dynamic data
(there are experimental patches to partially alleviate this problem).
I know that Mercury has some way to safely manipulate dynamically typed
objects. I'm not sure about Haskell, but I suspect most compilers have some
escape mechanism too.
LISP usually lacks a way to turn typing on. Also, SEXP feels like
quite a suboptimal syntax for specialized sublanguages like the type
language, or the language of objects of a given type.
All in all, you can't currently have the best of both worlds,
but I think it is an error to dismiss the achievements of the other world
just because they lack some of the great things achieved in the LISP world
(like great support for interactive programming environments -- although
OCaml and Mercury are not as bad as C on this side either).
Yours freely,
[ Fran�ois-Ren� �VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
[ TUNES project for a Free Reflective Computing System | http://tunes.org ]
If you make people think they're thinking, they'll love you;
but if you really make them think, they'll hate you. -- Don Marquis
Francois-Rene Rideau wrote:
> Thomas Lindgren <···@***.***> writes:
>
>> Nils Goesche <······@cartan.de> writes:
>>
>>> At first I thought, too, that static typing was a great feature. I
>>> don't
>>> anymore. You get used to it and after a while learn to write code that
>>> contains practically no type errors in the first place. Then, the
>>> remaining use of the type checker is only to annoy you because it isn't
>>> perfect and rejects correct code all the time.
>>
>> Yes ... A bit like a spell-checker, isn't it? But you can't turn
>> it off.
>>
> I disagree.
>
> First, when building large software and reusing modules from other
> people, a static typesystem is nice in enforcing invariants that you don't
> have in mind, because you wrote them long ago, or didn't write them at
> all. It takes a lot of trouble off your mind so you can focus on things
> that matter. This kind of problem mightn't be as big when programming
> in the small, and you have all the invariants in mind anyway.
> As I see it, the problem would rather be the fact that typesystems are
> often not expressive enough, and that making the system seamlessly support
> more elaborate typesystems is usually considered a difficult problem.
Through my lack of experience in writing real-world applications in
statically typed languages like OCaml I cannot claim if it actually helps
when writing big software systems. I think that Common Lisp somewhat proved
that dynamic typing works for _really_ large software systems.
Therefore I think that you cannot claim that people who use non-static
typed languages only had no trouble because they "programmed in the small"
;-)
[snipped paragraph on escaping static types in statically typed
languages...]
> LISP usually lacks a way to turn typing on. Also, SEXP feels like
> quite a suboptimal syntax for specialized sublanguages like the type
> language, or the language of objects of a given type.
> All in all, you can't currently have the best of both worlds,
> but I think it is an error to dismiss the achievements of the other world
> just because they lack some of the great things achieved in the LISP world
> (like great support for interactive programming environments -- although
> OCaml and Mercury are not as bad as C on this side either).
Your first sentence sounds as if you think Lisp is "untyped" - I know that
you know better but can you explain what you meant?
Furthermode you lost me on why SEXPs are a suboptimal syntax for
sublanguages like the type language or the language of objects of a given
type. I don't see any fundamental problems in using an SEXP syntax for a
type sublanguage.
I agree that you currently cannot have the best of both worlds and I often
lock whats going on in the other camps even if I do not actually use their
work.
What I still miss in OCaml are:
- Generic Functions (with multiple dispatch)
- Multiple Inheritance (or some other technique to support mixin-style
programming)
- A better integrated macro-system than CamlP4
- A CORBA ORB! (I would have been able to use OCaml instead of Java in a
university project regarding to distributed object systems)
I think the syntax of OCaml is mostly nice but I had some problems reading
and writing it. To my untrained eye it offers less structure than lisp but
I could imagine that this changes quickly with usage.
ciao Fare ;-)
Jochen
--
http://www.dataheaven.de
Jochen Schmidt <···@dataheaven.de> writes on comp.lang.lisp:
> I think that Common Lisp somewhat proved
> that dynamic typing works for _really_ large software systems.
>
Oh, well, there have been huge systems in C++ or COBOL, too.
So the argument should rather be one of cost/benefits
(the estimation of which is indeed partly subjective):
how much does it cost (in months, unit of proficiency, kloc, etc.,
ultimately, dollar) to achieve how much features that are worth what
(in fame, brand recognition, community building, number of customers, etc.,
ultimately, dollar)?
>> LISP usually lacks a way to turn typing on.
> Your first sentence sounds as if you think Lisp is "untyped" - I know that
> you know better but can you explain what you meant?
>
Indeed, this sentence as stated is incorrect.
What I meant is that there is no (standard) way in LISP to have the system
enforce any kind of rich static type system. Let me expand on that.
A rich static type system is a way to attach some non-trivial invariants
to the context in which some objects and functions will be used.
Christopher Browne suggested that CMUCL and Stalin would be counter-examples.
Stalin certainly isn't -- as far as I know, it won't enforce any kind of
user-supplied type declaration; it will infer a "type" for every program;
any invariant enforced as to the context of use of a given object is trivial.
CMUCL comes much closer, since it is possible to declare types, and have
the system enforce them, although it requires quite some familiarity with
the system so as to understand how to use declarations to *statically*
enforce invariants -- which implies filtering the CMUCL warnings to detect
whether any inconsistency was detected. In addition to such usability
issues, the richness of type-system enforceable by CMUCL its a far cry
from that of the simplest ML variant.
>> Also, SEXP feels like
>> quite a suboptimal syntax for specialized sublanguages like the type
>> language, or the language of objects of a given type.
>
> Furthermode you lost me on why SEXPs are a suboptimal syntax for
> sublanguages like the type language or the language of objects of a given
> type. I don't see any fundamental problems in using an SEXP syntax for a
> type sublanguage.
>
It's indeed not a "fundamental" problem, but an important usability problem.
As an exercise, just try to write ML programs with a SEXP syntax,
which Macro Antoniotti suggested in a mail would have made *ML
better languages. It's definitely possible - and actually, the original
ML interpreter and the first ML compilers were written in LISP, and
there was a internal LISP representation for terms. But there's a reason
why ML users did not just stick to such internal representation.
Not only do you end up using noticeably more characters,
but the result is rather unwieldy, unless you are writing deep macros,
as with camlp4. Note that I'm not claiming that a SEXP syntax be dropped
altogether (as was the case with Dylan), but that there are times when
a specialized syntax is preferrable (which I presume is precisely
the reason why CL has reader-macros).
As for the CL syntax (declare (type Tfoo bar)), defended by Christopher
Browne, apart from its not having a semantic of system-enforcement
(a variant certainly could), it has the syntactical disadvantage of
not being at point of declaration of the declared variable bar.
A syntax as practical as ML would be to have something like (the Tfoo bar)
in lambda lists as well as in positive terms, although once again
with semantics of a system-enforcement rather than user-enforcement.
My conclusion would be that the lack of rich strong static typing in LISP
is certainly a disadvantage, and that though extending LISP with such typing
is at least conceivable, for practical reasons it would probably lead to a
language that, while hopefully retaining enough of the distinctive
characteristics of LISP that we like to still be called a LISP, would
probably also be noticeably different from existing LISPs, and largely
incompatible too, both semantically and syntactically.
Would such a beast be desirable? I think it would be worth a try,
and I intend to try, one of these days.
Yours freely,
[ Fran�ois-Ren� �VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
[ TUNES project for a Free Reflective Computing System | http://tunes.org ]
It is a profoundly erroneous truism, repeated by all copy-books and
by eminent people when they are making speeches, that we should cultivate
the habit of thinking about what we are doing. The precise opposite is the
case. Civilization advances by extending the numbers of important operations
which we can perform without thinking about them. Operations of thought are
like cavalry charges in battle -- they are strictly limited in number, they
require fresh horses, and must only be made at decisive moments.
-- Alfred North Whitehead
From: Ray Blaak
Subject: Re: Static Typing in LISP? (was Re: The true faith)
Date:
Message-ID: <uwuyi1adv.fsf@telus.net>
Francois-Rene Rideau <···········@tunes.org> writes:
> My conclusion would be that the lack of rich strong static typing in LISP is
> certainly a disadvantage, and that though extending LISP with such typing is
> at least conceivable, for practical reasons it would probably lead to a
> language that, while hopefully retaining enough of the distinctive
> characteristics of LISP that we like to still be called a LISP, would
> probably also be noticeably different from existing LISPs, and largely
> incompatible too, both semantically and syntactically. Would such a beast
> be desirable? I think it would be worth a try, and I intend to try, one of
> these days.
Wouldn't a SEXP version of Dylan give you most of what is needed?
Or are you after the type inferencing and richer type specification abilities
available in ML, OCaml and friends?
Has long as the static typing is optional (or more or less equivalently: there
is some sort of ANYTHING type), allowing the best of both worlds (e.g. dynamic
typing for prototyping and flexibility, static typing when desired for helping
to ensure correctness, esp. in large systems), then this would be something I
would definitely like to see.
Also, make sure that full type information is always available at runtime, for
both static and dynamic types. This aids in debugging and analysis and dynamic
code generation.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
·····@telus.net The Rhythm has my soul.
Francois-Rene Rideau <···········@tunes.org> writes:
...
> >> Also, SEXP feels like
> >> quite a suboptimal syntax for specialized sublanguages like the type
> >> language, or the language of objects of a given type.
> >
> > Furthermode you lost me on why SEXPs are a suboptimal syntax for
> > sublanguages like the type language or the language of objects of a given
> > type. I don't see any fundamental problems in using an SEXP syntax for a
> > type sublanguage.
> >
> It's indeed not a "fundamental" problem, but an important usability problem.
> As an exercise, just try to write ML programs with a SEXP syntax,
> which Macro Antoniotti suggested in a mail would have made *ML
> better languages. It's definitely possible - and actually, the original
> ML interpreter and the first ML compilers were written in LISP, and
> there was a internal LISP representation for terms. But there's a reason
> why ML users did not just stick to such internal representation.
> Not only do you end up using noticeably more characters,
> but the result is rather unwieldy, unless you are writing deep macros,
> as with camlp4. Note that I'm not claiming that a SEXP syntax be dropped
> altogether (as was the case with Dylan), but that there are times when
> a specialized syntax is preferrable (which I presume is precisely
> the reason why CL has reader-macros).
>
> As for the CL syntax (declare (type Tfoo bar)), defended by Christopher
> Browne, apart from its not having a semantic of system-enforcement
> (a variant certainly could), it has the syntactical disadvantage of
> not being at point of declaration of the declared variable bar.
> A syntax as practical as ML would be to have something like (the Tfoo bar)
> in lambda lists as well as in positive terms, although once again
> with semantics of a system-enforcement rather than user-enforcement.
I disagree. Frist of all the `datatype' and friends declarations of
*ml languages, besides introducing new types in the system, do provide
you with essentially an operator syntax that, as a syntax, is another
way to look at CL macros. Secondly, I fail to see how a syntax like
(def foo ((x some-type) (y some-other-type) z
&key (q 3 fixnum) (w 4.9 float)) ...)
as opposed to
fun foo (x : some-type) (y : some-other-type) z q w = .....
| foo x y z 3 4.9 = ...
would be so cumbersome. (I know the semantic is not the same!).
The real reason for dropping S-expr notation is, IMHO and
ex-post-facto, historical. Pretty much the same kind of reasons why
in CL we have to suffer through pathnames.
When the first ML system where implemented, there was no good way to
write a general datatype for S-exprs. Hence, they could not fit in
the implementation. Add to that the strong mathematical inclination
of the original ML crowd and voila`: you have ML syntax.
My point is that in CL (and without resorting to too many reader
macros either) you can come up with very nice syntaxes for your
languages.
After all LOOP (like it or not) is a macro.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th 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'.
In article <··············@Samaris.tunes.org>, Francois-Rene Rideau wrote:
>Thomas Lindgren <···@***.***> writes:
>
>> Nils Goesche <······@cartan.de> writes:
>>
>>> At first I thought, too, that static typing was a great feature. I don't
>>> anymore. You get used to it and after a while learn to write code that
>>> contains practically no type errors in the first place. Then, the
>>> remaining use of the type checker is only to annoy you because it isn't
>>> perfect and rejects correct code all the time.
>>
>> Yes ... A bit like a spell-checker, isn't it? But you can't turn
>> it off.
>>
>I disagree.
>
>First, when building large software and reusing modules from other
>people, a static typesystem is nice in enforcing invariants that you don't
>have in mind, because you wrote them long ago, or didn't write them at all.
Enforcing invariants and static checking are two orthogonal things.
An invariant is simply some predicate over some objects which is required
or assumed to hold true.
A static type check is a validation of a constraint over some type
information objects that are known at the time a program is read.
Run time invariants typically have to do with the state of data
objects. In the case of a dynamic language, they also include type
information.
In general, only a small subset of invariants can be determined at compile
time through decalrations or by inference. The remaining ones can only
be checked through instrumentation incorporated into the program.
>It takes a lot of trouble off your mind so you can focus on things
>that matter.
People who have experience in both static and dynamic langauges tend to
disagree with this. The static system simply gets in the way, so you
focus on satisfying mindless constraints everywhere in the program,
not just in hotspots where performance matters.
Runtime errors occur in static and dynamic programs alike. In a dynamic
language, the type of an object is part of its run time state, so it can
be erroneous, like any other data. So what? In static languages this is
also the case that run time state can be erroneous. But it is actually
worse, because these languages usually have no safety net beyond the
static checks. All type errors *must* be caught at the time the program
is scanned and translated. Any type errors which bypass the checking
are disastrous. Usually they are marked as undefined behavior in a
language specification.
This static checking is done for the sake of speed, but these languages
force it into every nook and cranny of the program, no matter how rarely
executed. Even dead code must pass type checks!
There is static checking in a dynamic language. It is in the
*implementation*. You see the dynamic language implementation is
built over a fragile substrate. The implementation is trusted not to
misinterpret some arbitrary object as a type field, or treat a type field
as something else. There is no lower-level sub-type-field which will tell the
dynamic language that the memory cell it is dealing with *is* a type
field, or not. Something just has to be assumed and trusted. After all,
it is just machine language executing, which will happily treat any
operand as having any machine type, and trample over anything whose
address it can utter.
When something fragile must be assumed and trusted, it comes to reason
that the trust should be concentrated in a small kernel, which can be
thoroughly inspected and debugged, and perhaps even subject to the helpful
static type checks of a Stone Age programming language. Perhaps the
hardware itself, even, should take on some of the responsibilties.
That trust should not creep into every nook and cranny of every program
in the system!
A dynamic language is such a trusted kernel. Others centers
of responsibility are similarly trusted, like operating system
kernels. These components often let us down by exhibiting instability,
inflexibility and security holes. That is in part because they are built
on the fragile trust of a static programming language, and because they
are allowed to become very large without any shift to a higher level
of abstraction. There are layers of code, but they all use the same
implementation technique. So that fragile computing is distributed through
hundreds of thousands of lines of code. Whereas the implmementation of
a dynamic language typically has a reasonably small core, and the rest
of the furnishings are written in a subset of that language itself.
>This kind of problem mightn't be as big when programming
>in the small, and you have all the invariants in mind anyway.
Static languages are extremely inconvenient for small programs,
by comparison to dynamic one, (except in contrived cases
where a special library or other gadget makes a language
particularly suitable to the problem solved by the small program).
That does not mean that dynamic languages are *exclusively* convenient for
small programs. If you only consider small programs, and advocate static
languages, it may look that way. You might think, okay, so I'm beat by
the dynamic language on this small program, but surely it doesn't scale
well to a large program, because it doesn't have these static checks?
It turns out that the static type system not only starts inconvenient in a
small program and only gets worse and worse with increasing program size.
Making tiny changes creates huge repercussions, requiring a propagation
of change and recompiling. These coupling problems are dealt with
by certain relaxations to static typing, such as Simula 67 style
polymorphism, often without any compensating safety net. The slightest
accident somewhere threatens the entire program.
Proponents of static languages think that increasing the strength
can solve some of the stability problems. If only every type error
can be banished from the program, then there won't be accidents
due to an object being misused. And paradoxically, certain
relaxations to the static typeing are introduced to loosen
the coupling, such as Simula 67 style polymorphism.
Unfortunately, such strength renders these programming languages
useless precisely in their best domain of application. Which
is writing a small core of low-level trusted system code
such as memory management, garbage collection, device drivers,
interpreters and run-time support and the like. The aforementioned
kernel material.
In a stone age programming language with a static type system, you need
pointers, and the ability to just say ``this memory location is to be
treated like this type''. Such a capability is needed if you are to
bootstrap yourself from a dumb machine to a high level programming system.
It's also desirable for the language that is to be providing
run-time support to programs to itself require minimal run-time support.
But it's entirely pointless to make dynamic-like languages which are
statically typed. Take the still birth known as Java for instance;
useless for systems programming, and a type system that gets
in the way of high level programming. What's it good for? Java
practically screams to rip off its straitjacket and be a real dynamic
language.
>LISP usually lacks a way to turn typing on. Also, SEXP feels like
Lisp has declarations which are typically used to tell a compiler
to make assumptions about some data over some small body of code,
in hopes of making it run faster.
Static languages require static type information in every
corner of the program, even unreachable code.
Programmers is forced to make choices that resemble optimization,
even in code that doesn't require optimization. Those choices are hard
to change later.
>quite a suboptimal syntax for specialized sublanguages like the type
>language, or the language of objects of a given type.
Suboptimal in what parameter? You can write custom scanners and parsers
in Lisp, if you want. For example the well-known infix.cl file provides
a reader macro which understands a C-like notation, so you can for
instance write:
#i( f(x += a[i], y) )
Which means (f (incf x (aref a i) y)) . It's not wise to assume that
Lisp has any impedance against anything. You just need to lend Lisp two
dispatch characters, and it will run your own scanner and parser. All ANSI
standard, portable among implementatons. Such notations are suboptimal
with respect to writing code that needs to process the corresponding
object. They may be superior human interfaces, at least to people who
are trained in specific notations.
From: Ray Blaak
Subject: Static and dynamic typing should work together (was Re: The true faith)
Date:
Message-ID: <uu1tm18qj.fsf_-_@telus.net>
···@accton.shaw.ca (Kaz Kylheku) writes:
> >It takes a lot of trouble off your mind so you can focus on things
> >that matter.
>
> People who have experience in both static and dynamic langauges tend to
> disagree with this. The static system simply gets in the way, so you
> focus on satisfying mindless constraints everywhere in the program,
> not just in hotspots where performance matters.
If this is happening, then one is either a) using a badly designed language or
b) not declaring their types appropriately for the problem at hand.
One's types should be set up so that in general one can express the problem
solutions easily and naturally. Then, the type system getting in the way means
there is a programming error.
> Runtime errors occur in static and dynamic programs alike. In a dynamic
> language, the type of an object is part of its run time state, so it can be
> erroneous, like any other data. So what? In static languages this is also
> the case that run time state can be erroneous. But it is actually worse,
> because these languages usually have no safety net beyond the static checks.
> All type errors *must* be caught at the time the program is scanned and
> translated. Any type errors which bypass the checking are disastrous.
> Usually they are marked as undefined behavior in a language specification.
Useful statically typed languages must be able to detect runtime errors. That
is, they have a safety net at compile time, and another at runtime. E.g. Ada.
It is theoretically impossible to eliminate runtime errors, and any language
without runtime checking is indeed a recipe for disaster.
The only one I know of without a runtime safety net is C/C++. When I am forced
to use C++, I make sure all my classes have a liberal sprinkling of runtime
checks, precisely because the alternative is an uncontrolled program crash.
[I also *do not* remove these checks in the release version either. Why is it
considered to be ok to have a debug version crash with informative messages,
but the release version in front of the client's eyes crashes disastrously?
Makes no sense to me. Performance considerations are usually not an issue for
90%+ of the code anyway.]
> It turns out that the static type system not only starts inconvenient in a
> small program and only gets worse and worse with increasing program size.
My experience is the reverse (e.g. the Canadian Air Traffic system). Static
typing illustrated its usefulness more the larger and more complex the system
became.
> Making tiny changes creates huge repercussions, requiring a propagation
> of change and recompiling. These coupling problems are dealt with
> by certain relaxations to static typing, such as Simula 67 style
> polymorphism, often without any compensating safety net. The slightest
> accident somewhere threatens the entire program.
The reprecussions that result depend on the nature and location of the
change. Changes in a specification used by other modules cause the biggest
impacts. Changes located in a private implementation body impact only that body
of code.
But yes, it is the nature of the beast for static typing that full
recompilation can be needed, since how else can all the necessary dependencies
be properly verified before runtime.
> Proponents of static languages think that increasing the strength can solve
> some of the stability problems. If only every type error can be banished
> from the program, then there won't be accidents due to an object being
> misused.
Does anyone really think this? Static typing is primarily a tool for helping to
verify correctness. Not "verify correctness" but "help verify correctness". It
catches a significantly useful number of errors, but not all. It is
theoretically impossible to catch all.
That more efficient code can often be generated when static typing is used is
another advantage, but not the primary one.
Useful static languages must have a dynamic aspect to them or else they would
not be useful.
> But it's entirely pointless to make dynamic-like languages which are
> statically typed. Take the still birth known as Java for instance; useless
> for systems programming, and a type system that gets in the way of high level
> programming. What's it good for? Java practically screams to rip off its
> straitjacket and be a real dynamic language.
I strongly disagree with this. I would like to see languages with are both
dynamic and statically typed, allowing the programmer the option of choosing a
style for a particular problem, or mixing dynamic and static styles, or when
necessary simply going the full static route if that is required.
Provide the tools in an easy to use manner, and let the programmer use them as
appropriate. Let the programmer decide the tradeof between ease of use,
flexibility, and tool-aided correctness verification.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
·····@telus.net The Rhythm has my soul.
Ray Blaak <·····@telus.net> wrote in message news:<················@telus.net>...
> I strongly disagree with this. I would like to see languages with are both
> dynamic and statically typed, allowing the programmer the option of choosing a
> style for a particular problem, or mixing dynamic and static styles, or when
> necessary simply going the full static route if that is required.
Yes, and don't throw 'Strong' typing out along with 'Static' typing... Google
the web for 'gbeta' to see an example of a strongly typed language that supports
such dynamic behaviour as creation and manipulation of types at run-time.
From: Rahul Jain
Subject: Re: Static and dynamic typing should work together (was Re: The true faith)
Date:
Message-ID: <8766605y2b.fsf@photino.sid.rice.edu>
······@yahoo.com (thomas) writes:
> Yes, and don't throw 'Strong' typing out along with 'Static'
> typing... Google the web for 'gbeta' to see an example of a strongly
> typed language that supports such dynamic behaviour as creation and
> manipulation of types at run-time.
Hey, that sounds like what I can do in that that Lisp lanugage I keep
on hearing about on slashdot!!
--
-> -/- - Rahul Jain - -\- <-
-> -\- http://linux.rice.edu/~rahul -=- ············@techie.com -/- <-
-> -/- "I never could get the hang of Thursdays." - HHGTTG by DNA -\- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
Version 11.423.999.221020101.23.50110101.042
(c)1996-2002, All rights reserved. Disclaimer available upon request.
In article <··············@ID-125440.news.dfncis.de>, Nils Goesche
<······@cartan.de> wrote:
> At first I thought, too, that static typing was a great feature. I don't
> anymore. You get used to it and after a while learn to write code that
> contains practically no type errors in the first place. Then, the
> remaining use of the type checker is only to annoy you because it isn't
> perfect and rejects correct code all the time. There are lots of things
> that you could just write down in a dynamically typed language but in
> OCaml or SML you'd first have to fight the type checker for *hours*,
> until you finally find a both ingenious and totally braindamaged way
> to satisfy him.
This pretty much matches my experience with OCaml, though I probably
haven't tried as hard as you.
I'm just not smart enough to have total omniscience about types right
from the start.
And yet, those OCaml guys consistently write complex code in a short
time to win programming contests. How do they do it? I don't think I
could. I can do it in Dylan, where I can be a bit vague about types at
first and then think really hard about them only in the places that are
speed critical.
I very seldom get type errors in actual programming, but *knowing* that
your program is type-correct is a heck of a lot easier than *proving* it
to the OCaml compiler.
-- Bruce
In article <·····················@news3.calgary.shaw.ca>,
···@ashi.footprints.net wrote:
> In article <····················@eglaptop.jpl.nasa.gov>, Erann Gat wrote:
> >(perhaps the only application) of macros. As for metaprogramming being
> >infeasible in other languages, I'd agree that's the case today. But that
> >situation is only one bright idea away from changing.
>
> Erann, if these language designers are so smart, why don't they just
> skip ahead to the end and put all the features in?
Who said language designers were smart? Not me. But in this particular
case the "one bright idea" that I was referring to is a conceptual
breakthrough that hasn't been made yet: how to do macros for infix
syntax. That's a Really Hard Problem that hasn't been solved yet (IMO),
so you can't just "skip ahead to the end." But I'm not convinced it's
unsolvable.
E.
On Tue, 15 Jan 2002, Erann Gat wrote:
[snip]
> Who said language designers were smart? Not me. But in this particular
> case the "one bright idea" that I was referring to is a conceptual
> breakthrough that hasn't been made yet: how to do macros for infix
> syntax.
Hmm. Actually there are a number of ways to do that, starting with
prologian tricks. I think the issue is how to do it as nicely as Lisp
macros and how to develop the practices that make lisp macros so wildly
and effectively used.
> That's a Really Hard Problem that hasn't been solved yet (IMO),
> so you can't just "skip ahead to the end." But I'm not convinced it's
> unsolvable.
We really need a better description of the problem.
Cheers,
Bijan Parsia.
···@jpl.nasa.gov (Erann Gat) writes:
> Who said language designers were smart? Not me. But in this particular
> case the "one bright idea" that I was referring to is a conceptual
> breakthrough that hasn't been made yet: how to do macros for infix
> syntax. That's a Really Hard Problem that hasn't been solved yet (IMO),
> so you can't just "skip ahead to the end." But I'm not convinced it's
> unsolvable.
Dylan at least gives a try at it. And even though there are no
procedural macros in the standard, Functional Developer has them
internally, so they are possible to implement.
Andreas
--
"In my eyes it is never a crime to steal knowledge. It is a good
theft. The pirate of knowledge is a good pirate."
(Michel Serres)
···@jpl.nasa.gov (Erann Gat) writes:
> In article <··············@tunes.org>, Brian P Templeton <···@tunes.org> wrote:
>
>> ···@jpl.nasa.gov (Erann Gat) writes:
>> > Today the only feature
>> > that remains unique to Lisp is macros. Macros are certainly useful, but
>> > they are not by themselves an advantage that dominates all other
>> > considerations.
>> >
>> Don't forget metaprogramming. AFAICT, metaprogramming is *much* easier
>> in most Lisps than in other languages (in fact, I'm not convinced that
>> it's at all feasible to do metaprogramming in most other languages).
>
> Metaprogramming is easier in Lisp *because* of macros. In fact, I'd say
> that metaprogramming is not a feature of the language, but an application
> (perhaps the only application) of macros. As for metaprogramming being
> infeasible in other languages, I'd agree that's the case today. But that
> situation is only one bright idea away from changing.
>
No, metaprogramming is easier in Lisp because of sexps - source is
data, and data is source. Even if Lisp had no macros (assuming people
did not add lots of new special forms), metaprogramming would be just
as easy.
> E.
--
BPT <···@tunes.org> /"\ ASCII Ribbon Campaign
backronym for Linux: \ / No HTML or RTF in mail
Linux Is Not Unix X No MS-Word in mail
Meme plague ;) ---------> / \ Respect Open Standards
Brian P Templeton <···@tunes.org> writes:
> > Metaprogramming is easier in Lisp *because* of macros. In fact,
> > I'd say that metaprogramming is not a feature of the language, but
> > an application (perhaps the only application) of macros. As for
> > metaprogramming being infeasible in other languages, I'd agree
> > that's the case today. But that situation is only one bright idea
> > away from changing.
> >
> No, metaprogramming is easier in Lisp because of sexps - source is
> data, and data is source. Even if Lisp had no macros (assuming
> people did not add lots of new special forms), metaprogramming would
> be just as easy.
Both are needed -- macros alone are not enough since you need *some*
syntax structure to work with (and a high level sexp is naturally
better than flat strings as with CPP). But sexps alone are not good
either without any `backdoor' back to the implementation -- `eval' (or
some variant like `compile') would be a start but macros allow you to
plug your processing functions straight into normal code.
[But, being on tunes.org, you probably know that...]
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
·············@vanderbilt.edu (Sashank Varma) writes:
[...]
> Other languages seem to be zooming past Common Lisp as far as
> the standard libraries they offer; this appears to be what you're
> getting at. But what about the unique features of Lisp -- the
[...]
I think using CLOCC one has quite a bunch of useable code to start
with and it seems to be portable enough to get one's programs working
on several common lisp systems. The only thing I _really_ miss in
Common Lisp is threads. I respect ADA's features to do multithreading
in a true pascal-like manner. But far as I know the only free (and
useable) CL implementation supporting threads is CMU CL, or am I
wrong? As I do most work on my (very) old laptop that is not suited
for the heavy-weight CMU CL (and is thus running clisp), I have to
avoid threads. That is particularly painful when dealing with
networking.
Regards,
Julian St.
·········@gmx.net (Julian St.) writes:
> ·············@vanderbilt.edu (Sashank Varma) writes:
>
> [...]
>
>> Other languages seem to be zooming past Common Lisp as far as
>> the standard libraries they offer; this appears to be what you're
>> getting at. But what about the unique features of Lisp -- the
>
> [...]
>
> I think using CLOCC one has quite a bunch of useable code to start
> with and it seems to be portable enough to get one's programs working
> on several common lisp systems. The only thing I _really_ miss in
> Common Lisp is threads. I respect ADA's features to do multithreading
> in a true pascal-like manner. But far as I know the only free (and
> useable) CL implementation supporting threads is CMU CL, or am I
> wrong? As I do most work on my (very) old laptop that is not suited
> for the heavy-weight CMU CL (and is thus running clisp), I have to
> avoid threads. That is particularly painful when dealing with
> networking.
>
I've seen a port of CMUCL's MP package for SBCL (IIRC, from the same
person who wrote net-sbcl-sockets).
>
> Regards,
> Julian St.
--
BPT <···@tunes.org> /"\ ASCII Ribbon Campaign
backronym for Linux: \ / No HTML or RTF in mail
Linux Is Not Unix X No MS-Word in mail
Meme plague ;) ---------> / \ Respect Open Standards
Brian P Templeton <···@tunes.org> writes:
[...]
> > I think using CLOCC one has quite a bunch of useable code to start
> > with and it seems to be portable enough to get one's programs working
> > on several common lisp systems. The only thing I _really_ miss in
> > Common Lisp is threads. I respect ADA's features to do multithreading
> > in a true pascal-like manner. But far as I know the only free (and
> > useable) CL implementation supporting threads is CMU CL, or am I
> > wrong? As I do most work on my (very) old laptop that is not suited
> > for the heavy-weight CMU CL (and is thus running clisp), I have to
> > avoid threads. That is particularly painful when dealing with
> > networking.
> >
> I've seen a port of CMUCL's MP package for SBCL (IIRC, from the same
> person who wrote net-sbcl-sockets).
[...]
After I wrote the posting I remembered that I missed SBCL, but this is
caused mostly by the fact that I have never used SBCL myself. Besides
Corman Lisp does exist in the Windows world (really cool common lisp
compiler/ide) with support for both networking and
multithreading. It is quite cheap, too.
But I ask myself why there is still no support for multithreading in
e.g. clisp...
Regards,
Julian Stecklina
Jeder kennt doch diesen Ton
Die Post schickt ihn durch's Telefon
Dieses Zeichen nennt man frei
Und so f�hl ich mich dabei
--
Andreas Dorau
"Das Telefon sagt du"
·········@gmx.net (Julian St.) writes:
> But I ask myself why there is still no support for multithreading in
> e.g. clisp...
Because it's a bunch of work, probably. They had an offer of some
money up on sourceforge for a while, but honestly it was less than
what I'd want for the job, and now the offer's gone. What can
probably be concluded from this is that there just isn't sufficient
demand for it in the CLISP community.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
On Thu, 10 Jan 2002, Sashank Varma wrote:
[snip]
> Other languages seem to be zooming past Common Lisp as far as
> the standard libraries they offer; this appears to be what you're
> getting at.
[snip]
FWIW, that's not clear to me. Take Python. Post 1.6 developments seemed
focused on extending the base langauge (full lexical scope, list
comprehensions, etc. etc.). Yes, more libraries have been included, but
much of the standard library is painful unto nigh worthlessness (at least
as a complete, drop in, solution). I've just recently been bit by the CGI
module, and *all* the various XML ones. The CGI one hasn't been updated in
a very long time, afaict.
It's one thing to release a module/package. It's another to keep it up to
date, improve it, etc. And even if the improvments are done by others, you
still have to integrate those changes.
Having fine grained, integrated, shareable versioning is tough.
A lot of effort, also, seems to go into very unwieldy things. The W3C DOM,
for example. A "standard" and a buzzword and *rather* painful to use ;)
So I don't know about "Zooming past". Most langauges/environment don't
have particularly good format commands, for example.
I'd love if there were a journal or magazine that seriously evaluated
langauge libraries in a comparative way. And developed good testing and
evaluation methodologies for such.
It's not enough to look at the "module lists" floating around, since,
after all, they don't tend to go *very* deep into details like "broken" :)
(Some do, but even that's hard to evaluate since a somewhat broken package
might still be rather useful.)
Cheers,
Bijan Parsia.
···@jpl.nasa.gov (Erann Gat) wrote in message news:<····················@eglaptop.jpl.nasa.gov>...
> Apostle of the True Faith. I've been a Lisp programmer for twenty years.
During those 20 years, did you write some interesting programs, which
we could discuss here? It would be interesting to compare how you
felt about those programs when you wrote them with how you feel about
them now.
I'm also curious to know if you wrote macros to change the syntax of
Lisp and then later abandoned those macros after deciding the syntax
changes weren't really improvements. Is that something nearly all
Lisp programmers eventually do? Do they tend to do it after a certain
number of years of Lisp, or just at random times?
In article <····························@posting.google.com>,
··········@mailandnews.com (Software Scavenger) wrote:
> ···@jpl.nasa.gov (Erann Gat) wrote in message
news:<····················@eglaptop.jpl.nasa.gov>...
>
> > Apostle of the True Faith. I've been a Lisp programmer for twenty years.
>
> During those 20 years, did you write some interesting programs, which
> we could discuss here?
See
http://groups.google.com/groups?hl=en&selm=1f4c5c5c.0108252226.330d6cac%40posting.google.com
> I'm also curious to know if you wrote macros to change the syntax of
> Lisp and then later abandoned those macros after deciding the syntax
> changes weren't really improvements. Is that something nearly all
> Lisp programmers eventually do? Do they tend to do it after a certain
> number of years of Lisp, or just at random times?
I've written and abandoned many macros over the years. But a few I've kept.
E.
I remember reading that post before. My reaction to what you have done, is,
GOOD JOB! Programming and Lisp are more than the narrow idea of writing and
compiling a program for a specific machine. There is all the scaffold code
to get the code written (your cross compiler, simulators and of course your
testing code. The Lisp development environment is also a tool to get the
ideas from your head into a rigorous description. Of course most of your
stuff has been tossed and obviously not appreciated. I am sorry for that.
I remember working on an embedded system, I wrote code and tested for almost
two years (there were 9 of us). I remember sitting down, burning a EPROM
(386 K), looking at it and thinking, "This is it?!!". It was a little
deflating, what I thought was so important in the big scheme of things
wasn't.
Wade
"Erann Gat" <···@jpl.nasa.gov> wrote in message
·························@eglaptop.jpl.nasa.gov...
> In article <····························@posting.google.com>,
> ··········@mailandnews.com (Software Scavenger) wrote:
>
> > ···@jpl.nasa.gov (Erann Gat) wrote in message
> news:<····················@eglaptop.jpl.nasa.gov>...
> >
> > > Apostle of the True Faith. I've been a Lisp programmer for twenty
years.
> >
> > During those 20 years, did you write some interesting programs, which
> > we could discuss here?
>
> See
>
http://groups.google.com/groups?hl=en&selm=1f4c5c5c.0108252226.330d6cac%40po
sting.google.com
In article <············@news3.cadvision.com>, "Wade Humeniuk"
<········@cadvision.com> wrote:
> I remember reading that post before. My reaction to what you have done, is,
> GOOD JOB!
Thanks.
> Programming and Lisp are more than the narrow idea of writing and
> compiling a program for a specific machine. There is all the scaffold code
> to get the code written (your cross compiler, simulators and of course your
> testing code. The Lisp development environment is also a tool to get the
> ideas from your head into a rigorous description. Of course most of your
> stuff has been tossed and obviously not appreciated. I am sorry for that.
The stuff I've written that has been tossed pales in comparison to the
stuff that other people have written and has been tossed (e.g. Genera,
Smalltalk, NextSTEP). Rather than wringing our hands about how
unappreciated we are I think it's much more productive to start from the
premise that there might have been some good reasons all that stuff got
tossed, to try to understand what those reasons were, and then to take
those lessons and move on to the next thing.
> I remember working on an embedded system, I wrote code and tested for almost
> two years (there were 9 of us). I remember sitting down, burning a EPROM
> (386 K), looking at it and thinking, "This is it?!!". It was a little
> deflating, what I thought was so important in the big scheme of things
> wasn't.
Size isn't everything ;-)
E.
"Erann Gat" <···@jpl.nasa.gov> wrote in message
·························@eglaptop.jpl.nasa.gov...
> The stuff I've written that has been tossed pales in comparison to the
> stuff that other people have written and has been tossed (e.g. Genera,
> Smalltalk, NextSTEP). Rather than wringing our hands about how
> unappreciated we are I think it's much more productive to start from the
> premise that there might have been some good reasons all that stuff got
> tossed, to try to understand what those reasons were, and then to take
> those lessons and move on to the next thing.
>
I have my own ideas why things are the way they are. They may be right or
they may be wrong. But I do not concentrate or focus on that. I use Lisp
because it appeals to me. I find it useful and productive. It is not
popular, but if people like me do not even use it, who will? Nor do I view
Lisp (and me) as in a win-lose situation. I do not mind being in the
minority when it comes to programming language choice, I am just trying to
be genuine, who I really am. I am not happy programming in C++. If being
who I am is not enough, then so be it. I have been sincere. Hopefully by
allowing myself to be me, I will allow others to have the courage to be who
they are. The issues go far beyond a simple programming language choice.
The computing story is not over yet, who knows what will happen tommorrow or
20 years down the road? NextSTEP is reborn as Aqua, those who have been
able to make things happen (through shear force of character and will) just
havn't noticed Lisp yet.
Wade
In article <············@news3.cadvision.com>, "Wade Humeniuk"
<········@cadvision.com> wrote:
> The issues go far beyond a simple programming language choice.
Yes!
> The computing story is not over yet, who knows what will happen tommorrow or
> 20 years down the road? NextSTEP is reborn as Aqua, those who have been
> able to make things happen (through shear force of character and will) just
> havn't noticed Lisp yet.
Yes, NextSTEP being "reborn" as Aqua is a good object lesson. I would
like to see Lisp "reborn" in the same way. I think that's the only way
Lisp is going to avoid becoming another COBOL. But to do that it has to
change, and the Lisp community seems to be extraordinarily resistant to
change (which is ironic because it's exactly that same kind of reistance
that often prevents Lisp from getting a fair shake in the rest of the
world). As an example I cite the almost universally negative reaction on
this newsgroup to Paul Graham's attempt to reinvent Lisp as Arc.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> Yes, NextSTEP being "reborn" as Aqua is a good object lesson. I would
> like to see Lisp "reborn" in the same way.
Would you care to explain exactly what this "good object lesson" would
be?
From the perspective of a former customer of NeXT I think this is
quite an overstatement of the facts. The old NeXT did more than its
share of mercilessly screwing customers and peddling some horribly
below-grade products. Quite accordingly, they were spinning around
the drain before Apple saved the day. Macintosh developers'
vociferous demands for a set of interfaces that did not mandate the
OpenStep redux and its Objective-C language should be proof that even
massive amounts of market influence are not going to cause people to
drop everything and flock to your language and class library. I
sincerely fail to see any behavior that I would wish Lisp to emulate.
I think that's the only way
> Lisp is going to avoid becoming another COBOL. But to do that it has to
> change, and the Lisp community seems to be extraordinarily resistant to
> change (which is ironic because it's exactly that same kind of reistance
> that often prevents Lisp from getting a fair shake in the rest of the
> world).
Lisp, like just about anything else, will go places by having people
do things with it. I don't think it's any more complicated than that.
In article <···············@panix3.panix.com>, Carl Shapiro
<········@panix.com> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > Yes, NextSTEP being "reborn" as Aqua is a good object lesson. I would
> > like to see Lisp "reborn" in the same way.
>
> Would you care to explain exactly what this "good object lesson" would
> be?
NextSTEP was dead. Now it (or parts of it) has risen from the ashes. I
believe it was able to do so because Apple said, "Here's OS/X. It's new
and cool." instead of, "Here's NextSTEP again. You stupid gits made a
huge mistake when you rejected it the first time so we're going to give
you another chance to see the error of your ways."
> Lisp, like just about anything else, will go places by having people
> do things with it. I don't think it's any more complicated than that.
How I wish that were true.
E.
"Erann Gat" <···@jpl.nasa.gov> wrote in message
·························@192.168.1.50...
> In article <···············@panix3.panix.com>, Carl Shapiro
> <········@panix.com> wrote:
>
> > ···@jpl.nasa.gov (Erann Gat) writes:
> >
> > > Yes, NextSTEP being "reborn" as Aqua is a good object lesson. I would
> > > like to see Lisp "reborn" in the same way.
> >
> > Would you care to explain exactly what this "good object lesson" would
> > be?
>
> NextSTEP was dead. Now it (or parts of it) has risen from the ashes. I
> believe it was able to do so because Apple said, "Here's OS/X. It's new
> and cool." instead of, "Here's NextSTEP again. You stupid gits made a
> huge mistake when you rejected it the first time so we're going to give
> you another chance to see the error of your ways."
>
I think the lesson with NextSTEP is that it had Steve Jobs. Whose single
minded and forceful approach, alienating managers and executives with "do it
my way" did the job. Steve kept at it, kept his focus, EVEN, when he became
CEO of Apple. He thought he was right and did not let others disaud him.
Is he right? Many think so, hardly any of his bosses did.
The same goes for Bill Gates and Microsoft, focused, keeping to his view and
not being distracted by alternative ways. The point is that it does not
matter if the other ways are better, its that the tools he used were
sufficient to get the job done. Its getting the job done (manifesting the
ideas) which counts when being successful.
I worked for a small company which now is successful (bought by Intel), same
thing, the owner, though aware of alternatives (and backed me in my choice
of using Scheme a scripting/testing language, who had programmed in Lisp)
keep his focus very narrow. This owner had programmed in Lisp, but it was
cellphone software, embedded in C/C++. His comment about Lisp was, "It
would be nice if these language wars were over and they all had the features
of Lisp, instead of re-inventing the wheel.".
Wade
On 1/15/02 20.12, in article ···············@panix3.panix.com, "Carl
Shapiro" <········@panix.com> wrote:
> Lisp, like just about anything else, will go places by having people
> do things with it. I don't think it's any more complicated than that.
Very nicely put.
^L
Erann Gat wrote:
> change, and the Lisp community seems to be extraordinarily resistant to
> change....As an example I cite the almost universally negative reaction on
> this newsgroup to Paul Graham's attempt to reinvent Lisp as Arc.
I don't know about the rest of the universe, but in my case the negative
reaction was a resistance not to change per se but to making a language
worse (or to be precise re Arc, a worse language).
As for not getting a fair shake in the rest of the world, I do not think
the problem is that Lisp is too good, so making it worse probably won't
help.
Me, I am trying to find time to get an open source project going to
develop a Garnet-like Common Lisp GUI. A standard GUI seems to be on a
lot of wish lists.
ie, CL needs to do more /useful/ stuff out of the box, and the Cliki and
CLOCC repositories seem to be efforts in that direction.
But the language is fine, no need to mess with that.
kenny
clinisys
Kenny Tilton <·······@nyc.rr.com> writes:
> Erann Gat wrote:
>> change, and the Lisp community seems to be extraordinarily resistant to
>> change....As an example I cite the almost universally negative reaction on
>> this newsgroup to Paul Graham's attempt to reinvent Lisp as Arc.
>
> I don't know about the rest of the universe, but in my case the negative
> reaction was a resistance not to change per se but to making a language
> worse (or to be precise re Arc, a worse language).
>
> As for not getting a fair shake in the rest of the world, I do not think
> the problem is that Lisp is too good, so making it worse probably won't
> help.
>
> Me, I am trying to find time to get an open source project going to
> develop a Garnet-like Common Lisp GUI. A standard GUI seems to be on a
> lot of wish lists.
>
Haven't you heard of CLIM, and, more specifically, McCLIM? CLIM is
standardized and McCLIM is an implementation which is free software.
Cf. (IIRC) <URL:http://www.mikemac.com/mikemac/McCLIM/>, or if I
misremembered the URL then google for it.
> ie, CL needs to do more /useful/ stuff out of the box, and the Cliki and
> CLOCC repositories seem to be efforts in that direction.
>
> But the language is fine, no need to mess with that.
>
> kenny
> clinisys
--
BPT <···@tunes.org> /"\ ASCII Ribbon Campaign
backronym for Linux: \ / No HTML or RTF in mail
Linux Is Not Unix X No MS-Word in mail
Meme plague ;) ---------> / \ Respect Open Standards
Brian P Templeton wrote:
>
> Haven't you heard of CLIM
Yes, I have. We all discussed it hear a few weeks ago and I got talked
out of it. Want to talk me back in? I am of course open to it, and was
disappointed to hear Bad Things.
For one thing, I would just be using the lower-level layers, and folks
were not raving over those. Apparently the added value is at the higher
levels of functionality.
Right now I am hoping to make OpenGL work as the lowest layer, not sure
if that is viable. Just found a nice ACL/Win port of the Xerox (?)
bindings on Cliki, worked right out of the box.
Lisp and 3d -- lawdy I've died and gone to heaven!
kenny
clinisys
In article <·················@nyc.rr.com>, Kenny Tilton wrote:
>
>
> Right now I am hoping to make OpenGL work as the lowest layer, not sure
> if that is viable. Just found a nice ACL/Win port of the Xerox (?)
> bindings on Cliki, worked right out of the box.
>
> Lisp and 3d -- lawdy I've died and gone to heaven!
Do you mean use OpenGL for the whole thing? While not CL, this reminds me of
a neat app called Blender, which is essentially an entire 3D-modeler done
with an OpenGL interface for all the widgets.
Yes, I am wondering if a portable GUI could be built atop OpenGL. The
value would be a rich, universal (?) graphics layer. A bonus would be
some very sick 3d widgets.
Of course when I say universal, uh, each Lisp environment would need the
FFI to OpenGL. Anyway...
Looks like OpenGL whiffed on font handling for some reason, but I see
some OpenGL TrueType projects out there. I see key events, mouse
events... maybe I'll head over to the relevant OpenGL forums and see if
at least the hardcorians think I am crazy.
Come to think of it, combined with Cells (they are brilliant for
modelling) we might make CL into a nice game development platform.
This is my strength, btw, finding neat little projects one can toss off
in five to ten years. Well, I guess that is why we have open source
projects.
:)
kenny
clinisys
Tim Lavoie wrote:
>
> In article <·················@nyc.rr.com>, Kenny Tilton wrote:
> >
> >
> > Right now I am hoping to make OpenGL work as the lowest layer, not sure
> > if that is viable. Just found a nice ACL/Win port of the Xerox (?)
> > bindings on Cliki, worked right out of the box.
> >
> > Lisp and 3d -- lawdy I've died and gone to heaven!
>
> Do you mean use OpenGL for the whole thing? While not CL, this reminds me of
> a neat app called Blender, which is essentially an entire 3D-modeler done
> with an OpenGL interface for all the widgets.
Kenny Tilton <·······@nyc.rr.com> writes:
>
> Come to think of it, combined with Cells (they are brilliant for
> modelling) we might make CL into a nice game development platform.
I made some binding from CMUCL to the SDL (www.libsdl.org) and have
been thoroughly enjoying myself with "The Computational Beauty of
Nature" ( http://mitpress.mit.edu/books/FLAOH/cbnhtml/ ).
Coming from a demo-scene / games background, I have been looking for
ways to use Lisp in that area and the SDL is quite good and usable
(for me at least, being used to game-programmer's code ;-).
However, I haven't done enough work on and with the bindings yet to
say something definitive about SDL + Lisp.
It's preaching to the choir here ofcourse, but the dynamic nature of
Lisp really adds to the playability of an development environment.
cheers,
Erik.
--
"We're born with a number of powerful instincts, which are found across all
cultures. Chief amongst these are a dislike of snakes, a fear of falling,
and a hatred of popup windows" --Vlatko Juric-Kokic
On Thu, Jan 17, 2002 at 04:16:18PM +0100, Erik Winkels wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
> >
> > Come to think of it, combined with Cells (they are brilliant for
> > modelling) we might make CL into a nice game development platform.
>
> I made some binding from CMUCL to the SDL (www.libsdl.org) and have
> been thoroughly enjoying myself with "The Computational Beauty of
> Nature" ( http://mitpress.mit.edu/books/FLAOH/cbnhtml/ ).
I would be very interested to see these bindings, if you are willing
to release them. I attempted to make some a while back and continually
received segmentation violations after drawing about 72 pixels.
>
> Coming from a demo-scene / games background, I have been looking for
> ways to use Lisp in that area and the SDL is quite good and usable
> (for me at least, being used to game-programmer's code ;-).
>
> However, I haven't done enough work on and with the bindings yet to
> say something definitive about SDL + Lisp.
>
> It's preaching to the choir here ofcourse, but the dynamic nature of
> Lisp really adds to the playability of an development environment.
>
>
--
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Matthew Danish email: ·······@andrew.cmu.edu ;;
;; OpenPGP public key available from: 'finger ···@db.debian.org' ;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
In article <··············@xs4all.nl>, Erik Winkels wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>>
>> Come to think of it, combined with Cells (they are brilliant for
>> modelling) we might make CL into a nice game development platform.
>
> I made some binding from CMUCL to the SDL (www.libsdl.org) and have
> been thoroughly enjoying myself with "The Computational Beauty of
> Nature" ( http://mitpress.mit.edu/books/FLAOH/cbnhtml/ ).
>
> Coming from a demo-scene / games background, I have been looking for
> ways to use Lisp in that area and the SDL is quite good and usable
> (for me at least, being used to game-programmer's code ;-).
>
> However, I haven't done enough work on and with the bindings yet to
> say something definitive about SDL + Lisp.
>
> It's preaching to the choir here ofcourse, but the dynamic nature of
> Lisp really adds to the playability of an development environment.
Cool! Is there something that we can look at yet? I have and drool over the
same book myself, and have just started tinkering with using CLX
(lower-level than I want), or PostScript (non-interactive) with the same
thing in mind. I've only read a little about SDL, but it sounded like it
might fit really well.
Cheers,
Tim
--
"Experience is simply the name we give our mistakes."
--Oscar Wilde
Tim Lavoie <········@spamcop.net> writes:
> Cool! Is there something that we can look at yet? I have and drool over the
> same book myself, and have just started tinkering with using CLX
> (lower-level than I want), or PostScript (non-interactive) with the same
> thing in mind.
Did you mean PostScript from within Lisp, or did you mean that PS
itself is not interactive? If you meant the latter, well, you're
wrong, it is :) It's not a great development environment, but you to
in fact get a toplevel. Try typing into gs for a while.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Tim Lavoie <········@spamcop.net> writes:
>
[Lisp->SDL bindings]
> Cool! Is there something that we can look at yet?
Sure, but I don't have a website to put things at the moment. I can
either zip up the directory and send it to you or post the bindings
here. It's not much code, someone with experience in the CMUCL FFI
could do it in an hour or so.. probably less, but it took me somewhat
longer due to my inexperience :-)
> I've only read a little about SDL, but it sounded like it might fit
> really well.
It does. The availability of all sorts of add-on libraries is also
interesting, though I haven't actually checked the quality of them
yet.
Erik Winkels <·······@xs4all.nl> writes:
> Tim Lavoie <········@spamcop.net> writes:
> >
> [Lisp->SDL bindings]
> > Cool! Is there something that we can look at yet?
>
> Sure, but I don't have a website to put things at the moment. I can
> either zip up the directory and send it to you or post the bindings
> here. It's not much code, someone with experience in the CMUCL FFI
> could do it in an hour or so.. probably less, but it took me somewhat
> longer due to my inexperience :-)
What about making it LGPL and starting out a Sourceforge project?
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th 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'.
From: Erik Winkels
Subject: Re: SDL CMUCL bindings (Re: The true faith)
Date:
Message-ID: <87d708shbm.fsf@xs4all.nl>
Hi,
Marco Antoniotti <·······@cs.nyu.edu> writes:
> Erik Winkels <·······@xs4all.nl> writes:
> >
> > [...] but I don't have a website to put things at the moment. I
> > can either zip up the directory and send it to you or post the
> > bindings here. It's not much code, [...]
>
> What about making it LGPL and starting out a Sourceforge project?
It's so little code that I've mailed it to the people who have
requested it. They're free to do whatever they like to do with it.
(Including starting a SF project ;-)
Thanks for you interest though.
Erik.
--
. . . A phrase that expresses a notion so beautiful that the mind can't even
hope to wrap itself around it. The phrase is: "My brother-in-law, the bar
owner." -J.D. Baldwin, monk
Erik Winkels <·······@xs4all.nl> writes:
> Hi,
>
> Marco Antoniotti <·······@cs.nyu.edu> writes:
> > Erik Winkels <·······@xs4all.nl> writes:
> > >
> > > [...] but I don't have a website to put things at the moment. I
> > > can either zip up the directory and send it to you or post the
> > > bindings here. It's not much code, [...]
> >
> > What about making it LGPL and starting out a Sourceforge project?
>
> It's so little code that I've mailed it to the people who have
> requested it. They're free to do whatever they like to do with it.
> (Including starting a SF project ;-)
>
> Thanks for you interest though.
You are welcome.
I think that even if it is very little code, it is still worthwhile to
make it "public" (for an appropriate definition of "public") and easy
to find. Note that also having a note about CL on the SDL page is a
good thing.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th 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'.
From: Erik Winkels
Subject: Re: SDL CMUCL bindings (Re: The true faith)
Date:
Message-ID: <87ofjrx3j3.fsf@xs4all.nl>
Marco Antoniotti <·······@cs.nyu.edu> writes:
>
> I think that even if it is very little code, it is still worthwhile
> to make it "public" (for an appropriate definition of "public") and
> easy to find.
That is certainly true. I'll have a personal page up again in the
near future.
> Note that also having a note about CL on the SDL page is a
> good thing.
I'm not sure about that. I frankly wouldn't dare having the bindings
as they are now on the SDL page, for fear of giving CL a bad name.
However, once they have matured somewhat it would certainly be a good
thing to have CL up on the SDL page among the other languages like
Perl, Python, Ruby, etc. (see http://www.libsdl.org/languages.html )
It would be an excellent start for a young and budding hacker to
explore Lisp. Playing with graphics and sounds directly from the
prompt would be quite different from the usual "compile, make, run" C
experience.
Erik.
--
One man's theology is another man's belly laugh.
Marco Antoniotti <·······@cs.nyu.edu> writes:
> I think that even if it is very little code, it is still worthwhile to
> make it "public" (for an appropriate definition of "public") and easy
> to find.
I eventually did decide to make it "official" :-)
The project is still in the startup phase, but for those who want to
take a look already: http://cl-sdl.sourceforge.net/
> Note that also having a note about CL on the SDL page is a good
> thing.
A note has been sent to the webmaster of that site.
cheers,
Erik.
--
"Ah, fall - when leaves turn to burnished colors upon darkling branches,
collars are turned up against a wind which murmurs of winter, and homework
assignments appear on Usenet. <sigh>" -- Bob Jarvis
Erik Winkels wrote:
>
> Kenny Tilton <·······@nyc.rr.com> writes:
> >
> > Come to think of it, combined with Cells (they are brilliant for
> > modelling) we might make CL into a nice game development platform.
>
> I made some binding from CMUCL to the SDL (www.libsdl.org)
cool, audioa and video also from Lisp. woo-hoo! and I am fascinated to
see they also punt a little on text and fonts.
> and have
> been thoroughly enjoying myself with "The Computational Beauty of
> Nature" ( http://mitpress.mit.edu/books/FLAOH/cbnhtml/ ).
My first 3D project will be to model soap films. i am interested to see
if I can algorithmically come up with some of the more nonintuitive
ones.
>
> Coming from a demo-scene / games background, I have been looking for
> ways to use Lisp in that area and the SDL is quite good and usable
> (for me at least, being used to game-programmer's code ;-).
yeah, i got a little learning curve ahead of me on OpenGL I am afraid.
kenny
clinisys
Kenny Tilton <·······@nyc.rr.com> writes:
>
> My first 3D project will be to model soap films.
Soap as in "Dallas", "Dynasty", etc.?
> yeah, i got a little learning curve ahead of me on OpenGL I am
> afraid.
Lots of fun though!
I don't know where you are on the curve but if in case you are still
at the beginning: http://www.libsdl.org/opengl/intro.html
I found this tutorial very helpful, but I'm a learn by seeing source
code person.
cheers,
Erik.
"Kenny Tilton" <·······@nyc.rr.com> wrote
...
> Come to think of it, combined with Cells (they are brilliant for
> modelling) we might make CL into a nice game development platform.
I'm not really making games, as I find that writing programs to solve real
problems is more fun, but I have been doing this (OpenGL and CLOS
constraints) for several years now.
Have a look at http://www.fractalconcept.com/asp/html/softscan.html
(warning: it's a slow 128K connection)
It's 100% Lisp (+ VHDL for the really hard real time data acquisition part
(ns times)) The graphics are in OpenGL and all the dialog boxes (more than
150) are generated from the CLOS classes. It even has constraints as "Cells"
though not in the same way. Here is an example of how it looks: (the part
like Cells is the interface-rules section)
(def-class transducer ()
((trademark :content-type string :user-name #T"trademark")
(serial-number :content-type string :indexed t :user-name #T"serial
number")
(frequency :content-type float :user-name #T"frequency" :unit "MHz"
:initform 5.0)
(shape :content-type number :initform :circular :user-name #T"shape"
:initform :circular
:choices (bis:make-choice-list #T"Circular" :circular #T"Rectangular"
:rectangular)
(diameter :content-type float :user-name #T"diameter" :unit "mm")
(rect-length :content-type float :user-name #T"length" :unit "mm"
:default-disable (:ashape))
(rect-width :content-type float :user-name #T"width" :unit "mm"
:default-disable (:ashape))
(focal-length :content-type float :user-name #T"focal length" :unit
"mm"))
:guid #x0257f1e0aab711d19a9000c095ed76a0
:user-name #T"transducer"
:interface-rules '(("shape == :circular" "enable(diameter, :ashape),
disable(rect_length, :ashape), disable(rect_width, :ashape), rect_length =
0.0, rect_width = 0.0")
("shape == :rectangular" "disable(diameter, :ashape),
enable(rect_length, :ashape), enable(rect_width, :ashape), diameter = 0.0")
("(focal_length < 10.0) or (focal_length > 250.0)" "error")
("(frequency < 0.5) or (frequency > 25.0)" "error")
("(diameter < 10.0) or (diameter > 35.0)" "error")
("(rect_length < 10.0) or (rect_length > 35.0)" "error")
("(rect_width < 10.0) or (rect_width > 35.0)" "error")))
Marc
Marc Battyani wrote:
>
> "Kenny Tilton" <·······@nyc.rr.com> wrote
> ...
> > Come to think of it, combined with Cells (they are brilliant for
> > modelling) we might make CL into a nice game development platform.
>
> I'm not really making games, as I find that writing programs to solve real
> problems is more fun,
absolutely.
> but I have been doing this (OpenGL and CLOS
> constraints) for several years now.
cool. but i can't make out--are you using OpenGL for all imaging or just
the 3d models?
kenny
clinisys
"Kenny Tilton" <·······@nyc.rr.com> wrote
...
> > but I have been doing this (OpenGL and CLOS
> > constraints) for several years now.
>
> cool. but i can't make out--are you using OpenGL for all imaging or just
> the 3d models?
Only for the 3d. The dialogs are dynamically created using Win32 calls.
Marc
In article <·················@nyc.rr.com>, Kenny Tilton wrote:
> Yes, I am wondering if a portable GUI could be built atop OpenGL. The
> value would be a rich, universal (?) graphics layer. A bonus would be
> some very sick 3d widgets.
Apparently so. Blender (http://www.blender.nl) runs on Windows, Linux, IRIX,
Solaris (I think), with the exact same interface. That interface *IS* a
little daunting mind you, but that's the app, not OpenGL.
--
"Experience is simply the name we give our mistakes."
--Oscar Wilde
Kenny Tilton <·······@nyc.rr.com> writes:
> Brian P Templeton wrote:
>>
>> Haven't you heard of CLIM
>
> Yes, I have. We all discussed it hear a few weeks ago and I got talked
> out of it. Want to talk me back in? I am of course open to it, and was
> disappointed to hear Bad Things.
>
It appears that someone is working on an OpenGL backed for McCLIM.
> For one thing, I would just be using the lower-level layers, and folks
> were not raving over those. Apparently the added value is at the higher
> levels of functionality.
>
> Right now I am hoping to make OpenGL work as the lowest layer, not sure
> if that is viable. Just found a nice ACL/Win port of the Xerox (?)
> bindings on Cliki, worked right out of the box.
>
> Lisp and 3d -- lawdy I've died and gone to heaven!
>
> kenny
> clinisys
--
BPT <···@tunes.org> /"\ ASCII Ribbon Campaign
backronym for Linux: \ / No HTML or RTF in mail
Linux Is Not Unix X No MS-Word in mail
Meme plague ;) ---------> / \ Respect Open Standards
On Tue, 15 Jan 2002, Erann Gat wrote:
[snip]
> Yes, NextSTEP being "reborn" as Aqua is a good object lesson. I would
> like to see Lisp "reborn" in the same way.
Being bought out by a big comp, maintaing most of the core code and
features and adding a lot of stuff on top of it while having experimenting
with abandoning core, but decidedly minority tech (e.g., ObjectiveC for
C++ and then Java), and lost a lot of time with it reaching a compromise
where lots of your best stuff is still done with your minority tech?
How about we skip a few steps :)
(The above is simplified, but it *is* important. There *are* a lot of
lessons to be learned from that revival.)
> I think that's the only way
> Lisp is going to avoid becoming another COBOL. But to do that it has to
> change, and the Lisp community seems to be extraordinarily resistant to
> change
Well, certain sorts of change, yes. That seems sensible to me.
On the Squeak list there's a thread about how we should get some Java big
mo by moving to Java (specified in vague terms). It seems clear to me that
this would kill Squeak, certainly for me. One example I raised is how
Squeak has a some alternative syntaxes including a graphical "tile" based
one (mainly for kids). The nice thing about these is that they're exactly
congruent -- learning one really helps for the others because they're
notational varients. I don't see a fun way to do this for Java, *just*
because Java syntax is so complex. This is a tangible loss for people
researching about kids, education, and computing.
So change, when it can cost millions of dollers and disrupt delicate
synergies, needs to be approached sensible. And that means resisting some
of it.
> (which is ironic because it's exactly that same kind of reistance
> that often prevents Lisp from getting a fair shake in the rest of the
> world). As an example I cite the almost universally negative reaction on
> this newsgroup to Paul Graham's attempt to reinvent Lisp as Arc.
Again, this seems like an ill chosen example. Arc doesn't change Lisp, it
tosses it and starts from scratch. Lot's of folks have done that, with
varying interest and success. (And geez, one of the supposed appeals of
Arc will be its huge, and currently nonexistent, libraries.)
It even seems that Graham has gone out of his way to make it inaccessible
to most folks who don't commit altogether. As folks pointed out, he could
layer it on top of commen lisp, and seek points of congruence and
integration.
So, FWIW, I'm *really* curious how "abandon all your code, tools, tech,
books etc. and embrace a new, barely started language design which doesn't
include all sorts of things for whose sake you chose to brave the cold of
being a lisper in a hostile world" is a rationally appeally "change" to
Lisp, or that it even holds out promise for getting Lisp adopted widely.
It would be great if you could elaborate on the details of how these
examples support your views, and what we should be learning from
them. Just pointing at them seems, well, unhelpful and vague.
Cheers,
Bijan Parsia.
In article
<··········································@login9.isis.unc.edu>, Bijan
Parsia <·······@email.unc.edu> wrote:
> So change, when it can cost millions of dollers and disrupt delicate
> synergies, needs to be approached sensible. And that means resisting some
> of it.
Agreed. But when was the last time *anything* major in Common Lisp changed?
> It would be great if you could elaborate on the details of how these
> examples support your views, and what we should be learning from
> them. Just pointing at them seems, well, unhelpful and vague.
The point I was trying to support with the Aqua example was that I think
Lisp needs to reinvent itself, and that part of a successful reinvention
is marketing it as something new, and putting on enough new window
dressing to make it appear new to cursory inspection, even if it really
isn't new at all. The rest of the world keeps reinventing Lisp badly; the
Lisp shorld reinvent Lisp and do it right. That's what I see Paul trying
to do with Arc. And while Arc may not be perfect, at least he's trying.
E.
Erann Gat wrote:
> Lisp needs to reinvent itself, and that part of a successful reinvention
> is marketing it as something new, and putting on enough new window
> dressing to make it appear new to cursory inspection, even if it really
> isn't new at all.
I think /you/ need to take a rest and pass the Lisp advocacy torch onto
some fresh legs, you have certainly run a good leg for the team and
deserve a break.
The Lisp crowd needs to stop all this Python-envy and moaning and
groaning about being unpopular and just do good stuff with Lisp. If the
language is so great, go develop something with it and make money like
Graham did (and like CliniSys is trying to do).
Did infix help Dylan? No. Did Python try to be popular? No. It does not
work that way, we can't just look at popular things and copy them and
expect to be popular, too.
otoh if Arc takes off I retract all this.
:)
kenny
clinisys
In article <·················@nyc.rr.com>, Kenny Tilton
<·······@nyc.rr.com> wrote:
> I think /you/ need to take a rest and pass the Lisp advocacy torch onto
> some fresh legs,
I thought that's what I was doing.
BTW, word has reached me through the grapevine that I have given people
the impression that I have "abandoned" Lisp. That's not quite right. I
am no longer using Lisp (at the moment), but so say that I've abandoned it
is kind of like saying that someone who has lost a custody battle has
abandoned their child.
E.
Erann Gat wrote:
>
> In article <·················@nyc.rr.com>, Kenny Tilton
> <·······@nyc.rr.com> wrote:
>
> > I think /you/ need to take a rest and pass the Lisp advocacy torch onto
> > some fresh legs,
>
> I thought that's what I was doing.
Touche!
But to be fair, it is one thing to retire from the battle, another to
suggest we all lay down our arms, run up the other team's flag, spike
our cannons, yada yada..
kenny
clinisys
In article <·················@nyc.rr.com>, Kenny Tilton
<·······@nyc.rr.com> wrote:
> Erann Gat wrote:
> >
> > In article <·················@nyc.rr.com>, Kenny Tilton
> > <·······@nyc.rr.com> wrote:
> >
> > > I think /you/ need to take a rest and pass the Lisp advocacy torch onto
> > > some fresh legs,
> >
> > I thought that's what I was doing.
>
> Touche!
>
> But to be fair, it is one thing to retire from the battle, another to
> suggest we all lay down our arms, run up the other team's flag, spike
> our cannons, yada yada..
Excuse me? I have suggested no such things. I have suggested (to
continue your metaphor) that we have some things to learn by studying the
other team's battle plans and perhaps even by adopting some of their
tactics. I have also suggested that some of our weapons, while they might
have been the state of the art ten years ago, are now a bit dated and
rusty and that we should launch a new round of defense spending.
I'll also suggest that casting the situtation as a military conflict might
not be the most fruitful choice of metaphor.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> In article <·················@nyc.rr.com>, Kenny Tilton
> <·······@nyc.rr.com> wrote:
>
>> Erann Gat wrote:
>> >
>> > In article <·················@nyc.rr.com>, Kenny Tilton
>> > <·······@nyc.rr.com> wrote:
>> >
>> > > I think /you/ need to take a rest and pass the Lisp advocacy torch onto
>> > > some fresh legs,
>> >
>> > I thought that's what I was doing.
>>
>> Touche!
>>
>> But to be fair, it is one thing to retire from the battle, another to
>> suggest we all lay down our arms, run up the other team's flag, spike
>> our cannons, yada yada..
>
> Excuse me? I have suggested no such things. I have suggested (to
> continue your metaphor) that we have some things to learn by studying the
> other team's battle plans and perhaps even by adopting some of their
> tactics. I have also suggested that some of our weapons, while they might
> have been the state of the art ten years ago, are now a bit dated and
> rusty and that we should launch a new round of defense spending.
>
> I'll also suggest that casting the situtation as a military conflict might
> not be the most fruitful choice of metaphor.
>
Heh. Good point, Erann Scipio Africanus^W^WGat.
:)
> E.
--
BPT <···@tunes.org> /"\ ASCII Ribbon Campaign
backronym for Linux: \ / No HTML or RTF in mail
Linux Is Not Unix X No MS-Word in mail
Meme plague ;) ---------> / \ Respect Open Standards
···@jpl.nasa.gov (Erann Gat) writes:
> In article
> <··········································@login9.isis.unc.edu>, Bijan
> Parsia <·······@email.unc.edu> wrote:
>
> > So change, when it can cost millions of dollers and disrupt delicate
> > synergies, needs to be approached sensible. And that means resisting some
> > of it.
>
> Agreed. But when was the last time *anything* major in Common Lisp changed?
Nothing major has changed in ANSI Common Lisp, since probably about
1990-91. And that is a _very good_ thing. I'm sorry, but change is
not a priori better than constancy, quite the contrary. Every change
has associated costs (including the cost of associated risks), which
have to be surpassed measurably by the expected profit.
I don't see how major changes to the base language will give us
anything worth the huge cost.
If you look at languages that have had major (or even constant minor)
changes to their base language definition, you will see that few of
them are really being used for serious projects. The work-horses of
the industry are languages which haven't had major changes to their
base language definition, like e.g. C.
AFAICT, all the things people are clamoring for can be done as
additions to the base language.
> The point I was trying to support with the Aqua example was that I think
> Lisp needs to reinvent itself, and that part of a successful reinvention
> is marketing it as something new, and putting on enough new window
> dressing to make it appear new to cursory inspection, even if it really
> isn't new at all. The rest of the world keeps reinventing Lisp badly; the
> Lisp shorld reinvent Lisp and do it right. That's what I see Paul trying
> to do with Arc. And while Arc may not be perfect, at least he's trying.
It doesn't work that way. Mac OS X will succeed, _not_ because
Next/Apple was clever enough to dress it up as something new[1], but
for the fundamental reason that Mac OS X is heavily backed by Apple,
since it is the only OS that will be supported by new Apple hardware.
Solaris succeeded for the same reasons, even against heavy user
opposition (similarly to Mac OS X).
CL does not now, nor likely will in the near future have any kind of
backer of the given magnitude and influence. Just renaming (or even
reinventing) CL will just result in losing your old base, without
gaining a sufficiently new one. I'm sorry, but I think Dylan really
demonstrated that very clearly. If Apple hadn't abandoned Dylan, but
pushed it in the same way that Objective-C is now "pushed", and if
Dylan had reacted a bit more to the appearance of Java, I think Dylan
would have stood a chance at becoming popular. It would have had an
influential backer, some momentum, a fairly well-defined and largish
target audience, and yes, it had the new window dressing.
Dylan didn't succeed at becoming popular, and I predict it never will
grow out of being a niche language (like CL, Scheme, the functional
crowd, etc.), and it will probably never surpass CL in popularity.
Why would Arc (or any other attempt at "reinventing" CL, which usually
just means throwing out stuff the designer personally doesn't like),
which doesn't even start with an influential backer, fare any better?
Regs, Pierre.
Footnotes:
[1] That was a necessary, but far from sufficient step, and really
a minor marketing trick only.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
In article <··············@orion.bln.pmsf.de>, "Pierre R. Mai"
<····@acm.org> wrote:
> Nothing major has changed in ANSI Common Lisp, since probably about
> 1990-91. And that is a _very good_ thing. I'm sorry, but change is
> not a priori better than constancy, quite the contrary.
Yes, that's true, but so is the reverse: constancy is not a priori better
than change. It depends on what is constant and what is changing.
> I don't see how major changes to the base language will give us
> anything worth the huge cost.
Backwards-compatible changes don't necessarily incur a huge cost.
> If you look at languages that have had major (or even constant minor)
> changes to their base language definition, you will see that few of
> them are really being used for serious projects. The work-horses of
> the industry are languages which haven't had major changes to their
> base language definition, like e.g. C.
I'd say just the opposite is true. C has undergone at least two rounds of
major changes in its history (from K&R C to ANSI C, then it went from ANSI
C to C++, and arguably from C++ to C++ + STL). I believe these changes
have been a major factor in its success. Java has also undergone at least
one round of major changes to the base language in its short history.
Python makes major changes constantly. (They recently added lexical
closures.) I don't know about Perl, but I suspect the same is true for
it.
> It doesn't work that way. Mac OS X will succeed, _not_ because
> Next/Apple was clever enough to dress it up as something new[1],
You go on to make my response for me:
> [1] That was a necessary, but far from sufficient step, and really
> a minor marketing trick only.
I completely agree with footnote 1. It's necessary, but not sufficient.
But it's necessary.
> Why would Arc (or any other attempt at "reinventing" CL, which usually
> just means throwing out stuff the designer personally doesn't like),
> which doesn't even start with an influential backer, fare any better?
Because there are existence proofs that corporate backing is *not*
necessary for a new language to succeed. In fact, of the languages that
dominate the landscape today (C, Perl and Java) only one (Java) did so as
a result of a major corporate marketing push. So while having a big
marketing machine on your side may help, it is neither necessary nor
sufficient.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> In article <··············@orion.bln.pmsf.de>, "Pierre R. Mai"
> <····@acm.org> wrote:
>
> > Nothing major has changed in ANSI Common Lisp, since probably about
> > 1990-91. And that is a _very good_ thing. I'm sorry, but change is
> > not a priori better than constancy, quite the contrary.
>
> Yes, that's true, but so is the reverse: constancy is not a priori better
> than change. It depends on what is constant and what is changing.
If changing and staying constant have the same overall benefits, then
constancy wins. Change is _very_ expensive. See evolution, which is
only succesful, because it can expend lots of individual population
members.
> > I don't see how major changes to the base language will give us
> > anything worth the huge cost.
>
> Backwards-compatible changes don't necessarily incur a huge cost.
Complete agreement. That's why adding layered standards is something
I can get enthusiastic about. Reinventing the language (like in Arc)
is not.
The only problem is coming up with resources for such activities.
Things like Arc don't seem to me to be helping any.
> > If you look at languages that have had major (or even constant minor)
> > changes to their base language definition, you will see that few of
> > them are really being used for serious projects. The work-horses of
> > the industry are languages which haven't had major changes to their
> > base language definition, like e.g. C.
>
> I'd say just the opposite is true. C has undergone at least two rounds of
> major changes in its history (from K&R C to ANSI C, then it went from ANSI
> C to C++, and arguably from C++ to C++ + STL). I believe these changes
C did undergo _one_ major change, namely the transition from (several
variants of) K&R C to ANSI C, in the 80s, at huge cost, even though
most of K&R C can still be used portably in ANSI C. Since then it
has provided an increasingly stable platform for serious work, which
is one of the reasons that C is still one of the major work-horses of
the industry.
C++ is a completely different language, which has suffered to a
non-neglible degree from being non-constant for long stretches of its
existence. It is only now starting to begin to mature. Likewise,
many C++ projects are more or less experimental in nature, something
that is only slowly changing. It is thanks to the existence of a
fairly stable and mature "kernel language" (more or Cfront 2.0 maybe
plus exceptions) since ca. 1990, that C++ has been usable in projects
during the 90s.
> have been a major factor in its success. Java has also undergone at least
I don't. I think they have been negative factors in and of
themselves. They have (at least in the case of C) certainly resulted
in better languages in the end, which contributes to their _continued_
success, but they had to be successful enough _before_ they could
invest some of that into changing their base languages.
> one round of major changes to the base language in its short history.
Java is hampered to a very large degree by the fact that there are in
effect at least 3 currently used languages out there under the name of
Java, which are not really compatible. Java currently lives off its
hype, with people choosing Java for not completely technical reasons,
similarly to e.g. Smalltalk, C++ at the start of the OOP boom, or Lisp
during the AI hype. There are tons of projects that got suckered into
using Java, which have since abandoned it in favor of C++ or even C.
It has yet to be seen whether Java can survive the hype phase and turn
into a mature _and_ popular language, or not.
> Python makes major changes constantly. (They recently added lexical
Python is also a niche language. Remember Tcl?
> closures.) I don't know about Perl, but I suspect the same is true for
> it.
Perl is somewhat of a special case. While it has undergone lots of
incompatible changes, it has survived to this day, with nearly
unabating popularity. Don't know what this indicates.
> > It doesn't work that way. Mac OS X will succeed, _not_ because
> > Next/Apple was clever enough to dress it up as something new[1],
>
> You go on to make my response for me:
>
> > [1] That was a necessary, but far from sufficient step, and really
> > a minor marketing trick only.
>
> I completely agree with footnote 1. It's necessary, but not sufficient.
> But it's necessary.
But _first_ you have to have covered the sufficient stuff, because
you'll have to have your new user-base in place, when you abandon your
old one, or you'll just whither and die. So if anything, people
shouldn't be working on reinventing CL, they should be working on
finding influential backers first. Next/Jobs was clever enough to
reverse buy Apple, before they renamed their OS. Otherwise they'd be
dead by now.
> > Why would Arc (or any other attempt at "reinventing" CL, which usually
> > just means throwing out stuff the designer personally doesn't like),
> > which doesn't even start with an influential backer, fare any better?
>
> Because there are existence proofs that corporate backing is *not*
> necessary for a new language to succeed. In fact, of the languages that
An influential "backer" is necessary, it doesn't have to be commercial.
> dominate the landscape today (C, Perl and Java) only one (Java) did so as
> a result of a major corporate marketing push. So while having a big
Noone has said anything about marketing. C succeeded because of
Unix. People really wanted Unix (uniform OS across hardware
platforms), and C was the API language of choice. Again Perl is
somewhat special, but again Unix had a very large role to play in the
creation and adoption of Perl.
C++ was more of a roots effort, but it already had C in place, which
together with the OOP boom gained lots of early adopters. But I'd say
that C++ would be dead by now had not several platform providers
adopted it as their API language of choice (Microsoft and Apple among
them).
> marketing machine on your side may help, it is neither necessary nor
> sufficient.
Correct, influential backing doesn't mean a marketing machine, it
means a continued investment into the language, and a strategic
adoption as a platform. Of the languages you mention, only Perl
stands out as not having any official backer.
I'm still unconvinced that Arc is a better idea than Dylan (quite the
contrary).
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
In article <··············@orion.bln.pmsf.de>, "Pierre R. Mai"
<····@acm.org> wrote:
> If changing and staying constant have the same overall benefits, then
> constancy wins. Change is _very_ expensive.
No, I disagree. Change is not necessarily expensive. Some kinds of
changes are expensive, but not all. Also, in this case IMO the benefit of
(perceived) change would be significant.
> > Backwards-compatible changes don't necessarily incur a huge cost.
>
> Complete agreement. That's why adding layered standards is something
> I can get enthusiastic about. Reinventing the language (like in Arc)
> is not.
How about adding layered standards *and* giving the result a new name?
> The only problem is coming up with resources for such activities.
> Things like Arc don't seem to me to be helping any.
No, I don't think resources are the problem. Make a good business case
for the activity and the resources will come.
> C++ is a completely different language,
How "completely" different it is is a matter of perception, which is
precisely my point. On the one hand, C++ is similar enough to C that a
C++ compiler will compile nearly all C code, and people who are already
comfortable with C can ease more gently into C++ than they can into, say,
Lisp or ML. On the other hand, C++ is different enough from C that it is
impossible for someone who *doesn't* like C to simply dismiss C++ because
it's just like C. (Of course, they can still dismiss it for other
reasons.) Many people today dismiss Lisp because they think Lisp == Lisp
1.5. A new name would say to the world, "Look, this is not your
grandfather's Lisp. This is something new and different and you ought to
spend some time looking into it." Labels matter.
> Perl is somewhat of a special case. While it has undergone lots of
> incompatible changes, it has survived to this day, with nearly
> unabating popularity. Don't know what this indicates.
Me neither. But it does prove that stability and corporate backing (or
even sanity) are not prerequisites to success.
> An influential "backer" is necessary, it doesn't have to be commercial.
Yes. Now, who might serve as a non-commercial influential backer?
> I'm still unconvinced that Arc is a better idea than Dylan (quite the
> contrary).
I'm not convinced of that either. Different is not necessarily better,
but better is necessarily different. Of that I am convinced.
E.
"Erann Gat" <···@jpl.nasa.gov> wrote in message
·························@eglaptop.jpl.nasa.gov...
>
> How "completely" different it is is a matter of perception, which is
> precisely my point. On the one hand, C++ is similar enough to C that a
> C++ compiler will compile nearly all C code, and people who are already
> comfortable with C can ease more gently into C++ than they can into, say,
> Lisp or ML. On the other hand, C++ is different enough from C that it is
> impossible for someone who *doesn't* like C to simply dismiss C++ because
> it's just like C. (Of course, they can still dismiss it for other
> reasons.) Many people today dismiss Lisp because they think Lisp == Lisp
> 1.5. A new name would say to the world, "Look, this is not your
> grandfather's Lisp. This is something new and different and you ought to
> spend some time looking into it." Labels matter.
Any suggestion on a new name? I personally like Lisp (the label). It has
history.
Just for fun here is a list of things that came to my mind.
Lips as in (the parens look like lips)
Lexp as in Lisp Expression
L as in skipping ahead from C
Lx shortenting Lexp. Might as well take a hint from Arc.
Boa as in making fun of python (code also looks like a coiled boa)
Boomerang, my personal favorite, throw that exception! Maybe it will catch
on down-under, eh?
Wade
In article <············@news3.cadvision.com>, "Wade Humeniuk"
<········@cadvision.com> wrote:
> Any suggestion on a new name? I personally like Lisp (the label). It has
> history.
I like it too. But I'm not the target audience.
> Just for fun here is a list of things that came to my mind.
>
> Lips as in (the parens look like lips)
Too silly.
> Lexp as in Lisp Expression
Too hard to pronounce.
> L as in skipping ahead from C
Already taken by Rod Brooks (L is a subset of Common Lisp for programming
robots)
> Lx shortenting Lexp. Might as well take a hint from Arc.
Not bad.
> Boa as in making fun of python (code also looks like a coiled boa)
I like this one.
> Boomerang, my personal favorite, throw that exception! Maybe it will catch
> on down-under, eh?
I like that too.
E.
Come on! Let's just use the short hand `CL'!
It has a 'C' in the name and it sheds the `Lisp' altogether :)
Variation: C+L, C#L, you name it :)
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th 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'.
I have it!
Ciel
That's French for sky as in the sky is the limit, and it is pronounced
see-ell, aka CL.
kenny
clinisys
Marco Antoniotti wrote:
>
> Come on! Let's just use the short hand `CL'!
>
> It has a 'C' in the name and it sheds the `Lisp' altogether :)
>
> Variation: C+L, C#L, you name it :)
>
> Cheers
>
> --
> Marco Antoniotti ========================================================
> NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
> 719 Broadway 12th 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'.
In article <·················@nyc.rr.com>, Kenny Tilton
<·······@nyc.rr.com> wrote:
> I have it!
>
> Ciel
>
>
> That's French for sky as in the sky is the limit, and it is pronounced
> see-ell, aka CL.
I like it!
Now comes the hard part: designing it.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> In article <·················@nyc.rr.com>, Kenny Tilton
> <·······@nyc.rr.com> wrote:
>
> > I have it!
> >
> > Ciel
> >
> >
> > That's French for sky as in the sky is the limit, and it is pronounced
> > see-ell, aka CL.
>
> I like it!
>
> Now comes the hard part: designing it.
Oh, Come on.
Since you did not put any smileys, I'll assume that you are serious :)
I like the name, but I do not think that designing from scratch a new
language will buy you anything. Dylan is there to show you exactly
that.
Now. Let's take one of the desiderata that have been floating around.
(let ((a (make-array 100)))
(setf (a 42) 42)
(a 42))
=> 42
or
(let ((a (make-hash-table)))
(setf (a 42) 42)
(a 42))
=> 42
Now, AFAIK, *no* other language conflates the above. Either you have
a[42]
or
a{42}
Can you "extend" CL (or Ciel) to achieve something similar without (a)
compromising the base language, maybe at the cost of changing the
implementations?
I believe you can. You can write a specification for a new operator
called REF, akin to FUNCALL, so that the above becomes
(let ((a (make-array 100)))
(setf (ref a 42) 42)
(ref a 42))
=> 42
or
(let ((a (make-hash-table)))
(setf (ref a 42) 42)
(ref a 42))
=> 42
As you know, you can write REF in CL (Ciel) itself. Now the trick is
to (a) provide a reference implementation and (b) have the
implementors delve deeply in their code so that REF is optimized away
whenever possible.
The same reasoning aplies to a lot of other CL (Ciel) "missing
features". You name it.
E.g. sealed classes. The solution is very easy. Define an extension
to DEFCLASS.
(defclass something (....)
(....)
(:sealed t))
Bottom line: I do not believe that defining a new language buys you
anything.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th 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'.
In article <···············@octagon.mrl.nyu.edu>, Marco Antoniotti
<·······@cs.nyu.edu> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > In article <·················@nyc.rr.com>, Kenny Tilton
> > <·······@nyc.rr.com> wrote:
> >
> > > I have it!
> > >
> > > Ciel
> > >
> > >
> > > That's French for sky as in the sky is the limit, and it is pronounced
> > > see-ell, aka CL.
> >
> > I like it!
> >
> > Now comes the hard part: designing it.
>
> Oh, Come on.
>
> Since you did not put any smileys, I'll assume that you are serious :)
I'm serious that designing Ciel is going to be a lot harder than naming it.
> I like the name, but I do not think that designing from scratch a new
> language will buy you anything. Dylan is there to show you exactly
> that.
Who said anything about designing a new language from scratch? But the
Dylan experience is a serious warning, and your point is well taken.
I should reiterate: the reason I want a new langauge is not that I don't
like Common Lisp; I do. The reason I want a new langauge is that *other*
people that I have to work with don't like Common Lisp. I have tried to
change their minds and I have failed. So that leaves me with only three
options: 1) change jobs, 2) use C++ or 3) try something new. Actually, it
doesn't have to *be* new, it just has to *look* new. A new name is a
first step, necessary, but far from sufficient.
(Actually, I already tried option 1 and that didn't work either, which is
what started this whole thread of discussion if you recall.)
If I actually dive into this project (and I'm not sure if I am going to or
not) my intention would surely be to produce an initial reference
implementation in Common Lisp and retain as much of CL semantics as I can.
> You can write a specification for a new operator
> called REF, akin to FUNCALL, so that the above becomes
Yes, ref is a fine solution, except that...
> As you know, you can write REF in CL (Ciel) itself. Now the trick is
> to (a) provide a reference implementation and (b) have the
> implementors delve deeply in their code so that REF is optimized away
> whenever possible.
It's part (b) that seems like the tricky part, particularly since I'm not
actually a CL customer at the moment, which leaves me with very little
leverage with vendors.
> The same reasoning aplies to a lot of other CL (Ciel) "missing
> features". You name it.
>
> E.g. sealed classes. The solution is very easy. Define an extension
> to DEFCLASS.
>
> (defclass something (....)
> (....)
> (:sealed t))
I don't think this is that simple. The whole point of sealing a class is
not to simply mark it as sealed, but to enable a whole slew of compiler
optimizations that are not possible when things can be dynamically
redefined.
E.
In article <·················@nyc.rr.com>, Kenny Tilton
<·······@nyc.rr.com> wrote:
> > > >
> > > > I have it!
> > > >
> > > > Ciel
> > > >
> > > >
> > > > That's French for sky as in the sky is the limit, and it is pronounced
> > > > see-ell, aka CL.
Oooh. I'm currently working on a system that compiles "CL-80". "-80"
because I'm not fooling myself into thinking I'll get 100% of CL
anytime too soon (although it does have lots of extensions that don't
break CL compatibility). Eventually I hope it'll become CL-100 :). I
might need to change its name to "Ciel 80", I like that. It'll still
be abbreviated as CL-80 (and package "CL80") for reasons of it not
being worth introducing bugs over :)
···@jpl.nasa.gov (Erann Gat) writes:
>
> If I actually dive into this project (and I'm not sure if I am going to or
> not) my intention would surely be to produce an initial reference
> implementation in Common Lisp and retain as much of CL semantics as I can.
I (obviously) agree here. Hopefully CL-80, after maturing through use
in its intended domain[*] will be spun off into a general-purpose CL
implementation. Don't hold your breath, though (I say this
timeframe-wise).
In article <···············@octagon.mrl.nyu.edu>, Marco Antoniotti
<·······@cs.nyu.edu> wrote:
> >
> > You can write a specification for a new operator
> > called REF, akin to FUNCALL, so that the above becomes
Heh, my REF actually is FUNCALL when its first argument is a function.
> Yes, ref is a fine solution, except that...
>
> > As you know, you can write REF in CL (Ciel) itself. Now the trick is
> > to (a) provide a reference implementation and (b) have the
> > implementors delve deeply in their code so that REF is optimized away
> > whenever possible.
>
> It's part (b) that seems like the tricky part, particularly since I'm not
> actually a CL customer at the moment, which leaves me with very little
> leverage with vendors.
It's actually not that hard. You can even probably do it yourself.
In CMUCL, for example, you can get the type information you need at
compile time in a compiler macro. To be specific, for this:
(defun simple-array-zeroth (thing)
(declare (type (simple-array fixnum) thing))
(ref thing 0))
a compiler macro gets the type information you need to transform that
REF into an AREF. Incidentally, CL-80 contains the generic funtion
CL80:REF, which is properly optimized based on static type
information. Okay, I admit that at the moment it does almost squat
with types, but that'll change as the application programmers notice
case by case :). On the other hand, CL-80-on-CMUCL does this quite
nicely.
> > The same reasoning aplies to a lot of other CL (Ciel) "missing
> > features". You name it.
Kent Pitman said that he had his language extensions collected into a
library that he (I think) was planning on eventually selling. It'll
be interesting to see the documentation. I'm also going to be
interested in how the CL-80 extensions turn out. I'm trying my
damnedest to keep them well-organized and cohesive to form a nice
language. Its direction will be largely dictated by the needs of the
application (kind of an odd one) and the application programmers
(generally non-Lispers, C++ [not C] types).
> > E.g. sealed classes. The solution is very easy. Define an extension
> > to DEFCLASS.
> >
> > (defclass something (....)
> > (....)
> > (:sealed t))
>
> I don't think this is that simple. The whole point of sealing a class is
> not to simply mark it as sealed, but to enable a whole slew of compiler
> optimizations that are not possible when things can be dynamically
> redefined.
Ew. One problem with talking about layering good stuff on top of CL
is that we aren't going to agree on what stuff is good. I just say
"no", Nancy Reagan style, to sealing. I say "hells yeah" to
cmucl-style compilation blocks, though, which can buy a similar family
of optimizations.
[*] "in its intended domain". *sigh*. Sorry about that annoying
vague wording. I try to avoid saying crap like that, but in this case
I couldn't help it.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@jpl.nasa.gov (Erann Gat) writes:
[ Only commenting singular points, since I think I've made my opinion
on this whole approach fairly clear. ]
> If I actually dive into this project (and I'm not sure if I am going to or
> not) my intention would surely be to produce an initial reference
> implementation in Common Lisp and retain as much of CL semantics as I can.
Who cares what the language is implemented in? I think we agree that
the (computer) world would be a slightly better place if customers
stopped obsessing about the languages used in implementing something,
and started caring about the properties of the resulting software,
like e.g. cost, reliability, extendability, ...
Unless of course you plan to make the new language embedded in CL in
such a way that CL users can escape to the full language. Though I
fail to see how this is going to improve Ciel's chances of adoption.
> > You can write a specification for a new operator
> > called REF, akin to FUNCALL, so that the above becomes
>
> Yes, ref is a fine solution, except that...
>
> > As you know, you can write REF in CL (Ciel) itself. Now the trick is
> > to (a) provide a reference implementation and (b) have the
> > implementors delve deeply in their code so that REF is optimized away
> > whenever possible.
>
> It's part (b) that seems like the tricky part, particularly since I'm not
> actually a CL customer at the moment, which leaves me with very little
> leverage with vendors.
You could of course get lots of users to adopt your change, which
would create the leverage. Furthermore, for most implementations you
can use implementation defined accessors to e.g. type data to write
your own compiler-macros that do the necessary optimization.
All of that seems incredibly easier to do than designing a whole new
language, writing a complete, optimizing reference implementation,
getting lots of new users, and convincing N vendors to create new from
scratch implementations for that language.
> > E.g. sealed classes. The solution is very easy. Define an extension
> > to DEFCLASS.
> >
> > (defclass something (....)
> > (....)
> > (:sealed t))
>
> I don't think this is that simple. The whole point of sealing a class is
> not to simply mark it as sealed, but to enable a whole slew of compiler
> optimizations that are not possible when things can be dynamically
> redefined.
Again, writing a useful definition for that feature, and doing a
reference implementation of it in e.g. CMUCL/PCL[1] is all that's
needed, IMHO. If people really find this useful, they'll talk to
their vendors about implementing the feature. Especially when there
is a well-written definition, and the feature is not too invasive, I'm
fairly certain that vendors will be more than happy to adopt it.
To repeat: all of that is incredibly cheaper, and more effective than
creating a whole new language infrastructure from scratch.
Regs, Pierre.
Footnotes:
[1] CMU CL itself already has similar sealing declarations for its
own type/class system, but that is not really integrated with CMU
CL's PCL-descendant CLOS, and hence is mostly used to optimize
type-checking.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
In article <····················@eglaptop.jpl.nasa.gov>,
···@jpl.nasa.gov (Erann Gat) wrote:
> Who said anything about designing a new language from scratch? But the
> Dylan experience is a serious warning, and your point is well taken.
>
> I should reiterate: the reason I want a new langauge is not that I don't
> like Common Lisp; I do. The reason I want a new langauge is that *other*
> people that I have to work with don't like Common Lisp.
And have these people heard of Dylan?
-- Bruce
Staying technical.
···@jpl.nasa.gov (Erann Gat) writes:
> In article <···············@octagon.mrl.nyu.edu>, Marco Antoniotti
> <·······@cs.nyu.edu> wrote:
>
...
> > You can write a specification for a new operator
> > called REF, akin to FUNCALL, so that the above becomes
>
> Yes, ref is a fine solution, except that...
>
> > As you know, you can write REF in CL (Ciel) itself. Now the trick is
> > to (a) provide a reference implementation and (b) have the
> > implementors delve deeply in their code so that REF is optimized away
> > whenever possible.
>
> It's part (b) that seems like the tricky part, particularly since I'm not
> actually a CL customer at the moment, which leaves me with very little
> leverage with vendors.
The point is that IMHO, things got done in CL whenever a "reference
implementation" was at hand. CLX is such a beast. CLIM is a negative
example. Now every UN*X CL has CLX and some have added some
efficiency tricks to the implementation.
Moreover note that your statement above is self defeating. Since you
are somewhat admitting not to have any "financial muscle" at your
hand, how do you expect to define ex-novo a language, if you cannot
even try to influence a CL vendor?
Anyway, here is a REF implementation. I am sure you can optimize the
hell out of it, given a minimum knowlegde of the argument types.
==============================================================================
;;; -*- Mode: Lisp -*-
;;; Marco Antoniotti, 2002
;;; This code is in the public domain.
;;; No warranty of any kind whatsoever implied or stated.
;;;
;;; Do not even think of pulling an Azzeccagarbugli trick on this! :)
(defpackage "CL.EXT.REF" (:use "COMMON-LISP")
(:nicknames "REF")
(:export "REF"))
(in-package "CL.EXT.REF")
(declaim (inline ref))
(defun ref (item &rest arguments &aux (args-len (length arguments)))
(etypecase item
(array
(assert (plusp args-len))
(apply #'aref item arguments))
(hash-table
(assert (<= 1 args-len 2))
(gethash (first arguments) item (second arguments)))))
(defun (setf ref) (value item
&rest arguments
&aux (args-len (length arguments)))
(etypecase item
(array
(assert (plusp args-len))
(setf (row-major-aref item
(apply #'array-row-major-index item arguments))
value))
(hash-table
(assert (= 1 args-len))
(setf (gethash (first arguments) item) value))))
;;; end of file -- ref.lisp --
==============================================================================
> > The same reasoning aplies to a lot of other CL (Ciel) "missing
> > features". You name it.
> >
> > E.g. sealed classes. The solution is very easy. Define an extension
> > to DEFCLASS.
> >
> > (defclass something (....)
> > (....)
> > (:sealed t))
>
> I don't think this is that simple. The whole point of sealing a class is
> not to simply mark it as sealed, but to enable a whole slew of compiler
> optimizations that are not possible when things can be dynamically
> redefined.
Yes. I know. But my point is that you want a common way of specifying
this so that your code is portable *and* you can expect to have some
implementor take up the task of actually doing the optimization. The
Dylan experience can be taken as a reference. They have developed
some of the linguistic tools that are needed to extend CL. It is my
opinion that all that energy would have been much better spent in
improving CL, but it is useless to weep over spilt milk.
Going back to :sealed, I would simply like that all the CL
implementations would change their definition of DEFCLASS so that the
:sealed option is at least *ignored*. I do not care if it is actually
used or not. The CL user is accustomed at having implementations with
a wide spread of performance.
To reiterate with a different example, I believe that in recent times
one of the best service done to the CL community as a whole (for what
the term "community" mean) is Christophe Rhodes' SPLIT-SEQUENCE
definition (also despite the ruckus about the naming). It settled a
matter and it is a good design which is easy to implement and easy to
provide in an implementation.
All in all I am much more for these sort of incremental approach than
with the "let's start from scratch again".
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th 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'.
Marco Antoniotti <·······@cs.nyu.edu> writes:
> Anyway, here is a REF implementation. I am sure you can optimize the
> hell out of it, given a minimum knowlegde of the argument types.
>
> ==============================================================================
> ;;; -*- Mode: Lisp -*-
>
> ;;; Marco Antoniotti, 2002
> ;;; This code is in the public domain.
> ;;; No warranty of any kind whatsoever implied or stated.
> ;;;
> ;;; Do not even think of pulling an Azzeccagarbugli trick on this! :)
>
> (defpackage "CL.EXT.REF" (:use "COMMON-LISP")
> (:nicknames "REF")
> (:export "REF"))
>
> (in-package "CL.EXT.REF")
>
> (declaim (inline ref))
>
> (defun ref (item &rest arguments &aux (args-len (length arguments)))
> (etypecase item
> (array
> (assert (plusp args-len))
> (apply #'aref item arguments))
> (hash-table
> (assert (<= 1 args-len 2))
> (gethash (first arguments) item (second arguments)))))
Yikes, the whole point of the UTILITIES:REF that I use is that it's a
GF. I may as well describe my interface, because I like it:
(defgeneric (thing &rest subscripts)
"If an entry in THING is found for the given subscripts, the first
value that entry, and the second is T. Otherwise,the values are
NIL and NIL.")
I want it to work consistently across THING types. So that the user
can't tell if it was a hash-table, vector, user-defined object, or
what, that was dereferenced. Being able to specify a default value
and whether to raise an error would be nice, but there's nowhere for
those arguments to go. I could use dynamic variables, but I haven't
really felt the need to do that yet, so I suspect the above is good
enough; binding *ref-default* and *ref-errorp* would be no easier than
using multiple-value-bind.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> Marco Antoniotti <·······@cs.nyu.edu> writes:
>
> > Anyway, here is a REF implementation. I am sure you can optimize the
> > hell out of it, given a minimum knowlegde of the argument types.
> >
> > ==============================================================================
> > ;;; -*- Mode: Lisp -*-
> >
> > ;;; Marco Antoniotti, 2002
> > ;;; This code is in the public domain.
> > ;;; No warranty of any kind whatsoever implied or stated.
> > ;;;
> > ;;; Do not even think of pulling an Azzeccagarbugli trick on this! :)
> >
> > (defpackage "CL.EXT.REF" (:use "COMMON-LISP")
> > (:nicknames "REF")
> > (:export "REF"))
> >
> > (in-package "CL.EXT.REF")
> >
> > (declaim (inline ref))
> >
> > (defun ref (item &rest arguments &aux (args-len (length arguments)))
> > (etypecase item
> > (array
> > (assert (plusp args-len))
> > (apply #'aref item arguments))
> > (hash-table
> > (assert (<= 1 args-len 2))
> > (gethash (first arguments) item (second arguments)))))
>
> Yikes,
I scared you? Didn't I? :)
> the whole point of the UTILITIES:REF that I use is that it's a
> GF. I may as well describe my interface, because I like it:
>
> (defgeneric (thing &rest subscripts)
> "If an entry in THING is found for the given subscripts, the first
> value that entry, and the second is T. Otherwise,the values are
> NIL and NIL.")
>
> I want it to work consistently across THING types. So that the user
> can't tell if it was a hash-table, vector, user-defined object, or
> what, that was dereferenced. Being able to specify a default value
> and whether to raise an error would be nice, but there's nowhere for
> those arguments to go.
This specific breaks the nice default provision for GETHASH.
> I could use dynamic variables, but I haven't
> really felt the need to do that yet, so I suspect the above is good
> enough; binding *ref-default* and *ref-errorp* would be no easier than
> using multiple-value-bind.
Well, you can implement it that way. However, this is just for your
implementation. (Nothing wrong with that).
I think it was Pierre that said that improving on an existing base is
more difficult than veering off a tangent (not that I mean you did).
I have no problems in making REF a generic function, as long as you
make provisions to optimize it as much as you, can once you know the
type of the arguments. But, AFAIK, it is easier to optimize a regular
function than a GF. This would make the spreading of REF more uniform
and wider across implementations.
Given the above argument, would you still want a GF? Also given the
abuse of `operator=' that you somtime see in C++ programs? You are in
Berkeley. I remember Lee, the Ptolemy project leader, saying that C++
operator overloading was, in effect, abused in what is now Ptolemy
Classic.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th 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'.
Marco Antoniotti <·······@cs.nyu.edu> writes:
> ···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
> > Yikes,
>
> I scared you? Didn't I? :)
Yep :)
> > the whole point of the UTILITIES:REF that I use is that it's a
> > GF. I may as well describe my interface, because I like it:
> >
> > (defgeneric (thing &rest subscripts)
> > "If an entry in THING is found for the given subscripts, the first
> > value that entry, and the second is T. Otherwise,the values are
> > NIL and NIL.")
> >
> > I want it to work consistently across THING types. So that the user
> > can't tell if it was a hash-table, vector, user-defined object, or
> > what, that was dereferenced. Being able to specify a default value
> > and whether to raise an error would be nice, but there's nowhere for
> > those arguments to go.
>
> This specific breaks the nice default provision for GETHASH.
Well, it doesn't break it, it just doesn't provide it. It's the
happiest medium I could find between AREF and GETHASH. And it is
supposed to be a bit more like AREF... If I can supply a default for a
hash table, I want to be able to do the same for an array. Otherwise
I'm not sure I see the point of using REF instead of just AREF or
GETHASH directly.
> > I could use dynamic variables, but I haven't
> > really felt the need to do that yet, so I suspect the above is good
> > enough; binding *ref-default* and *ref-errorp* would be no easier than
> > using multiple-value-bind.
>
> Well, you can implement it that way. However, this is just for your
> implementation. (Nothing wrong with that).
>
> I think it was Pierre that said that improving on an existing base is
> more difficult than veering off a tangent (not that I mean you did).
Indeed, that's the hard part of this GF.
> I have no problems in making REF a generic function, as long as you
> make provisions to optimize it as much as you, can once you know the
> type of the arguments. But, AFAIK, it is easier to optimize a regular
> function than a GF. This would make the spreading of REF more uniform
> and wider across implementations.
>
> Given the above argument, would you still want a GF?
Absolutely. The whole point is to dereference in a type-agnostic
manner. If it costs performance, so be it. In CMUCL, though, you can
define transforms for known types, and if type inference can figure
out what type you're dereferencing, you don't call the GF. Besides,
I'm not arguing that we toss GETHASH, AREF, etc.
> Also given the abuse of `operator=' that you somtime see in C++
> programs? You are in Berkeley. I remember Lee, the Ptolemy project
> leader, saying that C++ operator overloading was, in effect, abused
> in what is now Ptolemy Classic.
I don't like overloading. I think my spec for REF is a generic
function, though. Actually, I think your version engages in
overloading. If I do:
(defun foo (thing)
(ref thing 3 4))
(foo *some-array*)
(foo *some-hash-table*)
The second argument to REF has very different semantics. That's the
point of (at least my) REF -- to allow changing the data structure
without having to rewrite all the consumers. I've changed 4
widely-used data structures in the compiler I'm working on so far, and
I was very glad I'd used REF.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Thomas Burdick wrote:
[Marco Antoniotti:]
> > I have no problems in making REF a generic function, as long as you
> > make provisions to optimize it as much as you, can once you know the
> > type of the arguments. But, AFAIK, it is easier to optimize a regular
> > function than a GF. This would make the spreading of REF more uniform
> > and wider across implementations.
> >
> > Given the above argument, would you still want a GF?
[Thomas:]
> Absolutely. The whole point is to dereference in a type-agnostic
> manner. If it costs performance, so be it. In CMUCL, though, you can
> define transforms for known types, and if type inference can figure
> out what type you're dereferencing, you don't call the GF. Besides,
> I'm not arguing that we toss GETHASH, AREF, etc.
For what it's worth, I'm with Thomas on this one. And I
suspect (though I haven't done the research -- looking at
how GETHASH is used in practice on a large variety of
programs -- to check) that for most purposes it would
be enough to make the default an attribute of the
hash table, not of the access.
In other words, imagine that you could say
(let ((h (make-hash-table :default "walrus")))
;; ... do some work on H ...
(multiple-value-bind (result foundp) (gethash 123 h)
;; here RESULT will be "walrus" if 123 wasn't
;; a key in the hash table, and FOUNDP will be NIL.
) )
I conjecture that this mechanism would usually be sufficient.
Of course, standard CL hash tables don't have it, but if
we could define our own kind of hash tables and have everything
work with them, it could easily be arranged. :-)
--
Gareth McCaughan ················@pobox.com
.sig under construc
················@pobox.com (Gareth McCaughan) writes:
> Thomas Burdick wrote:
>
> [Marco Antoniotti:]
> > > I have no problems in making REF a generic function, as long as you
> > > make provisions to optimize it as much as you, can once you know the
> > > type of the arguments. But, AFAIK, it is easier to optimize a regular
> > > function than a GF. This would make the spreading of REF more uniform
> > > and wider across implementations.
> > >
> > > Given the above argument, would you still want a GF?
>
> [Thomas:]
> > Absolutely. The whole point is to dereference in a type-agnostic
> > manner. If it costs performance, so be it. In CMUCL, though, you can
> > define transforms for known types, and if type inference can figure
> > out what type you're dereferencing, you don't call the GF. Besides,
> > I'm not arguing that we toss GETHASH, AREF, etc.
>
> For what it's worth, I'm with Thomas on this one. And I
> suspect (though I haven't done the research -- looking at
> how GETHASH is used in practice on a large variety of
> programs -- to check) that for most purposes it would
> be enough to make the default an attribute of the
> hash table, not of the access.
>
> In other words, imagine that you could say
>
> (let ((h (make-hash-table :default "walrus")))
> ;; ... do some work on H ...
> (multiple-value-bind (result foundp) (gethash 123 h)
> ;; here RESULT will be "walrus" if 123 wasn't
> ;; a key in the hash table, and FOUNDP will be NIL.
> ) )
>
> I conjecture that this mechanism would usually be sufficient.
> Of course, standard CL hash tables don't have it, but if
> we could define our own kind of hash tables and have everything
> work with them, it could easily be arranged. :-)
Well, this may be sufficient, but it has the disadvantage to hide the
use from the definition.
Given the above discussion, I think that TRT would be to make REF a
special operator as SETF and friends. This will introduce a nice
symmetry in the language. Of course, now things get really hairy, but
let's take this as an exercise.
The concrete syntax of REF becomes something like
(defmacro ref (item (&rest indexes-or-keys)
&key default
&allow-other-keys) ...)
So that for an 1D array A1
(ref a1 3) == (aref a1 3)
for a 2D array A2
(ref a2 (3 4)) == (aref a2 3 4)
for an hash-table HT
(ref ht 'key) == (gethash 'key ht)
again
(ref ht 'key :default 4) == (gethash 'key ht 4)
the nice thing is that for a `place' X
(ref X) == X
which in CL it can be argued to be just right, except maybe for
(ref (values 1 2 3 4)).
for an instance I of class C, say (defclass C () ((s :accessor s-of)))
(ref I 's) == (slot-value I 's)
but then for a hairy data structure HDT indexed by strings....
(ref hdt ("string1" "s2" "s3") :default 123)
Of course this means that adding "methods" to the REF special-operator
will have to work like for SETF. Hence you will need to add
DEFINE-REF-EXPANDER
GET-REF-EXPANDER
DEFREF
(the list is a suggestion) as special forms used to define new REF
forms.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th 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'.
Marco Antoniotti <·······@cs.nyu.edu> writes:
> Given the above discussion, I think that TRT would be to make REF a
> special operator as SETF and friends. This will introduce a nice
> symmetry in the language. Of course, now things get really hairy, but
> let's take this as an exercise.
>
> The concrete syntax of REF becomes something like
>
> (defmacro ref (item (&rest indexes-or-keys)
> &key default
> &allow-other-keys) ...)
>
>
> So that for an 1D array A1
>
> (ref a1 3) == (aref a1 3)
>
> for a 2D array A2
>
> (ref a2 (3 4)) == (aref a2 3 4)
I just posted something similar, and made a dismissive comment about
it, but I think I like this take on it. There's one dereferencing
position, and it can be either a subscript or a list of subscripts. I
think I'd want the position to be evaluated [so your second example
would be (ref a2 '(3 4)) ].
> for an hash-table HT
>
> (ref ht 'key) == (gethash 'key ht)
>
> again
>
> (ref ht 'key :default 4) == (gethash 'key ht 4)
>
> the nice thing is that for a `place' X
>
> (ref X) == X
>
> which in CL it can be argued to be just right, except maybe for
> (ref (values 1 2 3 4)).
>
> for an instance I of class C, say (defclass C () ((s :accessor s-of)))
>
> (ref I 's) == (slot-value I 's)
I actually don't like this as a default behavior. As a report from
the field, I've already caught one bug because an error was raised by
trying to REF an object that wasn't REF'able. If all classes were
REF'able by default, this would have bitten me later. It's pretty
easy to make a ref-mixin class. In fact, you could even do
(defref some-class slot-value)
> but then for a hairy data structure HDT indexed by strings....
>
> (ref hdt ("string1" "s2" "s3") :default 123)
>
> Of course this means that adding "methods" to the REF special-operator
> will have to work like for SETF. Hence you will need to add
>
> DEFINE-REF-EXPANDER
> GET-REF-EXPANDER
> DEFREF
>
> (the list is a suggestion) as special forms used to define new REF
> forms.
Ooh, I like. I think I'll rewrite (*sigh*) my REF implementation this
weekend, if I have time, and see what I think of this.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: Christophe Rhodes
Subject: Re: REF as a special operator (Re: Ciel (was: Re: The true faith))
Date:
Message-ID: <sqsn8wouje.fsf@cam.ac.uk>
···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> Marco Antoniotti <·······@cs.nyu.edu> writes:
>
> > Given the above discussion, I think that TRT would be to make REF a
> > special operator as SETF and friends. This will introduce a nice
> > symmetry in the language. Of course, now things get really hairy, but
> > let's take this as an exercise.
> >
> > The concrete syntax of REF becomes something like
> >
> > (defmacro ref (item (&rest indexes-or-keys)
> > &key default
> > &allow-other-keys) ...)
> >
> > [ snippage ]
> >
> > Of course this means that adding "methods" to the REF special-operator
> > will have to work like for SETF. Hence you will need to add
> >
> > DEFINE-REF-EXPANDER
> > GET-REF-EXPANDER
> > DEFREF
> >
> > (the list is a suggestion) as special forms used to define new REF
> > forms.
>
> Ooh, I like. I think I'll rewrite (*sigh*) my REF implementation this
> weekend, if I have time, and see what I think of this.
Note that you can't trivially write ref as a macro, as it will need to
dispatch on the run-time type of its item argument. Or you can, but it
will need to expand to a run-time typcaseish kind of thing, won't it?
Christophe
--
Jesus College, Cambridge, CB5 8BL +44 1223 510 299
http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)
From: Marco Antoniotti
Subject: Re: REF as a special operator (Re: Ciel (was: Re: The true faith))
Date:
Message-ID: <y6cr8ofahr6.fsf@octagon.mrl.nyu.edu>
Christophe Rhodes <·····@cam.ac.uk> writes:
> ···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
> > Marco Antoniotti <·······@cs.nyu.edu> writes:
> >
> > > Given the above discussion, I think that TRT would be to make REF a
> > > special operator as SETF and friends. This will introduce a nice
> > > symmetry in the language. Of course, now things get really hairy, but
> > > let's take this as an exercise.
> > >
> > > The concrete syntax of REF becomes something like
> > >
> > > (defmacro ref (item (&rest indexes-or-keys)
> > > &key default
> > > &allow-other-keys) ...)
> > >
> > > [ snippage ]
> > >
> > > Of course this means that adding "methods" to the REF special-operator
> > > will have to work like for SETF. Hence you will need to add
> > >
> > > DEFINE-REF-EXPANDER
> > > GET-REF-EXPANDER
> > > DEFREF
> > >
> > > (the list is a suggestion) as special forms used to define new REF
> > > forms.
> >
> > Ooh, I like. I think I'll rewrite (*sigh*) my REF implementation this
> > weekend, if I have time, and see what I think of this.
>
> Note that you can't trivially write ref as a macro, as it will need to
> dispatch on the run-time type of its item argument. Or you can, but it
> will need to expand to a run-time typcaseish kind of thing, won't it?
I think the challenge would be to write up a more complete spec for
REF, keeping in mind that (1) you want to be able to write as a macro
to start with, and (2) eventually you will want to make it a `special
operator'. You really need the `type checking' at run-time and
compile-time only when you have (2).
Ciao
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th 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'.
In article <···············@famine.OCF.Berkeley.EDU>,
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) wrote:
> > This specific breaks the nice default provision for GETHASH.
>
> Well, it doesn't break it, it just doesn't provide it. It's the
> happiest medium I could find between AREF and GETHASH. And it is
> supposed to be a bit more like AREF... If I can supply a default for a
> hash table, I want to be able to do the same for an array. Otherwise
> I'm not sure I see the point of using REF instead of just AREF or
> GETHASH directly.
Once again, Dylan's "element" works on every type of collection, and
allows a default value if the element can't be found. The default
applies just as much to sequences (arrays, lists, strings) as to hashes
-- the key of a sequence is an integer specifying the index of the item
to be returned, and the default value is returned if the index is out of
bounds.
-- Bruce
Bruce Hoult <·····@hoult.org> writes:
> In article <···············@famine.OCF.Berkeley.EDU>,
> ···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) wrote:
>
> > > This specific breaks the nice default provision for GETHASH.
> >
> > Well, it doesn't break it, it just doesn't provide it. It's the
> > happiest medium I could find between AREF and GETHASH. And it is
> > supposed to be a bit more like AREF... If I can supply a default for a
> > hash table, I want to be able to do the same for an array. Otherwise
> > I'm not sure I see the point of using REF instead of just AREF or
> > GETHASH directly.
>
> Once again, Dylan's "element" works on every type of collection, and
> allows a default value if the element can't be found. The default
> applies just as much to sequences (arrays, lists, strings) as to hashes
> -- the key of a sequence is an integer specifying the index of the item
> to be returned, and the default value is returned if the index is out of
> bounds.
How does that work syntactically? Infix and sexp?
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
In article <···············@conquest.OCF.Berkeley.EDU>,
···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) wrote:
> Bruce Hoult <·····@hoult.org> writes:
>
> > In article <···············@famine.OCF.Berkeley.EDU>,
> > ···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) wrote:
> >
> > > > This specific breaks the nice default provision for GETHASH.
> > >
> > > Well, it doesn't break it, it just doesn't provide it. It's the
> > > happiest medium I could find between AREF and GETHASH. And it is
> > > supposed to be a bit more like AREF... If I can supply a default for
> > > a
> > > hash table, I want to be able to do the same for an array. Otherwise
> > > I'm not sure I see the point of using REF instead of just AREF or
> > > GETHASH directly.
> >
> > Once again, Dylan's "element" works on every type of collection, and
> > allows a default value if the element can't be found. The default
> > applies just as much to sequences (arrays, lists, strings) as to hashes
> > -- the key of a sequence is an integer specifying the index of the item
> > to be returned, and the default value is returned if the index is out
> > of
> > bounds.
>
> How does that work syntactically? Infix and sexp?
You can use function call syntax and have the choice to specify a
default, or use [] and put up with getting an exception if the key is
not found.
let foo = element(collection, key);
let foo = element(collection, key, default: expression);
let foo = collection[key];
-- Bruce
Bruce Hoult <·····@hoult.org> writes:
> In article <···············@conquest.OCF.Berkeley.EDU>,
> ···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) wrote:
>
> > Bruce Hoult <·····@hoult.org> writes:
> >
> > > In article <···············@famine.OCF.Berkeley.EDU>,
> > > ···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) wrote:
> > >
> > > > > This specific breaks the nice default provision for GETHASH.
> > > >
> > > > Well, it doesn't break it, it just doesn't provide it. It's the
> > > > happiest medium I could find between AREF and GETHASH. And it is
> > > > supposed to be a bit more like AREF... If I can supply a default for
> > > > a
> > > > hash table, I want to be able to do the same for an array. Otherwise
> > > > I'm not sure I see the point of using REF instead of just AREF or
> > > > GETHASH directly.
> > >
> > > Once again, Dylan's "element" works on every type of collection, and
> > > allows a default value if the element can't be found. The default
> > > applies just as much to sequences (arrays, lists, strings) as to hashes
> > > -- the key of a sequence is an integer specifying the index of the item
> > > to be returned, and the default value is returned if the index is out
> > > of
> > > bounds.
> >
> > How does that work syntactically? Infix and sexp?
>
> You can use function call syntax and have the choice to specify a
> default, or use [] and put up with getting an exception if the key is
> not found.
>
> let foo = element(collection, key);
> let foo = element(collection, key, default: expression);
> let foo = collection[key];
Oh. So this doesn't work for multi-dimensional arrays? Because the
reason I don't have a default argument in my REF is that I want to be
able to do:
let foo = thing[1][2][3];
Which I would think would be:
let foo = element(thing, 1, 2, 3);
So could I do:
let foo = element(thing, 1, 2, 3, default: -1);
If so that seems kinda odd. But even so, that's not really an option
for CL, because odd-numbered rest arguments and keywords don't mix...
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
In article <···············@conquest.OCF.Berkeley.EDU>,
···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) wrote:
> > You can use function call syntax and have the choice to specify a
> > default, or use [] and put up with getting an exception if the key is
> > not found.
> >
> > let foo = element(collection, key);
> > let foo = element(collection, key, default: expression);
> > let foo = collection[key];
>
> Oh. So this doesn't work for multi-dimensional arrays? Because the
> reason I don't have a default argument in my REF is that I want to be
> able to do:
>
> let foo = thing[1][2][3];
>
> Which I would think would be:
>
> let foo = element(thing, 1, 2, 3);
>
> So could I do:
>
> let foo = element(thing, 1, 2, 3, default: -1);
>
> If so that seems kinda odd. But even so, that's not really an option
> for CL, because odd-numbered rest arguments and keywords don't mix...
If you use element() on a multidimensional array, it still takes a
single argument, which specifies the element using row-major order. If
you want to access an element using the cartesian coordinates of the
element then you use...
aref(array, #rest indices)
This doesn't have a default value. If you need one you could do:
element(array, row-major-index(array, #rest indices), default: exp);
I don't know that this is terribly elegant, but that's the way it
works...
-- Bruce
Bruce Hoult <·····@hoult.org> writes:
> In article <···············@conquest.OCF.Berkeley.EDU>,
> ···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) wrote:
>
> > > You can use function call syntax and have the choice to specify a
> > > default, or use [] and put up with getting an exception if the key is
> > > not found.
> > >
> > > let foo = element(collection, key);
> > > let foo = element(collection, key, default: expression);
> > > let foo = collection[key];
> >
> > Oh. So this doesn't work for multi-dimensional arrays? Because the
> > reason I don't have a default argument in my REF is that I want to be
> > able to do:
> >
> > let foo = thing[1][2][3];
> >
> > Which I would think would be:
> >
> > let foo = element(thing, 1, 2, 3);
> >
> > So could I do:
> >
> > let foo = element(thing, 1, 2, 3, default: -1);
> >
> > If so that seems kinda odd. But even so, that's not really an option
> > for CL, because odd-numbered rest arguments and keywords don't mix...
>
> If you use element() on a multidimensional array, it still takes a
> single argument, which specifies the element using row-major order. If
> you want to access an element using the cartesian coordinates of the
> element then you use...
>
> aref(array, #rest indices)
>
> This doesn't have a default value. If you need one you could do:
>
> element(array, row-major-index(array, #rest indices), default: exp);
>
>
> I don't know that this is terribly elegant, but that's the way it
> works...
Shoot, I was hoping for a magical answer to my dilema :) I guess Dylan
valued having a default argument over supporting multi-dimensional
dereferencing. Given my current usage of REF, I'd say that at least I
personally value multidimensional support over default support. I
guess I could do something like:
(defgeneric ref-function (thing subscripts &key default nil errorp))
(defmacro ref ((thing &rest subscripts) &key ...) ...)
But I think that's worse than the other two options.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@jpl.nasa.gov (Erann Gat) wrote in message news
> I should reiterate: the reason I want a new langauge is not that I don't
> like Common Lisp; I do. The reason I want a new langauge is that *other*
> people that I have to work with don't like Common Lisp. I have tried to
> change their minds and I have failed. So that leaves me with only three
> options: 1) change jobs, 2) use C++ or 3) try something new. Actually, it
> doesn't have to *be* new, it just has to *look* new. A new name is a
> first step, necessary, but far from sufficient.
I honestly think if you wrote a front-end for lisp that more-or-less
compiled a C-like language to lisp, you could popularize it pretty
quickly.
PERL and PYTHON could have been written this way; just imagine if they
had been.
I have thought of trying to make a lisp-like language that's main
purpose would be to retain the lisp goodness, but allow a suite of
code to run a fast as C when optimizations are cranked up.
dave
On 21 Jan 2002, David Hanley wrote:
[snip]
> I honestly think if you wrote a front-end for lisp that more-or-less
> compiled a C-like language to lisp, you could popularize it pretty
> quickly.
>
> PERL and PYTHON could have been written this way; just imagine if they
> had been.
[snip]
This put me to mind of wondering how much compiler optimization research
is done in Common Lisp...in particular for implementations of full blown
compilers. Er..other than for Common Lisp itself, I meant ;)
Does anyone sit around playing with gcc RTL in Common Lisp? Or the like?
Compiling to Scheme and doing optimizations there is fairly standard in
the literature and the mindshare. I would gratefully appreciate any
pointers to similar stuff using Common Lisp.
Cheers,
Bijan Parsia.
On 18 Jan 2002, Marco Antoniotti wrote:
[snip]
> Now. Let's take one of the desiderata that have been floating around.
>
> (let ((a (make-array 100)))
> (setf (a 42) 42)
> (a 42))
>
> => 42
>
> or
>
> (let ((a (make-hash-table)))
> (setf (a 42) 42)
> (a 42))
>
> => 42
>
> Now, AFAIK, *no* other language conflates the above. Either you have
Is the conflation just same syntax for array index and hash key access?
Python:
>>> array = [42]
>>> array[0]
42
>>> dict = {0:42}
>>> dict[0]
42
Smalltalk:
| array | "Declare temporary variable."
array := Array new: 42. "The new array will hold 42 slots."
array at: 42 put: 42.
array at: 42.
Result: 42
---------------
| dictionary |
dictionary := Dictionary new.
dictionary at: 42 put: 42. "You can use integers as keys, just like
Python."
dictionary at: 42.
Result: 42
> a[42]
> or
> a{42}
But perhaps I miss the point.
> Can you "extend" CL (or Ciel) to achieve something similar without (a)
> compromising the base language, maybe at the cost of changing the
> implementations?
>
> I believe you can. You can write a specification for a new operator
> called REF, akin to FUNCALL, so that the above becomes
>
> (let ((a (make-array 100)))
> (setf (ref a 42) 42)
> (ref a 42))
>
> => 42
>
> or
>
> (let ((a (make-hash-table)))
> (setf (ref a 42) 42)
> (ref a 42))
>
> => 42
[snip]
Yes, this is pretty much how Smalltalk works. Note, however, that Python
does provide [] as uniform special syntax.
So it really seems like I've missed *something*.
I do agree with your bottom line, though.
Cheers,
Bijan Parsia.
Bijan Parsia <·······@email.unc.edu> writes:
> On 18 Jan 2002, Marco Antoniotti wrote:
>
> [snip]
> > Now. Let's take one of the desiderata that have been floating around.
> >
> > (let ((a (make-array 100)))
> > (setf (a 42) 42)
> > (a 42))
> >
> > => 42
> >
> > or
> >
> > (let ((a (make-hash-table)))
> > (setf (a 42) 42)
> > (a 42))
> >
> > => 42
> >
> > Now, AFAIK, *no* other language conflates the above. Either you have
>
> Is the conflation just same syntax for array index and hash key access?
>
> Python:
>
> >>> array = [42]
> >>> array[0]
> 42
> >>> dict = {0:42}
> >>> dict[0]
> 42
>
> Smalltalk:
>
> | array | "Declare temporary variable."
> array := Array new: 42. "The new array will hold 42 slots."
> array at: 42 put: 42.
> array at: 42.
>
> Result: 42
>
> ---------------
>
> | dictionary |
> dictionary := Dictionary new.
> dictionary at: 42 put: 42. "You can use integers as keys, just like
> Python."
> dictionary at: 42.
>
> Result: 42
I stand corrected.
> Yes, this is pretty much how Smalltalk works. Note, however, that Python
> does provide [] as uniform special syntax.
>
> So it really seems like I've missed *something*.
You missed my ignorance :) Anyway, in CL you would have to conflate
(1) function calls, (2) array indexing, and (3) hash table indexing.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th 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'.
Marco Antoniotti wrote:
[Bijan Parsia:]
> > Python:
> >
> > >>> array = [42]
> > >>> array[0]
> > 42
> > >>> dict = {0:42}
> > >>> dict[0]
> > 42
...
> > Yes, this is pretty much how Smalltalk works. Note, however, that Python
> > does provide [] as uniform special syntax.
>
> You missed my ignorance :) Anyway, in CL you would have to conflate
> (1) function calls, (2) array indexing, and (3) hash table indexing.
Why #1?
By the way, the good thing about how Python does this isn't
the fact that array access and dict access look the same
but the fact that you can define other datatypes whose
accessors look the same and have everything work with them
that works with arrays and dicts. This is a pervasive
feature of the language: as far as possible, users can
design things that behave just like existing parts of the
language and everything will work with them.
Example: suppose you build a data structure that contains
a sequence of objects, where the underlying representation
is some sort of tree so that you can add and delete stuff
at arbitrary points in the sequence in O(log N) time. This
is pretty easy to do in CL or in Python. If you want to
iterate over these things in CL, you need to write your
own iteration function or macro, or (if you don't mind being
non-portable) define a new loop keyword; or else build a
list or vector out of the data structure any time you want
to iterate over it. In Python, you define either a "getitem
method" or an "iterator method", and then you can just say
for x in my_structure:
do_something_with(x)
exactly as you would for elements of a list. And anything
else that does iteration (list comprehensions, mapping
functions, and so on) will also work immediately with
your new structure.
This is (to my taste, anyway) very elegant, and it's
something you can't easily add to CL. You can design
your own iteration facility which enables this, of course,
but then you're effectively writing in a new dialect
of your own, and most of us are reluctant to do that.
And you'd have to redesign quite a lot: none of the
existing sequence functions are extensible in the right
way, so you'd need to replace them all.
The same goes for numbers, strings, files, functions
and so on. For just about any sort of object there is,
you can define your own objects that can replace it
everywhere. It's very nice.
Of course, it's also very hard to do efficiently. It
would not be easy to compile a language like this as
efficiently as Common Lisp can be compiled. It would,
at the very least, require whole-program analysis.
(This is becoming increasingly feasible these days...)
Still, I'd very much enjoy programming in a Python
with CL-like syntactic extensibility, or a CL with
Python-like semantic extensibility. For that matter,
I very much enjoy programming in Python and CL just
as they are. :-)
--
Gareth McCaughan ················@pobox.com
.sig under construc
················@pobox.com (Gareth McCaughan) writes:
> Marco Antoniotti wrote:
>
> [Bijan Parsia:]
> > > Python:
> > >
> > > >>> array = [42]
> > > >>> array[0]
> > > 42
> > > >>> dict = {0:42}
> > > >>> dict[0]
> > > 42
> ...
> > > Yes, this is pretty much how Smalltalk works. Note, however, that Python
> > > does provide [] as uniform special syntax.
> >
> > You missed my ignorance :) Anyway, in CL you would have to conflate
> > (1) function calls, (2) array indexing, and (3) hash table indexing.
>
> Why #1?
It seems to me that the only thing you can do as far as concrete
syntax goes, is to have
(op a1 a2 a3 ...)
where `op' can be a function, an array or an hash table.
> By the way, the good thing about how Python does this isn't
> the fact that array access and dict access look the same
> but the fact that you can define other datatypes whose
> accessors look the same and have everything work with them
> that works with arrays and dicts. This is a pervasive
> feature of the language: as far as possible, users can
> design things that behave just like existing parts of the
> language and everything will work with them.
>
> Example: suppose you build a data structure that contains
> a sequence of objects, where the underlying representation
> is some sort of tree so that you can add and delete stuff
> at arbitrary points in the sequence in O(log N) time. This
> is pretty easy to do in CL or in Python. If you want to
> iterate over these things in CL, you need to write your
> own iteration function or macro, or (if you don't mind being
> non-portable) define a new loop keyword; or else build a
> list or vector out of the data structure any time you want
> to iterate over it. In Python, you define either a "getitem
> method" or an "iterator method", and then you can just say
>
> for x in my_structure:
> do_something_with(x)
>
> exactly as you would for elements of a list. And anything
> else that does iteration (list comprehensions, mapping
> functions, and so on) will also work immediately with
> your new structure.
>
> This is (to my taste, anyway) very elegant, and it's
> something you can't easily add to CL. You can design
> your own iteration facility which enables this, of course,
> but then you're effectively writing in a new dialect
> of your own, and most of us are reluctant to do that.
> And you'd have to redesign quite a lot: none of the
> existing sequence functions are extensible in the right
> way, so you'd need to replace them all.
Well... I agree with all that you say. But the point is: do we need a
full blown new language to introduce these features, or can "we"
"agree" (quote marks mandatory) to extend the semantics of LOOP with a
new generic keyword
(loop for x coming-from <an-iterator> ...)
(Yes! I like it. Finally an INTERCAL keyword in CL!) plus defining
what an "iterator" should be? We could just take the STL as an
example.
The tricky part is extending LOOP. But LOOP implementations do come
with extensibility hooks.
These are really relatively easy things to do at this day and age.
The problem we face is to make sure that *all* implementations agree
and that we do not have to write ugly conditionals for these
extensions.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th 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'.
Marco Antoniotti wrote:
> > > You missed my ignorance :) Anyway, in CL you would have to conflate
> > > (1) function calls, (2) array indexing, and (3) hash table indexing.
> >
> > Why #1?
>
> It seems to me that the only thing you can do as far as concrete
> syntax goes, is to have
>
> (op a1 a2 a3 ...)
>
> where `op' can be a function, an array or an hash table.
I can't speak for anyone else in this discussion, but I'd
be perfectly happy with (ref thing a1 a2 ...) provided there
were also the appropriate facilities for mapping, looping,
filtering, and so on.
> Well... I agree with all that you say. But the point is: do we need a
> full blown new language to introduce these features, or can "we"
> "agree" (quote marks mandatory) to extend the semantics of LOOP with a
> new generic keyword
>
> (loop for x coming-from <an-iterator> ...)
>
> (Yes! I like it. Finally an INTERCAL keyword in CL!) plus defining
> what an "iterator" should be? We could just take the STL as an
> example.
>
> The tricky part is extending LOOP. But LOOP implementations do come
> with extensibility hooks.
We could certainly do that (for sufficiently small values of
"we"). We'd also need to make extensible versions of (or change
to make extensible) COPY-SEQ, FILL, SUBSEQ, MAP, REDUCE, COUNT,
LENGTH, REVERSE, SORT, FIND, POSITION, SEARCH, CONCATENATE,
REMOVE and so on. Plus the iterating bits of FORMAT. Probably
some other things I didn't mention.
> These are really relatively easy things to do at this day and age.
> The problem we face is to make sure that *all* implementations agree
> and that we do not have to write ugly conditionals for these
> extensions.
I don't think that's so easy.
--
Gareth McCaughan ················@pobox.com
.sig under construc
················@pobox.com (Gareth McCaughan) writes:
> Marco Antoniotti wrote:
> > > > You missed my ignorance :) Anyway, in CL you would have to conflate
> > > > (1) function calls, (2) array indexing, and (3) hash table indexing.
> > >
> > > Why #1?
> >
> > It seems to me that the only thing you can do as far as concrete
> > syntax goes, is to have
> >
> > (op a1 a2 a3 ...)
> >
> > where `op' can be a function, an array or an hash table.
>
> I can't speak for anyone else in this discussion, but I'd
> be perfectly happy with (ref thing a1 a2 ...) provided there
> were also the appropriate facilities for mapping, looping,
> filtering, and so on.
>
> > Well... I agree with all that you say. But the point is: do we need a
> > full blown new language to introduce these features, or can "we"
> > "agree" (quote marks mandatory) to extend the semantics of LOOP with a
> > new generic keyword
> >
> > (loop for x coming-from <an-iterator> ...)
> >
> > (Yes! I like it. Finally an INTERCAL keyword in CL!) plus defining
> > what an "iterator" should be? We could just take the STL as an
> > example.
> >
> > The tricky part is extending LOOP. But LOOP implementations do come
> > with extensibility hooks.
>
> We could certainly do that (for sufficiently small values of
> "we"). We'd also need to make extensible versions of (or change
> to make extensible) COPY-SEQ, FILL, SUBSEQ, MAP, REDUCE, COUNT,
> LENGTH, REVERSE, SORT, FIND, POSITION, SEARCH, CONCATENATE,
> REMOVE and so on. Plus the iterating bits of FORMAT. Probably
> some other things I didn't mention.
Ok. This is a different beast altogether.
I believe that
1 - REF and "iterators" (SERIES and stuff like that) can be provided
"easily" and in such a way not to take (too much of) a performance hit.
2 - Providing a "COLLECTION" interface to an extensible set of
SEQUENCE like operations can be done as a layered package. I have
no problems calling a function as
(seqs:subseq <any-collection> from end)
In this case I know that I might not get as fast as (cl:subseq ...)
> > These are really relatively easy things to do at this day and age.
> > The problem we face is to make sure that *all* implementations agree
> > and that we do not have to write ugly conditionals for these
> > extensions.
>
> I don't think that's so easy.
I do not think it is easy either, because of my second point. I think
it is relatively easy to provide layered specifications for very well
circumscribed pieces of the language and more layered specifications
for "higher" level language issues like general "collections" and
"iterators".
As an example, a simple interface for Java-like Enumerations can be
the following (no error checking, no bounds checking, no
`NoSuchElementException' condition). I will not want to get this in
the language. I like the "layered" package. Given the code below
(quite untested) you can already write Java-like code in CL
(let ((le (make-enumeration '(1 2 3 4))))
(loop while (has-more-elements-p le)
do (print (next-element le))))
My point is that to define these `extensions', is not that difficult.
What is difficult is to decide how to "organize" such extensions.
Cheers
==============================================================================
;;; -*- Mode: Lisp -*-
(defpackage "CL.UTIL.ENUMERATIONS" (:use "COMMON-LISP")
(:nicknames "ENUM")
(:export "ENUMERATION"
"ENUMERATIONP"
"MAKE-ENUMERATION"
"HAS-MORE-ELEMENTS-P"
"NEXT-ELEMENT"))
(in-package "ENUM")
(defclass enumeration ()
((enumerated-object :reader enumerated-object :initarg :object)))
(defgeneric enumerationp (x)
(:method ((x t)) nil)
(:method ((x enumeration)) t))
(defgeneric make-enumeration (x))
(defgeneric has-more-elements-p (x))
(defgeneric next-element (x))
(defclass list-enumeration (enumeration)
((ptr :accessor list-enum-ptr)))
(defmethod initialize-instance :after ((x list-enumeration) &key)
(setf (list-enum-ptr x) (enumerated-object x)))
(defmethod make-enumeration ((x list))
(make-instance 'list-enumeration :object x))
(defmethod has-more-elements-p ((x list-enumeration))
(not (null (list-enum-ptr x))))
(defmethod next-element ((x list-enumeration))
(with-slots (ptr)
x
(prog1 (first ptr)
(setf ptr (rest ptr)))))
(defclass vector-enumeration (enumeration)
((ptr :accessor vector-enum-ptr :type fixnum)))
(defmethod initialize-instance :after ((x vector-enumeration) &key)
(setf (vector-enum-ptr x) 0))
(defmethod make-enumeration ((x vector))
(make-instance 'vector-enumeration :object x))
(defmethod has-more-elements-p ((x vector-enumeration))
(< (vector-enum-ptr x) (length (enumerated-object x))))
(defmethod next-element ((x vector-enumeration))
(with-slots (ptr)
x
(prog1 (aref (enumerated-object x) ptr)
(incf ptr))))
(defclass string-enumeration (enumeration)
((ptr :accessor string-enum-ptr :type fixnum)))
(defmethod initialize-instance :after ((x string-enumeration) &key)
(setf (string-enum-ptr x) 0))
(defmethod make-enumeration ((x string))
(make-instance 'string-enumeration :object x))
(defmethod has-more-elements-p ((x string-enumeration))
(< (string-enum-ptr x) (length (enumerated-object x))))
(defmethod next-element ((x string-enumeration))
(with-slots (ptr)
x
(prog1 (char (enumerated-object x) ptr)
(incf ptr))))
;;; end of file -- enumerations.lisp --
==============================================================================
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th 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'.
In article <································@g.local>,
················@pobox.com wrote:
> Example: suppose you build a data structure that contains
> a sequence of objects, where the underlying representation
> is some sort of tree so that you can add and delete stuff
> at arbitrary points in the sequence in O(log N) time. This
> is pretty easy to do in CL or in Python. If you want to
> iterate over these things in CL, you need to write your
> own iteration function or macro, or (if you don't mind being
> non-portable) define a new loop keyword; or else build a
> list or vector out of the data structure any time you want
> to iterate over it. In Python, you define either a "getitem
> method" or an "iterator method", and then you can just say
>
> for x in my_structure:
> do_something_with(x)
>
> exactly as you would for elements of a list. And anything
> else that does iteration (list comprehensions, mapping
> functions, and so on) will also work immediately with
> your new structure.
>
> This is (to my taste, anyway) very elegant, and it's
> something you can't easily add to CL. You can design
> your own iteration facility which enables this, of course,
> but then you're effectively writing in a new dialect
> of your own, and most of us are reluctant to do that.
> And you'd have to redesign quite a lot: none of the
> existing sequence functions are extensible in the right
> way, so you'd need to replace them all.
Dylan also allows you to do this.
Write an element() and element-setter for the new collection type, and
then get iteration that works with everything from "for" to "every?" by
adding a method to the forward-iteration-protocol Generic Function.
> Of course, it's also very hard to do efficiently. It
> would not be easy to compile a language like this as
> efficiently as Common Lisp can be compiled. It would,
> at the very least, require whole-program analysis.
In typical Dylan implementations, generalized iteration costs, if the
exact type of the collection is...
not known: one GF call in the prolog of the iteration plus a couple of
indirect calls through function pointers each time around the body of
the loop.
known: the whole thing can be inlined if the designer of the collection
class wants it to be. In particular, iterating through arrays or lists
produces code identical to C.
-- Bruce
Bruce Hoult <·····@hoult.org> writes:
> In article <································@g.local>,
> ················@pobox.com wrote:
>
> > This is (to my taste, anyway) very elegant,
mine, too
> > and it's
> > something you can't easily add to CL. You can design
> > your own iteration facility which enables this, of course,
> > but then you're effectively writing in a new dialect
> > of your own, and most of us are reluctant to do that.
> > And you'd have to redesign quite a lot: none of the
> > existing sequence functions are extensible in the right
> > way, so you'd need to replace them all.
>
> Dylan also allows you to do this.
>
> Write an element() and element-setter for the new collection type, and
> then get iteration that works with everything from "for" to "every?" by
> adding a method to the forward-iteration-protocol Generic Function.
This is something I would *love* to have in Lisp. The lack of a REF
in CL is stupid easy to solve. I suppose we could do something like
make a generalized MAP, and a DO-MAP (or something). But that
wouldn't help inside LOOP (which I've expressed my love for before).
*I* can extend *my* LOOP, but I'm hesitant to do so, because it's not
portable. When I'm doing something that's essentially creating a new
dialect, I like to do it layered over standard CL, but this is one
case where I can't (I don't think -- I'd love to be proven wrong :).
I actually do have a MAP-THING function and a DO-THING macro to
iterate over REF'able things. But I don't feel comfortable with them,
which is part of the reason they're named so ridiculously. They're in
my UTILITIES package, but they ain't in the CL80 package (where
extended dialect implemented by the compiler I'm working on lives).
> > Of course, it's also very hard to do efficiently. It
> > would not be easy to compile a language like this as
> > efficiently as Common Lisp can be compiled. It would,
> > at the very least, require whole-program analysis.
Nah. You could have DOLIST, (loop for x across ...), etc., along with
this just fine. The same way that ELT, AREF, NTH, SVREF, ..., all
live together just fine. This would be the iteration version of ELT
on steriods (an iterative version of REF :). Done properly, the
iteration facility would be picked as a loop invariant, and would be
irrelevant for the inside of the loop.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Thomas F. Burdick wrote:
> This is something I would *love* to have in Lisp. The lack of a REF
> in CL is stupid easy to solve. I suppose we could do something like
> make a generalized MAP, and a DO-MAP (or something). But that
> wouldn't help inside LOOP (which I've expressed my love for before).
> *I* can extend *my* LOOP, but I'm hesitant to do so, because it's not
> portable. When I'm doing something that's essentially creating a new
> dialect, I like to do it layered over standard CL, but this is one
> case where I can't (I don't think -- I'd love to be proven wrong :).
The layered community standards idea hosted at CLiki so far is
explicitely thought as a place to agree on implementation specific
extensions.
Several Lispsystems offer implementation specific extensions to the base
language which could be candidates for a layered community standard:
- Weak Hashtables (ACL, LW, CMUCL and AFAIK CLISP with differing
interfaces)
- Hashtables with arbitrary hash and test functions (ACL and CMUCL with
slightly different interfaces)
- LOOP Extension Protocol (all implementations with MIT-LOOP - AFAIK at
least ACL, CMUCL, LW)
- Several facilities with MIT LOOP that are different to ANSI-CL LOOP
but are understood to be more convenient. (ACL, CMUCL, LW, not CLISP)
- Stream extension protocols like Gray-Streams or Simple-Streams
Several vendors extended the original Gray-Streams proposal (things
like STREAM-READ-SEQUENCE or BUFFERED-STREAMS in LispWorks)
- DEFADVICE (ACL, LispWorks, others?)
I think the term "Layered community standard" does not necessarily imply
that the topic can has to be implemented in portable Common Lisp. It is
"layered" because it is an optional add-on which is not mandatory to be
ANSI-Compliant. The purpose of this is simply to create a forum where we
can agree on common extensions to Common Lisp. To be effective we should
try to concentrate on topics that are commonly implemented but somewhat
different in their interfaces (like the above examples). Since all
facilities will be optional there is the opportunity to agree on
multiple facilities where we are not yet ready to agree on one (Think of
Gray-Streams vs. Simple Streams)
> I actually do have a MAP-THING function and a DO-THING macro to
> iterate over REF'able things. But I don't feel comfortable with them,
> which is part of the reason they're named so ridiculously. They're in
> my UTILITIES package, but they ain't in the CL80 package (where
> extended dialect implemented by the compiler I'm working on lives).
I discussed this topic a while ago with someone else and we came to the
conclusion that there might be a abstraction above sequences,
hashtables, a-lists, plists and user-defined "things" like b-trees. This
abstract type could be called "table" (What else is an array if not a
table with a key type of (integer 0 array-dimension-limit)). So the
functioms you mentioned may get called MAP-TABLE or DO-TABLE. An
interesting question might be to mandate that even if REF is implemented
as a GF the user cannot rely on method combinations with it. This would
allow to optimize calls to REF if the type of the table is declared.
(defun foo (table)
(declare (type hash-table table))
(ref table 'hello))
-transformed to->
(defun foo (table
(declare (type hash-table table))
(gethash table 'hello))
So you can extend REF by adding appropriate methods for your own table
types but you still can get outstanding performance.
(Sidenote: Dylans element() is in this way easier to optimize because
Dylan has no method-combinations like CL AFAIK)
Thinking about this example I wished there would be portable access to
the declaration information in compiler-macros this would allow
extending CL in a way that is generic _and_ efficient.
But it is even worse - I do not even know where to get this information
in for example Lispworks...
ciao,
Jochen
Jochen Schmidt <···@dataheaven.de> writes:
> - LOOP Extension Protocol (all implementations with MIT-LOOP - AFAIK at
> least ACL, CMUCL, LW)
I don't think LW supports this.
--
Lieven Marchand <···@wyrd.be>
She says, "Honey, you're a Bastard of great proportion."
He says, "Darling, I plead guilty to that sin."
Cowboy Junkies -- A few simple words
Lieven Marchand <···@wyrd.be> writes:
> > - LOOP Extension Protocol (all implementations with MIT-LOOP - AFAIK at
> > least ACL, CMUCL, LW)
>
> I don't think LW supports this.
Well, it's got LOOP:DEFLOOP and LOOP:DEFINE-LOOP-METHOD with the usual
semantics, I think, but they're not documented. So I guess that's not
supporting. That could change fairly easily.
--
Pekka P. Pirinen
A feature is a bug with seniority. - David Aldred <david_aldred.demon.co.uk>
···············@globalgraphics.com (Pekka P. Pirinen) writes:
> Well, it's got LOOP:DEFLOOP and LOOP:DEFINE-LOOP-METHOD with the usual
> semantics, I think, but they're not documented. So I guess that's not
> supporting. That could change fairly easily.
DEFINE-LOOP-PATH and DEFINE-LOOP-SEQUENCE-PATH, which are usually the
most convenient most documented ways to add loop paths for LOOPs of a
certain lineage, seem to both be unbound in my copy of Lispworks.
Carl Shapiro <········@panix.com> writes:
> ···············@globalgraphics.com (Pekka P. Pirinen) writes:
>
> > Well, it's got LOOP:DEFLOOP and LOOP:DEFINE-LOOP-METHOD with the usual
> > semantics, I think, but they're not documented. So I guess that's not
> > supporting. That could change fairly easily.
>
> DEFINE-LOOP-PATH and DEFINE-LOOP-SEQUENCE-PATH, which are usually the
> most convenient most documented ways to add loop paths for LOOPs of a
> certain lineage, seem to both be unbound in my copy of Lispworks.
Actually it seems that those symbols are unbound in 4.1.20 and
completely absent from 4.2.
···············@globalgraphics.com (Pekka P. Pirinen) writes:
> Lieven Marchand <···@wyrd.be> writes:
> > > - LOOP Extension Protocol (all implementations with MIT-LOOP - AFAIK at
> > > least ACL, CMUCL, LW)
> >
> > I don't think LW supports this.
>
> Well, it's got LOOP:DEFLOOP and LOOP:DEFINE-LOOP-METHOD with the usual
> semantics, I think, but they're not documented. So I guess that's not
> supporting. That could change fairly easily.
It would be very nice if these were documented, but MIT-LOOP's
extension mechanism works with loop-universes, add-loop-path,
named-variable etc.
--
Lieven Marchand <···@wyrd.be>
She says, "Honey, you're a Bastard of great proportion."
He says, "Darling, I plead guilty to that sin."
Cowboy Junkies -- A few simple words
In article <················@dataheaven.de>, Jochen Schmidt
<···@dataheaven.de> wrote:
> I discussed this topic a while ago with someone else and we came to the
> conclusion that there might be a abstraction above sequences,
> hashtables, a-lists, plists and user-defined "things" like b-trees. This
> abstract type could be called "table" (What else is an array if not a
> table with a key type of (integer 0 array-dimension-limit)). So the
> functioms you mentioned may get called MAP-TABLE or DO-TABLE.
In Dylan you have:
<explicit-key-collection> -- arbitrary key: hash tables, search trees
<sequence> -- key is an integer: vectors, arrays, strings, lists,
queues, ranges etc
<collection> -- one of the above
General iteration -- e.g. "for (e in myCollection) ... end" works with
any collection, as do map(), any?(), every?() etc.
> So you can extend REF by adding appropriate methods for your own table
> types but you still can get outstanding performance.
>
> (Sidenote: Dylans element() is in this way easier to optimize because
> Dylan has no method-combinations like CL AFAIK)
Correct.
-- Bruce
In article <···············@octagon.mrl.nyu.edu>, Marco Antoniotti
<·······@cs.nyu.edu> wrote:
> Now. Let's take one of the desiderata that have been floating around.
>
> (let ((a (make-array 100)))
> (setf (a 42) 42)
> (a 42))
>
> => 42
>
> or
>
> (let ((a (make-hash-table)))
> (setf (a 42) 42)
> (a 42))
>
> => 42
>
> Now, AFAIK, *no* other language conflates the above. Either you have
>
> a[42]
> or
> a{42}
No, there's Dylan (which you know about but perhaps don't know):
let a = make(<vector>, size: 100);
a[42] := 42;
a[42];
=> 42
let a = make(<table>);
a[42] := 42;
a[42];
=> 42
> Can you "extend" CL (or Ciel) to achieve something similar without (a)
> compromising the base language, maybe at the cost of changing the
> implementations?
>
> I believe you can. You can write a specification for a new operator
> called REF, akin to FUNCALL, so that the above becomes
>
> (let ((a (make-array 100)))
> (setf (ref a 42) 42)
> (ref a 42))
>
> => 42
>
> or
>
> (let ((a (make-hash-table)))
> (setf (ref a 42) 42)
> (ref a 42))
>
> => 42
You "ref" is in fact the same as Dylan's "element", which can be written
as either a function call (including a default value argument), or using
the [] syntactic sugar.
> As you know, you can write REF in CL (Ciel) itself. Now the trick is
> to (a) provide a reference implementation and (b) have the
> implementors delve deeply in their code so that REF is optimized away
> whenever possible.
It *is* quite a trick, and one that Dylan compilers know.
> The same reasoning aplies to a lot of other CL (Ciel) "missing
> features". You name it.
>
> E.g. sealed classes. The solution is very easy. Define an extension
> to DEFCLASS.
>
> (defclass something (....)
> (....)
> (:sealed t))
>
> Bottom line: I do not believe that defining a new language buys you
> anything.
You could certainly *implement* Dylan in CL, right down to reader macros
that parsed the infix syntax. (In fact, that's pretty much what Apple
did, building on top of MCL)
But, once you start consistently using your new features and stop using
the old ones, don't you think that your effort is worthy of being
regarded as a language in its own right? And certainly worthy of the
same careful design as any other language?
-- Bruce
Bruce Hoult <·····@hoult.org> writes:
> No, there's Dylan (which you know about but perhaps don't know):
>
> let a = make(<vector>, size: 100);
> a[42] := 42;
> a[42];
>
> => 42
>
> let a = make(<table>);
> a[42] := 42;
> a[42];
>
> => 42
Personally, I think that sequences and e.g. hash-tables are different
enough in semantics (e.g. continuous bounded range of keys,
vs. non-continuous, unbounded range of keys, integer vs. any-type
keys, etc.), that conflating them in a single accessor is not
a good idea, especially since the border cases (e.g. error conditions)
are usefully different.
> > As you know, you can write REF in CL (Ciel) itself. Now the trick is
> > to (a) provide a reference implementation and (b) have the
> > implementors delve deeply in their code so that REF is optimized away
> > whenever possible.
>
> It *is* quite a trick, and one that Dylan compilers know.
Not really. Any optimizing CL compiler will have the required
mechanisms in place already, given all the other generic (in the
non-CLOS sense) arithmetic and sequence operators. It is fairly
simple to plug a new operator into this system, e.g. in CMU CL:
(deftransform ref ((s i) (list *) * :when :both)
'(nth i s))
(deftransform ref ((s i) (vector *) * :when :both)
'(aref i s))
(deftransform ref ((s i) (hash-table *) * :when :both)
'(refgethash i s))
etc.
[ This leaves out differences in error-handling, which would
necessesitate some further hair, in order to present unified
behaviour... ]
Similar mechanisms will exist in all optimizing CL implementations
(and in implementations that don't optimize sequence functions,
optimizing ref is obviously not of higher priority).
> You could certainly *implement* Dylan in CL, right down to reader macros
> that parsed the infix syntax. (In fact, that's pretty much what Apple
> did, building on top of MCL)
Who says something about implementing Dylan? Not every language that
has e.g. sealing declarations is ipso-facto Dylan (CMU CL for example
has sealing for its internal class system).
> But, once you start consistently using your new features and stop using
> the old ones, don't you think that your effort is worthy of being
> regarded as a language in its own right? And certainly worthy of the
> same careful design as any other language?
No one has said that the new features should be designed with less
care than a new language (in fact, designing them should be done with
more care, since there is more fixed context that this has to fit
into). And noone has suggested that the new features should supercede
the old ones. elt hasn't superceded aref either. And what feature
should class sealing supercede?
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
···@jpl.nasa.gov (Erann Gat) writes:
> > That's French for sky as in the sky is the limit, and it is pronounced
> > see-ell, aka CL.
>
> I like it!
>
> Now comes the hard part: designing it.
Good luck, let me know how far yall get in 5 years.
In the meantime I'll write some CL.
--
Craig Brozefsky <·····@red-bean.com>
http://www.red-bean.com/~craig
Ask me about Common Lisp Enterprise Eggplants at Red Bean!
Erann Gat wrote:
>
> In article <·················@nyc.rr.com>, Kenny Tilton
> <·······@nyc.rr.com> wrote:
>
> > I have it!
> >
> > Ciel
> >
> >
> > That's French for sky as in the sky is the limit, and it is pronounced
> > see-ell, aka CL.
>
> I like it!
>
> Now comes the hard part: designing it.
>
First thing we do, let�s kill all the parentheses.
If you liked Ciel (or Cielo!), you're gonna love this: we modify Emacs
to show a space where there is ( or ). We keep prefix hence macros, but
lose the parens. Visually.
let auto-indenting show the grouping. that will win over the pythonites
bigtime.
some chord or other shows/hides parens, option-something shows parens
until you key-up.
Here is part of Steele's backquote implementation, grace a
paulgraham.com:
defun bq-simplify-args x
do args reverse cdr x cdr args
result
nil
cond atom car args
bq-attach-append *bq-append* car args result
and eq caar args *bq-list*
notany #'bq-splicing-frob cdar args
bq-attach-conses cdar args result
and eq caar args *bq-list**
notany #'bq-splicing-frob cdar args
bq-attach-conses
reverse cdr reverse cdar args
bq-attach-append *bq-append*
car last car args
result
and eq caar args *bq-quote*
consp cadar args
not bq-frob cadar args
null cddar args
bq-attach-conses list list *bq-quote*
caadar args
result
eq caar args *bq-clobberable*
bq-attach-append *bq-nconc* cadar args result
t bq-attach-append *bq-append*
car args
result
null args result
I scare myself sometimes.
kenny
clinisys
> we modify Emacs to show a space where there is ( or ). We keep
> prefix hence macros, but lose the parens. Visually.
Perhaps parenface.el does what you'd like?
http://www.davep.org/emacs/parenface.el
Ted
--
Edward O'Connor
···@oconnor.cx
Kenny Tilton <·······@nyc.rr.com> writes:
>
> defun bq-simplify-args x
> do args reverse cdr x cdr args
> result
> nil
> cond atom car args
> bq-attach-append *bq-append* car args result
> and eq caar args *bq-list*
> [SNIP!]
That's _so_ _weird_. Am I the only one who thinks
this is *less* readable than a parenthesized version?
> I scare myself sometimes.
Yeah. Me too. :-)
--
It would be difficult to construe Larry Wall, in article
this as a feature. <·····················@netlabs.com>
Alain Picard wrote:
>
> Kenny Tilton <·······@nyc.rr.com> writes:
>
> >
> > defun bq-simplify-args x
> > do args reverse cdr x cdr args
> > result
> > nil
> > cond atom car args
> > bq-attach-append *bq-append* car args result
> > and eq caar args *bq-list*
> > [SNIP!]
>
> That's _so_ _weird_. Am I the only one who thinks
> this is *less* readable than a parenthesized version?
My bad. I was too lazy to introduce the line breaks you would need to
make the indentation work. Here ya go, this should be OK (on a shorter
Steel BQ func):
defun bracket x
cond atom x
list *bq-list*
bq-process x
eq car x
*comma*
list *bq-list*
cadr x
eq car x
*comma-atsign*
cadr x
eq car x
*comma-dot*
list *bq-clobberable*
cadr x
t list *bq-list*
bq-process x
I'll be honest, even with parens i tend to give each func operand its
own line as above.
Gives new meaning to spaghetti code, don't you think? I am thinking we
address that by extending emacs to support multiple columns, like a
newspaper.
defun bracket x | eq car x
cond atom x | *comma-dot*
list *bq-list* | list *bq-clobberable*
bq-process x | cadr x
|
eq car x | t list *bq-list*
*comma* | bq-process x
list *bq-list* |
cadr x |
|
eq car x |
*comma-atsign* |
cadr x |
kenny
clinisys
Kenny Tilton <·······@nyc.rr.com> writes:
> Gives new meaning to spaghetti code, don't you think? I am thinking we
> address that by extending emacs to support multiple columns, like a
> newspaper.
>
> defun bracket x | eq car x
> cond atom x | *comma-dot*
> list *bq-list* | list *bq-clobberable*
> bq-process x | cadr x
> |
> eq car x | t list *bq-list*
> *comma* | bq-process x
> list *bq-list* |
> cadr x |
> |
> eq car x |
> *comma-atsign* |
> cadr x |
The frightening thing is that as I was reading this post, an
implementational strategy was forming in my head. I refuse to let
myself go through with it, because it's so not worth it for a joke,
but it would be kind of funny to see an Emacs that did all of this.
Font locking to show the paren level would be vital, of course.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
"Thomas F. Burdick" wrote:
>
> Kenny Tilton <·······@nyc.rr.com> writes:
>
> > Gives new meaning to spaghetti code, don't you think? I am thinking we
> > address that by extending emacs to support multiple columns, like a
> > newspaper.
> >
> > defun bracket x |
> > cond atom x |cond (cont'd)
> > list *bq-list* | eq car x
> > bq-process x | *comma-dot*
> > |
> > eq car x | list *bq-clobberable*
> > *comma* | cadr x
> > list *bq-list* | t list *bq-list*
> > cadr x | bq-process x
> > |
> > eq car x |
> > *comma-atsign* |
> > cadr x |
> >
>
> The frightening thing is that as I was reading this post, an
> implementational strategy was forming in my head. I refuse to let
> myself go through with it,
Since you'll probably break down and do it in spite of yourself:
I did not want to re-edit, but clearly the second column should start on
the line below the cond form, as shown above (with an cont'd thing I am
not so sure about).
:)
kenny
clinisys
From: Brian P Templeton
Subject: Re: Ciel: A Modest Proposal
Date:
Message-ID: <877kqdln72.fsf@tunes.org>
Kenny Tilton <·······@nyc.rr.com> writes:
> Alain Picard wrote:
>>
>> Kenny Tilton <·······@nyc.rr.com> writes:
>>
>> >
>> > defun bq-simplify-args x
>> > do args reverse cdr x cdr args
>> > result
>> > nil
>> > cond atom car args
>> > bq-attach-append *bq-append* car args result
>> > and eq caar args *bq-list*
>> > [SNIP!]
>>
>> That's _so_ _weird_. Am I the only one who thinks
>> this is *less* readable than a parenthesized version?
>
> My bad. I was too lazy to introduce the line breaks you would need to
> make the indentation work. Here ya go, this should be OK (on a shorter
> Steel BQ func):
>
> defun bracket x
> cond atom x
> list *bq-list*
> bq-process x
>
> eq car x
> *comma*
> list *bq-list*
> cadr x
>
> eq car x
> *comma-atsign*
> cadr x
>
> eq car x
> *comma-dot*
> list *bq-clobberable*
> cadr x
>
> t list *bq-list*
> bq-process x
>
> I'll be honest, even with parens i tend to give each func operand its
> own line as above.
>
> Gives new meaning to spaghetti code, don't you think? I am thinking we
> address that by extending emacs to support multiple columns, like a
> newspaper.
>
`M-x 2C-two-columns RET'?
> defun bracket x | eq car x
> cond atom x | *comma-dot*
> list *bq-list* | list *bq-clobberable*
> bq-process x | cadr x
> |
> eq car x | t list *bq-list*
> *comma* | bq-process x
> list *bq-list* |
> cadr x |
> |
> eq car x |
> *comma-atsign* |
> cadr x |
>
> kenny
> clinisys
--
BPT <···@tunes.org> /"\ ASCII Ribbon Campaign
backronym for Linux: \ / No HTML or RTF in mail
Linux Is Not Unix X No MS-Word in mail
Meme plague ;) ---------> / \ Respect Open Standards
Alain Picard <·······@optushome.com.au> writes:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
> >
> > defun bq-simplify-args x
> > do args reverse cdr x cdr args
> > result
> > nil
> > cond atom car args
> > bq-attach-append *bq-append* car args result
> > and eq caar args *bq-list*
> > [SNIP!]
>
> That's _so_ _weird_. Am I the only one who thinks
> this is *less* readable than a parenthesized version?
I'm sure there was a smiley implied there. But, of course,
you wouldn't have seen a smiley, since the parens had already
all been removed (:-)
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
Duane Rettig wrote:
>
> Alain Picard <·······@optushome.com.au> writes:
>
> > Kenny Tilton <·······@nyc.rr.com> writes:
> >
> > >
> > > defun bq-simplify-args x
> > > do args reverse cdr x cdr args
> > > result
> > > nil
> > > cond atom car args
> > > bq-attach-append *bq-append* car args result
> > > and eq caar args *bq-list*
> > > [SNIP!]
> >
> > That's _so_ _weird_. Am I the only one who thinks
> > this is *less* readable than a parenthesized version?
>
> I'm sure there was a smiley implied there.
<heh-heh> The subject line supports your theory.
I don't need emacs to hide the parens, my optic nerve started doing that
spontaneously after a couple of months of Lisp.
kenny
clinisys
On 19 Jan 2002, Alain Picard wrote:
[snipped illegible CL without parens]
> That's _so_ _weird_. Am I the only one who thinks
> this is *less* readable than a parenthesized version?
No. I sure do :)
A *few* parens would be nice...
(Of course, I might grow accustomed to it over time. But it sure seems
easier to "delete" parens than "add them in". At least for my visual
system.)
Cheers,
Bijan Parsia.
"Alain Picard" <·······@optushome.com.au> wrote in message
···················@gondolin.local.net...
> Kenny Tilton <·······@nyc.rr.com> writes:
>
> >
> > nil
> > cond atom car args
> > bq-attach-append *bq-append* car args result
> > and eq caar args *bq-list*
> > [SNIP!]
>
> That's _so_ _weird_. Am I the only one who thinks
> this is *less* readable than a parenthesized version?
>
OWWW! I think this is painful. I like my parens. Give them back to me. My
precious parens.
> > I scare myself sometimes.
>
> Yeah. Me too. :-)
>
Er... me to!
Vishal
"Kenny Tilton" <·······@nyc.rr.com> wrote in message
······················@nyc.rr.com...
> I have it!
>
> Ciel
>
>
> That's French for sky as in the sky is the limit, and it is pronounced
> see-ell, aka CL.
Nice. But Ciel is already the name of a French accounting software company
(member of the Sage group).
And their software is in C++ (I'm sure of this, I wrote the C++ class
library/framework they use)
Marc
Kenny Tilton wrote:
> I have it!
>
> Ciel
>
> That's French for sky as in the sky is the limit, and it is pronounced
> see-ell, aka CL.
I think there is a similar word in Italian -- cielo -- which I
think means "sky" but also "heavens"...
:)w
On Fri, 18 Jan 2002 20:33:20 +0000, Will Deakin <···········@hotmail.com>
wrote:
> I think there is a similar word in Italian -- cielo -- which I
> think means "sky" but also "heavens"...
Correct.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://web.mclink.it/amoroso/ency/README
[http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/]
In article <····················@eglaptop.jpl.nasa.gov>, Erann Gat wrote:
> In article <··············@orion.bln.pmsf.de>, "Pierre R. Mai"
> <····@acm.org> wrote:
>
>
>> Perl is somewhat of a special case. While it has undergone lots of
>> incompatible changes, it has survived to this day, with nearly
>> unabating popularity. Don't know what this indicates.
>
> Me neither. But it does prove that stability and corporate backing (or
> even sanity) are not prerequisites to success.
>
>> An influential "backer" is necessary, it doesn't have to be commercial.
>
> Yes. Now, who might serve as a non-commercial influential backer?
I think Perls big patron was luck. Here comes this new language that
munches text into different text and it coincided with the Internet
boom and it was free and there were libraries available so that I did
not have to learn the standards and write library code to get product
out the door(on the web). Now there is a massive code base available
for use that is free and it covers all the high points for business/web
apps(snmp, ldap, cgi, database, smtp/pop/imap, you name it) and it had
the additional advantage that in it original wave of acceptance almost
all of the programs written had a run time measured in seconds so the
os reclaimed the memory for you, bad code not a problem. And it was
billed as faster and easier then C to write in. And Perls only
competition in the scripting world back then was tcl and if I remember
correctly tcl was much slower then Perl then.
marc
>
>> I'm still unconvinced that Arc is a better idea than Dylan (quite the
>> contrary).
>
> I'm not convinced of that either. Different is not necessarily better,
> but better is necessarily different. Of that I am convinced.
>
> E.
····@oscar.eng.cv.net (Marc Spitzer) writes:
> I think Perls big patron was luck. Here comes this new language that
> munches text into different text and it coincided with the Internet
> boom and it was free and there were libraries available so that I did
> not have to learn the standards and write library code to get product
> out the door(on the web). Now there is a massive code base available
> for use that is free and it covers all the high points for business/web
> apps(snmp, ldap, cgi, database, smtp/pop/imap, you name it) and it had
> the additional advantage that in it original wave of acceptance almost
> all of the programs written had a run time measured in seconds so the
> os reclaimed the memory for you, bad code not a problem.
That was when Perl got big. It had already lived a number of years as
the Swiss army chainsaw for Unix system administrators. And there it
was an improvement on its competition, i.e., sed|awk|cut|grep|...
glued together with sh.
--
Lieven Marchand <···@wyrd.be>
She says, "Honey, you're a Bastard of great proportion."
He says, "Darling, I plead guilty to that sin."
Cowboy Junkies -- A few simple words
···@jpl.nasa.gov (Erann Gat) writes:
> How about adding layered standards *and* giving the result a new name?
There used to be a fun game called "find the ``Common Lisp' reference
on www.franz.com". They've revamped their site since then and it does
actually mention Lisp (and parentheses) on the front page, but my
recollection is that it used to be much more challenging to play.
I will add that I think there are two distinct audiences to consider:
the managers that you're fighting against are not the same people as
the in-college-or-recently-out-of-it hackers that I think of. Linux,
after all, made no bones about being a reimplementation of the
unfashionable Unix system, found immediate favour with the latter
group and is still working on the IS professsionals.
> > I'm still unconvinced that Arc is a better idea than Dylan (quite the
> > contrary).
>
> I'm not convinced of that either. Different is not necessarily better,
> but better is necessarily different. Of that I am convinced.
Unconvinced. Anyone who would have been put off by the name is going
to be doubly pissed off when he realises that not only is it still
Lisp (it has the parens, so it must be), but they're attempting some
kind of confidence trick by renaming it. I've met some fairly
intelligent people who think that RTL (the intermediate language used
by gcc) is Lisp ...
I think "stealth Lisp" is a viable strategy. It's unhip and you have
to either pay serious sums of money for it or mess with ugly
user-unfriendly free stuff, but if you jump through the hoops, once
you've seriously got to grips with it you'll not want to go back to
anything else[*]. Not dissimilar from the state of Linux/Unix in 1993,
really.
-dan
[*] "anything else" being a widely available commodity system. Lispms,
I'm told, are different
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
···@jpl.nasa.gov (Erann Gat) writes:
> > C++ is a completely different language,
>
> How "completely" different it is is a matter of perception, which is
> precisely my point. On the one hand, C++ is similar enough to C that a
> C++ compiler will compile nearly all C code, and people who are already
> comfortable with C can ease more gently into C++ than they can into, say,
> Lisp or ML. On the other hand, C++ is different enough from C that it is
> impossible for someone who *doesn't* like C to simply dismiss C++ because
> it's just like C. (Of course, they can still dismiss it for other
> reasons.) Many people today dismiss Lisp because they think Lisp == Lisp
> 1.5. A new name would say to the world, "Look, this is not your
> grandfather's Lisp. This is something new and different and you ought to
> spend some time looking into it." Labels matter.
>
So, much as C++ said, "I'm like C, but different (and better)," we
should pick a name that says, "I'm like Lisp, but different, more
modern, and better." Perhaps we should add symbols to the name Lisp,
like Stroustrup did to C.
So, let's see:
Lisp++ (nope, too copycatish)
incfLisp (naw)
iLisp (only if it comes free with a new iMac)
Wait, I know, how about "Common Lisp"!
I mean, why not? If indeed most people think Lisp = Lisp 1.5, then
Common Lisp implies a relationship to Lisp 1.5 much like C++ implies a
relationship to C. We could even shorten it to CL, which has that
modern, internetish, clipped feel.
Sicerely, (more or less)
Thom
--
(let ((e-mail-address ····@IXG.IUS")) (loop with new-string =
(make-string (length e-mail-address)) for count from 0 to (1- (length
e-mail-address)) for char-code = (char-code (aref e-mail-address
count)) for new-char-code = (if (and (> char-code 64) (< char-code
123)) (+ (mod (+ 13 char-code) 52) 65) char-code) do (setf (aref
new-string count) (code-char new-char-code)) finally (return
new-string)))
From: Dorai Sitaram
Subject: Re: The true faith and the new name
Date:
Message-ID: <a29hce$90n$1@news.gte.com>
In article <·················@shalott.cra.com>,
Thom Goodsell <·········@DESPAM.cra.com> wrote:
>
>So, much as C++ said, "I'm like C, but different (and better)," we
>should pick a name that says, "I'm like Lisp, but different, more
>modern, and better." Perhaps we should add symbols to the name Lisp,
>like Stroustrup did to C.
>
>So, let's see:
>Lisp++ (nope, too copycatish)
>incfLisp (naw)
>iLisp (only if it comes free with a new iMac)
>
>Wait, I know, how about "Common Lisp"!
>
>I mean, why not? If indeed most people think Lisp = Lisp 1.5, then
>Common Lisp implies a relationship to Lisp 1.5 much like C++ implies a
>relationship to C. We could even shorten it to CL, which has that
>modern, internetish, clipped feel.
Lisp 150. That's clearly 100 times Lisp 1.5 (none of
this ++ stuff), and (format t ··@r" 150) returns
an appropriate value.
--d
····@goldshoe.gte.com (Dorai Sitaram) writes:
> In article <·················@shalott.cra.com>,
> Thom Goodsell <·········@DESPAM.cra.com> wrote:
> >
> >So, much as C++ said, "I'm like C, but different (and better)," we
> >should pick a name that says, "I'm like Lisp, but different, more
> >modern, and better." Perhaps we should add symbols to the name Lisp,
> >like Stroustrup did to C.
> >
> >So, let's see:
> >Lisp++ (nope, too copycatish)
> >incfLisp (naw)
> >iLisp (only if it comes free with a new iMac)
> >
> >Wait, I know, how about "Common Lisp"!
> >
> >I mean, why not? If indeed most people think Lisp = Lisp 1.5, then
> >Common Lisp implies a relationship to Lisp 1.5 much like C++ implies a
> >relationship to C. We could even shorten it to CL, which has that
> >modern, internetish, clipped feel.
>
> Lisp 150. That's clearly 100 times Lisp 1.5 (none of
> this ++ stuff), and (format t ··@r" 150) returns
> an appropriate value.
It returns nil, which we could treat as NIL (the lisp dialect,
resurrected).
--
Janis Dzerins
Eat shit -- billions of flies can't be wrong.
···@jpl.nasa.gov (Erann Gat) writes:
> A new name would say to the world, "Look, this is not your
> grandfather's Lisp. This is something new and different and you ought to
> spend some time looking into it." Labels matter.
I did notice that in many of the promotional mailings I've gotten from
Franz, the word "Lisp" doesn't actually appear anywhere. Instead they
use the acronym CLOS and talk about selling a dynamic language.
--
Thomas A. Russ, USC/Information Sciences Institute ···@isi.edu
Yup, Peter denying Jesus all over again.
The funny thing is they tried to change horses to the OO hype by yelling
Dynamic Objects and CLOS and then that horse drowned, too. Hey, how
about Allegro XP!?
:) Actually, they are trying to make a buck, god bless them, I
understand. been there, done that.
kenny
clinisys
"Thomas A. Russ" wrote:
>
> ···@jpl.nasa.gov (Erann Gat) writes:
> > A new name would say to the world, "Look, this is not your
> > grandfather's Lisp. This is something new and different and you ought to
> > spend some time looking into it." Labels matter.
>
> I did notice that in many of the promotional mailings I've gotten from
> Franz, the word "Lisp" doesn't actually appear anywhere. Instead they
> use the acronym CLOS and talk about selling a dynamic language.
>
> --
> Thomas A. Russ, USC/Information Sciences Institute ···@isi.edu
On Thu, 17 Jan 2002 15:07:28 -0800, ···@jpl.nasa.gov (Erann Gat) wrote:
>1.5. A new name would say to the world, "Look, this is not your
>grandfather's Lisp. This is something new and different and you ought to
>spend some time looking into it." Labels matter.
Arc seems like an interesting project and a nice name...
--
Fernando Rodr�guez
frr at wanadoo dot es
--
"Pierre R. Mai" <····@acm.org> writes:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > In article <··············@orion.bln.pmsf.de>, "Pierre R. Mai"
> > <····@acm.org> wrote:
> >
> > > Nothing major has changed in ANSI Common Lisp, since probably about
> > > 1990-91. And that is a _very good_ thing. I'm sorry, but change is
> > > not a priori better than constancy, quite the contrary.
> >
> > Yes, that's true, but so is the reverse: constancy is not a priori better
> > than change. It depends on what is constant and what is changing.
>
> If changing and staying constant have the same overall benefits, then
> constancy wins. Change is _very_ expensive. See evolution, which is
> only succesful, because it can expend lots of individual population
> members.
>
> > > I don't see how major changes to the base language will give us
> > > anything worth the huge cost.
> >
> > Backwards-compatible changes don't necessarily incur a huge cost.
>
> Complete agreement. That's why adding layered standards is something
> I can get enthusiastic about. Reinventing the language (like in Arc)
> is not.
>
> The only problem is coming up with resources for such activities.
> Things like Arc don't seem to me to be helping any.
I wholehearthedly agree with Pierre. This is also the main reason why
I thought that Dylan was not so great an idea at the time.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th 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'.
"Pierre R. Mai" <····@acm.org> writes:
> Correct, influential backing doesn't mean a marketing machine, it
> means a continued investment into the language, and a strategic
> adoption as a platform. Of the languages you mention, only Perl
> stands out as not having any official backer.
And even Perl has the not inconsiderable weight of ORA behind it.
Among Unix people that counts for a lot.
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
Daniel Barlow <···@telent.net> writes:
> And even Perl has the not inconsiderable weight of ORA behind it.
> Among Unix people that counts for a lot.
Perl was huge long before ORA.
-Doug
Doug McNaught <····@mcnaught.org> writes:
> Daniel Barlow <···@telent.net> writes:
>
> > And even Perl has the not inconsiderable weight of ORA behind it.
> > Among Unix people that counts for a lot.
>
> Perl was huge long before ORA.
There was a Camel book for Perl 4 - I think my copy refers to 4.018 or
so. Given that I remember first installing Perl 5 in 1995 or so (for
SATAN, in fact) this predates the Dot Com Revolution(sic)
So, OK, maybe it was huge, but it was considerably less huge than it
has been since.
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
Daniel Barlow <···@telent.net> writes:
> Doug McNaught <····@mcnaught.org> writes:
>> Daniel Barlow <···@telent.net> writes:
>>> And even Perl has the not inconsiderable weight of ORA behind
>>> it. Among Unix people that counts for a lot.
>> Perl was huge long before ORA.
> There was a Camel book for Perl 4 - I think my copy refers to 4.018
> or so. Given that I remember first installing Perl 5 in 1995 or so
> (for SATAN, in fact) this predates the Dot Com Revolution(sic)
> So, OK, maybe it was huge, but it was considerably less huge than it
> has been since.
There was a Camel book for Perl _3_. Copyright 1990.
The ORA weight was not insignificant in my own experience; I was able
to specify the use of something as "experimental" as Perl for a
project on the basis that there actually existed public literature on
store shelves for it. (The alternatives would probably have been C or
VMS DCL... Definitely much worse...)
--
(reverse (concatenate 'string ········@" "enworbbc"))
http://www3.sympatico.ca/cbbrowne/lsf.html
There are two kinds of people in the world: People who think there are
two kinds of people and people who don't.
···@jpl.nasa.gov (Erann Gat) writes:
> I'd say just the opposite is true. C has undergone at least two rounds of
> major changes in its history (from K&R C to ANSI C, then it went from ANSI
> C to C++, and arguably from C++ to C++ + STL).
C++ ain't C
Regards, KBK
In article <··············@float.ne.mediaone.com>, Kurt B. Kaiser wrote:
>···@jpl.nasa.gov (Erann Gat) writes:
>
>> I'd say just the opposite is true. C has undergone at least two rounds of
>> major changes in its history (from K&R C to ANSI C, then it went from ANSI
>> C to C++, and arguably from C++ to C++ + STL).
>
>C++ ain't C
True, but it's possible to view C++ as an evolution of C. C++ retains the
ideas of C, in nearly the same form. A C program can be written in C++
in essentially the same way, declaration for declaration, expression
for expression and statement for statement, with similar time and
space performance given comparably capable compilers.
There are minor incompatibilities which prevent some C programs for
also being well-formed C++ programs with the same meaning.
There are also changes to C introduced in 1995 (Normative Addendum 1)
and 1999 which prevent some C90 programs from being valid C.
On Wed, 16 Jan 2002, Erann Gat wrote:
> In article
> <··········································@login9.isis.unc.edu>, Bijan
> Parsia <·······@email.unc.edu> wrote:
>
> > So change, when it can cost millions of dollers and disrupt delicate
> > synergies, needs to be approached sensible. And that means resisting some
> > of it.
>
> Agreed. But when was the last time *anything* major in Common Lisp changed?
I don't know. What do you count as "Common Lisp" and what would count as a
change to it?
The spec? General practices? Informal "standards"?
The dataflow stuff recently released seems need. The major commercial
implementations have plenty of addons, etc.
We're still after getting full compliance, yes?
There seem to be plenty of interesting strengths/differences between the
implementations that suggest that stuff changes.
Hmm. You might be interested in exploring SmallScript, which is a
Smalltalk dialect that has a lot of extentions inspired by Common Lisp
(starting with multimethods and a nice MOP). It's designed to have
multiple syntaxes (so some sort of macroing must be involved) and is
available for .NET (so it can get at all the forthcoming C#
libraries). Plus, it seems to have some nice performance tricks, albeit in
the JIT VM realm, rather than static native code generation.
I encourage all CLers to check it out. Though it's coming from Smalltalk,
it aims to be *very* linguistically rich. David Simmons, the author, would
be, I think, interested in adding features that make a CLer's heart swoon.
At the very least, it's way more developed than Arc. I.e., now in beta
commercial release with over two years of development effort.
Note, it's not *tied* to .NET. There's bare windows and linux release.
> > It would be great if you could elaborate on the details of how these
> > examples support your views, and what we should be learning from
> > them. Just pointing at them seems, well, unhelpful and vague.
>
> The point I was trying to support with the Aqua example was that I think
> Lisp needs to reinvent itself,
Well, *originally* you gave Nextstep as an example of pure failure. I
don't think Lisp is relevantly similar. (Though looking at OpenSTEP and
GNUStep may be interesting.)
Plus, MacOS/X (not "Aqua"; Aqua is the ui look) isn't "NextSTEP having
reinvented itself". It was the merger of two worried
techs/cultures/companies, plus a lot of cash, plus a fairly decent
userbase. It's hardly a model Lisp *can* follow in the near future,
afaict.
Squeak and Smallscript (and Camp Smalltalks) are some examples of small
groups (on the Squeak and Smallscript front) and consensus, community
wide, distributed efforst (Camp Smalltalk) are working to "reinvent" and
update Smalltalk. They are, IMHO, working rather well.
Camp Smalltalk is particularly fun. Getting together with a bunch of
Smalltalk folk to work on cross implementation/cross dialect projects that
expand our collective toolkit. Camp Common Lisp could be equally neat,
imho. I'm no Lisper, but I'd love to go to one just get my feet wet.
> and that part of a successful reinvention
> is marketing it as something new, and putting on enough new window
> dressing to make it appear new to cursory inspection, even if it really
> isn't new at all.
I guess. I've seen that fail as much as succeed.
> The rest of the world keeps reinventing Lisp badly; the
> Lisp shorld reinvent Lisp and do it right. That's what I see Paul trying
> to do with Arc. And while Arc may not be perfect, at least he's trying.
But look at the *massive* disanalogy between MacOS/X and Arc. MacOS/X is
working straightforwardly from two older techs and tech bases: NextSTEP
and MacOS. It's continuity is rather *tight*. Even if arc were fully
designed and implemented, it's nothing of the sort. It's a "from
scratch" effort that doesn't remotely attempt in *any* way to accomodate
existing practice. It doesn't *reinvent* the Lisp that is, it starts over.
This is what at lot of the criticism *said* and what a lot of the
resistence is based on.
Cheers,
Bijan Parsia.
Bijan Parsia <·······@email.unc.edu> writes:
> On Wed, 16 Jan 2002, Erann Gat wrote:
>
> > In article
> > <··········································@login9.isis.unc.edu>, Bijan
> > Parsia <·······@email.unc.edu> wrote:
> > > It would be great if you could elaborate on the details of how these
> > > examples support your views, and what we should be learning from
> > > them. Just pointing at them seems, well, unhelpful and vague.
> >
> > The point I was trying to support with the Aqua example was that I think
> > Lisp needs to reinvent itself,
>
> Well, *originally* you gave Nextstep as an example of pure failure. I
> don't think Lisp is relevantly similar. (Though looking at OpenSTEP and
> GNUStep may be interesting.)
>
> Plus, MacOS/X (not "Aqua"; Aqua is the ui look) isn't "NextSTEP having
> reinvented itself". It was the merger of two worried
> techs/cultures/companies, plus a lot of cash, plus a fairly decent
> userbase. It's hardly a model Lisp *can* follow in the near future,
> afaict.
Indeed. In fact, Apple's first attempt at resurrecting NextSTEP failed
miserably. It was called Rhapsody. The reason for its failure was that
product developers didn't want to throw away their development effort
on their original Mac toolkits, and so they rebelled. It was a similar
situation to when Sun changed over from Solaris 1 to Solaris 2. It
took many years to get to the point where Sun could remove support
for Solaris 1.
Both of these situations involve vendors trying to upgrade their
outdated systems with radical new ones. They needed to replace
the infrastructure of these systems, and they needed their customer
base to follow, in order to make future progress. Both met with
great resistance. How did they finally succeed? Time passed.
BTW, while it is true that Apple used the renaming marketing trick
to get from NextStep (via Rhapsody) to MacOSX, this is certainly not
the case with Sun; I don't consider the name Solaris 1 (i.e. SunOS4)
to be any different in substance than Solaris2 (SunOS5). It's just
a numeric increment.
How does all this compare with Lisp? It doesn't. Lisp is old, but not
outdated. In fact, Lisp was reinvented 10 years ago (this reinvention
started in the early 80's and culminated in the early 90's in the current
CL spec).
At about the same time CL was being finalized, the Dylan folk were trying
yet again to reinvent Lisp. They were open about Dylan's Lisp roots,
but they took (among other things) the standard views of the time that
they should lose the lisp name and that they should lose the lisp
syntax. And while not dead, Dylan has failed even to build as large
a user base as Common Lisp has (which has retained the name and the
syntax). Not that they were competing with Lisp, but in fact they
were trying to make Dylan a commodity language.
For all of the negative talk about Lisp's popuarity, there is simply
no escaping the fact that Lisp really is more popular than many
people suspect. It may of course be unpopular locally, in some
management circles (those who remember paying out billions for the
AI hype of the 80's), but Common Lisp boasts several different
implementations, three of them commercial. I'm even hearing of
that old GCL being resurrected and worked on. How many other
languages, or even systems, can boast even more than two or three
implementations?
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
In article <·············@beta.franz.com>, Duane Rettig <·····@franz.com> wrote:
> It may of course be unpopular locally, in some management circles
That is my problem in a nutshell. My local management circle (and as far
as I can tell, the entire metropolitan area where I live) happens to be
one of those where Lisp is unpopular.
E.
On Fri, 18 Jan 2002 14:58:43 -0800, ···@jpl.nasa.gov (Erann Gat) wrote:
>In article <·············@beta.franz.com>, Duane Rettig <·····@franz.com> wrote:
>
>> It may of course be unpopular locally, in some management circles
>
>That is my problem in a nutshell. My local management circle (and as far
>as I can tell, the entire metropolitan area where I live) happens to be
>one of those where Lisp is unpopular.
This is a paper that gives tips on introducing Erlang in new companies. I
might apply to Cl too...
http://www.research.avayalabs.com/user/wadler/armstrong.ps
You might also try to introduce Python instead. Once they realized that Python
is a good idea, you can sell CL as a Python on steroids.
--
Fernando Rodr�guez
frr at wanadoo dot es
--
On Fri, 18 Jan 2002, Duane Rettig wrote:
[snip]
> For all of the negative talk about Lisp's popuarity, there is simply
> no escaping the fact that Lisp really is more popular than many
> people suspect.
Indeed, I make this point to Smalltalkers and Smalltalk interlopers all
the time.
Marketshare envy ;)
> It may of course be unpopular locally, in some
> management circles (those who remember paying out billions for the
> AI hype of the 80's), but Common Lisp boasts several different
> implementations, three of them commercial. I'm even hearing of
> that old GCL being resurrected and worked on. How many other
> languages, or even systems, can boast even more than two or three
> implementations?
Smalltalk! Something like 7 (or more) commercial, >5 noncommerical,
especially if you include jvm targeted ones, etc.
Plus, and perhaps more importantly, people still learn from it.
Refactoring editors, XP, the HotSpot engine, CRC cards, Wikis, lower
profile stuff like a variety of GC techniques, Ruby's object model, all
came out of the Smalltalk community. Which is why some people dabble with
Smalltalk, i.e., just to get fresh ideas.
I wish people did this more with Common Lisp, which still has *loads* of
great ideas, worked out in detail, well documented, etc. etc. etc.
This *is*, I think, a marketing/accessibility issue. Some traction is, I
think, being gotten by all the Slashdot activity. Kent's interview was a
*very* good thing, and Paul Graham (even if Arc is daft, IMHO :)) is doing
CL a lot of good by getting those case studies going.
Sometimes, small things would be cool. I wish the vendors would particpate
in the International Functional Programming Contest, just to remind folks
how CL does stuff. It's only a weekend once a year!
One thing I've tried to get the Smalltalk big vendors to do is develope
some high profile apps for certain communities. XSLT processing is a *big
deal* for a lot of people, and a lot of the more popular XSLT engines are
done in Java. I feel confident that a Smalltalk or especially a Common
Lisp implementation could blow these away.
See:
http://www.xml.com/pub/a/2001/03/28/xsltmark/index.html
If XSLT sheets were integrated into CL along the lines of SXSLT
http://okmij.org/ftp/Scheme/SXML-short-paper.html
I think people would be very much enticed into using the host language. I
know several XSLT freaks how are *gaga* over the idea of having functons
returning XPath expressions integrated into their sheets. Sad, but *very*
true.
I imagine that a port of SXSLT wouldn't be too trying for an experience
CLer, and it's a lovely tractor app.
And people are silly, right? If they have a program on their machine that
is best of breed, quite nippy, small and convenient to install,
convenient, and *happens* to be written in Common Lisp, they'll think of
CL as best of breed, nippy, small, convenient to install, and convenient.
Cheers,
Bijan Parsia.
Bijan Parsia wrote:
> Marketshare envy ;)
good point. this is allegedly a high-tech endeavor driven by all sorts
of abstract theory I could never hope to follow (having read this NG for
a while) and /some/ of its most devoted adherents are treating it like a
high school popularity contest. as a visitor said (just before getting
his ass flamed off for him) we are so /human/ in here!
> One thing I've tried to get the Smalltalk big vendors to do is develope
> some high profile apps for certain communities. XSLT processing is a *big
> deal* for a lot of people, and a lot of the more popular XSLT engines are
> done in Java. I feel confident that a Smalltalk or especially a Common
> Lisp implementation could blow these away.
what? you want to win via substance?! I am thinking a new skirt and a
different shade of lipstick...
> I think people would be very much enticed into using the host language. I
> know several XSLT freaks how are *gaga* over the idea of having functons
> returning XPath expressions integrated into their sheets. Sad, but *very*
> true.
check. remember all that excitement in java over <gasp> automatic GC?
kenzo
clinisys
On Fri, 18 Jan 2002 22:07:37 GMT, Duane Rettig <·····@franz.com> wrote:
> AI hype of the 80's), but Common Lisp boasts several different
> implementations, three of them commercial. I'm even hearing of
If the 3 commercial implementations you refer to are ACL, LW[*] and MCL,
there are possibly more: Corman Lisp, the Gold Hill product (Golden Common
Lisp?), Medley/Venue and, of course, Symbolics. I don't know about their
current status, but they seem to be still commercially available.
Paolo
[*] And LCL.
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://web.mclink.it/amoroso/ency/README
[http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/]
>>>>> On 18 Jan 2002 09:17:29 -0500, Thom Goodsell ("Thom") writes:
Thom> Wait, I know, how about "Common Lisp"!
Mainstream Lisp
Plus Lisp
Advanced Lisp
Challenge Lisp
Christopher Stacy <······@swingandcircle.com> writes:
> >>>>> On 18 Jan 2002 09:17:29 -0500, Thom Goodsell ("Thom") writes:
> Thom> Wait, I know, how about "Common Lisp"!
>
> Mainstream Lisp
> Plus Lisp
> Advanced Lisp
> Challenge Lisp
incf
--
(concatenate 'string "cbbrowne" ·@canada.com")
http://www.ntlug.org/~cbbrowne/advocacy.html
"The computer is the ultimate polluter: its feces are
indistinguishable from the food it produces." -- Alan Perlis
··········@hotmail.com (larry) wrote in message news:<····························@posting.google.com>...
> CL - the programmable programming language!
The programming language for Computer Lovers (CL).
CL -- Kicking ass and taking down Bignums
Software Scavenger wrote:
>
> ··········@hotmail.com (larry) wrote in message news:<····························@posting.google.com>...
>
> > CL - the programmable programming language!
>
> The programming language for Computer Lovers (CL).
"Wade Humeniuk" <········@cadvision.com> wrote in message
·················@news3.cadvision.com...
> I have my own ideas why things are the way they are. They may be right or
> they may be wrong. But I do not concentrate or focus on that. I use Lisp
> because it appeals to me. I find it useful and productive. It is not
> popular, but if people like me do not even use it, who will? Nor do I
view
> Lisp (and me) as in a win-lose situation. I do not mind being in the
> minority when it comes to programming language choice, I am just trying to
> be genuine, who I really am. I am not happy programming in C++. If being
> who I am is not enough, then so be it. I have been sincere. Hopefully by
> allowing myself to be me, I will allow others to have the courage to be
who
> they are. The issues go far beyond a simple programming language choice.
I sometimes get the impression that human brains are not optimised for
finding truth but for obscuring our inner will with rationalisations; maybe
for the purpose of persuading ourselves and others that it's right to do
what we're going to do anyway, and/or that there's a solid rational basis
for believing what we already believe. Newsgroup discussions about technical
preferences are a great place to see this in action.
So I can't resist a "me too" here. People don't often discuss their language
choices as simply and honestly as this. I appreciate hearing it expressed
this way.
FWIW, I feel very much the same. I've enjoyed programming for a few years,
in a variety of languages, but Lisp has been a wonderful discovery for me.
It's not just the unique features of Lisp that make it so enjoyable to use.
I don't really know what it is. But I'm beyond needing 'technical support'
for my gut feeling that Lisp is GOOD.
As impressive as Erann Gat's technical track record is, I find his arguments
psychologically suspect. I (possibly mistakenly) parse his opinions
something like this:
***********
Lisp no longer seems as great to me as it once did, because other languages
have caught up in many ways. (But did those other languages take features
AWAY from Lisp in the process of borrowing them? Aren't they still present
in Lisp, and aren't they just as advantageous in Lisp as they are in the
newer languages? Do any of the new languages combine ALL of the great
features of Lisp, in addition to all their modern conveniences?).
Very smart people have achieved great results with non-Lisp languages. So
the features of Lisp are less compelling than I once believed. (Unless Erann
believed that Lisp was the ONLY language that smart people could use to
build amazing software, in spite of abundant proof to the contrary, this
seems quite illogical. He argues that those smart people who achieved great
results with non-Lisp languages could not have done what they did in Lisp
because .... because .... because ....
Because Lisp is too slow for some of the speed-critical parts of a project
like Google. For those critical parts we need the speed of C or asm. For the
other parts, Python is fast enough. (Fine - but if it's reasonable to use a
combination of Python and C, why not Lisp and C, or Lisp and asm? This just
doesn't make sense to me)).
I'm prepared to use languages that are slightly less powerful than Lisp
because, in combination with their other conveniences, they're good enough
to make Lisp less necessary than I once thought. (Fair enough) ;-)
***********
Unless I'm seriously misunderstanding and (unintentionally) misrepresenting
Erann's arguments, they are quite hollow. To me, they sound like little more
than psychological rationalisations for having 'moved on'.
> The computing story is not over yet, who knows what will happen tommorrow
or
> 20 years down the road? NextSTEP is reborn as Aqua, those who have been
> able to make things happen (through shear force of character and will)
just
> havn't noticed Lisp yet.
Still possible, I guess.
In article <·····················@ozemail.com.au>, "Patrick W."
<·······@yahoo.com.au> wrote:
> As impressive as Erann Gat's technical track record is, I find his arguments
> psychologically suspect. I (possibly mistakenly) parse his opinions
> something like this:
Thanks for the compliment, but you are misrepresenting my position.
> Lisp no longer seems as great to me as it once did, because other languages
> have caught up in many ways.
Lisp seems just as great to me as it ever did (perhaps even more so as the
result of this discussion). It is Lisp's *advantage* over other languages
that is not as compelling to me as it once was, not because Lisp is worse,
but because other languages have gotten better.
> Very smart people have achieved great results with non-Lisp languages. So
> the features of Lisp are less compelling than I once believed.
No. Smart people have achieved great results in C++, which I had thought
was categorically impossible. C++ seemed like such a complex mess that I
was convinced that any C++ project of any substantial size and complexity
was doomed to be riddled with bugs caused by people's inevitable deviation
from the zillions of coding standards that need to be followed to avoid
the myriad known pitfalls in C++ coding. Turns out I was wrong. I also
thought that unless you programmed in Lisp you had a choice between fast
development and slow execution (Perl, Python), or slow development and
fast execution (C/C++). Only Lisp gave you a good mix of both. That
turns out to be wrong too. Remember the 9-nines problem? I compared
solutions in both Lisp and Python. The Python code was shorter and ran
about twice as fast (compared to MCL). I've seen similar benchmark
results for Perl.
> Because Lisp is too slow for some of the speed-critical parts of a project
> like Google. For those critical parts we need the speed of C or asm. For the
> other parts, Python is fast enough. (Fine - but if it's reasonable to use a
> combination of Python and C, why not Lisp and C, or Lisp and asm? This just
> doesn't make sense to me)).
I never said nor meant to imply that it's unreasonable to use a
combination of Lisp and C. But 1) it's easier to get Python and C to work
together than Lisp and C, 2) if the interesting parts of the code are
written in C, what is the point of throwing Lisp (or any other language
for that matter) into the mix?
> I'm prepared to use languages that are slightly less powerful than Lisp
> because, in combination with their other conveniences, they're good enough
> to make Lisp less necessary than I once thought. (Fair enough) ;-)
That is a fair restatement of (part of) my position.
> Unless I'm seriously misunderstanding and (unintentionally) misrepresenting
> Erann's arguments, they are quite hollow. To me, they sound like little more
> than psychological rationalisations for having 'moved on'.
Please give me a little more credit that that. Even if I felt the need to
"rationalize" my having "moved on", why on earth would I do it on
comp.lang.lisp for all the world to see for all eternity?
I'm making these arguments for two reasons. One, I was asked a question,
and these "arguments" (I don't really see them as arguments) are my honest
answer. Second, as I said, I wish things were different. All else being
equal I would prefer to program in Lisp. But all else is not equal, and I
see that as a problem that can be and ought to be solved. I can't solve
it alone, so I'm hoping to find other people who think that this problem
exists and ought to be solved to work together on it. That's the reason
I'm sympathetic to Arc, not because I think Arc is necessarily a great
language, but because it starts from the premise that *something* needs to
change.
I know that many people on this newsgroup disagree with that premise.
Nothing needs to change. Everything is just hunky dory. Well, I'm happy
for you. But in my part of the world programming in Lisp is severely
career-limiting, and I find that most unhunky and undory.
So, no, I am not trying to rationalize having moved on. I am rebelling
against having moved on. And I am looking for help in changing the
circumstances that have caused me (and many, many other people who don't
care as much as I do and who don't hang out on this newsgroup) to move on.
E.
>>>>> "EG" == Erann Gat <···@jpl.nasa.gov> writes:
[... deleted a lot...]
EG> I never said nor meant to imply that it's unreasonable to use
EG> a combination of Lisp and C. But 1) it's easier to get Python
EG> and C to work together than Lisp and C, 2) if the interesting
EG> parts of the code are written in C, what is the point of
EG> throwing Lisp (or any other language for that matter) into the
EG> mix? [...]
For 1) I am not convinced this is a language problem. I am also not sure
you are asserting that it is, but if you are, maybe you could tell us why you
think that?
For 2) it depends on the development model you have in mind. You can
do your exploration in Lisp, pushing down the parts that are
performance critical but well understood to C _while retaining_ the
convenience of the Lisp development environment. Again I think this
NOT a language problem but an implementation issue. If you can write
your Lisp code in a way that punting to C becomes possible (ie 1-1
correspondence with C-native data types and such) the gain comes from
the better code generator that comes with the C compiler. This is
what I think based on some but not a huge amount of experience and I
would be thrilled to read your account.
cheers,
BM
Bulent Murtezaoglu <··@acm.org> writes:
> >>>>> "EG" == Erann Gat <···@jpl.nasa.gov> writes:
> [... deleted a lot...]
> EG> I never said nor meant to imply that it's unreasonable to use
> EG> a combination of Lisp and C. But 1) it's easier to get Python
> EG> and C to work together than Lisp and C, 2) if the interesting
> EG> parts of the code are written in C, what is the point of
> EG> throwing Lisp (or any other language for that matter) into the
> EG> mix? [...]
>
> For 1) I am not convinced this is a language problem. I am also not
> sure you are asserting that it is, but if you are, maybe you could
> tell us why you think that?
I can say from personal experience that this is *not* a language
issue. You can in-line C++ code in CL-80, no problem. CL-80 isn't
full CL (yet), but I don't see any mines in the unimplemented parts of
the spec wrt this. Oh, assembly language, too. C and C++ are quite
different languages, but for the purpose of this point, they can work
interchangeably. This is not a language issue.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
In article <··············@nkapi.internal>, Bulent Murtezaoglu
<··@acm.org> wrote:
> >>>>> "EG" == Erann Gat <···@jpl.nasa.gov> writes:
> [... deleted a lot...]
> EG> I never said nor meant to imply that it's unreasonable to use
> EG> a combination of Lisp and C. But 1) it's easier to get Python
> EG> and C to work together than Lisp and C, 2) if the interesting
> EG> parts of the code are written in C, what is the point of
> EG> throwing Lisp (or any other language for that matter) into the
> EG> mix? [...]
>
> For 1) I am not convinced this is a language problem. I am also not sure
> you are asserting that it is, but if you are, maybe you could tell us why you
> think that?
I'm not sure what you mean by "this". I didn't say anything was a
problem, language or otherwise. All I said was that you can mix Lisp and
C, but that this isn't a panacea.
> For 2) it depends on the development model you have in mind. You can
> do your exploration in Lisp, pushing down the parts that are
> performance critical but well understood to C _while retaining_ the
> convenience of the Lisp development environment. Again I think this
> NOT a language problem but an implementation issue. If you can write
> your Lisp code in a way that punting to C becomes possible (ie 1-1
> correspondence with C-native data types and such) the gain comes from
> the better code generator that comes with the C compiler. This is
> what I think based on some but not a huge amount of experience and I
> would be thrilled to read your account.
Sometimes this works, but not always. For example, suppose you write a
search engine in Lisp and discover that the performance bottleneck is in
your HTML parser. So you move the HTML parser into C only to discover
that the performance bottleneck is now in the FFI.
But this is all really tangential to my main point which is that the
arguments for using Lisp are less compelling now than they were ten years
ago, and that something ought to be done about it.
E.
* Erann Gat wrote:
> I never said nor meant to imply that it's unreasonable to use a
> combination of Lisp and C. But 1) it's easier to get Python and C to work
> together than Lisp and C, 2) if the interesting parts of the code are
> written in C, what is the point of throwing Lisp (or any other language
> for that matter) into the mix?
For which particular Lisp implementation do you mean this, or are you
implying that it is just inherently easier for all Lisp
implementations at any time in the past, present or future?
--tim
In article <···············@cley.com>, Tim Bradshaw <···@cley.com> wrote:
> * Erann Gat wrote:
>
> > I never said nor meant to imply that it's unreasonable to use a
> > combination of Lisp and C. But 1) it's easier to get Python and C to work
> > together than Lisp and C, 2) if the interesting parts of the code are
> > written in C, what is the point of throwing Lisp (or any other language
> > for that matter) into the mix?
>
> For which particular Lisp implementation do you mean this, or are you
> implying that it is just inherently easier for all Lisp
> implementations at any time in the past, present or future?
I mean it with varying degrees of certainty for 1) particular Lisp
implementations I have used in the past at the time that I used them
(CLisp, Allegro, Harlequin, and MCL, all two years ago or more) and 2) all
Lisp implementations at any time in the past, present or future.
Obviously I am less certain about (2) than I am about (1). Here are the
reasons I believe that (2) might be true: Python has a reference
implementation written in C, and a strong tradition of extending the
language with modules written in C. This gives it a de facto FFI standard
which Lisp does not have. It also has a de facto standard definition of
the data structures it uses for its memory management system written in
terms of C (i.e. the headers for its refcount system have a standard .h
file that defines them). Lisp lacks such a standard, and considering the
resistance of the Lisp community to change of any kind, let alone one of
this magnitude, seems unlikely to have one any time in the future.
E.
From: Gene Michael Stover
Subject: Lisp with other languages via pipes (was Re: The true faith)
Date:
Message-ID: <3C5A5716.7020105@gte.net>
Erann Gat wrote:
> In article <···············@cley.com>, Tim Bradshaw <···@cley.com> wrote:
>
>
>>* Erann Gat wrote:
>>
>>
>>>I never said nor meant to imply that it's unreasonable to use a
>>>combination of Lisp and C. But 1) it's easier to get Python and C to work
>>>together than Lisp and C, 2) if the interesting parts of the code are
>>>written in C, what is the point of throwing Lisp (or any other language
>>>for that matter) into the mix?
I know I'm stretching the definition of using Lisp &
C together, but in a way, I do it all the time, like
this:
program-i-wrote-in-c | program-i-wrote-in-lisp
Lisp works great with Unix pipes.
It's sort of the ultimate language for pipes because it's
so easy to read & write complex data. Combine that with
the usual Unix utilities, make sure *PRINT-PRETTY* is
NIL (so you can make sure lists print on a single line of
text), & life is good. In fact, I did a quick consulting
job today in which I wrote a couple tiny Lisp programs &
then used shell scripts to pipe them to & from a bunch
of plain old Unix utilities.
I know I'm stretching the limits of what it means to use
C with Lisp, but pipes are a way of doing it, & they
work really well.
gene
From: Christopher Browne
Subject: Re: Lisp with other languages via pipes (was Re: The true faith)
Date:
Message-ID: <m3zo2ttga1.fsf@chvatal.cbbrowne.com>
The world rejoiced as Gene Michael Stover <········@gte.net> wrote:
> Erann Gat wrote:
>> In article <···············@cley.com>, Tim Bradshaw <···@cley.com> wrote:
>>>* Erann Gat wrote:
>>>>I never said nor meant to imply that it's unreasonable to use a
>>>>combination of Lisp and C. But 1) it's easier to get Python and C
>>>>to work together than Lisp and C, 2) if the interesting parts of
>>>>the code are written in C, what is the point of throwing Lisp (or
>>>>any other language for that matter) into the mix?
> I know I'm stretching the definition of using Lisp & C together, but
> in a way, I do it all the time, like this:
> program-i-wrote-in-c | program-i-wrote-in-lisp
This is more or less equivalent to saying:
(loop
with langs = '(c perl ocaml ada python icon fortran c++ forth
scheme ,*additional-languages*)
for l1 in langs
do (loop for l2 in langs
do (format t "program-i-wrote-in-~A program-i-wrote-in-~A~%"
l1 l2)))
--
(reverse (concatenate 'string ··········@" "enworbbc"))
http://www3.sympatico.ca/cbbrowne/lisp.html
"As soon as we started programming, we found to our surprise that it
wasn't as easy to get programs right as we had thought. Debugging had
to be discovered. I can remember the exact instant when I realized
that a large part of my life from then on was going to be spent in
finding mistakes in my own programs."
-- Maurice Wilkes discovers debugging, 1949
···@jpl.nasa.gov (Erann Gat) wrote in message news:<····················@192.168.1.50>...
> turns out to be wrong too. Remember the 9-nines problem? I compared
> solutions in both Lisp and Python. The Python code was shorter and ran
> about twice as fast (compared to MCL). I've seen similar benchmark
> results for Perl.
It might be illuminating to post the code of the different versions of
the nine nines program, and their timings. Someone might notice a way
to make the Lisp version shorter and faster. If Python beats Lisp,
it's very impressive, because Python has a reputation of being much
slower than Lisp. Was the Lisp code compiled?
"Erann Gat" <···@jpl.nasa.gov> wrote in message
·························@192.168.1.50...
> Lisp seems just as great to me as it ever did (perhaps even more so as the
> result of this discussion). It is Lisp's *advantage* over other languages
> that is not as compelling to me as it once was, not because Lisp is worse,
> but because other languages have gotten better.
Sure. Being a relative newcomer to Lisp, I tend to overlook the fact that
there must once have been much greater gulf between Lisp and other popular
languages. I approached it from the opposite direction; didn't discover Lisp
until quite some time after exposure to C(++), Java and Python.
Even from my perspective, the gap between Lisp and the alternatives is still
wide enough for a newbie to be strongly impressed by it. I still distinctly
remember the impression I had when I brought home a copy of Winston & Horn.
Felt like an archaeologist uncovering relics of a highly advanced lost
civilisation in my back yard.
> > Unless I'm seriously misunderstanding and (unintentionally)
misrepresenting
> > Erann's arguments, they are quite hollow. To me, they sound like little
more
> > than psychological rationalisations for having 'moved on'.
>
> Please give me a little more credit that that. Even if I felt the need to
> "rationalize" my having "moved on", why on earth would I do it on
> comp.lang.lisp for all the world to see for all eternity?
I suspected something along the lines of Kenny Tilton's Stendhal quote.
Turns out I was mistaken. Sorry for the offence.
> ... I wish things were different. All else being
> equal I would prefer to program in Lisp. But all else is not equal, and I
> see that as a problem that can be and ought to be solved. I can't solve
> it alone, so I'm hoping to find other people who think that this problem
> exists and ought to be solved to work together on it. That's the reason
> I'm sympathetic to Arc, not because I think Arc is necessarily a great
> language, but because it starts from the premise that *something* needs to
> change.
>
> I know that many people on this newsgroup disagree with that premise.
> Nothing needs to change. Everything is just hunky dory. Well, I'm happy
> for you. But in my part of the world programming in Lisp is severely
> career-limiting, and I find that most unhunky and undory.
FWIW, I concur wholeheartedly with the goal. I'd like to see new life in the
Lisp community; especially a healthier Lisp job market. (And as for the
means, why not? I don't see how it will harm the conservative Common Lisp
community if a more vibrant experimentally-minded hacker community
flourishes alongside it).
On Tue, 15 Jan 2002, Erann Gat wrote:
> In article <············@news3.cadvision.com>, "Wade Humeniuk"
> <········@cadvision.com> wrote:
[snip]
> > ideas from your head into a rigorous description. Of course most of your
> > stuff has been tossed and obviously not appreciated. I am sorry for that.
>
> The stuff I've written that has been tossed pales in comparison to the
> stuff that other people have written and has been tossed (e.g. Genera,
> Smalltalk, NextSTEP).
Er...this is a rather poor list of "tossed" things:
Genera, still sold both in original form (old lisp machines) and
opengenera; ok, not a huge market force :)
Smalltalk, 7-10 active implementations, 2 superduper enterprise
versions with combined seats in the multi-tens of
thousands, not counting non-commerical
versions; conferences, new books (3 Squeak books out in
the past years; Dolphin books, etc.); still big
player in developing and pushing ideas, e.g., XP,
Active Essays, etc.; active user communities, etc. etc.
NextSTEP == MacOS/X (a good chunk of it), plus someone just
annouced (I believe I saw it on slashdot) that GnuStep
was being bundled up with a linux kernal in to what
certainly seemed like a NeXT work alike.
These are just bad examples, I think (though Genera is closest). How about
InterLisp (killed by Common Lisp), the Newton (*TONS* of money just
tossed, her), GO (same), SK8 (from Apple, *very* slick programming
langauge), Dylan (ok, that was a bit of joke, but the Apple Dylan
Enviroment was, like SK8, a huge chunk of nifty code (in MCL) that was
basically tossed; I mean, you can still use it, but it's really quite
moribund), etc.
> Rather than wringing our hands about how
> unappreciated we are I think it's much more productive to start from the
> premise that there might have been some good reasons all that stuff got
> tossed,
And good reasons why some stuff didn't. It's really hard to see how
Smalltalk and NextStep have been *tossed*! Every new mac is shipped with
Mac OS X, which is a direct line decendent of NextStep! Ok, MS dominates,
but Apple looks to be the Unix box volume *leader*, by a large margin.
That just isn't having been tossed. Apple paid $400 million for it :)
Oh ohoh, opendoc, *wow* there was a LOT of code from all *sorts* of
companies (Apple, IBM, tons of smaller companies) just thrown in the
garbage. Taligent....God, they had to dig new landfills for that. Or maybe
that's what filled the salt caverns in Nevada (it's tons of C++ code,
after all).
> to try to understand what those reasons were, and then to take
> those lessons and move on to the next thing.
Yes, but can I urge realistic evaluation of the current state of things,
too? There's lots of ways of being successful and happy without being the
top dog, the big gun, or the evil monopoly. Given that there can't be
more than one top dog (at any time), only a few (we hope) big guns, and
only one (in any area at a time) evil monopoly, the rest of us, of
necessity, have to figure other ways to be. I personally prefer not to
have to cling to the top dog, polish the big gun, or toe the line of an
evil monopoly.
Perhaps surprisingly, that's not all that hard to do, in many cases.
Cheers,
Bijan Parsia.
In article
<··········································@login9.isis.unc.edu>, Bijan
Parsia <·······@email.unc.edu> wrote:
> Er...this is a rather poor list of "tossed" things:
Yes. The trouble with things that have really been tossed is not many
people (including myself) know about them.
E.
On Wed, 16 Jan 2002, Erann Gat wrote:
> In article
> <··········································@login9.isis.unc.edu>, Bijan
> Parsia <·······@email.unc.edu> wrote:
>
> > Er...this is a rather poor list of "tossed" things:
>
> Yes. The trouble with things that have really been tossed is not many
> people (including myself) know about them.
Er...InterLisp (though there is code available), Taligent, SK8, Apple
Dylan Environment, Hypercard looks like it's going that way, the Newton
*definitely*, lot's of Ashton-Tate software (remember them?)...
Some of these thing may be revivable (SK8 source code is available, for
example, Newton's isn't and is pretty much a mess).
So, I actually don't think it's *that* hard to find these stories! Even if
not, it seems odd to illustrate your point with...erhm...not examples of
what you're talking about :)
Cheers,
Bijan Parsia.
>>>>> "Erann" == Erann Gat <···@jpl.nasa.gov> writes:
Erann> In article <····························@posting.google.com>,
Erann> ··········@mailandnews.com (Software Scavenger) wrote:
>> ···@jpl.nasa.gov (Erann Gat) wrote in message
Erann> news:<····················@eglaptop.jpl.nasa.gov>...
>>
>> > Apostle of the True Faith. I've been a Lisp programmer for twenty years.
>>
>> During those 20 years, did you write some interesting programs, which
>> we could discuss here?
Erann> See http://groups.google.com/groups?hl=en&selm=1f4c5c5c.0108252226.330d6cac%40posting.google.com
Looking at that impressive list, and given your Google experiences,
which of the old projects would you done differently today? Where
would the extensive libraries of modern languages (if they had been
available at the time) been a great benefit?
------------------------+-----------------------------------------------------
Christian Lynbech | Ericsson Telebit, Skanderborgvej 232, DK-8260 Viby J
Phone: +45 8938 5244 | email: ·················@ted.ericsson.dk
Fax: +45 8938 5101 | web: www.ericsson.com
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- ·······@hal.com (Michael A. Petonic)
In article <··············@chl.ted.dk.eu.ericsson.se>, Christian Lynbech
<·················@ted.ericsson.dk> wrote:
> >>>>> "Erann" == Erann Gat <···@jpl.nasa.gov> writes:
>
> Erann> In article <····························@posting.google.com>,
> Erann> ··········@mailandnews.com (Software Scavenger) wrote:
>
> >> ···@jpl.nasa.gov (Erann Gat) wrote in message
> Erann> news:<····················@eglaptop.jpl.nasa.gov>...
> >>
> >> > Apostle of the True Faith. I've been a Lisp programmer for twenty
years.
> >>
> >> During those 20 years, did you write some interesting programs, which
> >> we could discuss here?
>
> Erann> See
http://groups.google.com/groups?hl=en&selm=1f4c5c5c.0108252226.330d6cac%40posting.google.com
>
> Looking at that impressive list, and given your Google experiences,
> which of the old projects would you done differently today? Where
> would the extensive libraries of modern languages (if they had been
> available at the time) been a great benefit?
For the most part I would not have done anything differently. Lisp was
definitely the right choice at the time. But two of my recent projects
(one in Lisp and one in Java) I would have done in Python if I'd know then
what I know now. Both of these were relatively simple
non-performance-critical Web apps.
<opinion>
BTW, I would much rather see Lisp change to meet modern challenges than
see Lisp programmers convert to Python. Lisp is still better than Python
from purely language-based considerations. But the extent to which Lisp
is better than Python is much smaller than the extent to which Lisp is
better than C, to the point where non-language considerations (like not
having to fight with management) give Python the edge in some cases.
</opinion>
E.
---
Es is nicht gasagt das es besser wird wenn es anders wirt. Wenn es
aber besser werden soll muss es anders werden. (Loosely translated:
Different is not necessarily better. But better is necessarily
different.)
-- G. Ch. Lichtenberg
···@jpl.nasa.gov (Erann Gat) writes:
> <opinion>
> BTW, I would much rather see Lisp change to meet modern challenges than
> see Lisp programmers convert to Python. Lisp is still better than Python
> from purely language-based considerations. But the extent to which Lisp
> is better than Python is much smaller than the extent to which Lisp is
> better than C, to the point where non-language considerations (like not
> having to fight with management) give Python the edge in some cases.
> </opinion>
At Franz, we agree with you and are continually looking for ways
to extend our implementation of CL (through extensions) to make
it better and better.
Could you give us a wish-list of specific ways you'd like to see
Lisp change?
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
In article <·············@beta.franz.com>, Duane Rettig <·····@franz.com> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > <opinion>
> > BTW, I would much rather see Lisp change to meet modern challenges than
> > see Lisp programmers convert to Python. Lisp is still better than Python
> > from purely language-based considerations. But the extent to which Lisp
> > is better than Python is much smaller than the extent to which Lisp is
> > better than C, to the point where non-language considerations (like not
> > having to fight with management) give Python the edge in some cases.
> > </opinion>
>
> At Franz, we agree with you and are continually looking for ways
> to extend our implementation of CL (through extensions) to make
> it better and better.
>
> Could you give us a wish-list of specific ways you'd like to see
> Lisp change?
A complete answer to that question would be very, very long. As a start
I'll recommend reading http://www.paulgraham.com/popular.html, with which
I mostly agree.
Here are some representative items from my wish list:
1. I want to fill in the semantic space of function calls, that is, I
want to be able to put something other than a function or a closure in the
car of a list and have the result be something meaningful. Examples: I'd
like to be able to call an array and have the result be equivalent to a
call to aref. I'd like to be able to call a hash table and have the
result be equivalent to a call to gethash. I'd like to be able to call a
CLOS instance and have the result be equivalent by default to a call to
slot-value. And I'd like a way to override that behavior. And I'd like
all these things to be setfable.
2. I'd like to be able to write C code in Lisp, that is, I'd like to have
a defined subset of the language whose semantics are essentially the
semantics of C and be confident that the resulting code would be
essentially the same as what a C compiler would have generated. I'd like
to be able to use the resulting subset of Lisp (LiCp?) to, e.g., write a
Linux device driver. I'd like to be able to call C code (real C code
generated by a C compiler, not LiCp code) by doing nothing more than
(include "foo.h").
3. I want standardized regular expression and ODBC client libraries.
4. I'd like it to be called something other than Lisp. That is, I'd like
Lisp's features in a language with a different name (like Arc). This may
seem petty, but in my experience the prejudice against Lisp is immense,
and I'm sick and tired of fighting about it.
E.
Erann Gat wrote:
> 4. I'd like it to be called something other than Lisp.
Doesn't matter. The second people see the parens, they'd know.
> This may
> seem petty, but in my experience the prejudice against Lisp is immense,
> and I'm sick and tired of fighting about it.
It does seem petty. I understand and sympathise with your fatigue and
disheartenment, but would urge that you fight on, rather than succumbing to
the tides of trendiness and (yes) prejudice. Those who don't fight
prejudice are doomed to live in a world where decisions are made by
prejudice.
faa
On Tue, 15 Jan 2002 21:38:41 -0800, "Frank A. Adrian"
<·······@ancar.org> wrote:
>Erann Gat wrote:
>> 4. I'd like it to be called something other than Lisp.
>
>Doesn't matter. The second people see the parens, they'd know.
Yeah but you abandon parens and use the secret weapon...
Curly braces !
Seriously the C crowd think that curly braces are ok.
So code like
(defun i-propice-load ()
(load-foreign-libraries
nil
(list "/usr/local/propice/lib/libmp.a"
"-lm"
"-lc")))
would become :
{defun i-propice-load ()
{load-foreign-libraries
nil
{list "/usr/local/propice/lib/libmp.a"
"-lm"
"-lc"}}}
voila !
---------------------------------------------------------
Devising your own font (Devanagari, pinhead graphics, etc.)
and using it in the mail is a good tactic,as is finding some way to use existing obscure fonts.
Aramaic , Pre-Rashi Hebrew and Sanskrit are particularly useful in this regard.
-- from the Symbolics Guidelines for Sending Mail
Israel r t <········@optushome.com.au> writes:
> "-lc"}}}
No, actually the ")))" is the problem, and "}}}" doesn't fix it. The
solution is to align the delimiters vertically when their contents are
aligned vertically. Emacs brace matching is no substitute for just
doing it clearly in the first place. Some languages (python, haskell)
take seriously the claim that only indentation should matter; the
")))" convention fails to achieve those benefits.
I'm aware that the official lisp religion says otherwise, so don't
bother following up to tell me that.
{defun i-propice-load ()
{load-native-libraries ;; C is NATIVE, lisp is foreign
nil
{list "/usr/local/propice/lib/libmp.a"
"-lm"
"-lc"
}
}
}
Israel r t <········@optushome.com.au> writes:
> On Tue, 15 Jan 2002 21:38:41 -0800, "Frank A. Adrian"
> <·······@ancar.org> wrote:
>
>>Erann Gat wrote:
>>> 4. I'd like it to be called something other than Lisp.
>>
>>Doesn't matter. The second people see the parens, they'd know.
>
> Yeah but you abandon parens and use the secret weapon...
> Curly braces !
>
> Seriously the C crowd think that curly braces are ok.
>
> So code like
> (defun i-propice-load ()
> (load-foreign-libraries
> nil
> (list "/usr/local/propice/lib/libmp.a"
> "-lm"
> "-lc")))
>
> would become :
>
> {defun i-propice-load ()
> {load-foreign-libraries
> nil
> {list "/usr/local/propice/lib/libmp.a"
> "-lm"
> "-lc"}}}
>
> voila !
>
(set-macro-character #\{ #'(lambda (stream char)
(declare (ignore char))
(read-delimited-list #\} stream)))
(set-macro-character #\} (get-macro-character #\)))
Then:
* {defun range(from to)
{loop for n from from to to
collect n}}
RANGE
* {defun fact(n)
{reduce #'* {range 1 n}}}
FACT
* {fact 3}
6
*
>
> ---------------------------------------------------------
> Devising your own font (Devanagari, pinhead graphics, etc.)
> and using it in the mail is a good tactic,as is finding some way to use existing obscure fonts.
> Aramaic , Pre-Rashi Hebrew and Sanskrit are particularly useful in this regard.
> -- from the Symbolics Guidelines for Sending Mail
hth,
--
BPT <···@tunes.org> /"\ ASCII Ribbon Campaign
backronym for Linux: \ / No HTML or RTF in mail
Linux Is Not Unix X No MS-Word in mail
Meme plague ;) ---------> / \ Respect Open Standards
On Tue, 15 Jan 2002, Frank A. Adrian wrote:
> Erann Gat wrote:
> > 4. I'd like it to be called something other than Lisp.
>
> Doesn't matter. The second people see the parens, they'd know.
[snip]
Which is why a indentation model (hey! It's like Python!) might
work. In a decent editor, the parens could even be actually there, but not
displayed.
Cheers,
Bijan Parsia.
On 1/15/02 20.07, in article ····················@eglaptop.jpl.nasa.gov,
"Erann Gat" <···@jpl.nasa.gov> wrote:
> 2. I'd like to be able to write C code in Lisp, that is, I'd like to have
> a defined subset of the language whose semantics are essentially the
> semantics of C and be confident that the resulting code would be
> essentially the same as what a C compiler would have generated. I'd like
> to be able to use the resulting subset of Lisp (LiCp?) to, e.g., write a
> Linux device driver. I'd like to be able to call C code (real C code
> generated by a C compiler, not LiCp code) by doing nothing more than
> (include "foo.h").
I agree with the first part but not the second part. I have no need for
another standalone C, since I'm already an expert C programmer. Being able
to do (include "foo.h") is an FFI issue and not an extend Lisp issue. (And
a C compiler doesn't emit C code; C programmers do.)
What I would like to see is a subset of Lisp that can see memory and
translates into machine code in a fairly straightforward manner, much as C
does. The only types here would be byte, word and double float and
sequentially allocated regions of these. (I don't care much about whether C
semantics are preserved or not, so long as there is a c-call operator for
making external calls.)
This would be immensely useful for implementing performance critical code
and interfaces to UNIX system calls. At a minimum, I'd like to have special
operators for IEEE double, Z/2^32 and Z/2^64.
> 4. I'd like it to be called something other than Lisp. That is, I'd like
> Lisp's features in a language with a different name (like Arc). This may
> seem petty, but in my experience the prejudice against Lisp is immense,
> and I'm sick and tired of fighting about it.
This is stupid. If you are sick of fighting it, stop. If people don't like
Lisp, they shouldn't be forced to use it. Programmers who are unhappy tend
to be unproductive. If you're not happy using Lisp any more, I would
recommend that you drop it. Evangelism other than teaching is a waste of
time.
I've looked at Arc, and it strikes me as a step backwards more than anything
else. Instead of trying to incorporate successful ideas from other
languages, Graham seems to be trying to create a language that's strictly
worse than what's already there in the name of typing less. The efficiency
model is a mistake. Profilers are important, but Lisp efficiency has enough
twists and dark corners already. Arc offers us more of this and a claim
that if you write server apps the profiler will be good. At least Common
Lisp efficiency is well understood by now; Arc will take a while to get that
far. A forward looking language would concentrate on making more obvious
what's fast enough to be put in the inner loop and what isn't (i.e., do for
speed what high level languages already do for expressing algorithms and
program structure).
My general feeling about the Arc document is that it's not a new language so
much as a ``I program in Lisp this way, so here's Lisp without all the crap
I don't use/want/need'' document. Since not everybody is Paul Graham, I'm
not surprised that the reaction to it hasn't been overwhelmingly positive.
I would be happy to be proven wrong.
^L
In article <····················@cs.umass.edu>, Louis Theran
<······@cs.umass.edu> wrote:
> > 4. I'd like it to be called something other than Lisp. That is, I'd like
> > Lisp's features in a language with a different name (like Arc). This may
> > seem petty, but in my experience the prejudice against Lisp is immense,
> > and I'm sick and tired of fighting about it.
>
> This is stupid. If you are sick of fighting it, stop. If people don't like
> Lisp, they shouldn't be forced to use it.
You misunderstand. I haven't been fighting people who don't like Lisp
trying to force them to use it. I've been fighting managers who want to
prevent people who do like Lisp from using it. And I have taken your
advice and stopped fighting. That's why I don't use Lisp any more.
E.
In article <····················@cs.umass.edu>, Louis Theran
<······@cs.umass.edu> wrote:
> On 1/15/02 20.07, in article ····················@eglaptop.jpl.nasa.gov,
> "Erann Gat" <···@jpl.nasa.gov> wrote:
>
> > 2. I'd like to be able to write C code in Lisp, that is, I'd like to have
> > a defined subset of the language whose semantics are essentially the
> > semantics of C and be confident that the resulting code would be
> > essentially the same as what a C compiler would have generated. I'd like
> > to be able to use the resulting subset of Lisp (LiCp?) to, e.g., write a
> > Linux device driver. I'd like to be able to call C code (real C code
> > generated by a C compiler, not LiCp code) by doing nothing more than
> > (include "foo.h").
>
> I agree with the first part but not the second part. I have no need for
> another standalone C, since I'm already an expert C programmer. Being able
> to do (include "foo.h") is an FFI issue and not an extend Lisp issue. (And
> a C compiler doesn't emit C code; C programmers do.)
Agreed. Though (include "foo.h") would be a very convenient FFI, so I'd
like that too.
> What I would like to see is a subset of Lisp that can see memory and
> translates into machine code in a fairly straightforward manner, much as C
> does. The only types here would be byte, word and double float and
> sequentially allocated regions of these. (I don't care much about whether C
> semantics are preserved or not, so long as there is a c-call operator for
> making external calls.)
>
> This would be immensely useful for implementing performance critical code
> and interfaces to UNIX system calls. At a minimum, I'd like to have special
> operators for IEEE double, Z/2^32 and Z/2^64.
Yes, this is pretty much what I meant, but you said it better. The only
thing I'd add is that I'd like to see the subset include a conditional, a
while/until loop, and dotimes.
E.
In article <····················@eglaptop.jpl.nasa.gov>, Erann Gat wrote:
>1. I want to fill in the semantic space of function calls, that is, I
>want to be able to put something other than a function or a closure in the
>car of a list and have the result be something meaningful.
Err, you *can't* put a closure or function in the first position of a list.
You can put a function *name* there (which can be a compound thing like
a setf function or just a symbol) or you can put a lambda
expression. These things are different from function and closure objects,
respectively, which are made using the function operator. That
doesn't work:
(#'format t "~a~%" "Hello") ; Nope!
(#'(lambda (x) (+ x x)) 2) ; Nope!
Examples: I'd
>like to be able to call an array and have the result be equivalent to a
>call to aref. I'd like to be able to call a hash table and have the
>result be equivalent to a call to gethash.
What if someone else wants to call a hash table with different semantics?
Whose override wins? How do you want to establish regions of the program
where these meanings are known: some let-like environment thing?
I'd like to be able to call a
>CLOS instance and have the result be equivalent by default to a call to
>slot-value.
Would you be happy with having these objects being funcallable? I think
asking for an array object to be treated as a function to call in the
first position of a list is maybe too much, given that even a closure
in that position is not treated as a function to call!
So then you are basically talking about turning funcall, apply, mapcar
and friends into generic functions, with predefined methods for various
objects, so you can funcall a hash table or array. That seems like a
tall order.
How about, instead, making an adapter which generates a closure based
on an object's type? This could be a generic function.
(funcall (functionize some-hash) x) ; same as (gethash x some-hash)
(funcall (functionize some-array) 2 3) ; same as (aref some-array 2 3)
(funcall (functionize some-object) 's) ; (slot-value some-object 's)
This could perhaps be made setfable somehow.
(setf (funcall (functionize some-hash) x) y)
But the setf macro here cannot determine the object's type at
macroexpansion time, thus some magic has to be woven into the
expansion to locate the appropriate setter function for the
given object.
I don't know what primary convenience you are trying to achieve,
so I'm only grasping at straws.
>4. I'd like it to be called something other than Lisp. That is, I'd like
>Lisp's features in a language with a different name (like Arc). This may
>seem petty, but in my experience the prejudice against Lisp is immense,
>and I'm sick and tired of fighting about it.
Then the first thing you have to do is get people who teach a certain
language at Universities to stop calling it Lisp. I suspect that
a lot of Lisp prejudice comes from people being exposed to a certain
poor poor dialect of it, in which everything worthwhile must be done
from scratch.
In article <····················@news1.calgary.shaw.ca>,
···@ashi.footprints.net wrote:
> In article <····················@eglaptop.jpl.nasa.gov>, Erann Gat wrote:
> >1. I want to fill in the semantic space of function calls, that is, I
> >want to be able to put something other than a function or a closure in the
> >car of a list and have the result be something meaningful.
>
> Err, you *can't* put a closure or function in the first position of a list.
Right. My mistake.
> What if someone else wants to call a hash table with different semantics?
Tough. ;-) ;-) ;-)
> Would you be happy with having these objects being funcallable?
Yes, I could live with that.
> So then you are basically talking about turning funcall, apply, mapcar
> and friends into generic functions, with predefined methods for various
> objects, so you can funcall a hash table or array. That seems like a
> tall order.
No, because I don't want to be able to redefine the behavior of hash
tables and arrays. Those can be fixed. And I'm happy to have the
redefinable behavior for instances be attached to a real generic function
that has some new name (like funcall-instance or some such thing). So you
don't really need to change funcall etc. into generic functions to get
what I want, you just have to extend their current behavior.
I believe that this change would actually be pretty straightforward.
E.
In article <····················@news1.calgary.shaw.ca>,
Kaz Kylheku <···@ashi.footprints.net> wrote:
>In article <····················@eglaptop.jpl.nasa.gov>, Erann Gat wrote:
>>4. I'd like it to be called something other than Lisp. That is, I'd like
>>Lisp's features in a language with a different name (like Arc). This may
>>seem petty, but in my experience the prejudice against Lisp is immense,
>>and I'm sick and tired of fighting about it.
>
>Then the first thing you have to do is get people who teach a certain
>language at Universities to stop calling it Lisp. I suspect that
>a lot of Lisp prejudice comes from people being exposed to a certain
>poor poor dialect of it, in which everything worthwhile must be done
>from scratch.
Last month, I informally asked a prominent
Scheme-teaching academic if he thought and/or taught
that Scheme was a Lisp. He was surprised at my
question. He didn't go into whether he thought Scheme
was a Lisp, probably because he thought I was asking a
largely useless "thought-provoking" question, and he
didn't find it interesting enough to take a stance,
because it didn't make a material difference to
coursework. To the question whether he told his
students that Scheme was a Lisp, he said No. The
impression I get (from both this teacher and others) is
that Scheme teachers generally have a small time window
to get their pedagogic concerns across. There is not
enough time to devote to this taxonomy question
that so exercises the comp.lang.lisp newsgroup.
I don't think the problem from the CL side is that
students are coming away from their Scheme courses
learning that Scheme is a Lisp. Rather, they take a
look at Common Lisp and draw correlations between
Scheme and Common Lisp. Ie, they think Common Lisp is
a Scheme! I don't claim to quite understand the
implication of surface syntax here. Perl and many
other languages adopt a C-like syntax presumably to
reduce the syntax learning curve, but users don't
typically think Perl is a C or C is a Perl or whatever.
Either the s-expression syntax isn't seen as capable of
representing many different languages (the C syntax
doesn't have this (dis)advantage), or Common Lisp
simply isn't differentiating itself enough and in a
positive way. Negative differentiation such as "the
Scheme teachers must be doing something underhanded"
doesn't contribute to effective differentiation anyway
(it largely preaches to the converted). Maybe CL
really isn't all that interested in identifying itself
distinctly where it counts. Neither is Scheme for that
matter -- witness the unbroken tradition of Scheme
teaching starting from SICP which implies that the
particular language chosen is incidental -- but that's
a different story.
--d
ps: What is my own view? I personally think
Common Lisp is not a Scheme, but I am open to
correction.
····@goldshoe.gte.com (Dorai Sitaram) writes:
> I don't think the problem from the CL side is that students are
> coming away from their Scheme courses learning that Scheme is a
> Lisp. Rather, they take a look at Common Lisp and draw correlations
> between Scheme and Common Lisp. Ie, they think Common Lisp is a
> Scheme!
Indeed, that's essentially what I thought after learning Scheme.
> I don't claim to quite understand the implication of surface syntax
> here. Perl and many other languages adopt a C-like syntax
> presumably to reduce the syntax learning curve, but users don't
> typically think Perl is a C or C is a Perl or whatever.
I've seen people claim that it's easy to learn C knowing Perl and vice
versa because they're similar languages. When I claimed that they're
not, many people objected and said that the differences are
immaterial. I get the impression that they merely use both languages
in similar ways and never noticed a difference except for a few
operators.
--
-> -/- - Rahul Jain - -\- <-
-> -\- http://linux.rice.edu/~rahul -=- ············@techie.com -/- <-
-> -/- "I never could get the hang of Thursdays." - HHGTTG by DNA -\- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
Version 11.423.999.221020101.23.50110101.042
(c)1996-2002, All rights reserved. Disclaimer available upon request.
* ····@goldshoe.gte.com (Dorai Sitaram)
|
| I don't think the problem from the CL side is that
| students are coming away from their Scheme courses
| learning that Scheme is a Lisp. Rather, they take a
| look at Common Lisp and draw correlations between
| Scheme and Common Lisp. Ie, they think Common Lisp is
| a Scheme! I don't claim to quite understand the
| implication of surface syntax here. Perl and many
| other languages adopt a C-like syntax presumably to
| reduce the syntax learning curve, but users don't
| typically think Perl is a C or C is a Perl or whatever.
I once had a co-worker who after having struggled with some PHP code
for two weeks still thought he was writing Perl code.
:)
--
Vebjorn Ljosa
···@jpl.nasa.gov (Erann Gat) writes:
> 4. I'd like it to be called something other than Lisp. That is, I'd like
> Lisp's features in a language with a different name (like Arc). This may
> seem petty, but in my experience the prejudice against Lisp is immense,
> and I'm sick and tired of fighting about it.
I think the prejudice problem is slowly fading away. The young people
in the business, who were still in elementary school during the first
years of the AI winter, either don't know anything about lisp at all
(which is becoming a bigger problem than prejudice, I think), have
prejudice against everything that is not java or C++ (but are
otherwise not biased against lisp), or are actually quite positive. I
think young linux hackers belong to the last category. These are the
people you can attract to Common Lisp before they get lost in their
own perl code. A lot of these people associate nothing negative with
the name 'lisp', the problem may sometimes be the quite opposite, that
they have a 'positive prejudice': I have an impression that some think
that lisp is the tool of the 'higher gods of programming' that the
'lesser programmers' don't think they'll ever learn to master ;-)
--
(espen)
On Wed, 16 Jan 2002 08:43:11 GMT, Espen Vestre
<·····@*do-not-spam-me*.vestre.net> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > 4. I'd like it to be called something other than Lisp. That is, I'd like
[...]
> I think the prejudice problem is slowly fading away. The young people
I agree. In Italy, where I live, it looks like certain terms or expressions
are being used again without negative implications, such as AI.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://web.mclink.it/amoroso/ency/README
[http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/]
···@jpl.nasa.gov (Erann Gat) writes:
> In article <·············@beta.franz.com>, Duane Rettig <·····@franz.com> wrote:
>
> > ···@jpl.nasa.gov (Erann Gat) writes:
> >
> > > <opinion>
> > > BTW, I would much rather see Lisp change to meet modern challenges than
> > > see Lisp programmers convert to Python. Lisp is still better than Python
> > > from purely language-based considerations. But the extent to which Lisp
> > > is better than Python is much smaller than the extent to which Lisp is
> > > better than C, to the point where non-language considerations (like not
> > > having to fight with management) give Python the edge in some cases.
> > > </opinion>
> >
> > At Franz, we agree with you and are continually looking for ways
> > to extend our implementation of CL (through extensions) to make
> > it better and better.
> >
> > Could you give us a wish-list of specific ways you'd like to see
> > Lisp change?
>
> A complete answer to that question would be very, very long. As a start
> I'll recommend reading http://www.paulgraham.com/popular.html, with which
> I mostly agree.
>
> Here are some representative items from my wish list:
>
> 1. I want to fill in the semantic space of function calls, that is, I
> want to be able to put something other than a function or a closure in the
> car of a list and have the result be something meaningful. Examples: I'd
> like to be able to call an array and have the result be equivalent to a
> call to aref. I'd like to be able to call a hash table and have the
> result be equivalent to a call to gethash. I'd like to be able to call a
> CLOS instance and have the result be equivalent by default to a call to
> slot-value. And I'd like a way to override that behavior. And I'd like
> all these things to be setfable.
>
> 2. I'd like to be able to write C code in Lisp, that is, I'd like to have
> a defined subset of the language whose semantics are essentially the
> semantics of C and be confident that the resulting code would be
> essentially the same as what a C compiler would have generated. I'd like
> to be able to use the resulting subset of Lisp (LiCp?) to, e.g., write a
> Linux device driver. I'd like to be able to call C code (real C code
> generated by a C compiler, not LiCp code) by doing nothing more than
> (include "foo.h").
>
> 3. I want standardized regular expression and ODBC client libraries.
>
> 4. I'd like it to be called something other than Lisp. That is, I'd like
> Lisp's features in a language with a different name (like Arc). This may
> seem petty, but in my experience the prejudice against Lisp is immense,
> and I'm sick and tired of fighting about it.
Very good list. (well, maybe except 1 - I do not quite see the value
in that).
Now, what about
5. I want public domain (yes: you read it right) reference
implementations just like it happened for CLOS and CLX (well, close
enough), and not for CLIM.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th 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'.
Erann Gat wrote:
> Es is nicht gasagt das es besser wird wenn es anders wirt. Wenn es
> aber besser werden soll muss es anders werden. (Loosely translated:
> Different is not necessarily better. But better is necessarily
> different.)
> -- G. Ch. Lichtenberg
More literally translated:
"It's not sure that it will be better if it gets different but if it
should get better it has to get different."
ciao,
Jochen
··········@mailandnews.com (Software Scavenger) writes:
[...]
> I'm also curious to know if you wrote macros to change the syntax of
> Lisp and then later abandoned those macros after deciding the syntax
> changes weren't really improvements. Is that something nearly all
> Lisp programmers eventually do? Do they tend to do it after a certain
> number of years of Lisp, or just at random times?
I have not very much experience with Lisp, but I think every
programmer has an own style of thinking and solving problems. With
time one will try to add features to the language (either normal
library procedures/functions or especially macros in Lisp) that
supports the own problem solving strategies.
Regards,
Julian St.
···@jpl.nasa.gov (Erann Gat) writes:
> Instead, I lost my faith. There were two main reasons for this. First, I
> got to see firsthand what a group of smart people working together can
> accomplish even when they aren't using Lisp. It's an awesome thing. I
> don't believe it would be possible to reproduce Google in Lisp.
>
> Second, I learned that Lisp is not as great as I thought it was.
> Certainly twenty years ago, and even ten years ago, there was nothing that
> could touch it. But the world has been slowly catching up while Lisp has
> been largely stagnant for a decade. The list of features that Lisp offers
> that aren't found in other languages has grown shorter and shorter. The
> list of useful library functions found in other languages and not in Lisp
> has grown longer. It's the old story of the tortoise and the hare. Lisp
> has been napping for ten years, and the rest of the world is catching up.
> (In some areas it has already caught up, or even passed us.)
..............................
> When I say "reproduce Google" I mean reproduce not only Google's behavior but
> also its performance. When you're doing essentially a single computation
> repeated 100 million times a day performance matters. To get Google-like
> performance you have to do some pretty hairy optimizing at some pretty low
> levels. All kinds of things that you can usually ignore start to become very
> significant at that scale. Lisp's great strength (one of them) is that it
> hides a lot of the low-level cruft, which is exactly the opposite of what you
> need in that case.
Eran, you may have received a healthy dose of realism, but I'm sure you will
recover your faith if you give it a chance. No single language is appropriate
for all situations. I've seen benchmarks indicating that Lisp is on the order
of 30% slower than C, which isn't at all bad considering that C is statically
typed (but still not type safe). And C is 50% - 100% slower than assembler.
So if you are doing something like Google, a factor of two means the world
because you have to have twice as much hardware. And so it's not surprising
that the lower levels of Google are implemented in something like C or
assembler.
Other languages may have picked up the features first seen in Lisp. Even Lucid
set out to write a C IDE which incorporated the features first seen in Lisp
environments. It is true that these things have become commonplace now. But
to take Python as an example of a language heavily influenced by the Lisp
family: it's 10 - 50 times slower than C and there is no compiler is yet in
sight. Meanwhile, Lisp is way ahead on speed.
In his introduction to Friedman's _Essentials of Programming Languages_, 2nd
edition (2000), Hal Ableson makes interesting points:
"...programming techniques that explicitly involve the structure of language
are becoming increasingly important...perhaps this is an inevitable consequence
of the fact that our programs are becoming increasingly complex--thinking more
explicitly about languages may be our best tool for dealing with this
complexity.....Perhaps the whole distinction between program and programming
language is a misleading idea, and future programmers will see themselves not
as writing programs in particualr, but as creating new languages for each new
application."
The Lisp family is uniquely suited to that kind of development. Nothing comes
close, and there hasn't been much "catch up" in that area by other languages.
Certainly C++ has gone off in an entirely different direction, and C/Assembler
haven't changed at all in that regard.
Of course, the other epiphany is how much smart people working together can
accomplish. That factor outweighs the tools, a fact for which we have plenty
of evidence.
Renew your faith!
KBK
In article <··············@float.ne.mediaone.com>, ···@shore.net (Kurt B.
Kaiser) wrote:
> Eran, you may have received a healthy dose of realism, but I'm sure you will
> recover your faith if you give it a chance. No single language is appropriate
> for all situations.
Hm, that actually *was* my faith, that Lisp was appropriate for (very
nearly) all situations.
> But
> to take Python as an example of a language heavily influenced by the Lisp
> family: it's 10 - 50 times slower than C and there is no compiler is yet in
> sight. Meanwhile, Lisp is way ahead on speed.
First, when Lisp was as old as Python is now it too was slow. But that's
really a moot point. Sometimes speed matters, sometimes (often) it
doesn't. When it doesn't, Python is plenty fast enough. When it matters
it *really* matters, and Lisp isn't fast enough. For Lisp to win on
performance you have to be right in the sweet spot where Python is too
slow but you don't need C. Sometimes you hit the sweet spot, but most of
the time you're at one extreme or the other.
> In his introduction to Friedman's _Essentials of Programming Languages_, 2nd
> edition (2000), Hal Ableson makes interesting points:
>
> "...programming techniques that explicitly involve the structure of language
> are becoming increasingly important...perhaps this is an inevitable
consequence
> of the fact that our programs are becoming increasingly complex--thinking more
> explicitly about languages may be our best tool for dealing with this
> complexity.....Perhaps the whole distinction between program and programming
> language is a misleading idea, and future programmers will see themselves not
> as writing programs in particualr, but as creating new languages for each new
> application."
>
> The Lisp family is uniquely suited to that kind of development. Nothing comes
> close, and there hasn't been much "catch up" in that area by other languages.
> Certainly C++ has gone off in an entirely different direction, and C/Assembler
> haven't changed at all in that regard.
I think Hal's been in the ivory tower too long. Where are all these
increasingly complex programs? Where I see things getting more complex is
in computer graphics, data mining, and possibly bioinformatics (I don't
really know much about that). Every other major area of computer science
- operating systems, databases, even the Web - seems to me to be
essentially unchanged (in terms of complexity) from the state of the art
ten years ago. And in those areas I mentioned speed matters, so it's all
being done in C++.
> Of course, the other epiphany is how much smart people working together can
> accomplish. That factor outweighs the tools, a fact for which we have plenty
> of evidence.
Yes. I've said it before, I'll say it again: if someone can figure out
how to get Lisp programmers to work together they could get fabulously
rich.
> Renew your faith!
The truth is that, while I was a true believer, I never really had *faith*
in Lisp. I am a scientist, not a man of faith. I believed in Lisp
because I had firsthand evidence of its superiority. My "faith" will be
restored when I see evidence that Lisp is changing to meet today's
challenges.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> > In his introduction to Friedman's _Essentials of Programming Languages_,
> > 2nd edition (2000), Hal Ableson makes interesting points:
> >
> > "...programming techniques that explicitly involve the structure of
> > language are becoming increasingly important...perhaps this is an
> > inevitable > consequence of the fact that our programs are becoming
> > increasingly complex--thinking more explicitly about languages may be our
> > best tool for dealing with this complexity.....Perhaps the whole
> > distinction between program and programming language is a misleading idea,
> > and future programmers will see themselves not as writing programs in
> > particualr, but as creating new languages for each new application."
> >
> > The Lisp family is uniquely suited to that kind of development. Nothing
> > comes close, and there hasn't been much "catch up" in that area by other
> > languages. Certainly C++ has gone off in an entirely different direction,
> > and C/Assembler haven't changed at all in that regard.
>
> I think Hal's been in the ivory tower too long. Where are all these
> increasingly complex programs? Where I see things getting more complex is in
> computer graphics, data mining, and possibly bioinformatics (I don't really
> know much about that). Every other major area of computer science -
> operating systems, databases, even the Web - seems to me to be essentially
> unchanged (in terms of complexity) from the state of the art ten years ago.
> And in those areas I mentioned speed matters, so it's all being done in C++.
I'm wondering whether the stagnation to which you refer is inherent or whether
it is caused by the limitations of widely used tools like C++.
The O/O hype has passed (just check your bookstore) with moderate effect (no
silver bullet there :) and the next paradigm hasn't shifted yet. Generative
programming? Maybe widespread acceptance of a programming style using
functions as first class entities?
Current tools tend to be either glue (Python) or Visual (where the coders don't
really know what they are doing, the "wizards" take care of that). Not much
sophistication. But maybe sophistication is considered to be unmaintainable.
Regards, KBK
On Fri, 11 Jan 2002 04:44:44 GMT, ···@shore.net (Kurt B. Kaiser)
wrote:
>The O/O hype has passed (just check your bookstore) with moderate effect (no
>silver bullet there :) and the next paradigm hasn't shifted yet. Generative
>programming? Maybe widespread acceptance of a programming style using
>functions as first class entities?
If you looking for a new programming paradigm, take a look at dataflow
programming model which we discussed with Kent Tilton 2-3 weeks ago. I
found it not less amazing that object model while it is 'orthogonal'
to it (may be used independently).
Arseny Slobodjuck wrote:
>
> On Fri, 11 Jan 2002 04:44:44 GMT, ···@shore.net (Kurt B. Kaiser)
> wrote:
>
> >The O/O hype has passed (just check your bookstore) with moderate effect (no
> >silver bullet there :) and the next paradigm hasn't shifted yet. Generative
> >programming? Maybe widespread acceptance of a programming style using
> >functions as first class entities?
> If you looking for a new programming paradigm, take a look at dataflow
> programming model which we discussed with Kent Tilton 2-3 weeks ago. I
> found it not less amazing that object model while it is 'orthogonal'
> to it (may be used independently).
Yes, my experience has been that we get much more reuse out of classes
when slots can be expressed as arbitrary HLL rules varying from instance
to instance of the same class.
I have been coding frantically for eight months adding all sorts of
functionality requested by the user and rarely have had to create a new
class. When i do they usually do not add slots, they are just a
convenient way of bundling up reusable sets of slot default-initargs.
kenny
clinisys
···@jpl.nasa.gov (Erann Gat) writes:
> I think Hal's been in the ivory tower too long. Where are all these
> increasingly complex programs? Where I see things getting more complex is
> in computer graphics, data mining, and possibly bioinformatics (I don't
> really know much about that). Every other major area of computer science
> - operating systems, databases, even the Web - seems to me to be
> essentially unchanged (in terms of complexity) from the state of the art
> ten years ago.
Hmm. For the stuff I've been doing in lisp the last few years, I'd
conclude that
- python's too simple-minded and much too slow
- java is also too slow and less flexible
- lisp is fast enough ... but even if it was a little to slow, the
speed advantage by using C++ instead of lisp would cost a fortune
in salaries and/or longer development time, and you would still end
up with a less flexible system. I.e. you're much better of
investing a little more in hardware (we are using pretty expensive
Sun servers, but we are a _long_ way from using a lot of the most
expensive ones. YMMV here, of course).
So I think I disagree with
> And in those areas I mentioned speed matters, so it's all
> being done in C++.
at least if "those areas" are "every other area". It wasn't clear to
me if the applications I work on actually are included in this group:
Business IS systems, many-tier applications with databases at the
bottom, applications which are not doing "rocket science" (;-)) but
which need to be very reliable, fast enough, and _very_ expandable,
changable, flexible.
The obvious, to me, advantage of lisp for such software is that it
gives you, compared to lower-level languages:
- shorter development cycles and less development costs
- usually about the same speed
- more flexibility
- higher uptime ("live patching")
Compared to other higher-level languages like Python or Java, it
gives you
- higher speed (and I think also _stability_)
- more power and flexibility
--
(espen)
In article <····················@192.168.1.50>, ···@jpl.nasa.gov says...
> I think Hal's been in the ivory tower too long. Where are all these
> increasingly complex programs? Where I see things getting more complex is
> in computer graphics, data mining, and possibly bioinformatics (I don't
> really know much about that). Every other major area of computer science
> - operating systems, databases, even the Web - seems to me to be
> essentially unchanged (in terms of complexity) from the state of the art
> ten years ago. And in those areas I mentioned speed matters, so it's all
> being done in C++.
>
You are asking where the complex programs are?
All over the place, each large application is _very complex_.
We got used to permanent buggy OS, DB, Application Servers.....
Not only buggy, but inflexible.
Today customization of large software packages is a nightmare. Try to
introduce a SAP system in a large organisation.
The opportunity is huge, time will come where today's rigide and buggy
large application will be just unacceptable. Time will come where
flexibility and fault tolerance will matter.
But of course Common Lisp has to evolve, integrate other very
interesting paradigms out there...
···@jpl.nasa.gov (Erann Gat) writes:
> First, when Lisp was as old as Python is now it too was slow. But that's
> really a moot point. Sometimes speed matters, sometimes (often) it
> doesn't. When it doesn't, Python is plenty fast enough. When it matters
> it *really* matters, and Lisp isn't fast enough. For Lisp to win on
I disagree. I once tried to run a server application written in Pyton
(MojoNation, in case anyone cares). That server was unable to deliver
more than one or two Megabit/sec performance, and that was on a 700MHz
Athlon with 512 MB of RAM.
Python is too slow by a factor of 50 or so.
> performance you have to be right in the sweet spot where Python is too
> slow but you don't need C. Sometimes you hit the sweet spot, but most of
> the time you're at one extreme or the other.
Well, in my experience, most often speed does matter enough that one
would prefer to use a compiled language, but not enough that the extra
30% or so you get out of writing in C would be worth the trouble.
Besides, if you *really* want performance, it seems that you have to
abandon C in favor of OCaml...
Andreas
--
"In my eyes it is never a crime to steal knowledge. It is a good
theft. The pirate of knowledge is a good pirate."
(Michel Serres)
···@jpl.nasa.gov (Erann Gat) wrote in message news:<····················@192.168.1.50>...
> For Lisp to win on
> performance you have to be right in the sweet spot where Python is too
> slow but you don't need C. Sometimes you hit the sweet spot, but most of
> the time you're at one extreme or the other.
A few months ago I watched a video of an expert panel at the Dynamic
Languages Seminar at MIT. P. Tucker Withington made a comment which
resonates with what you say.
To paraphrase, he said that many of the truly new and interesting
things being done today are those things which were out of the reach
of computational power until now, thanks to ever increasing processer
speed, memory, mass storage, etc. These things are often only doable
in the very fastest implementation, so speed does matter. The
implication was that some interesting problems were not really good
areas for dynamic languages because they weren't fast enough.
In a sense, the bias that performance is a secondary consideration
flows from a contempt for the brute force method, and a preference for
the algorithmically elegant solution. However, some interesting things
are really only doable because of what can only be described as raw
machine power. If one's more elegant language cannot keep up, then
it's elegance is of little use in this type of cutting edge project.
Raf
* Raffael Cavallaro
| In a sense, the bias that performance is a secondary consideration
| flows from a contempt for the brute force method, and a preference for
| the algorithmically elegant solution. However, some interesting things
| are really only doable because of what can only be described as raw
| machine power. If one's more elegant language cannot keep up, then
| it's elegance is of little use in this type of cutting edge project.
While this is obviously true, the very existence and proliferation of
exceedingly slow languages like Perl, Python, and Java, means that people
are beginning to understand that performance does not matter for _every_
task and are more than willing to do the logic in a more convenient
language. I think Common Lisp may have tried to compete on performance
when it should have competed on convenience. On the other hand, I would
so love to have all of Common Lisp available to me in a form that would
compile to "C-compatible" code, that followed the calling conventions of
more widely used languages upon request, so that Common Lisp could be
used without having to let it be the master of the whole application.
///
--
Erik Naggum <····@naggum.net> writes:
> On the other hand, I would so love to have all of Common Lisp
> available to me in a form that would compile to "C-compatible"
> code, that followed the calling conventions of more widely used
> languages upon request, so that Common Lisp could be used without
> having to let it be the master of the whole application.
Have you checked ECL <http://ecls.sourceforge.net/>? It isn't all of
CL yet, but the maintainers are aiming "to achieve maximum compliance
with ANSI Common-Lisp". It employs standard C calling conventions and
it can also build dynamically loadable as well as linkable object
files, see <http://ecls.sourceforge.net/ecldev.html> for details.
Edi.
Erik Naggum wrote:
>
> * Raffael Cavallaro
> | However, some interesting things
> | are really only doable because of what can only be described as raw
> | machine power. If one's more elegant language cannot keep up, then
> | it's elegance is of little use in this type of cutting edge project.
>
I am working on a puzzle over here, maybe y'all can help me out.
Lisp is too slow, C is fast enough, right?
So Lisp should not be used for some kinds of projects, yes?
I hear a numbers from time to time saying Lisp is sometimes as fast as
C, sometimes 20% slower. Exact numbers don't matter for this problem.
So we should not work 20% slower on "some interesting things", no matter
the advantages of the more elegant language.
OK, not sure on the dates, but six months ago I picked up a 1.4 GHZ
Dell, today I hear Pentiums are spinning at 2.2GHZ.
This means that a cutting edge C project today would have been a third
slower six months ago, hence too slow and should not have been
undertaken.
And systems certainly will be 20% faster before any cutting edge project
starting today can be completed, so no interesting project at all should
be started. Today's systems are too slow.
That result doe snot look right. Anyone see where I went wrong?
thx
kenny
clinisys
"Kenny Tilton" <·······@nyc.rr.com> wrote in message
······················@nyc.rr.com...
>
>
> Erik Naggum wrote:
> >
> > * Raffael Cavallaro
> > | However, some interesting things
> > | are really only doable because of what can only be described as raw
> > | machine power. If one's more elegant language cannot keep up, then
> > | it's elegance is of little use in this type of cutting edge project.
> >
>
> I am working on a puzzle over here, maybe y'all can help me out.
>
> Lisp is too slow, C is fast enough, right?
I think the general sentiment is that Lisp is too slow and C is too slow. I
do not think I have seen anyone that is happy that things run quickly enough
(even though they do). Push the optimization to cc -O500, maybe then the
compiler will optimize the code done to 100 assembly instructions, all
running in the processor cache, no stack, all registers.
Wade
Mantra of computing masses, "Faster Please".
"Wade Humeniuk" <········@cadvision.com> writes:
> (even though they do). Push the optimization to cc -O500, maybe then the
> compiler will optimize the code done to 100 assembly instructions, all
> running in the processor cache, no stack, all registers.
That neglects the fact that programs have an inherent complexity and
minimum size. Chaitin has a pretty tight proof on this (he talks
about irreducible algorithmic information), but a simple enumeration
argument should suffice to understand that on an intuitive basis.
Andreas
--
"In my eyes it is never a crime to steal knowledge. It is a good
theft. The pirate of knowledge is a good pirate."
(Michel Serres)
In article <··············@teonanacatl.andreas.org>, Andreas Bogk
<·······@andreas.org> wrote:
> "Wade Humeniuk" <········@cadvision.com> writes:
>
> > (even though they do). Push the optimization to cc -O500, maybe then the
> > compiler will optimize the code done to 100 assembly instructions, all
> > running in the processor cache, no stack, all registers.
>
> That neglects the fact that programs have an inherent complexity and
> minimum size. Chaitin has a pretty tight proof on this (he talks
> about irreducible algorithmic information), but a simple enumeration
> argument should suffice to understand that on an intuitive basis.
Actually, Chaitin's result is that it's impossible to know whether you
have attained the point of irreducible complexity once programs grow
beyond a certain size. See http://www.flownet.com/gat/chaitin.html for a
summary.
E.
In article <·················@nyc.rr.com>, Kenny Tilton wrote:
>
>
>Erik Naggum wrote:
>>
>> * Raffael Cavallaro
>> | However, some interesting things
>> | are really only doable because of what can only be described as raw
>> | machine power. If one's more elegant language cannot keep up, then
>> | it's elegance is of little use in this type of cutting edge project.
>>
>
>I am working on a puzzle over here, maybe y'all can help me out.
>
>Lisp is too slow, C is fast enough, right?
>
>So Lisp should not be used for some kinds of projects, yes?
Yes, if you consider individual functions to be projects. :)
Or if you have some reason to be avoiding mixed-language programming.
>And systems certainly will be 20% faster before any cutting edge project
>starting today can be completed, so no interesting project at all should
>be started. Today's systems are too slow.
>
>That result doe snot look right. Anyone see where I went wrong?
Sometimes people write code today in anticipation of faster hardware in
six months, a year or two or whatever. This might be true in some industry
centered around computer graphics; like games whose primary attractive
feature is the sophistication of the rendering model rather than play.
The program is written with some release date in mind, and is planned
around the projected hardware available at that time, rather than today's
hardware.
This is how Microsoft ensures that they fill up the bleeding edge PC's
memory and drag its apparent performance to that of the 4.77 Mhz IBM PC.
It's planned months and years in advance.
Kenny Tilton <·······@nyc.rr.com> writes:
> Erik Naggum wrote:
> >
> > * Raffael Cavallaro
> > | However, some interesting things
> > | are really only doable because of what can only be described as raw
> > | machine power. If one's more elegant language cannot keep up, then
> > | it's elegance is of little use in this type of cutting edge project.
> >
>
> I am working on a puzzle over here, maybe y'all can help me out.
>
> Lisp is too slow, C is fast enough, right?
Not for me, ever. If Lisp is too slow (after trying, in order, cmucl,
acl [not that I'm any good with it], and clisp if it involves
bignums), then C is too slow. Period. At this point, it's time to
hand-optimize the assembler. Having spent the better part of a Sunday
doing this a couple weeks ago, I got a 30% speed increase over the
fastest compiled version (which had been C). But of course, this
Lisp + assembler solution was *correct*, where the C solution was
correct for a certain problem space. But the important part was that
it was faster :). If I'm going to switch to C for speed, it's a bad
choice -- C doesn't look like my machine, assembly language does.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
In article <················@naggum.net>, Erik Naggum <····@naggum.net>
wrote:
> While this is obviously true, the very existence and proliferation of
> exceedingly slow languages like Perl, Python, and Java
It's certainly possible to use Perl for tasks on which it is slow, but
for most of the typical things I do with Perl it is *very* hard to beat
it to any significant extent using C or any other compiled language.
As a rough rule of thumb, if the tightest loop you need in your Perl
program is one iterating over the lines in a text file then you'll have
trouble beating the speed. Not that you *can't*, but it won't be worth
the trouble.
Within that loop, you can have any number of string manipulations,
regular expression matching, putting things in and out of hash tables
and arrays, and simple calculations and conditionals without changing
the validity of the rule of thumb.
-- Bruce
>>>>> "BH" == Bruce Hoult <·····@hoult.org> writes:
[...]
BH> It's certainly possible to use Perl for tasks on which it is
BH> slow, but for most of the typical things I do with Perl it is
BH> *very* hard to beat it to any significant extent using C or
BH> any other compiled language. [...]
Hmm, see:
http://www.bagley.org/~doug/shootout/
for perly things implemented and benchmarked in a gazillion languages.
CMUCL seems to do OK, and would have done much better with some minor
modifications to the compiler and the rules the author of that page
imposes (eg. rolling our own readline etc.).
Now I realize you said "significant," but there are results there that
show 2-3x improvemnt over perl, which, I suspect qualifies. It all depends
on what you do: you might care about 30% improvement if you were analyzing
2Gig text files such as cumulative logs etc. (I did and yeah can be done
with CMUCL if you spend quality time with the docs and compiler warnings).
cheers,
BM
In article <··············@nkapi.internal>, Bulent Murtezaoglu
<··@acm.org> wrote:
> >>>>> "BH" == Bruce Hoult <·····@hoult.org> writes:
> [...]
> BH> It's certainly possible to use Perl for tasks on which it is
> BH> slow, but for most of the typical things I do with Perl it is
> BH> *very* hard to beat it to any significant extent using C or
> BH> any other compiled language. [...]
>
> Hmm, see:
>
> http://www.bagley.org/~doug/shootout/
>
> for perly things implemented and benchmarked in a gazillion languages.
Actually, I wouldn't consider Perl a reasonable language for very many
of those benchmarks. Still, it gets 70% the score of the leaders.
> CMUCL seems to do OK, and would have done much better with some minor
> modifications to the compiler and the rules the author of that page
> imposes (eg. rolling our own readline etc.).
Dylan isn't there at *all*, due to an (in my opinion stupid) restriction
of Bagley's that programs must be in a single text file. We've recently
modified Gwydion Dylan so that you can compile a single file main
program with default libraries, but he's not updating the web page any
more.
> Now I realize you said "significant," but there are results there that
> show 2-3x improvemnt over perl, which, I suspect qualifies.
Barely. That means Perl runs faster on three machines I've got here
(Mac G4/867, PIII/1000, Athlon/700) than machine code runs on my 266 MHz
laptop. That doesn't stop me doing all my email and usenet and
documentation and much of my web browsing on the laptop.
> It all depends on what you do: you might care about 30% improvement if
> you were analyzing 2Gig text files such as cumulative logs etc.
What I usually care about is the total time-to-write-the-program plus
time-to-run-the-program.
For most programs I write, it's the time to write the program that
dominates. By far. I use Perl for the things that I can write more
quickly in Perl than in anything else. For those things, the Perl is
nearly always fast enough. Maybe a couple of times slower than a
compiled language, but with runtimes in seconds and writetimes in
minutes or hours that doesn't matter.
Of course for really huge datasets or something run thousands of times
that changes.
Also, a program doesn't have to be very complex before I can write it
faster in Dylan or Lisp (or even C++). Perl can do functions and
complex pointer-based data structures but it *sucks* at both.
-- Bruce
Erik Naggum <····@naggum.net> wrote in message news:<················@naggum.net>...
> On the other hand, I would
> so love to have all of Common Lisp available to me in a form that would
> compile to "C-compatible" code, that followed the calling conventions of
> more widely used languages upon request, so that Common Lisp could be
> used without having to let it be the master of the whole application.
If you're on the Windows platform, Xanalys LispWorks lets you compile
your code to a .dll which can be called by other non-lisp code. I know
they have a Linux version of LispWorks as well, which may also have
this compile-to-library ability.
I know you use ACL, but for this particular need, you might want to
look at LispWorks.
·······@mediaone.net (Raffael Cavallaro) writes:
>
> If you're on the Windows platform, Xanalys LispWorks lets you compile
> your code to a .dll which can be called by other non-lisp code. I know
> they have a Linux version of LispWorks as well, which may also have
> this compile-to-library ability.
>
> I know you use ACL, but for this particular need, you might want to
> look at LispWorks.
When I used ACL on Windows (about 2 years ago) it also had this capability.
Thom
--
(let ((e-mail-address ····@IXG.IUS")) (loop with new-string =
(make-string (length e-mail-address)) for count from 0 to (1- (length
e-mail-address)) for char-code = (char-code (aref e-mail-address
count)) for new-char-code = (if (and (> char-code 64) (< char-code
123)) (+ (mod (+ 13 char-code) 52) 65) char-code) do (setf (aref
new-string count) (code-char new-char-code)) finally (return
new-string)))
···@jpl.nasa.gov (Erann Gat) writes:
> In article <··································@4ax.com>, Fernando
> Rodr�guez <·······@must.die> wrote:
>
> > I think I saw in your webpage that you were working at google. If that's true,
> > what's taking you and Peter Norvig so long to convert all googlers to The True
> > Faith? ;-)
>
> I worked at Google for a year. Now I'm back at JPL. (ObDisclaimer: I do
> not speak for the Laboratory.)
>
> Working at Google was a very humbling and educational experience. I used
> to think I was a pretty bright guy until I went to work there. One of the
> things I learned came as a great shock to me: not all people who choose to
> program in languages other than Lisp are idiots.
Well that is IMHO obvious and just ignorants could think that the not
Lisp users are idiots.
>
> So I got to be pretty smug about Lisp (and my own abilities). With the
> advantages of Lisp being so obvious (to me) and so enormous I spent a lot
> of time puzzling over why everyone didn't use it. I came to the
> conclusion that people who didn't use Lisp did so simply because they
> didn't know about how wonderful it was, and so I set off on a ten-year
> crusade to enlighten the heathen, with mixed results. The story of that
> crusade makes an interesting tale in and of itself but would take us far
> afield here. The point is, I went to Google fully intending to convert
> them to the True Faith.
Sorry I do not like the term Faith for it. Languages are tools and one
should trust his tools but faith is IMHO much too strong.
>
> Instead, I lost my faith. There were two main reasons for this. First, I
> got to see firsthand what a group of smart people working together can
> accomplish even when they aren't using Lisp.
Well I'm not really suprised about that. Just having read some books
about Software Engeneering and Programmint it was mentioned nearly
everywhere that personal skills make the difference. The spreach
between Joe Average (and below) and true Hackers is around
10-30:1. That means one Hacker can replace 10 Joe Average
programmers, the problem is to find such people and beeing able to
hold them.
I think you'll find them in areas where they really found interesting
enough tasks. I guess Google offers that.
> It's an awesome thing. I
> don't believe it would be possible to reproduce Google in Lisp.
Well this is a very strong argument and can not be prooved. I'm sure
nobody is willing to spend millions of Dollars to support or decline
that. The same is true IMHO vice versa. Graham has written that it
seems to be unpossible to develop his e-shop solution could not have
been done without Lisp. Well I don't believe that either.
>
> Second, I learned that Lisp is not as great as I thought it was.
> Certainly twenty years ago, and even ten years ago, there was nothing that
> could touch it.
Well there are some areas where I can't see anything comparable.
> But the world has been slowly catching up while Lisp has
> been largely stagnant for a decade. The list of features that Lisp offers
> that aren't found in other languages has grown shorter and shorter.
Definitely.
> The
> list of useful library functions found in other languages and not in Lisp
> has grown longer. It's the old story of the tortoise and the hare. Lisp
> has been napping for ten years, and the rest of the world is catching up.
> (In some areas it has already caught up, or even passed us.)
Agreed.
Regards
Friedrich
In article <····················@eglaptop.jpl.nasa.gov>,
···@jpl.nasa.gov (Erann Gat) wrote:
> I don't believe it would be possible to reproduce Google in Lisp.
That's a pretty strong statement. Why?
-- Bruce
In article <···························@news.paradise.net.nz>, Bruce Hoult
<·····@hoult.org> wrote:
> In article <····················@eglaptop.jpl.nasa.gov>,
> ···@jpl.nasa.gov (Erann Gat) wrote:
>
> > I don't believe it would be possible to reproduce Google in Lisp.
>
> That's a pretty strong statement. Why?
When I say "reproduce Google" I mean reproduce not only Google's behavior
but also its performance. When you're doing essentially a single
computation repeated 100 million times a day performance matters. To get
Google-like performance you have to do some pretty hairy optimizing at
some pretty low levels. All kinds of things that you can usually ignore
start to become very significant at that scale. Lisp's great strength
(one of them) is that it hides a lot of the low-level cruft, which is
exactly the opposite of what you need in that case.
BTW, I didn't intend for it to be a strong statement, just a statement
about my personal subjective assessment. I could be wrong. In fact, I
would be thrilled to learn that I am wrong. But I wouldn't bet my life
savings on it.
E.
···@jpl.nasa.gov (Erann Gat) wrote in message news:<····················@192.168.1.50>...
> In article <···························@news.paradise.net.nz>, Bruce Hoult
> <·····@hoult.org> wrote:
>
> > In article <····················@eglaptop.jpl.nasa.gov>,
> > ···@jpl.nasa.gov (Erann Gat) wrote:
> >
> > > I don't believe it would be possible to reproduce Google in Lisp.
> >
> > That's a pretty strong statement. Why?
>
> When I say "reproduce Google" I mean reproduce not only Google's behavior
> but also its performance. When you're doing essentially a single
> computation repeated 100 million times a day performance matters. To get
> Google-like performance you have to do some pretty hairy optimizing at
> some pretty low levels.
Yes, but didn't we know this to begin with?
People seem to forget that programs can be written in combinations of
languages. With this approach, one can prototype & build a system in
lisp, and then optimize the critical bits in C.
The same goes for programs written in C. It's common to rewrite the
parts of a C program that need to go faster in assembler.
-dj special ed
In article <···························@posting.google.com>,
·············@yahoo.com (dj special ed) wrote:
> ···@jpl.nasa.gov (Erann Gat) wrote in message
news:<····················@192.168.1.50>...
> > In article <···························@news.paradise.net.nz>, Bruce Hoult
> > <·····@hoult.org> wrote:
> >
> > > In article <····················@eglaptop.jpl.nasa.gov>,
> > > ···@jpl.nasa.gov (Erann Gat) wrote:
> > >
> > > > I don't believe it would be possible to reproduce Google in Lisp.
> > >
> > > That's a pretty strong statement. Why?
> >
> > When I say "reproduce Google" I mean reproduce not only Google's behavior
> > but also its performance. When you're doing essentially a single
> > computation repeated 100 million times a day performance matters. To get
> > Google-like performance you have to do some pretty hairy optimizing at
> > some pretty low levels.
>
> Yes, but didn't we know this to begin with?
Maybe some people did, but the question posed to me was "what is taking so
long for [me] and Peter Norvig to convert Google to the true faith?" or
words to that effect. The premise behind that question is that Lisp is
"the true faith," and that it would actually make sense to convert Google
to it.
A long time ago I wrote a response to something that Kent Pitman wrote but
I never posted it. It seems apropos here, so I dug it out of the bit
bucket:
Kent:
> In defense of that non-advocacy, I think there is a certain
> community-wide disdain for the idea that advocacy should make or break
> a language. Lisp people tend to focus their time on substance and hope
despite overwhelming evidence to the contrary
> that the substance will end up mattering in the long run.
The community seems to share a disdain for more than just advocacy. Our
disdain extends to just about everything that isn't Lisp. This disdain is
evident in statements like "substance will end up mattering in the long
run", which implicit ly rejects the possibility that substance *has*
mattered, and that the world has rejected Lisp for substantial reasons and
not just superficial ones.
E.
Erann Gat wrote:
This disdain is
> evident in statements like "substance will end up mattering in the long
> run", which implicit ly rejects the possibility that substance *has*
> mattered, and that the world has rejected Lisp for substantial reasons and
> not just superficial ones.
CliniSys (powered by CL) has solved a problem in its domain away from
which our competitors have run. Their not addressing that problem
squarely has compromised their offerings so badly that they have gained
little share of a lucrative market and in fact have created an image
problem we will have to overcome.
Thanks to CL, that problem is now our b*tch. So there's one sweet data
point.
Look, application software development is still a young discipline. Can
we talk again in ten years?
kenny
clinisys
On Fri, 11 Jan 2002 18:48:28 GMT, Kenny Tilton <·······@nyc.rr.com>
wrote:
>CliniSys (powered by CL) has solved a problem in its domain away from
>which our competitors have run. Their not addressing that problem
>squarely has compromised their offerings so badly that they have gained
>little share of a lucrative market and in fact have created an image
>problem we will have to overcome.
Just out of curiousity, that problem is?
( Assuming you can tell that is. )
Thaddeus L Olczyk wrote:
> Just out of curiousity, that problem is?
> ( Assuming you can tell that is. )
I'll hold back a little, but the problem was:
... managing a flood of never-ending flood of different and changing
documents and..
... applying to them arbitrary and changing business rules,..
... across a remote, sometimes-connected network...
... without changing the application.
So the classic "code as data" thing is clutch.
kenny
clinisys
Kenny Tilton wrote:
> I'll hold back a little, but the problem was:
>
> ... managing a flood of never-ending flood of different and changing
> documents and..
>
> ... applying to them arbitrary and changing business rules,..
>
> ... across a remote, sometimes-connected network...
>
> ... without changing the application.
>
> So the classic "code as data" thing is clutch.
Software-project estimation is not a silver bullet:
http://www.idiom.com/~zilla/Work/Softestim/softestim.html
The article is more a philosophical one; but it is interesting that they
mention Goedel (Austrian mathematician) and his theorem.
After reading this article I am not sure anyfurther, whether a
computer-language really matters or not.
S. Gonzi
Siegfried Gonzi wrote:
> Software-project estimation is not a silver bullet:
that's what i keep telling management. especially Hofstedder's (sp?)
law.
> After reading this article I am not sure anyfurther, whether a
> computer-language really matters or not.
Why not? Given the same intractable problem, using a better language
still gets you there sooner. It might be the lower of two values of
infinity...
:)
kenny
clinisys
On Sat, 12 Jan 2002 11:20:09 +0100, Siegfried Gonzi
<···············@kfunigraz.ac.at> wrote:
>http://www.idiom.com/~zilla/Work/Softestim/softestim.html
>
>The article is more a philosophical one; but it is interesting that they
>mention Goedel (Austrian mathematician) and his theorem.
>
>After reading this article I am not sure anyfurther, whether a
>computer-language really matters or not.
The main paper at http://www.idiom.com/~zilla/Work/kcsest.pdf is worth
reading too.
On Fri, 11 Jan 2002 18:48:28 GMT, Kenny Tilton <·······@nyc.rr.com> wrote:
>
>
>Erann Gat wrote:
> This disdain is
>> evident in statements like "substance will end up mattering in the long
>> run", which implicit ly rejects the possibility that substance *has*
>> mattered, and that the world has rejected Lisp for substantial reasons and
>> not just superficial ones.
>
>CliniSys (powered by CL) has solved a problem in its domain away from
>which our competitors have run. Their not addressing that problem
>squarely has compromised their offerings so badly that they have gained
>little share of a lucrative market and in fact have created an image
>problem we will have to overcome.
It's a different situation. You're probably doing a lot of exploratory
programming (_real_ programming), and lisp excels at that.
I might be wrong, but IR is much more straight forward and a rather well known
territory, where performance and memory footprint are very important, so C
seems the appropriate tool.
The fanciest thing I've seen in IR was keeping some 'mini indexes' in memory
for data that had just been indexed so it could be searched immediately,
before it had been 'dumped' to the inverted file. Of course, I might be wrong
and google is way advanced and fancy...
Anyway, if I can choose I'd stick to the exploratory (real) thing. ;-)
--
Fernando Rodr�guez
frr at wanadoo dot es
--
On 1/11/02 1:54 P, in article ��RTICLE], "Fernando Rodr�guez"
<·······@must.die> wrote:
> I might be wrong, but IR is much more straight forward and a rather well known
> territory, where performance and memory footprint are very important, so C
> seems the appropriate tool.
Performance is important, but until IR delivers something that actually
understands both the search query and the text it indexes, it will never
live up to its possibilities.
"I want all documents that could reasonably convince someone who is
currently a pagan to convert to Catholicism, assuming they are over 30 with
at least one child, and does not include any pictures of John-Paul II."
<reasonable continuations>
WHAT KIND OF PAGAN, SPECIFICALLY?
Druid
IS THEIR CHILD HEALTHY?
Yes
I HAVE FOUND 3 SUCH DOCUMENTS ONLINE, AND 2 BOOKS AVAILABLE IN THE RARE
BOOKS SECTION OF THE NEW YORK PUBLIC LIBRARY. ONLY ONE DOCUMENT IS IN MODERN
ENGLISH. PLEASE REFER TO THE BROWSER WINDOW NOW BEING BROUGHT UP ON THE PC
BEHIND YOU. SHALL I BOOK A FLIGHT TO NEW YORK CITY FOR YOU?
etc.
Now how does C, specifically, help me do this more than some other language?
Most of the problems here are independent of implementation language.
Google may be better than most other current search engines, but it's still
a pretty wimpy IR system.
On Fri, 11 Jan 2002 15:55:33 -0600, "Bradford W. Miller"
<·················@motorola.com> wrote:
>Performance is important, but until IR delivers something that actually
>understands both the search query and the text it indexes, it will never
>live up to its possibilities.
>
>Now how does C, specifically, help me do this more than some other language?
>Most of the problems here are independent of implementation language.
{ Currently unrealistic example deleted }
Wasn't this what AI has been promising us for years ?
Still no end in sight...
On Fri, 11 Jan 2002 15:55:33 -0600, "Bradford W. Miller"
<·················@motorola.com> wrote:
>On 1/11/02 1:54 P, in article ��RTICLE], "Fernando Rodr�guez"
><·······@must.die> wrote:
>
>> I might be wrong, but IR is much more straight forward and a rather well known
>> territory, where performance and memory footprint are very important, so C
>> seems the appropriate tool.
>
>Performance is important, but until IR delivers something that actually
>understands both the search query and the text it indexes, it will never
>live up to its possibilities.
>
>"I want all documents that could reasonably convince someone who is
>currently a pagan to convert to Catholicism, assuming they are over 30 with
>at least one child, and does not include any pictures of John-Paul II."
Not only that's science fiction, but it has almost nothing to do with IR,
that's AI (since it implies that the app must understand the text).
Back on planet Earth, IR is basically about finding a particualr entry in a B+
tree and doing some cosine calculations pretty fast. C is perfectly OK for it,
especially if performance is extremely important.
--
Fernando Rodr�guez
frr at wanadoo dot es
--
Fernando Rodr�guez <·······@must.die> writes:
> On Fri, 11 Jan 2002 15:55:33 -0600, "Bradford W. Miller"
> <·················@motorola.com> wrote:
>
> >Performance is important, but until IR delivers something that
> >actually understands both the search query and the text it indexes,
> >it will never live up to its possibilities.
> >
> >"I want all documents that could reasonably convince someone who is
> >currently a pagan to convert to Catholicism, assuming they are over
> >30 with at least one child, and does not include any pictures of
> >John-Paul II."
>
> Not only that's science fiction, but it has almost nothing to do
> with IR, that's AI (since it implies that the app must understand
> the text).
It's getting less science fiction every year.
> Back on planet Earth, IR is basically about finding a particualr
> entry in a B+ tree and doing some cosine calculations pretty fast. C
> is perfectly OK for it, especially if performance is extremely
> important.
Amazing -- what chances are that your planet will be called the same
as ours... On this Earth, you have this Internet thing that allows
you to verify things -- go to "areas of interests" in
http://www.sigir2002.org/, or just look at stuff in
http://www.acm.com/sigir/. B trees and cosines are important but so
is the above.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
On 12 Jan 2002 18:45:38 -0500, Eli Barzilay <···@barzilay.org> wrote:
>> Back on planet Earth, IR is basically about finding a particualr
>> entry in a B+ tree and doing some cosine calculations pretty fast. C
>> is perfectly OK for it, especially if performance is extremely
>> important.
>
>Amazing -- what chances are that your planet will be called the same
>as ours...
I don't think that planet Earth will be called Wonderland anytime soon. ;-)
Last time we tried renaming it, we started an AI winter...
>On this Earth, you have this Internet thing that allows
>you to verify things -- go to "areas of interests" in
>http://www.sigir2002.org/, or just look at stuff in
I'm familiar with the sigir activities, but 'areas of interest' is quite
different from 'areas of expertise'.
>http://www.acm.com/sigir/. B trees and cosines are important but so
>is the above.
It certainly is, but text understanding as decribed by Bradford is not even
science fiction, it's just wishful thinking. Didn't we learn a thing since the
"General" Problem Solver? :-P
--
Fernando Rodr�guez
frr at wanadoo dot es
--
Fernando Rodr�guez <·······@must.die> writes:
[shuffled]
> I'm familiar with the sigir activities, but 'areas of interest' is
> quite different from 'areas of expertise'.
So going back quickly, the statement that "it [fancy text example] has
almost nothing to do with IR" is true if you replace "IR" by "the
expertise of IR"...
> I don't think that planet Earth will be called Wonderland anytime
> soon. ;-) Last time we tried renaming it, we started an AI winter...
> [...]
> It certainly is, but text understanding as decribed by Bradford is
> not even science fiction, it's just wishful thinking. Didn't we
> learn a thing since the "General" Problem Solver? :-P
The CS world definitely learned its lesson from that winter... This
is why today people are attacking this problem very carefully. For
example, one lesson is that using statistics is important as opposed
to symbolic systems (with the GPS being one of its classic early
examples). So, people are being more careful not to have another
winter explosion, but it doesn't mean that there is no work and all
that stuff is now strictly dream stuff. For example, parsing NL is
one of these dreams, and there are things now that can do a decent
job. For example, for an input of:
| A naval commander who had observed the uss vincennes in the persian
| gulf said the ship had no good reason for shooting down an Iranian
| civilian airliner killing all 290 aboard.
You get something that might not look too exciting first, but it's not
too far from something you can use directly in a program:
| (SVP 1
| (NPB 2 (1 DT "A")
| (2 JJ "NAVAL")
| (3 NN "COMMANDER")
| (WHNP 0 (4 WP "WHO")
| (VP 0 (5 VBD "HAD")
| (VP-A 0 (6 VBN "OBSERVED")
| (NPB 2 (7 DT "THE")
| (8 NNP "USS")
| (9 NNPS "VINCENNES"))
| (PP 0 (10 IN "IN")
| (NPB 2 (11 DT "THE")
| (12 NNP "PERSIAN")
| (13 NNP "GULF")))))))
| (14 VBD "SAID")
| (VP 1 (NPB 1 (15 DT "THE") (16 NN "SHIP"))
| (17 VBD "HAD")
| (NPB 2 (18 DT "NO")
| (19 JJ "GOOD")
| (20 NN "REASON")
| (PP 0 (21 IN "FOR")
| (VP 0 (22 VBG "SHOOTING")
| (PP 0 (23 IN "DOWN")
| (NPB 3 (24 DT "AN")
| (25 JJ "IRANIAN")
| (26 JJ "CIVILIAN")
| (27 NN "AIRLINER")))
| (VP 0 (28 VBG "KILLING")
| (NPB 1 (29 DT "ALL") (30 CD "290"))
| (ADVP 0 (31 RB "ABOARD"))))))))
So this is pretty far from Bradford's thing, but it doesn't look too
impossible...
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
Slightly on the topic of IR, I think this is probably as good a forum
as any to ask this question on. So, I spent most of yesterday
discovering a really cool algorithm. As I filled up more and more of
a notebook proving to myself that it did in fact work, and seemed to
have the complexity I thought it did, I started getting pretty
excited. I couldn't find anything relevant on this subject before I
discovered this algorithm. After looking at what I'd come up with, I
tried describing how I was doing things into a search engine for a
while, and discovered that indeed, Galil and Park described an
equivalent algorithm in 1990 in "An improved algorithm for approximate
string matching". I was finding the longest common substring of two
strings.
So, I wasn't surprised that I wasn't the first person to discover
this. However, if I'm going to avoid a repeat of this incident, I
should probably do some reading. Anyone have any recommendations?
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
I meant to change the subject line before I posted this, becuase
"true faith" doesn't quite capture the gist of the message :)
-Thomas, who needs to proofread his usenet posts better today
···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> Slightly on the topic of IR, I think this is probably as good a forum
> as any to ask this question on. So, I spent most of yesterday
> discovering a really cool algorithm. As I filled up more and more of
> a notebook proving to myself that it did in fact work, and seemed to
> have the complexity I thought it did, I started getting pretty
> excited. I couldn't find anything relevant on this subject before I
> discovered this algorithm. After looking at what I'd come up with, I
> tried describing how I was doing things into a search engine for a
> while, and discovered that indeed, Galil and Park described an
> equivalent algorithm in 1990 in "An improved algorithm for approximate
> string matching". I was finding the longest common substring of two
> strings.
>
> So, I wasn't surprised that I wasn't the first person to discover
> this. However, if I'm going to avoid a repeat of this incident, I
> should probably do some reading. Anyone have any recommendations?
>
> --
> /|_ .-----------------------.
> ,' .\ / | No to Imperialist war |
> ,--' _,' | Wage class war! |
> / / `-----------------------'
> ( -. |
> | ) |
> (`-. '--.)
> `. )----'
>> So, I wasn't surprised that I wasn't the first person to discover
>> this. However, if I'm going to avoid a repeat of this incident, I
>> should probably do some reading. Anyone have any recommendations?
Algorithms on Strings, Trees, and Sequences:
Computer Science and Computational Biology by Dan Gusfield
http://www.amazon.com/exec/obidos/ASIN/0521585198/
-- Kimmo, http://www.iki.fi/kt/
((lambda (integer)
(coerce (loop for i upfrom 0 by 8 below (integer-length integer)
collect (code-char (ldb (byte 8 i) integer))) 'string))
100291759904362517251920937783274743691485481194069255743433035)
········@cc.helsinki.fi (Kimmo T Takkunen) writes:
> >> So, I wasn't surprised that I wasn't the first person to discover
> >> this. However, if I'm going to avoid a repeat of this incident, I
> >> should probably do some reading. Anyone have any recommendations?
>
> Algorithms on Strings, Trees, and Sequences:
> Computer Science and Computational Biology by Dan Gusfield
>
> http://www.amazon.com/exec/obidos/ASIN/0521585198/
>
Very good book. Now if anybody has a pointer to a clear explanation
on how to actually build the linear space matching algorithm, I'll be
glad to hear it :)
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th 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'.
Marco Antoniotti <·······@cs.nyu.edu> wrote:
> ········@cc.helsinki.fi (Kimmo T Takkunen) writes:
>> Algorithms on Strings, Trees, and Sequences:
>> Computer Science and Computational Biology by Dan Gusfield
>>
>> http://www.amazon.com/exec/obidos/ASIN/0521585198/
> Very good book. Now if anybody has a pointer to a clear explanation
> on how to actually build the linear space matching algorithm, I'll be
> glad to hear it :)
How did you like the explanation in:
"Introduction to computational molecular biology",
by Setubal and Meidanis?
--
···············@Helsinki.Fi............http://www.cs.helsinki.fi/~ssmoland/
"Money, only green linen paper, is indigestible for all autopoietic
entities like us who lack lignases." - Lynn Margulis
On 13 Jan 2002 11:38:33 -0800, ···@conquest.OCF.Berkeley.EDU (Thomas F.
Burdick) wrote:
>So, I wasn't surprised that I wasn't the first person to discover
>this. However, if I'm going to avoid a repeat of this incident, I
>should probably do some reading. Anyone have any recommendations?
On IR algorithms?
"Information Retrieval, Algorithms and datastructures" from Baeza-Yates et al
--
Fernando Rodr�guez
frr at wanadoo dot es
--
On Mon, 14 Jan 2002 01:41:24 +0100, Fernando Rodríguez
<·······@must.die> wrote:
>On 13 Jan 2002 11:38:33 -0800, ···@conquest.OCF.Berkeley.EDU (Thomas F.
>Burdick) wrote:
>
>
>>So, I wasn't surprised that I wasn't the first person to discover
>>this. However, if I'm going to avoid a repeat of this incident, I
>>should probably do some reading. Anyone have any recommendations?
>
>On IR algorithms?
>"Information Retrieval, Algorithms and datastructures" from Baeza-Yates et al
See http://www.sims.berkeley.edu/~hearst/irbook/
A couple of the chapters can be downloaded.
-------------------
Direct all spam to:
·········@whitehouse.gov, ··············@whitehouse.gov,
·····@aol.com,·······@aol.com,
·····@yahoo.com, ·····@hotmail.com, ·····@msn.com,
·····@cia.gov , ·····@sprint.com, ·····@earthlink.com, ···@ftc.gov, ·······@spamcop.net
israel r t <········@optushome.com.au> writes:
> See http://www.sims.berkeley.edu/~hearst/irbook/
Oooh, goody, someone nearby I can maybe bug in person about this topic :)
Thanks very much to everyone who replied. Hopefully I can fit a bunch
of reading into my frighteningly busy schedule for the next month...
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
>>>>> On Fri, 11 Jan 2002 20:54:20 +0100, Fernando Rodr�guez ("Fernando") writes:
Fernando> On Fri, 11 Jan 2002 09:50:40 -0800, ···@jpl.nasa.gov (Erann Gat) wrote:
>> disdain extends to just about everything that isn't Lisp. This disdain is
>> evident in statements like "substance will end up mattering in the long
>> run", which implicit ly rejects the possibility that substance *has*
>> mattered, and that the world has rejected Lisp for substantial reasons and
>> not just superficial ones.
Fernando> Maybe, but every programmer I met that has rejected lisp, did it for
Fernando> superficial reasons and had a superficial knowledge of the language. :-?
I think the key element of this discussion is the phrase "reject it",
which implies that it is rejected for all purposes. There are various
reasons why different people in different situations would reject Lisp
(or anything else) -- it's the other side of the coin of why you would
advocate something in a particular situation. For example, if you need
control over the bit-level representation of your data structures, and
you can't find any suitable implementation that let's you have that,
then you would sensibly reject Lisp (or Java or C or BASIC or whatever)
for that purpose.
But most people do reject Lisp primarily for superficial reasons,
without understanding it.
Being willing to expend the cost of learning something new is another
reason that people often reject things like Lisp; whether that's
reasonable or not is a matter of circumstance and opinion.
I don't advocate Lisp for all programming, except in some highly
theoretical sense, but it's preferred for most projects that come
down the pike for most people, and I bet that's the position of
most Lispers.
If I were in the business of ultra-high-performance search engines,
I might write the program in some Lisp-like notation, and use Lisp
to "compile" that down to the target environment. There's a point
where the cost versus expressive power of inventing such a language
pays off, and one would need more specific information to analyze
whether it would gain anything.
On Fri, 11 Jan 2002 09:50:40 -0800, ···@jpl.nasa.gov (Erann Gat) wrote:
>Maybe some people did, but the question posed to me was "what is taking so
>long for [me] and Peter Norvig to convert Google to the true faith?" or
>words to that effect. The premise behind that question is that Lisp is
>"the true faith," and that it would actually make sense to convert Google
>to it.
Hold on, I'm sure there was also a smile somewhere in my post. :-) I hope
nobody has taken my (our) usage of the words 'true faith' too seriously...
I understand that lisp isn't the appropriate language for building the core
information retrieval engine for something as huge as google, but maybe it's
appropriate for some intelligent analysis of the data, such as the data
obtained with the googlebar... :-?
Since there were 2 well know lispers working at google, I curious if lisp was
been used (and how) over there.
>A long time ago I wrote a response to something that Kent Pitman wrote but
>I never posted it. It seems apropos here, so I dug it out of the bit
>bucket:
>
>disdain extends to just about everything that isn't Lisp. This disdain is
>evident in statements like "substance will end up mattering in the long
>run", which implicit ly rejects the possibility that substance *has*
>mattered, and that the world has rejected Lisp for substantial reasons and
>not just superficial ones.
Maybe, but every programmer I met that has rejected lisp, did it for
superficial reasons and had a superficial knowledge of the language. :-?
--
Fernando Rodr�guez
frr at wanadoo dot es
--
On Fri, 11 Jan 2002 09:50:40 -0800, ···@jpl.nasa.gov (Erann Gat)
wrote:
Kent:
>> that the substance will end up mattering in the long run.
>
>The community seems to share a disdain for more than just advocacy. Our
>disdain extends to just about everything that isn't Lisp. This disdain is
>evident in statements like "substance will end up mattering in the long
>run", which implicit ly rejects the possibility that substance *has*
>mattered, and that the world has rejected Lisp for substantial reasons and
>not just superficial ones.
This seems to be typical of most marginal communities.
I have seen variants of the argument "substance will eventually win
" in the smalltalk, ada, eiffel, os2 and sgi communities.
It seems improbable that every marginalised language is going to win.
Lisp, Ada , Eiffel and Smalltalk are all excellent languages, far
superior to the Gang of Three ( Java, C++ , C ).
Yet, if Kent is right, they may have all been " rejected ... for
substantial reasons and not just superficial ones."
Will we all end up like the Moonies , convinced that our faith is the
One True Faith while the rest of the world moves on ?
israel r t wrote:
> This seems to be typical of most marginal communities.
> I have seen variants of the argument "substance will eventually win
> " in the smalltalk, ada, eiffel, os2 and sgi communities.
> It seems improbable that every marginalised language is going to win.
>
> Lisp, Ada , Eiffel and Smalltalk are all excellent languages, far
> superior to the Gang of Three ( Java, C++ , C ).
>
> Yet, if Kent is right, they may have all been " rejected ... for
> substantial reasons and not just superficial ones."
>
> Will we all end up like the Moonies , convinced that our faith is the
> One True Faith while the rest of the world moves on ?
I have not done Ada or Eiffel,
have done Smalltalk and Lisp,
used to teach Smalltalk.
I think the reason is mindshare,
which unfortunately looks pretty relevant to a hiring manager.
Not very many people can use these languages well.
It's true that two or three people who can use them well
can outproduce a whole roomful of very competent C/C++/Java guys.
But a manager is highly influenced by the Truck Effect:
if one of your exotic wonderboys goes away for any reason,
he can be very hard to replace.
Furthermore, the loss of one of these
is equivalent to the loss of a whole team of C/C++/Java guys.
Yes, I know the time/cost tradeoffs,
but most managers don't want to hear the facts on this issue,
they just want to know if they can hire someone off the street,
and street people don't do Smalltalk.
I'm doing C++ right now,
and I'm painfully aware of just how unproductive this thing is.
But my client believes that I can be replaced if I go splat,
and that belief helps them get through the day.
Underneath it all,
my work is informed by my Smalltalk and Lisp experience
in ways that your average C/C++/Java guy just doesn't get,
and my client understands that I know something they don't.
I would love to be able to do Smalltalk all day long.
I would hate to go through life with the outlook of a C guy.
It's hard, but I try to be content,
and I go home and work on learning APL.
For those of us who actually have to produce things,
it's what you feed your brain that's relevant,
and C and its children are not enough.
Steve
--
Steven T Abell
Software Designer
http://www.brising.com
In software, nothing is more concrete than a good abstraction.
"Steven T Abell" <·····@brising.com> wrote in message
······················@brising.com...
> israel r t wrote:
> > This seems to be typical of most marginal communities.
> > I have seen variants of the argument "substance will eventually win
> > " in the smalltalk, ada, eiffel, os2 and sgi communities.
> > It seems improbable that every marginalised language is going to win.
> >
> > Lisp, Ada , Eiffel and Smalltalk are all excellent languages, far
> > superior to the Gang of Three ( Java, C++ , C ).
> >
> > Yet, if Kent is right, they may have all been " rejected ... for
> > substantial reasons and not just superficial ones."
> >
> > Will we all end up like the Moonies , convinced that our faith is the
> > One True Faith while the rest of the world moves on ?
>
> I have not done Ada or Eiffel,
> have done Smalltalk and Lisp,
> used to teach Smalltalk.
>
> I think the reason is mindshare,
> which unfortunately looks pretty relevant to a hiring manager.
>
> Not very many people can use these languages well.
> It's true that two or three people who can use them well
> can outproduce a whole roomful of very competent C/C++/Java guys.
> But a manager is highly influenced by the Truck Effect:
> if one of your exotic wonderboys goes away for any reason,
> he can be very hard to replace.
> Furthermore, the loss of one of these
> is equivalent to the loss of a whole team of C/C++/Java guys.
> Yes, I know the time/cost tradeoffs,
> but most managers don't want to hear the facts on this issue,
> they just want to know if they can hire someone off the street,
> and street people don't do Smalltalk.
>
> I'm doing C++ right now,
> and I'm painfully aware of just how unproductive this thing is.
> But my client believes that I can be replaced if I go splat,
> and that belief helps them get through the day.
> Underneath it all,
> my work is informed by my Smalltalk and Lisp experience
> in ways that your average C/C++/Java guy just doesn't get,
> and my client understands that I know something they don't.
>
> I would love to be able to do Smalltalk all day long.
> I would hate to go through life with the outlook of a C guy.
> It's hard, but I try to be content,
> and I go home and work on learning APL.
> For those of us who actually have to produce things,
> it's what you feed your brain that's relevant,
> and C and its children are not enough.
>
> Steve
> --
> Steven T Abell
> Software Designer
> http://www.brising.com
>
> In software, nothing is more concrete than a good abstraction.
I think Steve is right. I too am primarily a C++ developer but would like to
be using langages such as Eiffel, which I've read a lot about but not used.
However, I'm constrained by learning what I have to learn to make a living
and what can be leveraged off of C++. So things like C# and ASP are worth my
while investing in and Eiffel isn't - for now, at any rate.
I think that it is good for programmers to be familiar with more than one
language, even if only cursorily. My C++ has improved and is improving
(hopefully) by being informed by important concepts from Eiffel and from
more general reading on software engineering.
It's always going to be hard for something new to get a look in. There is,
of course, the economic reason that, for example, C/C++ guys are two a penny
but Eiffel and Smalltalk guys aren't. That's why you often need some kind of
killer application or killer technology area to leverage off of. Eiffel, for
example, may get a boost from .Net, especially as its offering a few things
that the other languages don't. But I fear it's not being marketed very well
at the moment.
Another barrier to overcome is programmers themselves. It's difficult enough
to get C programmers to buy into OO and to get C++ programmers to use the
techniques that exist to write safer, more maintainable code. This may
partly be due to the complexity of C++ but I also think it's just
boneheadedness (e.g., the attitude "I've always used sprintf why try
anything different?")
In my last job, a difficult-to-fine damaged memory problem was caused by an
incorrectly coded sprintf. This would not have been caused by using the more
modern C++ alternatives. But a dyed-in-the-wool C programmer would probably
just say that programmers should be competent enough not to make mistakes.
However, having said this, the minority languages would probably help their
case better by not dogmatically dismissing everything else but by being more
constructive. Not everything in C/C++ is bad.
From: Erik Naggum
Subject: Re: True faiths ( was Re: The true faith )
Date:
Message-ID: <3219936759616091@naggum.net>
* "Kevin McFarlane" <·····@atech.globalnet.co.uk>
| It's always going to be hard for something new to get a look in. There
| is, of course, the economic reason that, for example, C/C++ guys are two
| a penny but Eiffel and Smalltalk guys aren't.
This is one of the most misleading abuses of statistics around. Just
because the probability that you hit a C++ programmer if you throw a rock
into a crowd is very high, does not mean that the probability that he can
replace _your_ C++ programmer is any higher than finding a replacement
Eiffel or Smalltalk programmer. Because you have to weed through tons of
idiots who only _claim_ they know C++, the effort required to find a real
replacement may be significantly lower for Eiffel or Smalltalk. Besides,
if you can find a good programmer, chances are very good that he will be
able to learn any programming language you use reasonably well in the
time it would take to find a good C++ programmer. And learning from the
sources of the previous programmer is a lot easier than learning the
language from scratch in a general, application-independent way.
I have actually witnessed this. A company I worked for got a new manager
level that was completely superfluous, so the new manager had to prove to
herself that she had a real job, and spent a lot of time arguing against
using languages that were not mainstream, and basically made it hard to
use anything but Java, and many good people quit. Then a Java man got
seriously ill. She was unable to replace him in the 5 months he was
away. The other Java men could not do his work. To her amazement,
choice of language mattered less than the other skills the programmers
had. The conclusion from this story that this manager actually arrived
at was that it was bad to have skilled programmers -- she alone should
make the design decisions and programmers would simply implement them.
She could now return to her policy of using only mainstream languages and
hire only unskilled programmers who lied about knowing a language. As
far as I know, nothing interesting has happened at that company for a
long time.
///
--
Erik Naggum <····@naggum.net> writes:
> I have actually witnessed this. A company I worked for got a new manager
> level that was completely superfluous, so the new manager had to prove to
> herself that she had a real job, and spent a lot of time arguing against
> using languages that were not mainstream, and basically made it hard to
> use anything but Java, and many good people quit. Then a Java man got
> seriously ill. She was unable to replace him in the 5 months he was
> away. The other Java men could not do his work.
The scary thing is that your experience is no exception, there are
_so_ many representatives of this type of manager around. It's the
kind of manager that actually thinks that hiring java or C++
programmers is so easy because they teach these languages at "every
school", and fail to understand that having successfully spent 2 or 3
years at some school which educates "it professionals" doesn't
necessarily imply that you're suited to be a programmer at all, and it
_definitely_ doesn't mean that you're well trained in the languages
they happen to use at that school.
--
(espen)
On Mon, 14 Jan 2002 08:12:01 GMT, Espen Vestre
<·····@*do-not-spam-me*.vestre.net> wrote:
>The scary thing is that your experience is no exception, there are
>_so_ many representatives of this type of manager around. It's the
>kind of manager that actually thinks that hiring java or C++
>programmers is so easy because they teach these languages at "every
>school"
It also explains why managers speak so disparagingly of programmers as
"mere coders"
-------------------
Direct all spam to:
·········@whitehouse.gov, ··············@whitehouse.gov,
·····@aol.com,·······@aol.com,
·····@yahoo.com, ·····@hotmail.com, ·····@msn.com,
·····@cia.gov , ·····@sprint.com, ·····@earthlink.com, ···@ftc.gov, ·······@spamcop.net
From: Patrick Doyle
Subject: Re: True faiths ( was Re: The true faith )
Date:
Message-ID: <Gq0qMK.8u5@ecf.utoronto.ca>
israel r t <········@optushome.com.au> wrote:
>On Mon, 14 Jan 2002 08:12:01 GMT, Espen Vestre
><·····@*do-not-spam-me*.vestre.net> wrote:
>
>>The scary thing is that your experience is no exception, there are
>>_so_ many representatives of this type of manager around. It's the
>>kind of manager that actually thinks that hiring java or C++
>>programmers is so easy because they teach these languages at "every
>>school"
>
>It also explains why managers speak so disparagingly of programmers as
>"mere coders"
Right: because most of them are. :-)
--
--
Patrick Doyle
······@eecg.toronto.edu
On Wed, 16 Jan 2002 06:42:20 GMT, ······@eecg.toronto.edu (Patrick
Doyle) wrote:
>>It also explains why managers speak so disparagingly of programmers as
>>"mere coders"
>Right: because most of them are. :-)
Right.
Their instructors are just as bad.
I met someone who is teaching VB and Pascal at the local TAFE ( sort
of substandard community college ).
He actually thought that Pascal is an OOP !
He either does not know what OOP is or else he is confusing Borlands
proprietary Delphi extensions with Pascal.
I now see kids who can barely walk without drooling who want to "do
computers because it pays well". In another decade they would have
been barely adequate butchers or bakers. Now they become VB
programmers and "help desk" people.
---------------------------------------------------------
Devising your own font (Devanagari, pinhead graphics, etc.)
and using it in the mail is a good tactic,as is finding some way to use existing obscure fonts.
Aramaic , Pre-Rashi Hebrew and Sanskrit are particularly useful in this regard.
-- from the Symbolics Guidelines for Sending Mail
israel r t <········@optushome.com.au> writes:
> He either does not know what OOP is or else he is confusing Borlands
> proprietary Delphi extensions with Pascal.
IRL he is right, isn't he? I mean: Isn't Delphi the only Pascal that
can be considered to be "alive & kicking"? (I don't know Delphi,
but AFAIK, the OO extensions actually have a longer history, they
go back to Apple's Object Pascal)
--
(espen)
On Wed, 16 Jan 2002 08:55:58 GMT, Espen Vestre
<·····@*do-not-spam-me*.vestre.net> wrote:
>israel r t <········@optushome.com.au> writes:
>
>> He either does not know what OOP is or else he is confusing Borlands
>> proprietary Delphi extensions with Pascal.
>
>IRL he is right, isn't he? I mean: Isn't Delphi the only Pascal that
>can be considered to be "alive & kicking"?
Well Pascal tended to hang around for quite a while in education areas
because
a) it was originally designed for education
b) they had it and what's the point of buying a new environment?
Yahoo lists a couple of compilers available for Pascal now.
> (I don't know Delphi,
>but AFAIK, the OO extensions actually have a longer history, they
>go back to Apple's Object Pascal)
Delphi was built on top of Object Pascal, I'm not sure who originally
did Object Pascal.
--
"Hope is replaced by fear and dreams by survival, most of us get by."
Stuart Adamson 1958-2001
Mad Hamish
Hamish Laws
······@bigpond.com
In article <················@news.bigpond.com>, ······@bigpond.com (Mad
Hamish) wrote:
> > (I don't know Delphi,
> >but AFAIK, the OO extensions actually have a longer history, they
> >go back to Apple's Object Pascal)
>
> Delphi was built on top of Object Pascal, I'm not sure who originally
> did Object Pascal.
Nicklaus Wirth spent a year on sabbatical at Apple, designing Object
Pascal with them.
-- Bruce
Bruce Hoult <·····@hoult.org> wrote in message news:<···························@news.paradise.net.nz>...
>
> Nicklaus Wirth spent a year on sabbatical at Apple, designing Object
> Pascal with them.
>
> -- Bruce
Two thoughts.
If I remember correctly, Pascal was originally designed based on a
provability calculus. That is, Pascal programs were supposed to be
provably correct (don't ask me to define that), which is why there
were so many things "missing", such as C-equivalents "break" and
"goto". Provability gave way to usability...
If you read back a few messages about mindless managers and mere
coders, I thought of a very frightening parallel. Anyone out there
read "Atlas Shrugged" by Ayn Rand? How about The Peter Principle?
This sounds all too much like promotion to incompentence or epidemic
ignorance and apathy. Would that John Galt were here, or perhaps
*not* here...
-- Tom
In article <····························@posting.google.com>, ·······@qwest.com (Tom Hawker) writes:
> If I remember correctly, Pascal was originally designed based on a
> provability calculus. That is, Pascal programs were supposed to be
> provably correct (don't ask me to define that), which is why there
> were so many things "missing", such as C-equivalents "break" and
> "goto". Provability gave way to usability...
DEC's SVS project to provide an A1 Security Kernel on VAX was written
in Pascal, with special caution taken to omit the Pascal runtime library
DEC generally used, because that was written in a lower level language.
This had to do with provability of the implementation.
The project was dumped after going into Field Test because DEC found out
there was no real customer demand. (NCSC wanted other agencies to use
A1 systems, other agencies did not want to spend their money on that.)
·······@qwest.com (Tom Hawker) wrote in message news:<····························@posting.google.com>...
> If I remember correctly, Pascal was originally designed based on a
> provability calculus. That is, Pascal programs were supposed to be
> provably correct (don't ask me to define that), which is why there
> were so many things "missing", such as C-equivalents "break" and
> "goto".
Wirth's original Pascal *did* have goto. In fact, it could jump right
out of the current procedure up the call stack, so it was actually a
bit like C's longjmp() function!
············@hotmail.com (Peter Gummer) wrote in message news:<···························@posting.google.com>...
> ·······@qwest.com (Tom Hawker) wrote in message news:<····························@posting.google.com>...
> > If I remember correctly, Pascal was originally designed based on a
> > provability calculus. That is, Pascal programs were supposed to be
> > provably correct (don't ask me to define that), which is why there
> > were so many things "missing", such as C-equivalents "break" and
> > "goto".
>
> Wirth's original Pascal *did* have goto. In fact, it could jump right
> out of the current procedure up the call stack, so it was actually a
> bit like C's longjmp() function!
The first Pascal compilers were in fact written in Pascal and that
code contained "goto"s.
Greg
From: Hartmann Schaffer
Subject: Re: True faiths ( was Re: The true faith )
Date:
Message-ID: <3c6b194a@news.sentex.net>
In article <····························@posting.google.com>,
·······@qwest.com (Tom Hawker) writes:
> If I remember correctly, Pascal was originally designed based on a
> provability calculus. That is, Pascal programs were supposed to be
> provably correct (don't ask me to define that), which is why there
> were so many things "missing", such as C-equivalents "break" and
> "goto". Provability gave way to usability...
i am quite sure that you remember incorrectly ;-): Pascal had goto
(the labels were numeric, which helped the argument that gotos made
code unreadable). afair it was tony hoare who used pascal in his
provability calculus (there were some rumors that he was deeply
disturbed by how easy it turned out to be to include goto in the
calculus)
> ...
hs
--
how are we defending our freedom and democracy by dismantling them?
Tom Hawker wrote:
>
> Bruce Hoult <·····@hoult.org> wrote in message news:<···························@news.paradise.net.nz>...
> >
> > Nicklaus Wirth spent a year on sabbatical at Apple, designing Object
> > Pascal with them.
> >
> > -- Bruce
>
> Two thoughts.
>
> If I remember correctly, Pascal was originally designed based on a
> provability calculus. That is, Pascal programs were supposed to be
> provably correct (don't ask me to define that), which is why there
> were so many things "missing", such as C-equivalents "break" and
> "goto". Provability gave way to usability...
You're thinking of Concurrent Pascal, didn't even have recursive
functioon calls, idea beaing you could predict stack usage in advance. I
think the ordinary Pascal was designed to be self documenting rather
than provable.
On Wed, 16 Jan 2002 06:42:20 GMT, ······@eecg.toronto.edu (Patrick
Doyle) wrote:
>>It also explains why managers speak so disparagingly of programmers as
>>"mere coders"
>Right: because most of them are. :-)
Right.
Their instructors are just as bad.
I met someone who is teaching VB and Pascal at the local TAFE ( sort
of substandard community college ).
He actually thought that Pascal is an OOP !
He either does not know what OOP is or else he is confusing Borlands
proprietary Delphi extensions with Pascal.
I now see kids who can barely walk without drooling who want to "do
computers because it pays well". In another decade they would have
been barely adequate butchers or bakers. Now they become VB
programmers and "help desk" people.
---------------------------------------------------------
Devising your own font (Devanagari, pinhead graphics, etc.)
and using it in the mail is a good tactic,as is finding some way to use existing obscure fonts.
Aramaic , Pre-Rashi Hebrew and Sanskrit are particularly useful in this regard.
-- from the Symbolics Guidelines for Sending Mail
From: Immanuel Litzroth
Subject: Re: True faiths ( was Re: The true faith )
Date:
Message-ID: <m2advh9oz5.fsf@enfocus.be>
In this respect the articles
http://www-106.ibm.com/developerworks/java/library/assignment-operator/?dwzone=java
in which the author has a hard time finding a programmer that can
write a c++ assigment operator and
http://oss.software.ibm.com/icu/docs/papers/cpp_report/the_assignment_operator_revisited.html
in which the author admits that he wasn't up to the task either are
interesting and amusing reading
Immanuel
I was particularly impressed with his last paragraph in the second
article. For some reason, he doesn't conclude that there's something
wrong with C++. Can't imagine why...
---------BEGIN-QUOTE-----------
I don't know about you, but there's something really scary to me about a
language where copying state from one object to another is this
complicated. By now, I suspect at least a dozen or two programmers have
contributed something new to this discussion. If it takes this many
programmers to write a simple assignment operator, think how complicated
writing code that actually does something meaningful must be!
--
Remove obvious stuff to e-mail me.
Bob Bane
From: Hyman Rosen
Subject: Re: True faiths ( was Re: The true faith )
Date:
Message-ID: <3C4863C5.6040406@mail.com>
Bob Bane wrote:
> I was particularly impressed with his last paragraph in the second
> article. For some reason, he doesn't conclude that there's something
> wrong with C++. Can't imagine why...
I can. The problem he's trying to solve is difficult; I don't see
anything in its nature which wouldn't be equally difficult in Ada.
Hyman Rosen wrote:
> Bob Bane wrote:
>
> > I was particularly impressed with his last paragraph in the second
> > article. For some reason, he doesn't conclude that there's something
> > wrong with C++. Can't imagine why...
>
> I can. The problem he's trying to solve is difficult; I don't see
> anything in its nature which wouldn't be equally difficult in Ada.
Dijkstra said something once, I believe it was in "A Discipline of
Computer Programming," about the inherent complexity of assignment
and the fact that most programmers did not understand how it actually
worked. In the same article, he suggests that, "until a programmer
really understands assignment, he [sic] does not understand programming."
In C++ or Ada (or whatever) there is no need to write an assignment
operator unless the assignment between two objects is more complex
than predefined assignment. One benefit of the limited type in Ada is
to highlight the dangers of assignment. This is also why most complex
data structures in Ada are limited types.
I am not fond of the C++ idiom for tinkering with assignment, but it is
a reasonable model given the rest of the language design. It is not clear
Ada 95 got it right either, but it feels safer to me. I prefer Ada's
proscription against directly overloading the assignment operator. The
contract is more clear to me if it is written as,
package P is
type T is [tagged] limited private; -- no predefined methods on
limited type
-- public explicit declaration of methods on T
procedure Copy_Deep (Source : in T; Target : in out T);
procedure Copy_Shallow (Source : in T; Target : in out T);
-- pre-conditions on Copy_Deep and Copy_Shallow
Invalid_Source : exception;
-- post-conditions on Copy_Deep and Copy_Shallow
Incomplete_Copy_Operation : exception;
private
-- private methods, if any
-- full definition of T;
end P;
This specification makes clear the contract and still eliminates any
possibility for stupid assignment between objects of the type.
Richard Riehle
"Richard Riehle" <·······@adaworks.com> wrote in message
······················@adaworks.com...
> In C++ or Ada (or whatever) there is no need to write an assignment
> operator unless the assignment between two objects is more complex
> than predefined assignment. One benefit of the limited type in Ada is
> to highlight the dangers of assignment. This is also why most complex
> data structures in Ada are limited types.
That's why I routinely turn off copy-assignment and copy-construction in my
ADTs:
class C
{
public:
C();
//...
private:
C& operator=(const C&);
C(const C&);
//...
};
I recently had to override assignment for a type, but that was only for a
class sans vtable (the type wasn't "tagged"). Fortunately, I haven't had to
overrided assignment for a tagged type.
> This specification makes clear the contract and still eliminates any
> possibility for stupid assignment between objects of the type.
What I showed above is the standard C++ idiom for doing the same.
From: Hyman Rosen
Subject: Re: True faiths ( was Re: The true faith )
Date:
Message-ID: <3C4A58B8.10304@mail.com>
Richard Riehle wrote:
> procedure Copy_Deep (Source : in T; Target : in out T);
> procedure Copy_Shallow (Source : in T; Target : in out T);
I dislike the notion of providing these methods as external interfaces
to a type. It seems wrong to me for a client to have to know what kind
of copy to use - that's the type's business to know.
In article <··············@mail.com>, Hyman Rosen wrote:
>Richard Riehle wrote:
>
>> procedure Copy_Deep (Source : in T; Target : in out T);
>> procedure Copy_Shallow (Source : in T; Target : in out T);
>
>
>I dislike the notion of providing these methods as external interfaces
>to a type. It seems wrong to me for a client to have to know what kind
>of copy to use - that's the type's business to know.
This turns out to be circular reasoning, because what a type ``knows''
is partally defined by the operations you can perform on it.
Suppose that you have N methods for copying an object. I do not take it
as a theorem that you can always make an (N + 1)-th method which unifies
the other N, magically choosing the appropriate one. How can this magic
meta-method possibly know what semantics the caller wants?
···@accton.shaw.ca (Kaz Kylheku) wrote in message news:<···················@news2.calgary.shaw.ca>...
> Suppose that you have N methods for copying an object. I do not take it
> as a theorem that you can always make an (N + 1)-th method which unifies
> the other N, magically choosing the appropriate one. How can this magic
> meta-method possibly know what semantics the caller wants?
A big part of the problem is that copy semantics are tied closely to
the memory management paradigm in use. With garbage collection, it's
common for an assignment statement to simply copy a pointer or
reference such that the target of the assignment refers to the same
object. Without garbage collection, it's much more complicated,
because the target of the assignment statement has to know whether to
free the object when done with it. Names such as deep copy and
shallow copy do not cover the complexities, and might just add more
confusion.
In languages with garbage collection, the best way might be to define
copy to mean shallow copy, and use other names than copy for all other
copying operations. For example, to make a copy on a remote computer,
you could use a name such as send. Thus we would be talking about
three levels of copying: Assignment, meaning to copy the reference to
make something else refer to the same object, copy, meaning to copy
the object itself so it can be modified without modifying the original
object, and the third level, where the copy operation would be named
send or whatever name might be appropriate for the purpose of each
such copy operation.
Kaz Kylheku <···@ashi.footprints.net> wrote:
>In article <··············@mail.com>, Hyman Rosen wrote:
>>Richard Riehle wrote:
>>
>>> procedure Copy_Deep (Source : in T; Target : in out T);
>>> procedure Copy_Shallow (Source : in T; Target : in out T);
>>
>>I dislike the notion of providing these methods as external interfaces
>>to a type. It seems wrong to me for a client to have to know what kind
>>of copy to use - that's the type's business to know.
>
>This turns out to be circular reasoning, because what a type ``knows''
>is partally defined by the operations you can perform on it.
>
>Suppose that you have N methods for copying an object. I do not take it
>as a theorem that you can always make an (N + 1)-th method which unifies
>the other N, magically choosing the appropriate one. How can this magic
>meta-method possibly know what semantics the caller wants?
I must be crazy. I have never written a system where the semantics
of the "copy" operation mattered. Mainly, this is for two reasons:
1. A lot of my data is immutable, so the copying semantics are moot.
2. Instead of copying an existing object, my usual idiom is to create a
new one from scratch.
I suppose there are some cases where these two things don't apply, or
would be inappropriate, and one would have to think very carefully about
the semantics of copying, but I can't think of such a case off the top
of my head.
I suppose that only says something about my inexperience as a programmer.
Can anyone show an example of a situation where copying semantics really
matter?
--
--
Patrick Doyle
······@eecg.toronto.edu
From: Steven T Abell
Subject: Re: Copying semantics molehill (was Re: True faiths)
Date:
Message-ID: <3C4D8AC7.37C31EEC@brising.com>
> Can anyone show an example of a situation where copying semantics really
> matter?
Sure.
Imagine you have an object with some simple attributes,
ans some connections to other complex objects,
and you want to save this object to a file.
A shallow copy would only take those attributes that were simple,
for example, numbers and strings.
A deep copy would also copy out all of the connected complex objects,
and all of their connected objects, and all of their connected objects, etc.
For a great many objects that you will actually build,
a deep copy will eventually copy the entire image,
or get stuck in a copy cycle,
where some referent of the original object
refers back to the original object.
There are tools, such as in VisualWorks,
that scan the copy graph before copying
to work around this cyclic copying.
They work, but they are often unavoidably slow.
The exact meaning of "copy" turns out to be a *really* hard problem:
there is no single answer that works in all cases.
One place where copy depth is often a problem is in copying collections.
The usual copy creates a duplicate collection
with references to the same objects as the original collection.
This might be what you want, or it might not.
For this kind of copy,
you have to remember that changes to a collection element
will appear in *both* collections,
since both collections refer to that object.
A deeper copy copies the elements also,
but the question arises: How deeply do you copy?
Once again, there is no simple answer.
You have to think very carefully about your application's needs
and then code your copy semantics just as carefully.
Steve
--
Steven T Abell
Software Designer
http://www.brising.com
In software, nothing is more concrete than a good abstraction.
In article <·················@brising.com>,
Steven T Abell <·····@brising.com> wrote:
>> Can anyone show an example of a situation where copying semantics really
>> matter?
>
>Sure.
>Imagine you have an object with some simple attributes,
>ans some connections to other complex objects,
>and you want to save this object to a file.
Ok, I must admit, that's a good one. It's not really a copying issue
per se, but a persistence issue, though they have a lot in common.
I'm no expert on object persistence, so I'll have to leave it at that. :-)
--
--
Patrick Doyle
······@eecg.toronto.edu
In article <··········@ecf.utoronto.ca>, Patrick Doyle wrote:
>Kaz Kylheku <···@ashi.footprints.net> wrote:
>>In article <··············@mail.com>, Hyman Rosen wrote:
>>>Richard Riehle wrote:
>>>
>>>> procedure Copy_Deep (Source : in T; Target : in out T);
>>>> procedure Copy_Shallow (Source : in T; Target : in out T);
>>>
>>>I dislike the notion of providing these methods as external interfaces
>>>to a type. It seems wrong to me for a client to have to know what kind
>>>of copy to use - that's the type's business to know.
>>
>>This turns out to be circular reasoning, because what a type ``knows''
>>is partally defined by the operations you can perform on it.
>>
>>Suppose that you have N methods for copying an object. I do not take it
>>as a theorem that you can always make an (N + 1)-th method which unifies
>>the other N, magically choosing the appropriate one. How can this magic
>>meta-method possibly know what semantics the caller wants?
>
>I must be crazy. I have never written a system where the semantics
>of the "copy" operation mattered. Mainly, this is for two reasons:
>
>1. A lot of my data is immutable, so the copying semantics are moot.
>
>2. Instead of copying an existing object, my usual idiom is to create a
>new one from scratch.
Anecdotal evidence. I have written systems where it mattered.
Here is a recent example: a protocol stack where I have three ways
to copy a network buffer buffer object. I can copy a pointer, and
increment a reference count. I can copy the header structure which
maintains various pointers into the buffer, and bump up a lower reference
count on the buffer. Or I can do a deep copy which copies the buffer
as well.
This data is not immutable, so the copying semantics are not moot.
>I suppose there are some cases where these two things don't apply, or
>would be inappropriate, and one would have to think very carefully about
>the semantics of copying, but I can't think of such a case off the top
>of my head.
>
>I suppose that only says something about my inexperience as a programmer.
>Can anyone show an example of a situation where copying semantics really
>matter?
How about a Lisp example?
(eq 'a 'a) ==> T
(eq 'a (copy-symbol 'a)) ==> NIL
A copy of a symbol is usually useless, because a symbol is meaningful
precisely because it is EQ to itself. So you usually need shallow,
reference copies of a symbol.
If a symbol is embedded in an object, and you want to copy that object,
you probably want to copy those embeddded symbols by reference. And then
you are no longer making an entirely new object from scratch; the common
symbols are shared substructure.
In article <······················@news2.calgary.shaw.ca>,
Kaz Kylheku <···@ashi.footprints.net> wrote:
>
>Here is a recent example: a protocol stack where I have three ways
>to copy a network buffer buffer object. I can copy a pointer, and
>increment a reference count. I can copy the header structure which
>maintains various pointers into the buffer, and bump up a lower reference
>count on the buffer. Or I can do a deep copy which copies the buffer
>as well.
>
>This data is not immutable, so the copying semantics are not moot.
Ok, so when you copy a container object--like lists, arrays, etc.--you
need to know whether to copy its contents too. Is this the same issue?
>If a symbol is embedded in an object, and you want to copy that object,
>you probably want to copy those embeddded symbols by reference. And then
>you are no longer making an entirely new object from scratch; the common
>symbols are shared substructure.
I have a hard time picturing how this is implemented. Does one just
contain a reference to part of the other?
--
--
Patrick Doyle
······@eecg.toronto.edu
······@eecg.toronto.edu (Patrick Doyle) wrote in message news:<··········@ecf.utoronto.ca>...
> I must be crazy. I have never written a system where the > semantics of the "copy" operation mattered. Mainly, this
> is for two reasons:
>
> 1. A lot of my data is immutable, so the copying semantics are moot.
>
> 2. Instead of copying an existing object, my usual idiom is to create a
> new one from scratch.
Not crazy, but unusual. You are saying that you do not
do assignments of the form
a := b;
where a and b are both objects and that you do not
use IN OUT parameters. It is certainly possible to write
code with these constraints, but definitely unusual.
In article <····························@posting.google.com>,
Robert Dewar <·····@gnat.com> wrote:
>······@eecg.toronto.edu (Patrick Doyle) wrote in message news:<··········@ecf.utoronto.ca>...
>> I must be crazy. I have never written a system where the semantics
>> of the "copy" operation mattered. Mainly, this is for two reasons:
>>
>> 1. A lot of my data is immutable, so the copying semantics are moot.
>>
>> 2. Instead of copying an existing object, my usual idiom is to create a
>> new one from scratch.
>
>Not crazy, but unusual. You are saying that you do not
>do assignments of the form
>
> a := b;
>
>where a and b are both objects and that you do not
>use IN OUT parameters.
No, actually I'm saying what I said. ;-)
>It is certainly possible to write code with these constraints, but
>definitely unusual.
It is most certainly not unusual. For instance, Java has neither
object-wise assignment nor in-out parameters.
Do you mean it's unusual in some particular language?
--
--
Patrick Doyle
······@eecg.toronto.edu
Hyman Rosen wrote:
> Richard Riehle wrote:
>
> > procedure Copy_Deep (Source : in T; Target : in out T);
> > procedure Copy_Shallow (Source : in T; Target : in out T);
>
> I dislike the notion of providing these methods as external interfaces
> to a type. It seems wrong to me for a client to have to know what kind
> of copy to use - that's the type's business to know.
Well I don't like having an assignment statement that behaves in an
unpredictable way when I use it. So I prefer having the copy semantics
spelled out as clearly as possible. This clarity assures me that, when
I call a method, it will behave as I expected. From my perspective,
clarity is an essential feature of a type. Behaving according to my
expectations is another nice feature for any method, whether it is
assignment or some other method.
As to the client needing to know which copy to use, in practice we
would make only one available, but we would make clear the semantics
of that copy. The other point is that using Ada's limited types, we
don't have to worry about making mistakes regarding the assignment
operation.
Richard Riehle
From: Hyman Rosen
Subject: Re: True faiths ( was Re: The true faith )
Date:
Message-ID: <3C4BE556.7040707@mail.com>
Richard Riehle wrote:
> Hyman Rosen wrote:
>>Richard Riehle wrote:
>>> procedure Copy_Deep (Source : in T; Target : in out T);
>>> procedure Copy_Shallow (Source : in T; Target : in out T);
>>>
>>I dislike the notion of providing these methods as external interfaces
>>to a type. It seems wrong to me for a client to have to know what kind
>>of copy to use - that's the type's business to know.
>
> Well I don't like having an assignment statement that behaves in an
> unpredictable way when I use it.
I think we can agree on this with unbridled enthusiasm :-)
> So I prefer having the copy semantics spelled out as clearly as possible.
> This clarity assures me that, when I call a method, it will behave as
> I expected.
But the user of a type generally isn't concerned with its innards.
Why would you take a simple concept like copying or assignment and
burden it with implementation details? If you were writing a sort
method for a conatiner, wouldn't you just call it "sort" rather than
"merge_sort' or "bubble_sort"?
And if we were to say "do as Ada does", consider Unbounded_String.
> As to the client needing to know which copy to use, in practice we
> would make only one available, but we would make clear the semantics
> of that copy. The other point is that using Ada's limited types, we
> don't have to worry about making mistakes regarding the assignment
> operation.
Well, the normal semantics of a copy are that the source and destination
are not tied to each other after the copy is made. Of course, internally
that might not be true, because you could be maintaining reference
counts, and doing copy-on-write. You would place all that information
into the routine name?
And limited types are irrelevant here. C++ and Ada can both prevent
assignment from compiling. The problem was writing assignment correctly
when you do want to provide it.
Hyman Rosen wrote:
> But the user of a type generally isn't concerned with its innards.
> Why would you take a simple concept like copying or assignment and
> burden it with implementation details? If you were writing a sort
> method for a conatiner, wouldn't you just call it "sort" rather than
> "merge_sort' or "bubble_sort"?
In fact, I do care about this. The performance characteristics
of each kind of sort are important. Under some circumstances
I want to use a Merge Sort utility and other times I want a
Quicksort. This is one place where I can benefit from a knowledge
of the Big O notation.
> Well, the normal semantics of a copy are that the source and destination
> are not tied to each other after the copy is made. Of course, internally
> that might not be true, because you could be maintaining reference
> counts, and doing copy-on-write. You would place all that information
> into the routine name?
I will want to have information in the contract that gives the client of
my specification an opportunity to choose which method to invoke,
and what to expect from it. It might be quite useful for a client to
know that a method is managed or not managed, but this does not
have to be part of the name. In my example, I included preconditions
and postconditions in the form of meaningful exception names. These also
provide some information for the client.
In the legal world, there is something called "due notice." Any contract,
including a type/class specfication, needs to be explicit.
> And limited types are irrelevant here. C++ and Ada can both prevent
> assignment from compiling. The problem was writing assignment correctly
> when you do want to provide it.
Actually, when considering the need for clarity, I think there is a difference.
The technique for preventing assignment in C++ is not, in my mind, as
clear as the declaration of a limited type. The fact that some construct
can be expressed in a particular language does not mean it is best
expressed in that language. We will simply have to agree to disagree
on the point regarding limited types.
Richard Riehle
In article <················@mail.com>, Hyman Rosen wrote:
>Richard Riehle wrote:
>
>> Hyman Rosen wrote:
>>>Richard Riehle wrote:
>>>> procedure Copy_Deep (Source : in T; Target : in out T);
>>>> procedure Copy_Shallow (Source : in T; Target : in out T);
>>>>
>>>I dislike the notion of providing these methods as external interfaces
>>>to a type. It seems wrong to me for a client to have to know what kind
>>>of copy to use - that's the type's business to know.
>>
>> Well I don't like having an assignment statement that behaves in an
>> unpredictable way when I use it.
>
>
>I think we can agree on this with unbridled enthusiasm :-)
>
>> So I prefer having the copy semantics spelled out as clearly as possible.
>
> > This clarity assures me that, when I call a method, it will behave as
> > I expected.
>
>But the user of a type generally isn't concerned with its innards.
That is false.
>Why would you take a simple concept like copying or assignment and
>burden it with implementation details? If you were writing a sort
>method for a conatiner, wouldn't you just call it "sort" rather than
>"merge_sort' or "bubble_sort"?
The semantics of copying an object are not transparent to the user in
a way that choice of sorting algorithm is transparent.
All sorting algorithms which ensure the same postconditions are
effectively equivalent except for performance.
Different ways of copying an object do not ensure the same postconditions.
They are semantically different, in a way that may matter critically
to the caller.
Here is a slightly better analogy: do you want a stable sort or can you
live with an unstable one? The difference is visible to the caller.
If a stable sort is essential, but an unstable one is invoked, that
is a mistake.
There can be lots of other variations: what comparison function is
used for the elements? Each function leads to a different sort. There
are effectively as many sort operations as there are ways to compare
the elements.
Usually, we arrange for the caller to be able to specify the computation,
so we can offer all of these sorts behind one interface. The function
sorts, but the caller specifies *how*. It's the same thing with object
replication. We can copy in various ways, the caller specifies *how*.
Hyman Rosen <·······@mail.com> wrote in message news:<················@mail.com>...
> Well, the normal semantics of a copy are that the source and destination
> are not tied to each other after the copy is made. Of course, internally
> that might not be true, because you could be maintaining reference
> counts, and doing copy-on-write. You would place all that information
> into the routine name?
Why not?
clone
(returns a deep copy, with no references to original)
link
(shallow copy - just another reference to the original)
clone-on-write
(what it suggests - starts as a "link," but becomes a "clone" when a
client attempts to write to it.)
From: René
Subject: Re: True faiths ( was Re: The true faith )
Date:
Message-ID: <n0zba70b.fsf@esmertec.com>
Bob Bane <····@removeme.gst.com> writes:
> I was particularly impressed with his last paragraph in the second
> article. For some reason, he doesn't conclude that there's something
> wrong with C++. Can't imagine why...
Hmm, I read the below as "There is something wrong with C++!". Or were you
just being ironic?
> ---------BEGIN-QUOTE-----------
>
> I don't know about you, but there's something really scary to me about a
> language where copying state from one object to another is this
> complicated. By now, I suspect at least a dozen or two programmers have
> contributed something new to this discussion. If it takes this many
> programmers to write a simple assignment operator, think how complicated
> writing code that actually does something meaningful must be!
Bjarne Stroustrup often says that complexity is inevitable for a
programming language that is widely used for many different tasks and big
projects. It may start out simple, but as different user groups gets their
stuff in, the complexity comes in the language, compiler, runtime system,
libraries and/or user code. I don't know why CL isn't more popular, but
starting anew (arc, dylan) to simplify and change some superficial features
seems like a _lot_ of work and a good risk of ending up in the same spot
years later. Everything doesn't have to be elegant, as long as there is a
known approach/idiom for expressing it.
-- Ren�
In article <············@esmertec.com>, Ren� <······@stud.ntnu.no>
wrote:
> Bjarne Stroustrup often says that complexity is inevitable for a
> programming language that is widely used for many different tasks and big
> projects. It may start out simple, but as different user groups gets
> their
> stuff in, the complexity comes in the language, compiler, runtime system,
> libraries and/or user code.
And as you learn more and more that complexity should be moved out of
user code and into the compiler, runtime system, and libraries.
C++ does a lot of this, but not nearly as much as other languages.
> I don't know why CL isn't more popular, but
> starting anew (arc, dylan) to simplify and change some superficial
> features seems like a _lot_ of work and a good risk of ending up in
> the same spot years later.
That's not starting anew. It's building on top of what has been learned
without being restricted by the straitjacket of the installed base.
What is the growth path for Common Lisp? This community seems
incredibly resistant to change. Stroustrup isn't afraid to make changes
to C++ that are incompatable with existing code and require people to
make a few (usually fairly trivial) changes to previously working
programs. Neither are the Perl or Python people. Neither are Apple
with their OS APIs -- see the transition from the Classic MacOS API to
the Carbon API.
Is it possible for people to work for change -- *incompatable* change --
within Common Lisp, or are they forced to start a new language instead?
-- Bruce
From: Friedrich Dominicus
Subject: Re: True faiths ( was Re: The true faith )
Date:
Message-ID: <87r8omrcr0.fsf@frown.here>
Bruce Hoult <·····@hoult.org> writes:
>
> What is the growth path for Common Lisp? This community seems
> incredibly resistant to change. Stroustrup isn't afraid to make changes
> to C++ that are incompatable with existing code and require people to
> make a few (usually fairly trivial) changes to previously working
> programs.
This is not true. I suggest you recheck all his things he liked to
change but did not to not "break" something in existance. The problem
is IMHO that he tried to be C-compatible as much as he could if he
really would not have fear about change C++ would look quite different.
Regards
Friedrich
In article <··············@frown.here>, Friedrich Dominicus wrote:
>Bruce Hoult <·····@hoult.org> writes:
>
>>
>> What is the growth path for Common Lisp? This community seems
>> incredibly resistant to change. Stroustrup isn't afraid to make changes
>> to C++ that are incompatable with existing code and require people to
>> make a few (usually fairly trivial) changes to previously working
>> programs.
>This is not true. I suggest you recheck all his things he liked to
>change but did not to not "break" something in existance. The problem
>is IMHO that he tried to be C-compatible as much as he could if he
>really would not have fear about change C++ would look quite different.
C++ wantonly breaks C compatibility with some entirely unproductive
changes. For example, the class keyword declares types in exactly the
same way as struct, except that members without an access specifier
are private rather than public. That's a very poor reason to take an
identifier away from everyone for good.
In article <··············@frown.here>, Friedrich Dominicus
<·····@q-software-solutions.com> wrote:
> Bruce Hoult <·····@hoult.org> writes:
>
> >
> > What is the growth path for Common Lisp? This community seems
> > incredibly resistant to change. Stroustrup isn't afraid to make
> > changes
> > to C++ that are incompatable with existing code and require people to
> > make a few (usually fairly trivial) changes to previously working
> > programs.
> This is not true. I suggest you recheck all his things he liked to
> change but did not to not "break" something in existance. The problem
> is IMHO that he tried to be C-compatible as much as he could if he
> really would not have fear about change C++ would look quite different.
He worked pretty hard to stay compatible with C, but seemed to feel free
to change those things in C++ that weren't C compatible as he went along.
The scope of declarations introduced in loop control expressions is an
obvious example. And one that Microsoft *still* doesn't do properly,
ten years later.
I've been using C++ since 1989, so I've been through it all.
-- Bruce
Bruce Hoult <·····@hoult.org> writes:
>
> Stroustrup isn't afraid to make changes
> to C++ that are incompatable with existing code and require people to
> make a few (usually fairly trivial) changes to previously working
> programs.
And I used to curse him and his ilk roundly, in no uncertain language,
when I was doing C++. This was one of the major reasons.
> Neither are the Perl or Python people.
That's right. So it's impossible to do serious commercial work
with these languages. You think this is a plus?
> Is it possible for people to work for change -- *incompatable* change --
> within Common Lisp,
It's spelled *incompatIble*, thanks.
As for the answer to your question, Pierre Mai (or was it Duane Rettig?)
recently posted an excellent exposition of the costs of change vs stability.
Which incompatible change did you have in mind? How would the benefits of
that proposed change outweight the costs to the existing users?
I, personally, cannot think of a case in which the answer to your
question is "yes". What change did you have in mind?
> or are they forced to start a new language instead?
The question is: do you really think you will end up with something better
and cheaper, starting a whole new language, convincing companies to
spring up to implement it, getting it standardized, etc etc? At the
end of the day, it's all about money and time. I want to move on with
my life and get some useful programs written. Don't you?
--
It would be difficult to construe Larry Wall, in article
this as a feature. <·····················@netlabs.com>
In article <··············@gondolin.local.net>, Alain Picard
<·······@optushome.com.au> wrote:
> Bruce Hoult <·····@hoult.org> writes:
>
> >
> > Stroustrup isn't afraid to make changes
> > to C++ that are incompatable with existing code and require people to
> > make a few (usually fairly trivial) changes to previously working
> > programs.
>
> And I used to curse him and his ilk roundly, in no uncertain language,
> when I was doing C++. This was one of the major reasons.
Nevertheless, C++ is wildly sucessful.
> > Neither are the Perl or Python people.
>
> That's right. So it's impossible to do serious commercial work
> with these languages. You think this is a plus?
Serious commerical work is being done using these languages.
> > Is it possible for people to work for change -- *incompatable* change
> > within Common Lisp,
>
> It's spelled *incompatIble*, thanks.
>
> As for the answer to your question, Pierre Mai (or was it Duane Rettig?)
> recently posted an excellent exposition of the costs of change vs
> stability.
>
> Which incompatible change did you have in mind? How would the benefits
> of
> that proposed change outweight the costs to the existing users?
>
> I, personally, cannot think of a case in which the answer to your
> question is "yes". What change did you have in mind?
I'll take that as a "no, it's not possible".
> > or are they forced to start a new language instead?
>
> The question is: do you really think you will end up with something
> better and cheaper, starting a whole new language
Several groups appear to have thought so, yes, or at least that this was
the *easier* path, however hard it might be.
Sad if this is true, but it does appear to be the case.
-- Bruce
Bruce Hoult <·····@hoult.org> writes:
> In article <··············@gondolin.local.net>, Alain Picard
> <·······@optushome.com.au> wrote:
>
> > Bruce Hoult <·····@hoult.org> writes:
> >
> > >
> > > Stroustrup isn't afraid to make changes
> > > to C++ that are incompatable with existing code and require people to
> > > make a few (usually fairly trivial) changes to previously working
> > > programs.
> >
> > And I used to curse him and his ilk roundly, in no uncertain language,
> > when I was doing C++. This was one of the major reasons.
>
> Nevertheless, C++ is wildly sucessful.
For varying definitions of wildly. Dissatisfaction with C++ drove
many shops either back to C (the clearer thinkers), or forward to Java
(the optimistic kind), where they got more of the same (they are
probably slowly starting to jump ship, on to the next great thing).
> > Which incompatible change did you have in mind? How would the benefits
> > of
> > that proposed change outweight the costs to the existing users?
> >
> > I, personally, cannot think of a case in which the answer to your
> > question is "yes". What change did you have in mind?
>
> I'll take that as a "no, it's not possible".
No, it is a "unless you show clear problems with the existing
approach, we default to no". In case it has not been clear to you,
the base of CL is not an experimental playground, but a building
block. And building blocks only tend to be useful, if they don't
morph their shape all of the time.
Why has there been no change to the basics of CL in quite some time?
Because there have been no serious deficiencies in it. Simple as
that. At the current point in time, all serious deficiencies in CL
can be fixed outside/on top of the base language.
And, believe it or not, not every user of a programming language is in
this game for the "let's build the best (according to my idiosyncratic
personal definition) programming language around" sheer joy of
building new languages. Lot's of people are in it for the "give me an
adequate tool to create reliable software that creates lots of value"
part of it.
As an example, I'm certainly in the latter camp. In my professional
life, I'm currently responsible for a software suite that has to this
point generated several million EUR in value to its users. It is a
software suite that has, by leveraging the power of CL, made things
possible, that haven't been possible (for the given constraints in
cost and time) before, and it more or less created a new market for
itself.
In that capacity, what are my problems? Certainly not "CL doesn't
have ELEMENT", or "CL doesn't have sealing declarations", or even "not
everything is a STANDARD-CLASS", or any of that microscopic stuff
(especially since it is IMHO up to debate whether all of them are
really deficiencies).
Some of the problems are:
- Why has nobody created a good solution to the persistency needs of
simulation systems? OODBMS are not suited for large homogeneous
data-sets, RDBMS are not really well suited to hierarchical or
graph-like data-structures, none of them are really very good at
being embedded, and maintained automatically, etc.
- Why are there no really good embeddable software libraries for
graphical result presentation?
- Why is each SAP R/3 installation a semantic minefield of its own?
...
In other words: Had CL not been available, but Dylan had, then we
might have used Dylan (if there had been more than one commercial
vendor, that is), and I'd now be arguing against changing Dylan,
instead. What I care about in a language is "is it good enough to
write large, complex, reliable, maintainable and sufficiently
speedy systems (of the sort I'm interested in) in it", and "is it
based on a stable, well-written, well-accepted and implemented
standards document".
Compared to that, I couldn't care less about car vs. first, sealing by
default, sealing by choice, or no sealing at all.
> > > or are they forced to start a new language instead?
> >
> > The question is: do you really think you will end up with something
> > better and cheaper, starting a whole new language
>
> Several groups appear to have thought so, yes, or at least that this was
> the *easier* path, however hard it might be.
>
> Sad if this is true, but it does appear to be the case.
And lots of other groups went off to create their own little
languages, even when it was demonstrably true that they could have
extended CL completely within ANSI CL to create a semantically
equivalent language.
The reasons, I think, are clear: It is both more intellectual work to
enhance an existing base, than it is to simply start from scratch, and
it comes with more prestige.
In any case I think it is probably in everybody's interest that those
interested in constantly, and light-headedly tinkering with the base
language go off and create their own languages, than upset the
foundation of those interested in building upon programming languages
(either in order to tinker with new programming language features or
paradigms on top off CL, or to create new applications, or both).
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
From: Tim Bradshaw
Subject: Re: True faiths ( was Re: The true faith )
Date:
Message-ID: <ey3n0z8appc.fsf@cley.com>
* Bruce Hoult wrote:
> Nevertheless, C++ is wildly sucessful.
So is the common cold. It's more interesting to know whether the
programs written in C++ are wildly successful, or whether they are
disasters waiting to happen or in the process of happening. My guess
is one of the latter two, but there's basically no evidence for any
position because about the last thing any commercial organisation is
going to tell you is that their n-million line program is so much
scrap metal.
To answer the original question for myself: I'm not interested in
incompatible changes to CL. `A few (usually fairly trivial) changes'
add up to an awful lot of changes when multiplied up by a large number
of large programs, The cost of these changes is likely to be far
higher than the cost incurred by implementors in making compatible
changes, unless the language design is sufficiently broken. C++ is
probably an example of a language design which is sufficiently broken
of course.
--tim
In message <················@removeme.gst.com>
Bob Bane <····@removeme.gst.com> wrote:
> I was particularly impressed with his last paragraph in the second
> article. For some reason, he doesn't conclude that there's something
> wrong with C++. Can't imagine why...
>
> ---------BEGIN-QUOTE-----------
>
> I don't know about you, but there's something really scary to me about a
> language where copying state from one object to another is this
> complicated. By now, I suspect at least a dozen or two programmers have
> contributed something new to this discussion. If it takes this many
> programmers to write a simple assignment operator, think how complicated
> writing code that actually does something meaningful must be!
Despite this he's still (presumably) hiring C++ programmers!
In message <··············@corp.supernews.com> Kevin McFarlane wrote:
> Yes. This is true. BTW, have you read this? It supports your case.
>
> "Debunking the Myth of a Desperate Software Labor Shortage"
> http://heather.cs.ucdavis.edu/itaa.real.html
One of the claims in this document is
> [firms could] hire a generic programmer and let him/her learn the specific
> skills on the job, which any competent programmer can do within weeks.
> Refusing to hire a C-language programmer to write Java code is like a Ford
> dealer refusing to hire mechanics who have only Chevy experience, [...]
Ordinarily, I would agree, but looking at the assignment operator example I
have had second thoughts. I read the code and saw quickly why each line was
there and why it was necessary, but I'm sure I wouldn't have come up with
all of it myself! There is a simple solution, though; the coding standards
in the last project I worked on required that each class should have an
assignment operator and a copy constructor defined, but made private and
with no implementation.
I think I'll try to stick to languages with garbage collection.
Regards,
Simon Willcocks
From: Hyman Rosen
Subject: Re: True faiths ( was Re: The true faith )
Date:
Message-ID: <3C4D9B03.60803@mail.com>
Simon Willcocks wrote:
> I think I'll try to stick to languages with garbage collection.
But garbage collection has nothing to do with this problem!
The problem is handling an assignment when the type contains
bases and subobjects that must be copied, and doing such
copying could cause exceptions. You must arrange for the
copying to succeed, or else leave the destination object in
a consistent state, as well as propogate exceptions back to
the caller.
In article <··············@mail.com>, Hyman Rosen <·······@mail.com>
wrote:
> Simon Willcocks wrote:
>
> > I think I'll try to stick to languages with garbage collection.
>
>
> But garbage collection has nothing to do with this problem!
>
> The problem is handling an assignment when the type contains
> bases and subobjects that must be copied, and doing such
> copying could cause exceptions. You must arrange for the
> copying to succeed, or else leave the destination object in
> a consistent state, as well as propogate exceptions back to
> the caller.
Garbage collection has a *lot* to do with this problem!
A large proportion of assignments in languages such as C++ are done
merely in order to resolve the question of who owns an object and who is
responsible for eventually deleting it.
With GC available, objects are seldom copied with pointers to them being
passed around instead. You don't care who "owns" the object, because it
just magically goes away when all the pointers to it get forgotten.
-- Bruce
From: Hyman Rosen
Subject: Re: True faiths ( was Re: The true faith )
Date:
Message-ID: <3C4DE2F3.9020904@mail.com>
Bruce Hoult wrote:
> Garbage collection has a *lot* to do with this problem!
>
> A large proportion of assignments in languages such as C++ are done
> merely in order to resolve the question of who owns an object and who is
> responsible for eventually deleting it.
>
> With GC available, objects are seldom copied with pointers to them being
> passed around instead. You don't care who "owns" the object, because it
> just magically goes away when all the pointers to it get forgotten.
You don't get to redefine the problem so that your favorite technique
becomes the solution.
Hyman Rosen wrote:
>
> Bruce Hoult wrote:
>
> > Garbage collection has a *lot* to do with this problem!
> >
> > A large proportion of assignments in languages such as C++ are done
> > merely in order to resolve the question of who owns an object and who is
> > responsible for eventually deleting it.
> >
> > With GC available, objects are seldom copied with pointers to them being
> > passed around instead. You don't care who "owns" the object, because it
> > just magically goes away when all the pointers to it get forgotten.
>
> You don't get to redefine the problem so that your favorite technique
> becomes the solution.
GC does not redefine the problem, it eliminates it. Which was the point.
kenny
clinisys
From: Hyman Rosen
Subject: Re: True faiths ( was Re: The true faith )
Date:
Message-ID: <3C4F272B.6020209@mail.com>
Kenny Tilton wrote:
> Hyman Rosen wrote:
>>You don't get to redefine the problem so that your favorite technique
>>becomes the solution.
>
> GC does not redefine the problem, it eliminates it. Which was the point.
It does no such thing. The original problem specified an object with
two subobjects which were owned by the parent and with a non-empty
base object. You must write assignment for this type so that the
destination acquires its own private copies of the subobjects of the
source, and such that if copying any subcomponent fails (with an
exception) you leave the destination object undamaged.
You do *not* get to hand-wave away the requirement of copying the
subobjects. Say, for example, they represent a pair of buffers. After
the copy is made, the source object and the destination object are
independent - when one writes into its buffers, the other must not
see any change to its own.
From: Tim Bradshaw
Subject: Re: True faiths ( was Re: The true faith )
Date:
Message-ID: <ey34rlczowh.fsf@cley.com>
* Hyman Rosen wrote:
> It does no such thing. The original problem specified an object with
> two subobjects which were owned by the parent and with a non-empty
> base object. You must write assignment for this type so that the
> destination acquires its own private copies of the subobjects of the
> source, and such that if copying any subcomponent fails (with an
> exception) you leave the destination object undamaged.
Well, one thing here is a terminological issue - in many GCd languages
assignment would not make a copy, so assignment and copying are
conceptually different operations.
But what GC does solve is not the copying problem - which, in Lisp at
least (together with the related equality problem), is regarded as an
issue which does not have a general solution nor any hope of one: Lisp
people at least do not regard copying as trivial - but the problem of
needing to copy to resolve low-level ownership issues. If you have to
manually manage memory then it's crucial that only one person frees
the memory associated with some object, and one (bad) way of resolving
this is, if you need two handles on something, to actually make a
copy, so each copy can then be independently freed. In a GCd language
this is a non-problem since the reuse of memory is dealt with by the
GC, so you can happily pass around a reference to the thing instead.
--tim
Hyman Rosen wrote:
>
> Kenny Tilton wrote:
> > Hyman Rosen wrote:
> >>You don't get to redefine the problem so that your favorite technique
> >>becomes the solution.
> >
> > GC does not redefine the problem, it eliminates it. Which was the point.
>
> It does no such thing. The original problem specified an object with
> two subobjects which were owned by the parent and with a non-empty
> base object. You must write assignment for this type so that the
> destination acquires its own private copies of the subobjects of the
> source, and such that if copying any subcomponent fails (with an
> exception) you leave the destination object undamaged.
>
> You do *not* get to hand-wave away the requirement of copying the
> subobjects. Say, for example, they represent a pair of buffers. After
> the copy is made, the source object and the destination object are
> independent - when one writes into its buffers, the other must not
> see any change to its own.
Perhaps I misunderstood. The problem of /copying/ a structure is
clear--how deep is something only the application can decide. Fine. Now
what is all this about assignment having to worry about copying?
The story I saw seemed to think you needed both a copy and assignment
method in C++, and that the assignment method also had to worry about
what to copy (and blowing up during a copy).
Why confuse the two? I just pass pointers (if you will) around.
assignment is always by reference. Automatic GC gets to clean up after
me. Life is good. When I /copy/ a structure...well, I'll have to get
back to you if it ever comes up.
:)
kenny
clinisys
From: Hyman Rosen
Subject: Re: True faiths ( was Re: The true faith )
Date:
Message-ID: <3C4FC2FF.7000103@mail.com>
Kenny Tilton wrote:
> Perhaps I misunderstood. The problem of /copying/ a structure is
> clear--how deep is something only the application can decide. Fine. Now
> what is all this about assignment having to worry about copying?
It was in the problem spec. Anyway, the (now) canonical way to do this
ib C++, thanks to Herb Sutter's "Exceptional C++", is to make objects
have a non-throwing swap() method, and base assignment on copying:
struct s
{
void swap(s &other) throw(); // non-throwing swap
s(const s &other); // copy constructor
s &operator=(const s &other)
{
s(other).swap(*this);
return *this;
}
};
> The story I saw seemed to think you needed both a copy and assignment
> method in C++, and that the assignment method also had to worry about
> what to copy (and blowing up during a copy).
Assignment exists in C++ not least because it exists in C. Like Ada, the
default is to do a memberwise copy. If you choose to allow assignment in
your class, you have to get it right.
> Why confuse the two? I just pass pointers (if you will) around.
> assignment is always by reference. Automatic GC gets to clean up after
> me. Life is good. When I /copy/ a structure...well, I'll have to get
> back to you if it ever comes up.
From: Ray Blaak
Subject: Canconical C++ assignment (was Re: True faiths ...)
Date:
Message-ID: <ubsfj1ymp.fsf_-_@telus.net>
Hyman Rosen <·······@mail.com> writes:
> It was in the problem spec. Anyway, the (now) canonical way to do this
> ib C++, thanks to Herb Sutter's "Exceptional C++", is to make objects
> have a non-throwing swap() method, and base assignment on copying:
>
> struct s
> {
> void swap(s &other) throw(); // non-throwing swap
> s(const s &other); // copy constructor
> s &operator=(const s &other)
> {
> s(other).swap(*this);
> return *this;
> }
> };
Interesting. Is a discussion of the tradeoffs of this approach online
anywhere? I note an original presentation at http://www.gotw.ca/gotw/059.htm.
My only criticism with this approach is that one now has two places to
maintain a detailed field-by-field knowledge of the class: in the copy
constructor and in swap().
For maintenance reasons, I prefer this kind of approach, although there are
downsides with exception handling and dealing with virtual vs non-virtual
assignment operators:
class C
{
public:
C(const C &other)
{
*this = other;
}
C &operator=(const C &other)
{
if (this != &other)
{ // field by field assignment/cleanup, perhaps to temp vars first
// to allow intelligent exception processing.
}
return *this;
}
};
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
·····@telus.net The Rhythm has my soul.
In article <················@mail.com>, Hyman Rosen <·······@mail.com>
wrote:
> Bruce Hoult wrote:
>
> > Garbage collection has a *lot* to do with this problem!
> >
> > A large proportion of assignments in languages such as C++ are done
> > merely in order to resolve the question of who owns an object and who
> > is
> > responsible for eventually deleting it.
> >
> > With GC available, objects are seldom copied with pointers to them
> > being
> > passed around instead. You don't care who "owns" the object, because
> > it
> > just magically goes away when all the pointers to it get forgotten.
>
>
> You don't get to redefine the problem so that your favorite technique
> becomes the solution.
Yes you do. The aim is to solve the customer's problem. They don't
give a damn whether you copy objects or pass them by reference. They
don't even know what the options *mean*!
-- programs are hard to analyse for correctness because of GOTOs.
Solution: don't use them
-- programs are hard to analyse for correctness because of destructive
assignment. Solution: don't use assignment.
-- programs are often buggy because of off-by-one errors in loop
control. Solution: use implicit loops and/or mapping functions
controlled by the size of the collection they are operating on.
-- programs are often buggy because of errors in memory management.
Solution: automate memory management.
Bruce Hoult wrote:
> In article <················@mail.com>, Hyman Rosen <·······@mail.com>
> wrote:
> > You don't get to redefine the problem so that your favorite technique
> > becomes the solution.
>
> Yes you do. The aim is to solve the customer's problem. They don't
> give a damn whether you copy objects or pass them by reference. They
> don't even know what the options *mean*!
It depends on what you mean by customer. A customer of a class/type
declaration is usually another programmer. I am a member of that
class of customers, and I do care and I do know what the options mean.
One of the things I like about Eiffel is the careful attention given to the
design of the class contract. I want to know, from that contract, what
to expect of my engaging it. For example, what kinds of things can go
wrong, what are my responsibilities as a user of the contract, and what
performance considerations I might want to consider in choosing a
particular contract. And, yes, I want to know if it includes some form
of storage management, and have some idea of what that storage
management feature will have on my own program.
The next few observations remind me of something I once heard regarding
programming rules. "Those who make up rules about programming tend
to be people who no longer write production programs."
> -- programs are hard to analyse for correctness because of GOTOs.
> Solution: don't use them
Generally true. Knuth has a lengthy article on this in his book, Literate
Programming. To simply say, "Don't use go to, is a bit simplistic." I
have seen perfectly good examples where, during fine tuning of a program,
someone has achieved significant performance improvement with a go to.
Some languages support goto-less programming better than others. Some
eliminate the option altogether and also eliminate the benefits of it. Go
to
is an option that should be used sparingly, almost never, but is handy when
you actually need it. I realize one can "prove" that it is never needed.
So
be it. Sometimes it just might be useful.
> -- programs are hard to analyse for correctness because of destructive
> assignment. Solution: don't use assignment.
I understand this is a joke. However, it conforms nicely to some of the
fundamental notions of functional programming.
> -- programs are often buggy because of off-by-one errors in loop
> control. Solution: use implicit loops and/or mapping functions
> controlled by the size of the collection they are operating on.
Well, in Ada this never seems to be a problem. In Eiffel it is never
a problem. It is often a problem in programs that use the C family
of languages. However, I think C# has a fix for this.
> -- programs are often buggy because of errors in memory management.
> Solution: automate memory management.
A naive suggestion, at best. Which automated form of memory management
will you suggest? There are many from which one can choose. Each has
its own benefits, depending on the kind of software you are writing. This
is
one of the things C++ gets right. Ada also. The problem of automated
memory management is one of the things that makes Java ill-suited to
many kinds of embedded, real-time software applications. Jim Rogers
makes a good point about this vis a vis Ada. In Ada, we have the option
of selecting the memory management model we wish to use, letting it be
automatic or not, and targeting each type to a different model of memory
management when that is a appropriate. This is a level of flexibility
not typical of most other languages. Yes, I know one can do this in C++,
but expressibile and expressive are not the same thing. Ada is really
expressive in allowing this kind of automated memory management for
a given type. That is as it should be since Ada is intended for safety-
critical, real-time embedded software systems.
Richard Riehle
Bruce Hoult wrote:
> Garbage collection has a *lot* to do with this problem!
>
> A large proportion of assignments in languages such as C++ are done
> merely in order to resolve the question of who owns an object and who is
> responsible for eventually deleting it.
>
> With GC available, objects are seldom copied with pointers to them being
> passed around instead. You don't care who "owns" the object, because it
> just magically goes away when all the pointers to it get forgotten.
Copying pointers and using GC or even reference counting is a very
nice solution for single threaded applications. It becomes a very
messy solution for multi-threaded applications. Now all those
copied pointers need to be protected from inappropriate simultaneous
access by several threads.
In threaded applications GC solves no concurrency issues, but it
does complicate them. How can a semaphore be "held" by only one
thread if only one instance exists, and all threads hold a
pointer to that instance? How can you keep one thread from
consuming all the free store or "heap"?
Obviously there are answers to all those questions.
Unfortunately, those answers a generally pretty messy unless
someone has designed your GC solution with concurrency in mind.
Jim Rogers
Colorado Springs, Colorado USA
In article <················@worldnet.att.net>, Jim Rogers wrote:
>Bruce Hoult wrote:
>
>> Garbage collection has a *lot* to do with this problem!
>>
>> A large proportion of assignments in languages such as C++ are done
>> merely in order to resolve the question of who owns an object and who is
>> responsible for eventually deleting it.
>>
>> With GC available, objects are seldom copied with pointers to them being
>> passed around instead. You don't care who "owns" the object, because it
>> just magically goes away when all the pointers to it get forgotten.
>
>Copying pointers and using GC or even reference counting is a very
>nice solution for single threaded applications. It becomes a very
>messy solution for multi-threaded applications. Now all those
>copied pointers need to be protected from inappropriate simultaneous
>access by several threads.
By definition, something that is copied isn't shared, and so doesn't
have to be protected. What it points to is shared, so that's a different
matter.
Making copies of every object is not a realistic solution in multithreaded
programs, no matter what language they are written in. You can do it
sometimes, but not always.
If you must share references to objects, GC is far cleaner and safer
than reference counting techniques. It will automatically ensure that no
thread will delete an object while it is still in use by another thread.
>In threaded applications GC solves no concurrency issues, but it
>does complicate them. How can a semaphore be "held" by only one
>thread if only one instance exists, and all threads hold a
>pointer to that instance?
How can a semaphore be useful unless there is one shared instance
of it? Do you know the first thing about threading? Doh!
>How can you keep one thread from
>consuming all the free store or "heap"?
This is a problem regardless of your memory management strategy, if you
admit dynamic storage allocation. If you insist on making copies for
the sake of avoiding sharing, you will only make this concern worse.
Garbage collection eliminates memory leaks, thus lessening the
concern.
>Obviously there are answers to all those questions.
>Unfortunately, those answers a generally pretty messy unless
>someone has designed your GC solution with concurrency in mind.
Do you know what GC is? It simply means computing what objects are unreachable
and liberating their storage for future allocations.
It has nothing to do with the semantics of those objects while they
are still live. Garbage collected or not, shared objects have to be
protected from concurrent access.
Of course a garbage collector has to be correctly implemented to be used
in a multithreaded environment. However, it remains easy to use; the
user simply remains unconcerned about what happens to unreachable
objects.
Kaz Kylheku wrote:
> In article <················@worldnet.att.net>, Jim Rogers wrote:
>
>>Bruce Hoult wrote:
>>
>>
>>>Garbage collection has a *lot* to do with this problem!
>>>
>>>A large proportion of assignments in languages such as C++ are done
>>>merely in order to resolve the question of who owns an object and who is
>>>responsible for eventually deleting it.
>>>
>>>With GC available, objects are seldom copied with pointers to them being
>>>passed around instead. You don't care who "owns" the object, because it
>>>just magically goes away when all the pointers to it get forgotten.
>>>
>>Copying pointers and using GC or even reference counting is a very
>>nice solution for single threaded applications. It becomes a very
>>messy solution for multi-threaded applications. Now all those
>>copied pointers need to be protected from inappropriate simultaneous
>>access by several threads.
>>
>
> By definition, something that is copied isn't shared, and so doesn't
> have to be protected. What it points to is shared, so that's a different
> matter.
>
> Making copies of every object is not a realistic solution in multithreaded
> programs, no matter what language they are written in. You can do it
> sometimes, but not always.
>
> If you must share references to objects, GC is far cleaner and safer
> than reference counting techniques. It will automatically ensure that no
> thread will delete an object while it is still in use by another thread.
>
>
>>In threaded applications GC solves no concurrency issues, but it
>>does complicate them. How can a semaphore be "held" by only one
>>thread if only one instance exists, and all threads hold a
>>pointer to that instance?
>>
>
> How can a semaphore be useful unless there is one shared instance
> of it? Do you know the first thing about threading? Doh!
>
Of course Doh! I was thinking about the concept of many handles
to the same object, without the object state itself identifying
the "owner".
>
>>How can you keep one thread from
>>consuming all the free store or "heap"?
>>
>
> This is a problem regardless of your memory management strategy, if you
> admit dynamic storage allocation. If you insist on making copies for
> the sake of avoiding sharing, you will only make this concern worse.
> Garbage collection eliminates memory leaks, thus lessening the
> concern.
>
Aha. There are solutions to this problem, with or without GC.
The solution is to provide a separate storage pool for each
thread. That storage pool could then be managed manually or by
GC. With this design, one thread consuming its storage pool would
not interfere with the storage usage of other threads.
If you do use GC you will need some way of partitioning the
GC work among the storage pools. This could be done in a single
GC, or by implementing many GC's.
>
>>Obviously there are answers to all those questions.
>>Unfortunately, those answers a generally pretty messy unless
>>someone has designed your GC solution with concurrency in mind.
>>
>
> Do you know what GC is? It simply means computing what objects are unreachable
> and liberating their storage for future allocations.
>
Yes, I know this. It appears to me that computing unreachability
across a multi-processor system is much more difficult than with
the simpler memory model of a uni-processor system. Am I wrong?
> It has nothing to do with the semantics of those objects while they
> are still live. Garbage collected or not, shared objects have to be
> protected from concurrent access.
Yes, and that concurrent sharing complicates the reachability
algorithm.
While operations on general shared memory objects do not need
to be, and indeed often cannot be, atomic, operations on
semaphores must be atomic. This includes reachability
calculations. It would seem that an object that is unreachable
must remain unreachable. In general this is true. With out of order
instruction execution in some multi-processor systems this cannot
be guaranteed.
>
> Of course a garbage collector has to be correctly implemented to be used
> in a multithreaded environment. However, it remains easy to use; the
> user simply remains unconcerned about what happens to unreachable
> objects.
>
Certainly, a GC properly implemented for a multithreaded environment
should be just as easy to use as one implemented in a single threaded
environment. This does, however, argue for a language providing GC
to also implement a threading model as part of the language standard.
Mixing a threaded implementation with a GC designed only for single
threaded applications could lead to very disappointing results.
Jim Rogers
Colorado Springs, Colorado USA
Jim Rogers <················@worldnet.att.net> wrote in message news:<················@worldnet.att.net>...
[...]
> Copying pointers and using GC or even reference counting is a very
> nice solution for single threaded applications. It becomes a very
> messy solution for multi-threaded applications. Now all those
> copied pointers need to be protected from inappropriate simultaneous
> access by several threads.
>
LOL! Jim, this sounds like an excellent example of a problem where
it's important to distinguish between deep and shallow copy operators,
which has been a large part of the debate in this thread in the first
place...
Greg
> Bruce Hoult wrote:
>
> > Garbage collection has a *lot* to do with this problem!
> >
> > A large proportion of assignments in languages such as C++ are done
> > merely in order to resolve the question of who owns an object and who is
> > responsible for eventually deleting it.
> >
> > With GC available, objects are seldom copied with pointers to them being
> > passed around instead. You don't care who "owns" the object, because it
> > just magically goes away when all the pointers to it get forgotten.
This doesn't seem to be a question of something "going away", it's a
question
of how the object(s) behave while they are still in use. For example:
Suppose you have a process A which has something (an object or whatever)
called X it wants to pass to a process B. The process B must be free to do
whatever it wants to/with that X thing. However, the process A also wants to
keep going with the X after the B is done with whatever it was doing (and I
won't even mention the case where it wants to do it *while* the B is at it).
This sort of thing can be very useful in a roll-back situations, or when
some
duplicates are in fact completely independent in their handling but just
happen
to come from the same source etc. Pointers/references are totally useless in
such cases, you do need a separate copy and, if the language doesn't provide
it, you are reduced to hand-coding it yourself. With all the pitfalls that
it may
entail.
If my vague recollection of the vintage Pascal is correct, it did have a
specific
distinction between P^ := Q^; and P := Q; Which was, of course, the
difference
between the shallow and [one-level]deep copy. Now, just where does a GC
come to play in this difference? Mind you, that vintage Pascal could have or
not
the GC implemented - the semantics would be exactly the same.
The same applies to your argument above - it doesn't really matter what
happens
to the storage after it's out of use. The question is/was how do you
implement the
semantics while it's still around.
From: David Combs
Subject: Re: True faiths ( was Re: The true faith )
Date:
Message-ID: <a47r79$jf$1@news.panix.com>
In article <····················@news.xtra.co.nz>,
AG <······@nowhere.co.nz> wrote:
>> Bruce Hoult wrote:
>>
>> > Garbage collection has a *lot* to do with this problem!
>> >
>> > A large proportion of assignments in languages such as C++ are done
>> > merely in order to resolve the question of who owns an object and who is
>> > responsible for eventually deleting it.
>> >
>> > With GC available, objects are seldom copied with pointers to them being
>> > passed around instead. You don't care who "owns" the object, because it
>> > just magically goes away when all the pointers to it get forgotten.
>
>This doesn't seem to be a question of something "going away", it's a
>question
>of how the object(s) behave while they are still in use. For example:
>
>Suppose you have a process A which has something (an object or whatever)
>called X it wants to pass to a process B. The process B must be free to do
>whatever it wants to/with that X thing. However, the process A also wants to
>keep going with the X after the B is done with whatever it was doing
Coroutines (across processes) help here? You do have to
know (not just when?) but *where*, in the source, you want
to "resume" the other one. Not at all "automatic".
How *does* one nicely-handle such a situation? "Automatically"?
How about this one (maybe simple, obvious, for you guys,
but not for me):
You're writing a program in a language that has gc,
eg lisp (or Mainsail, the language I use -- derived
from (ancient) SAIL (Stanford's Algol-like syntaxed competitor to
lisp as ai language -- lost, of course),
and from one or more places in the program written
in the language-with-gc, you want to call out to
something written in a *different* language,
which also has a *different* memory-mngt scheme --
maybe gc, maybe not.
And you want to pass a ref to a data structure
owned by the first progtam into the second program.
So far, simple enough. The with-gc language
is stopped between the call into the other-languaged
program and the return back in.
No problem with a gc occurring *while* the 2nd program
is playing with the (shared) data structure.
HOWEVER -- suppose that that called 2nd-program needs
to call a function back in the 1st program.
NOW we DO have a problem: that call back into the
first program, the one with memory-mngt via gc,
just might eat up enough pieces of newly allocated
memory that it triggers a gc!
Thus pulling the rug out from under the 2nd program --
since its reference back into the first program's
data structure will be pointing to garbage, if
the "shared" data structure gets slid somewhere
else by the gc.
QUESTION: what kind of solutions are there to
this problem?
(The one I've been using is to turn off the
gc during the first call out, and re-activating
it when that first call returns -- the hope
being that the 2nd call back in doesn't run
out of memory! (Actually, we make it do
a preemptive gc before we freeze everything.)
So far, so good....)
What are some more, er, robust approaches?
Thanks!
David
From: Ray Blaak
Subject: Re: True faiths ( was Re: The true faith )
Date:
Message-ID: <ud6zb52ne.fsf@telus.net>
·······@panix.com (David Combs) writes:
> [...] from one or more places in the program written in the
> language-with-gc, you want to call out to something written in a *different*
> language, which also has a *different* memory-mngt scheme -- maybe gc, maybe
> not.
[...]
> And you want to pass a ref to a data structure
> owned by the first progtam into the second program.
[...and what happens if this shared data is collected while still in use in
the second program?]
You need support from the gc-language to "lock" objects to that the gc will
not collect them.
That is, you need a way of marking objects as being under manual memory
management.
Many gc-languages provide such hooks. The Java Native Interface, for example,
allows the programmer to add/remove references to Java objects from outside
Java, so as to control whether or not they are gc'd.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
·····@telus.net The Rhythm has my soul.
In article <···········@news.panix.com>, David Combs wrote:
>In article <····················@news.xtra.co.nz>,
>AG <······@nowhere.co.nz> wrote:
>>> Bruce Hoult wrote:
>>>
>>> > Garbage collection has a *lot* to do with this problem!
>>> >
>>> > A large proportion of assignments in languages such as C++ are done
>>> > merely in order to resolve the question of who owns an object and who is
>>> > responsible for eventually deleting it.
>>> >
>>> > With GC available, objects are seldom copied with pointers to them being
>>> > passed around instead. You don't care who "owns" the object, because it
>>> > just magically goes away when all the pointers to it get forgotten.
>>
>>This doesn't seem to be a question of something "going away", it's a
>>question
>>of how the object(s) behave while they are still in use. For example:
>>
>>Suppose you have a process A which has something (an object or whatever)
>>called X it wants to pass to a process B. The process B must be free to do
>>whatever it wants to/with that X thing. However, the process A also wants to
>>keep going with the X after the B is done with whatever it was doing
>
>Coroutines (across processes) help here? You do have to
>know (not just when?) but *where*, in the source, you want
>to "resume" the other one. Not at all "automatic".
Not really, because A and B want to use the object in parallel. Coroutines
make the synchronization problem go away, because coroutine A is suspended
when coroutine B is running and vice versa. The passing of control
is explicit. With processes you don't have this, except maybe with
non-preemptive (cooperative) threads.
The solutions are to copy the object upfront, or to do some lazy copying:
copy on write. This is what happens with the memory pages of a process
on a moderm Unix system when you do fork(). Otherwise if B destructively
manpulates an object that A is also using, you have an instant race
condition.
Of course, there is the possibility of making a thread-aware object which
can be shared in some disciplined way.
>NOW we DO have a problem: that call back into the
>first program, the one with memory-mngt via gc,
>just might eat up enough pieces of newly allocated
>memory that it triggers a gc!
>
>Thus pulling the rug out from under the 2nd program --
>since its reference back into the first program's
>data structure will be pointing to garbage, if
>the "shared" data structure gets slid somewhere
>else by the gc.
Firstly, you may be confusing GC with compacting-GC. It's not a
necessity for garbage collection to actually move data around to
eliminate fragmentation. The primary job of garbage collection is to
hunt down unreachable memory and liberate it. If the GC in question is
non-compacting, you have nothing to worry about, (so long as the non-GC
domain isn't the only one with remaining references to the object, so
that it looks unreferenced in the GC domain).
If objects *can* be moved by the collector, what you can do is implement
the ability to lock some objects to prevent them from moving. Any objects
that are passed into the non-GC domain are locked, and then their
previous lock status is restored upon returning.
Making copies of objects into the non-GC domain, which have to be
liberated there, is also not out of the question. In the reverse
direction, any object created in the non-GC domain that you want to brring
into the GC domain will almost certainly have to be reallocated into
GC storage. The non-GC domain can be equipped with a special function
for allocating GC storage for objects in preparation for passing them
the GC domain, so the copy operation doesn't have to take place.
Since the non-GC domain is probably written in some stone age language
with manual memory allocation, its programmers won't mind learning some
special way of allocating memory. :)
>QUESTION: what kind of solutions are there to
>this problem?
>
>(The one I've been using is to turn off the
>gc during the first call out, and re-activating
>it when that first call returns -- the hope
>being that the 2nd call back in doesn't run
>out of memory! (Actually, we make it do
>a preemptive gc before we freeze everything.)
This is equivalent to locking down everything, which is simpler, but
unnecessary.
·······@panix.com (David Combs) wrote in message news:<···········@news.panix.com>...
>
> QUESTION: what kind of solutions are there to
> this problem?
>
> What are some more, er, robust approaches?
>
> Thanks!
>
> David
Try a different language.
The Cincom Smalltalk implementation allows access to C calls (which,
of course, will get you to C++ if you're careful). The function must
reside in a shared library that loads into the Smalltalk address space
and can access -- through controls -- object memory. Object memory
runs under the GC; accessing an object from C "locks" it so it
doesn't get collected or moved on you. Dynamic memory allocation from
C (or C++) uses the standard malloc() calls. I know that some
Smalltalk implementations (such as GNU) actually have a private
version of the malloc routines (same semantics) to control memory
zones.
The interface is rather flexible, supporting semantics to create
objects that look like C structures internally and are converted to
native C structures on function invocation. The invocation will even
permit spawning the function as a thread, but there are more
restrictions placed on those.
The calling mechanism uses C's pass-by-value semantics. But since you
can pass object references (OOPs), you have access to everything else
as well. There is some support for semaphores, but I think it's
rather limited. Thunking, or a reverse call from C to Smalltalk, is
possible using Smalltalk blocks, but I do not know how this is
handled.
-- Tom
In comp.lang.ada Bruce Hoult <·····@hoult.org> wrote:
: A large proportion [...ownership/deleting]
^^^^^
: With GC available, objects are seldom copied
^^^^^^
Yes, but what does frequency of an operation say about the importance
of the availability of the respective copying operation?
When an object has to be backed up (transaction, retransmission,
adventurous options of changing its state with backtracking,
recursively splitting processing to different processors/memories,
saving to files, ...), another pointer to serve the manipulation
is essentially useless, and GC or not GC is simply not the point.
For a concrete language example, why are there expanded objects in
Eiffel? And how does this relate to GC, and multitasking?
(I'm asking myself these questions to get a clear picture,
they are not merly rhetorical.)
Georg
In article <················@removeme.gst.com>, Bob Bane
<····@removeme.gst.com> wrote:
> I was particularly impressed with his last paragraph in the second
> article. For some reason, he doesn't conclude that there's something
> wrong with C++. Can't imagine why...
>
> ---------BEGIN-QUOTE-----------
>
> I don't know about you, but there's something really scary to me about a
> language where copying state from one object to another is this
> complicated. By now, I suspect at least a dozen or two programmers have
> contributed something new to this discussion. If it takes this many
> programmers to write a simple assignment operator, think how complicated
> writing code that actually does something meaningful must be!
And the really really scary thing is that I know C++ well enough to know
why I need an assignment operator, and know how to write it correctly
off the top of my head (and with the inherited:: call inside the
try{}!). Most C++ places that I've worked I'm the *only* person who
would get this right.
And yet, when I tell them that their development would be better done
using Dylan or one of the languages in the "Newsgroups:" line they think
I'm crazy.
-- Bruce
In article <···························@news.paradise.net.nz>, Bruce
Hoult wrote:
>And the really really scary thing is that I know C++ well enough to know
>why I need an assignment operator, and know how to write it correctly
>off the top of my head (and with the inherited:: call inside the
>try{}!). Most C++ places that I've worked I'm the *only* person who
>would get this right.
Most C++ programmers I have come across know only an imaginary, simplified
dialect of C++ that they have assembled from various incorrect sources,
and compiler-specific reference. It is my experience that attitudes
toward standards and language specifications in general tend to be very
poor among C++ users.
There is a lot of literature written by idiots and for idiots, purportedly
about C++, but really about a simplified dialect having little to do with
C++. The literature about languages which are not hyped up tends to be of
a much higher quality. The result is that if you typical C++ programmer
comes across a textbook about some programming language (like say one of
the ones in the Newsgroups: line) that language seems incredibly difficult
compared to the simplified language that he misunderstands C++ to be.
He doesn't understand that half of his code is not even portable to
the compiler he developed it with, but works only by fluke, and that if
he were to get it right, he would have to work in a much more complex
programming language, namely the real C++.
In article <···························@news.paradise.net.nz>,
Bruce Hoult wrote:
> In article <················@removeme.gst.com>, Bob Bane
> <····@removeme.gst.com> wrote:
>
>> I was particularly impressed with his last paragraph in the second
>> article. For some reason, he doesn't conclude that there's something
>> wrong with C++. Can't imagine why...
>>
>> ---------BEGIN-QUOTE-----------
>>
>> I don't know about you, but there's something really scary to me about a
>> language where copying state from one object to another is this
>> complicated. By now, I suspect at least a dozen or two programmers have
>> contributed something new to this discussion. If it takes this many
>> programmers to write a simple assignment operator, think how complicated
>> writing code that actually does something meaningful must be!
>
>
> And the really really scary thing is that I know C++ well enough to know
> why I need an assignment operator, and know how to write it correctly
> off the top of my head (and with the inherited:: call inside the
> try{}!). Most C++ places that I've worked I'm the *only* person who
> would get this right.
>
> And yet, when I tell them that their development would be better done
> using Dylan or one of the languages in the "Newsgroups:" line they think
> I'm crazy.
>
> -- Bruce
From their POV you are crazy, most places want to hire, for lack of a
better term, cogs. People who do there job, go home, fear management
and are easy to push around by management. I feel the reason for this
is that management knows that they CAN replace one average(or sub
average) programmer with another as long as you pick commodity people
and are using commodity languages. The problem with very good or even
worse great programmers is that you need to find more people like that
to replace them, they do not fear management and are generally are
"trouble makers", they have opinions that differ from management
about what to do and/or how to do it with facts to back them up.
marc
Marc Spitzer wrote:
> The problem with very good or even
> worse great programmers is that you need to find more people like that
> to replace them, they do not fear management and are generally are
> "trouble makers", they have opinions that differ from management
> about what to do and/or how to do it with facts to back them up.
>
> marc
>
Yes, and they also have this annoying habit of coming through with "home
runs" for the company when conventional wisdom says their approach is wrong.
- Ed
>
> Marc Spitzer wrote:
>
> > The problem with very good or even
> > worse great programmers is that you need to find more people like that
> > to replace them,
no, you only think you do. then your average programmer looks at the
code for a week and before you can set up the first interview ms/mr
average says "looks pretty straightforward to me, i can maintain this."
otoh, if mr/ms average gives up on the mess, the dearly departed most
assuredly was not great nor even very good.
early on in my career i heard a line that puzzled me until i saw OPC:
"if you have an indispensible programmer, fire them."
kenny
clinisys
Kenny Tilton <·······@nyc.rr.com> writes:
> no, you only think you do. then your average programmer looks at the
> code for a week and before you can set up the first interview ms/mr
> average says "looks pretty straightforward to me, i can maintain this."
>
> otoh, if mr/ms average gives up on the mess, the dearly departed most
> assuredly was not great nor even very good.
Hmm, for the slightly-below-average programmer, though, often they'll
*think* they can maintain something, but in doing so will fuck up all
over the place, break perfectly nice algorithms, change things to
ineffecient algorithms, etc., not because they *couldn't* have
followed the nicely-documented, cleverly written code, but because
they figured it would be easier to do things the "normal" way whenever
they had to change a part of a program. Things can stepwise decline
into a mess in the hands of people who want everything to be done the
"normal" way. The problem is that most programs are a mess, so
changing things to work the way everything else does is likely to make
it worse, if it was above-average to start with.
> early on in my career i heard a line that puzzled me until i saw OPC:
> "if you have an indispensible programmer, fire them."
I understand what this is supposed to mean, but what about the very
well-read, educated programmer who knows (or knows how to find) better
ways of doing lots of things than the normal, naive method/algorithm?
Such a programmer can be indiscpensible for things that can't be done
in the naive way (for efficiency or complexity reasons, or whatever).
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Bruce Hoult wrote:
>
> And the really really scary thing is that I know C++ well enough to know
> why I need an assignment operator, and know how to write it correctly
> off the top of my head (and with the inherited:: call inside the
> try{}!). Most C++ places that I've worked I'm the *only* person who
> would get this right.
>
> And yet, when I tell them that their development would be better done
> using Dylan or one of the languages in the "Newsgroups:" line they think
> I'm crazy.
>
> -- Bruce
Was reading this thread, this message, simultaneously talking on IRC.
Let me reproduce part of one conversation:
<dAS-> it sucks.. I'm still depressed over lisp
<dAS-> like wtf..
<dAS-> if I can't get a job with it.. I see little reason to spend all my
time on it..
<dAS-> I love it..
<dAS-> but really..
<dAS-> and why do all lisp companies only request *LISP GURUS*
<dAS-> like wtf is up with that
I guess this can be applied to any non-mainstream language.
Immanuel Litzroth <·········@enfocus.be> wrote in message news:<··············@enfocus.be>...
>
> In this respect the articles...
>
> Immanuel
I read through both of these articles. I have also read through all
of the responses to this subthread. I am not a C++ expert, but I have
a background in computer languages. I would not have gotten a
"perfect" solution, but the problems associated with "owning" pointers
were obvious, and really should be so to anyone with a basic OO
background, which I guess eliminates most of the C++ programmers. ;-)
My solution did not include transactions (the try/catch stuff),
because I would have assumed a failure to be catastrophic (an
oversight of the stated problem requirements). Unwise, perhaps...
But all that aside, I am surprised that everyone seems to have missed
an underlying concept. Most of this thread goes into all the funny
semantics of assigning, copying, and garbage collection behavior,
while overlooking the simplest fact of all: the hassles come about
because you're dealing with a strongly typed language! (Ada's limited
private types only make the contract cleaner to visualize, they don't
overcome the associated problems. And don't get me started on the
supposed advantages of strong vs. weak/dynamic typing.)
GCed languages usually eliminate the problem of "assignment" because
there is no such feature: they do dynamic typing/dynamic binding,
replacing references (virtual pointers) to objects rather than the
contents. You have to write special methods to implement assignment,
and I have found only a handful of cases where that is desirable, let
alone necessary, and after years of thought I'm not certain about
those. In such cases I've used "copy_from", where the argument is the
source whose state is copied into the receiver. (Destructors for
releasing system resources are usually invoked manually or can be
through GC finalization mechanisms, which automate the necessary
cleanup even in cases that would otherwise be memory leaks.)
Now, all of the things said about "owned" versus "aliased" references
must be taken into account. In my experience a dynamically typed
language will never have a slicing problem. But ownership of
contained objects must still be managed. Where the language doesn't
support assignment per se, then implicitly this means "owned" objects
must be copied (that is, cloned) in the usual way for the language
when assignment is implemented, which is what you'd expect.
Which leads to the discussion of copy semantics. Either the language
or the type must define the semantics of what "copy" means. It
certainly is easier when the language specifies a default
interpretation. But there are valid reasons for having shared_copy
(which does NOT do ownership copies), shallow_copy (which copies or
clears contained objects not meant to be shared, such as a dictionary
cache), and deep_copy, which copies everything and its brother,
sister, cousin, and aunt. Some data structures cannot wisely
implement deep copies without some smarts to prevent infinite
replication, such as duplicating graph structures.
I guess my point to all of this is that I will contend that the
problem is in the language and not the individual. Yes, an
unfortunate number of our colleagues may not really understand the
complexities of languages they use. (Let's leave personal indolence
and insolence out of it, shall we?) Yes, management usually feels it
needs to exert its authority on issues for which it is not competent
to evaluate the options. (Let's skip the ego thing, too.) But *why*
do I need to propagate such insanities where there are better ways?
Stroustrop et al and his philosophy notwithstanding, with a background
in languages and a frequent, practical user of compiler technology, my
opinion professionally is that C++ as a language absolutely sucks. It
is a pain to use simply because all of the issues noted in this thread
are counter-intuitive. It doesn't matter in the least whether they
are useful to have. There is simply no reason whatsoever that the
normal, introductory, or just plain naive programmer should ever feel
like disemboweling him/herself trying to get something to work when
the trouble is related to obscure language semantics. (I'm sorry,
this is one of the reasons I dislike Ada: coming up with the Posix
bindings was almost an exercise in futility because of all the
restrictions on packages and types.) In that regard, Objective-C is
much cleaner as a strongly typed language, since it is a real albeit
hybrid OO language, where the OO-ness has been neatly layered onto the
original language.
And so that leads to objections about changes to the [base] language.
I must disagree: changes are inevitable. We always find better ways
to do things, or eventually discover that the original way was not as
extensible (read that, "OO") as one would like, or even that some way
we depend on is flatly wrong, and so we "improve" it. I've had to
port system implementations across 8 versions of a single language,
and it is never easy when you've made system (base code) extensions or
changes. (One particularly nasty variant was a rewrite of the
graphics system!) Having a language "protected" by a "standard" still
doesn't prevent gratuitous changes. The best one can do is adapt
programming practices that help to minimize the effects of such
rudeness. But don't whine about it, because the language we favor
most today may very well either be changed or obsolete tomorrow...
-- Tom
"Erik Naggum" <····@naggum.net> wrote in message
·····················@naggum.net...
> * "Kevin McFarlane" <·····@atech.globalnet.co.uk>
> | It's always going to be hard for something new to get a look in. There
> | is, of course, the economic reason that, for example, C/C++ guys are two
> | a penny but Eiffel and Smalltalk guys aren't.
>
Hi Erik
> This is one of the most misleading abuses of statistics around. Just
> because the probability that you hit a C++ programmer if you throw a
rock
> into a crowd is very high, does not mean that the probability that he
can
> replace _your_ C++ programmer is any higher than finding a replacement
> Eiffel or Smalltalk programmer. Because you have to weed through tons
of
> idiots who only _claim_ they know C++, the effort required to find a
real
> replacement may be significantly lower for Eiffel or Smalltalk.
But the Eiffel or Smalltalk programmer might cost you more (in salary), as
there are fewer of them to go around.
> Besides,
> if you can find a good programmer, chances are very good that he will be
> able to learn any programming language you use reasonably well in the
> time it would take to find a good C++ programmer. And learning from the
> sources of the previous programmer is a lot easier than learning the
> language from scratch in a general, application-independent way.
I agree with you. And I would like that to be the case but unfortuantely it
isn't. Employers are obsessed with buzzwords. Many of the buzzwords they're
obsessed about can be learnt to a useful level within a few days by
competent programmers. But I guess it's less effort for recruiters to
concentrate on buzzwords than to assess candidates in more depth.
A friend of mine who was involved in hiring told me a story about this. Two
candidates were offered jobs. The first had all the buzzwords and impressed
the senior manager. My friend was sceptical but the senior manager won on
that occasion. The second candidate had no buzzwords but exuded competence.
The senior manager was not impressed but my friend was. This time my friend
won.
The first candidate was hopelesly out of his depth and left within a week.
The second candidate turned out to be one of their star programmers.
>
> I have actually witnessed this. A company I worked for got a new
manager
> level that was completely superfluous, so the new manager had to prove
to
> herself that she had a real job, and spent a lot of time arguing against
> using languages that were not mainstream, and basically made it hard to
> use anything but Java, and many good people quit. Then a Java man got
> seriously ill. She was unable to replace him in the 5 months he was
> away. The other Java men could not do his work. To her amazement,
> choice of language mattered less than the other skills the programmers
> had.
Yes. This is true. BTW, have you read this? It supports your case.
"Debunking the Myth of a Desperate Software Labor Shortage"
http://heather.cs.ucdavis.edu/itaa.real.html
One of its counterintuitive findings is this:
"A study quoted Myths and Methods: a Guide to Software Productivity by David
T. Fisher (Prentice-Hall, 1991) found that the factor Personnel Capability,
i.e. general talent and energy of the programmers, counted for a score of
4.18 in a productivity prediciton equation. This was by far the largest
factor; the next largest was Product Complexity, with a score of only 2.36.
The factor (Programming) Language Experience, i.e. experience with a
specific software skill, had the smallest score among the 15 factors
studied, with a score of only 1.20. Fisher comments:
'The relatively small impact of language knowledge is an important fact
which is not intuitively obvious. Judging by advertisements for programmers
it would seem that [IT] managers tend to overemphasize specific language
experience.'"
> The conclusion from this story that this manager actually arrived
> at was that it was bad to have skilled programmers -- she alone should
> make the design decisions and programmers would simply implement them.
> She could now return to her policy of using only mainstream languages
and
> hire only unskilled programmers who lied about knowing a language. As
> far as I know, nothing interesting has happened at that company for a
> long time.
>
Unfortunately, this seems to be how most companies operate. And I can't see
it changing anytime soon.
israel r t <········@optushome.com.au> writes:
> Will we all end up like the Moonies , convinced that our faith is the
> One True Faith while the rest of the world moves on ?
Depends.
If you can find the right group of folks who are all interested in improving
their productivity with marginal languages, you can always try and work outside
the "C Block" and do an end-run around slower-moving organizations.
It is Great Mistake to assume that, because a programming language has been
overlooked by the majority, it is therefore not worth pursuing in a niche.
Sure, there's a great draw to simply throwing up one's hands and saying "ah,
what the heck, everyone else is using C++"... and that is a choice of safety
over all else. Not a bad choice, but perhaps not the best choice.
It all depends, of course.
-->VPutz
> Lisp, Ada , Eiffel and Smalltalk are all excellent languages, far
> superior to the Gang of Three ( Java, C++ , C ).
>
> Yet, if Kent is right, they may have all been " rejected ... for
> substantial reasons and not just superficial ones."
For a second I thought by "they" you meant Java, C++ and C. They have
indeed all been rejected, if you think about it.
Anybody want to do without GC and OO (besides Graham)? Goodbye C.
Anybody want to do without GC and worry about pointers and use templates
to get past static typing and wait minutes for a single
edit-compile-link-run iteration? Goodbye C++, witness the rejoicing over
Java, Perl, Python, Ruby...
Anybody happy with Java? Why are people adding JIT compilation, GFs, MI
(AspectJ) and macros?
Obviously the winner is any compiled (fast), GCed, GFing, MI dynamic
language with macros. Mature, an ANSII standard and a free
implementation would not hurt either. hang on...
Kenny
CliniSys
On Sat, 12 Jan 2002 03:56:04 GMT, Kenny Tilton <·······@nyc.rr.com>
wrote:
>Obviously the winner is any compiled (fast), GCed, GFing, MI dynamic
>language with macros. Mature, an ANSII standard and a free
>implementation would not hurt either. hang on...
And Ocaml wins again ! :-)
No macros though...
Lots of currying and and higher order functions however.
And speeeeeeed !
( As if it really matters with commodity 2 GHz processors... )
n Sat, 12 Jan 2002 16:49:59 +1100, israel r t
<········@optushome.com.au> wrote:
>On Sat, 12 Jan 2002 03:56:04 GMT, Kenny Tilton <·······@nyc.rr.com>
>wrote:
>
>>Obviously the winner is any compiled (fast), GCed, GFing, MI dynamic
>>language with macros. Mature, an ANSII standard and a free
>>implementation would not hurt either. hang on...
>
>And Ocaml wins again ! :-)
>
>No macros though...
>Lots of currying and and higher order functions however.
>
>And speeeeeeed !
>( As if it really matters with commodity 2 GHz processors... )
Hmmm. Is there a version of ML that supports macros?
······@interaccess.com (Thaddeus L Olczyk) writes:
> n Sat, 12 Jan 2002 16:49:59 +1100, israel r t
> <········@optushome.com.au> wrote:
> >On Sat, 12 Jan 2002 03:56:04 GMT, Kenny Tilton <·······@nyc.rr.com>
> >wrote:
> >>Obviously the winner is any compiled (fast), GCed, GFing, MI
> >>dynamic language with macros. Mature, an ANSII standard and a free
> >>implementation would not hurt either. hang on...
> >And Ocaml wins again ! :-)
> Hmmm. Is there a version of ML that supports macros?
OCAML has a module called "camlp4" which is something akin to macros,
although it makes me think more of Scheme "define-syntax" than of
Lispy DEFMACRO.
<http://caml.inria.fr/camlp4/>
--
(reverse (concatenate 'string ·············@" "enworbbc"))
http://www.ntlug.org/~cbbrowne/macros.html
"Linux: the operating system with a CLUE... Command Line User
Environment". (seen in a posting in comp.software.testing)
Christopher Browne <········@acm.org> writes:
> OCAML has a module called "camlp4" which is something akin to
> macros,
Yes, it lets you do stuff like:
# #load "/usr/lib/camlp4/camlp4o.cma";;
Camlp4 Parsing version 3.02
# #load "/usr/lib/camlp4/pa_lisp.cmo";;
# (value foo (lambda (x y) (+ x y)))
val foo : int -> int -> int = <fun>
# (foo 2)
- : int -> int = <fun>
# (foo 2 3)
- : int = 5
# ((foo 2) 3)
- : int = 5
But it is far from making `paren-people' happy..
> although it makes me think more of Scheme "define-syntax" than of
> Lispy DEFMACRO.
It is _much_ closer to defmacro than to define-syntax -- it is just
the language manipulating syntax objects (has nothing to do with
hygiene, and the fact that it uses patterns comes from the core
language, unrelated to the macro system).
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
From: Friedrich Dominicus
Subject: Re: True faiths ( was Re: The true faith )
Date:
Message-ID: <87bsg03qpj.fsf@frown.here>
······@interaccess.com (Thaddeus L Olczyk) writes:
> n Sat, 12 Jan 2002 16:49:59 +1100, israel r t
> <········@optushome.com.au> wrote:
>
> >On Sat, 12 Jan 2002 03:56:04 GMT, Kenny Tilton <·······@nyc.rr.com>
> >wrote:
> >
> >>Obviously the winner is any compiled (fast), GCed, GFing, MI dynamic
> >>language with macros. Mature, an ANSII standard and a free
> >>implementation would not hurt either. hang on...
> >
> >And Ocaml wins again ! :-)
> >
> >No macros though...
Not fully correct see
http://caml.inria.fr/camlp4/
> >Lots of currying and and higher order functions however.
> >
> >And speeeeeeed !
> >( As if it really matters with commodity 2 GHz processors... )
> Hmmm. Is there a version of ML that supports macros?
Well I think it's Ocaml.
Regards
Friedrich
israel r t <········@optushome.com.au> writes:
> >Obviously the winner is any compiled (fast), GCed, GFing, MI dynamic
> >language with macros. Mature, an ANSII standard and a free
> >implementation would not hurt either. hang on...
> And Ocaml wins again ! :-)
OCaml doesn't have generic functions, and it is statically typed.
On the other hand it comes with algebraic data types, which can be
handy...
Andreas
--
"In my eyes it is never a crime to steal knowledge. It is a good
theft. The pirate of knowledge is a good pirate."
(Michel Serres)
In comp.lang.ada israel r t <········@optushome.com.au> wrote:
: And Ocaml wins again ! :-)
: And speeeeeeed !
: ( As if it really matters with commodity 2 GHz processors... )
For a decision to be taken shortly, I have compared your
loosers (and more of them) to SML-NJ, Ruby, and SNOBOL4.
Task: do lots of calculations with (alledgedly double prec.)
reals. Result (with optimization, where I know how to achieve it
with compiler switches, with and without range checking):
loosers other than Java: in the range of 10-15 time units,
ML: 45,
Java: 70, (though default compiler options in VAJ 3.5/Win)
Scripting languages: aborted, since they were alread running
for a very long time doing only 10000 iterations, where the
others had run 1Mio times.
It would be interesting to learn whether or not OCaml or any other
of the more pleasing very high level languages are
significantly faster than SML-NL in this respect (since we have to
think about some real time/response time constraints).
Java seems to be adventurous anyway when it comes to fpt,
according to Kahan, so there...
(eAsk me for details if you are interested.)
-- Georg
> Obviously the winner is any compiled (fast), GCed, GFing, MI dynamic
> language with macros. Mature, an ANSII standard and a free
> implementation would not hurt either. hang on...
Like Dylan?
comp.lang.dylan
http://www.gwydiondylan.org
http://www.functionalobjects.com
-- Doug
On 12 Jan 2002 19:39:25 GMT, Doug Hockin
<·······@staffware-spokane.com> wrote:
>> Obviously the winner is any compiled (fast), GCed, GFing, MI dynamic
>> language with macros. Mature, an ANSII standard and a free
>> implementation would not hurt either. hang on...
>
>
>Like Dylan?
>
>comp.lang.dylan
>http://www.gwydiondylan.org
>http://www.functionalobjects.com
>
>-- Doug
He didn't say dead language.
Doug Hockin wrote:
>
> > Obviously the winner is any compiled (fast), GCed, GFing, MI dynamic
> > language with macros. Mature, an ANSII standard and a free
> > implementation would not hurt either. hang on...
>
> Like Dylan?
Is Dylan mature, stable, ANSII standard?
Anyway, not enough parentheses. And I like unhygienic macros.
Dylan to me adds no value over Lisp, so why bother?
All that said, yup, Dylan is something I would consider if Lisp did not
exist.
Oh, damnit, I forgot. How about a MOP. Does Dylan expose the MOP so I
can metaclass?
Anyway, the big quetsion is: what is the added value over Lisp to make
me give up Lisp.
One more thing: I love editing with parentheses-aware editors. Infix
won't cut it.
kenny
clinisys
Kenny Tilton <·······@nyc.rr.com> writes:
> Doug Hockin wrote:
> >
[> > > is Kenny Tilton]
> > > Obviously the winner is any compiled (fast), GCed, GFing, MI dynamic
> > > language with macros. Mature, an ANSII standard and a free
> > > implementation would not hurt either. hang on...
> >
> > Like Dylan?
>
> Is Dylan mature, stable, ANSII standard?
I thought those were just niceties, not necessary for the language to
"win", according to you just above.
> Anyway, not enough parentheses. And I like unhygienic macros.
>
> Dylan to me adds no value over Lisp, so why bother?
Well, sure, right now. Since Dylan seems to have what you think it
would take for a non-mainstream language to make it into the
mainstream, if it did, that's the value it *would* offer. I'd be
*thrilled* to be a Dylaner if there were a ton of Dylan jobs.
You seem to have changed from talking about what "the winner" needs,
to talking about what language you'd rather use. I don't think it's a
good idea to change the definition of "win" so radically, at least
mid-thread :)
> All that said, yup, Dylan is something I would consider if Lisp did not
> exist.
>
> Oh, damnit, I forgot. How about a MOP. Does Dylan expose the MOP so I
> can metaclass?
Yeah, it might have just fallen out of the winning category. I agree,
a MOP is vital.
> Anyway, the big quetsion is: what is the added value over Lisp to make
> me give up Lisp.
>
> One more thing: I love editing with parentheses-aware editors. Infix
> won't cut it.
If you had an infix language that could be turned into a sexp form,
you could probably make an editor that actually worked on its
structure in the image. Not that I'm advocating this, I'm just sayin...
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
"Thomas F. Burdick" wrote:
>
> Kenny Tilton <·······@nyc.rr.com> writes:
>
> > Doug Hockin wrote:
> > >
> [> > > is Kenny Tilton]
> > > > Obviously the winner is any compiled (fast), GCed, GFing, MI dynamic
> > > > language with macros. Mature, an ANSII standard and a free
> > > > implementation would not hurt either. hang on...
> > >
> > > Like Dylan?
> >
> > Is Dylan mature, stable, ANSII standard?
>
> I thought those were just niceties, not necessary for the language to
> "win", according to you just above.
was doug making that distinction? anyway, that was just a point of
information. i do not follow dylan, for all i know it's spec is
stable--i wasn't arguing, i was asking.
> > Dylan to me adds no value over Lisp, so why bother?
>
> Well, sure, right now. Since Dylan seems to have what you think it
> would take for a non-mainstream language to make it into the
> mainstream, if it did, that's the value it *would* offer. I'd be
> *thrilled* to be a Dylaner if there were a ton of Dylan jobs.
well, my whole point was, look past current popularity to how developers
are reacting to the status quo with new languages or new features for
java to get at True Popularity. so might-make-it-mainstream is subtly
OT.
I anyway like to separate the question of how great is a language
regardless of its popularity from considerations deriving from
popularity, such as the number of available jobs, programmers and
libraries. The latter effects of popularity do not in the long run wag
the popularity dog; there was a day when COBOL, VSAM and CICS ruled the
world. Pascal was so big the original Mac OS team used it. And the
Romans really kicked the Christians' asses. Hang on...
Note that I am not saying popularity does not add value in the practical
ways we all grok, just that I like to control for popularity when
assessing long-term prospects of languages.
kenny
clinisys
On Sat, 12 Jan 2002 20:14:53 GMT, Kenny Tilton <·······@nyc.rr.com> wrote:
>> Like Dylan?
>
>Is Dylan mature, stable, ANSII standard?
>
>Anyway, not enough parentheses. And I like unhygienic macros.
>
>Dylan to me adds no value over Lisp, so why bother?
If you are allergic to parentheses, Dylan and Python are very useful. ;-)
--
Fernando Rodr�guez
frr at wanadoo dot es
--
From: Patrick Doyle
Subject: Re: True faiths ( was Re: The true faith )
Date:
Message-ID: <GpvuqI.BJA@ecf.utoronto.ca>
In article <·················@nyc.rr.com>,
Kenny Tilton <·······@nyc.rr.com> wrote:
>
>Oh, damnit, I forgot. How about a MOP. Does Dylan expose the MOP so I
>can metaclass?
Er, what's a MOP?
--
--
Patrick Doyle
······@eecg.toronto.edu
On Sat, 12 Jan 2002 10:46:36 +1100, israel r t wrote:
> Yet, if Kent is right, they may have all been " rejected ... for
> substantial reasons and not just superficial ones."
This implies that the marked is rational and logical. It has shown time
and time again that it isn't. The marked won't choose a superior
technical solution over an inferior yet better marketed or seemingly
cheaper solution.
Capitalisme will need to adjust itself in the near future from the
short-term gain view to a long-term view. This includes taking into
account security and maintainability over time. In all sectors we see
that the drive to cut costs leads to problems with the security; secure
food, transport, utilities, software etc... There now seems to come
articles that looks at the cost of software bugs for bussinesses.
It is just as frustrating every time I hear about some company that
makes some kind of "secure" solution and when you ask them what language
they use they say C or C++. When one then ask them why they use such an
unsafe language they start arguing not that C/C++ is safe, they mostly
agree that it isn't, but out of economical concerns or that they need
people that can program and people know C/C++.
Preben
--
() Join the worldwide campaign to protect fundamental human rights.
'||}
{||' http://www.amnesty.org/
In article <····························@kiuk0156.chembio.ntnu.no>, Preben Randhol wrote:
> On Sat, 12 Jan 2002 10:46:36 +1100, israel r t wrote:
>> Yet, if Kent is right, they may have all been " rejected ... for
>> substantial reasons and not just superficial ones."
>
> This implies that the marked is rational and logical. It has shown time
> and time again that it isn't. The marked won't choose a superior
> technical solution over an inferior yet better marketed or seemingly
> cheaper solution.
It won't? Where do you know that? Who is ``the market''? Software
companies decide for themselves which programming language they use.
Your company is free to choose, too.
> Capitalisme will need to adjust itself in the near future from the
> short-term gain view to a long-term view.
Funny; ``in the near future''. This claim is *very* old, but we are
still waiting ;-)
> It is just as frustrating every time I hear about some company that
> makes some kind of "secure" solution and when you ask them what language
> they use they say C or C++. When one then ask them why they use such an
> unsafe language they start arguing not that C/C++ is safe, they mostly
> agree that it isn't, but out of economical concerns or that they need
> people that can program and people know C/C++.
Well, that's the decision they made, then. If you think it's a wrong
one, you could prove it by making a different decision in /your/ company.
If you are right, your product should be more successful, right?
Blaming the market doesn't make sense at all here. You think the market
is ``irrational and illogical''? Who is ``rational and logical'' then?
Some communist party? There isn't much of an alternative here; either
companies are free to choose, as they are now, or some communist party
decides which programming language we all have to use. Just imagine
which one would that be, considering the ``rational and logical''
decisions those parties have made in the past...
Regards,
--
Nils Goesche
Ask not for whom the <CONTROL-G> tolls.
PGP key ID 0xC66D6E6F
Nils Goesche <······@t-online.de> writes:
> In article <····························@kiuk0156.chembio.ntnu.no>, Preben Randhol wrote:
>
> > Capitalisme will need to adjust itself in the near future from the
> > short-term gain view to a long-term view.
>
> Funny; ``in the near future''. This claim is *very* old, but we are
> still waiting ;-)
Even restricting one's view to economics alone, look at the United
States. We're in the second economic recession in 10 years. And in
the time in between, although unemployment was low, wages didn't grow.
This isn't much of a refultation of the claim. Or are you just
arguing that capitalism still exists? If so, that's not much of an
argument.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> Nils Goesche <······@t-online.de> writes:
>
> > In article <····························@kiuk0156.chembio.ntnu.no>, Preben Randhol wrote:
> > > Capitalism will need to adjust itself in the near future from
> > > the short-term gain view to a long-term view.
> > Funny; ``in the near future''. This claim is *very* old, but we
> > are still waiting ;-)
> Even restricting one's view to economics alone, look at the United
> States. We're in the second economic recession in 10 years. And in
> the time in between, although unemployment was low, wages didn't
> grow. This isn't much of a refultation of the claim. Or are you
> just arguing that capitalism still exists? If so, that's not much
> of an argument.
And "wages" and "unemployment" are forcibly supposed to be related to
the manner of ownership of the results of production _how_?
[You're probably _not_ amongst the clueless on this, but I find it
tremendously irritating when people get spectacularly worshipful about
"capitalism" when they're clearly thinking about things that aren't
forcibly related, such as when concepts of "private property" and
"free markets" could apply equally well under arrangements such as
"mercantilism."]
The notion that it makes sense for "capitalism to adjust itself" to
something when capitalism is an _economic concept_ seems just
spectacularly silly. It's a _definition_, and definitions don't
adjust themselves.
--
(concatenate 'string "cbbrowne" ·@acm.org")
http://www3.sympatico.ca/cbbrowne/
"We're all a little weird. And life is a little weird. And when we
find someone whose weirdness is compatible with ours, we join up with
them and fall into mutually satisfying weirdness - and call it
love..." -- R. Fulghum
Christopher Browne <········@acm.org> writes:
> ···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> > Nils Goesche <······@t-online.de> writes:
> >
> > > In article <····························@kiuk0156.chembio.ntnu.no>, Preben Randhol wrote:
>
> > > > Capitalism will need to adjust itself in the near future from
> > > > the short-term gain view to a long-term view.
>
> > > Funny; ``in the near future''. This claim is *very* old, but we
> > > are still waiting ;-)
>
> > Even restricting one's view to economics alone, look at the United
> > States. We're in the second economic recession in 10 years. And in
> > the time in between, although unemployment was low, wages didn't
> > grow. This isn't much of a refultation of the claim. Or are you
> > just arguing that capitalism still exists? If so, that's not much
> > of an argument.
>
> And "wages" and "unemployment" are forcibly supposed to be related to
> the manner of ownership of the results of production _how_?
I was responding to a claim that seemed to be implying that there
wasn't anything wrong with capitalism's optimizing for short-term
gain. In fact, I think imperialism has just about reached a point of
equilibrium, where it's no longer beneficial (for the capitalist
class) to increase productivity. The United States is now a society
where the average amount of labor is increasing, but the net
production isn't (if things are produced but subsequently exploded or
thrown out, there was no net production). Increased work and
declining wages during the period *between* cyclical recessions is a
symptom of this.
> [You're probably _not_ amongst the clueless on this, but I find it
> tremendously irritating when people get spectacularly worshipful about
> "capitalism" when they're clearly thinking about things that aren't
> forcibly related, such as when concepts of "private property" and
> "free markets" could apply equally well under arrangements such as
> "mercantilism."]
>
> The notion that it makes sense for "capitalism to adjust itself" to
> something when capitalism is an _economic concept_ seems just
> spectacularly silly. It's a _definition_, and definitions don't
> adjust themselves.
But capitalism has certainly evolved over time. Property and class
relations have changed since the mid 19th century. Who knows, maybe
it will evolve some more and find a way to increase production. Or
maybe it won't, and we'll have a social crisis and a change in
property relations :)
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
In article <···············@conquest.OCF.Berkeley.EDU>, Thomas F. Burdick wrote:
> Christopher Browne <········@acm.org> writes:
>
>> ···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>> > Nils Goesche <······@t-online.de> writes:
>> >
>> > > In article <····························@kiuk0156.chembio.ntnu.no>, Preben Randhol wrote:
>>
>> > > > Capitalism will need to adjust itself in the near future from
>> > > > the short-term gain view to a long-term view.
>>
>> > > Funny; ``in the near future''. This claim is *very* old, but we
>> > > are still waiting ;-)
>>
>> > Even restricting one's view to economics alone, look at the United
>> > States. We're in the second economic recession in 10 years. And in
>> > the time in between, although unemployment was low, wages didn't
>> > grow. This isn't much of a refultation of the claim. Or are you
>> > just arguing that capitalism still exists? If so, that's not much
>> > of an argument.
>>
>> And "wages" and "unemployment" are forcibly supposed to be related to
>> the manner of ownership of the results of production _how_?
>
> I was responding to a claim that seemed to be implying that there
> wasn't anything wrong with capitalism's optimizing for short-term
> gain.
There /is/ something wrong with your idea of `capitalism' being
`optimizing' for anything like `short-term gains'. /People/ are
`optimizing'. Maybe some managers and politicians are `optimizing
for short-term gains'. But that is nothing to worry about: If you
think you know better how to win in the long run, by any means, do it!
Those stupid short-term-thinkers that apparently worry you so much
will lose and you'll take them over when they're broke ;-)
But yes, I know what you're up to. You are, like everybody else
on the `leftist' side,
convinced that you can do better than the market; that you know what
people /really/ want, or at least should want to do or to buy because
you are, because of your superior intelligence, able to predict
the future and are the only one who can tell what has to be done instead
in order to save us all. So, we need a strong government, ownership
of companies and anything else has to be transferred to the government
which must be led by yourself, of course, not by some ordinary,
mortal short-term-thinker. Then, elections are no longer necessary
and in fact dangerous, because the stupid public might not recognize,
because of their lack of intelligence, how everything the government
does will be good for them, in the long run, of course, and some
`right-wing' evildoers might convince them to elect somebody else and
we can't have that, can we?
Pretty close? I hope you are not offended by this too much, but I
wanted to show you how all this `leftist' talk sounds to people not
sharing your views. Now you probably think that I am a `right-wing'
evil-doer, that would be a typical reflex at least, but there are
other views of the world than the leftist, and not all of them are
right-wing.
If you find this interesting, however, you might be also interested in
``The Vision of the Anointed: Self-Congratulation As a Basis for
Social Policy''
by Thomas Sowell,
or
``Free to Choose: A Personal Statement''
by Milton and Rose D. Friedman,
both available at Amazon.
Regards,
--
Nils Goesche
Ask not for whom the <CONTROL-G> tolls.
PGP key ID 0xC66D6E6F
Nils Goesche <······@t-online.de> writes:
> There /is/ something wrong with your idea of `capitalism' being
> `optimizing' for anything like `short-term gains'. /People/ are
> `optimizing'. Maybe some managers and politicians are `optimizing
> for short-term gains'. But that is nothing to worry about: If you
> think you know better how to win in the long run, by any means, do it!
> Those stupid short-term-thinkers that apparently worry you so much
> will lose and you'll take them over when they're broke ;-)
To say the above you need to completely ignore property relations.
> But yes, I know what you're up to.
No, you don't. Just because you've met a whole lot of Stalinists and
holier-than-thou Social Democrats doesn't mean you understand the
views of everyone in the class struggle. In particular, even if it
were reasonable to have that attitude with Europeans, projecting your
political understanding across the Atlantic is a recipe for disaster.
You are, like everybody else
> on the `leftist' side,
> convinced that you can do better than the market; that you know what
> people /really/ want, or at least should want to do or to buy because
> you are, because of your superior intelligence, able to predict
> the future and are the only one who can tell what has to be done instead
> in order to save us all. So, we need a strong government, ownership
> of companies and anything else has to be transferred to the government
> which must be led by yourself, of course, not by some ordinary,
> mortal short-term-thinker. Then, elections are no longer necessary
> and in fact dangerous, because the stupid public might not recognize,
> because of their lack of intelligence, how everything the government
> does will be good for them, in the long run, of course, and some
> `right-wing' evildoers might convince them to elect somebody else and
> we can't have that, can we?
>
> Pretty close? I hope you are not offended by this too much, but I
> wanted to show you how all this `leftist' talk sounds to people not
> sharing your views.
Oh, I know how I sound to others. I can't do much about the fact that
some people listen to one thing and hear another. The only way to get
past that is to have a real conversation with someone. On that note,
if you want to continue this over e-mail, I'm down. But I'd rather
not continue this in comp.*, for reasons I hope are obvious :)
> by Milton and Rose D. Friedman,
Oh dear god, Milton Friedman??? I don't know about your politicl
views, but this man's are frighteningly right-wing. If you want to
know what his politics means for the 2nd and 3rd world, look at what
he helped do in Latin America. BTW, this is a very mainstream view to
be frightened of / hateful towards him.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
^This is a sabot cat, a big clue I'm not a communist
From: James A. Robertson
Subject: Re: True faiths ( was Re: The true faith )
Date:
Message-ID: <3C41DF35.6010906@mail.com>
As much as I enjoy a good political discussion, and as much as I've been
sucked into them in this and other forums, I'm going to ask that you
take this to email or an appropriate forum.
Thanks,
Thomas F. Burdick wrote:
> Nils Goesche <······@t-online.de> writes:
>
>
>>There /is/ something wrong with your idea of `capitalism' being
>>`optimizing' for anything like `short-term gains'. /People/ are
>>`optimizing'. Maybe some managers and politicians are `optimizing
>>for short-term gains'. But that is nothing to worry about: If you
>>think you know better how to win in the long run, by any means, do it!
>>Those stupid short-term-thinkers that apparently worry you so much
>>will lose and you'll take them over when they're broke ;-)
>>
>
> To say the above you need to completely ignore property relations.
>
>
>>But yes, I know what you're up to.
>>
>
> No, you don't. Just because you've met a whole lot of Stalinists and
> holier-than-thou Social Democrats doesn't mean you understand the
> views of everyone in the class struggle. In particular, even if it
> were reasonable to have that attitude with Europeans, projecting your
> political understanding across the Atlantic is a recipe for disaster.
>
>
>
> You are, like everybody else
>
>>on the `leftist' side,
>>convinced that you can do better than the market; that you know what
>>people /really/ want, or at least should want to do or to buy because
>>you are, because of your superior intelligence, able to predict
>>the future and are the only one who can tell what has to be done instead
>>in order to save us all. So, we need a strong government, ownership
>>of companies and anything else has to be transferred to the government
>>which must be led by yourself, of course, not by some ordinary,
>>mortal short-term-thinker. Then, elections are no longer necessary
>>and in fact dangerous, because the stupid public might not recognize,
>>because of their lack of intelligence, how everything the government
>>does will be good for them, in the long run, of course, and some
>>`right-wing' evildoers might convince them to elect somebody else and
>>we can't have that, can we?
>>
>>
>
>>Pretty close? I hope you are not offended by this too much, but I
>>wanted to show you how all this `leftist' talk sounds to people not
>>sharing your views.
>>
>
> Oh, I know how I sound to others. I can't do much about the fact that
> some people listen to one thing and hear another. The only way to get
> past that is to have a real conversation with someone. On that note,
> if you want to continue this over e-mail, I'm down. But I'd rather
> not continue this in comp.*, for reasons I hope are obvious :)
>
>
>> by Milton and Rose D. Friedman,
>>
>
> Oh dear god, Milton Friedman??? I don't know about your politicl
> views, but this man's are frighteningly right-wing. If you want to
> know what his politics means for the 2nd and 3rd world, look at what
> he helped do in Latin America. BTW, this is a very mainstream view to
> be frightened of / hateful towards him.
>
>
In article <················@mail.com>, James A. Robertson wrote:
> As much as I enjoy a good political discussion, and as much as I've been
> sucked into them in this and other forums, I'm going to ask that you
> take this to email or an appropriate forum.
Of course, sorry about that. I won't post anything more to this thread
and switched to email.
Regards,
--
Nils Goesche
Ask not for whom the <CONTROL-G> tolls.
PGP key ID 0xC66D6E6F
Nils Goesche <······@t-online.de> writes:
> There /is/ something wrong with your idea of `capitalism' being
> `optimizing' for anything like `short-term gains'. /People/ are
> `optimizing'. Maybe some managers and politicians are `optimizing
The problem is within the so-called "system effect", actions that do
not result from individual action of the people, but of structures as
a whole.
Very much like neurons in our brain...
> But yes, I know what you're up to. You are, like everybody else
> on the `leftist' side,
> convinced that you can do better than the market; that you know what
> people /really/ want, or at least should want to do or to buy because
> you are, because of your superior intelligence, able to predict
> the future and are the only one who can tell what has to be done instead
> in order to save us all. So, we need a strong government, ownership
I think it's too easy to paint this as the typical 'leftist' attitude.
Modern politics has more dimensions than just the one left-right
dimension many people use to save themselves from thinking for
themselves.
What you describe is more the individualism vs. society axis. The far
extreme you describe is totalitarism: no power left at the individual,
all power at the society. This has been happening for both the
leftists (Stalin-type socialist dictatorship), and the rightists
(Hitler-type nationalist dictatorship).
For the left-right debate, I think this quote gets it all: "There are
two kinds of fools: one say 'This is old and therefore good', the
other say 'this is new and therefore better'." Neither the left nor
the right position is inherently right, it's about the balance that
benefits mankind the most.
The same goes for the balance between freedom and security: the very
nature of society is to give up some freedom (such as the freedom to
kill your neighbour) for security (such as being secure from being
killed by your neighbour). Again, we're challenged to balance this
well, and it's independent of the left-right balance.
Andreas
--
"In my eyes it is never a crime to steal knowledge. It is a good
theft. The pirate of knowledge is a good pirate."
(Michel Serres)
>>>>> "Preben" == Preben Randhol <·············@pvv.org> writes:
Preben> On Sat, 12 Jan 2002 10:46:36 +1100, israel r t wrote:
>> Yet, if Kent is right, they may have all been " rejected ... for
>> substantial reasons and not just superficial ones."
Preben> This implies that the marked is rational and logical. It has
Preben> shown time and time again that it isn't.
Exactly, the market is made up of armies of individuals that behave
according to their own small views of the world. If enough individuals
falls for a myth about something being smart and cool, then that will
be the markets collected reaction as well.
Preben> Capitalisme will need to adjust itself in the near future from
Preben> the short-term gain view to a long-term view.
Unfortunately, I do not share that optimism. To survive in the market
place, it is good enough that you do not do any worse than your
competitors in certain areas and then you can be better in some other
areas. So using C as an application language will not a business if
the competitors do the same. Of course using something better than C
will increase the advantages of that business, but it isn't a
requirement.
So as long as enough people believe something, and the market will
provide a selfsustainable weight to a belief once it is there, it will
not be working against you, even if it is downright wrong.
A real bummer for payrollers such as myself that needs to depend on
management seeing through the myths to be able to work with lisp, but
certainly also a great opportunity for the entrepreneur with a good
idea and an understanding of what lisp can do for him.
In the land of the blind, the one-eyed is king.
------------------------+-----------------------------------------------------
Christian Lynbech | Ericsson Telebit, Skanderborgvej 232, DK-8260 Viby J
Phone: +45 8938 5244 | email: ·················@ted.ericsson.dk
Fax: +45 8938 5101 | web: www.ericsson.com
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- ·······@hal.com (Michael A. Petonic)
In article <················@worldnet.att.net>, Jim Rogers <················@worldnet.att.net> writes:
> Aha. There are solutions to this problem, with or without GC.
> The solution is to provide a separate storage pool for each
> thread. That storage pool could then be managed manually or by
> GC. With this design, one thread consuming its storage pool would
> not interfere with the storage usage of other threads.
What happens when one thread passes an object to another thread ?
Larry Kilgallen wrote:
> In article <················@worldnet.att.net>, Jim Rogers <················@worldnet.att.net> writes:
>
>
>>Aha. There are solutions to this problem, with or without GC.
>>The solution is to provide a separate storage pool for each
>>thread. That storage pool could then be managed manually or by
>>GC. With this design, one thread consuming its storage pool would
>>not interfere with the storage usage of other threads.
>>
>
> What happens when one thread passes an object to another thread ?
>
You have three choices.
1) Only objects allocated from a global storage pool can be passed
between threads.
2) (Yuck) Objects are only passed by copy, not by reference.
3) Any object can be passed by reference. Objects from a local
storage pool cannot be allocated by any but their local thread.
This option really makes deallocation, either manual or GC, very
hard to get right. :-(
The first option is often enforced by multi-processor systems,
where shared data must be in a special region of memory visible
to all processors. In Ada terms, this region of memory would be
used only for protected objects.
Of course, with this option, it is still possible for a single
thread to unfairly dominate memory usage. As in all cases, you
stil need to design intelligently to limit storage pool
contention.
Jim Rogers
Colorado Springs, Colorado USA
Jim Rogers wrote:
> 2) (Yuck) Objects are only passed by copy, not by reference.
Actually, this is only "Yuck" with primitive semantics. For example, a
functional program uses this type of semantic (only copy) all the time,
but the compiler is smart enough to figure out when to copy and when not
to. Hermes did a similar thing, and the compiler was good enough that it
not only usually passed by reference in spite of the pass by copy
semantics, it often managed to not pass the value at all, and simply
compiled the address of the caller's variable into the callee where it
could.
Think about something like SQL and whether it's easy or hard for the
programmer to make it work right on distributed processors.
--
Darren New
San Diego, CA, USA (PST). Cryptokeys on demand.
The opposite of always is sometimes.
The opposite of never is sometimes.
···@jpl.nasa.gov (Erann Gat) writes:
> When I say "reproduce Google" I mean reproduce not only Google's behavior
> but also its performance. When you're doing essentially a single
> computation repeated 100 million times a day performance matters. To get
> Google-like performance you have to do some pretty hairy optimizing at
> some pretty low levels. All kinds of things that you can usually ignore
> start to become very significant at that scale. Lisp's great strength
> (one of them) is that it hides a lot of the low-level cruft, which is
> exactly the opposite of what you need in that case.
You could never write a { 3d modeller, real-time data acquisition
system, operating system } in Lisp! After all, such software requires
repeatedly performaning computationally-intensive operations within a
finite period of time. Who could reasonably expect Lisp to meet such
deadlines!?!
More seriously, if you need to make your Lisp code run super fast,
nobody is going to stop you from exploiting compiler idioms, machine
idioms, or manually performing code optimizations your compiler
missed. The limiting factor is your own cleverness and the same goes
for C and Fortran.
Perhaps the only thing using a language aside from Lisp will give you
is a lot of shoulders to cry on. I suppose some people need that kind
of thing, though.
"Carl Shapiro" <········@panix.com> wrote in message
····················@panix3.panix.com...
> ···@jpl.nasa.gov (Erann Gat) writes:
> You could never write a { 3d modeller, real-time data acquisition
> system, operating system } in Lisp! After all, such software requires
> repeatedly performaning computationally-intensive operations within a
> finite period of time. Who could reasonably expect Lisp to meet such
> deadlines!?!
The only thing preventing a "Hard" Real Time system in Lisp is dynamic
memory allocation. If you have very precise timings one should (in general)
have all manipulated storage on the stack or in static memory locations.
You know where everything is and have control of all resources. Nothing
unexpected, no page swapping (probably no virtual memory), no unexpected
garbage collections. There is no reason a Lisp dialect could not be created
and compiled for a hard real-time problems (other languages are). Just
eliminate dynamic allocation. One is just left with the Lisp syntax and of
course many of the benefits disappear. Of course the real time system could
then developed in a simulation environment (say written in CL) and then
cross-compiled and tested in the actual system (which it probably has to be
anywise).
When developing a real-time system, there is still LOTS of simulation and
test code, which Lisp is really good at. This
development/documentation/testing framework is at least 50% of the work,
probably more like 95%. People always forget this simple fact of getting
your code from design to delivery involves more than just writing the actual
system. Scaffold code like this is more complex than the delivered product.
Which real-time data acquisition system did you have in mind? A remote
terminal unit monitoring a fire alarm at a remote pipeline pumping station
and collecting data from a particle accelerator are two vastly different
things.
Wade
Carl Shapiro <········@panix.com> wrote:
>You could never write a { 3d modeller, real-time data acquisition
>system, operating system } in Lisp! After all, such software requires
>repeatedly performaning computationally-intensive operations within a
>finite period of time. Who could reasonably expect Lisp to meet such
>deadlines!?!
>
G2, the ancestor of G2 Classic (see http://www.gensym.com) was a
real-time expert system shell written in Lisp (a CL one with some
extensions like the ones described in the post of Wade). I think G2
Classic is now C, I would like to know what has been the real benefit
of the port.
--
www.algo.be
Logo programming : www.algo.be/logo.html
Francis Leboutte <··········@algo.be> writes:
> G2, the ancestor of G2 Classic (see http://www.gensym.com) was a
> real-time expert system shell written in Lisp (a CL one with some
> extensions like the ones described in the post of Wade). I think G2
> Classic is now C, I would like to know what has been the real benefit
> of the port.
Gensym's G2 real-time expert system, the Telewindows display client,
and their RPC library are all still written in Common Lisp. FYI, G2
Classic is the same thing as G2. "Classic" is just a wacky marketing
term intended to differentiate the expert system itself from all of
the layered products building on top of it.
In case anybody is interested, there have been several papers
published which describe aspects of the memory management and Lisp
delivery strategies used by Gensym.
Carl Shapiro <········@panix.com> writes:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > When I say "reproduce Google" I mean reproduce not only Google's behavior
> > but also its performance. When you're doing essentially a single
> > computation repeated 100 million times a day performance matters. To get
> > Google-like performance you have to do some pretty hairy optimizing at
> > some pretty low levels. All kinds of things that you can usually ignore
> > start to become very significant at that scale. Lisp's great strength
> > (one of them) is that it hides a lot of the low-level cruft, which is
> > exactly the opposite of what you need in that case.
>
> You could never write a { 3d modeller, real-time data acquisition
> system, operating system } in Lisp! After all, such software requires
Take a look at http://www.izware.com. This is the
ex-Symbolics and ex-Nichimen stuff. Lots of people
think this is perhaps the best 3D modeller. And
it's in Common Lisp.
-cph
> Take a look at http://www.izware.com. This is the
> ex-Symbolics and ex-Nichimen stuff. Lots of people
> think this is perhaps the best 3D modeller. And
> it's in Common Lisp.
Thanks for this link. It just happened that my 8 year old son wanted to do
some 3D modelling (wants to design video games). I downloaded the Nendo
Demo. It's great and my son has learned to use it already.
Wade
In article <····················@192.168.1.50>, ···@jpl.nasa.gov (Erann
Gat) wrote:
> In article <···························@news.paradise.net.nz>, Bruce Hoult
> <·····@hoult.org> wrote:
>
> > In article <····················@eglaptop.jpl.nasa.gov>,
> > ···@jpl.nasa.gov (Erann Gat) wrote:
> >
> > > I don't believe it would be possible to reproduce Google in Lisp.
> >
> > That's a pretty strong statement. Why?
>
> When I say "reproduce Google" I mean reproduce not only Google's behavior
> but also its performance. When you're doing essentially a single
> computation repeated 100 million times a day performance matters. To get
> Google-like performance you have to do some pretty hairy optimizing at
> some pretty low levels. All kinds of things that you can usually ignore
> start to become very significant at that scale. Lisp's great strength
> (one of them) is that it hides a lot of the low-level cruft, which is
> exactly the opposite of what you need in that case.
Sure, but the better Lisps (or Lisp-like languages, such as Dylan) allow
you to specify the low level details pretty well when you need to.
Or is lots of google written in assembler?
-- Bruce
Bruce Hoult <·····@hoult.org> writes:
> Sure, but the better Lisps (or Lisp-like languages, such as Dylan) allow
> you to specify the low level details pretty well when you need to.
>
> Or is lots of google written in assembler?
For decades (at least since Lisp 1.5), Lisp implementations have
allowed one to in-line assembly code in Lisp functions. Having to
write parts of your Lisp project in assembler has effectively never
been an issue.
···@jpl.nasa.gov (Erann Gat) wrote in message news:<····················@eglaptop.jpl.nasa.gov>...
> This came as a hard lesson for me because when I went to Google I was an
> Apostle of the True Faith. I've been a Lisp programmer for twenty years.
I'm still confused about this. You were a Lisp fanatic. You left
JPL, where you were using Lisp extensively, in what most people would
consider a dream job, programming robots and spacecraft, sending them
to other planets, etc. You left that job and went to Google, where
they had no plans to use Lisp at all. What was your job at Google?
Why did you want that job, and why did they want you?
In article <····························@posting.google.com>,
··········@mailandnews.com (Software Scavenger) wrote:
> ···@jpl.nasa.gov (Erann Gat) wrote in message
news:<····················@eglaptop.jpl.nasa.gov>...
>
> > This came as a hard lesson for me because when I went to Google I was an
> > Apostle of the True Faith. I've been a Lisp programmer for twenty years.
>
> I'm still confused about this. You were a Lisp fanatic. You left
> JPL, where you were using Lisp extensively, in what most people would
> consider a dream job, programming robots and spacecraft, sending them
> to other planets, etc. You left that job and went to Google, where
> they had no plans to use Lisp at all. What was your job at Google?
I was a software engineer.
> Why did you want that job, and why did they want you?
The unvarnished truth about my motives is a very long story. Suffice it
to say that I had been at JPL for twelve years and I wanted to do
something different before I retired. As to why Google wanted me, well, I
guess it's because they thought I had something to contribute to the
company. I was (and actually still am) a Lisp fan, but I am not (and
never was) *just* a Lisp fan. It's astonishing how many people, both
lispers and non, assume that my fondness for Lisp defines my entire
professional identity.
E.
>>>>> On Mon, 21 Jan 2002 11:35:32 -0800, Erann Gat ("Erann") writes:
Erann> Remember the 9-nines problem? I compared solutions in both
Erann> Lisp and Python. The Python code was shorter and ran about
Erann> twice as fast (compared to MCL). I've seen similar benchmark
Erann> results for Perl.
I don't understand what you're trying to say here: there is something
inherent about the Lisp language such that programs will generally be
more efficient when written in Perl or Python? Or are you just saying
that the MCL compiler runs this particular program slower than some
single-implementation-compiler for some other language? I suppose if
your requirements are that you're solving the "9-nines" problem and are
restricted to that particular compiler, that might mean something to you.
It is well known (in thesis and books, in discussions here, etc.) that
benchmarking random programs is generally misleading because those results
do not scale to indicate performance in real applications.
* Christopher Stacy wrote:
> It is well known (in thesis and books, in discussions here, etc.)
> that benchmarking random programs is generally misleading because
> those results do not scale to indicate performance in real
> applications.
But they make good newsgroup postings, which is much more important
than actually being true, or even plausible.
--tim
Tim Bradshaw wrote:
> But they make good newsgroup postings, which is much more important
> than actually being true, or even plausible.
But only so long as they are also inflamatory and critical of languages
that the author has no knowledge of. Oh yes - it also helps if one
disparages well-known personages in some particular newsgroup and
crossposts to several language-related (or sometimes not) newsgroups, as
well.
And, of course, have a nice day...
faa
>>>>> On Mon, 21 Jan 2002 11:35:32 -0800, Erann Gat ("Erann") writes:
Erann> Smart people have achieved great results in C++, which I had
Erann> thought was categorically impossible.
Well, that does sound like religion!
I would say that Lisp is optimized for managing complexity and is
generally better at it than C++.
Smart people have achieved great results in assembley language, too.
Christopher Stacy wrote:
>
> >>>>> On Mon, 21 Jan 2002 11:35:32 -0800, Erann Gat ("Erann") writes:
> Erann> Smart people have achieved great results in C++, which I had
> Erann> thought was categorically impossible.
>
> Well, that does sound like religion!
Indeed. I've had good luck with COBOL a few times.
You know, Stendhal had a good chapter in "On Love" about infatuation,
and how the infatuated, once the objects of their desire prove unequal
to the over-ardent estimation--as they must--are then equally unjust in
their rejection.
Hmmmm...
:)
kenny
clinisys
Christopher Stacy <······@swingandcircle.com> writes:
> >>>>> On Mon, 21 Jan 2002 11:35:32 -0800, Erann Gat ("Erann") writes:
> Erann> Smart people have achieved great results in C++, which I had
> Erann> thought was categorically impossible.
>
> Well, that does sound like religion!
>
> I would say that Lisp is optimized for managing complexity and is
> generally better at it than C++.
>
> Smart people have achieved great results in assembley language, too.
This is an important point for anyone who gets too smug about their
language. In an essay, Knuth discusses structured programming and
makes the point that structured programming is probably superior to
what they'd been doing before, for almost all programs, but that
doesn't mean that they didn't make lots of good software in the time
before then.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Kenny Tilton <·······@nyc.rr.com> writes:
> Alain Picard wrote:
> >
> > Kenny Tilton <·······@nyc.rr.com> writes:
> >
> > >
> > > defun bq-simplify-args x
> > > do args reverse cdr x cdr args
> > > result
> > > nil
> > > cond atom car args
> > > bq-attach-append *bq-append* car args result
> > > and eq caar args *bq-list*
> > > [SNIP!]
> >
> > That's _so_ _weird_. Am I the only one who thinks
> > this is *less* readable than a parenthesized version?
>
> My bad. I was too lazy to introduce the line breaks you would need to
> make the indentation work. Here ya go, this should be OK (on a shorter
> Steel BQ func):
>
> defun bracket x
> cond atom x
> list *bq-list*
> bq-process x
>
> eq car x
> *comma*
> list *bq-list*
> cadr x
>
> eq car x
> *comma-atsign*
> cadr x
>
> eq car x
> *comma-dot*
> list *bq-clobberable*
> cadr x
>
> t list *bq-list*
> bq-process x
>
> I'll be honest, even with parens i tend to give each func operand its
> own line as above.
I once had to put out a report with indentations similar to above. It
helped to follow the indentation by providing a rule:
defun bracket x
cond atom x
| |list *bq-list*
| | bq-process x
| | |
| eq car x
| | *comma*
| list *bq-list*
| | cadr x
| | |
| eq car x
| | *comma-atsign*
| cadr x
| | |
| eq car x
| | *comma-dot*
| list *bq-clobberable*
| | cadr x
| | |
| t list *bq-list*
| | bq-process x
> Gives new meaning to spaghetti code, don't you think? I am thinking we
> address that by extending emacs to support multiple columns, like a
> newspaper.
>
> defun bracket x | eq car x
> cond atom x | *comma-dot*
> list *bq-list* | list *bq-clobberable*
> bq-process x | cadr x
> |
> eq car x | t list *bq-list*
> *comma* | bq-process x
> list *bq-list* |
> cadr x |
> |
> eq car x |
> *comma-atsign* |
> cadr x |
Interestingly, when I look at this from my newsreader, it interprets the
asterisks as a bold font indicator, so it loses a couple of colums.
As a result, your line is crooked.
(although as I'm editing this reply, it is perfectly straight...)
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
Duane Rettig <·····@franz.com> writes:
> Interestingly, when I look at this from my newsreader, it interprets the
> asterisks as a bold font indicator, so it loses a couple of colums.
> As a result, your line is crooked.
Yes, the Gnus maintainer really doesn't care. I was apparently the
millionth person to point out that this was *removing* information
where Gnus usually only adds it through font-locking. I pointed out
the *var* convention for specials in CL. He just doesn't give a damn.
Too bad. I wasn't arguing against removing the feature, just having
it leave the asterisks present by default. The really annoying
response I got was to (setq gnus-treat-emphasize nil). It works, but
it doesn't change the fact that it's a brain-dead default.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
In article <···············@conquest.OCF.Berkeley.EDU>, Thomas F. Burdick wrote:
> Duane Rettig <·····@franz.com> writes:
>
>> Interestingly, when I look at this from my newsreader, it interprets the
>> asterisks as a bold font indicator, so it loses a couple of colums.
>> As a result, your line is crooked.
>
> Yes, the Gnus maintainer really doesn't care. I was apparently the
> millionth person to point out that this was *removing* information
> where Gnus usually only adds it through font-locking. I pointed out
> the *var* convention for specials in CL. He just doesn't give a damn.
> Too bad. I wasn't arguing against removing the feature, just having
> it leave the asterisks present by default. The really annoying
> response I got was to (setq gnus-treat-emphasize nil). It works, but
> it doesn't change the fact that it's a brain-dead default.
Interestingly, slrn, which is in many ways similiar to gnus, gets
this very thing right :-)
Regards,
--
Nils Goesche
Ask not for whom the <CONTROL-G> tolls.
PGP key ID 0xC66D6E6F
From: Brian P Templeton
Subject: Re: Ciel: A Modest Proposal
Date:
Message-ID: <87elkkjq7h.fsf@tunes.org>
···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> Duane Rettig <·····@franz.com> writes:
>
>> Interestingly, when I look at this from my newsreader, it interprets the
>> asterisks as a bold font indicator, so it loses a couple of colums.
>> As a result, your line is crooked.
>
> Yes, the Gnus maintainer really doesn't care. I was apparently the
> millionth person to point out that this was *removing* information
> where Gnus usually only adds it through font-locking. I pointed out
> the *var* convention for specials in CL. He just doesn't give a damn.
> Too bad. I wasn't arguing against removing the feature, just having
> it leave the asterisks present by default. The really annoying
> response I got was to (setq gnus-treat-emphasize nil). It works, but
> it doesn't change the fact that it's a brain-dead default.
>
Sorry if I'm missing something obvious, but how does this remove
information with the other default faces used by Gnus? Also, if I am
not incorrect that this does not discard information, then I also add
that some CL developers either like it or don't particularly care (I
haven't made up my mind yet), and the people that dislike it, by
virtue of being Lisp programmers, will likely know what SETQ does ;).
> --
> /|_ .-----------------------.
> ,' .\ / | No to Imperialist war |
> ,--' _,' | Wage class war! |
> / / `-----------------------'
> ( -. |
> | ) |
> (`-. '--.)
> `. )----'
--
BPT <···@tunes.org> /"\ ASCII Ribbon Campaign
backronym for Linux: \ / No HTML or RTF in mail
Linux Is Not Unix X No MS-Word in mail
Meme plague ;) ---------> / \ Respect Open Standards
Brian P Templeton <···@tunes.org> writes:
> ···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
> > Duane Rettig <·····@franz.com> writes:
> >
> >> Interestingly, when I look at this from my newsreader, it interprets the
> >> asterisks as a bold font indicator, so it loses a couple of colums.
> >> As a result, your line is crooked.
> >
> > Yes, the Gnus maintainer really doesn't care. I was apparently the
> > millionth person to point out that this was *removing* information
> > where Gnus usually only adds it through font-locking. I pointed out
> > the *var* convention for specials in CL. He just doesn't give a damn.
> > Too bad. I wasn't arguing against removing the feature, just having
> > it leave the asterisks present by default. The really annoying
> > response I got was to (setq gnus-treat-emphasize nil). It works, but
> > it doesn't change the fact that it's a brain-dead default.
> >
>
> Sorry if I'm missing something obvious, but how does this remove
> information with the other default faces used by Gnus?
Let me rephrase that sentance. Whereas Gnus usually only adds
information (via font locking), this feature actually removes
information (the asterisks) in addition to adding font locking.
> Also, if I am not incorrect that this does not discard information,
> then I also add that some CL developers either like it or don't
> particularly care (I haven't made up my mind yet), and the people
> that dislike it, by virtue of being Lisp programmers, will likely
> know what SETQ does ;).
Normally Gnus does something like:
(some-fun :foo (foo)
:bar (bar))
where the line that starts ":bar ..." is colored as a quotation. It
doesn't remove the ":", partly because it's using heuristics to guess
at meaning, so it shouldn't remove the information it thought it
translated into color. Not all *word* words are meant to be bold.
Making it bold is fine, but removeing the *'s is a pretty confident
statement about what exactly they meant.
And I figured out how to turn that "feature" off pretty quickly, but
not before having a bit of confusion first. There is *no* other
situation I know of where Gnus deletes portions of the news text, so I
wasn't expecting it at all.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> And I figured out how to turn that "feature" off pretty quickly, but
> not before having a bit of confusion first. There is *no* other
> situation I know of where Gnus deletes portions of the news text, so
> I wasn't expecting it at all.
What about _underlines_?
From: Brian P Templeton
Subject: Re: Ciel: A Modest Proposal
Date:
Message-ID: <87vgdpepta.fsf@tunes.org>
···@agharta.de (Dr. Edmund Weitz) writes:
> ···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
>> And I figured out how to turn that "feature" off pretty quickly, but
>> not before having a bit of confusion first. There is *no* other
>> situation I know of where Gnus deletes portions of the news text, so
>> I wasn't expecting it at all.
>
> What about _underlines_?
And /emphasis/.
--
BPT <···@tunes.org> /"\ ASCII Ribbon Campaign
backronym for Linux: \ / No HTML or RTF in mail
Linux Is Not Unix X No MS-Word in mail
Meme plague ;) ---------> / \ Respect Open Standards
>>>>> On Fri, 11 Jan 2002 08:48:59 -0700, Wade Humeniuk ("Wade") writes:
Wade> "Carl Shapiro" <········@panix.com> wrote in message
Wade> ····················@panix3.panix.com...
>> ···@jpl.nasa.gov (Erann Gat) writes:
>> You could never write a { 3d modeller, real-time data acquisition
>> system, operating system } in Lisp!
Wade> The only thing preventing a "Hard" Real Time system in Lisp is dynamic
Wade> memory allocation.
I think he was being facetious, citing a few examples of real-time
applications that have been done in Lisp in the past.
Telephone switching is another one.
"Jean-Fran�ois Brouillet" <·····@mac.com> wrote in message
························@mac.com...
> you'll have for free in years. Leave c.l.l. in peace, and I promise to
> step down from my soapbox.
I'd prefer if _you_ would leave c.l.l in peace. Really....
--
Coby
(remove #\space "coby . beck @ opentechgroup . com")
D'o� y d�barque suil�? Y s'appelle aussi Naggum?
Ah bon? Y sont deux maintenant?
Poor little shitty thing! When you read that a thread title
is "Nagging Naggum", you don't need to stretch your imagination
beyond inhumane limits to kind of guess we're not talking
16th century litterature!
--
Jean-Fran�ois Brouillet
On 3/1/02 23:08, in article
·························@typhoon.tampabay.rr.com, "Coby Beck"
<·····@mercury.bc.ca> wrote:
>
> "Jean-Fran�ois Brouillet" <·····@mac.com> wrote in message
> ························@mac.com...
>> you'll have for free in years. Leave c.l.l. in peace, and I promise to
>> step down from my soapbox.
>
> I'd prefer if _you_ would leave c.l.l in peace. Really....
>
> --
> Coby
> (remove #\space "coby . beck @ opentechgroup . com")
>
>
Please understand the special c.l.l psychology. We have just elaborated that
Erik is an important feature of CL (though some people think he is a bug).
We are all afraid of losing him as nobody knows what happens to CL after
him? Some people are even afraid that in this case CL turns into Scheme
(after the spell is removed).
J.B.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
Check out our new Unlimited Server. No Download or Time Limits!
-----== Over 80,000 Newsgroups - 19 Different Servers! ==-----
Janos Blazi <······@hotmail.com> wrote:
> Please understand the special c.l.l psychology. We have just elaborated that
> Erik is an important feature of CL (though some people think he is a bug).
> We are all afraid of losing him as nobody knows what happens to CL after
> him? Some people are even afraid that in this case CL turns into Scheme
> (after the spell is removed).
This aspect had completely eluded me. Sorry for not seeing the obvious.
But in that case, shouldn't we commoditize Naggum as naggum, as in:
"Today I fixed two f***ing naggums in my code" or
"The marketing department has added two naggums to their bullet list" ?
But then we might as well use him for the posterity, as in:
(defun naggum (x) x) ; identity
(defun naggum () nil) ; tautology
(defun naggum (x) ; non elimination of abusive
(naggum (1+ x))) ; self-recursion
--
Jean-Fran�ois Brouillet
On Fri, 04 Jan 2002 00:08:14 +0000, Jean-François Brouillet
<·····@mac.com> wrote:
> "Today I fixed two f***ing naggums in my code" or
> "The marketing department has added two naggums to their bullet list" ?
Excellent.
I can see all sorts of possibilities there..
" VB is a naggum"
"Windows is bringing about the inexorable naggumification of the free
world ."
" In the Lord of the Rings, Sauron wanted to get the Master Ring so
that he would become the Great Naggum "
On Fri, 4 Jan 2002 00:56:38 +0100, "Janos Blazi" <······@hotmail.com>
wrote:
>Please understand the special c.l.l psychology. We have just elaborated that
>Erik is an important feature of CL (though some people think he is a bug).
We are working on improving the incremental garbage collection
algorithm so that he will be removed...
However, we suspect that he will be around until Bill Gates embraces
Common Lisp.
>We are all afraid of losing him as nobody knows what happens to CL after
>him? Some people are even afraid that in this case CL turns into Scheme
>(after the spell is removed).
Apres moi, le deluge !
My sincere apologies for my rather limited Francophone abilities.
Jean-Fran�ois Brouillet <·····@mac.com> writes:
> D'o� y d�barque suil�? Y s'appelle aussi Naggum?
> Ah bon? Y sont deux maintenant?
Non, il sont plusieurs, _imb�cile_.
Sans farces, I've read many interesting posts by Erik
in the past, but none by you. Tell you what, you post
_ONE_ post with technical merit in it, and the "community"
which you profess to "protect" will _so_ amazed that they'll
probably welcome you with open arms.
We're not holding our breath, however.
Alain Picard <·······@optushome.com.au> wrote:
>
>Non, il sont plusieurs, _imb�cile_.
>
H�h�! Par un effet de bord sournois, ce groupe deviendrait-il un
groupe francophone?
Sorry, I couldn't resist!
--
www.algo.be
Logo programming : www.algo.be/logo.html
* Jean-Fran�ois Brouillet
| Why Naggum thinks that [...]
I did not think that. That you think so based on my response is _very_
interesting. You are not smart enough to understand that you were
deliberately tricked into revealing your real position and purpose with a
response that would feel hostile only if _you_ were a bad person. Thank
you for choosing the kind of response that leaves no doubt about you.
| Why would attacking Naggum be _interesting_ ? To whom ?
Good. You are defending yourself, now. This is very good evidence of
_conscious_ wrong-doing on your part. You are a very bad person, which I
wanted you to come out and tell us yourself, and you did, admirably.
Your insistence on talking about me just because I point out that your
considerable personality disorders are (sarcastically) _interesting_ is
extremely revealing. I can only thank you for relieving me of any need
to demonstrate how you are a very bad person. And you will continue to
provide us with more evidence of your very bad character, if you are the
character I judge you to be. Go ahead, now.
| If attacking Naggum [...]
Get psychiatric help, Jean-Fran�ois Brouillet. You need it. This is
obvious to me now, and it will be obvious to everyone else in a short
while. Please keep up the self-incrimination for the benefit of those
who might still think that you could be normal, decent human being.
///
--
Naggum: do you actually read (and understand???) the parts that
you skip when quoting?
It seems to me that you don't!
The question is _not_ to decide whether I'm a good or a bad person.
Nobody cares.
My only goal is to get you to
SHUT UP BECAUSE YOU'RE WASTING EVERYONE'S BANDWIDTH
AND JEOPARDIZING OUR READ TIME WHICH IS NOT SO COPIOUS
Go create an alt.naggum.fans but leave us alone! I've got a lot to
learn in Common Lisp, and your sudden irruptions in various threads
prevents people from carrying on with exposing their ideas.
YOU'RE SUCH A GREAT INHIBITOR
We don't _need_ Naggum.
Mais, merde enfin. Il fait vraiment chier ce connard. J'en ai
rien � taper de ce que ducon Naggum pense. Moi? Je veux voire
du Lisp dans comp.lang.lisp.
Et �tre d�barass� de ce psychopathe de Naggum qui vient polluer
toutes les discussions!
C'est trop demander peut-�tre ?
Naggum: GO HOME! take a vacation! KILL YOURSELF! leave us alone.
I am fed-up! I want to learn. NOT READ ABOUT THE EMPTYNESS OF
NAGGUM SKULL !
GO AWAY
--
Jean-Fran�ois Brouillet
On 3/1/02 15:55, in article ················@naggum.net, "Erik Naggum"
<····@naggum.net> wrote:
> * Jean-Fran�ois Brouillet
> | Why Naggum thinks that [...]
>
> I did not think that. That you think so based on my response is _very_
> interesting. You are not smart enough to understand that you were
> deliberately tricked into revealing your real position and purpose with a
> response that would feel hostile only if _you_ were a bad person. Thank
> you for choosing the kind of response that leaves no doubt about you.
>
> | Why would attacking Naggum be _interesting_ ? To whom ?
>
> Good. You are defending yourself, now. This is very good evidence of
> _conscious_ wrong-doing on your part. You are a very bad person, which I
> wanted you to come out and tell us yourself, and you did, admirably.
>
> Your insistence on talking about me just because I point out that your
> considerable personality disorders are (sarcastically) _interesting_ is
> extremely revealing. I can only thank you for relieving me of any need
> to demonstrate how you are a very bad person. And you will continue to
> provide us with more evidence of your very bad character, if you are the
> character I judge you to be. Go ahead, now.
>
> | If attacking Naggum [...]
>
> Get psychiatric help, Jean-Fran�ois Brouillet. You need it. This is
> obvious to me now, and it will be obvious to everyone else in a short
> while. Please keep up the self-incrimination for the benefit of those
> who might still think that you could be normal, decent human being.
>
> ///
* Jean-Fran�ois Brouillet <·····@mac.com>
| Naggum: GO HOME! take a vacation! KILL YOURSELF! leave us alone.
| I am fed-up! I want to learn. NOT READ ABOUT THE EMPTYNESS OF
| NAGGUM SKULL !
Your pain will soon be over. In the short time you have left among the
living, you could do something you can enjoy, or you can continue to
scream in agony in front of your computer, but then again, you had that
choice all your life, and then you begin posting to comp.lang.lisp.
///
--
On Thu, 03 Jan 2002 22:42:17 +0000, Jean-François Brouillet
<·····@mac.com> wrote:
>Naggum: GO HOME! take a vacation! KILL YOURSELF! leave us alone.
>I am fed-up! I want to learn. NOT READ ABOUT THE EMPTYNESS OF
>NAGGUM SKULL !
>GO AWAY
Actually, Erik has been through many rounds of this sort of flaming.
His usual response is to get nastier and nastier and more and more
vitriolic until you are forced off the news group.
It may be more worthwhile to ignore him or kill file him.
He really is not worth the effort it takes to dislike him.
He is probably a lonely old man with no friends or family who
deserves our pity.
Don't waste your time on him.
"israel r t" wrote:
> Actually, Erik has been through many rounds of this sort of flaming.
> [...]
> He is probably a lonely old man with no friends or family who
> deserves our pity.
>
> Don't waste your time on him.
Point taken.
But I will probably indulge myself in my daily banner posting
each time he aggresses someone.
BTW: I've no clue how technically a newsgroup can become
moderated. Anyone knows?
--
Jean-Fran�ois Brouillet
In article <···················@mac.com>, Jean-Fran�ois Brouillet wrote:
>BTW: I've no clue how technically a newsgroup can become
>moderated. Anyone knows?
If this newsgroup were moderated, you would disappear. However, Erik
would not. So, you are effectively wishing for your own annihilation
from the newsgroup, in favor of your opponent du jour. :)
YANC
(Yet Another Naggum Clone)
I'm close to despair.
Please, read carefully the threads you reply to, otherwise, you
will be seen as someone who prefers to write than to read, to
throw invectives rather than gathering understanding.
For the record, I've been monitoring comp.lang.lisp for about
7 years now, though I've only recently decided to take lisp more
seriously. That's why:
- I've stayed a *lurker* for so long (and I intend to do so unless
I've something to provide/request)
- I hate that behavior which consist at denying the questions and
even questionning the mental state of the person making the request.
That's why I don't like _most_ of Naggum's posts.
To reply to your particularly thopughtless remark, if the group
was moderated, none of Naggum's rants would be accepted (only his
interesting contributions would go through) and I wouldn't even need
to try to remind him that not everyone feels OK with the kind
of put-offs he sends to people.
I would, then, stay a happy lurker, until such time, if ever, when
I have something to say.
Can _you_ understand that point?
--
Jean-Fran�ois Brouillet
On 4/1/02 8:04, in article ·······················@news3.calgary.shaw.ca,
"Kaz Kylheku" <···@accton.shaw.ca> wrote:
> In article <···················@mac.com>, Jean-Fran�ois Brouillet wrote:
>> BTW: I've no clue how technically a newsgroup can become
>> moderated. Anyone knows?
>
> If this newsgroup were moderated, you would disappear. However, Erik
> would not. So, you are effectively wishing for your own annihilation
> from the newsgroup, in favor of your opponent du jour. :)
Jean-Fran�ois Brouillet <·····@mac.com> writes:
> YANC
>
> (Yet Another Naggum Clone)
[...]
> Can _you_ understand that point?
>
Can _you_ understand that not everyone who agrees with Erik Naggum at
some times is not a clone of him? (`clone' here meaning an exact
duplicate of something)
> --
> Jean-Fran�ois Brouillet
>
>
> On 4/1/02 8:04, in article ·······················@news3.calgary.shaw.ca,
> "Kaz Kylheku" <···@accton.shaw.ca> wrote:
>
>> In article <···················@mac.com>, Jean-Fran�ois Brouillet wrote:
>>> BTW: I've no clue how technically a newsgroup can become
>>> moderated. Anyone knows?
>>
>> If this newsgroup were moderated, you would disappear. However, Erik
>> would not. So, you are effectively wishing for your own annihilation
>> from the newsgroup, in favor of your opponent du jour. :)
>
--
BPT <···@tunes.org> /"\ ASCII Ribbon Campaign
backronym for Linux: \ / No HTML or RTF in mail
Linux Is Not Unix X No MS-Word in mail
Meme plague ;) ---------> / \ Respect Open Standards
> > We don't _need_ Naggum.
>
> (decf we)
(eval +)
--
Edward O'Connor
···@oconnor.cx
If you are concerned about netiquette, you are either concerned about
your own and _follow_ good netiquette, or you are concerned about
others and _violate_ good netiquette by bothering people with your
"concern", as the only person whose netiquette you can affect is
precisely _yourself_.
-- Erik Naggum, in c.l.l
On Thu, 03 Jan 2002 15:55:56 GMT, Erik Naggum <····@naggum.net> wrote:
>| Why Naggum thinks that [...]
>
> I did not think that. That you think so based on my response is _very_
> interesting. You are not smart enough to understand that you were
> deliberately tricked into revealing your real position and purpose with a
> response that would feel hostile only if _you_ were a bad person. Thank
> you for choosing the kind of response that leaves no doubt about you.
Try olanzapine 20 mgs daily
http://www.priory.com/focus3.htm
Jean-Fran�ois Brouillet <·····@mac.com> writes:
> On 2/1/02 10:12, in article ················@naggum.net, "Erik Naggum"
> <····@naggum.net> wrote:
>
>> * Jean-Fran�ois Brouillet <·····@mac.com>
>> | Only an arrogant moron, living in a loser country could utter such loser
>> | sentences. If that half brain that this lower life has rented were still
>> | half working [we're talking 25% of full regime here, if you can't do the
>> | math yourself] we would be spared such loser posts which don't bring any
>> | value _at all_ to that thread.
>> :
>> | --
>> | Jean Fran�ois Brouillet
>> | ^
>> | +--- this letter is called "Fuck You! Loser"
>>
>> What an _interesting_ display of personality problems. Get help, OK?
>
> Why Naggum thinks that my renaming of the "c" with "cedilla" letter
> as an attack against Naggum himself is any _interesting_ at all is pure
> mystery to me.
>
> Why would attacking Naggum be _interesting_ ? To whom ?
>
> If attacking Naggum only came from the "bile-overflow" department, then
> people may sympathise, but then simply move on. Is Naggum such an important
> <plug-some-emphatic-title> that the whole 21st century has to be grateful
> forever for having been blessed by the smallest Naggum thought?
>
> | Naggun standard canned reply to this is going to be along the
> | lines that _I_ need medical treatment because _I_'m exposing
> | personality disorders. And saying <whatever, your-call> about
> | him is simply a sign of me being <brain-under-powered> or whatever
> | he fancies those days.
> |
> | Isn't this entire Naggum-thing pathetic?
>
> Naggum, of all your posts, about 10% have real value. And I mean _real_.
> Unfortunatenly, the other 90% is utter non-sense, bullshitting arrogance
> of the clever among the cleverest who deigns blessing the poor crowd
> with his infinite wisdom.
>
> Naggum, enough is too much. There are real contributors to c.l.l, and
> your signal/noise ratio is way too low. Nobody _cares_ about how you
> feel, and whether such sub-population deserves to live/die/flourish/perish
> according to St Naggum.
>
> Make us a favor: give us a break: stop posting 10 times a day to c.l.l
^^ ^^
You could at least not imply that everyone agrees with you. Many
people do not (even though I, at least, disagree with his opinions on
languages and internationalization).
> (as if you had no other useful work to do). By restraining yourself to
> core issues, and avoiding raw, unwarranted, blunt, uncalled-for opinions
> you will contribute to making c.l.l a better place.
>
> I, for one, would have happily carried on lurking c.l.l for quite a while
> if it werent' for this and the previous message.
>
>> Get help, OK?
>
> How much do I owe you, Doctor, for such an amazing diagnostic?
> Do you accept Euros ?
>
>> ///
>
> --
> Jean-Fran�ois Brouillet
>
--
BPT <···@tunes.org> /"\ ASCII Ribbon Campaign
backronym for Linux: \ / No HTML or RTF in mail
Linux Is Not Unix X No MS-Word in mail
Meme plague ;) ---------> / \ Respect Open Standards
Jean-Fran�ois Brouillet wrote:
> Jochen Schmidt
>
> # My English is far from being good, but I finally came to the opinion
> # that I don't see German the language as very important.
>
> I would agree too...if my native language were German that is ;-)
> It turns out that my English is far better, and that my French is near
> perfection. If I had more time, I would certainly learn more winner
> languages (Russian and Arabic spring to mind).
It is nice for you if you think that your English is far better (than
what?). I don't choose languages I want to learn because they are
understood as "winner languages" - if that would be the case I would never
have a chance to learn french...
But seriously - I don't think there are any "winner languages" at all - I
really hope that your attitude is not very common anymore in your country.
(And I'm glad to know some people from french who support my hopes)
Languages and the corresponding cultures are tightly coupled - therefore I
choose languages of cultures that I find interesting. Until now my plans
for the next language I want to learn as soon as I find the time are either
Chinese (Mandarin) or Japanese.
I furthermore think that it is common to learn the language of the country
were you live - regardless if the country is a "winner" or if the people
speak a "winner language".
There is only one country in Europe that demands from other countries to
learn their native language at the european parliament (and it is not
Germany).
I'm quite happy that those ugly nationalistic attitudes widely disappeared
in Germany many years ago...
> # More and more often I catch me that I at least partially think
> # in English
>
> No you don't. Only mono-linguists can argue they do, until proven wrong.
To bad for you that you never experienced it before...
> When you utter some sentence (in any language) you know, ahead of the
> words coming out of your mouth, what the sentence is going to affirm.
> (that is, unless you are a politician of course ;-). Yet those words
> that will appear in the near future, are not _verbalized_ yet, and are
> only _translated_ to your utterance language as your tongue makes some
> progress.
This may be true - but it is a difference if it is translated directly to
English or if it is translated to German and after that translated from
that to English...
> While, according to Bergson, the language is the support of the thought,
> it is _not_ the thought itself, even though a given language _shapes_ the
> way you think.
Yes _your_ thoughts are not well materialized in a specific language - not
in your mind and not much more if they are spoken out - but probably you
will somedays realize that it is not because of a language problem...
> Multiplying the languages you know can only give you more perspectives,
> and ways of thinking. Reducing their number can only lead you to an
> impoverished mental landscape, where entire areas of human thought will
> simply never flourish.
>
> Finally, this idea that a given language has "won" is utter non-sense.
> French had "won" two centuries ago. Where is it today? Give me a break
> and go by some more brain cells. At any point in time, there is a dominant
> language. Latin two thousand years ago, Chinese in the next decade. And
> so what?
Your nearly perfect English skills may have led you on the wrong road if
you think that I said that I have the idea that any language has "won" or
that it is not worth to learn more languages. I said that I by myself
actuallyprefer to read English literature (instead of German translations
of them!) out of practical reasons and because I like the language. I
prefer to not generalize from me about others - I can only speak for myself.
> So what?
>
> The issue is that way too often, this kind of decision (whether and how
> to support non dominant languages) is left to computer specialists, the
> vast majority of whom are _anything else_ illiterate. This includes art,
> poetry, literature, and most forms of human expressions that do not appeal
> to those "computer morons".
As I already said - _I_ do not generalize from me about others...
> If a shoe helps you walk, a computer is meant to help you think. No matter
> what uneducated, university degrees loaded psychopaths would love you to
> believe.
>
> "Ouf! Depuis le temps que j'attendais �a, je me suis pay� le Naggum!"
And I finally realize that it was probably not worth the time for an
answer...
> Jean Fran�ois Brouillet
> ^
> +--- this letter is called "Fuck You! Loser"
The "�" wow - and you speak about people being illiterate...
Grow up...
ciao,
Jochen Schmidt
--
http://www.dataheaven.de
In article <···················@mac.com>, Jean-Fran�ois Brouillet wrote:
>"Ouf! Depuis le temps que j'attendais �a, je me suis pay� le Naggum!"
>
>--
>Jean Fran�ois Brouillet
> ^
> +--- this letter is called "Fuck You! Loser"
That's what you *think* it says, but to me, it spells: ``I'm an idiot
who doesn't understand that one must use only ASCII when posting to
English-language Usenet newsgroups, both in the body and headers''.
You might think that the glyph produced by this character is the
letter c with a diacritical mark under it known as a cedilla.
But on my terminal, it produces a little picture of a donkey.
If I were reading a French newsgroup, I would, of course, rectify that.
·········@nahoo.de (Janosch Zwerensky) writes:
> >>(defun coll-step (n)
> >> (if (= (mod n 2) 0) (/ n 2) (+ 1 (* 3 n))))
> >
> >Why not use EVENP here?
>
> Using evenp here doesn't hurt nor help, performancewise, here. I agree though
> that evenp looks more natural.
>
> >Did you remember to compile it?
> Of course I did. I might have little experience with lisp so far,
> but I am not stupid.
Can you tell a bit more about what you did to accomplish this? I'm
not usually considered stupid, either, but have made the mistake of
_believing_ I was running a compiled copy, when reality was that I
wasn't...
Some mistakes are regrettably easy to make, and if you think I'm
calling you "stupid," the moniker would have to apply just as much to
myself...
> Still, the program seems to be around 10 times slower than an
> algorithmically equivalent C program, which is a larger speed loss
> than what I would have expected just from Lisp doing BigInteger
> arithmetics vs. the long long int calculations one does in C.
I'd hope for a smaller factor than 10 for this, though I'd not expect
1...
--
(concatenate 'string "cbbrowne" ·@acm.org")
http://www.ntlug.org/~cbbrowne/x.html
"It's a pretty rare beginner who isn't clueless. If beginners weren't
clueless, the infamous Unix learning cliff wouldn't be a problem."
-- david parsons
From: Janosch Zwerensky
Subject: Re: Beginner question: performance problems with a simple program
Date:
Message-ID: <a0fukq$cv3$04$1@news.t-online.com>
Hi,
>Can you tell a bit more about what you did to accomplish this? I'm
>not usually considered stupid, either, but have made the mistake of
>_believing_ I was running a compiled copy, when reality was that I
>wasn't.
If you're saying here that ACL doesn't necessarily compile a lisp program
when one tells it to do just that, I *might* be guilty of having done such a
mistake. I wouldn't be sad if that were the case, since I'd probably get a
good performance boost then by finally doing a compilation ;).
Still, my lisp read-eval-print-loop says the functions I'm loading are
compiled functions indeed.
..
>
>Some mistakes are regrettably easy to make, and if you think I'm
>calling you "stupid," the moniker would have to apply just as much to
>myself...
I agree it was stupid of me to use the word "stupid" in that context.
>I'd hope for a smaller factor than 10 for this, though I'd not expect
>1...
The really bad thing is that this factor of ten seems to go up when you
increase the values given to max-lst. Probably I'm doing something badly
wrong thus.. :(
Regards,
Janosch.
From: Erik Naggum
Subject: Re: Beginner question: performance problems with a simple program
Date:
Message-ID: <3218471295676491@naggum.net>
* Janosch Zwerensky
| The program works fine, except for the fact that I am not feeling well
| about its performance speed-wise. Does anyone on this group have any
| tips to offer regarding improvements in this respect? (I am working with
| Allegro Common Lisp).
Evaluate (excl::explain-compiler-settings) and turn on the various
:explain options. The amount of output even exceeds CMUCL at its worst,
but it can be very helpful in realizing when and how to declare stuff.
What were the types of variables in the C version? How much time does a
function call usually take? Do you have an example?
///
--
The past is not more important than the future, despite what your culture
has taught you. Your future observations, conclusions, and beliefs are
more important to you than those in your past ever will be. The world is
changing so fast the balance between the past and the future has shifted.
From: Janosch Zwerensky
Subject: Re: Beginner question: performance problems with a simple program
Date:
Message-ID: <a0fvaj$bah$03$1@news.t-online.com>
Hi,
> (...)
> What were the types of variables in the C version? How much time does a
> function call usually take? Do you have an example?
First, here's the C program I used:
#include <stdio.h>
int main(void)
{ long int nmax=0;
int new_max = 0;
long long a, amax = 0;
scanf("%d",&nmax);
for (int n = 3; n <= nmax; n=n+4)
{
a = n;
while (a >= n)
{
if (a&1)
{
a = 3*a + 1;
if (a > amax)
{
amax = a;
if (!new_max) new_max = 1;
}
}
else
{
a = a >> 1;
}
}
if (new_max)
{
new_max = 0;
printf("%d : %e\n", n, (double) amax);
}
}
return 0;
}
On my machine and compiled with lcc-win32, this takes around 0.6 seconds to do
the equivalent of evaluating max-lst(1000000), which in turn takes just under 6
seconds on my machine under allegro common lisp. The number type I'm using in C
is long long, which happens to go just high enough for this application and
reasonable input values.
Regards,
Janosch.
From: Barry Margolin
Subject: Re: Beginner question: performance problems with a simple program
Date:
Message-ID: <5CLW7.10$Ip1.36718@burlma1-snr2>
In article <···············@news.t-online.com>,
Janosch Zwerensky <·········@nahoo.de> wrote:
>Hi,
>
>> (...)
>> What were the types of variables in the C version? How much time does a
>> function call usually take? Do you have an example?
>
>First, here's the C program I used:
What happens if you do a more straight-forward translation into Lisp,
i.e. use iteration rather than recursion? Or what happens if you recode
the C program to use lots of separate functions and recursion, rather than
a single function with iteration?
If the recursion gets very deep, you could be taking more page faults on
the stack. Iterative solutions don't have this problem. Are you assuming
tail-recursion elimination in the Lisp version? Lisp isn't Scheme, and
many Lisp implementations don't do tail-call optimization, or they only do
them with specific optimization settings enabled.
>On my machine and compiled with lcc-win32, this takes around 0.6 seconds to do
>the equivalent of evaluating max-lst(1000000), which in turn takes just under 6
>seconds on my machine under allegro common lisp. The number type I'm using in C
>is long long, which happens to go just high enough for this application and
>reasonable input values.
There's a big difference between C's long-long arithmetic and Lisp's bignum
arithmetic. Lisp has to be prepared for the values to get arbitrarily
large, so it has to use more general algorithms that can handle any
length. C can generate much simpler code because it knows exactly how many
bytes the long-long values take up. It's hard to avoid some extra overhead
from this generality, although a factor of 10 seems unlikely.
What happens if you change both programs to use double-precision floating
point?
Maybe it's a combination of the bignum arithmetic and the recursion
vs. iteration difference.
--
Barry Margolin, ······@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
From: Janosch Zwerensky
Subject: Re: Beginner question: performance problems with a simple program
Date:
Message-ID: <a0g2mr$jcv$07$1@news.t-online.com>
Hi,
>If the recursion gets very deep, you could be taking more page faults on
>the stack. Iterative solutions don't have this problem. Are you assuming
>tail-recursion elimination in the Lisp version?
Yes, I did assume that. If lisp doesn't do this here, I indeed ought to have a
problem. I will build a more iterative version of my lisp program and see if
and what happens :).
Thanks anyway for bringing up this point!
>There's a big difference between C's long-long arithmetic and Lisp's bignum
>arithmetic.
I'm aware of that and for that reason alone I wouldn't be surprised if Lisp
would be significantly slower for this problem than C. Still, a factor of ten
seemed (possibly) excessive to me if nothing else went wrong.
>
>What happens if you change both programs to use double-precision floating
>point?
I already tried it for the Lisp program, and it didn't help much,
performance-wise. Could it be the case that Lisp is converting those doubles to
bignums when doing the evenp test? If so, I could imagine that this might be
time-consuming.
Anyway, I will try to see what happens to the C program if I have it compute
with doubles.
Thanks again for all that input,
Janosch.
·········@nahoo.de (Janosch Zwerensky) writes:
> Hi,
>
> >If the recursion gets very deep, you could be taking more page faults on
> >the stack. Iterative solutions don't have this problem. Are you assuming
> >tail-recursion elimination in the Lisp version?
>
> Yes, I did assume that. If lisp doesn't do this here, I indeed ought
> to have a problem. I will build a more iterative version of my lisp
> program and see if and what happens :). Thanks anyway for bringing
> up this point!
>
> >There's a big difference between C's long-long arithmetic and Lisp's bignum
> >arithmetic.
>
> I'm aware of that and for that reason alone I wouldn't be surprised
> if Lisp would be significantly slower for this problem than
> C. Still, a factor of ten seemed (possibly) excessive to me if
> nothing else went wrong.
I'd expect a Lisp version to run very close to C, so, yes, this is
excessive.
> >What happens if you change both programs to use double-precision floating
> >point?
>
> I already tried it for the Lisp program, and it didn't help much,
> performance-wise. Could it be the case that Lisp is converting those
> doubles to bignums when doing the evenp test? If so, I could imagine
> that this might be time-consuming. Anyway, I will try to see what
> happens to the C program if I have it compute with doubles. Thanks
> again for all that input,
CL's evenp is only defined for integers, for obvious reasons (is
5.999999999 even?).
Anyway, I rewrote your program using LOOP and type declarations:
(defun iterative-max-list (range)
(declare (type (unsigned-byte 64) range))
(flet ((coll-max (a)
(loop for n of-type (unsigned-byte 64) = a
then (if (evenp n) (floor n 2) (1+ (* 3 n)))
for b of-type (unsigned-byte 64) = n then (max b n)
until (< n a)
finally (return (max b n)))))
(loop with max of-type (unsigned-byte 64) = (coll-max 3)
for n of-type (unsigned-byte 64) from 3 to range by 4
for am of-type (unsigned-byte 64) = max then (coll-max n)
when (> am max)
do (princ (list n am))
(setf max am)
finally (return max))))
I compiled both versions in CMUCL with
(optimize (speed 3) (safety 1) (compilation-speed 0) (space 0))
and your C version with gcc.
On my Celeron 500 under linux:
"echo 1000000 | ./max_list", compiled with gcc -O
Min: 0.273s
Max: 0.721s
Mean: 0.48250000000000004s
"echo 1000000 | ./max_list", compiled with gcc -O3
Min: 0.45s
Max: 0.628s
Mean: 0.5326s
(iterative-max-list 1000000)
Min: 0.84s
Max: 0.85s
Mean: 0.85s
(max-lst 1000000)
Min: 2.14s
Max: 2.17s
Mean: 2.17s
Each test was run 11 times, and only counted the last 10 runs. So,
counting only the best versions in C and Lisp:
Min: 311.11% of C
Max: 118.06% of C
Mean: 177.08% of C
It could be better, but it's not too bad. And certainly better than
1000% :-). Also, changing that type declaration to integer instead of
(unsigned-byte 64) runs at 150% of the long-long-equivalent version,
which is an option you don't have in C :-). Also, be sure to bind
*print-pretty* to nil when you run the Lisp version or it might spend
a lot of time formatting its output.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: Janosch Zwerensky
Subject: Re: Beginner question: performance problems with a simple program
Date:
Message-ID: <a0hrq5$3ku$02$2@news.t-online.com>
Hi,
I've written my own iterative version of my program in the meantime. It's not
nearly as fast as yours, because I didn't put in the appropriate declarations,
but it is significantly faster than my first try nonetheless.
On my machine and under Allegro Common Lisp, your code seems to be around 3.5
times slower than the C program. I guess the difference to your measurements
can be attributed to me having used another compiler than you; I probably ought
to finally get me Linux and CMUCL ;)...
Greetings,
Janosch Zwerensky.
From: Janosch Zwerensky
Subject: Re: Beginner question: performance problems with a simple program
Date:
Message-ID: <a0isv3$nok$03$1@news.t-online.com>
Hi,
I've done a few minor changes on your program now, which seem to give a speedup
of an additional ten percent on my system :)... :
(defun iterative-max-list (range)
(declare (type (unsigned-byte 64) range))
(flet ((coll-max (a)
(let* ((b a))
(loop for n of-type (unsigned-byte 64) = a
then (if (evenp n) (floor n 2) (progn
(setf x (1+ (* 3
n)))
(setf b (max x b))
(floor x 2)))
for x of-type (unsigned-byte 64) = a
until (< n a)
finally (return (max b n))))))
(loop with max of-type (unsigned-byte 64) = (coll-max 3)
for n of-type (unsigned-byte 64) from 3 to range by 4
for am of-type (unsigned-byte 64) = max then (coll-max n)
when (> am max)
do (princ (list n am))
(setf max am)
finally (return max))))
I don't think that what I did here looks very elegant. If someone has something
better to offer, I'd be glad to see it.
Regards,
Janosch.
From: Dr. Edmund Weitz
Subject: Re: Beginner question: performance problems with a simple program
Date:
Message-ID: <u1ub7xm1.fsf@agharta.de>
·········@nahoo.de (Janosch Zwerensky) writes:
> Hi,
>
> I've done a few minor changes on your program now, which seem to give a speedup
> of an additional ten percent on my system :)... :
>
> (defun iterative-max-list (range)
> (declare (type (unsigned-byte 64) range))
> (flet ((coll-max (a)
> (let* ((b a))
> (loop for n of-type (unsigned-byte 64) = a
> then (if (evenp n) (floor n 2) (progn
> (setf x (1+ (* 3
> n)))
> (setf b (max x b))
> (floor x 2)))
> for x of-type (unsigned-byte 64) = a
> until (< n a)
> finally (return (max b n))))))
> (loop with max of-type (unsigned-byte 64) = (coll-max 3)
> for n of-type (unsigned-byte 64) from 3 to range by 4
> for am of-type (unsigned-byte 64) = max then (coll-max n)
> when (> am max)
> do (princ (list n am))
> (setf max am)
> finally (return max))))
>
> I don't think that what I did here looks very elegant. If someone has something
> better to offer, I'd be glad to see it.
I think the (FLOOR X 2) part isn't necessary (or even wrong), so it should be:
(defun iterative-max-list (range)
(declare (type (unsigned-byte 64) range))
(flet ((coll-max (a)
(let* ((b a))
(loop for n of-type (unsigned-byte 64) = a
then (if (evenp n)
(floor n 2)
(prog1
(setf x (1+ (* 3 n)))
(setf b (max x b))))
for x of-type (unsigned-byte 64) = a
until (< n a)
finally (return (max b n))))))
(loop with max of-type (unsigned-byte 64) = (coll-max 3)
for n of-type (unsigned-byte 64) from 3 to range by 4
for am of-type (unsigned-byte 64) = max then (coll-max n)
when (> am max)
do (princ (list n am))
(setf max am)
finally (return max))))
Edi.
From: Dr. Edmund Weitz
Subject: Re: Beginner question: performance problems with a simple program
Date:
Message-ID: <m38zbmakg9.fsf@bird.agharta.de>
···@agharta.de (Dr. Edmund Weitz) writes:
> I think the (FLOOR X 2) part isn't necessary (or even wrong), so it
> should be:
>
> (defun iterative-max-list (range)
> (declare (type (unsigned-byte 64) range))
> (flet ((coll-max (a)
> (let* ((b a))
> (loop for n of-type (unsigned-byte 64) = a
> then (if (evenp n)
> (floor n 2)
> (prog1
> (setf x (1+ (* 3 n)))
> (setf b (max x b))))
> for x of-type (unsigned-byte 64) = a
> until (< n a)
> finally (return (max b n))))))
> (loop with max of-type (unsigned-byte 64) = (coll-max 3)
> for n of-type (unsigned-byte 64) from 3 to range by 4
> for am of-type (unsigned-byte 64) = max then (coll-max n)
> when (> am max)
> do (princ (list n am))
> (setf max am)
> finally (return max))))
Or maybe
(defun iterative-max-list (range)
(declare (type (unsigned-byte 64) range))
(loop with max of-type (unsigned-byte 64) = 0
for a of-type (unsigned-byte 64) from 3 to range by 4
for am of-type (unsigned-byte 64) = max
then (let ((n a))
(declare (type (unsigned-byte 64) n))
(loop if (evenp n)
do (setq n (floor n 2))
else
maximize (setq n (1+ (* 3 n)))
until (< n a)))
when (> am max)
do (princ (list a
(setf max am)))
finally (return max)))
or, if you're only interested in the maximum value,
(defun iterative-max-list (range)
(declare (type (unsigned-byte 64) range))
(loop for a of-type (unsigned-byte 64) from 3 to range by 4
for am of-type (unsigned-byte 64) = 0
then (let ((n a))
(declare (type (unsigned-byte 64) n))
(loop if (evenp n)
do (setq n (floor n 2))
else
maximize (setq n (1+ (* 3 n)))
until (< n a)))
maximize am))
I have to add that I wasn't able to get ratios as good as Thomas
F. Burdick's on my machine (CMUCL 18c, P3 850, 256 MB RAM, Linux
2.4.10) - even with the same compilation options and with
*PRINT-PRETTY* set to NIL. The C program - compiled with -O3 - was
about 3 times as fast. If I compared the last version with a modified
C program that also only prints the final result it got even worse:
The C program was about 5 to 6 times as fast as CMUCL.
On the other hand, CMUCL was significantly faster than AllegroCL, ECL,
or LispWorks - which didn't surprise me very much...
Edi.
···@agharta.de (Dr. Edmund Weitz) writes:
> ···@agharta.de (Dr. Edmund Weitz) writes:
>
> > I think the (FLOOR X 2) part isn't necessary (or even wrong), so it
> > should be:
> >
> > (defun iterative-max-list (range)
> > (declare (type (unsigned-byte 64) range))
> > (flet ((coll-max (a)
> > (let* ((b a))
> > (loop for n of-type (unsigned-byte 64) = a
> > then (if (evenp n)
> > (floor n 2)
> > (prog1
> > (setf x (1+ (* 3 n)))
> > (setf b (max x b))))
> > for x of-type (unsigned-byte 64) = a
> > until (< n a)
> > finally (return (max b n))))))
> > (loop with max of-type (unsigned-byte 64) = (coll-max 3)
> > for n of-type (unsigned-byte 64) from 3 to range by 4
> > for am of-type (unsigned-byte 64) = max then (coll-max n)
> > when (> am max)
> > do (princ (list n am))
> > (setf max am)
> > finally (return max))))
>
> Or maybe
>
> (defun iterative-max-list (range)
> (declare (type (unsigned-byte 64) range))
> (loop with max of-type (unsigned-byte 64) = 0
> for a of-type (unsigned-byte 64) from 3 to range by 4
> for am of-type (unsigned-byte 64) = max
> then (let ((n a))
> (declare (type (unsigned-byte 64) n))
> (loop if (evenp n)
> do (setq n (floor n 2))
> else
> maximize (setq n (1+ (* 3 n)))
> until (< n a)))
> when (> am max)
> do (princ (list a
> (setf max am)))
> finally (return max)))
>
> or, if you're only interested in the maximum value,
>
> (defun iterative-max-list (range)
> (declare (type (unsigned-byte 64) range))
> (loop for a of-type (unsigned-byte 64) from 3 to range by 4
> for am of-type (unsigned-byte 64) = 0
> then (let ((n a))
> (declare (type (unsigned-byte 64) n))
> (loop if (evenp n)
> do (setq n (floor n 2))
> else
> maximize (setq n (1+ (* 3 n)))
> until (< n a)))
> maximize am))
BTW, when reading this, I just noticed that range and a are both
fixnums. Of course, that will probably only make a couple percent
difference.
> I have to add that I wasn't able to get ratios as good as Thomas
> F. Burdick's on my machine (CMUCL 18c, P3 850, 256 MB RAM, Linux
> 2.4.10) - even with the same compilation options and with
> *PRINT-PRETTY* set to NIL. The C program - compiled with -O3 - was
> about 3 times as fast. If I compared the last version with a modified
> C program that also only prints the final result it got even worse:
> The C program was about 5 to 6 times as fast as CMUCL.
For whatever reason, CMUCL seems to emit really good code (relative to
gcc) for my Celeron. I have no idea if CMUCL's code is for whatever
reason especially well optimized for Celerons or if gcc is especially
bad with them.
> On the other hand, CMUCL was significantly faster than AllegroCL, ECL,
> or LispWorks - which didn't surprise me very much...
Yeah, Python really shines when it goes to work on numeric code. If
it new how to open code a few operations on 64-bit words (say as a
pair of 32-bit words), it could probably do a lot better here.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: Raymond Toy
Subject: Re: Beginner question: performance problems with a simple program
Date:
Message-ID: <3C2DE5C8.8050200@telocity.com>
Thomas F. Burdick wrote:
>
> For whatever reason, CMUCL seems to emit really good code (relative to
> gcc) for my Celeron. I have no idea if CMUCL's code is for whatever
> reason especially well optimized for Celerons or if gcc is especially
> bad with them.
CMUCL doesn't know anything about the different flavors of x86
processors. The generated code is the same for all them. The only
difference would be in the C part of CMUCL, which probably isn't really
exercised by the code above (except for GC).
Ray
From: Janosch Zwerensky
Subject: Re: Beginner question: performance problems with a simple program
Date:
Message-ID: <a0k0hi$hkd$00$1@news.t-online.com>
Hi,
>I have to add that I wasn't able to get ratios as good as Thomas
>F. Burdick's on my machine (CMUCL 18c, P3 850, 256 MB RAM, Linux
>2.4.10) - even with the same compilation options and with
>*PRINT-PRETTY* set to NIL. The C program - compiled with -O3 - was
>about 3 times as fast.
with this version of the C program:
#include <stdio.h>
int main(void)
{ long int nmax=0;
int new_max = 0;
long long a, amax = 0;
nmax=1000000;
// scanf("%d",&nmax);
for (int n = 3; n <= nmax; n=n+4)
{
a = n;
while (a >= n)
{
if (a&1)
{
a = 3*a + 1;
if (a > amax)
{
amax = a;
if (!new_max) new_max = 1;
}
a=a >> 1; }
else
{
a = a >> 1;
}
}
if (new_max)
{
new_max = 0;
printf("%d : %e\n", n, (double) amax);
}
}
return 0;
}
compiled with lcc-win32, I get a ratio of just under five versus the version of
the lisp program I posted recently (I get a runtime of 0.5 seconds on my
machine for C vs. 2.35 seconds for Lisp).
What do you get here with CMUCL?
Regards,
Janosch.
From: Janosch Zwerensky
Subject: Re: Beginner question: performance problems with a simple program
Date:
Message-ID: <a0kdku$6fs$07$1@news.t-online.com>
Hi again,
I just compared the two programs again, doing the equivalent of evaluating
(iterative-max-list 100000000) in both Lisp and C. I get runtimes of 746
seconds for Lisp versus 33.5 seconds for C, which is a 22:1 disadvantage for
Lisp :(...
Regards,
Janosch.
From: Erik Naggum
Subject: Re: Beginner question: performance problems with a simple program
Date:
Message-ID: <3218634538190945@naggum.net>
* Janosch Zwerensky
| I just compared the two programs again, doing the equivalent of
| evaluating (iterative-max-list 100000000) in both Lisp and C. I get
| runtimes of 746 seconds for Lisp versus 33.5 seconds for C, which is a
| 22:1 disadvantage for Lisp :(...
Do they return the same results? It may sound like a stupid question,
but you would probably be surprised to learn hown often a C solution is
_much_ faster than a Common Lisp solution, but also very, very wrong. If
I want wrong results, I can get that far faster than 33.5 seconds. :)
I think you have run into the bignum cost in Common Lisp. Although
arbitrarily-sized integers is a major feature of the language, some
implementations have not made a particular point of making bignums very
efficient, despite the availability of very high-performance libraries.
I find this sufficiently annoying that I have complained about it several
times, but there is apparently no commercial value in fast bignums, and
since I do not want to pay for reimplementing mp libraries, nor anybody
else, it seems, nothing happens.
You could try CLISP to see if it can give you a significant performance
improvement, but I doubt that you can beat a 64-bit integer if you have
the hardware support for it. Most bignum libraries use 16- or 32-bit
"bigits" and it is hard to make that as fast as a known size.
It would have been so great if Common Lisp implementations could use
machine integers if bindings/slots, etc, were so declared, but it would
probably make garbage collection slightly harder and more expensive.
///
--
The past is not more important than the future, despite what your culture
has taught you. Your future observations, conclusions, and beliefs are
more important to you than those in your past ever will be. The world is
changing so fast the balance between the past and the future has shifted.
From: Raymond Toy
Subject: Re: Beginner question: performance problems with a simple program
Date:
Message-ID: <4nk7v5kc6j.fsf@rtp.ericsson.se>
>>>>> "Erik" == Erik Naggum <····@naggum.net> writes:
Erik> It would have been so great if Common Lisp implementations could use
Erik> machine integers if bindings/slots, etc, were so declared, but it would
Erik> probably make garbage collection slightly harder and more expensive.
But they do don't they? CMUCL certainly will use (signed-byte 32) and
(unsigned-byte 32) if so declared (or can be determined by the
compiler). Even gcl uses unboxed double-floats when so declared. I
assume ACL and Lispworks can too.
Ray
From: Janosch Zwerensky
Subject: Re: Beginner question: performance problems with a simple program
Date:
Message-ID: <a0qh0r$c7d$02$2@news.t-online.com>
> Do they return the same results?
Yes, they do.
At least if you disregard the fact that the output format of the C version
doesn't show you all digits of the results.
C's long longs seem to reach just high enough for the results to be
uncompromised.
>(...)
Regards,
Janosch.
From: Dr. Edmund Weitz
Subject: Re: Beginner question: performance problems with a simple program
Date:
Message-ID: <m3ellaj2hm.fsf@bird.agharta.de>
·········@nahoo.de (Janosch Zwerensky) writes:
> At least if you disregard the fact that the output format of the C
> version doesn't show you all digits of the results.
On my machine (glibc 2.2.4) you can use the "%lld" format with printf
and thus get all digits.
·········@nahoo.de (Janosch Zwerensky) writes:
> Hi,
>
> >I have to add that I wasn't able to get ratios as good as Thomas
> >F. Burdick's on my machine (CMUCL 18c, P3 850, 256 MB RAM, Linux
> >2.4.10) - even with the same compilation options and with
> >*PRINT-PRETTY* set to NIL. The C program - compiled with -O3 - was
> >about 3 times as fast.
>
> with this version of the C program:
{ int n;
> for (/* int */ n = 3; n <= nmax; n=n+4)
}
> compiled with lcc-win32, I get a ratio of just under five versus the
> version of the lisp program I posted recently (I get a runtime of
> 0.5 seconds on my machine for C vs. 2.35 seconds for Lisp). What do
> you get here with CMUCL?
On my machine with gcc -O3 (faster than -O this time), I compared that to:
(defun iterative-max-list (range)
(declare (fixnum range)
(optimize (speed 3) (safety 1) (compilation-speed 0) (space 0)))
(loop with max of-type (unsigned-byte 64) = 16
for i of-type fixnum = 3 then (truly-the fixnum (+ i 4))
for i^ of-type (unsigned-byte 64) = max
then (loop for j of-type (unsigned-byte 64) = i
then (if (evenp j) (floor j 2) (1+ (* 3 j)))
for jmax of-type (unsigned-byte 64) = j then (max j jmax)
until (< j i)
finally (return jmax))
until (> i range)
when (> i^ max)
do (princ (list i i^))
(setf max i^)
finally (return max)))
The Lisp runs at about 210% of the C (0.82s : 0.39s).
Okay, I'm officially tired of this game :-). Actually I was before,
but I went one more round, partially because you asked, and partially
because I hit (for the 3rd time in 2 days!) M-C-Backspace, which
really *should* kill the previous sexp, but instead force-quits
Xfree86. The worst part is that it doesn't save the Emacs desktop, so
it's a pain in the butt to get back to where I was. I really wish I
knew how to change that setting in Xfree86. I've been meaning to
investigate, but I'm worried I'll find that it's hard-coded and I'll
need to rebuild it from source. If I had my way, it would be bound to
M-A-C-S-Pause, so I couldn't possibly hit it on accident. Why on
earth do people make force-quit so easy to hit? Command-. on the Mac
also happens to be find-tag in Emacs. </vent>
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: Daniel Barlow
Subject: Re: Beginner question: performance problems with a simple program
Date:
Message-ID: <87heq9wq2d.fsf@noetbook.telent.net>
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> Okay, I'm officially tired of this game :-). Actually I was before,
> but I went one more round, partially because you asked, and partially
> because I hit (for the 3rd time in 2 days!) M-C-Backspace, which
> really *should* kill the previous sexp, but instead force-quits
> Xfree86. The worst part is that it doesn't save the Emacs desktop, so
By some bizarre twist of (probably IRC-assisted) coincidence, you're
the third person in as many days to mention that.
Option "DontZap" "boolean"
This disallows the use of the Ctrl+Alt+Backspace
sequence. That sequence is normally used to termi�
nate the X server. When this option is enabled,
that key sequence has no special meaning and is
passed to clients. Default: off.
From XF86Config-4(5x) on my Debian system. HTH
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
From: Alain Picard
Subject: OT [Re: Beginner question: performance problems with a simple program]
Date:
Message-ID: <86u1u8s7ed.fsf_-_@gondolin.local.net>
Daniel Barlow <···@telent.net> writes:
> ···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
> > Okay, I'm officially tired of this game :-). Actually I was before,
> > but I went one more round, partially because you asked, and partially
> > because I hit (for the 3rd time in 2 days!) M-C-Backspace, which
> > really *should* kill the previous sexp, but instead force-quits
> > Xfree86. The worst part is that it doesn't save the Emacs desktop, so
>
> By some bizarre twist of (probably IRC-assisted) coincidence, you're
> the third person in as many days to mention that.
>
> Option "DontZap" "boolean"
Yes, this is a _major_ annoyance. Is the use of emacs declining?
It seems I see more and more software blithely capturing what are
valid emacs keystrokes for their own uses. [e.g. the K desktop's
window manager, and others I've given up on and no longer remember]
Philosophically, do emacs users have a "right" to not have their
keystrokes stolen thusly, since, after all, emacs predates pretty
much all of this offending software? Hmmmm.
I've started using Xmodmap games to get a Hyper and a Super bit,
at least _those_ may be safe for a while. :-)
--
It would be difficult to construe Larry Wall, in article
this as a feature. <·····················@netlabs.com>
Alain Picard wrote:
> Daniel Barlow <···@telent.net> writes:
>
>> ···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>>
>> > Okay, I'm officially tired of this game :-). Actually I was before,
>> > but I went one more round, partially because you asked, and partially
>> > because I hit (for the 3rd time in 2 days!) M-C-Backspace, which
>> > really *should* kill the previous sexp, but instead force-quits
>> > Xfree86. The worst part is that it doesn't save the Emacs desktop, so
>>
>> By some bizarre twist of (probably IRC-assisted) coincidence, you're
>> the third person in as many days to mention that.
>>
>> Option "DontZap" "boolean"
>
> Yes, this is a _major_ annoyance. Is the use of emacs declining?
> It seems I see more and more software blithely capturing what are
> valid emacs keystrokes for their own uses. [e.g. the K desktop's
> window manager, and others I've given up on and no longer remember]
>
> Philosophically, do emacs users have a "right" to not have their
> keystrokes stolen thusly, since, after all, emacs predates pretty
> much all of this offending software? Hmmmm.
>
> I've started using Xmodmap games to get a Hyper and a Super bit,
> at least _those_ may be safe for a while. :-)
Yes thats nice - I have bound all lisp oriented keystrokes (That begin with
C-M- ) to "super-" which I remapped to the left windows key - this also
solves the C-M-Backspace problem :-)
ciao,
Jochen
--
http://www.dataheaven.de
From: Martin Thornquist
Subject: Re: Beginner question: performance problems with a simple program
Date:
Message-ID: <xunu1u91q0c.fsf@fjorir.ifi.uio.no>
[ Thomas F. Burdick ]
> because I hit (for the 3rd time in 2 days!) M-C-Backspace, which
> really *should* kill the previous sexp, but instead force-quits
> Xfree86. The worst part is that it doesn't save the Emacs desktop, so
> it's a pain in the butt to get back to where I was. I really wish I
> knew how to change that setting in Xfree86. I've been meaning to
In section "ServerFlags"
Option "DontZap"
for XFree 4, or just
DontZap
for XFree 3.
Martin
--
"An ideal world is left as an exercise to the reader."
-Paul Graham, On Lisp
Martin Thornquist <············@ifi.uio.no> writes:
> [ Thomas F. Burdick ]
>
> > because I hit (for the 3rd time in 2 days!) M-C-Backspace, which
> > really *should* kill the previous sexp, but instead force-quits
> > Xfree86. The worst part is that it doesn't save the Emacs desktop, so
> > it's a pain in the butt to get back to where I was. I really wish I
> > knew how to change that setting in Xfree86. I've been meaning to
>
> In section "ServerFlags"
>
> Option "DontZap"
Thanks. I actually looked at the manual right after posting that.
I'm so much less nervous typing now :)
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: Dr. Edmund Weitz
Subject: Re: Beginner question: performance problems with a simple program
Date:
Message-ID: <m38zbmhvdt.fsf@bird.agharta.de>
·········@nahoo.de (Janosch Zwerensky) writes:
> with this version of the C program:
>
> [snip]
>
> compiled with lcc-win32, I get a ratio of just under five versus the
> version of the lisp program I posted recently (I get a runtime of
> 0.5 seconds on my machine for C vs. 2.35 seconds for Lisp). What do
> you get here with CMUCL?
All results are on a PIII 850, 256 MB RAM, Linux 2.4.10 with CMUCL
18c[1], gcc 2.95.3[2].
If I compare your C program above[3] vs. your earlier posted CMUCL
program I get
with an arg of 1,000,000: 0.12 (C) vs. 0.56 (CMUCL) secs
with an arg of 10,000,000: 0.9 (C) vs. 6.7 (CMUCL) secs
But enough Lisp bashing: It seems rather obvious to me that C wins
because it supports the 'long long' type while Lisp doesn't. This is a
nice feature and long longs can indeed get quite big, but there's
still a rather arbitrary upper limit. I think Collatz sequences are a
typical example where you really want unlimited precision arithmetic
and you want to keep your machine running for a couple of days.
I wrote a small C program[4] that uses the gmp library and changed my
earlier Lisp program by just removing the declarations[5]. The
results:
with an arg of 1,000,000: 1.6 (C) vs. 0.7 (CMUCL) secs
with an arg of 10,000,000: 12.3 (C) vs. 8.7 (CMUCL) secs
No I can sleep better... :)
DISCLAIMER: This was my first encounter with the gmp library. I hope I
haven't done anything completely inefficient and/or dumb.
Edi.
[1] with *PRETTY-PRINT* set to NIL and (OPTIMIZE (SPEED 3) (SAFETY 0)
(SPACE 0) (DEBUG 0) (COMPILATION-SPEED 0))
[2] with -O3 optimization
[3] I had to slightly change the program because gcc didn't like the
'(for int n = ...' statement.
[4] See below for the code.
[5] You decide which program looks nicer... :)
++++++++++++
(defun iterative-max-list (range)
(loop with max = 0
for a from 3 to range by 4
for am = 16
then (let ((n a))
(loop if (evenp n)
do (setq n (floor n 2))
else
maximize (setq n (1+ (* 3 n)))
until (< n a)))
when (> am max)
do (princ (list a
(setf max am)))
finally (return max)))
+++++++++++++
#include <stdio.h>
#include "gmp.h"
main (int argc, char **argv) {
mpz_t a, amax, n, nmax;
int new_max = 0;
char str[255], str2[255];
scanf("%s", str);
mpz_init_set_str(nmax, str, 10);
mpz_init(a);
mpz_init(amax);
mpz_set_ui(amax, 0);
mpz_init(n);
mpz_set_ui(n, 3);
while (mpz_cmp(n, nmax) <= 0) {
mpz_set(a, n);
while (mpz_cmp(a, n) >= 0) {
if (mpz_tstbit(a, 0)) {
mpz_mul_ui(a, a, 3);
mpz_add_ui(a, a, 1);
if (mpz_cmp(a, amax) > 0) {
mpz_set(amax, a);
new_max = 1;
}
} else {
mpz_tdiv_q_ui(a, a, 2);
}
}
if (new_max) {
new_max = 0;
printf("%s: %s\n", mpz_get_str(str, 10, n),
mpz_get_str(str2, 10, amax));
}
mpz_add_ui(n, n, 4);
}
}
From: Janosch Zwerensky
Subject: Re: Beginner question: performance problems with a simple program
Date:
Message-ID: <a0qgfp$c7d$02$1@news.t-online.com>
Hi,
>(...)
>But enough Lisp bashing: It seems rather obvious to me that C wins
>because it supports the 'long long' type while Lisp doesn't.
That's true, of course. The question left was merely by what margin C would win
here.
> This is a
>nice feature and long longs can indeed get quite big, but there's
>still a rather arbitrary upper limit. I think Collatz sequences are a
>typical example where you really want unlimited precision arithmetic
>and you want to keep your machine running for a couple of days.
Except for the part about actively *wanting* to keep the machine running for
days, no argument here ;).
>I wrote a small C program[4] that uses the gmp library and changed my
>earlier Lisp program by just removing the declarations[5].
Out of curiosity, I also removed all declarations from the so far fastest Lisp
program I had for this problem. Here is the program I got thereby:
(defun iterative-max-list (range)
(flet ((coll-max (a)
(let* ((b a))
(loop for n = a
then (if (evenp n) (floor n 2) (progn
(setf x (1+ (* 3
n)))
(setf b (max x b))
(floor x 2)))
for x = a
until (< n a)
finally (return (max b n))))))
(loop with max = (coll-max 3)
for n from 3 to range by 4
for am = max then (coll-max n)
when (> am max)
do (princ (list n am))
(setf max am)
finally (return max))))
It surprised me a lot that this program doesn't seem to be any slower than the
corresponding program with declarations. Does anybody on this group have an
explanation to offer for this?
Regards,
Janosch.
·········@nahoo.de (Janosch Zwerensky) writes:
> Hi,
>
[ Edmund Weitz: ]
> >(...)
> >But enough Lisp bashing: It seems rather obvious to me that C wins
> >because it supports the 'long long' type while Lisp doesn't.
You meant to say "while no current Lisp implementation does", of
course, right? :-)
> That's true, of course. The question left was merely by what margin
> C would win here.
>
> > This is a nice feature and long longs can indeed get quite big,
> >but there's still a rather arbitrary upper limit. I think Collatz
> >sequences are a typical example where you really want unlimited
> >precision arithmetic and you want to keep your machine running for
> >a couple of days.
>
> Except for the part about actively *wanting* to keep the machine running for
> days, no argument here ;).
>
> >I wrote a small C program[4] that uses the gmp library and changed my
> >earlier Lisp program by just removing the declarations[5].
>
> Out of curiosity, I also removed all declarations from the so far
> fastest Lisp program I had for this problem. Here is the program I
> got thereby:
>
> (defun iterative-max-list (range)
> (flet ((coll-max (a)
> (let* ((b a))
> (loop for n = a
> then (if (evenp n) (floor n 2) (progn
> (setf x (1+ (* 3
> n)))
> (setf b (max x b))
> (floor x 2)))
> for x = a
> until (< n a)
> finally (return (max b n))))))
> (loop with max = (coll-max 3)
> for n from 3 to range by 4
> for am = max then (coll-max n)
> when (> am max)
> do (princ (list n am))
> (setf max am)
> finally (return max))))
>
> It surprised me a lot that this program doesn't seem to be any
> slower than the corresponding program with declarations. Does
> anybody on this group have an explanation to offer for this?
That's easy, ACL isn't doing anything with the (unsigned-byte 64)
declarations. I'd imagine the fixnum declarations would make a tiny
bit of difference, but they don't matter in the inner loop, so, like I
said, tiny. CMUCL produces about 150% slower code with integer
declarations, and only slightly different code with no declarations at
all.
By the way, I'm not surprised that ACL doesn't do anything (or
anything much) useful with the type declarations. Their customers
benefit tremendously more from, say, simple-streams, than they would
from an equivalent effort put into super-optimizing numeric code.
After all, if you really need this as blazingly tight inner loop, you
probably want to write it in assembler, anyhow.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: Dr. Edmund Weitz
Subject: Re: Beginner question: performance problems with a simple program
Date:
Message-ID: <m3itamj2m6.fsf@bird.agharta.de>
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> > >But enough Lisp bashing: It seems rather obvious to me that C
> > >wins because it supports the 'long long' type while Lisp doesn't.
>
> You meant to say "while no current Lisp implementation does", of
> course, right? :-)
Sure... :)
From: Janosch Zwerensky
Subject: Re: Beginner question: performance problems with a simple program
Date:
Message-ID: <a0jv81$5op$03$1@news.t-online.com>
>I think the (FLOOR X 2) part isn't necessary (or even wrong), so it should be:
>
If n isn't even, x:=3n+1 must be an even number. Therefore, in this case I know
that I'm going to divide that number by two in the next step anyway and thus
doing it right away saves me an unnecessary evenp test.
Why do you think that I might have done something wrong here?
Regards,
Janosch.
From: Dr. Edmund Weitz
Subject: Re: Beginner question: performance problems with a simple program
Date:
Message-ID: <m3d70yhwj0.fsf@bird.agharta.de>
·········@nahoo.de (Janosch Zwerensky) writes:
> >I think the (FLOOR X 2) part isn't necessary (or even wrong), so it
> >should be:
>
> If n isn't even, x:=3n+1 must be an even number. Therefore, in this
> case I know that I'm going to divide that number by two in the next
> step anyway and thus doing it right away saves me an unnecessary
> evenp test. Why do you think that I might have done something wrong
> here?
Nothing wrong there. I just didn't think enough... :)
Edi.
Interesting tidbit:
I have a lisp chess program i wrote/am writing. I was refering to it
on the chess programmer board, and one of the other posters really
went after me for being so stupid as to program it in lisp, saying C++
would be much faster, easier to write, simpler, blah blah. In the
process he made it clear he didn't know any lisp at all. You know,
the usual.
I decided to redo a section of my lisp code in C++ to see what kind of
speed sacrifice i was making. I used C++ STL, and compiled with g++
no optimization, the lisp version with CMUCL with no optimizations.
The C++ version used vectors, the lisp version lists.
The lisp version was 30% faster.
I was blown away. I cranked up the optimizations on both versions,
-O4 in the g++ code, and (speed 3)(safety 0) in the LISP version. Now
the lisp code was only about 5% faster.
The C version was also about 50% longer and took several times longer
to write.
This makes my job ( in which i have to use PRO-C ) even more
depressing. :)
dave
From: Janosch Zwerensky
Subject: Re: Beginner question: performance problems with a simple program
Date:
Message-ID: <a12u08$r3j$02$1@news.t-online.com>
Hi,
>The lisp version was 30% faster.
>
>I was blown away. I cranked up the optimizations on both versions,
>-O4 in the g++ code, and (speed 3)(safety 0) in the LISP version. Now
>the lisp code was only about 5% faster.
>
That's interesting. How many nodes per second are you getting, and on what
machine, and what things are you doing in your eval function currently?
Regards,
Janosch.
·········@nahoo.de (Janosch Zwerensky) wrote in message news:<···············@news.t-online.com>...
> Hi,
>
> >The lisp version was 30% faster.
> >
> >I was blown away. I cranked up the optimizations on both versions,
> >-O4 in the g++ code, and (speed 3)(safety 0) in the LISP version. Now
> >the lisp code was only about 5% faster.
> >
>
> That's interesting. How many nodes per second are you getting, and on what
> machine, and what things are you doing in your eval function currently?
>
Oh. It's still *very* early. When i crank up the optimizations, it's
only about 8-10K NPS on my pentium 200, and the eval is pretty much
piece-square lookup. At this point, i am solely trying to get it to
play a correct game. I knew it was kinda slow, so doing a C++ version
of my attack function was partally to prove to myself that it's my
programming, and not the language im using. :)
This is just something i've hacked up over the past month putting in
an evening hour or two a few times a week.
I tried to do a chess program once in C and i'm getting the lisp
version knocked out **much** more quickly.
dave
On 3 Jan 2002 13:24:17 -0800, ···········@yahoo.com (David Hanley) wrote:
> I have a lisp chess program i wrote/am writing. I was refering to it
Just a reminder that CLOCC (Common Lisp Open Code Collection) includes some
chess code:
http://clocc.sourceforge.net
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://web.mclink.it/amoroso/ency/README
[http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/]
> Just a reminder that CLOCC (Common Lisp Open Code Collection) includes some
> chess code:
>
> http://clocc.sourceforge.net
Yes, i saw that, but it does a couple of things that pretty much
ensure it'll only run fast on some future hardware. It represents the
board as multiple 64 bit vectors. This is really clever, but i found
that an array of piece structures is much much much quicker. This is
one place that C has an advantage, in that most compilers have 64 bit
unsigned types. Of course, it's pretty coincidental for a 2000 year
old game to map directly into the word size of modern processors!
I thought of doing an othello game like that in C. You could make a
list of the legal moves with something like 120 non-branching
instructions executed.
dave