After a long time I am finally going through "On Lisp" as I have never been
using macros and I got the feeling from the posts on this newsgroup that "On
Lisp" is the right book to understand both the how and why of macros. (End
of Introduction)
Now while reading it I found in section "3.2 Imperative Outsied-In" on page
34 the following comment:
"The first thing we notice is the creation of y and sqr in the inital let.
This is a sign that bad thinks are to follow.
Like eval at runtime, uninitialized varables are so rarely needed that they
should be treated as a sympton of some illness in the program.
Such variables are often used like pins which hold the program down and keep
it from coiling into its natural shape."
He provides the following code as example:
--BAD--
(defun imp (x)
(let (y sqr)
(setq y (car x))
(setq sqr (expt y 2))
(list 'a sqr)))
--GOOD--
(defun imp (x)
(list 'a (expt (car x) 2))
The question is do you consider the following code as bad practice?
(defun safe-time-zone (speed deceleration &optional think-time)
(setf
deceleration (abs deceleration)
speed (abs speed)
think-time (or think-time $thinking-time))
(let* ((braking-time (/ speed $cfav deceleration))
(thinking-distance (* think-time (/ speed $cfav)))
(braking-distance (* 0.5 deceleration braking-time braking-time))
(overall-distance (+ thinking-distance braking-distance))
(safe-braking-zone (/ overall-distance (/ speed $cfav))))
(/ (fceiling safe-braking-zone 0.1) 10)))
Note $cfav is coefficient-factor-acceleration-velocity i.e. 3.6 as
acceleration is in m/s while speed is in km/h.
Should I have written it in a more functional way even though it would have
implied an extremly long one-line function?
More in general should I try to avoid the creation of middle-level utility
variables? I feel a bit in doubt as from one side I see the point of keeping
the code
elegantly simple, however I see an advantage from a readibility point of
view in not having to try to decipher long formulas in the code above it's
clear what is my idea of overall-distance in abstract but not in actual
implementation.
So just kind of wondering what has expirience tought to more proficient
programmers in this case.
One more final silly question: am I right in assuming that if I use setf I
do not have any reason to ever use setq?
(CLtL 2nd edition states regarding setq {var form}*:
"X3J13 voted in March 1989 <173> to specify that any var refers not to an
ordinary variable but to a binding
made by symbol-macrolet, then that var is handled as if setf had been used
instead of setq").
Thanks.
> (defun safe-time-zone (speed deceleration &optional think-time)
> (setf
> deceleration (abs deceleration)
> speed (abs speed)
> think-time (or think-time $thinking-time))
> (let* ((braking-time (/ speed $cfav deceleration))
> (thinking-distance (* think-time (/ speed $cfav)))
> (braking-distance (* 0.5 deceleration braking-time braking-time))
> (overall-distance (+ thinking-distance braking-distance))
> (safe-braking-zone (/ overall-distance (/ speed $cfav))))
> (/ (fceiling safe-braking-zone 0.1) 10)))
Why not like this:
(defun safe-time-zone (speed deceleration &optional think-time)
(let* ((deceleration (abs deceleration))
(speed (abs speed))
(think-time (or think-time $thinking-time))
(braking-time (/ speed $cfav deceleration))
(thinking-distance (* think-time (/ speed $cfav)))
(braking-distance (* 0.5 deceleration braking-time braking-time))
(overall-distance (+ thinking-distance braking-distance))
(safe-braking-zone (/ overall-distance (/ speed $cfav))))
(/ (fceiling safe-braking-zone 0.1) 10)))
The setf implies a change in state and you aren't really doing that.
Reading ahead, I also like Joe Marshall's suggestion (retaining your
variable names):
(defun safe-time-zone (speed deceleration &optional (think-time $thinking-time))
(let* ((deceleration (abs deceleration))
(speed (abs speed))
(braking-time (/ speed $cfav deceleration))
(thinking-distance (* think-time (/ speed $cfav)))
(braking-distance (* 0.5 deceleration braking-time braking-time))
(overall-distance (+ thinking-distance braking-distance))
(safe-braking-zone (/ overall-distance (/ speed $cfav))))
(/ (fceiling safe-braking-zone 0.1) 10)))
It's OK to have intermediate variables for readability's sake.
Sometimes it can also help debuggability.
Stylistically the preference is to use
1) let if you can,
2) let* if you must, and
3) setf when you are actually changing state in an enclosing scope.
Another stylistic approach is to write little functions, especially if
you might use them more than once:
(defconstant $cfav 3.6
"Allows conversion between meters per second and kilometers per
hour.")
(defconstant $thinking-time .75
"Default thinking time in seconds.")
(defun brake-time (speed deceleration)
(/ speed $cfav deceleration))
(defun brake-zone (speed distance)
(/ distance (/ speed $cfav)))
(defun think-time-to-think-distance (time speed)
(* time (/ speed $cfav)))
(defun braking-distance (deceleration time)
(* 0.5 deceleration time time))
;; The idea below is that maybe you have a canonical "left-to-right"
;; model and you want to be able to handle going either direction,
;; say, to deal with head-on collisions.
(defun normalize (quantity)
(abs quantity))
;; I'm assuming you want your returned value to have a fixed number of
;; significant digits past the decimal point.
(defun convert-to-precision (quantity)
(/ (fceiling quantity 0.1) 10))
(defun safe-time-zone (speed deceleration &optional (think-time $thinking-time))
(let* ((speed (normalize speed))
(deceleration (normalize deceleration))
(braking-time (brake-time speed deceleration))
(thinking-distance (think-time-to-think-distance think-time speed))
(braking-distance (braking-distance deceleration braking-time))
(overall-distance (+ thinking-distance braking-distance))
(safe-braking-zone (brake-zone speed overall-distance)))
(convert-to-precision safe-braking-zone)))
The point of doing this is, first, it's often more readable and
self-documenting, second, it's easier to think about what you're doing
if it comes in bite-sized chunks, and finally it can make debugging
easier because you can trace the functions. Some compilers, such as
CMUCL, will allow you to declare the functions inline and thereby
avoid a performance penalty for this style of programming.
You also ask if setf is a complete replacement for setq, and that's
the case, though some like to retain setq as a marker for setting
variables instead of "places". But since setf has no efficiency
penalty for the variable case, I've gravitated to setf, probably more
out of laziness than anything else.
--
Fred Gilham ······@csl.sri.com
99% of lawyers give the rest a bad name. -- Steve Wright
"Rmagere" <·······@*the-mail-that-burns*.*figure-it-out*> wrote in message news:<············@news.ox.ac.uk>...
> He provides the following code as example:
> --BAD--
> (defun imp (x)
> (let (y sqr)
> (setq y (car x))
> (setq sqr (expt y 2))
> (list 'a sqr)))
>
> --GOOD--
> (defun imp (x)
> (list 'a (expt (car x) 2))
False dichotomy; there is also this possibility which eliminates the
assignment:
(let* ((y (car x))
(sqr (expt y 2))
(list 'a sqr))
> The question is do you consider the following code as bad practice?
>
> (defun safe-time-zone (speed deceleration &optional think-time)
> (setf
>
> deceleration (abs deceleration)
>
> speed (abs speed)
>
> think-time (or think-time $thinking-time))
>
> (let* ((braking-time (/ speed $cfav deceleration))
>
> (thinking-distance (* think-time (/ speed $cfav)))
>
> (braking-distance (* 0.5 deceleration braking-time braking-time))
>
> (overall-distance (+ thinking-distance braking-distance))
>
> (safe-braking-zone (/ overall-distance (/ speed $cfav))))
>
> (/ (fceiling safe-braking-zone 0.1) 10)))
Of course this is good style. You are giving meaningful names to
important quantities that are intermediate values in a larger
calculation. This makes it much easier to understand the code; you
have effectively documented how you are calculating the SAFE-TIME-ZONE
parameter.
The question is one of balance: you don't want to bind every trivial
subexpression to some variable. You just want to achieve the right
level of chunking to make it understandable.
It's similar to the commenting principles; you don't put a useless
comment to the right of every line:
(setf a (* b c)) ;; multiply b by c, store it in a, doh!
> Note $cfav is coefficient-factor-acceleration-velocity i.e. 3.6 as
> acceleration is in m/s while speed is in km/h.
>
>
>
> Should I have written it in a more functional way even though it would have
> implied an extremly long one-line function?
No, because in doing so you would lose the clarity of the
transformation from times, speeds and acceleration to distances.
> More in general should I try to avoid the creation of middle-level utility
> variables?
Absolutely not, just avoid over-generating too many useless ones which
add nothing. Quite often, the intermediate variables come straight
from the theory. I can imagine that your safe distance calculation
came from some text, and that text used the same intermediate
variables to explain the steps.
> One more final silly question: am I right in assuming that if I use setf I
> do not have any reason to ever use setq?
That is correct. SETQ is for old timers who learned Lisp before there
was SETF.
> (CLtL 2nd edition states regarding setq {var form}*:
>
> "X3J13 voted in March 1989 <173> to specify that any var refers not to an
> ordinary variable but to a binding
>
> made by symbol-macrolet, then that var is handled as if setf had been used
> instead of setq").
That's right; in other words, SETQ had to be repaired for transparency
through symbol macros. You can think of it as a special case of SETF
where the assignment place is syntactically constrained to being a
symbol.
Neither SETF nor SETQ is ``lower level'' with respect to the other.
The implementation of SETF could generate SETQ code for symbol
arguments, so that SETQ handles that case. Or it could be the other
way around: SETQ could reduce to SETF, effectively being an alternate
interface to it. Or they could both rely on some lower-level substrate
for handling assignment to bindings.
SETF is better because it's one size fits all, eliminating the need
for SET, SETQ, RPLACA and so forth. If you know how to access it, and
the possibility exists that you can store to it, SETF knows how (or
can be taught to) so you don't have to. If the machine can do work
for you, and that work takes place at compile time, don't ask any
questions, just let it! :)
From: Joe Marshall
Subject: Re: Question about Lisp Coding Style
Date:
Message-ID: <ad92axvj.fsf@ccs.neu.edu>
"Rmagere" <·······@*the-mail-that-burns*.*figure-it-out*> writes:
> After a long time I am finally going through "On Lisp" as I have never been
> using macros and I got the feeling from the posts on this newsgroup that "On
> Lisp" is the right book to understand both the how and why of macros. (End
> of Introduction)
>
> Now while reading it I found in section "3.2 Imperative Outsied-In" on page
> 34 the following comment:
> "The first thing we notice is the creation of y and sqr in the inital let.
> This is a sign that bad thinks are to follow.
> Like eval at runtime, uninitialized varables are so rarely needed that they
> should be treated as a sympton of some illness in the program.
> Such variables are often used like pins which hold the program down and keep
> it from coiling into its natural shape."
>
> He provides the following code as example:
> --BAD--
> (defun imp (x)
> (let (y sqr)
> (setq y (car x))
> (setq sqr (expt y 2))
> (list 'a sqr)))
>
> --GOOD--
> (defun imp (x)
> (list 'a (expt (car x) 2))
The reason the first is considered `bad' is that one cannot understand
small fragments of the code without considering the entire function.
Look at the subexpression (list 'a sqr). Well, we know that we'll get
a two element list, the first element being the symbol A, the second
being what... Ah, there's a binding for SQR, but it's bound to NIL?
No, wait, the meaning of SQR changes when we get to (setq sqr (expt y
2)). But Y is bound to NIL, too... oh, the meaning of Y changes in
(setq y (car x)).
In an example so small, it hardly makes a difference, but it becomes
much more important in a large programs.
> The question is do you consider the following code as bad practice?
>
> (defun safe-time-zone (speed deceleration &optional think-time)
> (setf
> deceleration (abs deceleration)
> speed (abs speed)
> think-time (or think-time $thinking-time))
> (let* ((braking-time (/ speed $cfav deceleration))
> (thinking-distance (* think-time (/ speed $cfav)))
> (braking-distance (* 0.5 deceleration braking-time braking-time))
> (overall-distance (+ thinking-distance braking-distance))
> (safe-braking-zone (/ overall-distance (/ speed $cfav))))
> (/ (fceiling safe-braking-zone 0.1) 10)))
There are some things I would change, but there is an important
difference betweeen what you have written and the `bad' example above.
The intermediate results *don't* change once they are bound. This
means I can reason about fragments of your code without having to scan
through the entire body to find out if anything got changed. So I
know, for example, that the THINKING-DISTANCE is function of the SPEED
and the THINK-TIME *only*. Since the computation of the
BRAKING-DISTANCE won't have an effect on the THINKING-DISTANCE, I can
ignore the details of that if I wish.
Now as to what I'd change...
Since think-time is optional, and since there is a default value,
you should simply use it as follows:
(defun safe-time-zone (speed deceleration &optional (think-time $thinking-time))
...)
I'd also change `$thinking-time' into `*default-thinking-time*'
I'm concerned about taking the absolute values of speed and
decelaration. This could be masking errors (for instance, if you step
on the gas instead of the brake, your `deceleration' will be negative,
yet this function will still compute a `safe time zone' where none
exists.) Better would be an explicit check:
(check-type deceleration (real 0 *))
(check-type speed (real 0 *))
Since you use the quantity (/ speed $cfav) in several places, it is
one that *ought* to be named!
(let* ((converted-speed (/ speed *conversion-factor*))
The `overall distance' is rather unnecessary, but the other variables
seem ok. The last expression '(/ (fceiling...) 10.)' should be a named
expression 'ceiling-ten-units' or something to give some clue as to
what it is doing.
(defun safe-time-zone (speed deceleration &optional (think-time *default-thinking-time*))
(check-type speed (real 0 *))
(check-type deceleration (real 0 *))
(let* ((converted-speed (/ speed *conversion-factor*))
(thinking-distance (* think-time converted-speed))
(braking-time (/ converted-speed deceleration))
(braking-distance (* .5 deceleration braking-time braking-time)))
(ceiling-ten-units (/ (+ thinking-distance braking-distance)
converted-speed))))
> Should I have written it in a more functional way even though it would have
> implied an extremly long one-line function?
In this case, I don't think so. The intermediate results have an intuitive
meaning.
> More in general should I try to avoid the creation of middle-level
> utility variables? I feel a bit in doubt as from one side I see the
> point of keeping the code elegantly simple, however I see an
> advantage from a readibility point of view in not having to try to
> decipher long formulas in the code above it's clear what is my idea
> of overall-distance in abstract but not in actual implementation.
I would have said that overall-distance is the one to chuck because
it is really obvious in that last expression that we are combining
the thinking-distance and the braking-distance. (Incidentally, notice
that the `thinking' calculation and the `braking' calculation are
done in the order that it would happen in reality.)
> So just kind of wondering what has experience taught to more proficient
> programmers in this case.
This is only my opinion. I'm guessing that others will have radically
different opinions.
> One more final silly question: am I right in assuming that if I use setf I
> do not have any reason to ever use setq?
Yes.
Some of us who remember when SETQ was for variables and SETF was for
`locations' will usually keep them separate, but it doesn't matter
these days.
Joe Marshall <···@ccs.neu.edu> wrote:
> The reason the first is considered `bad' is that one cannot understand
> small fragments of the code without considering the entire function.
> Look at the subexpression (list 'a sqr). Well, we know that we'll get
> a two element list, the first element being the symbol A, the second
> being what... Ah, there's a binding for SQR, but it's bound to NIL?
> No, wait, the meaning of SQR changes when we get to (setq sqr (expt y
> 2)). But Y is bound to NIL, too... oh, the meaning of Y changes in
> (setq y (car x)).
Would it be fair to generalize this as "Don't bind something unless
you're ready to give it a value, if you can avoid it" -- or perhaps,
"If you're going to give something a value straightaway, just do it in
the binding -- don't bind to a null value just to SETQ right after."
--
Karl A. Krueger <········@example.edu>
Woods Hole Oceanographic Institution
Email address is spamtrapped. s/example/whoi/
"Outlook not so good." -- Magic 8-Ball Software Reviews
From: Joe Marshall
Subject: Re: Question about Lisp Coding Style
Date:
Message-ID: <4qzauidb.fsf@ccs.neu.edu>
"Karl A. Krueger" <········@example.edu> writes:
> Joe Marshall <···@ccs.neu.edu> wrote:
>> The reason the first is considered `bad' is that one cannot understand
>> small fragments of the code without considering the entire function.
>> Look at the subexpression (list 'a sqr). Well, we know that we'll get
>> a two element list, the first element being the symbol A, the second
>> being what... Ah, there's a binding for SQR, but it's bound to NIL?
>> No, wait, the meaning of SQR changes when we get to (setq sqr (expt y
>> 2)). But Y is bound to NIL, too... oh, the meaning of Y changes in
>> (setq y (car x)).
>
> "If you're going to give something a value straightaway, just do it in
> the binding -- don't bind to a null value just to SETQ right after."
I'd definitely agree with this statement, but I'm wary of `general
rules of thumb' like the following:
> Would it be fair to generalize this as "Don't bind something unless
> you're ready to give it a value, if you can avoid it"
I think I'd rather say, don't gratuitously expand the scope of a
binding. In other words, why have a binding X defined (and unused)
over the entire body of a function when you could bind it where you
needed it.
There are exceptions, of course. In the code I wrote:
(defun safe-time-zone (speed deceleration &optional (think-time *default-thinking-time*))
(check-type speed (real 0 *))
(check-type deceleration (real 0 *))
(let* ((converted-speed (/ speed *conversion-factor*))
(thinking-distance (* think-time converted-speed))
(braking-time (/ converted-speed deceleration))
(braking-distance (* .5 deceleration braking-time braking-time)))
(ceiling-ten-units (/ (+ thinking-distance braking-distance)
converted-speed))))
Since braking-time is used only for the calculation of
braking-distance, this *could* have been written like this:
(defun safe-time-zone (speed deceleration &optional (think-time *default-thinking-time*))
(check-type speed (real 0 *))
(check-type deceleration (real 0 *))
(let* ((converted-speed (/ speed *conversion-factor*))
(thinking-distance (* think-time converted-speed))
(braking-distance (let ((braking-time (/ converted-speed deceleration)))
(* .5 deceleration braking-time braking-time))))
(ceiling-ten-units (/ (+ thinking-distance braking-distance)
converted-speed))))
and the ceiling-ten-units could be pulled outside:
(defun safe-time-zone (speed deceleration &optional (think-time *default-thinking-time*))
(check-type speed (real 0 *))
(check-type deceleration (real 0 *))
(ceiling-ten-units
(let* ((converted-speed (/ speed *conversion-factor*))
(thinking-distance (* think-time converted-speed))
(braking-distance (let ((braking-time (/ converted-speed deceleration)))
(* .5 deceleration braking-time braking-time))))
(/ (+ thinking-distance braking-distance)
converted-speed))))
But this seems to me to be *far* less readable.
"Rmagere" <·······@*the-mail-that-burns*.*figure-it-out*> wrote in message
·················@news.ox.ac.uk...
>
> He provides the following code as example:
> --BAD--
> (defun imp (x)
> (let (y sqr)
> (setq y (car x))
> (setq sqr (expt y 2))
> (list 'a sqr)))
>
> --GOOD--
> (defun imp (x)
> (list 'a (expt (car x) 2))
Note that the lesson here is that the variables were uninitialized in the
let statement, a misfeature not shared by your example.
As importantly to my eye, the names given to the variables don't have any
semantic meaning beyond what is obvious. So essentially only
temporary intermediates are created, avoided by the functional style in the
good example. Had the code been
(defun convert-datagram-command-to-ieee-format (datagram)
(declare (type (cons number t) datagram)) ; let everyone know we expect
the car of the input to be a number
(let* ((datagram-identifier (car datagram))
(ieee-identifier (expt datagram-identifier 2)))
;;; ieee requires all datagram commands to begin with the symbol 'a
(list 'a ieee-identifier)))
then we are documenting how our algorithm works, and the code becomes GOOD.
It's now easy for someone else to come along and figure out what gets done
by this code. That is, we've moved beyond simply stating an algorithm TO THE
MACHINE, we now realize our customer is also the next programmer who will
read the code, possibly ourself in five or ten years!
From: Nils Goesche
Subject: Re: Question about Lisp Coding Style
Date:
Message-ID: <lyn0d2azms.fsf@cartan.de>
"Rmagere" <·······@*the-mail-that-burns*.*figure-it-out*> writes:
> --BAD--
> (defun imp (x)
> (let (y sqr)
> (setq y (car x))
> (setq sqr (expt y 2))
> (list 'a sqr)))
> --GOOD--
> (defun imp (x)
> (list 'a (expt (car x) 2))
> The question is do you consider the following code as bad practice?
> (defun safe-time-zone (speed deceleration &optional think-time)
> (setf deceleration (abs deceleration)
> speed (abs speed)
> think-time (or think-time $thinking-time))
> (let* ((braking-time (/ speed $cfav deceleration))
> (thinking-distance (* think-time (/ speed $cfav)))
> (braking-distance (* 0.5 deceleration braking-time braking-time))
> (overall-distance (+ thinking-distance braking-distance))
> (safe-braking-zone (/ overall-distance (/ speed $cfav))))
> (/ (fceiling safe-braking-zone 0.1) 10)))
> Should I have written it in a more functional way even though it
> would have implied an extremly long one-line function?
>
> More in general should I try to avoid the creation of middle-level
> utility variables? I feel a bit in doubt as from one side I see the
> point of keeping the code
>
> elegantly simple, however I see an advantage from a readibility
> point of view in not having to try to decipher long formulas in the
> code above it's clear what is my idea of overall-distance in
> abstract but not in actual implementation.
I'd say your code is just fine, although I'm not sure whether naming
Lisp variables with $ signs is a good idea. If $cfav is a special
variable, name it *cfav*. If it is a constant, many people use +cfav+
or simply cfav. The `GOOD� example is indeed better than the `BAD�
example, simply because it is easier to read. I think Graham gives
this advice for people who do not know they /could/ rewrite `BAD� as
`GOOD�, even though they'd probably immediately agree that `GOOD� is
better once they've seen it.
> One more final silly question: am I right in assuming that if I use
> setf I do not have any reason to ever use setq?
Yes. Some people (including me) prefer using SETQ when possible
because then SETF immediately signals: ``Something fancy happening
here��. But you don't have to do that.
Regards,
--
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x0655CFA0
> I'd say your code is just fine, although I'm not sure whether naming
> Lisp variables with $ signs is a good idea. If $cfav is a special
> variable, name it *cfav*. If it is a constant, many people use +cfav+
> or simply cfav.
Thanks for your reply and $cfav is a special variable (though now that you
make me notice it is actually a constant so I will change my definition of
it
and its name).
I started using $cfav and $thinking-time rather than *cfav* and
*thinking-time* after having read one of Erann Gat complete idiot's
guide to ... (packages, special variables, lexical variables etc) where he
stated that *var* used to be the norm while now people tend to use $var.
I thought "neat" as I always forget the last * and as I tend to change often
special-variables for testing purpose on the top-level while watching the
events unfold on a window getting the name right the first time is quite
useful.
However if such change in conventions has actually not taken place then I
will go back to the *var* format.
In article <············@news.ox.ac.uk>, "Rmagere"
<·······@*the-mail-that-burns*.*figure-it-out*> wrote:
> > I'd say your code is just fine, although I'm not sure whether naming
> > Lisp variables with $ signs is a good idea. If $cfav is a special
> > variable, name it *cfav*. If it is a constant, many people use +cfav+
> > or simply cfav.
>
> Thanks for your reply and $cfav is a special variable (though now that you
> make me notice it is actually a constant so I will change my definition of
> it
> and its name).
> I started using $cfav and $thinking-time rather than *cfav* and
> *thinking-time* after having read one of Erann Gat complete idiot's
> guide to ... (packages, special variables, lexical variables etc) where he
> stated that *var* used to be the norm while now people tend to use $var.
I don't believe I said that. If I did, please tell me where because I
need to correct it. It's not true.
What I have said in the past is that I believe that it would be a good
idea to change the convention from *var* to $var, but very few people in
the Common Lisp community seem to agree. (As a general rule I have found
the Common Lisp community to be extraordinarily resistant to
institutionalized change of any sort.)
E.
···@jpl.nasa.gov (Erann Gat) writes:
> What I have said in the past is that I believe that it would be a good
> idea to change the convention from *var* to $var, but very few people in
> the Common Lisp community seem to agree. (As a general rule I have found
> the Common Lisp community to be extraordinarily resistant to
> institutionalized change of any sort.)
These two sentences have little to do with each other, contrary to
the implication of the parenthesizaton. Perhaps if you were to
replace "institutionalized" with "gratuitous", it would bring them
closer together, but somehow I don't quite think that's what you
had in mind...
I agree with the first statement, and in fact I am one of those in
the community who prefer *var* to $var.
However, your parenthesised statement reads as slightly hyperbolic,
and you aren't using the word "institutionalized" in a way that
I can fit into the context. By _definition_, institutionalized
change is extremely slow, so the CL community fits very well with
that style - there's nothing to resist. Did you really want another
word besides that word, or would you mind rephrasing your
parenthesized statement more precisely? Perhaps instead this was
a brain-o and you are really railing _against_ the strong
institutionalization that the CL community seems to adhere to?
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
In article <·············@beta.franz.com>, Duane Rettig <·····@franz.com> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > What I have said in the past is that I believe that it would be a good
> > idea to change the convention from *var* to $var, but very few people in
> > the Common Lisp community seem to agree. (As a general rule I have found
> > the Common Lisp community to be extraordinarily resistant to
> > institutionalized change of any sort.)
>
> These two sentences have little to do with each other, contrary to
> the implication of the parenthesizaton.
I disagree. I think they have a little to do with each other. See below.
> Perhaps if you were to
> replace "institutionalized" with "gratuitous", it would bring them
> closer together, but somehow I don't quite think that's what you
> had in mind...
This seems to me nothing more than a roundabout way of saying that you
consider changing the convention from *var* to $var to be a gratuitous
one. That's fine. You're entitled to your opinion.
> I agree with the first statement, and in fact I am one of those in
> the community who prefer *var* to $var.
I know.
> However, your parenthesised statement reads as slightly hyperbolic,
> and you aren't using the word "institutionalized" in a way that
> I can fit into the context.
That may be because you deleted the relevant context:
Rmagere> Erann Gat ... stated that *var* used to be the norm while
Rmagere> now people tend to use $var.
> By _definition_, institutionalized change is extremely slow
It seems to me that institutionalized change in Common Lisp is slow even
by the standards of institutionalized change. As a general rule, if
something used to be the norm in Common Lisp then it's a very good bet
that it's still the norm today. This is not to say that nothing ever
changes, but "the norms" change very slowly, more slowly than in any other
programming language in active use, hence "extraordinarily" slowly.
Most members of the Common Lisp community seem to consider this a
feature. I happen believe that the drawbacks outweigh the benefits. I
think reasonable people can disagree about the merits of the situation,
but not over what the situation is.
> there's nothing to resist.
Of course there is. If there was nothing to resist we would not be having
this conversation.
> Did you really want another
> word besides that word, or would you mind rephrasing your
> parenthesized statement more precisely? Perhaps instead this was
> a brain-o and you are really railing _against_ the strong
> institutionalization that the CL community seems to adhere to?
I stand by my original statement as I wrote it. What I meant was that any
statement of the form, "X used to be the norm in Common Lisp and now it is
not" is almost certainly wrong no matter what X is. This was relevant
because it was alleged that I had made a statement of that form.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> In article <·············@beta.franz.com>, Duane Rettig <·····@franz.com> wrote:
> > However, your parenthesised statement reads as slightly hyperbolic,
> > and you aren't using the word "institutionalized" in a way that
> > I can fit into the context.
>
> That may be because you deleted the relevant context:
>
> Rmagere> Erann Gat ... stated that *var* used to be the norm while
> Rmagere> now people tend to use $var.
Yes, I can see that one might think of the (false) phrase "now
people tend to use" as referring to institutionalization, whether formal
or not, but the hyperbole I saw in your statement was not the use of that
word, but of your use of the phrase "of any sort". More true would be
"of any sort which I (E.G.) have tried".
You've come up with ideas several times on this newsgroup, and have been
resisted many of those times. Perhaps this bothers you, but:
1. So have we all had such experiences of having a Good Idea that
was resisted.
2. Comp.lang.lisp is not an institution that can effect a change
in Common Lisp itself.
> > By _definition_, institutionalized change is extremely slow
>
> It seems to me that institutionalized change in Common Lisp is slow even
> by the standards of institutionalized change.
It is interesting that you use the ruler to measure itself and call itself
slow.
As a general rule, if
> something used to be the norm in Common Lisp then it's a very good bet
> that it's still the norm today.
Agreed.
This is not to say that nothing ever
> changes, but "the norms" change very slowly, more slowly than in any other
> programming language in active use,
Yes.
hence "extraordinarily" slowly.
Yes, you did use the word "extraordinarily", but you also coupled that
to the word "resistant". If you had said something like "Common Lisp
changes extraordinarily slowly", I would have agreed and had no issue
with your terminology.
> Most members of the Common Lisp community seem to consider this a
> feature. I happen believe that the drawbacks outweigh the benefits. I
> think reasonable people can disagree about the merits of the situation,
> but not over what the situation is.
>
> > there's nothing to resist.
>
> Of course there is. If there was nothing to resist we would not be having
> this conversation.
I'll take the blame for that context-failure. Let's bring back
the whole context, including the sentence you left out:
You said:
| As a general rule I have found
| the Common Lisp community to be extraordinarily resistant to
| institutionalized change of any sort.
to which I said:
| By _definition_, institutionalized
| change is extremely slow, so the CL community fits very well with
| that style - there's nothing to resist.
I should have been a little more verbose on that last phrase: instead
of "there's nothing to resist" I could have said "there not enough tension
between the CL community and the instituions that are set up to change
CL to the point where resistance (by the CL community) is necessary". If
there is any resistance, it may be a resistance on your part to such stability.
I know you have written papers, and that might be considered to establish
you as an institution in some communities, but the CL community doesn't
respond to that (it doesn't resist such efforts, it simply doesn't respond
to them) toward changing the language or its implementations. But there
are at least two institutions that have strong sway on the CL community;
one is a testing effort by Paul Dietz, and the other is the standards
committee. So tell me, have you tried exerting some kind of pressure in
either of those institutions? Have you offered to help Paul on his test
suite? Have you joined the CL standards committee?
> > Did you really want another
> > word besides that word, or would you mind rephrasing your
> > parenthesized statement more precisely? Perhaps instead this was
> > a brain-o and you are really railing _against_ the strong
> > institutionalization that the CL community seems to adhere to?
>
> I stand by my original statement as I wrote it. What I meant was that any
> statement of the form, "X used to be the norm in Common Lisp and now it is
> not" is almost certainly wrong no matter what X is. This was relevant
> because it was alleged that I had made a statement of that form.
Well, yes, although a year ago no CL at all had arrays of element-type
nil, and now many do (or are at least in the works).
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
> ···@jpl.nasa.gov (Erann Gat) writes:
>>It seems to me that institutionalized change in Common Lisp is slow even
>>by the standards of institutionalized change.
Another feat of alchemy: the transformation of the virtues of maturity
and stability into programming language deficiencies! And merely by
adding the simple of ingredient of other folks not preferring one
typographical convention over another!! Only a True Wizard could villify
a once-respected language community over something so inconsequential.
I am going to go find a language that changes every day, maybe Perl or
Python. I bet I can sell /them/ on StudlyCaps. The reactionary bastards
here are useless!!
kt
--
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Of all the various delusions, the sense of discrimination between
oneself and others is the worst form, as it creates nothing but
unpleasantness for both sides."
-- Tenzin Gyatso, the Fourteenth Dalai Lama
In article <················@nyc.rr.com>, Kenny Tilton
<·······@nyc.rr.com> wrote:
> > ···@jpl.nasa.gov (Erann Gat) writes:
> >>It seems to me that institutionalized change in Common Lisp is slow even
> >>by the standards of institutionalized change.
>
> Another feat of alchemy: the transformation of the virtues of maturity
> and stability into programming language deficiencies! And merely by
> adding the simple of ingredient of other folks not preferring one
> typographical convention over another!! Only a True Wizard could villify
> a once-respected language community over something so inconsequential.
>
> I am going to go find a language that changes every day, maybe Perl or
> Python. I bet I can sell /them/ on StudlyCaps. The reactionary bastards
> here are useless!!
>
> kt
Another symptom of the Common Lisp community's extraordinary resistance to
chance is the vituperative and overblown reactions one gets at the mere
suggestion that change might be a good thing.
E.
Erann Gat wrote:
> In article <················@nyc.rr.com>, Kenny Tilton
> <·······@nyc.rr.com> wrote:
>
>
>>>···@jpl.nasa.gov (Erann Gat) writes:
>>>
>>>>It seems to me that institutionalized change in Common Lisp is slow even
>>>>by the standards of institutionalized change.
>>>
>>Another feat of alchemy: the transformation of the virtues of maturity
>>and stability into programming language deficiencies! And merely by
>>adding the simple of ingredient of other folks not preferring one
>>typographical convention over another!! Only a True Wizard could villify
>>a once-respected language community over something so inconsequential.
>>
>>I am going to go find a language that changes every day, maybe Perl or
>>Python. I bet I can sell /them/ on StudlyCaps. The reactionary bastards
>>here are useless!!
>>
>>kt
>
>
> Another symptom of the Common Lisp community's extraordinary resistance to
> chance is the vituperative and overblown reactions one gets ...
Good thing I edited out the bad stuff!
:)
kt
···@jpl.nasa.gov (Erann Gat) writes:
> Another symptom of the Common Lisp community's extraordinary
> resistance to chance is the vituperative and overblown reactions one
> gets at the mere suggestion that change might be a good thing.
I'm going to jump in here, since I feel that I have "seen the light"
lately with the resistance to change within the CL community. I think
that when people find CL or scheme they try learning it, find that
some idioms are a bit odd (with explanatins of "we always did it that
way so that's how it became standardized") and then make requests to
change the language to be more similar to modern languages (which the
new user was more familiar with generally) and then find resistance to
those suggestions, which then pisses them off and gives them the
impression that the CL community is a bunch of old farts stuck in the
past.
Change is a good thing, but not as good as all the marketing that
successful software companies have been shoving down our throats for
the past 20 years. Like another discussion in this group pointed out,
somehow stability of a programming environment (or software in
general) is now considered a bad thing and if a project doesn't
realease every two weeks it's already considered dated.
I for one have changed my opinions on Lisp/Scheme after finding the
wealth of papers and other documents which explain the design
decisions that helped the standard form in the first place. Instead
of wishing that lisp was more modern I've just accepted that maybe I
need a bit more experience and that things might be a little different
in the CL world.
After working with something for 5-20 years I might start suggesting
changes on how to make the tools I use better, and trust the people
that have that experience to have made good decisions based on the
experiences they have had. This doesn't mean that all of them were
right or the easiest to learn or that they make any sense now, but
with time and experience using the system these reasons become clear.
CL works and there are many in this group that are adament about it.
Just because some young whippersnapper has some ideas that
perl/python/whathaveyou is the best thing since sliced bread doesn't
mean that we should just go about suggesting we reshape something that
works into the realm of instability.
And in conclusion, change is good (that's why I started learning to
use CL), but don't expect by jumping into the river you'll instantly
be able to direct the current (especially if you haven't put in the
time to learn why things were done the way they were).
--
burton samograd
······@hotmail.com
http://kruhftwerk.dyndns.org
Burton Samograd <······@hotmail.com> writes:
> ···@jpl.nasa.gov (Erann Gat) writes:
> > Another symptom of the Common Lisp community's extraordinary
> > resistance to chance is the vituperative and overblown reactions one
> > gets at the mere suggestion that change might be a good thing.
> Just because some young whippersnapper has some ideas that
> perl/python/whathaveyou is the best thing since sliced bread doesn't
> mean that we should just go about suggesting we reshape something that
> works into the realm of instability.
I'm sure you're not thinking of Erann as being one of those "young
whippersnappers". And the changes he wants are toward a different
end than improvement of the language, per se.
> And in conclusion, change is good (that's why I started learning to
> use CL),
And CL promotes change. The fact that it is an extensible language
makes change a basic part of CL, and CL is thought of as a language-
writing language. One has to get used to the difference, though,
between changing by substitution of different definitions, and
changing by extension.
but don't expect by jumping into the river you'll instantly
> be able to direct the current (especially if you haven't put in the
> time to learn why things were done the way they were).
Good analogy. If you want to go places fast when you jump into
a fast-moving stream, don't try to swim against the current toward
some goal upstream. Instead, learn what the stream's goal is, and
relax - see how fast it gets you there. It's quite a ride.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Burton Samograd <······@hotmail.com> writes:
> And in conclusion, change is good (that's why I started learning to
> use CL), but don't expect by jumping into the river you'll instantly
> be able to direct the current (especially if you haven't put in the
> time to learn why things were done the way they were).
An interesting perspective.
It reminds me, btw, that a lot of time I go to the store and see the
huge volume of books on "new things in CS" and think "ugh. more stuff
to learn." But then I leaf through it and see that very little has
changed other than syntax and the number of new ideas has not grown
anywhere near as fast as the number of new product wrappers. Seen in
this light, one might leave aside the presumption that failure to
change means stagnation and start to question the common wisdom that
the fact of change is proof of non-stagnation. I won't say there are
no new ideas, but the few there are have certainly been obfuscated by
the many changes in trivial syntactics. So I think your point is
well-made about the value of long-standing papers and other auxiliary
material that haven't grown stale in this community as fast as in some
others. In some sense, you might regard that we're an experiment not
just in new ideas but in honest product packaging...
Kenny Tilton <·······@nyc.rr.com> writes:
> > ···@jpl.nasa.gov (Erann Gat) writes:
> >>It seems to me that institutionalized change in Common Lisp is slow even
> >>by the standards of institutionalized change.
>
> Another feat of alchemy: the transformation of the virtues of maturity
> and stability into programming language deficiencies! And merely by
> adding the simple of ingredient of other folks not preferring one
> typographical convention over another!! Only a True Wizard could
> villify a once-respected language community over something so
> inconsequential.
>
> I am going to go find a language that changes every day, maybe Perl or
> Python. I bet I can sell /them/ on StudlyCaps.
For typographical conventions, one important point to consider is that
we use different levels of speech, depending on the context. When I'm
conversating with my patnas, I spit hella slang, and generally speak
in an informal manner -- in this group, I use a more universally
comprehensible (I hope) style of informal language. The same goes for
code: my Lisp code looks fiarly idiomatically like me. I've seen
Kenny's code, and some of Erann's, and I *know* they write idiomatic
code. However, when posting code snippets here, they bend to the
arbitrary conventions that have been established to promote
readability. I'm sure Kenny would love to post his code snippets
using those evil, obnoxious StudlyCapsWithoutHyphens, but doesn't want
to require the level of effort/investment on the part of his readers
that it would take for them to be able to read it.
> The reactionary bastards here are useless!!
So you're saying you want to help me with the dialectical-materialist
exploration of typographical conventions in code, I'm working on? :-)
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Thomas F. Burdick wrote:
> For typographical conventions, one important point to consider is that
> we use different levels of speech, depending on the context. When I'm
> conversating with my patnas, I spit hella slang...
I am reminded (by the loosest of connections!) of the two good ol' boys
down at my sports bar a couple of nights ago drawling away their
ghetto-ese, not as a putdown, but merely having adopted the vernacular.
Wonderful, bro.
> readability. I'm sure Kenny would love to post his code snippets
> using those evil, obnoxious StudlyCapsWithoutHyphens,
declining feature, homey. eyeballing RoboCells in the next window, I spy
lotsa hyphens and one compromise: mktask. Not mkTask, and not mk-task.
but i have yet to crack a bottle of champagne and fire up wingrep to
aggressively convertLegacyUsages.
>> The reactionary bastards here are useless!!
>
> So you're saying you want to help me with the dialectical-materialist
> exploration of typographical conventions in code, I'm working on? :-)
Bro, do I get to shoot a gun in the air?
kt
In article <·············@beta.franz.com>, Duane Rettig <·····@franz.com> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > In article <·············@beta.franz.com>, Duane Rettig
<·····@franz.com> wrote:
>
> > > However, your parenthesised statement reads as slightly hyperbolic,
> > > and you aren't using the word "institutionalized" in a way that
> > > I can fit into the context.
> >
> > That may be because you deleted the relevant context:
> >
> > Rmagere> Erann Gat ... stated that *var* used to be the norm while
> > Rmagere> now people tend to use $var.
>
> Yes, I can see that one might think of the (false) phrase "now
> people tend to use" as referring to institutionalization, whether formal
> or not, but the hyperbole I saw in your statement was not the use of that
> word, but of your use of the phrase "of any sort". More true would be
> "of any sort which I (E.G.) have tried".
My statement is based not only on my personal experience, but also on my
observations about actual changes in Common Lisp from whatever source (see
below). Also, you do not know all of the things that I have tried, nor
all of the things that I have observed. All you know is what you've seen
transpire on c.l.l.
> Yes, you did use the word "extraordinarily", but you also coupled that
> to the word "resistant". If you had said something like "Common Lisp
> changes extraordinarily slowly", I would have agreed and had no issue
> with your terminology.
<shrug> That seems to me to be splitting semantic hairs. In any case, I
believe both statements are true, and I'll stand by them both.
> If there is any resistance, it may be a resistance on your part
> to such stability.
The phrase "resistance to stability" strikes me as a bit linguistically
awkward, but not incorrect.
> I know you have written papers, and that might be considered to establish
> you as an institution in some communities, but the CL community doesn't
> respond to that (it doesn't resist such efforts, it simply doesn't respond
> to them) toward changing the language or its implementations. But there
> are at least two institutions that have strong sway on the CL community;
> one is a testing effort by Paul Dietz, and the other is the standards
> committee. So tell me, have you tried exerting some kind of pressure in
> either of those institutions? Have you offered to help Paul on his test
> suite? Have you joined the CL standards committee?
I have not offered to help Paul (I had no indication that he needed any
help) and I didn't even know that the CL standards committee still
existed. I thought it disbanded after the finalization of the standard.
(What does the committee do nowadays? Who's on it? How often do they
meet? How do I join?)
But I think you are under a serious misapprehension about my motives. You
say that "[writing] some papers ... might be considered to establish [me]
as an institution in some communities ..." which seems to indicate that
you think I care about being "an institution" (whatever that means) in the
CL community. I don't. All I want is to be able to use CL. My position,
my standing, and my aspirations are no more and no less than someone who
used to be a customer, who has been forced by circumstances to no longer
be a customer, and who wishes once again to be a customer. And I am not
alone. Everywhere I turn I find people who would love to use Lisp but who
can't because of circumstances. My advocacy for change is motivated by my
belief that change is a necessary condition for Lisp's market share to
grow to the point where everyone who wants to make their living writing
Lisp code (including me) can do so. This is not an ego trip.
> > I stand by my original statement as I wrote it. What I meant was that any
> > statement of the form, "X used to be the norm in Common Lisp and now it is
> > not" is almost certainly wrong no matter what X is. This was relevant
> > because it was alleged that I had made a statement of that form.
>
> Well, yes, although a year ago no CL at all had arrays of element-type
> nil, and now many do (or are at least in the works).
No, that is not true. CLisp version 2.27 released over two years ago
supported element type nil. Also, element type nil was required by (a
certain interpretation of) the standard, and so even if what you said were
true I would consider it a bug fix, not a change.
If that's your best example of change in Common Lisp I'd say that's pretty
good support for my position.
E.
[Others have responded to most of your article with some good info
and corrections. I want to concentrate here on the issue of the
reasons for desiring change.]
···@jpl.nasa.gov (Erann Gat) writes:
> But I think you are under a serious misapprehension about my motives. You
> say that "[writing] some papers ... might be considered to establish [me]
> as an institution in some communities ..." which seems to indicate that
> you think I care about being "an institution" (whatever that means) in the
> CL community. I don't.
No misunderstanding there. And I always knew that your frustration
with CL not changing has always been due to your perception about the
real problem you experience. It is a given that CL as a language will
not be changed quickly. And you're correct in that I do not know
what all you've tried in order to accomplish your goal - what I was
doing above was making a guess as to what one of those attempts might
have been. I hadn't formed that guess in the exact shape if an if/then
statement, but could easily have done so. And if the predicate if an
if is false, then the consequent is of no consequence...
> All I want is to be able to use CL.
This unqualified statement leaves you wide open for a "so then just
use it" response. However, knowing your history, and the connection
you have always placed on changing CL and the reasons for such a
desire, I can already state the a more accurate way for you to have
put it would have been:
All I want is for my employer to sanction my use of CL in my job.
You have said and implied this many times, and you say it again below.
But your solution is to change CL, where it is really your employer's
perception of CL that needs changing.
My position,
> my standing, and my aspirations are no more and no less than someone who
> used to be a customer, who has been forced by circumstances to no longer
> be a customer, and who wishes once again to be a customer. And I am not
> alone. Everywhere I turn I find people who would love to use Lisp but who
> can't because of circumstances.
Yes, we've known that here on c.l.l. for several years. And the problem
is that you're only turning around; you're not walking out of the culture
of of engineers who have blamed Lisp for their problems, and who are indeed
all around you. I'm not at all suprised at your perceptions.
But let me ask you this: Are you going to ILC '03? If not, you should,
even if it takes scheduling a vacation in order to do so. If you're
serious about using CL in your work, then your employer's perception of
CL will have to change, however that is to come about (which might be
through education or maybe even a job change). But before your employer's
perception of CL and the CL community changes, your own perception of the
CL community will need to change as well.
Or perhaps you've been to one of the Lispnyk/Lispnik meetings? Is there
one in your area? If not, ever thought of starting one?
> My advocacy for change is motivated by my
> belief that change is a necessary condition for Lisp's market share to
> grow to the point where everyone who wants to make their living writing
> Lisp code (including me) can do so.
Right. I've heard your solution many times before, but problem
solving is all about keeping the _problem_ in the forefront, not a
desired solution. You just happened to have chosen and are sticking
with one of the hardest solutions to your problem, when there are
quite a few other solutions that are easier and ae in fact becoming
more and more viable every year.
> This is not an ego trip.
Never said it was. I sense frustration rather than inflated ego.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
In article <·············@beta.franz.com>, Duane Rettig <·····@franz.com> wrote:
> All I want is for my employer to sanction my use of CL in my job.
To be more precise, what I really want is for CL to be sufficiently
mainstream that I don't have to make huge compromises in my life in order
to use it. The truth is, I do still use CL, but at the moment it's a
hobby, and the time and resources I have to devote to it are the time and
resources I devote to a hobby. I want to be able to use CL in my
business, whatever that happens to be. At the moment (and for most but
not all of the past 15 years) my business is aerospace, which is a
business that I happen to believe very strongly could benefit tremendously
from more widespread use of Lisp, so I've decided to continue to focus my
attention here until something better comes along.
> You have said and implied this many times, and you say it again below.
> But your solution is to change CL, where it is really your employer's
> perception of CL that needs changing.
Yes, that's certainly true. But having observed the dynamics of decision
making here for fifteen years I don't think my employer's perception of
Lisp is likely to change unless Lisp changes.
> Yes, we've known that here on c.l.l. for several years. And the problem
> is that you're only turning around; you're not walking out of the culture
> of of engineers who have blamed Lisp for their problems, and who are indeed
> all around you. I'm not at all suprised at your perceptions.
That's not true. I did walk out. In June of 2000 I quite my job and went
to work for Google, only to discover (to my shock) that they were just as
hostile to Lisp as JPL. So I came back. I have also made several other
attempts to walk out (including interviewing for a job at Franz, by the
way).
> But let me ask you this: Are you going to ILC '03?
Yes, I'm presenting a paper there.
> Or perhaps you've been to one of the Lispnyk/Lispnik meetings? Is there
> one in your area? If not, ever thought of starting one?
Yes, I am a founding member of CRACL, the Los Angeles Lisp users group,
and I have been to every single one their (our) meetings.
> > My advocacy for change is motivated by my
> > belief that change is a necessary condition for Lisp's market share to
> > grow to the point where everyone who wants to make their living writing
> > Lisp code (including me) can do so.
>
> Right. I've heard your solution many times before, but problem
> solving is all about keeping the _problem_ in the forefront, not a
> desired solution.
I believe I have been keeping the problem in the forefront. In fact, I
don't have a proposed solution, except for this vague hand-wavy idea about
coming up with a better process to manage change. (I would gladly propose
a solution, and I'd do it in a minute if I had any reason believe it
wouldn't be a complete waste of time.)
> You just happened to have chosen and are sticking
> with one of the hardest solutions to your problem
No, I have identified what I believe to be a necessary (but not
sufficient) condition for changing the status quo.
> when there are
> quite a few other solutions that are easier and ae in fact becoming
> more and more viable every year.
I'm open to suggestions. What do you recommend?
>
> > This is not an ego trip.
>
> Never said it was. I sense frustration rather than inflated ego.
Then why did you make that comment about how publishing a few papers
doesn't make someone "an institution"? (You can treat that as a
rhetorical question.)
Yes, I am somewhat frustrated, both by my management, and by the CL
community. The potential mutual benefit that these two groups could have
for each other is enormous, and I am frustrated by the fact that I have
been unable to bring them together. I am frustrated that as a a result I
have to sit around and watch a lot of effort being wasted as people beat
their heads against the wall trying to tame C++ (and that now I have to
join in the head-beating in order to pay the mortgage).
You should be frustrated too. After all, your tax dollars are paying for
all this.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> In article <·············@beta.franz.com>, Duane Rettig <·····@franz.com> wrote:
>
> > All I want is for my employer to sanction my use of CL in my job.
>
> To be more precise, what I really want is for CL to be sufficiently
> mainstream that I don't have to make huge compromises in my life in order
> to use it. The truth is, I do still use CL, but at the moment it's a
> hobby, and the time and resources I have to devote to it are the time and
> resources I devote to a hobby. I want to be able to use CL in my
> business, whatever that happens to be. At the moment (and for most but
> not all of the past 15 years) my business is aerospace, which is a
> business that I happen to believe very strongly could benefit tremendously
> from more widespread use of Lisp, so I've decided to continue to focus my
> attention here until something better comes along.
Yes, of course, I knew that - there is no way you can post the kinds of
technical articles on this ng without at least playing with CL, and that
is why I rejected use of the "just use it" retort as specious.
> > You have said and implied this many times, and you say it again below.
> > But your solution is to change CL, where it is really your employer's
> > perception of CL that needs changing.
>
> Yes, that's certainly true. But having observed the dynamics of decision
> making here for fifteen years I don't think my employer's perception of
> Lisp is likely to change unless Lisp changes.
This is an important observation. It has several possible conclusions:
1. You can buck your perception and try to change your employer's
perception of lisp anyway. This is likely to fail, especially if
you bieleve that it will fail. Best case, you'd be in for a fight,
and possibly a compromise in your job situation.
2. Try to change the perception of the community around you, to bring
pressure to bear on your employer indirectly. I am gratified to hear
that you are actually doing this by way of a local lisp group. It
may seem like a roundabout way to get people within your company to
change, but peer pressure, critical mass, and groundswell really are
strong forces in management circles, even when there is animosity
toward that groundswell.
3. You can try to change lisp. You've been trying, but unsuccessfully.
I predict that trend will continue, because your final goal is at odds
with the rest of the community. Even if you were to succeed in making
a small change to CL, (or even a large change, for that matter), there
is no cause/effect relationship that will get your employer to suddenly
sit up and take notice, and say "Aha, CL is the right tool for us!".
4. You could change jobs. Yeah, I know, you like your job, and have been
in that industry for many years. OK. Ya builds yer bridge, and ya gets
over it.
> > Yes, we've known that here on c.l.l. for several years. And the problem
> > is that you're only turning around; you're not walking out of the culture
> > of of engineers who have blamed Lisp for their problems, and who are indeed
> > all around you. I'm not at all suprised at your perceptions.
>
> That's not true. I did walk out. In June of 2000 I quite my job and went
> to work for Google, only to discover (to my shock) that they were just as
> hostile to Lisp as JPL. So I came back. I have also made several other
> attempts to walk out (including interviewing for a job at Franz, by the
> way).
Yes, we know about that mistake; you've talked to us about it quite
often. I assume that if you hadn't thought of Google as a potential
Lisp shop, nor of certain people of Lisp staure who might have drawn
you there, you might have asked the hard questions and not gotten the
shock that you did.
> > But let me ask you this: Are you going to ILC '03?
>
> Yes, I'm presenting a paper there.
Excellent! Perhaps you'll get a sense of the excitement that has been
building.
> > Or perhaps you've been to one of the Lispnyk/Lispnik meetings? Is there
> > one in your area? If not, ever thought of starting one?
>
> Yes, I am a founding member of CRACL, the Los Angeles Lisp users group,
> and I have been to every single one their (our) meetings.
Excellent! How many are attending, and what agenda do you have? Are
you doing some kind of proactive work to pomulgate CL to your community?
> > > My advocacy for change is motivated by my
> > > belief that change is a necessary condition for Lisp's market share to
> > > grow to the point where everyone who wants to make their living writing
> > > Lisp code (including me) can do so.
> >
> > Right. I've heard your solution many times before, but problem
> > solving is all about keeping the _problem_ in the forefront, not a
> > desired solution.
>
> I believe I have been keeping the problem in the forefront. In fact, I
> don't have a proposed solution, except for this vague hand-wavy idea about
> coming up with a better process to manage change. (I would gladly propose
> a solution, and I'd do it in a minute if I had any reason believe it
> wouldn't be a complete waste of time.)
>
> > You just happened to have chosen and are sticking
> > with one of the hardest solutions to your problem
>
> No, I have identified what I believe to be a necessary (but not
> sufficient) condition for changing the status quo.
You keep saying that change is a necessary conditon. Perhaps you should
explain why you believe that to be so.
> > when there are
> > quite a few other solutions that are easier and ae in fact becoming
> > more and more viable every year.
>
> I'm open to suggestions. What do you recommend?
Work withing your local group. Attend all of ILC '03, and draw some
ideas from there.
> > > This is not an ego trip.
> >
> > Never said it was. I sense frustration rather than inflated ego.
>
> Then why did you make that comment about how publishing a few papers
> doesn't make someone "an institution"? (You can treat that as a
> rhetorical question.)
But I won't. In one Star Trek episode, when the Enterprise was on its way
out into space and landing pod had just gotten into orbit and only had a
few minutes of fuel left, and all communications were dead, Spock, in
an act of desparation, ejected and ignited the fuel, throwing a flare into
space. The crew of the entreprise happened to see it, and turned around and
beamed the crew of the pod up just before it burned up in the atmosphere.
When things settled down, Kirk asked Spock if it was true that he had
performed an act of desparation, which would be a human thing to do.
And Spock answered "I analyzed the situation, and the only logical
choice to make was an 'act of desparation'. So I made that logical choice".
You may view institutionalization by paper-writing as an egotistical
thing. I don't, but regognize that it is done for that purpose many
times. However, I was not implying that by making yourself an
institution in that way that you were being egotistical. Instead,
I would have assumed that you were applying one of many techniques to
accomplish a goal. In a sense "without ego, I hereby perform this
act of egotism"...
> Yes, I am somewhat frustrated, both by my management, and by the CL
> community. The potential mutual benefit that these two groups could have
> for each other is enormous, and I am frustrated by the fact that I have
> been unable to bring them together. I am frustrated that as a a result I
> have to sit around and watch a lot of effort being wasted as people beat
> their heads against the wall trying to tame C++ (and that now I have to
> join in the head-beating in order to pay the mortgage).
Don't beat your head. It'll only hurt you.
> You should be frustrated too. After all, your tax dollars are paying for
> all this.
I am not an alchoholic, and I don't know if AA is where this prayer
originated, but I like and follow it: "God grant me the strength to
change the things I can change, the serenity to accept the things I
cannot change, and the wisdom to know the difference." No, I am not
frustrated.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
In article <·············@beta.franz.com>, Duane Rettig <·····@franz.com> wrote:
> Yes, of course, I knew that - there is no way you can post the kinds of
> technical articles on this ng without at least playing with CL, and that
> is why I rejected use of the "just use it" retort as specious.
Well, thank god for that.
> 1. You can buck your perception and try to change your employer's
> perception of lisp anyway.
I have tried that, and I have chronicled the results of my efforts in some
detail.
> 3. You can try to change lisp. You've been trying,
No I haven't. That is your fundamental mistake.
> > > But let me ask you this: Are you going to ILC '03?
> >
> > Yes, I'm presenting a paper there.
>
> Excellent! Perhaps you'll get a sense of the excitement that has been
> building.
I hope so.
> > > Or perhaps you've been to one of the Lispnyk/Lispnik meetings? Is there
> > > one in your area? If not, ever thought of starting one?
> >
> > Yes, I am a founding member of CRACL, the Los Angeles Lisp users group,
> > and I have been to every single one their (our) meetings.
>
> Excellent! How many are attending, and what agenda do you have? Are
> you doing some kind of proactive work to pomulgate CL to your community?
We have about half a dozen regulars, and about a dozen more who come and
go. We're a bit rudderless at the moment, trying to figure out what we
really ought to be doing.
> You keep saying that change is a necessary conditon. Perhaps you should
> explain why you believe that to be so.
In a nutshell, because the situation here at the moment is such that the
conversation comes to an abrupt halt at the first mention of the word
"Lisp." I believe that if there were something new to talk about that
people could be persuaded to take another look. Also because the world is
changing, and I think Lisp needs to change with it.
But let's distinguish between change, and a better process for managing
change. What I would really like to see is the latter, in part because I
think that's really what's missing, and in part because I think that the
former would follow.
> > > when there are
> > > quite a few other solutions that are easier and ae in fact becoming
> > > more and more viable every year.
> >
> > I'm open to suggestions. What do you recommend?
>
> Work withing your local group. Attend all of ILC '03, and draw some
> ideas from there.
Let me be mor precise: What would you recommend that I do that I am not
already doing?
E.
On 19 Sep 2003 14:05:37 -0700, Duane Rettig <·····@franz.com> wrote:
> I am not an alchoholic, and I don't know if AA is where this prayer
> originated, but I like and follow it: "God grant me the strength to
> change the things I can change, the serenity to accept the things I
> cannot change, and the wisdom to know the difference."
I think this is definitely older than the AA. I've seen this
attributed to St. Francis of Assissi most of the time, sometimes to
Confucius.
Edi.
···@jpl.nasa.gov (Erann Gat) wrote in message news:<····················@k-137-79-50-101.jpl.nasa.gov>...
> To be more precise, what I really want is for CL to be sufficiently
> mainstream that I don't have to make huge compromises in my life in order
> to use it.
Too bad that no lisp company can make the wildly speculative
investment in cl-emacs. Having just helped convert someone this week
to using emacs for all his ide needs, it makes little sense that all
his elisp skill is lost for normal programming.
A great scenario would be something similar to ibm's Eclipse or
Mozilla's xul. An app that people are interested in because it also
implies a useful crossplatform system. It would certainly gain
grassroots adoption.
···@jpl.nasa.gov (Erann Gat) writes:
> The potential mutual benefit that these two groups could have for
> each other is enormous, and I am frustrated by the fact that I have
> been unable to bring them together. I am frustrated that as a a
> result I have to sit around and watch a lot of effort being wasted
> as people beat their heads against the wall trying to tame C++ (and
> that now I have to join in the head-beating in order to pay the
> mortgage).
Are you sitting in the next cubicle over? I'm living this same
situation.
One problem with trying to get Lisp up for consideration here is that
it is another new, possibly good idea, just like switching to C++ was
only a few years ago, and we see how well that's going. They don't
want new ideas. They're too busy licking wounds from the last new
idea.
> You should be frustrated too. After all, your tax dollars are
> paying for all this.
And seeing this one too.
--
Steven E. Harris :: ········@raytheon.com
Raytheon :: http://www.raytheon.com
···@jpl.nasa.gov (Erann Gat) writes:
> In article <·············@beta.franz.com>, Duane Rettig <·····@franz.com> wrote:
>
>> ···@jpl.nasa.gov (Erann Gat) writes:
>>
>> Well, yes, although a year ago no CL at all had arrays of element-type
>> nil, and now many do (or are at least in the works).
>
> No, that is not true. CLisp version 2.27 released over two years ago
> supported element type nil. Also, element type nil was required by (a
> certain interpretation of) the standard, and so even if what you said were
> true I would consider it a bug fix, not a change.
[1]> (lisp-implementation-version)
"2.27 (released 2001-07-17) (built on cyberhq.internal.cyberhqz.com [192.168.0.2])"
[2]> (upgraded-array-element-type 'nil)
BIT
[3]> (array-element-type (make-array 0 :element-type 'nil))
BIT
That doesn't look like "support" to me.
> If that's your best example of change in Common Lisp I'd say that's pretty
> good support for my position.
I doubt it was Duane's best example; I'm sure that simple-streams is
much more strongly on his radar. But, in any case, how about two
simple empirical changes from my experience: program writers these
days are much less likely to distribute code in the CL-USER package,
and they're much more likely to use *FEATURES* robustly than in the
past.
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
In article <··············@lambda.jcn.srcf.net>, Christophe Rhodes
<·····@cam.ac.uk> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > In article <·············@beta.franz.com>, Duane Rettig
<·····@franz.com> wrote:
> >
> >> ···@jpl.nasa.gov (Erann Gat) writes:
> >>
> >> Well, yes, although a year ago no CL at all had arrays of element-type
> >> nil, and now many do (or are at least in the works).
> >
> > No, that is not true. CLisp version 2.27 released over two years ago
> > supported element type nil. Also, element type nil was required by (a
> > certain interpretation of) the standard, and so even if what you said were
> > true I would consider it a bug fix, not a change.
>
> [1]> (lisp-implementation-version)
> "2.27 (released 2001-07-17) (built on cyberhq.internal.cyberhqz.com
[192.168.0.2])"
> [2]> (upgraded-array-element-type 'nil)
> BIT
> [3]> (array-element-type (make-array 0 :element-type 'nil))
> BIT
>
> That doesn't look like "support" to me.
<shrug> It's more like support than, say, Harlequin which (properly IMO,
but that's another story) until very recently threw an exception when one
tried to create an array of element type nil.
> > If that's your best example of change in Common Lisp I'd say that's pretty
> > good support for my position.
>
> I doubt it was Duane's best example;
I certainly hope it wasn't.
> I'm sure that simple-streams is much more strongly on his radar.
How many Common Lisp implementations support simple-streams?
> But, in any case, how about two
> simple empirical changes from my experience: program writers these
> days are much less likely to distribute code in the CL-USER package,
> and they're much more likely to use *FEATURES* robustly than in the
> past.
What I'm talking about here is institutionalized change, i.e. change that
the Common Lisp community officially (if not formally) endorses by some
method, something analogous to the changes one sees in Python or Perl.
For example, I can go to www.python.org to see the current "official"
state of Python. I can look at
http://www.python.org/doc/current/modindex.html to see the list of library
modules that are officially blessed by the Python community (and observe
that the list changes over time). I can look at
http://www.python.org/doc/current/whatsnew/whatsnew23.html to see the most
recent changes in the core Python language. These are what I would call
"institutionalized changes". (Python also has a mechanism, the __future__
module, to help make the problems caused by these changes more
manageable.)
There are also "unofficial" changes to Python proposed and implemented by
members of the Python community, (e.g. http://www.stackless.com/). This
is what I would call non-institutionalized changes.
The process of non-instutionalized change in Common Lisp is fairly
robust. I think this is due in large measure to the unique simplicity
with which a user (as opposed to an implementor) can effect changes in
(his or her copy of) the language.
But institutionalized changes seem to me to be non-existent, and indeed
resisted, not because Common Lisp users are "stuck in their ways" (as Kent
puts it) but because Common Lisp users do not perceive that the benefits
of institutionalized change outweigh the drawbacks. And I understand
that.
The problem is, I am not a Common Lisp user. I used to be one, and I
would like to be one again, but at the moment I am not, not from my own
choice, but because in my line of work Common Lisp is considered too far
out of the mainstream. The Powers That Be have rendered their judgement,
and the only hope I see of changing that is to either wait for a
generational change in management, or to try to effect enough change in
Common Lisp that the Powers That Be can be convinced that it's worthwhile
taking another look. And I believe that my situation is not unique.
So while I am sympathetic to the reasons for (let's put a positive spin on
it) embracing stability, I believe that on balance the drawbacks outweigh
the benefits in this case. Trick is, the people who are hurt by stability
are disenfranchised. They are the ones who, like me, want to use CL but
can't, who would like to become experts but have to treat CL essentially
as a hobby when they budget their time. And so they have no voice (as
Duane was so eager to point out). By contrast, the people with the voice,
the experts, the ones who still get paid to work on or with CL, are the
ones best served by stability. And naturally they tend to get their way
because, after all, they're the customers.
E.
···@jpl.nasa.gov (Erann Gat) writes:
>> I'm sure that simple-streams is much more strongly on his radar.
>
> How many Common Lisp implementations support simple-streams?
At least three, to various extents: Allegro, CMUCL and SBCL. (CMUCL
support largely by Paul Foley; SBCL by Rudi Schlatte, at least
inspired by the CMUCL implementation).
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
On Fri, 19 Sep 2003 09:42:47 -0700, ···@jpl.nasa.gov (Erann Gat) wrote:
> I didn't even know that the CL standards committee still existed. I
> thought it disbanded after the finalization of the standard. (What
> does the committee do nowadays? Who's on it? How often do they
> meet? How do I join?)
<http://www.franz.com/~smh/J13/>
···@jpl.nasa.gov (Erann Gat) writes:
> If that's your best example of change in Common Lisp I'd say that's pretty
> good support for my position.
How about hierarchical packages? I think that by now there are at
least three implementations that have them.
In article <··············@cupid.igpm.rwth-aachen.de>, Mario S. Mommer
<········@yahoo.com> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
> > If that's your best example of change in Common Lisp I'd say that's pretty
> > good support for my position.
>
> How about hierarchical packages? I think that by now there are at
> least three implementations that have them.
That's news to me. Which three?
E.
···@jpl.nasa.gov (Erann Gat) writes:
> In article <··············@cupid.igpm.rwth-aachen.de>, Mario S. Mommer
> <········@yahoo.com> wrote:
> > How about hierarchical packages? I think that by now there are at
> > least three implementations that have them.
>
> That's news to me. Which three?
Oops, overcounted. AFAICT, only ACL (well, they invented it) and CMUCL
have them. But it seems this can be easily added to LispWorks:
http://www.tfeb.org/lisp/hax.html#HIERARCHICAL-PACKAGES
In any case, there IS change, but only on issues that people see as
relevant.
Erann Gat writes:
> In article <··············@cupid.igpm.rwth-aachen.de>, Mario S. Mommer
> <········@yahoo.com> wrote:
[...]
>> How about hierarchical packages? I think that by now there are at
>> least three implementations that have them.
>
> That's news to me. Which three?
If you are not completely overwhelmed by email and newsgroups you
regularly check, you might consider subscribing to a few more mailing
lists, where most hot things about Lisp projects happen. Some of the
most active and possibly little known are those of McCLIM, SBCL and
CLump.
I personally particularly like the more or less steady breeze of
McCLIM commit logs (these are sent to a specific list, not the general
one). By the way, have you tried the CLIM listener that comes with
McCLIM? I have never seen a real Lisp Machine, but I think this
listener looks especially cool and promising--and I can actually play
with it.
If you have only limited time, you may regularly check Linux Weekly
News. Get the "one big page" format and search for the string
"lisp". Better yet, have your boss do that :)
Paolo
--
Paolo Amoroso <·······@mclink.it>
···@jpl.nasa.gov (Erann Gat) writes:
> In article <·············@beta.franz.com>, Duane Rettig <·····@franz.com> wrote:
>
> > ···@jpl.nasa.gov (Erann Gat) writes:
> >
> > > What I have said in the past is that I believe that it would be a good
> > > idea to change the convention from *var* to $var, but very few people in
> > > the Common Lisp community seem to agree. (As a general rule I have found
> > > the Common Lisp community to be extraordinarily resistant to
> > > institutionalized change of any sort.)
> >
> > These two sentences have little to do with each other, contrary to
> > the implication of the parenthesizaton.
>
> I disagree. I think they have a little to do with each other. See below.
>
> > Perhaps if you were to
> > replace "institutionalized" with "gratuitous", it would bring them
> > closer together, but somehow I don't quite think that's what you
> > had in mind...
>
> This seems to me nothing more than a roundabout way of saying that you
> consider changing the convention from *var* to $var to be a gratuitous
> one. That's fine. You're entitled to your opinion.
The change would eat up another pseudo-alphabetic to no good end.
The variable namespace is not so cluttered that there's any ambiguity
resulting from names like *foo* and +bar+. They read fine.
However, people presently can use $foo as a readmacro, and if you lock
it down for some community-wide purpose, you take away one of a preciosu
few characters to do an action that did not require that expansion.
I happen to think it's relatively clever and useful for CL to have taken
advantage of these otherwise-meaningless notations in a way that is not
easily available to an infix parser rather than grabbing new characters
from the previous space.
The proposal is well-meaning but not without cost. It is straightforward
for a consenting individual to opt to do $foo in the privacy of his own
code. It is belligerent and invasive to ask that others change their
working code to accomodate such a style choice made by another.
An example of compatible changes or at least _attempts_ at compatible
changes that would not be gratuitous would be things like the following:
- Create a SPECIAL-VARIABLE-P predicate so that special variables
can be easily detected in searches.
- Create a mechanism for declaring (perhaps using regular expressions
or some other more specialized means) the convention for notating
special variables within a package, so that someone can say "I use
$FOO for specials, please warn me if you see $FOO free without a
special declaration/proclamation." That is, it is a legitimate
concern that some system tools won't respect your personal style, but
it is not a legitimate concern that some other programmers will not
respect your style (any more than it is a legitimate concern that
you will not respect theirs).
- Extend APROPOS (or create a similar tool) to accept other arguments
that search only for special variables. (In HyperMeta code, I have
my own SHOW-MATCHING-SYMBOLS that allows me to specify that I want
to search only externals, etc. -- searching only bound or fbound or
special-declared symbols would be natural extensions.)
- Extend the language (as Zetalisp does) to allow specials to have
aliases (by sharing the value cell). It might be some implementations
can't accomodate this, but it's worth a discussion. In that way,
you could use either of *FOO* or $FOO to mean the same thing.
This was very handy in the Maclisp->CL conversion, since *print-base*
used to be named BASE and *read-base* used to be IBASE; zetalisp
just shared the value cell. (The variable *NOPOINT was more trouble,
since it was replaced in CL by (NOT *PRINT-RADIX*). I jokingly
suggested that perhaps a way of creating an inverse-value-cell-alias
was the answer here, but it wasn't done. Code had to be manually
rewritten.)
A further reason that it's a bad change to make is that it requires either
(a) a change in the standard driven by something that is not broken
or (b) for special user-variables to be notated differently than special
system-variables. (Of course, I say this in full knowledge that the
+foo+ convention already has that bad property. It's unfortunate that
pi is not +pi+, etc.)
Nothing keeps you, btw, from making a readmacro $ that will read a name
and will symbolconc "*"'s on either end. ;) That would be a compatible
way to do it.
Note that the reason I and others get so annoyed at the proposals for
gratuitous change is that they seem to not be preceded by a discussion
of a problem. That is, the "problem description" and "proposal" are
merged. We explicitly avoided this in all X3J13 cleanups exactly for
the reason that discussions like:
Problem: Special variables aren't named $foo.
Solution: Make them named $foo.
aren't really helpful. What you want is:
Problem: I can't link my code with foreign code because symbol
names like *FOO* aren't valid C function or variable names.
or some such. THEN we can talk. But in the process of talking, we'll
find that hyphen doesn't map either. And so there will have to be
translation tables. And maybe _FOO_ will be a proper mapping of *FOO*.
Without changing the Lisp side. Or maybe you'll say
Problem: I just hate *foo* as a notation.
And then people will prefer:
Solution: Use the many other characters available to
you for personal choice.
rather than:
Solution: Make everyone use what I like.
You can't claim that a community is "stuck in its ways" if the majority
just happens to prefer stability over change on things that have no
technical impact. And yet, in a lot of your proposals, not only are
the initial problem description and the proposal for solution merged,
BUT ALSO there is a lament that the community refuses to see your way.
On the very first presentation. That's self-fulfilling prophecy in the
worst way. What's the point of trying to satisfy someone who is so
determined to criticize those people they're asking for help from?
There are ways to proceed on these things and ways not to. And different
techniques work at different times.
Even back when we _were_ accepting changes I don't think your suggestion
would have flown, exactly because the cost of change is too high.
You may be interested to know that as a matter of history, the big
source split between Symbolics and the LMITI (LMI/MIT/TI) systems of
Lisp Machines was caused when one night someone (I think it was RMS,
but not sure) went through and renamed all of the special variables to
suit a naming convention he chose. It doesn't matter if the change
was good or bad, the point was that tons of code not at the site where
the change was "globally" made did not compile any more. People at
Symbolics panicked (appropriately, I think) saying "our sources, the
value of our business, sit somewhere where any individual at MIT with
a console can just change them???" Almost overnight, as I recall, the
Symbolics sources were reverted and split to be private. All over a
single incident of apparent lack of respect by one individual for the
needs of community stability. (I saw the email that came from whoever
did it and I seem to recall it was characterized as helpful change.
As is the change proposed in the thread here on the newsgroup. But
the intent of the maker is not the only metric of what is helpful.
The needs of all impacted parties must be considered to get proper
perspective.) NOTE WELL: I think if you read Stallman's account of
the way the source split happened, it will say something completely
different. This is my personal recollection, and our own memories are
probably each biased by our own politics. (And surely there were
other politics and undercurrents going on that contributed as well.)
I'll leave it to you to figure out if he's right or I'm right or if it
doesn't matter to the point I'm making. (I was not a Symbolics
employee at the time; I was an MIT employee, so no, I did not have
"that Symbolics bias", if you think that matters. Though my later
memories may have been through that meatgrinder, if you want to
characterize it thus.)
In article <···············@shell01.TheWorld.com>, Kent M Pitman
<······@world.std.com> wrote:
[A long argument against using $foo for special variables]
These are all good arguments. You will note that I am not lobbying for
this change at all, merely stating that I think it would be a good idea.
> You can't claim that a community is "stuck in its ways"
I made no such claim.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> In article <···············@shell01.TheWorld.com>, Kent M Pitman
> <······@world.std.com> wrote:
>
> [A long argument against using $foo for special variables]
>
> These are all good arguments. You will note that I am not lobbying for
> this change at all, merely stating that I think it would be a good idea.
A meta-point then:
I have come to distrust one-place predicates in political rhetoric.
Mr. Senator, are you in favor of the environment? Yes.
Mr. Senator, are you in favor of lower taxes? Yes.
Mr. Senator, are you in favor of a strong defense? Yes.
...
These tell me nothing. They appear to say that someone likes something
but never puts them into the position of showing what they would trade
for it.
Mr. Senator, if you could lower taxes or have a strong defense
which would you do? Uh, ...
In this case, saying
I merely favor it.
does not cut it for me. If you can't come to the table with:
I would sacrifice the stability of the language just to get this.
then you are not really saying the thing you appear to be saying,
since that is the price tag of what you are saying you like.
As long as you're dealing in counterfactual prefrences, you might as
well be saying
I wish rainwater were beer.
Anyway, just to summarize, my meta-point is that statements about what
one likes or not, in the absence of a context that creates a trade economy
for that thing are not interesting. This is really just a corollary of
my often-made point that there are no things that are Good or Bad in the
abstract, they are only Good or Bad in a context. By saying you prefer
it but are not advocating chagne, you're appearing (at least to me)
to be speak without context.
Of course, nothing makes you abide by my personal rules of debate.
But at least this will help you understand where I'm coming from in
being troubled by your remark even when you say it did not intend
to trouble me. My "disingenuous speaker" alarm is going off, whether
or not that was your intent.
In article <···············@shell01.TheWorld.com>, Kent M Pitman
<······@world.std.com> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > In article <···············@shell01.TheWorld.com>, Kent M Pitman
> > <······@world.std.com> wrote:
> >
> > [A long argument against using $foo for special variables]
> >
> > These are all good arguments. You will note that I am not lobbying for
> > this change at all, merely stating that I think it would be a good idea.
[Snip]
> Of course, nothing makes you abide by my personal rules of debate.
> But at least this will help you understand where I'm coming from in
> being troubled by your remark even when you say it did not intend
> to trouble me. My "disingenuous speaker" alarm is going off, whether
> or not that was your intent.
I didn't respond at length simply because I thought you were going off on
a tangent. Let's review what this conversation is about:
1. Rmagere said that I had written in one of my Idiot's Guides that the
typographical convention for special variables had changed from *foo* to
$foo.
2. I responded by saying that a) I had not to my knowledge written this,
b) the convention hadn't changed, c) a good working assumption about
conventions (and just about everything else in CL) is that they don't
change.
3. As a parenthetical I said that I had in the past expressed a personal
preference for $foo over *foo*, that I retain that preference, and that
this may have been where Rmagere got the impression that I had said that
the convention had changed. But this comment was already a tangent, and
your lengthy response to it even more of a tangent.
The only reason I didn't respond is because it was a tangent, and very
likely to be a waste of time, since it's very unlikely that the reasons I
have for personally preferring $foo to *foo* are going to have any impact.
Nonetheless, since you insist, here are my reasons for preferring $foo to *foo*:
1. Less typing. One fewer excursion to the shift key.
2. Easier greppage. I think that dynamic variables are important enough
that it's worth spending a character on making them readily apparent,
vusally distinguishable from, say, multiplication, and easily searchable.
2a. Using the $foo convention allows a transition to a state where the
correspondence between the typographical convention and dynamic variables
is actually enforced by the system, e.g. by having a reader macro for #\$
that expands $foo into (symbol-value 'foo) or something like that. (As a
general rule I believe that any time the burden in placed on the
programmer to adhere to a typographical convention in order to avoid
problems, that is an indication of a flaw in the language design.)
3. More in keeping with typographical conventions in other languages.
Fewer gratuitous differences with industry standard conventions make Lisp
more accessible to newcomers.
4. I find $foo to be more aesthetically pleasing than *foo*,
notwithstanding my utter disdain for Perl.
Anyone tempted to respond to this please take note: these are my personal
opinions only. The only reason I post them is because Kent thought it was
disingenuous of me not to.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> Anyone tempted to respond to this please take note: these are my personal
> opinions only. The only reason I post them is because Kent thought it was
> disingenuous of me not to.
Actually, for me, it's always interesting to hear people's reasons.
But I did not call you disingenuous. I just said I had installed in
myself an alarm that goes off now when people use certain forms of
certain statements. And the form is "I like x." (one-place
predicate). You responded with more things of that form. I was
pointing out that this risks being disingenuous (or, if not
intentional, then merely meaningless) unless you say "I like x more
than y." (the two-place predicate)
The problem is that someone can like anything. The question is what
are they willing to trade. Or, in some cases, are you willing to trade
the marked price.
And you didn't really get to that point. Because the price is the stability
of the language.
I guess maybe you're just saying you're window shopping and want to be
ignored. But though you sometimes seem to think no one listens to
you, no one would be responding if that were really so. The fact is
that we listen and then don't get much from it.
You say you don't use CL. That doesn't necessarily make you a great
candidate for influencing what CL does. But you then identify you as
a potential customer, and you seem to say "if only.." and then list
some reasons. Yet when asked why your employer won't let you use CL,
the answer is never "because it uses *foo* instead of $foo", nor any
of the other aesthetic changes you want to make. Nor have you made a
credible case for the idea that a bunch of little changes like this would
add up to something big.
Sometimes you seem to imply that "if only the language were changeable
at all, then I could get the things I really need" and then it seems like
you're just trying through these discussions to open the door to "unfettered
change". But unfettered change would probably get you a stream of changes
you didn't want just as fast as it got you the possibility of a few changes
you did want. So I'm even unconvinced that if you "won totally" and found
ANSI CL open for arbitrary change by open-minded people tomorrow that you
would be in a goal state closer to your dream.
I am not trying to slight you nor to impugn your motives. I'm just trying
to say I often just can't figure out what you're doing in any practical
sense. If it's just carrying on bar-room conversation, I guess that's
fine. But you seem to want people to take you more seriously than that,
and that's where I get lost and try to set things onto a more productive
track... Forgive me if my attempts at being productive fall just as short
for you as yours sometimes do for me. I'm sure it's not for lack of trying
on the part of either of us... but for some reason I feel compelled to keep
trying ... as, I suppose, do you.
In article <···············@shell01.TheWorld.com>, Kent M Pitman
<······@world.std.com> wrote:
> The problem is that someone can like anything. The question is what
> are they willing to trade. Or, in some cases, are you willing to trade
> the marked price.
>
> And you didn't really get to that point. Because the price is the stability
> of the language.
Stability is a continuum, not a boolean. By saying that "the price" (the
price of what, by the way? I'm not even sure what you're talking about
here) is "the stability of the language" you imply that "the stability of
the language" is a single monolithic thing that would get thrown out lock
stock and barrel if people started writing $foo instead of *foo*. I think
you know that's not true, (and I think it's therefore to some extent
disingenuous of you to imply that it is, but that's neither here nor
there).
> I guess maybe you're just saying you're window shopping and want to be
> ignored. But though you sometimes seem to think no one listens to
> you, no one would be responding if that were really so. The fact is
> that we listen and then don't get much from it.
What were you expecting to get?
> You say you don't use CL. That doesn't necessarily make you a great
> candidate for influencing what CL does.
Yes, that's a typical attitude in the CL community, and one of the reasons
IMO that CL is not increasing its market share. It seems to be focused on
existing customers. Potential customers get treated with neglect at best
and disdain at worst. That is not a good growth strategy IMHO.
> But you then identify you as
> a potential customer, and you seem to say "if only.." and then list
> some reasons. Yet when asked why your employer won't let you use CL,
> the answer is never "because it uses *foo* instead of $foo", nor any
> of the other aesthetic changes you want to make. Nor have you made a
> credible case for the idea that a bunch of little changes like this would
> add up to something big.
That's because I do not claim that a bunch of little changes would add up
to something big. I do not claim that JPL would start using Lisp if
people started using $foo instead of *foo*. Where do you come up with
these things?
I have asked you this before, I'll ask you again: why do you choose to
twist and misrepresent my position in the ways that you find to be the
most distasteful? What are you hoping to accomplish?
> Sometimes you seem to imply that "if only the language were changeable
> at all, then I could get the things I really need" and then it seems like
> you're just trying through these discussions to open the door to "unfettered
> change".
There, you just did it again. I have never called for unfettered change.
That is a pure fabrication on your part. Why do you do that? What are
you hoping to accomplish?
> I am not trying to slight you nor to impugn your motives.
That may not be your intent, but that is what you are in fact doing, and I
can't for the life of me figure out why.
> I'm just trying
> to say I often just can't figure out what you're doing in any practical
> sense.
At the moment all I am trying to do is to stop people from spreading
misinformation about what I have and have not said.
> If it's just carrying on bar-room conversation, I guess that's
> fine. But you seem to want people to take you more seriously than that,
> and that's where I get lost and try to set things onto a more productive
> track...
At the moment it's pretty much bar-room conversation. But if you want
this to turn into a productive exchange one thing that would be helpful is
for you to stop misrepresenting my position.
E.
From: Christopher C. Stacy
Subject: Re: Question about Lisp Coding Style
Date:
Message-ID: <ubrtg2egf.fsf@dtpq.com>
>>>>> On Fri, 19 Sep 2003 14:48:06 -0700, Erann Gat ("Erann") writes:
Erann> Yes, that's a typical attitude in the CL community, and one of
Erann> the reasons IMO that CL is not increasing its market share.
Erann> It seems to be focused on existing customers. Potential
Erann> customers get treated with neglect at best and disdain at worst.
I missed the part where there were potential customers
asking for special variables to be named $FOO ?
······@dtpq.com (Christopher C. Stacy) writes:
> >>>>> On Fri, 19 Sep 2003 14:48:06 -0700, Erann Gat ("Erann") writes:
>
> Erann> Yes, that's a typical attitude in the CL community, and one of
> Erann> the reasons IMO that CL is not increasing its market share.
> Erann> It seems to be focused on existing customers. Potential
> Erann> customers get treated with neglect at best and disdain at worst.
>
> I missed the part where there were potential customers
> asking for special variables to be named $FOO ?
Of course, he was making a larger point with the potential customers bit.
I'm willing to give Erann the benefit of the doubt that some things
might need to change significantly for Lisp to meet a wide audience.
However, I *really* don't think that little things like *foo* v $foo,
or any simple typographical convention is what needs to change. Small
changes to Lisp are fine, but not if they're revisiting old decisions
in the small. A different namespace for specials is a non-trivial
jump -- I don't think you can get existing Lispers to swallow
incremental steps approaching this jump, because we're all okay with
the existing single variable namespace. Rather than an orthodox
darwinist model, consider a gouldian[*] (heirarchical-selection, of wich
punctuated-equilibrium is a special case) model instead.
Personally, I think that Lisp has a good chance of widespreacd
acceptance, sticking to its conventional model. The current IT crisis
(which is only part of the general economic crisis) necessarily opens
doors for unorthodox approaches. At the same time, it doesn't close
the door to the orthodox entryway -- ie, just because the tiltionaise
approach has a particularly appealing opportunity right now, doesn't
mean that that gattian approach is in a bad place. I'm a pretty
confirmed gouldian -- a selection episode is coming, and I hope we
have a well-developed diversity of approaches when it comes.
[*] I mean gouldian in the larger extra-biology sense. I'm a somewhat
gouldian biologist, but when it comes to philosphy of science, and
general theoretcial theory, I'm a ferverent gouldian.
Gouldianism/heirarchical-selection is an simple but important
extention on dialectical materialism. When it comes to biology, I
have scientific differences with Gould (ie, I think there are cases
where he didn't apply gouldian analysis correctly), but that doesn't
undermine gouldian analysis -- in fact, in only streanghtens it.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> Personally, I think that Lisp has a good chance of widespreacd
> acceptance, sticking to its conventional model.
What you think, patna?
> > Erann> Yes
But what about
> The current IT crisis
> (which is only part of the general economic crisis)
?
> > Erann> CL is not increasing its market share.
Then what's up with it?
> > Erann> that's a typical attitude in the CL community.
Aiiight, so we concernt, then why it is we ain't got shit on
lock-down?
> > Erann> Potential customers get treated with neglect
Fuck blood, you got to be knowin we hellof clockin this shit, main.
Grindin, main, sometime quarterbackin!
> > Erann> at best
Aiiight so mebbe we jus be clockin the dope. That aint mean we ain't
treat em wit --
> > Erann> disdain at worst.
Damn, god, I was goin' say r.e.s.p.e.c.t. But if you spiet it you
done seen it.
> > Erann> IMO that CL is not increasing its market share.
Outside seein expansion I know the game comes thick on the outside an
eeryone know a hustler gotta hustle, so where yo block at? You shook
that shit down or you still working at it? Sup wit it?
patna.
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> What you think, patna?
I think I finally got my spam filters configured. In case you're not
aware, there's an email-worm/IE-virus that's currently spreading on
the internet. It's the fastest-spreading one yet (according to news
reports). Of course, I use Emacs/VM (that's a Lisp MUA) on Solaris
and Mac OS X, so I'm not vulerable to attack. Er, worm-attack that
is. When these things spread, they collect email addresses on the
way, but they *do* need a seed group. Guess who was in the seed
group? Think >25MB/hr before I got any filtering in place (25MB is
the hard quota of my mail spool -- I think it was more like 1GB/hr,
but I can only confirm >25MB/hr). I like to think of this as a
victory for Lisp developers -- I mean, we must be important, right?
Well, it's over. If anyone sent me any mail in the last two days,
please resend it. If it totals > 100000 bytes, that's one of the 40
rules that get your mail bounced, so don't send attachments. But, I
finally got my email working again to the point where I can use it for
earning my income again. Dio mio, grazia!!!!
Thomas F. Burdick writes:
> I think I finally got my spam filters configured. In case you're not
> aware, there's an email-worm/IE-virus that's currently spreading on
> the internet. It's the fastest-spreading one yet (according to news
> reports). Of course, I use Emacs/VM (that's a Lisp MUA) on Solaris
By the way, I am wondering about those cyberterrorism studies
commissioned by the US government. If I recall correctly, they appeal
to citizens so that each of them does its part. Do they refer to those
citizens, of whom 9 out of 10 use Windows and Outlook? Good luck...
Paolo
--
Paolo Amoroso <·······@mclink.it>
From: Christopher C. Stacy
Subject: Re: Question about Lisp Coding Style
Date:
Message-ID: <u3cerclqe.fsf@dtpq.com>
>>>>> On 19 Sep 2003 23:52:40 -0700, Thomas F Burdick ("Thomas") writes:
Thomas> ······@dtpq.com (Christopher C. Stacy) writes:
>> >>>>> On Fri, 19 Sep 2003 14:48:06 -0700, Erann Gat ("Erann") writes:
>>
Erann> Yes, that's a typical attitude in the CL community, and one of
Erann> the reasons IMO that CL is not increasing its market share.
Erann> It seems to be focused on existing customers. Potential
Erann> customers get treated with neglect at best and disdain at worst.
>>
>> I missed the part where there were potential customers
>> asking for special variables to be named $FOO ?
Thomas> Of course, he was making a larger point with the potential customers bit.
Without details, the statements are absolutely meaningless.
Please list potential customers and the projects that would
probably have been done in Common Lisp, if only the language
had provided certain changes; please list those changes.
Thomas> I'm willing to give Erann the benefit of the doubt that some things
Thomas> might need to change significantly for Lisp to meet a wide audience.
In my experience, a "wide audience" is fundamentally incompatible
with a thing of high quality. Please list the changes, significant
or otherwise, that you think would make Lisp appeal to whatever
market you're talking about.
Christopher C. Stacy wrote:
> In my experience, a "wide audience" is fundamentally incompatible
> with a thing of high quality.
"Wide audience" does contribute to improvement in quality, though,
because bugs in the implementation(s) are exposed more quickly,
and more resources are available to fix them. gcc gets pounded
on a lot.
A corollary is that among fringe languages, age and stability of
the language definition (and libraries) are relatively more important,
since the bugs are worked out more slowly.
Paul
In article <·············@dtpq.com>, ······@dtpq.com (Christopher C.
Stacy) wrote:
> >>>>> On Fri, 19 Sep 2003 14:48:06 -0700, Erann Gat ("Erann") writes:
>
> Erann> Yes, that's a typical attitude in the CL community, and one of
> Erann> the reasons IMO that CL is not increasing its market share.
> Erann> It seems to be focused on existing customers. Potential
> Erann> customers get treated with neglect at best and disdain at worst.
>
> I missed the part where there were potential customers
> asking for special variables to be named $FOO ?
Thanks for proving my point.
In article <···············@shell01.TheWorld.com>, Kent M Pitman
<······@world.std.com> wrote:
> Yum. Yes, I'm veritably salivating at the thought of returning to those
> days... all in the name of making CL more practical to modern users.
I am starting to get really fed up with people misrepresenting my position.
I never said that potential customers were asking for a change in the
typographical convention for specials. I never said that making that
change would result in increasing Lisp's popularity. I never said that
the typographical convention should change. All I said was that I had a
personal preference, and I clearly identified it as such.
In fact, I wanted very much to just keep my personal preferences about
this to myself, but when I tried to do that Kent gave me a long lecture
about being disingenuous.
There is no way to win with you people. I feel like I'm back in
elementary school playing some bizarre schoolyard game. "Tell us what you
think." "No, I'd really rather keep it to myself." "Oh, come on, if you
don't tell us we'll all think you're a snob or something." "OK, but this
is just my personal opinion. I think X" "You think Y? Man, that is
STUPID!"
I ask again: why are you doing this? What are you hoping to accomplish?
E.
··························@jpl.nasa.gov (Erann Gat) writes:
> I am starting to get really fed up with people misrepresenting my position.
People are not misrepresenting your position.
We are not saying "Erann intended x".
We are saying "What we thought we heard Erann said was x."
Or sometimes we are saying "What we thought we heard said was x."
and we're oblivious even to the fact that it was you speaking
(notwithstanding the poster I'm replying to, I often just speak
generally and not straight back at the poster, as "generic Joe" Marshall
can attest to from a recent interchange I had with (generically) him.)
To me it doesn't matter who said a thing. What matters is the thing,
once it is said, or once I think it might be said. Sometimes people just
say things that remind me that I wanted to write down something on a topic
even...
These are really substantially different things.
It seems to me that there are several lessons here:
* People criticizing your ideas are not criticizing you.
* People characterizing your ideas are not always trying to do damage to
them. Sometimes they are doing their absolute very best to sum up what
you said in concise space to respond. I know I'm doing that.
I perceive others to be doing that, too. (To me, "misrepresent"
has a connotational aspect of intent; in my dialect, a person cannot
misrepresent something without intending to.)
* People listen to you more than you think. That's WHY they are hearing
you suggesting change when you're just stating an opinion. People
do this to me all the time, but I don't say they are misrepresenting me.
I cringe. I have to do damage control. But I assume it's my error,
not theirs, that they misunderstood my intent.
* When you ARE trying to get a change made (which perhaps does not
include now), it seems to me that you often do not achieve your
goal of rallying the troops. It seems possible to me that this is
neither a conspiracy nor even in any way willful or disrespectful
or uncaring on others' parts but rather related somehow to the
message you convey unintentionally as you attempt to do what I
perceive as rallying.
As a corollary, I have to wonder whether your real problem internally
at JPL is Lisp or your ability to make an effective case for Lisp.
Lest you find this overly critical, let me say that I have had problems
selling Lisp in some organizations and many others I know have also.
I don't mean this to be personal at all. My real point
is that I do not necessarily blame Lisp (where I perceive that when
you advocate Lisp and people fail to accept it, it's Lisp that is at
fault and not your argument). I think there are many other
languages that would not fly either, at least in my own experience
and maybe in yours, too ... but not because of their linguistic
properties. Often the property that is a killer is that they are
"not Java" or "not C". These are very hard things to fix in a language.
I don't know how to make Lisp be not "not Java". Yet even though being
"not Java" is, I suppose, a property of Lisp, I tend to think it's better
to model this as a problem with your argument. That is, I do not blame
Lisp for having kept itself out of some shops; I blame my persuasional
skills. Because for however hard it is to get someone who wants Java
to use Lisp, it is a million times easier than persuading them that
Lisp _is_ Java. Lisp is not and never will be Java. That's definitional.
A fundamental property of the Universe. Whereas, people (even stubborn
people) do change their minds. So I'd rather argue that they should
use non-Java languages than argue that Lisp is really "just Java"
if the truth is that Javaness is the criterion for acceptance.
If the criterion is "this is our house language and it bugs us when
people use other things", then that's gonna be it. But addressing
that problem is the real barrier, not addressing the language per se.
> I never said that potential customers were asking for a change in the
> typographical convention for specials.
You do routinely identify yourself as a potential customer.
You did here identify that this was a preference of yours.
You did here say that people were unresponsive to suggestion and stuck
in their ways.
You can see how someone might reasonably have "heard" you saying this.
People do simple inferencing. Not to be spiteful. Because it helps
them put important things together.
> I never said that making that
> change would result in increasing Lisp's popularity.
But you did tell a story about how Lisp is not popular where you are.
And you have said you are trying to fix that.
And you are making suggestions about what changes you'd like.
And people assume you aren't wasting valuable energy making suggestions
that wouldn't have a material effect.
So you can see how people might reasonably have "heard" you saying this.
> I never said that the typographical convention should change.
But you have pushed for regularity.
And you have suggested that things are too hard to learn.
And you have identified this as a good idea that you wanted to lend
support to.
And people are listening to you to find out what suggestions you have
about how to make Lisp more popular, since you're the one who routinely
identifies yourself as on the fence, just between a user and a non-user.
So you can see how people might reasonably have "heard" you say this.
> All I said was that I had a
> personal preference, and I clearly identified it as such.
I have been in places where I've been representing the United States at
an ISO WG16 meeting (standardizing ISLISP). (I'm not such a rep now,
but I used to be.) It was not uncommon to hear certain people (the
Japanese guys are the most careful about it) be inordinately careful about
how they present their personal remarks. They often were heard to say
(approximately) this phrase set that bracketed a personal remark:
I would like to offer my personal opinion.
The following is my personal opinion:
<insert a few words of personal opinion>
This has been my personal opinion.
At first I thought this was just baroque and unnecessary, but later I
came to appreciate this kind of bracketing as important. One day I'd
just make a casual remark and the next day I'd overhear someone saying
not just "Kent thinks ..." and not just "Harlequin thinks ..." (I
worked there at the time) but "The United States thinks ..." and then
a repeat of what I'd just said. Was this a false statement? Surely.
As a general rule, the United States did not authorize me to be making
random pronouncements of opinion in its name. There were limited ways
in which I could act as a kind of diplomat in their name, but it was
VERY confined. Still, the question becomes: was someone else
"misrepresenting me" by saying this? No. They were simply confused,
and in part by my failure to communicate clearly which hat I was
wearing while making which remark.
> In fact, I wanted very much to just keep my personal preferences about
> this to myself, but when I tried to do that Kent gave me a long lecture
> about being disingenuous.
I didn't at any point call you disingenuous, and I have even clarified
that claim in between the remark you refer to and now. I said that I
have observed that certain behaviors are often signals for that and
that it's quite useful to have a trap that notices standard ways in
which that's done. I said that you were triggering the alarm, but I
did not make a remark about your intent. People have car alarms and
it's possible to say "Fred triggered your car alarm." without saying
"Fred was breaking into your car." They are different.
> There is no way to win with you people.
I agree with this. But only because no one is competing with you.
You are not winning or losing. It's just a dialog. We're trying to
be as interested in you as you are in us. We are not obliged to agree
with you any more than you are obliged to agree with us. So we're all
just coping. I don't see the problem here.
> I feel like I'm back in elementary school playing some bizarre
> schoolyard game. "Tell us what you think." "No, I'd really rather
> keep it to myself." "Oh, come on, if you don't tell us we'll all
> think you're a snob or something." "OK, but this is just my
> personal opinion. I think X" "You think Y? Man, that is STUPID!"
Poeple are remarking on the position, not on you.
Look, I'd have to go back and check, but either you raised this issue
first (in which case your little rendition of the schoolhouse game is
wrong because you went first and unilaterally volunteered your opinion
in this thread and not in the game) or else you didn't go first (in which
case the position we're characterizing (without mentioning your name)
is not even yours and you're just thinking we're picking on you when
we're just talking about the issue.
> I ask again: why are you doing this? What are you hoping to accomplish?
I'm not sure what "this" is. I'm just answering your questions to the
best of my ability.
And I'm offering technical opinions on technical topics like whether a
change from *foo* to $foo is a good idea. There were a lot of things
we talked about and thought about that we did not write down. People
come in and suggest things like as if it was new, and often it's not.
So I often offer both my opinion and my memory of what the state of
the world was at the time this was nailed down. We certainly discussed
this _extensively_.
In article <···············@shell01.TheWorld.com>, Kent M Pitman
<······@world.std.com> wrote:
> ··························@jpl.nasa.gov (Erann Gat) writes:
>
> > I am starting to get really fed up with people misrepresenting my position.
>
> People are not misrepresenting your position.
Yes, they are. And you are among them. Just one example:
> The proposal is well-meaning but not without cost.
This necessarily implies that I (or someone) was making a proposal. I was
not. Therefore, this is a misrepresentation of my position.
> We are not saying "Erann intended x".
Yes, you are. Not in those words, but as soon as you mention "the
proposal" you are necessarily implying that there is a proposal on the
table. There isn't.
> We are saying "What we thought we heard Erann said was x."
No, you aren't. If you were there would be no problem because then I
could simply respond with, "No, what I said was X."
> * People criticizing your ideas are not criticizing you.
No, you are criticizing phantoms. You are criticizing a proposal that no
one has made. (You, Kent, are also criticizing my personal preferences in
programming style after going out of your way to solicit them, which I
also find to be quite rude, notwithstanding any merit your criticism may
have.)
> * People characterizing your ideas are not always trying to do damage to
> them. Sometimes they are doing their absolute very best to sum up what
> you said in concise space to respond. I know I'm doing that.
> I perceive others to be doing that, too. (To me, "misrepresent"
> has a connotational aspect of intent; in my dialect, a person cannot
> misrepresent something without intending to.)
I don't think you're doing what you're doing out of malicious intent. I
think you're doing it because you're just not giving it much thought, but
I could be wrong (which is why I keep asking you why you're doing it).
Nonetheless, the fact is that you are doing it, and you need to recognize
that if we're going to have a productive exchange.
> * People listen to you more than you think.
How would you know? Do you have ESP? How else would you know how much I
think people listen to me?
(I know that people listen to me. That's why I give careful consideration
to (almost) everything I write here, and why I get so annoyed when people
crticize me for saying things that I didn't say.)
> That's WHY they are hearing
> you suggesting change when you're just stating an opinion.
I understand that. That is why I went out of my way to label my opinion
with a big disclaimer: THIS IS JUST MY OPINION. If someone persists in
believing that I am making a proposal after seeing that then I'm sorry,
but it's their fault, not mine.
> * When you ARE trying to get a change made (which perhaps does not
> include now)
Indeed, I have tried this on c.l.l. only twice. I failed both times, and
I learned my lesson.
> , it seems to me that you often do not achieve your
> goal of rallying the troops. It seems possible to me that this is
> neither a conspiracy nor even in any way willful or disrespectful
> or uncaring on others' parts but rather related somehow to the
> message you convey unintentionally as you attempt to do what I
> perceive as rallying.
I never said there was a conspiracy, nor any of those other things.
(Misrepresenting my position again.) What is going on here is that you
are engaging in some kind of armchair psychoanalysis and doing a crappy
job. You are inventing positions and motivations for me out of whole
cloth.
> As a corollary, I have to wonder whether your real problem internally
> at JPL is Lisp or your ability to make an effective case for Lisp.
I got Lisp to fly on a spacecraft. That makes me the most successful Lisp
salesman in the history of the space exploration business. No, I don't
think the problem lies entirely with me.
> Lest you find this overly critical, let me say that I have had problems
> selling Lisp in some organizations and many others I know have also.
I have had relatively few problems selling Lisp in my organization
actually. The problem I am having is recent, and I expect it to be
transient. My past attempts to institute change in Lisp are only one of a
number of strategies that I am pursuing in parallel to address this
problem, most of which I am not advertising here. The CL community can be
part of the solution, or they can be part of the problem. Right now it
appears that a significant and vocal segment of the community has chosen
to be part of the problem. That is disappointing, but I'm not wringing my
hands over it. I can do this without your help, though I'd still much
rather this be a team effort.
Like I said, the only thing I am hoping to accomplish here is to stop
people from misrepresenting my position by, for example, saying that I am
making proposals for change when I am not.
> I don't mean this to be personal at all.
I don't take it personally.
> > I never said that potential customers were asking for a change in the
> > typographical convention for specials.
>
> You do routinely identify yourself as a potential customer.
>
> You did here identify that this was a preference of yours.
I also made very clear my reluctance to publish those views, that I was
doing so only because (I perceived that) you were pressuring me to do so,
and that these were only my personal preferences.
> You did here say that people were unresponsive to suggestion and stuck
> in their ways.
No. "Stuck in their ways" is a phrase that you invented, not me. Once
again, you misrepresent my position.
> You can see how someone might reasonably have "heard" you saying this.
No, I'm sorry, but I cannot.
> > I never said that making that
> > change would result in increasing Lisp's popularity.
>
> But you did tell a story about how Lisp is not popular where you are.
>
> And you have said you are trying to fix that.
>
> And you are making suggestions about what changes you'd like.
No, I am not. Expressing a personal preference after being asked to do so
is not the same as making a suggestion for a change.
> And people assume you aren't wasting valuable energy making suggestions
> that wouldn't have a material effect.
>
> So you can see how people might reasonably have "heard" you saying this.
No. The only way that someone could come to this conclusion is by
willfully ignoring my repeated disclaimers. That is not, IMO, reasonable.
> > I never said that the typographical convention should change.
>
> But you have pushed for regularity.
>
> And you have suggested that things are too hard to learn.
>
> And you have identified this as a good idea that you wanted to lend
> support to.
>
> And people are listening to you to find out what suggestions you have
> about how to make Lisp more popular, since you're the one who routinely
> identifies yourself as on the fence, just between a user and a non-user.
>
> So you can see how people might reasonably have "heard" you say this.
No, but I'm getting tired of having to explain all this at length.
> Still, the question becomes: was someone else
> "misrepresenting me" by saying this? No. They were simply confused,
> and in part by my failure to communicate clearly which hat I was
> wearing while making which remark.
Very well, Kent, you are confused. But now that you have been made aware
of this would it be reasonable for me to interpret any future false
statements about what I have and have not said as misrepresentations?
> > In fact, I wanted very much to just keep my personal preferences about
> > this to myself, but when I tried to do that Kent gave me a long lecture
> > about being disingenuous.
>
> I didn't at any point call you disingenuous
I didn't say that you did (yet another misrepresentation). I said you
gave me a long lecture about being disingenuous, which is in fact true
(modulo reasonable interpretations of the meanings of the words "long" and
"lecture").
> > There is no way to win with you people.
>
> I agree with this. But only because no one is competing with you.
"There's no way to win with you people" is an idiomatic expression in
English that merely expresses frustration. It does not imply that there
is a competition.
> And I'm offering technical opinions on technical topics like whether a
> change from *foo* to $foo is a good idea.
OK, but that's a non-sequitur. We had this same discussion back in May,
when I actually did make a proposal, which I withdrew less than 72 hours
after I made it largely because I found your counter-arguments compelling.
For the record: the convention for special variables in CL has not
changed, and I do not advocate that it be changed, notwithstanding my
personal preferences. (BTW and FWIW, I mostly use *foo* rather than $foo
in my own code, notwithstanding my personal preferences, out of deference
to convention.)
Can we please just drop this now?
E.
From: Joe Marshall
Subject: Re: Question about Lisp Coding Style
Date:
Message-ID: <vfrk3o0n.fsf@ccs.neu.edu>
Kent M Pitman <······@world.std.com> writes:
> (notwithstanding the poster I'm replying to, I often just speak
> generally and not straight back at the poster, as "generic Joe" Marshall
> can attest to from a recent interchange I had with (generically) him.)
Yep. Absolutely.
> I have been in places where I've been representing the United States at
> an ISO WG16 meeting (standardizing ISLISP). (I'm not such a rep now,
> but I used to be.) It was not uncommon to hear certain people (the
> Japanese guys are the most careful about it) be inordinately careful about
> how they present their personal remarks. They often were heard to say
> (approximately) this phrase set that bracketed a personal remark:
>
> I would like to offer my personal opinion.
> The following is my personal opinion:
> <insert a few words of personal opinion>
> This has been my personal opinion.
>
> At first I thought this was just baroque and unnecessary, but later I
> came to appreciate this kind of bracketing as important. One day I'd
> just make a casual remark and the next day I'd overhear someone saying
> not just "Kent thinks ..." and not just "Harlequin thinks ..." (I
> worked there at the time) but "The United States thinks ..." and then
> a repeat of what I'd just said. Was this a false statement? Surely.
> As a general rule, the United States did not authorize me to be making
> random pronouncements of opinion in its name. There were limited ways
> in which I could act as a kind of diplomat in their name, but it was
> VERY confined. Still, the question becomes: was someone else
> "misrepresenting me" by saying this? No. They were simply confused,
> and in part by my failure to communicate clearly which hat I was
> wearing while making which remark.
I seems to be necessary to do the same thing (seriously mark personal
opinion) on usenet.
Nonetheless, I refuse to do so because I'd rather pretend that most of
the people I converse with are smart enough to realize that my
personal opinion is *always* what I express (as if I *could* express
someone else's!) In the *extremely* rare case when someone is foolish
enough to entrust me with some official standing, I'd make a point of
letting people know that what I was saying was more than my own
opinion.
I also assume that in lieu of any sort of claim of official standing
that everyone else is offering their own opinion. If you are reading
minds and offering other people's opinions, you ought to make note of
that.
>> Erann Gat said:
>> There is no way to win with you people.
>
> I agree with this.
If you still have the same opinion after wading through the responses
trying to separate the technical argument from the ad-hominem vitriol,
I'd call that a win. This can be a `challenging' group.
··························@jpl.nasa.gov (Erann Gat) writes:
> There is no way to win with you people. I feel like I'm back in
> elementary school playing some bizarre schoolyard game. "Tell us what you
> think." "No, I'd really rather keep it to myself." "Oh, come on, if you
> don't tell us we'll all think you're a snob or something." "OK, but this
> is just my personal opinion. I think X" "You think Y? Man, that is
> STUPID!"
>
> I ask again: why are you doing this? What are you hoping to accomplish?
You've been made into the a straw-man representing a threat to the
"lisp community" -- so now in order to prove their intellectual
prowess as well as deserved right to be a card-carrying member of the
"lisp community" they must demonstrate for their peers and elders
their skill in rhetorical defense of the purity of their lispy bodily
fluids.
What they are hoping to accomplish is perhaps to relieve some sense of
alienation they feel, to lash out at a imaginary source of persecution
in an act of vengeance, or simply to establish their position in the
pecking order of c.l.l
A big fuck you to that kind of "lisp community"
Considering all the things that the real lisp community should be
working on in order to help one another get thru their daily
programming tasks, wasting time on c.l.l or other forums taking cheap
shots at those who are not lambda pure is the last thing idle hands
should be doing.
c.l.l is dead, long live lisp.
--
Sincerely, Craig Brozefsky <·····@red-bean.com>
No war! No racist scapegoating! No attacks on civil liberties!
Chicago Coalition Against War & Racism: www.chicagoantiwar.org
Craig Brozefsky wrote:
> ··························@jpl.nasa.gov (Erann Gat) writes:
>
>
>>There is no way to win with you people. I feel like I'm back in
>>elementary school playing some bizarre schoolyard game. "Tell us what you
>>think." "No, I'd really rather keep it to myself." "Oh, come on, if you
>>don't tell us we'll all think you're a snob or something." "OK, but this
>>is just my personal opinion. I think X" "You think Y? Man, that is
>>STUPID!"
>>
>>I ask again: why are you doing this? What are you hoping to accomplish?
>
>
> You've been made into the a straw-man representing a threat to the
> "lisp community" -- so now in order to prove their intellectual
> prowess as well as deserved right to be a card-carrying member of the
> "lisp community" they must demonstrate for their peers and elders
> their skill in rhetorical defense of the purity of their lispy bodily
> fluids.
Now we're talking! The Savages of Lisp Strike Back! Thanks for restoring
some melodrama to this NG.
>
> What they are hoping to accomplish is perhaps to relieve some sense of
> alienation they feel, to lash out at a imaginary source of persecution
> in an act of vengeance, or simply to establish their position in the
> pecking order of c.l.l
>
> A big fuck you to that kind of "lisp community"
Well fuck you and the horse you came in on for claiming people here do
not simply honestly disagree with the OP and instead are attacking an
innocent victim to score points with a gang community existing only in
your deeply paranoid mind.
[Okay, Beezelbub, can I wear the colors now?]
--
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"[If anyone really has healing powers,] I would like to call
them about my knees."
-- Tenzin Gyatso, the Fourteenth Dalai Lama
Kenny Tilton <·······@nyc.rr.com> writes:
> Well fuck you and the horse you came in on for claiming people here
> do not simply honestly disagree with the OP and instead are
> attacking an innocent victim to score points with a gang community
> existing only in your deeply paranoid mind.
Yeah, the reactionary nature of c.l.l exists only in my mind.
--
Sincerely, Craig Brozefsky <·····@red-bean.com>
No war! No racist scapegoating! No attacks on civil liberties!
Chicago Coalition Against War & Racism: www.chicagoantiwar.org
Craig Brozefsky wrote:
> Yeah, the reactionary nature of c.l.l exists only in my mind.
You've been reading 'How to Win Friends and Influence People', right?
Paul
Craig Brozefsky wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>Well fuck you and the horse you came in on for claiming people here
>>do not simply honestly disagree with the OP and instead are
>>attacking an innocent victim to score points with a gang community
>>existing only in your deeply paranoid mind.
>
>
> Yeah, the reactionary nature of c.l.l exists only in my mind.
>
Well this is a good example of how these Usenet deals are so hopeless.
My problem was with the motivation you ascribed to the OP's adversaries,
your comeback is to say "cll is indeed reactionary". Hopeless!
Anyway, you still see cll as an organized group. As if. Perhaps this
illusion arises from the unanimity of individuals acting independently
in concluding they are ok with *asterisks*.
Mind you, the frequent beatings I take over CamelCase /are/ in fact
carefully coordinated campaigns orchestrated from a coffee shop in
Berkeley. But not this asterisks deal.
You do however have me excited over the prospect of Mr. Browne shifting
his weekly analysis away from mere dissection of NG volume to weekly
rankings of the c.l.l. pecking order. I just hope there is someone below me.
kenny
--
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"[If anyone really has healing powers,] I would like to call
them about my knees."
-- Tenzin Gyatso, the Fourteenth Dalai Lama
Kenny Tilton <·······@nyc.rr.com> writes:
> Mind you, the frequent beatings I take over CamelCase /are/ in fact
> carefully coordinated campaigns orchestrated from a coffee shop in
> Berkeley. But not this asterisks deal.
Shit, why did no one invite me to these clandestine meetings? I work
in Berkeley at least twice a week! In a cafe, no less! And here I
kept trying to organize a best-coast-hypens-clique from my cafe in
Oakland -- no wonder I was so unsuccessful. "�Que? No hablo 'lisp'."
It all makes sense now.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Kenny Tilton <·······@nyc.rr.com> writes:
> Well this is a good example of how these Usenet deals are so
> hopeless. My problem was with the motivation you ascribed to the
> OP's adversaries, your comeback is to say "cll is indeed
> reactionary". Hopeless!
Honest disagreement is not the issue, and never was. Please rewind to
the question Erann posed:
There is no way to win with you people. I feel like I'm back in
elementary school playing some bizarre schoolyard game. "Tell us
what you think." "No, I'd really rather keep it to myself."
"Oh, come on, if you don't tell us we'll all think you're a snob
or something." "OK, but this is just my personal opinion. I
think X" "You think Y? Man, that is STUPID!"
I ask again: why are you doing this? What are you hoping to
accomplish?
> Anyway, you still see cll as an organized group. As if.
Having read c.l.l for 4 years, I know it is not organized. I'm not
sure why you took my caricature of some posters picking at Erann as a
diagnosis for the motivation of the group as a homogeneic whole.
Actually, I have an idea why you did that, but would prefer to stick
to my original point.
For awhile Erann has been a chew toy in c.l.l; going back to some
posts he made about losing faith in lisp:
http://groups.google.com/groups?selm=gat-1902021257120001%40eglaptop.jpl.nasa.gov&rnum=1
I have seen people taking pot shots at him, and maybe dealt a few
myself. It happens to other people who express a "loss of faith", or
who suggest changes they would like to see in the language, in the
standard, or the way the community approaches the two. Their comments
get reduced to the absurd, misrepresented, taken out of context, and
dismissed as ignorant. For example, Kent questioned Erann's ability
to comment on CL because he doesn't use it at work now. Recall that
Erann helped launch CL into Space and the CL standard has not changed
since then.
Me and Erann are not imagining this stuff, ask google, nor am I trying
to say it is an organized effort of the c.l.l cabal. It's a tendency
this newsgroup has exhibited for years. The Lisp community has work
to do, and it really cannot afford this forum being wasted on such
reactionary pettiness. The #lisp IRC channel isn't like this, CLIKI
isn't like this, the conferences aren't like this, the mailing lists
aren't like this. Why should we tolerate it in the newsgroup?
--
Sincerely, Craig Brozefsky <·····@red-bean.com>
No war! No racist scapegoating! No attacks on civil liberties!
Chicago Coalition Against War & Racism: www.chicagoantiwar.org
In article <·················@piracy.red-bean.com>, Craig Brozefsky
<·····@red-bean.com> wrote:
> For awhile Erann has been a chew toy in c.l.l
That metaphor really made me laugh. For what it's worth, I don't feel
like a chew toy most of the time (though I do get frustrated on
occasion). IMO the content of c.l.l. is for the most part of pretty high
quality, particularly by usenet standards.
E.
Erann Gat wrote in message ...
>In article <·················@piracy.red-bean.com>, Craig Brozefsky
><·····@red-bean.com> wrote:
>
>> For awhile Erann has been a chew toy in c.l.l
>
>That metaphor really made me laugh. For what it's worth, I don't feel
>like a chew toy most of the time (though I do get frustrated on
>occasion). IMO the content of c.l.l. is for the most part of pretty high
>quality, particularly by usenet standards.
I'm laughing, too. Probably because of my experience in the town of South
Park, my speedreading had that message ending "..of pretty high quality,
particularly by Usenet bastards".
:)
kt
ps. Could anyone who used to know me send me an email? Speaking of chew
toys, Netscape has taken to chewing my address book into shreds when I leave
it home alone too long. Hmmm, time to get a backup utility? :(
Craig Brozefsky wrote:
> Lisp Reactionaries Go Home
That is true. I go home every night. You need a comma after
"Reactionaries" to form an injunction. Fix that and post it to one
hundred newsgroups.
> ...I'm not
> sure why you took my caricature of some posters picking at Erann ...
Oh, you were /joking/! Sorry, all this work on RoboCells and my ILC talk
must be dulling my sense of humor.
kenny
ps. "chew toy"? I love it.
--
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"[If anyone really has healing powers,] I would like to call
them about my knees."
-- Tenzin Gyatso, the Fourteenth Dalai Lama
From: Christopher C. Stacy
Subject: Re: Question about Lisp Coding Style
Date:
Message-ID: <uvfrnb6ml.fsf@dtpq.com>
>>>>> On Sat, 20 Sep 2003 08:38:25 -0700, Erann Gat ("Erann") writes:
Erann> In article <·············@dtpq.com>, ······@dtpq.com (Christopher C.
Erann> Stacy) wrote:
>> >>>>> On Fri, 19 Sep 2003 14:48:06 -0700, Erann Gat ("Erann") writes:
>>
Erann> Yes, that's a typical attitude in the CL community, and one of
Erann> the reasons IMO that CL is not increasing its market share.
Erann> It seems to be focused on existing customers. Potential
Erann> customers get treated with neglect at best and disdain at worst.
>>
>> I missed the part where there were potential customers
>> asking for special variables to be named $FOO ?
Erann> Thanks for proving my point.
Erann> In article <···············@shell01.TheWorld.com>, Kent M Pitman
Erann> <······@world.std.com> wrote:
>> Yum. Yes, I'm veritably salivating at the thought of returning to those
>> days... all in the name of making CL more practical to modern users.
Erann> I am starting to get really fed up with people misrepresenting my position.
Erann> I never said that potential customers were asking for a change
Erann> in the typographical convention for specials.
That was the most recent change that you seemed to be asking for,
surrounded by your tirades about how people don't want to make
the necessary changes for Lisp to be popular at the kinds of
places where you work.
So if that's not one of the changes you think will help that cause,
how about explaining some of the changes that you do mean.
Erann> I ask again: why are you doing this? What are you hoping to accomplish?
I thought that was one of my implied questions.
In article <·············@dtpq.com>, ······@dtpq.com (Christopher C.
Stacy) wrote:
> So if that's not one of the changes you think will help that cause,
> how about explaining some of the changes that you do mean.
I do not think any particular changes are likely to make much of a
difference. I think that the existence of change, and a better process
for managing it, might.
E.
Erann Gat <··························@jpl.nasa.gov> wrote:
> In article <·············@dtpq.com>, ······@dtpq.com (Christopher C.
> Stacy) wrote:
>
> > So if that's not one of the changes you think will help that cause,
> > how about explaining some of the changes that you do mean.
>
> I do not think any particular changes are likely to make much of a
> difference. I think that the existence of change, and a better process
> for managing it, might.
The problem with this is that change for change's sake is costly and
stupid. Just because 90% of the people in the IT universe fail to
understand this doesn't make it false <cf.: Sturgeon's Law>.
So in order for anyone to get on a change bandwagon, there have to be
some change proposals out there that make real sense to a lot of the
community, and where having a better "change management process" would
help the situation.
In the absence of such change proposals, or nagging problems requiring
change, most (nearly all?) users will be opposed to change, and for
*very* good reasons. If it ain't broke -- don't fix it.
AFAICT, the ways in which CL is broken (in the sense of not being easy
to use for certain tasks) are already being worked on in implementation
and library efforts. The one way you have identified, IMO can't be
fixed by changing the language arbitrarily.
I think you are getting confused by the fact that when lisp was last
very popular, it was in a state of rapid change. By the time the
standards comittee cemented the current state of CL, we were already on
this side of the AI winter and lisp was as dead as Samuel Clemens. But
that change was rapid *because* the language was popular (and also
because there were so many different dialects, with varying strengths
and weaknesses and there was a lot of push to bring them together), not
the other way around
There is a big correlation between a language being popular and a
language changing fast, but I think you are putting the cart before the
horse. It's not that change attracts users, but that languages with
more users will naturally change more. Why? Two reasons. First is
that the more diverse the community, the more likely any change
supported by a minority will have the critical mass necessary for a
change to the language to be better/simpler than for the community that
has the problem to simply work around the existing language.
The second is that a larger community lowers the cost of change. More
implementors are at work building/prototyping possible changes, more
people are available to ponder the science of it and sit on standards
committees to hammer out the best approach. And more people are working
on fixing bugs and incompatibilities that come up in implementing any
changes. This is exactly what Paul said somewhere, and it makes perfect
sense. The more on the fringe a language is, the less it will change,
and the less it *should* change. Also, the better a language is, the
less it will change, and the less it *should* change. I think every
posting to c.l.l would agree that CL is not only on the fringe, but also
among the very best general purpose languages available (as long as
popularity is not a major concern). So it is not surprising that it
doesn't change much. How should it?
Michael
·······@bcect.com (Michael Sullivan) writes:
> AFAICT, the ways in which CL is broken (in the sense of not being easy
> to use for certain tasks) are already being worked on in implementation
> and library efforts. The one way you have identified, IMO can't be
> fixed by changing the language arbitrarily.
Let's look at Gray and Simple Streams. They are in effect two
competing standards for OO streams. If i need a stream class which
can be built from one or the other, how do I decide which one too
target if I want maximal portability between existing CL
implementations. Right now it meaks picking one and taking
responsibility for ensuring it is portable to target implementations.
There was also a recent discussion about a common web programming API.
There is work on a portable posix api.
Outside of c.l.l I can't think of a place where implementors and users
can come together in a forum to work on establishing new community
standards. In concrete terms -- I would like to start up a discussion
regarding streams with representatives from the commercial vendors,
the free CL hackers, and other users. I would like the discussion to
take place in the context of a process for establishing a conensus and
codifying it.
> The more on the fringe a language is, the less it will change, and
> the less it *should* change. Also, the better a language is, the
> less it will change, and the less it *should* change. I think every
> posting to c.l.l would agree that CL is not only on the fringe, but
> also among the very best general purpose languages available (as
> long as popularity is not a major concern). So it is not surprising
> that it doesn't change much. How should it?
This is not changing the language, as in changing the ANSI CL spec.
It is building upon that fine work. I do have some thoughts on how
the language itself should change, mostly on the fringes.
--
Craig Brozefsky <·····@onshored.com> Senior Programmer
onShore Development http://www.onshore-devel.com
Free Common Lisp Software http://alpha.onshored.com/lisp-software
In article <······························@bcect.com>, ·······@bcect.com
(Michael Sullivan) wrote:
> Erann Gat <··························@jpl.nasa.gov> wrote:
>
> > In article <·············@dtpq.com>, ······@dtpq.com (Christopher C.
> > Stacy) wrote:
> >
> > > So if that's not one of the changes you think will help that cause,
> > > how about explaining some of the changes that you do mean.
> >
> > I do not think any particular changes are likely to make much of a
> > difference. I think that the existence of change, and a better process
> > for managing it, might.
>
> The problem with this is that change for change's sake is costly and
> stupid.
I am not advocating change for the sake of change. I am advocating change
for the sake of a marketing strategy. Also, while some changes are
costly, not all changes are. To object to all changes on the grounds that
some changes are costly is not sound reasoning.
> If it ain't broke -- don't fix it.
But it is broke, at least from where I sit. Last Sunday we had a meeting
of CRACL, the Los Angeles area Lisp user's group. Seven people showed
up. Not a single one of them used Lisp at work. (And one person had
given up Lisp entirely for OCaml!) This isn't Podunk, this is the second
largest metropolitan area in the country. There is a major software
industry here serving the entertainment and aerospace sectors, and we
can't muster even a single professional Lisp programmer to show up to a
user's group meeting. To me, that's broke irrespective of how technically
perfect the language may be.
E.
From: Kenny Tilton
Subject: Lisp (TeamKenny) vs C++ (The Bastards!) [was Re: Question about Lisp Coding Style
Date:
Message-ID: <3F713961.1C39DCB1@nyc.rr.com>
Erann Gat wrote:
>
> In article <······························@bcect.com>, ·······@bcect.com
> (Michael Sullivan) wrote:
>
>
> > If it ain't broke -- don't fix it.
>
> But it is broke, at least from where I sit. Last Sunday we had a meeting
> of CRACL, the Los Angeles area Lisp user's group. Seven people showed
> up. Not a single one of them used Lisp at work.
<snip>
> To me, that's broke irrespective of how technically
> perfect the language may be.
Didn't the Dylan experiment demolish the idea that the language is the
problem? What more could they have done to suck up to the Great
Unwashed? And how far did appeasement get them?
Instead of worrying about syntax and fail as miserably as Dylan, why not
help out on RoboCells? One of the threads on the RoboCup mailing list is
about how to handle the rapidly swelling number of teams. RoboCup is
booming, without Lisp, the language that started it and the language of
AI. My mention of my Lisp framework here on c.l.l. brought an inquiry
from a university in Portugal which already has a simulation team as
well as a real robot team. Maybe others of the hundreds of teams would
be interested in a decent Lisp starter client and will jump languages.
But we have to make that easy by providing them with a hot starter
client to copy.
A couple of weeks ago I invited folks here to pitch in on my effort or
that of the lads working on porting TriLearn. Response zilch. With a
little effort from a couple of Lispniks we could penetrate a huge market
of universities and students in a very high visibility area, one with
Lisp written all over it since it is AI. Even if you (or anyone) cannot
help on such short notice, hey, ILC2003 is not the end of RoboCells.
RoboCells is coming along quite nicely, tho. My emphasis has been not on
playing well (tho I might make an exception and hunker down on the
goalie for obvious reasons), but rather on developing a framework that
would facilitate development (authoring, debugging, testing) and provide
hooks to support machine learning. I am looking forward to playing with
that after the conference, right now I have to stop getting fancy and
just teach TeamKenny about taking free kicks when awarded, etc. But I'll
be laying out the framework during my talk on Wednesday.
btw, Turns out we'll be playing against the /real/ TriLearn (the C++
version). If that doesn't make Lispniks rally to the cause...
kenny
PS. Ping Justin Dubs: how is your client coming? Netscape ate my address
book or I'd write directly.
--
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"[If anyone really has healing powers,] I would like to call
them about my knees."
-- Tenzin Gyatso, the Fourteenth Dalai Lama
In article <·················@nyc.rr.com>, Kenny Tilton
<·······@nyc.rr.com> wrote:
> Erann Gat wrote:
> >
> > In article <······························@bcect.com>, ·······@bcect.com
> > (Michael Sullivan) wrote:
> >
> >
> > > If it ain't broke -- don't fix it.
> >
> > But it is broke, at least from where I sit. Last Sunday we had a meeting
> > of CRACL, the Los Angeles area Lisp user's group. Seven people showed
> > up. Not a single one of them used Lisp at work.
> <snip>
> > To me, that's broke irrespective of how technically
> > perfect the language may be.
>
> Didn't the Dylan experiment demolish the idea that the language is the
> problem?
No. The Dylan experiment is actually support for my position. Dylan was
a technical triumph and a marketing disaster. The reason it was a
marketing disaster is because they focused entirely on making it a
technical triumph, and in so doing they forgot all about their
audience/customers. They made "a better Lisp", thus alienating all the
people who don't like Lisp, and then they got rid of S-expressions, thus
alienating all the people who do like Lisp. It's no wonder that no one
uses Dylan. Even today, when Dylan is still technically superior in
nearly every way to e.g. Python, Python wins. Most of the world has never
even heard of Dylan.
The Lisp situation is not quite so grim. Most of the world has at least
heard of Lisp. But "everyone knows" that Lisp isn't really good for real
programming, and it's only used for obscure AI research, and that it's
slow because it's interpreted and whatnot. (For any new people reading
this, all these things are in fact false even though they are widely
believed.)
At JPL, "everyone knows" that Lisp was used on a spacecraft once, and that
the result was a disaster. That's also false, but it doesn't matter. The
sad truth about the world is that the truth is mostly irrelevant. It's
what people believe that counts.
> Instead of worrying about syntax and fail as miserably as Dylan, why not
> help out on RoboCells?
Hm, good question. Let's talk at ILC.
E.
From: Kenny Tilton
Subject: (belated) ANNC: RoboCells [was Re: Lisp (TeamKenny) vs C++ (The Bastards!) [was Re: Question about Lisp Coding Style
Date:
Message-ID: <3F71E883.BC19890@nyc.rr.com>
Erann Gat wrote:
>
> In article <·················@nyc.rr.com>, Kenny Tilton
> <·······@nyc.rr.com>
> > Instead of worrying about syntax and fail as miserably as Dylan, why not
> > help out on RoboCells?
>
> Hm, good question. Let's talk at ILC.
Sorry, my new rule is "No Talking". We got enough talkers, we need Just
Doers. Go here:
https://sourceforge.net/projects/robocells/
...download the $#%&@ing software and get to work. If someone cannot at
least download the software, build it and run it, well, OK, no hard
feelings, but they sure as hell won't do anything else, so I'm gonna go
write some code.
btw, there is a ZIP and a tarball, same source in both. One human being
has notified me that he successfully DLed and built on Linux/CMUCL, tho
he ran into the two issues documented in an errata file you will also
find on the site.
The source includes the full source for Cells. Eventually that will be
maintained separately from the separate Cells sourceforge project, but
right now I felt this would be more conveneient, esp. since the new
challenges of RoboCells are provoking a surprising number of refinements
to the s/w. I'll probably even make lazy propagation an option RSN, so I
can have all sorts of handy dandy world model rules that will not fire
until the player happens actually to call for it.
btw, I am feeling pretty sheepish over here. I think I forgot to
announce RoboCells when I put it up a few weeks ago. What happened was
that I planned to quickly dash off release 1.1 and /then/ make an
announcement, but getting to 1.1 was surprisingly non-trivial. And in
truth, the software is still a little raw for general use, but folks
could at least see if they can build it and run it. There is a pretty
thorough set of install/run instructions in the read me, and I am always
here for questions/problems/bug reports so there should be quick
turnaround on problems.
With game time fast approaching, I am now focussing on the win32 source
and won't be doing anything in re CMUCL/Linux, but on the other hand
nothing I am doing now should create problems. Famous last words, there
will be some surprises, but the energy for finding those surprises and
reporting them will have to come from someone who wants to goof around
with RoboCells.
Great fun, btw.
kenny
--
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"[If anyone really has healing powers,] I would like to call
them about my knees."
-- Tenzin Gyatso, the Fourteenth Dalai Lama
In article <················@nyc.rr.com>, Kenny Tilton
<·······@nyc.rr.com> wrote:
> Erann Gat wrote:
> >
> > In article <·················@nyc.rr.com>, Kenny Tilton
> > <·······@nyc.rr.com>
> > > Instead of worrying about syntax and fail as miserably as Dylan, why not
> > > help out on RoboCells?
> >
> > Hm, good question. Let's talk at ILC.
>
> Sorry, my new rule is "No Talking".
Why are you even bothering to go to ILC then? Oh, right, it's because
you're giving a presentation. So I guess you don't apply your own rules
to yourself. (And that, by the way, is now my answer to the question you
posed.)
E.
From: Kenny Tilton
Subject: Re: (belated) ANNC: RoboCells [was Re: Lisp (TeamKenny) vs C++ (The Bastards!) [was Re: Question about Lisp Coding Style
Date:
Message-ID: <m8ncb.16579$nU6.3607265@twister.nyc.rr.com>
Erann Gat wrote:
> In article <················@nyc.rr.com>, Kenny Tilton
> <·······@nyc.rr.com> wrote:
>
>
>>Erann Gat wrote:
>>
>>>In article <·················@nyc.rr.com>, Kenny Tilton
>>><·······@nyc.rr.com>
>>>
>>>>Instead of worrying about syntax and fail as miserably as Dylan, why not
>>>>help out on RoboCells?
>>>
>>>Hm, good question. Let's talk at ILC.
>>
>>Sorry, my new rule is "No Talking".
>
>
> Why are you even bothering to go to ILC then?
I'll be talking to people who might Actually Do Something(tm), and who
don't need me to hold their hand, who get involved because RoboCup is a
blast as well as a chance to do Lisp and help Lisp grow.
Many are called, few are chosen. But I understand that people are pretty
busy already with their current jobs, families, and their own pet
projects, so it is no problem really that others are not pitching in on
RoboCells.
I'll just keep casting the net, esp. when I need a break from programming.
Hey, it turns out one of the RoboCuppers just started an AI class up at
Yale and they are using Lisp /and/ the instructor has done RoboCup. I
have to look into that as a possible way to grow Lisp.
What are you doing today to grow Lisp?
kenny
In article <·······················@twister.nyc.rr.com>, Kenny Tilton
<·······@nyc.rr.com> wrote:
> What are you doing today to grow Lisp?
Working on my ILC presentation.
E.
From: Kenny Tilton
Subject: Re: (belated) ANNC: RoboCells [was Re: Lisp (TeamKenny) vs C++ (The Bastards!) [was Re: Question about Lisp Coding Style
Date:
Message-ID: <0Xocb.29133$u67.21613@twister.nyc.rr.com>
Erann Gat wrote:
> In article <·······················@twister.nyc.rr.com>, Kenny Tilton
> <·······@nyc.rr.com> wrote:
>
>
>>What are you doing today to grow Lisp?
>
>
> Working on my ILC presentation.
<chew>
Anything like the depressing handwringing over Lisp not being more
popular like the one at LUGM '99? That does nothing to grow Lisp. </chew>
kenny
In article <·····················@twister.nyc.rr.com>, Kenny Tilton
<·······@nyc.rr.com> wrote:
> Erann Gat wrote:
> > In article <·······················@twister.nyc.rr.com>, Kenny Tilton
> > <·······@nyc.rr.com> wrote:
> >
> >
> >>What are you doing today to grow Lisp?
> >
> >
> > Working on my ILC presentation.
>
> <chew>
> Anything like the depressing handwringing over Lisp not being more
> popular like the one at LUGM '99? That does nothing to grow Lisp. </chew>
Asking have-you-stopped-beating-your-wife-yet type questions doesn't help
much either. I did not give a presentation at LUGM '99, depressing or
otherwise. In fact, I have never given a presentation at a Lisp
conference before; this year's will be my first. It's entitled "Locales:
First-Class Lexical Environments for Common Lisp". Whether that's
depressing or not you'll have to judge for yourself.
E.
From: Kenny Tilton
Subject: Re: (belated) ANNC: RoboCells [was Re: Lisp (TeamKenny) vs C++ (The Bastards!) [was Re: Question about Lisp Coding Style
Date:
Message-ID: <twrcb.16620$nU6.3705086@twister.nyc.rr.com>
Erann Gat wrote:
> In article <·····················@twister.nyc.rr.com>, Kenny Tilton
> <·······@nyc.rr.com> wrote:
>
>
>>Erann Gat wrote:
>>
>>>In article <·······················@twister.nyc.rr.com>, Kenny Tilton
>>><·······@nyc.rr.com> wrote:
>>>
>>>
>>>
>>>>What are you doing today to grow Lisp?
>>>
>>>
>>>Working on my ILC presentation.
>>
>><chew>
>>Anything like the depressing handwringing over Lisp not being more
>>popular like the one at LUGM '99? That does nothing to grow Lisp. </chew>
>
>
> Asking have-you-stopped-beating-your-wife-yet type questions doesn't help
> much either. I did not give a presentation at LUGM '99, depressing or
> otherwise.
Oh. My bad. Who was it that got up and just started talking about Lisp
being so unpopular and what the hell were we going to do? Gabriel made
the only interesting suggestion: "Pick a fight.".
kenny
In article <·······················@twister.nyc.rr.com>, Kenny Tilton
<·······@nyc.rr.com> wrote:
> Erann Gat wrote:
>
> > In article <·····················@twister.nyc.rr.com>, Kenny Tilton
> > <·······@nyc.rr.com> wrote:
> >
> >
> >>Erann Gat wrote:
> >>
> >>>In article <·······················@twister.nyc.rr.com>, Kenny Tilton
> >>><·······@nyc.rr.com> wrote:
> >>>
> >>>
> >>>
> >>>>What are you doing today to grow Lisp?
> >>>
> >>>
> >>>Working on my ILC presentation.
> >>
> >><chew>
> >>Anything like the depressing handwringing over Lisp not being more
> >>popular like the one at LUGM '99? That does nothing to grow Lisp. </chew>
> >
> >
> > Asking have-you-stopped-beating-your-wife-yet type questions doesn't help
> > much either. I did not give a presentation at LUGM '99, depressing or
> > otherwise.
>
> Oh. My bad. Who was it that got up and just started talking about Lisp
> being so unpopular and what the hell were we going to do?
My memories of LUGM99 are very vague. It's possible I said something like
that at a BoF session or over lunch or some such thing. What difference
does it make now, four years later? (And do you really think that these
snarky insinuations are going to be productive?)
> Gabriel made the only interesting suggestion: "Pick a fight.".
I don't think he meant with me.
E.
From: Kenny Tilton
Subject: Re: (belated) ANNC: RoboCells [was Re: Lisp (TeamKenny) vs C++ (The Bastards!) [was Re: Question about Lisp Coding Style
Date:
Message-ID: <ghCcb.13636$lZ6.4039792@twister.nyc.rr.com>
Erann Gat wrote:
> My memories of LUGM99 are very vague. It's possible I said something like
> that at a BoF session or over lunch or some such thing. What difference
> does it make now, four years later?
You were the one who offered your ILC talk when I asked what you were
doing to grow Lisp. Hopefully it is about exciting new software
development directions. Whoever it was at the front of the room that led
to, yes, an open discussion of Lisp's popularity, I just recall it being
a very depressing half hour or so for everyone, to no good end.
People are finding their way to CL on their own, and there is probably
nothing we can do to change that either way. They are coming because the
imperative, static typing, non-reflective languages have hit a
productivity ceiling, one which can be punched through only with
precisely the features we love in Lisp. Calling it Ciel or Arc or
changing *this* to $that is just silly. People will wake up when they
are good and ready, and it will be one at a time and Early Adopters in
very small numbers who start the process. That is why I did the Road to
Lisp Survey, to highlight those individuals (tho old farts were not
excluded):
RoboCup is one interesting possible exception. It has (it seems) a ton
of energy and momentum, and it involves schools which involve students,
aka the next generation. And the fit is a natural, because it is really
an AI collaboration, and we all know Lisp is an AI language. Hell, this
is probably the only corner of the semantic universe in which the
Conventional Wisdom works for us. Hey! A Lisp framework!! Let's use
that! That rooolz for AI!!!
And it is fun.
(And do you really think that these
> snarky insinuations are going to be productive?)
You got me on "snarky":
from http://www.urbandictionary.com/define.php?term=snarky
> snarky
> "snark-ee"
>
> (adjective) describes a witty mannerism, personality, or behavior that is a combination of sarcasm and cynicism. Usually accepted as a complimentary term. Snark is sometimes mistaken for a snotty or arrogant attitude.
>
> Her snarky remarks had half the room on the floor laughing and the other half ready to walk out.
I can live with that. Productive? No, just trying to stay dry from your
rain on this parade. Some folks have a knack for unhappiness. Here we
have a language which is a pure joy to use (if you use Cells), yet some
still manage to be unhappy because they cannot use it at work. So? Use
it at home. Work on any of the great projects out there which when
polished enough will attract new faces.
kenny
In article <·······················@twister.nyc.rr.com>, Kenny Tilton
<·······@nyc.rr.com> wrote:
> Erann Gat wrote:
>
> > My memories of LUGM99 are very vague. It's possible I said something like
> > that at a BoF session or over lunch or some such thing. What difference
> > does it make now, four years later?
>
> You were the one who offered your ILC talk when I asked what you were
> doing to grow Lisp. Hopefully it is about exciting new software
> development directions. Whoever it was at the front of the room that led
> to, yes, an open discussion of Lisp's popularity, I just recall it being
> a very depressing half hour or so for everyone, to no good end.
The first step in solving a problem is recognizing that it exists. That
is often unpleasant, which is unfortunate, but that's just the way things
are. Shooting the messenger is a popular but ineffective response. (So
is burying your head in the sand.)
> People are finding their way to CL on their own, and there is probably
> nothing we can do to change that either way. They are coming because the
> imperative, static typing, non-reflective languages have hit a
> productivity ceiling, one which can be punched through only with
> precisely the features we love in Lisp.
Yes. That's one of the reasons Python is becoming so popular.
> Calling it Ciel or Arc or changing *this* to $that is just silly.
Just ten minutes ago I was talking to a program manager here at JPL who
was telling me about how they are having a much easier time getting
funding for the "Laboratory for Reliable Software" than they did for the
"Center for Space Mission Information and Software Systems" despite the
fact that the two things are one and the same. The sad truth about the
world is that silly things matter a lot more than they should.
> I can live with that. Productive? No, just trying to stay dry from your
> rain on this parade. Some folks have a knack for unhappiness. Here we
> have a language which is a pure joy to use (if you use Cells), yet some
> still manage to be unhappy because they cannot use it at work. So? Use
> it at home. Work on any of the great projects out there which when
> polished enough will attract new faces.
We have a fundamentally different outlook on this. I do not consider
using Common Lisp "a pure joy". The things I would call "pure joy"
include dinner at Spago, doing spins in a Falco, hiking the Sierras, and a
few activities I can't mention because the JPL Thought Police are
watching. Programming in Common Lisp is for me not even in the same
league. It's a hell of a lot more fun than programming in C++, but just
about anything short of a root canal is more fun than programming in C++
(and there are times when I'm ambivalent about the root canal).
For me, Lisp is a means to an end. It is a way of getting things done
that is faster and more effective than other ways of getting things done
so I have more time left over at the end of the day to do the things that
really matter in life. I don't care about Common Lisp's popularity for
its own sake. I care about it because life is too short to waste
programming in C++. But more than that, life is too rich to spend too
much of it *programming*. Programming can be fun, but it's just one thing
in life, at least in my life. If your passion is programming that's
fine. Just don't expect everyone to share it.
So you see, not worrying about the situation and "just using CL at home"
would completely defeat the purpose as far as I'm concerned.
E.
From: Kenny Tilton
Subject: Re: (belated) ANNC: RoboCells [was Re: Lisp (TeamKenny) vs C++ (The Bastards!) [was Re: Question about Lisp Coding Style
Date:
Message-ID: <5gMcb.16440$lZ6.4210046@twister.nyc.rr.com>
Erann Gat wrote:
> We have a fundamentally different outlook on this. I do not consider
> using Common Lisp "a pure joy". The things I would call "pure joy"
> include dinner at Spago, doing spins in a Falco, hiking the Sierras, and a
> few activities I can't mention because the JPL Thought Police are
> watching. Programming in Common Lisp is for me not even in the same
> league. It's a hell of a lot more fun than programming in C++, but just
> about anything short of a root canal is more fun than programming in C++
> (and there are times when I'm ambivalent about the root canal).
Boy do we differ. Some of the most fun I've had was doing a front-end
for insurance policy capture in COBOL. I ended up teaching programming
to a crossover employee (changing careers) from accounting at the same
job. When after three weeks she managed to get a simple menu thingy
working and instead of breaking it I said, OK, Look's good, she just
flipped. And she asked, Does this feeling go away, or does it always
feel so good to get something working? I reassured her it never goes
away. Maybe you never felt that way at all.
>
> For me, Lisp is a means to an end.
Bingo. Just two days ago while working on RoboCells I almost felt high.
Might have been the caffeine and ma huang, but the coding was a delight.
I had broken thru a blind spot and the goalie was zipping about
precisely and without fuss like it never had before. Weeks of staring at
the idiot spinning and wiggling and jerking around, and all of sudden
I've got Pele in goal. You don't love that sh*t?
I feel sorry for you. I am as happy going to work as I am snowboarding
or speedskating or dance skating, or sitting down to savor a bottle of
beer and some Oreos.
kenny
In article <·······················@twister.nyc.rr.com>, Kenny Tilton
<·······@nyc.rr.com> wrote:
> Maybe you never felt that way at all.
Maybe you've never done spins in a Falco.
> I feel sorry for you.
Don't worry about me. I'll be fine.
E.
----
"Good enough" is the death knell of progress.
From: Raffael Cavallaro
Subject: Re: (belated) ANNC: RoboCells [was Re: Lisp (TeamKenny) vs C++ (The Bastards!) [was Re: Question about Lisp Coding Style
Date:
Message-ID: <aeb7ff58.0309261639.6e136e99@posting.google.com>
Kenny Tilton <·······@nyc.rr.com> wrote in message news:<·······················@twister.nyc.rr.com>...
> Might have been the caffeine and ma huang
[snip]
> or sitting down to savor a bottle of
> beer and some Oreos.
If you routinely combine, on the one hand, caffeine and ma huang
(a.k.a, ephedra sinica), and, on the other, beer and Oreos, you must
be high _all_ the time ;^)
Seriously, though, the caffeine and ma huang combo could kill you -
that pairing has caused fatal heart attacks and strokes. Be careful.
From: Kenny Tilton
Subject: Re: (belated) ANNC: RoboCells [was Re: Lisp (TeamKenny) vs C++ (The Bastards!) [was Re: Question about Lisp Coding Style
Date:
Message-ID: <L56db.28612$nU6.4590948@twister.nyc.rr.com>
Raffael Cavallaro wrote:
> Kenny Tilton <·······@nyc.rr.com> wrote in message news:<·······················@twister.nyc.rr.com>...
>
>
>>Might have been the caffeine and ma huang
>
> [snip]
>
>>or sitting down to savor a bottle of
>>beer and some Oreos.
>
>
> If you routinely combine, on the one hand, caffeine and ma huang
> (a.k.a, ephedra sinica), and, on the other, beer and Oreos, you must
> be high _all_ the time ;^)
>
> Seriously, though, the caffeine and ma huang combo could kill you -
> that pairing has caused fatal heart attacks and strokes. Be careful.
Hey, thx for your concern. They're not that bad, though. Every few years
an athlete puts on a sweat suit, takes ephedra, and then runs around for
hours in the sun to make weight and kills themself and ephedra takes the
fall, but it's a bum rap.
kenny
ps. i was kidding about the oreos. That was a line from the old Mary
Tyler Moore show, it was Lou's typical breakfast after he separated from
his wife. :)
In article <·······················@twister.nyc.rr.com>,
Kenny Tilton <·······@nyc.rr.com> wrote:
> Every few years
> an athlete puts on a sweat suit, takes ephedra, and then runs around for
> hours in the sun to make weight and kills themself and ephedra takes the
> fall, but it's a bum rap.
Statistical evidence from clinical trials, not merely anecdote,
indicates that the ephedra caffeine combination increases the liklihood
of palpitations, autonomic hpyeractivity, vomiting, and psychiatric
symptoms. See: <http://ods.od.nih.gov/factsheets/ephedra.html>
raf
From: Kenny Tilton
Subject: Re: (belated) ANNC: RoboCells [was Re: Lisp (TeamKenny) vs C++ (The Bastards!) [was Re: Question about Lisp Coding Style
Date:
Message-ID: <E1hdb.18323$lZ6.4776351@twister.nyc.rr.com>
Raffael Cavallaro wrote:
> In article <·······················@twister.nyc.rr.com>,
> Kenny Tilton <·······@nyc.rr.com> wrote:
>
>
>> Every few years
>>an athlete puts on a sweat suit, takes ephedra, and then runs around for
>>hours in the sun to make weight and kills themself and ephedra takes the
>>fall, but it's a bum rap.
>
>
> Statistical evidence from clinical trials, not merely anecdote,
> indicates that the ephedra caffeine combination increases the liklihood
> of palpitations, autonomic hpyeractivity, vomiting, and psychiatric
> symptoms. See: <http://ods.od.nih.gov/factsheets/ephedra.html>
Well, again, thanks for the concern, but it says there:
"# Results of controlled trials show that the use of ephedrine,
ephedrine plus caffeine, or ephedra plus botanicals containing caffeine
is associated with 2-3 times the risk of nausea, vomiting, psychiatric
symptoms such as anxiety and change in mood, autonomic hyperactivity,
and palpitations compared with placebo.
"# RAND analyzed adverse event reports filed with the U.S. Food and Drug
Administration (FDA) and with a manufacturer of ephedra-containing
dietary supplements as well as published case reports. Although this
analysis raises concerns about the safety of botanical dietary
supplements containing ephedra, most of these case reports are not
documented sufficiently to support an informed judgment about the
relationship between the use of ephedra-containing dietary supplements
or ephedrine and the adverse event in question.
# According to the RAND report, the number of deaths, myocardial
infarctions, cerebrovascular accidents, seizures, and serious
psychiatric illnesses in young adults is sufficient to warrant a
hypothesis-testing study, such as a case-control study, to test the
possibility that consumption of ephedra or ephedrine causes these
serious adverse events."
The warnings on my bottle of Advil are scarier. :) But you are right,
actually, ephedra is nasty stuff, so I only use it when I am training
hard to shed weight or when preparing for ILC2003, and as you suggested,
I am careful.
<cue the band>
But if I don't make it to ILC, if I shuffle off this mortal choir to
sing with the choir eternal and push up daisies, let it be remembered
that my only regret is that I have but one life to give for Lisp, The
Language to Die For(tm).
:)
kenny
··························@jpl.nasa.gov (Erann Gat) writes:
> In article <·······················@twister.nyc.rr.com>, Kenny Tilton
> <·······@nyc.rr.com> wrote:
>
>> Erann Gat wrote:
>>
>> > My memories of LUGM99 are very vague. It's possible I said something like
[...]
>> development directions. Whoever it was at the front of the room that led
>> to, yes, an open discussion of Lisp's popularity, I just recall it being
>> a very depressing half hour or so for everyone, to no good end.
>
> The first step in solving a problem is recognizing that it exists. That
> is often unpleasant, which is unfortunate, but that's just the way things
> are. Shooting the messenger is a popular but ineffective response. (So
> is burying your head in the sand.)
OK, that's the first step. The following n steps include equally
important tasks like creating a plan to fix the problem, and
implementing that plan.
There was an open discussion at ILC2002 about Lisp's popularity too.
Three years later and we're still hung up on identifying there's a
problem? Can we not just take that as read and get on with it, yet?
> So you see, not worrying about the situation and "just using CL at home"
> would completely defeat the purpose as far as I'm concerned.
Except to the extent, if any, that using CL at home has some effect on
the Lisp community or on potential Lisp users.
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
In article <··············@noetbook.telent.net>, Daniel Barlow
<···@telent.net> wrote:
> > So you see, not worrying about the situation and "just using CL at home"
> > would completely defeat the purpose as far as I'm concerned.
>
> Except to the extent, if any, that using CL at home has some effect on
> the Lisp community or on potential Lisp users.
The word "just" in my comment is significant. I do in fact use CL at home
(and at work too when I can, which nowadays isn't nearly as often as I'd
like). I do enjoy programming. I do enjoy the thrill of making something
work. But it's not my whole life.
But your point is well taken, which is why I do spend some of my spare
time doing things like writing guides for beginners on what seem to be
some of the more confusing aspects of CL. And I even manage to get in a
bit of hacking now and then. But I hacked Lisp professionally for over
ten years (and generated a fair number of success stories, some of them
highly visible) and Lisp's popularity plummeted regardless. It just
doesn't seem likely that what little hacking I can now manage in my spare
time is going to have much of an effect. (Not that that's going to stop
me from hacking, just that it seems prudent to also pursue other courses
of action at the same time.)
E.
Erann Gat writes:
> highly visible) and Lisp's popularity plummeted regardless. It just
> doesn't seem likely that what little hacking I can now manage in my spare
> time is going to have much of an effect. (Not that that's going to stop
Linus Torvalds might have had similar thoughts.
Paolo
--
Paolo Amoroso <·······@mclink.it>
··························@jpl.nasa.gov (Erann Gat) writes:
> The first step in solving a problem is recognizing that it exists. That
> is often unpleasant, which is unfortunate, but that's just the way things
> are. Shooting the messenger is a popular but ineffective response. (So
> is burying your head in the sand.)
Don't forget redefining the problem away, passing new laws, spending
more money, creating a task force, and doing demonstrably useless and
futile things because `we can't just do *nothing*'.
And the grandaddy of them all: assigning blame.
From: Thomas F. Burdick
Subject: Re: (belated) ANNC: RoboCells [was Re: Lisp (TeamKenny) vs C++ (The Bastards!) [was Re: Question about Lisp Coding Style
Date:
Message-ID: <xcvad8svavk.fsf@famine.OCF.Berkeley.EDU>
Kenny Tilton <·······@nyc.rr.com> writes:
> You got me on "snarky":
Before you go self-identifying as "snarky", you might want to consider
identifying as a playahata. I've been playahatin on C++ at every
opportunity, and with some success.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: Pascal Costanza
Subject: Re: (belated) ANNC: RoboCells [was Re: Lisp (TeamKenny) vs C++ (The Bastards!) [was Re: Question about Lisp Coding Style
Date:
Message-ID: <bkut0m$17sc$1@f1node01.rhrz.uni-bonn.de>
Kenny Tilton wrote:
> People are finding their way to CL on their own, and there is probably
> nothing we can do to change that either way. They are coming because the
> imperative, static typing, non-reflective languages have hit a
> productivity ceiling, one which can be punched through only with
> precisely the features we love in Lisp. Calling it Ciel or Arc or
> changing *this* to $that is just silly. People will wake up when they
> are good and ready, and it will be one at a time and Early Adopters in
> very small numbers who start the process.
That's only one side of the story - although it's surely an important one.
However, the other side consists of the people who do not do the actual
programming but nevertheless make and/or influence technical decisions.
[1] They need to be fed somehow. Or so some people think.
Think about XML: and extremely bad variant of s-expressions. However,
they have made no reference to s-expressions, call it "new", and so the
non-programmers swallow it. The "new" Lisp dialects aim at something
similar.
I don't know whether these are actually good ideas. But keep in mind
that they are aimed at other target audiences than you might think of.
Pascal
[1] Sometimes they are managers, but probably even worse are
ex-programmers who switched to management jobs too early.
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
From: Kenny Tilton
Subject: Re: (belated) ANNC: RoboCells [was Re: Lisp (TeamKenny) vs C++ (The Bastards!) [was Re: Question about Lisp Coding Style
Date:
Message-ID: <i8Dcb.13817$lZ6.4055553@twister.nyc.rr.com>
Pascal Costanza wrote:
> Think about XML: and extremely bad variant of s-expressions. However,
> they have made no reference to s-expressions, call it "new", and so the
> non-programmers swallow it.
Not because it was new, but because it was like HTML, the same trick
C++, Java, and Python used, staying close to the "C" motherlode. Java
added GC, OO, and the promise of portability. Python added
interactivity/RAD. But they stood close to "C".
kenny
From: Gareth McCaughan
Subject: Re: (belated) ANNC: RoboCells [was Re: Lisp (TeamKenny) vs C++ (The Bastards!) [was Re: Question about Lisp Coding Style
Date:
Message-ID: <87eky439dc.fsf@g.mccaughan.ntlworld.com>
Kenny Tilton wrote:
> Not because it was new, but because it was like HTML, the same trick
> C++, Java, and Python used, staying close to the "C" motherlode. Java
> added GC, OO, and the promise of portability. Python added
> interactivity/RAD. But they stood close to "C".
I don't think Python is very close to C. It's
- not natively compiled
- largely free of curly braces
- dynamically typed
- possessed of a rather large standard library for doing
high-ish level things
- locally verbose rather than locally terse[1]
- garbage collected
- free of explicit pointers
It resembles C in having infix syntax and a few common
bits of syntactic heritage (square brackets for lookup
operators, mandatory parens and commas for function
application) that are equally shared by, say, Pascal.
[1] The word "locally" is important here. Lisp is locally
verbose too (WITH-STANDARD-IO-SYNTAX, MULTIPLE-VALUE-BIND,
etc) but globally very concise. Python is locally less
verbose than CL, but (like just about everything else)
globally more verbose.
--
Gareth McCaughan
.sig under construc
From: Kenny Tilton
Subject: Re: (belated) ANNC: RoboCells [was Re: Lisp (TeamKenny) vs C++ (The Bastards!) [was Re: Question about Lisp Coding Style
Date:
Message-ID: <N2Lcb.16235$lZ6.4179001@twister.nyc.rr.com>
Gareth McCaughan wrote:
> Kenny Tilton wrote:
>
>
>>Not because it was new, but because it was like HTML, the same trick
>>C++, Java, and Python used, staying close to the "C" motherlode. Java
>>added GC, OO, and the promise of portability. Python added
>>interactivity/RAD. But they stood close to "C".
>
>
> I don't think Python is very close to C. It's...
<a bunch of things I was not thinking of>
Unless I am grievously mistaken (I might be!) Python calls C seamlessly.
No FFI. That is what I meant by staying close to the motherlode: all
those libraries are just there for the asking. CL is not far off, I
would say, having done a bunch of FFI work getting CL to talk to OpenGL,
but then I had to do it repeatedly because I was trying to do a
universal CL library (and the U in UFFI is a bit of marketing Erann
would like a lot <g>). And some things such as callbacks from C were
extremely problematic. Mind you, I have no idea if Python can be called
from C!
kt
> - not natively compiled
> - largely free of curly braces
> - dynamically typed
> - possessed of a rather large standard library for doing
> high-ish level things
> - locally verbose rather than locally terse[1]
> - garbage collected
> - free of explicit pointers
>
> It resembles C in having infix syntax and a few common
> bits of syntactic heritage (square brackets for lookup
> operators, mandatory parens and commas for function
> application) that are equally shared by, say, Pascal.
>
>
> [1] The word "locally" is important here. Lisp is locally
> verbose too (WITH-STANDARD-IO-SYNTAX, MULTIPLE-VALUE-BIND,
> etc) but globally very concise. Python is locally less
> verbose than CL, but (like just about everything else)
> globally more verbose.
>
Kenny Tilton <·······@nyc.rr.com> writes:
> Unless I am grievously mistaken (I might be!) Python calls C
> seamlessly. No FFI. That is what I meant by staying close to the
> motherlode: all those libraries are just there for the asking. CL is
> not far off, I would say, having done a bunch of FFI work getting CL
> to talk to OpenGL, but then I had to do it repeatedly because I was
> trying to do a universal CL library.
As an aside, Corman Common Lisp has a terrific FFI to C.
It can parse C headers and generate the FFI on the fly, so calling
C from lisp is embarassingly easy.
Joe Marshall wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>Unless I am grievously mistaken (I might be!) Python calls C
>>seamlessly. No FFI. That is what I meant by staying close to the
>>motherlode: all those libraries are just there for the asking. CL is
>>not far off, I would say, having done a bunch of FFI work getting CL
>>to talk to OpenGL, but then I had to do it repeatedly because I was
>>trying to do a universal CL library.
>
>
> As an aside, Corman Common Lisp has a terrific FFI to C.
> It can parse C headers and generate the FFI on the fly, so calling
> C from lisp is embarassingly easy.
I played with that. The header files need massaging to handle the edge
cases, yes? But it is still a neat hack.
You know, it seems to me that it would be nice if CL implementations
simply read C headers, and as effectively as do C compilers. Of course
now the "LIbraries to Die For" are Java, so it may be too late. Franz
probably made a good move when they added interlanguage bridges to Java.
kenny
On Fri, 26 Sep 2003 13:16:40 GMT, Kenny Tilton <·······@nyc.rr.com>
wrote:
>
>You know, it seems to me that it would be nice if CL implementations
>simply read C headers, and as effectively as do C compilers. Of course
>now the "LIbraries to Die For" are Java, so it may be too late. Franz
>probably made a good move when they added interlanguage bridges to Java.
>
"Libraries to Die For", I think you should trademark that one Kenny.
:)
Doug Tolton
(format t ···@~a~a.~a" "dtolton" "ya" "hoo" "com")
Kenny Tilton <·······@nyc.rr.com> writes:
> Gareth McCaughan wrote:
>
>> Kenny Tilton wrote:
>>
>>>Not because it was new, but because it was like HTML, the same trick
>>>C++, Java, and Python used, staying close to the "C" motherlode. Java
>>>added GC, OO, and the promise of portability. Python added
>>>interactivity/RAD. But they stood close to "C".
>> I don't think Python is very close to C. It's...
>
> <a bunch of things I was not thinking of>
>
> Unless I am grievously mistaken (I might be!) Python calls C
> seamlessly. No FFI.
This is incorrect... Python requires "shim" code for
integrating with C. This code is written in C, which is obviously an
inferior solution compared to doing the integration from the
higher-level language :-)
The "shim" code is concerned with marshalling/demarshalling of
arguments, return codes and exceptions.
--
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/
Raymond Wiker <·············@fast.no> writes:
> Kenny Tilton <·······@nyc.rr.com> writes:
> > Unless I am grievously mistaken (I might be!) Python calls C
> > seamlessly. No FFI.
>
> This is incorrect... Python requires "shim" code for
> integrating with C. This code is written in C, which is obviously an
> inferior solution compared to doing the integration from the
> higher-level language :-)
For a more complete picture: (1) Writing FFI code in C is not inferior
if you never do it, but use tools which do it automatically for you
(swig is frequently used and does an ok job, often requiring little or
no manual interaction). (2) Some people also use a python-like
language for C-interfacing: http://ldots.org/pyrex-guide/
Matthias wrote:
> Raymond Wiker <·············@fast.no> writes:
>
>
>>Kenny Tilton <·······@nyc.rr.com> writes:
>>
>>>Unless I am grievously mistaken (I might be!) Python calls C
>>>seamlessly. No FFI.
>>
>> This is incorrect... Python requires "shim" code for
>>integrating with C. This code is written in C, which is obviously an
>>inferior solution compared to doing the integration from the
>>higher-level language :-)
>
>
> For a more complete picture: (1) Writing FFI code in C is not inferior
> if you never do it, but use tools which do it automatically for you
> (swig is frequently used and does an ok job, often requiring little or
> no manual interaction). (2) Some people also use a python-like
> language for C-interfacing: http://ldots.org/pyrex-guide/
And because Python is standard (is it?!) across all platforms, folks who
by whatever means glue Python to their favorite library then turn around
and share it.
So it's not /that/ easy to get to C, but a lot of C libs end up
available and across all platforms at once. Thx for the corrections,
everyone.
kenny
Raymond Wiker <·············@fast.no> writes:
> Python requires "shim" code for integrating with C. This code is
> written in C, which is obviously an inferior solution compared to
> doing the integration from the higher-level language :-)
If you prefer C++, Boost.Python makes this task easier.�
Footnotes:
� http://www.boost.org/libs/python/doc/index.html
http://www.boost.org/libs/python/doc/tutorial/index.html
--
Steven E. Harris :: ········@raytheon.com
Raytheon :: http://www.raytheon.com
Steven E. Harris <········@raytheon.com> writes:
> Raymond Wiker <·············@fast.no> writes:
>
>> Python requires "shim" code for integrating with C. This code is
>> written in C, which is obviously an inferior solution compared to
>> doing the integration from the higher-level language :-)
>
> If you prefer C++, Boost.Python makes this task easier.�
>
>
> Footnotes:
> � http://www.boost.org/libs/python/doc/index.html
> http://www.boost.org/libs/python/doc/tutorial/index.html
Now *this* looks interesting... thanks! (Note: I don't really
*like* C++ (or Python)) :-)
--
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/
From: Doug Tolton
Subject: Re: (belated) ANNC: RoboCells [was Re: Lisp (TeamKenny) vs C++ (The Bastards!) [was Re: Question about Lisp Coding Style
Date:
Message-ID: <ccg8nvsmfr0qr11s8dpdpk85ah6f67aejh@4ax.com>
On Thu, 25 Sep 2003 23:41:33 GMT, Kenny Tilton <·······@nyc.rr.com>
wrote:
>
>Unless I am grievously mistaken (I might be!) Python calls C seamlessly.
>No FFI. That is what I meant by staying close to the motherlode: all
>those libraries are just there for the asking. CL is not far off, I
>would say, having done a bunch of FFI work getting CL to talk to OpenGL,
>but then I had to do it repeatedly because I was trying to do a
>universal CL library (and the U in UFFI is a bit of marketing Erann
>would like a lot <g>). And some things such as callbacks from C were
>extremely problematic. Mind you, I have no idea if Python can be called
>from C!
>
The reason python Integrates so seamlessly with C is because it is
written in C. There are two main branch variants of Python, they are
called CPython (the main python) and Jython (Java Based). CPython
gives you fantastic integration with C and of course Jython integrates
seamlessly with Java. The Python team has kept extensibility in C as
a priority during the development. Yes you can call back into Python
from C, but I don't know what the limitations are there, because I
haven't done that.
Something that I've found interesting in working a lot with Python is
how good it's integration with other languages is. You can build a
Python COM component and call it from VB or C#. We use late binding
when doing so, but I've looked at how it's laid out, and I believe
static binding should work too. We are also working on a project
where we are *forced* to use IE (ugh) but we want to automate the
processing of certain web pages. We have been able to load the IE
ActiveX control into python and operate against it. They are very
serious about being the glue language that holds things together.
Doug Tolton
(format t ···@~a~a.~a" "dtolton" "ya" "hoo" "com")
From: Marco Antoniotti
Subject: Re: (belated) ANNC: RoboCells [was Re: Lisp (TeamKenny) vs C++ (The Bastards!) [was Re: Question about Lisp Coding Style
Date:
Message-ID: <3F78492D.7000507@cs.nyu.edu>
Doug Tolton wrote:
> On Thu, 25 Sep 2003 23:41:33 GMT, Kenny Tilton <·······@nyc.rr.com>
> wrote:
>
>
>>Unless I am grievously mistaken (I might be!) Python calls C seamlessly.
>>No FFI. That is what I meant by staying close to the motherlode: all
>>those libraries are just there for the asking. CL is not far off, I
>>would say, having done a bunch of FFI work getting CL to talk to OpenGL,
>>but then I had to do it repeatedly because I was trying to do a
>>universal CL library (and the U in UFFI is a bit of marketing Erann
>>would like a lot <g>). And some things such as callbacks from C were
>>extremely problematic. Mind you, I have no idea if Python can be called
>
>>from C!
>
>
> The reason python Integrates so seamlessly with C is because it is
> written in C. There are two main branch variants of Python, they are
> called CPython (the main python) and Jython (Java Based). CPython
> gives you fantastic integration with C and of course Jython integrates
> seamlessly with Java. The Python team has kept extensibility in C as
> a priority during the development. Yes you can call back into Python
> from C, but I don't know what the limitations are there, because I
> haven't done that.
>
> Something that I've found interesting in working a lot with Python is
> how good it's integration with other languages is. You can build a
> Python COM component and call it from VB or C#.
You can do the same with Common Lisp. (Of course I am being deliberately
vague here :) of course you cannot do it with CMUCL!)
Cheers
--
Marco
From: Doug Tolton
Subject: Re: (belated) ANNC: RoboCells [was Re: Lisp (TeamKenny) vs C++ (The Bastards!) [was Re: Question about Lisp Coding Style
Date:
Message-ID: <caqgnv0q0p65ejmt9ab6jqdlcocueiff55@4ax.com>
On Mon, 29 Sep 2003 11:01:01 -0400, Marco Antoniotti
<·······@cs.nyu.edu> wrote:
>
>
>Doug Tolton wrote:
>> On Thu, 25 Sep 2003 23:41:33 GMT, Kenny Tilton <·······@nyc.rr.com>
>> wrote:
>>
>>
>>>Unless I am grievously mistaken (I might be!) Python calls C seamlessly.
>>>No FFI. That is what I meant by staying close to the motherlode: all
>>>those libraries are just there for the asking. CL is not far off, I
>>>would say, having done a bunch of FFI work getting CL to talk to OpenGL,
>>>but then I had to do it repeatedly because I was trying to do a
>>>universal CL library (and the U in UFFI is a bit of marketing Erann
>>>would like a lot <g>). And some things such as callbacks from C were
>>>extremely problematic. Mind you, I have no idea if Python can be called
>>
>>>from C!
>>
>>
>> The reason python Integrates so seamlessly with C is because it is
>> written in C. There are two main branch variants of Python, they are
>> called CPython (the main python) and Jython (Java Based). CPython
>> gives you fantastic integration with C and of course Jython integrates
>> seamlessly with Java. The Python team has kept extensibility in C as
>> a priority during the development. Yes you can call back into Python
>> from C, but I don't know what the limitations are there, because I
>> haven't done that.
>>
>> Something that I've found interesting in working a lot with Python is
>> how good it's integration with other languages is. You can build a
>> Python COM component and call it from VB or C#.
>
>You can do the same with Common Lisp. (Of course I am being deliberately
>vague here :) of course you cannot do it with CMUCL!)
That's what I've been trying to figure out. There are several
pre-reqs for me to get figured out in order to use it here at work.
Such as database access, working with COM components etc.
Do you know if it's possible to invoke COM components via UFFI?
I will have to play around with CLIM on windows as well.
Doug Tolton
(format t ···@~a~a.~a" "dtolton" "ya" "hoo" "com")
From: Marco Antoniotti
Subject: Re: (belated) ANNC: RoboCells [was Re: Lisp (TeamKenny) vs C++ (The Bastards!) [was Re: Question about Lisp Coding Style
Date:
Message-ID: <3F78A1F7.2060503@cs.nyu.edu>
Doug Tolton wrote:
> On Mon, 29 Sep 2003 11:01:01 -0400, Marco Antoniotti
> <·······@cs.nyu.edu> wrote:
>
>
>>
>>Doug Tolton wrote:
>>
>>>
>>>Something that I've found interesting in working a lot with Python is
>>>how good it's integration with other languages is. You can build a
>>>Python COM component and call it from VB or C#.
>>
>>You can do the same with Common Lisp. (Of course I am being deliberately
>>vague here :) of course you cannot do it with CMUCL!)
>
>
> That's what I've been trying to figure out. There are several
> pre-reqs for me to get figured out in order to use it here at work.
> Such as database access, working with COM components etc.
>
> Do you know if it's possible to invoke COM components via UFFI?
In principle it should be possible to do that. After all you just need
to build a UFFI library over COM.
However, that is not what I you do in the three different
implementations of Common Lisp (this is obviously a reminder that there
is more than an implementation of Common Lisp) that run under Windows.
ACL and LW provide their own COM interfaces. I did extensive work on LW
4.2.7 COM and some little work on ACL 6.x COM interfaces. The LW one
"feels" more lispy (although that is just me). I do not have experience
in Corman, but I gather that that implementation has a COM layer that is
very close to the C/C++ bare metal.
Cheers
--
Marco
From: Doug Tolton
Subject: Re: (belated) ANNC: RoboCells [was Re: Lisp (TeamKenny) vs C++ (The Bastards!) [was Re: Question about Lisp Coding Style
Date:
Message-ID: <tvo4nv085nl254d16v786838uoel4eh8p8@4ax.com>
On Wed, 24 Sep 2003 20:29:06 GMT, Kenny Tilton <·······@nyc.rr.com>
wrote:
>
>Many are called, few are chosen.
Interesting statement. It has religious overtones where I come from.
I guess you could make the case that this entire newsgroup borders on
religious fanaticism. Would that make Scheme the devil? >:)
Doug Tolton
(format t ···@~a~a.~a" "dtolton" "ya" "hoo" "com")
From: Espen Vestre
Subject: Re: (belated) ANNC: RoboCells [was Re: Lisp (TeamKenny) vs C++ (The Bastards!) [was Re: Question about Lisp Coding Style
Date:
Message-ID: <kw8yodw8nf.fsf@merced.netfonds.no>
Doug Tolton <·······@yahoo.com> writes:
> I guess you could make the case that this entire newsgroup borders on
> religious fanaticism.
Well, don't count me in, I'm a quite non-religious person and Common
Lisp fits that attitude perfectly, because Common Lisp is all about
good tools and, unlike some computer scientist sects, _not_ about
tying up your hands with rope while you program because you will be
rewarded in the programmer's heaven.
--
(espen)
>>>>> "Doug" == Doug Tolton <·······@yahoo.com> writes:
>> Many are called, few are chosen.
Doug> I guess you could make the case that this entire newsgroup borders on
Doug> religious fanaticism.
Well, try to ask a VI related question on alt.religion.emacs.
In fact posting pretty much anything on alt.religion.emacs will
produce wonderfully weird and (at times) incredible funny responses.
Doug> Would that make Scheme the devil? >:)
No, merely a detour to True Enlightment (tm)
Christian
"I may be a fanatic, but my tools are still better than yours"
Lynbech
------------------------+-----------------------------------------------------
Christian Lynbech | christian ··@ defun #\. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- ·······@hal.com (Michael A. Petonic)
On Thu, 25 Sep 2003 11:51:42 +0200, Christian Lynbech
<·················@ericsson.com> wrote:
>>>>>> "Doug" == Doug Tolton <·······@yahoo.com> writes:
>
>>> Many are called, few are chosen.
>
>Doug> I guess you could make the case that this entire newsgroup borders on
>Doug> religious fanaticism.
>
>Well, try to ask a VI related question on alt.religion.emacs.
Why would anyone use VI? :)
I wasn't really serious about this newsgroup being religiously
fanatic. I'm still a newbie, at Lisp and this newsgroup, so I'm not
qualified to make such and unqualified statement. :)
>
>In fact posting pretty much anything on alt.religion.emacs will
>produce wonderfully weird and (at times) incredible funny responses.
>
>Doug> Would that make Scheme the devil? >:)
>
>No, merely a detour to True Enlightment (tm)
Do not try to bend the Scheme, instead try to realize the truth.
What is that?
Only that there is no Scheme.
Doug Tolton
(format t ···@~a~a.~a" "dtolton" "ya" "hoo" "com")
From: Kenny Tilton
Subject: Re: (belated) ANNC: RoboCells [was Re: Lisp (TeamKenny) vs C++ (The Bastards!) [was Re: Question about Lisp Coding Style
Date:
Message-ID: <bpCcb.13637$lZ6.4042913@twister.nyc.rr.com>
Doug Tolton wrote:
> On Wed, 24 Sep 2003 20:29:06 GMT, Kenny Tilton <·······@nyc.rr.com>
> wrote:
>
>
>>Many are called, few are chosen.
>
>
> Interesting statement. It has religious overtones where I come from.
<g> Sorry, I am afraid this is just an example of why Xerox did not want
people to use xerox as a generic term; the overuse dilutes the trademark.
> I guess you could make the case that this entire newsgroup borders on
> religious fanaticism. Would that make Scheme the devil? >:)
Why do you ask me about Scheme? I know not. Am I my brother's keeper?
:)
kenny
From: Paolo Amoroso
Subject: Re: (belated) ANNC: RoboCells [was Re: Lisp (TeamKenny) vs C++ (The Bastards!) [was Re: Question about Lisp Coding Style
Date:
Message-ID: <87fzili90b.fsf@plato.moon.paoloamoroso.it>
Kenny Tilton writes:
> What are you doing today to grow Lisp?
Do you mean Lisp enlargement?
Paolo
--
Paolo Amoroso <·······@mclink.it>
From: Kenny Tilton
Subject: Re: (belated) ANNC: RoboCells [was Re: Lisp (TeamKenny) vs C++ (The Bastards!) [was Re: Question about Lisp Coding Style
Date:
Message-ID: <XLBcb.13631$lZ6.4030046@twister.nyc.rr.com>
Paolo Amoroso wrote:
> Kenny Tilton writes:
>
>
>>What are you doing today to grow Lisp?
>
>
> Do you mean Lisp enlargement?
You may be on to something. Erann thinks the key to swelling Lisp is
more headlines and a new name.
How about Extended Lisp?
Kenny Tilton <·······@nyc.rr.com> writes:
>>>What are you doing today to grow Lisp?
>> Do you mean Lisp enlargement?
>
> You may be on to something. Erann thinks the key to swelling Lisp is
> more headlines and a new name.
>
> How about Extended Lisp?
Extend, enlarge, grow. It'll never fly, the spam filters will trap it.
-dan "INCREA$E YOUR IMA.GE SI5E BY THREE 1NCHES!"
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
Daniel Barlow writes:
> Extend, enlarge, grow. It'll never fly, the spam filters will trap it.
Hmmm... Now I understand Graham's marketing strategy for Arc, and his
interest for spam filters. Quite subtle.
Paolo
--
Paolo Amoroso <·······@mclink.it>
On Wed, 24 Sep 2003 09:02:59 -0700, ··························@jpl.nasa.gov
(Erann Gat) wrote:
>> Didn't the Dylan experiment demolish the idea that the language is the
>> problem?
>
>No. The Dylan experiment is actually support for my position. Dylan was
>a technical triumph and a marketing disaster.
This is a good description of CL too...
In article <··································@4ax.com>, frr
<······@telefonica.net> wrote:
> On Wed, 24 Sep 2003 09:02:59 -0700, ··························@jpl.nasa.gov
> (Erann Gat) wrote:
>
>
> >> Didn't the Dylan experiment demolish the idea that the language is the
> >> problem?
> >
> >No. The Dylan experiment is actually support for my position. Dylan was
> >a technical triumph and a marketing disaster.
>
> This is a good description of CL too...
CL is a marketing triumph by comparison to Dylan.
E.
From: Rene de Visser
Subject: Re: Lisp (TeamKenny) vs C++ (The Bastards!) [was Re: Question about Lisp Coding Style
Date:
Message-ID: <bkv7pk$1ce$1@news1.wdf.sap-ag.de>
"Erann Gat" <··························@jpl.nasa.gov> wrote in message
················································@192.168.1.52...
>
> CL is a marketing triumph by comparison to Dylan.
>
> E.
I think your idea of a process for change is not the right way to make Lisp
attractive to management.
What is attractive is the latest new thing that they have to have.
So a process for great new things that are implemented/available in Lisp is
the way to go.
You don't even need to mention Lisp, just the great new thing.
Preferably though, it should be so based on Lisp that even the thought of
porting it to Java or XML
makes people want to cringe...
Either that or it has to be safe. Everyone else is using it so I won't get
in trouble if there are problems.
I don't think Lisp is going to win this way. At least not yet.
Or you partially hide Lisp underneath. Perhaps an application builder, based
on Lisp, with Lisp as the
extension language.
Rene.
>
> Or you partially hide Lisp underneath. Perhaps an application builder, based
> on Lisp, with Lisp as the
> extension language.
>
You can go a long way here. Application builders are a great way to
submarine languages into the commercial world. Apple has had pretty
good success with ObjC and its NeXT based framework, and Borland has
done pretty well with Kylix, which is actually ObjectPascal (!)
underneath.
Erann Gat wrote:
> In article <······························@bcect.com>, ·······@bcect.com
> (Michael Sullivan) wrote:
>>The problem with this is that change for change's sake is costly and
>>stupid.
>
>
> I am not advocating change for the sake of change. I am advocating change
> for the sake of a marketing strategy. Also, while some changes are
> costly, not all changes are. To object to all changes on the grounds that
> some changes are costly is not sound reasoning.
Maybe this is a good opportunity to get a broader perspective here.
I think Erann is basically right: If Common Lisp would "officially"
adapt changes/additions/whatever, such things would make it to the news.
Other languages are covered by online and print publications because of
changes.
So it seems to me that Erann's "hidden" goal is to create more publicity
for Lisp, at least partially. And this is a reasonable goal.
Forget about $ for special variables, studly caps, and all those things.
Think about how to improve the visibility of (Common) Lisp. In this
light, Erann's suggestions make a lot of sense.
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
Pascal Costanza writes:
> I think Erann is basically right: If Common Lisp would "officially"
> adapt changes/additions/whatever, such things would make it to the
> news. Other languages are covered by online and print publications
> because of changes.
Not necessarily. I guess you don't read Linux Weekly News :)
Paolo
--
Paolo Amoroso <·······@mclink.it>
Paolo Amoroso wrote:
> Pascal Costanza writes:
>
>
>>I think Erann is basically right: If Common Lisp would "officially"
>>adapt changes/additions/whatever, such things would make it to the
>>news. Other languages are covered by online and print publications
>>because of changes.
>
>
> Not necessarily. I guess you don't read Linux Weekly News :)
You're right. And this means I don't get the joke... :(
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
Pascal Costanza writes:
> Paolo Amoroso wrote:
>> Pascal Costanza writes:
>>
>>>I think Erann is basically right: If Common Lisp would "officially"
>>>adapt changes/additions/whatever, such things would make it to the
>>>news. Other languages are covered by online and print publications
>>>because of changes.
>> Not necessarily. I guess you don't read Linux Weekly News :)
>
> You're right. And this means I don't get the joke... :(
Try this:
- point your favorite browser to http://lwn.net
- navigate to the back issues section
- start from the latest issue
- pick the "one big page" version
- search for the string "lisp"
- repeat with other back issues until you get bored
or just search for the string "lisp" from LWN's home page.
Paolo
--
Paolo Amoroso <·······@mclink.it>
Paolo Amoroso <·······@mclink.it> wrote:
+---------------
| Pascal Costanza writes:
| >> Not necessarily. I guess you don't read Linux Weekly News :)
| >
| > You're right. And this means I don't get the joke... :(
|
| Try this:
| - point your favorite browser to http://lwn.net
...
| or just search for the string "lisp" from LWN's home page.
+---------------
Good job, Paolo!! ;-} ;-} Item #2 in the search results:
Common Lisp Utilities
([Development] Posted Sep 22, 2003 19:32 UTC (Mon) by cook)
A new Lisp-based project called Common Lisp Utilities has been
launched. "Version 1.0, the first public release, contains code
for data and control structures, financial functions, AI algorithms,
math and cryptography."
<URL:http://lwn.net/Articles/50337/>
[Follow the link to see why the smileys...]
Some of the other results from the same search:
Etiquette 0.3 announced
([Development] Posted Sep 16, 2003 16:57 UTC (Tue) by cook)
Etiquette version 0.3 is out. "Etiquette is "an interaction
protocol construction toolkit. The project goal is to build a
framework for rapid design of network communication code." The
system is written in Common Lisp."
Gsharp 0.2 released
([Development] Posted Sep 8, 2003 19:51 UTC (Mon) by cook)
Version 0.2 of Gsharp, an interactive, extensible editor for
musical scores written in Lisp, is available.
GNU CLISP 2.31 released
([Development] Posted Sep 8, 2003 19:49 UTC (Mon) by cook)
Version 2.31 of GNU CLISP, a Common Lisp implementation, is available.
Macho 0.2 released
([Development] Posted Sep 2, 2003 3:41 UTC (Tue) by corbet)
Macho is a web archiving system for electronic mail, written in
Lisp. Version 0.2 has just been released, with new support for
better quoting highlighting, an improved message parser, and
improved performance.
CL-GD 0.14 released
([Development] Posted Sep 2, 2003 3:41 UTC (Tue) by corbet)
Version 0.14 of CL-GD - a Common Lisp library for dynamic image
creation - has been released. This is the first public release of
CL-GD, which is built on top of the classic "GD" graphics library.
SBCL 0.8.3 released
([Development] Posted Aug 29, 2003 17:26 UTC (Fri) by cook)
Steel Bank Common Lisp version 0.8.3 is out. "This version,
which now also builds on MacOS X, features new optimizations,
improved compiler validation, support for automatic dowload and
installation of code from CCLAN, the SB-THREAD:INTERRUPT-THREAD
function and the usual bug fixes."
...and ~240 more...
-Rob
-----
Rob Warnock, PP-ASEL-IA <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Paolo Amoroso wrote:
> Pascal Costanza writes:
>
>
>>Paolo Amoroso wrote:
>>
>>>Pascal Costanza writes:
>>>
>>>
>>>>I think Erann is basically right: If Common Lisp would "officially"
>>>>adapt changes/additions/whatever, such things would make it to the
>>>>news. Other languages are covered by online and print publications
>>>>because of changes.
>>>
>>>Not necessarily. I guess you don't read Linux Weekly News :)
>>
>>You're right. And this means I don't get the joke... :(
>
>
> Try this:
>
> - point your favorite browser to http://lwn.net
> - navigate to the back issues section
> - start from the latest issue
> - pick the "one big page" version
> - search for the string "lisp"
> - repeat with other back issues until you get bored
...doesn't work for me because I don't have a subscription. The title
suggest that this is Linux centered. Would you recommend it stil?
> or just search for the string "lisp" from LWN's home page.
This worked for me, and I get a picture... ;)
Pascal
Pascal Costanza writes:
> ...doesn't work for me because I don't have a subscription. The title
> suggest that this is Linux centered. Would you recommend it stil?
Yes. Linux Weekly News is a weekly publication. Non subscribers have
access to all issues except the current one, which becomes free the
week after publication.
I recommend LWN for a couple of reasons, a general one and a
Lisp-related one. The former is that LWN does a good job of covering
general interest issues such as Open Source, intellectual property,
security, etc.
The latter reason is that the Lisp news are not necessarily
Linux-centric. See for example the announcements about OpenMCL, or the
community news about ILC, documentation, standardization, etc.
Paolo
--
Paolo Amoroso <·······@mclink.it>
Erann Gat wrote:
> I am starting to get really fed up with people misrepresenting my position.
....
> I ask again: why are you doing this? What are you hoping to accomplish?
Applying Occam's Razor, why look for intent behind the misconstruction
of remarks when misconstruction of remarks is done quite readily thank
you very much even by friendly listeners? If one suspects deliberate
misconstruction, hey, why have an exchange with a butthead?
One problem is phrase by phrase dissection and rebuttal of a post. A
person tries to make a point, but to do so they have to write a whole
bunch of sentences. The point is usually clear, and usually the
sentences or choice of words or even supporting factual details are
flawed. One can respond to the larger point and let the errata slide and
have a nice dialogue, or one can have a field day dissecting the post.
>> you
know
>> what
I mean. Then the victim naturally falls into the trap of defending each
probably accurate and embarrassing correction, and a Classic Endless
Thread is off and running. The thread cannot end because it is
adversarial, so no one can say "Good point." I myself have that
hardcoded into my grammar checker as a red flag item. And no one has the
reproductive organs to say, "Right, I was wrong on that, but my point
stands..." So...
> Eschew
point
> counter
point threads if they are no fun?
kenny
--
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"[If anyone really has healing powers,] I would like to call
them about my knees."
-- Tenzin Gyatso, the Fourteenth Dalai Lama
In article <················@nyc.rr.com>, ·······@nyc.rr.com wrote:
> Erann Gat wrote:
> > I am starting to get really fed up with people misrepresenting my position.
> ....
> > I ask again: why are you doing this? What are you hoping to accomplish?
>
> Applying Occam's Razor, why look for intent behind the misconstruction
> of remarks when misconstruction of remarks is done quite readily thank
> you very much even by friendly listeners? If one suspects deliberate
> misconstruction, hey, why have an exchange with a butthead?
It was a rhetorical question designed to 1) get the responder to think and
2) publicize the fact that my positions were being misrepresented. There
are lurkers here, and did not want to leave them with the wrong
impression. The last time this sort of thing happened it took me a full
month of shouting "I withdrew my proposal already! Stop beating on me!"
before things finally died down. I was hoping that more rapid proactive
action this time would kill the discussion more quickly.
Also, despite our disagreements I do not consider Kent a butthead. :-)
> One problem is phrase by phrase dissection and rebuttal of a post. A
> person tries to make a point, but to do so they have to write a whole
> bunch of sentences. The point is usually clear, and usually the
> sentences or choice of words or even supporting factual details are
> flawed. One can respond to the larger point and let the errata slide and
> have a nice dialogue, or one can have a field day dissecting the post.
Yes, but in this case the larger point was also wrong, and I thought the
best way to show that was to go point by point.
> I mean. Then the victim naturally falls into the trap of defending each
> probably accurate and embarrassing correction, and a Classic Endless
> Thread is off and running. The thread cannot end because it is
> adversarial, so no one can say "Good point."
Good point.
E.
"Kenny Tilton" <·······@nyc.rr.com> wrote in message
·····················@nyc.rr.com...
> Erann Gat wrote:
> > I am starting to get really fed up with people misrepresenting my
position.
> ....
> > I ask again: why are you doing this? What are you hoping to accomplish?
>
> Applying Occam's Razor, why look for intent behind the misconstruction
> of remarks when misconstruction of remarks is done quite readily thank
> you very much even by friendly listeners? If one suspects deliberate
> misconstruction, hey, why have an exchange with a butthead?
This is a very good point. I think there is a lot of overly defensive
dialogue going on too. "Defensive? I'm not being defensive! You're the
one being defensive. How come it's always the other guy being defensive?"
-- thanks to Martin Short and SCTV
I think there is less attacking than defending going on...
> One problem is phrase by phrase dissection and rebuttal of a post. A
> person tries to make a point, but to do so they have to write a whole
> bunch of sentences. The point is usually clear, and usually the
> sentences or choice of words or even supporting factual details are
> flawed. One can respond to the larger point and let the errata slide and
> have a nice dialogue, or one can have a field day dissecting the post.
This too is a good point. Usenet is funny that way. If you expressed
yourself verbally with a paragraph of speech, people would rarely respond
sentence by sentence. Although written, usenet dialogues are better
approached as if they had been spoken. Sometimes a simple, "I understand
your point, but that's not what I meant." works wonders.
FWIW, I think the breakdown of this thread is the result of too many chips
on too many shoulders. Also FWIW, I understood that Erann was not trying to
change anything in the Lisp world. I also understand how his remark about
"exceptional resistance to change" (something close to that, no?) provoked
people. The rest is becoming harder to understand.
Sometimes, less is more (but if less is more, just think how much more more
will be!) -- thanks to "Frasier"
> no one has the reproductive organs to say, "Right,
> I was wrong on that,...
Then I'll say it: "Kenny was wrong, on that and many other points"
;)
--
Coby Beck
(remove #\Space "coby 101 @ big pond . com")
In article <············@otis.netspace.net.au>, "Coby Beck"
<·····@mercury.bc.ca> wrote:
> his remark about
> "exceptional resistance to change" (something close to that, no?)
The exact quote was "As a general rule I have found the Common Lisp
community to be extraordinarily resistant to institutionalized change of
any sort."
I stand by this comment. In fact, I will go further and say that this
resistance to change (or commitment to stability if you want to give it a
positive spin) is a point of pride in the Common Lisp community.
> I also understand how [this remark] provoked people.
Would you mind explaining it to me then because I don't get it at all.
E.
From: Marco Antoniotti
Subject: Re: Question about Lisp Coding Style
Date:
Message-ID: <3F6F2531.3040908@cs.nyu.edu>
Christopher C. Stacy wrote:
>>>>>>On Fri, 19 Sep 2003 14:48:06 -0700, Erann Gat ("Erann") writes:
>>>>>
>
> Erann> Yes, that's a typical attitude in the CL community, and one of
> Erann> the reasons IMO that CL is not increasing its market share.
> Erann> It seems to be focused on existing customers. Potential
> Erann> customers get treated with neglect at best and disdain at worst.
>
> I missed the part where there were potential customers
> asking for special variables to be named $FOO ?
AFAIR, using the $FOO convention will not work in MCL. This is the
reason why MK's INFIX package switched to #I(...) instead of the TeX-ish
$...$
Cheers
--
Marco
In article <················@cs.nyu.edu>, ·······@cs.nyu.edu wrote:
> Christopher C. Stacy wrote:
> >>>>>>On Fri, 19 Sep 2003 14:48:06 -0700, Erann Gat ("Erann") writes:
> >>>>>
> >
> > Erann> Yes, that's a typical attitude in the CL community, and one of
> > Erann> the reasons IMO that CL is not increasing its market share.
> > Erann> It seems to be focused on existing customers. Potential
> > Erann> customers get treated with neglect at best and disdain at worst.
> >
> > I missed the part where there were potential customers
> > asking for special variables to be named $FOO ?
>
>
> AFAIR, using the $FOO convention will not work in MCL. This is the
> reason why MK's INFIX package switched to #I(...) instead of the TeX-ish
> $...$
Nope, it works just fine:
? (defvar $foo 1)
$FOO
? $foo
1
?
E.
Erann Gat <···@jpl.nasa.gov> wrote:
+---------------
| 4. I find $foo to be more aesthetically pleasing than *foo*,
| notwithstanding my utter disdain for Perl.
+---------------
Wel... uh..., I find myself often using $1, $2, $3... as *lexical*
variables[1] -- by analogy to /bin/sh, rather than Perl -- and
would be somewhat irked if I could no longer do that. So there. ;-}
-Rob
[1] Mostly inside a readmacro that does lambda abbreviations:
#$(* (+ 3 $2) $1) ==> (lambda ($1 $2) (* (+ 3 $2) $1))
Almost never used in source code saved in files, but
*very* convenient when typing MAPCARs into the REPL.
[Note: The actual lambda list also defines "&REST $*"... ;-} ]
-----
Rob Warnock, PP-ASEL-IA <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Rob Warnock wrote:
> Erann Gat <···@jpl.nasa.gov> wrote:
> +---------------
> | 4. I find $foo to be more aesthetically pleasing than *foo*,
> | notwithstanding my utter disdain for Perl.
> +---------------
>
> Wel... uh..., I find myself often using $1, $2, $3... as *lexical*
> variables[1] -- by analogy to /bin/sh, rather than Perl -- and
> would be somewhat irked if I could no longer do that. So there. ;-}
C'mon, we all started on Basic, $ is for string variables. At the back$
of course. hm... ok, youse guys can have the convention for the front, I
guess there's no conflict.
:)
--
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"[If anyone really has healing powers,] I would like to call
them about my knees."
-- Tenzin Gyatso, the Fourteenth Dalai Lama
Erann Gat wrote:
> Nonetheless, since you insist, here are my reasons for preferring $foo to *foo*:
...
> 2. Easier greppage. I think that dynamic variables are important enough
> that it's worth spending a character on making them readily apparent,
> visally distinguishable from, say, multiplication, and easily searchable.
egrep '\$' some-file.lisp
egrep '\*[^ ]+\*' some-file.lisp
A few more characters of typing, but it's hardly
enough to disqualify the standard convention's
specials as "easily searchable".
--
Gareth McCaughan
.sig under construc
Gareth McCaughan <················@pobox.com> writes:
> Erann Gat wrote:
>
> > Nonetheless, since you insist, here are my reasons for preferring $foo to *foo*:
> ...
> > 2. Easier greppage. I think that dynamic variables are important enough
> > that it's worth spending a character on making them readily apparent,
> > visally distinguishable from, say, multiplication, and easily searchable.
>
> egrep '\$' some-file.lisp
> egrep '\*[^ ]+\*' some-file.lisp
>
> A few more characters of typing, but it's hardly
> enough to disqualify the standard convention's
> specials as "easily searchable".
And if I didn't use an environment that did services like this for me
already, but I'd put it in a shell script or something, so that it
didn't make any difference how much typing it was. (I'll refrain from
whining overly about how it's hard to write shell scripts to search
for $ because $FOO already means something and it's not "special
variable", since that isn't relevant to a one-time writing of the
script either.) When finally invoked, my script or editor command or
whatever would operate the same regardless of the syntax.
Also, interactively, with completion, there are precious few conflicts
with
*rea TAB (completes to) *read-
and then
ba TAB (completes to) *read-base*
and I don't find myself typing the trailing *, so I don't find even a
single character wasted interactively in finding *read-base* rather
than $read-base.
... or will it be $read_base, since I _assume_ the next step
in unwanted change once one said "oh, sure, go ahead and change things".
Then we could relive years of wars over the now-settled conflict between
"but _ isn't an operator [in infix languages] and is a better separator"
vs.
"but _ is a shifted char and it hurts my hands to type it".
Yum. Yes, I'm veritably salivating at the thought of returning to those
days... all in the name of making CL more practical to modern users.
Kent M Pitman <······@world.std.com> writes:
> You can't claim that a community is "stuck in its ways" if the majority
> just happens to prefer stability over change on things that have no
> technical impact. And yet, in a lot of your proposals, not only are
There are so many rapidly changing languages and software projects
that people may have completely forgotten about design stability. They
may take it for granted that everything must change in "Internet
time".
Paolo
--
Paolo Amoroso <·······@mclink.it>
"Rmagere" <·······@*the-mail-that-burns*.*figure-it-out*> writes:
> > I'd say your code is just fine, although I'm not sure whether naming
> > Lisp variables with $ signs is a good idea. If $cfav is a special
> > variable, name it *cfav*. If it is a constant, many people use +cfav+
> > or simply cfav.
>
> Thanks for your reply and $cfav is a special variable (though now that you
> make me notice it is actually a constant so I will change my definition of
> it
> and its name).
> I started using $cfav and $thinking-time rather than *cfav* and
> *thinking-time* after having read one of Erann Gat complete idiot's
> guide to ... (packages, special variables, lexical variables etc) where he
> stated that *var* used to be the norm while now people tend to use $var.
> I thought "neat" as I always forget the last * and as I tend to change often
> special-variables for testing purpose on the top-level while watching the
> events unfold on a window getting the name right the first time is quite
> useful.
> However if such change in conventions has actually not taken place then I
> will go back to the *var* format.
Nope, no such change has occured. As for mistyping specials, yeah, I
used to do that fairly frequently, too. Realizing that if I typed
*foo, I almost certainly want to put a final * at the end, I made a
quick Emacs hack:
(defun tfb:insert-stars (arg)
"A very slight modification of insert-parentheses from GNU Emacs."
(interactive "P")
(if arg (setq arg (prefix-numeric-value arg))
(setq arg 0))
(cond ((> arg 0) (skip-chars-forward " \t"))
((< arg 0) (forward-sexp arg) (setq arg (- arg))))
(insert ?\*)
(save-excursion
(or (eq arg 0) (forward-sexp arg))
(insert ?\*)))
(global-set-key "\M-*" 'tfb:insert-stars)
So, now I can type "M-* foo", and I'll get "*foo*". Or, I can type
"a-really-long-special-name M-- M-*", and I'll get
"*a-really-long-special-name*". Very handy. I also have versions for
Fred and Hemlock (the MCL and CMUCL built-in editors).
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: Nils Goesche
Subject: Re: Question about Lisp Coding Style
Date:
Message-ID: <lyisnqavcz.fsf@cartan.de>
"Rmagere" <·······@*the-mail-that-burns*.*figure-it-out*> writes:
> I started using $cfav and $thinking-time rather than *cfav* and
> *thinking-time* after having read one of Erann Gat complete idiot's
> guide to ... (packages, special variables, lexical variables etc)
> where he stated that *var* used to be the norm while now people tend
> to use $var.
I'm pretty sure he was joking when he said that :-)
Regards,
--
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x0655CFA0
> (defun safe-time-zone (speed deceleration &optional think-time)
> (setf
> deceleration (abs deceleration)
> speed (abs speed)
> think-time (or think-time $thinking-time))
> (let* ((braking-time (/ speed $cfav deceleration))
> (thinking-distance (* think-time (/ speed $cfav)))
> (braking-distance (* 0.5 deceleration braking-time braking-time))
> (overall-distance (+ thinking-distance braking-distance))
> (safe-braking-zone (/ overall-distance (/ speed $cfav))))
> (/ (fceiling safe-braking-zone 0.1) 10)))
Here's my version (uglified some to deal with wraps here, and I did not
know what to call ADJ-SPEED):
(defun at^2/2 (accel time)
(* 0.5 (abs accel) time time))
(defun discretize (discretion value)
(/ (fceiling value discretion) (/ 1 discretion)))
(defun safe-time-zone (speed accel &optional (think-time
+thinking-time+)
&aux (adj-speed (/ (abs speed) +cfav+)))
(discretize 0.1 (/ (+ (* think-time adj-speed)
(at^2/2 accel (/ adj-speed accel)))
adj-speed)))
I think the big thing is to first break out stuff like at^2/2 (whatever
you call it <g>) and /then/ see if you need all that intermediate stuff
to make your code readable. I am guessing those two new functions will
be of value elsewhere anyway, so start there.
I changed decel to accel because I wager you are passing in a negative
value when the vehicle is decelerating. A negative deceleration would be
increasing in speed.
kenny
ps. I may have broken your code. btw, I am surprised you have a negative
speed.
--
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"I'm non-violent, but if a hawk comes down when I'm feeding
my birds, I lose my temper and get my air rifle."
-- Tenzin Gyatso, the Fourteenth Dalai Lama
I forgot to mention:
(/ speed +cfav+)
...appeared three times in your code. I do not know what that adjustment
is, but it should be done only once, and I wager another reusable
function is justified.
kt
--
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"I'm non-violent, but if a hawk comes down when I'm feeding
my birds, I lose my temper and get my air rifle."
-- Tenzin Gyatso, the Fourteenth Dalai Lama
Kenny Tilton <·······@nyc.rr.com> writes:
> (defun discretize (discretion value)
> (/ (fceiling value discretion) (/ 1 discretion)))
(defun discretize (unit value)
(* (fceiling value unit) unit))
:-) But I don't like the name. I mean, "discretize" is an excellent
term, but it doesn't make it clear whether it's rounding up, down
or sideways. My suggestion is below.
For what it's worth, here's my preferred version of the whole
thing.
(defun round-to-next-multiple-of (unit x)
(* (fceiling x unit) unit))
(defun safe-time-zone (speed deceleration
&optional (thinking-time *thinking-time*))
"Given a SPEED in km/h and a maximum DECELERATION in m/s^2,
return the minimum gap (in seconds while travelling
at SPEED) between vehicles that makes it possible for
one vehicle to stop safely without colliding with the
one in front if the latter stops instantaneously.
The result is rounded up to the next multiple of 0.1 ."
(setf deceleration (abs deceleration)
speed (abs speed))
(let* ((speed-in-m/s (/ speed +km/h-to-m/s+))
(braking-time (/ speed-in-m/s deceleration))
(braking-distance (* 0.5 deceleration braking-time braking-time))
(braking-time-at-full-speed (/ braking-distance converted-speed))
(total-time-needed (+ thinking-time braking-time-at-full-speed)))
(round-to-next-multiple-of 0.1 total-time-needed)))
A few points:
- Wolfhard's simplified formula is much simpler, but
also less clear. This isn't Wolfhard's fault; the
real problem is that ...
- The quantity being calculated is surely a meaningless
one. It's the distance you want rather than the time,
isn't it?
- Although I wouldn't do the calculation using Wolfhard's
formula, I *do* think it's pointless to calculate the
"thinking distance" when all you're going to do is to
divide it by the speed again. That requires computing
the quantity I've called BRAKING-TIME-AT-FULL-SPEED.
The name is a bit long, but I can't think of a shorter
name that expresses the meaning as clearly. Being
unable to find a pithy name for a quantity sometimes
indicates that it's a wrong thing to be calculating;
I think that's true here.
- ROUND-TO-NEXT-MULTIPLE-OF is another lengthy name,
but again I couldn't think of a shorter one that
wasn't less clear. I find it much more natural to
put the unit first. Here's a cute variation, which
(un?)fortunately isn't legal CL because ROUND is
already taken.
(defun round (x &key to-next-multiple-of)
(let ((unit (or to-next-multiple-of 1)))
(* (fceiling x unit) unit)))
(defun safe-time-zone (...)
...
(round total-time-needed :to-next-multiple-of 0.1))
For this sort of thing to be genuinely useful, you'd
want to be able to define verb/preposition combinations
piecemeal. You could do it with CLOS and EQL specializers,
kinda sorta. :-)
- There must be a better name than SAFE-TIME-ZONE but
I can't think of one right now. That's connected with
the fact that I can't see when you'd want the time
rather than the distance.
- I'd like to take issue with the (implicit) specifications
of this routine.
- I think SPEED and DECELERATION should be required
to be positive on entry. I bet they always, or almost
always, are in actual use; if need be, you can
normalize their signs outside this function. As it
stands, SAFE-TIME-ZONE is doing too many different
jobs.
- Similarly, I have difficulty imagining that rounding
to the next multiple of 0.1 is really the job of this
function. Surely that's a presentation issue, in
some sense; it should be in the user interface (if
this is being used interactively) or in whatever
generates nicely formatted output (if it's being
used that way) or, in short, almost anywhere but
here :-).
- The discrepancy between m/s^2 (for deceleration) and km/h
(for speed) is a bit alarming. I almost wonder whether
it would be worth putting the propeller beanie on and
making some classes for quantities-with-units, so that
the values you pass in aren't "the speed in km/h" and
"the deceleration in m/s^2" but simply "the speed" and
"the deceleration", with units attached. Then you'd be
rounding to the nearest multiple of 0.1s.
There are plenty of drawbacks to doing that, but it would
put an end to unit mismatches.
- No function longer than two lines without a docstring
should be considered "good Lisp style". :-)
--
Gareth McCaughan
.sig under construc
Gareth McCaughan wrote:
>
> (defun round-to-next-multiple-of (unit x)
> (* (fceiling x unit) unit))
>
I just realized I have a problem with all formulas like the one above
that replace (/ (fceiling x 0.1) 10))
i.e.
let's say x is 3.1323123 and the unit precision is 0.01
by using (/ (fceiling x 0.01) 100)) I get 3.14
by using (round-to-next-multiple-of 0.01 x) I get 3.1399999
and although close when I run a test such as
(= 3.14 (round-to-next-multiple-of 0.01 3.1323123)) returns NIL
while
(= 3.14 (/ (fceiling 3.1323123 0.01) 100)) return T
"Rmagere" <·······@*the-mail-that-burns*.*figure-it-out*> writes:
> (= 3.14 (round-to-next-multiple-of 0.01 3.1323123)) returns NIL
> while
> (= 3.14 (/ (fceiling 3.1323123 0.01) 100)) return T
It's rarely a good idea to use exact equals ("=") with floating point values.
Floating point calculations are inherently inexact (in the way you're using
them), so you almost always want to check whether the results are within a
small bound instead.
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
As I felt the soft, cool mud squish between my toes, I thought, Man these are
not very good shoes.
-- Deep Thoughts, by Jack Handey [1999]
Don Geddis <···@geddis.org> writes:
> "Rmagere" <·······@*the-mail-that-burns*.*figure-it-out*> writes:
> > (= 3.14 (round-to-next-multiple-of 0.01 3.1323123)) returns NIL
> > while
> > (= 3.14 (/ (fceiling 3.1323123 0.01) 100)) return T
>
> It's rarely a good idea to use exact equals ("=") with floating point values.
///////////////////////
I'd have stricken the indicated words, but I otherwise agree with your
point.
"Rmagere" <·······@*the-mail-that-burns*.*figure-it-out*> wrote in message
·················@news.ox.ac.uk...
>
> (defun safe-time-zone (speed deceleration &optional think-time)
> (setf
>
> deceleration (abs deceleration)
>
> speed (abs speed)
>
> think-time (or think-time $thinking-time))
>
> (let* ((braking-time (/ speed $cfav deceleration))
>
> (thinking-distance (* think-time (/ speed $cfav)))
>
> (braking-distance (* 0.5 deceleration braking-time
braking-time))
>
> (overall-distance (+ thinking-distance braking-distance))
>
> (safe-braking-zone (/ overall-distance (/ speed $cfav))))
>
> (/ (fceiling safe-braking-zone 0.1) 10)))
(defun safe-time-zone (speed deceleration &optional think-time)
(setf deceleration (abs deceleration)
speed (abs speed)
think-time (or think-time $thinking-time))
(let* ((braking-time (/ speed $cfav deceleration))
(thinking-distance (* think-time (/ speed $cfav)))
(braking-distance (* 0.5 deceleration braking-time braking-time))
(overall-distance (+ thinking-distance braking-distance))
(safe-braking-zone (/ overall-distance (/ speed $cfav))))
(/ (fceiling safe-braking-zone 0.1) 10)))
First a few remarks:
- Special variables are usually named *var* instead of $var. Similarily,
constants are usually named +constant+ instead of $constant.
- You can specify default values to &optional arguments, so you don't
need to setf think-time.
- I would avoid modifying function parameters, because I feel that it
reduces readability.
> Should I have written it in a more functional way even though it
> would have implied an extremly long one-line function?
>
> More in general should I try to avoid the creation of middle-level utility
> variables? I feel a bit in doubt as from one side I see the point of
keeping
> the code
Functional code is good, but you shouldn't try to make your code
completely side effect-free (remove all SETFs from your code just
because they mean side effects, or LETs "because they create variables",
etc.). Nothing is wrong with side effects, as long as you keep them
within a reasonable limit (scope). For example, changing values of
local variables in a function is not bad, since from outside of the
function there is no side effect visible.
After all, you can consider that _any_ code has side effects, since its
execution always modifies at least some CPU registers... :)
--
Matthieu Villeneuve
Rmagere:
>
> The question is do you consider the following code as bad practice?
:
> (defun safe-time-zone (speed deceleration &optional think-time)
> (setf deceleration (abs deceleration)
> speed (abs speed)
> think-time (or think-time $thinking-time))
> (let* ((braking-time (/ speed $cfav deceleration))
> (thinking-distance (* think-time (/ speed $cfav)))
> (braking-distance (* 0.5 deceleration braking-time braking-time))
> (overall-distance (+ thinking-distance braking-distance))
> (safe-braking-zone (/ overall-distance (/ speed $cfav))))
> (/ (fceiling safe-braking-zone 0.1) 10)))
:
> Should I have written it in a more functional way even though it would have
> implied an extremly long one-line function?
Note, that apart from ceiling and km/h to m/s conversion the body of
safe-time-zone could look like:
(+ think-time (* 0.5 (/ speed deceleration)))
--
"Hurry if you still want to see something. Everything is vanishing."
-- Paul C�zanne (1839-1906)
Wolfhard Bu� wrote:
> Rmagere:
>
>>The question is do you consider the following code as bad practice?
>
> :
>
>>(defun safe-time-zone (speed deceleration &optional think-time)
>> (setf deceleration (abs deceleration)
>> speed (abs speed)
>> think-time (or think-time $thinking-time))
>> (let* ((braking-time (/ speed $cfav deceleration))
>> (thinking-distance (* think-time (/ speed $cfav)))
>> (braking-distance (* 0.5 deceleration braking-time braking-time))
>> (overall-distance (+ thinking-distance braking-distance))
>> (safe-braking-zone (/ overall-distance (/ speed $cfav))))
>> (/ (fceiling safe-braking-zone 0.1) 10)))
>
> :
>
>>Should I have written it in a more functional way even though it would have
>>implied an extremly long one-line function?
>
>
> Note, that apart from ceiling and km/h to m/s conversion the body of
> safe-time-zone could look like:
>
> (+ think-time (* 0.5 (/ speed deceleration)))
Good f**king point. There is a moral here somewhere. :)
--
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"I'm non-violent, but if a hawk comes down when I'm feeding
my birds, I lose my temper and get my air rifle."
-- Tenzin Gyatso, the Fourteenth Dalai Lama
Wow so many feedbacks and all of them v. insightful well I will now
to reply to most of the points raised in them in this one single post.
By the way thanks for the help (thanks should be obvious but better keep
things clear).
To Erann Gat:
Erann Gat wrote:
> In article <············@news.ox.ac.uk>, "Rmagere"
> <·······@*the-mail-that-burns*.*figure-it-out*> wrote:
>
>> I started using $cfav and $thinking-time rather than *cfav* and
>> *thinking-time* after having read one of Erann Gat complete idiot's
>> guide to ... (packages, special variables, lexical variables etc)
>> where he stated that *var* used to be the norm while now people tend
>> to use $var.
>
> I don't believe I said that. If I did, please tell me where because I
> need to correct it. It's not true.
>
> What I have said in the past is that I believe that it would be a good
> idea to change the convention from *var* to $var, but very few people
> in the Common Lisp community seem to agree. (As a general rule I
> have found the Common Lisp community to be extraordinarily resistant
> to institutionalized change of any sort.)
>
You are perfectly right you did say it would have been a good idea not that
the change
had actually happened. When I read it I thought "cool now I can skip the
extra character"
however I have now come to appreciate it for the fact that when I am looking
for the
special variables in my code I just search for $ in the code and I find all
of them (as I
never use $ for any other reason) while if I name them *var* I must already
have some
idea of which variables I am looking for as there are far more (* a b) then
special variables.
I wonder if I may use �var instead of +var+ for the same reason.
I am the first one to admit that it is not good practice to deviate from the
accepted standard
but at this stage I am coding for myself (and for my future-self) and I feel
that this change might
make it easier for me to mantain my code. At the end when the code is
finished (though I doubt
it will ever be) I should be able to easily change all my $var �var to *var*
+var+ though I still
have to think this through.
To all who have suggested the following change:
Joe Marshall wrote:
>
> Since think-time is optional, and since there is a default value,
> you should simply use it as follows:
>
> (defun safe-time-zone (speed deceleration &optional (think-time
> $thinking-time)) ...)
>
Yeah that should have been obvious I just completely forgot about it
kind of related to the &optional argument is there a way for me to
specify the class or the class+initial value of optional parameters is a
defmethod?
i.e. How can I get something like this in acl5.01 to work?
(defmethod trial ((car vehicle) &optional ((another-car vehicle)
*standard-car*))
Joe Marshall wrote:
> I'd also change `$thinking-time' into `*default-thinking-time*'
[skipped]
> Since you use the quantity (/ speed $cfav) in several places, it is
> one that *ought* to be named!
>
> (let* ((converted-speed (/ speed *conversion-factor*))
>
You are right in both instances those changes would increase readibility
To Kenny Tilton:
Kenny Tilton wrote:
> (defun at^2/2 (accel time)
> (* 0.5 (abs accel) time time))
>
> (defun discretize (discretion value)
> (/ (fceiling value discretion) (/ 1 discretion)))
>
> I think the big thing is to first break out stuff like at^2/2
> (whatever you call it <g>) and /then/ see if you need all that
> intermediate stuff to make your code readable. I am guessing those
> two new functions will be of value elsewhere anyway, so start there.
I like discretize or the variants proposed by Gareth McCaughan as
in fact I do use that formula in other places so it would make sense
to clearly define it (and also achieve coherence of discretion by having
a +var+ to choose its level)
I am not too keen on at^2/2 as:
a) I actually never use that formula but here
b) not sure if it does add clarity as in a way I find (at^2/2 accel time)
more
obscure of (* 0.5 accel time time) though I must admit that if I used it
more
often and with less meaningful names of variables then having
established
such function would make clearer what is happening [i.e (at^2/2 a b)
would make clearer that a is accel and b is time].
>
> I changed decel to accel because I wager you are passing in a negative
> value when the vehicle is decelerating. A negative deceleration would
> be increasing in speed.
Yeah I do pass an acceleration and that's why I have (abs deceleration)
I just called it deceleration as that is what this function consider as the
reference idea [though by doing that (abs deceleration) I do probably
mix up a readers idea]
To Gareth McCaughan
Gareth McCaughan wrote:
> - There must be a better name than SAFE-TIME-ZONE but
> I can't think of one right now. That's connected with
> the fact that I can't see when you'd want the time
> rather than the distance.
Well I agree that if I was modelling a perfect vehicle with perfect
information I would model a braking-distance-at-full-speed however
I am more interested in how a human decides if he is too close to another
vehicle and in my case, when I drive, I know my speed (tachimeter and
mainly the approaching speed of stationary objects such as signs), I also
know my braking capacity from experience and while I do have a
feeling for how many seconds away I am from the car in front I don't
think I would be able to get a good approximation of how many meters I
am from it. That's why usually you hear told to learning-drivers "keep
2 seconds from the car in front".
>
> - Similarly, I have difficulty imagining that rounding
> to the next multiple of 0.1 is really the job of this
> function. Surely that's a presentation issue, in
> some sense; it should be in the user interface (if
> this is being used interactively) or in whatever
> generates nicely formatted output (if it's being
> used that way) or, in short, almost anywhere but
> here :-).
You are right it would be nicer outside of this function but as I plan
to use the return value in several conditional statements involving
= I would have each time to call:
(discretize (safe-time-zone acc speed) +precision+)
rather than (safe-time-zone acc speed)
> - The discrepancy between m/s^2 (for deceleration) and km/h
> (for speed) is a bit alarming. I almost wonder whether
> it would be worth putting the propeller beanie on and
> making some classes for quantities-with-units, so that
> the values you pass in aren't "the speed in km/h" and
> "the deceleration in m/s^2" but simply "the speed" and
> "the deceleration", with units attached. Then you'd be
> rounding to the nearest multiple of 0.1s.
>
> There are plenty of drawbacks to doing that, but it would
> put an end to unit mismatches.
I used to have something along those lines as I mention in another part
of this post it just kind of turned out being a bit too messy for my liking
though might go back to a simplier version of it.
To Fred Gilham:
Fred Gilham wrote:
> Another stylistic approach is to write little functions, especially if
> you might use them more than once:
>
> (defconstant $cfav 3.6
> "Allows conversion between meters per second and kilometers per
> hour.")
>
> (defconstant $thinking-time .75
> "Default thinking time in seconds.")
>
> (defun brake-time (speed deceleration)
> (/ speed $cfav deceleration))
>
> (defun brake-zone (speed distance)
> (/ distance (/ speed $cfav)))
>
> (defun think-time-to-think-distance (time speed)
> (* time (/ speed $cfav)))
>
> (defun braking-distance (deceleration time)
> (* 0.5 deceleration time time))
>
Not sure if I would use all those functions but I do like the clarity that
I feel by looking at them and also they do provide me with access to
all the individual parts as I later comment to Wolfhard BuB post.
> ;; The idea below is that maybe you have a canonical "left-to-right"
> ;; model and you want to be able to handle going either direction,
> ;; say, to deal with head-on collisions.
> (defun normalize (quantity)
> (abs quantity))
You are right that is the approach I used to have before a fully 360degrees
approach, with CLOS classes for my geometry to have seamless integration
between cartesian, polar and relative-polar coordinates and between km/h
and m/s however it had become a nightmare to mantain (probably or
definetly due to bad coding style) and it kept me from investigating what I
was actually interested in so I decided to move away from the unnecessary
complexity (i.e. the program must be used by me and I must be able to argue
for its usefulness but I do not expect for it to be ever used by others but
for a few ideas).
Also do you happen to know if there's any Lisp code pubblicly available
regarding modelling vehicles and or drivers?
To Wolfhard BuB
Wolfhard Bu� wrote:
> Note, that apart from ceiling and km/h to m/s conversion the body of
> safe-time-zone could look like:
>
> (+ think-time (* 0.5 (/ speed deceleration)))
You are absolutely right but I haven't yet decided if I will be using any of
the
intermediate values and pass them on in a (values ~ ~) call. Though
I think I will opt for the small fucntion approach of Fred Gilham.
From: Joe Marshall
Subject: Re: Question about Lisp Coding Style
Date:
Message-ID: <smmslxi5.fsf@ccs.neu.edu>
"Rmagere" <·······@*the-mail-that-burns*.*figure-it-out*> writes:
> Kind of related to the &optional argument is there a way for me to
> specify the class or the class+initial value of optional parameters is a
> defmethod?
Nope, but...
> i.e. How can I get something like this in acl5.01 to work?
> (defmethod trial ((car vehicle) &optional ((another-car vehicle)
> *standard-car*))
(defmethod trial ((car vehicle) (another-car vehicle))
...)
(defmethod trial ((car vehicle) (another-car null))
(trial car *standard-car*))
Rmagere wrote:
>>I changed decel to accel because I wager you are passing in a negative
>>value when the vehicle is decelerating. A negative deceleration would
>>be increasing in speed.
>
> Yeah I do pass an acceleration and that's why I have (abs deceleration)
> I just called it deceleration as that is what this function consider as the
> reference idea ...
No the function's "idea" is manifested by its code, which takes the
absolute value of "deceleration", meaning the function "thinks" it is
getting a negative value to convey the deceleration, in turn meaning an
acceleration is "expected" by the function.
I am not quibbling here. Consider what happens in many Lisp IDEs when
you go to call your function and just after you type
(safe-time-whatever.. you see the function signature helpfully
displayed, including "deceleration". If the vehicle is in fact slowing
down, I would supply a positive value for deceleration.
I know /you/ are thinking about deceleration, but your code is handling
an acceleration, no matter what you call the variable.
kt
Kenny Tilton wrote:
> Rmagere wrote:
>>> I changed decel to accel because I wager you are passing in a
>>> negative value when the vehicle is decelerating. A negative
>>> deceleration would be increasing in speed.
>>
>> Yeah I do pass an acceleration and that's why I have (abs
>> deceleration)
>> I just called it deceleration as that is what this function consider
>> as the reference idea ...
>
> No the function's "idea" is manifested by its code, which takes the
> absolute value of "deceleration", meaning the function "thinks" it is
> getting a negative value to convey the deceleration, in turn meaning
> an acceleration is "expected" by the function.
>
> I am not quibbling here. Consider what happens in many Lisp IDEs when
> you go to call your function and just after you type
> (safe-time-whatever.. you see the function signature helpfully
> displayed, including "deceleration". If the vehicle is in fact slowing
> down, I would supply a positive value for deceleration.
>
> I know /you/ are thinking about deceleration, but your code is
> handling an acceleration, no matter what you call the variable.
>
You are perfectly right what you just wrote is what I tried to convey,
although ineffectively (and I was aware of it while I was writing them),
with the lines of the post between [] that you cut out i.e.:
>> I just called it deceleration as that is what this function consider
>> as the reference idea [though by doing that (abs deceleration) I do
>> probably mix up a readers idea]
In fact as the deceleration I am using here is actually a constant property
of the vehicle rather than that the acceleration at it's current value I
just
need to change that value from negative to positive to achive convergence
of idea and implementation (thing which I will most definetly do).
"Rmagere" <·······@*the-mail-that-burns*.*figure-it-out*> writes:
Others have commented on your code, I'll just add:
> One more final silly question: am I right in assuming that if I use setf I
> do not have any reason to ever use setq?
That's certainly my opinion: I just never use SETQ, period.
Within the topic of special variables and their conventions I was just
wondering
would it be bad to hide a special variable *foo* within a (defun foo ()
*foo*)
and a (defun (setf foo) (new-value) (setf *foo* new-value))?
In that way I would get rid of the two * and replace them with () and
although
it requires the same amount of work (or possibly more) I find the solution
less
obtrusive and also it does allow me to have diffent "users" who have
different
global-variables they refer to.
However this method would partially hide the "special" nature of the
variables.
Also is there an idiot's guid to loop? as following the advice of small
functions
I have managed to rewrite chunks of code with more compact loop versions
of it, however I know that I haven't even scratched the surface of its
potential.
I will search google-groups as I kind of remember of a long post about loop.
Thanks again.
P.S. sorry for having involuntary caused the long OT that is currently
running
under this thread.
In article <············@news.ox.ac.uk>, "Rmagere"
<·······@*the-mail-that-burns*.*figure-it-out*> wrote:
> Within the topic of special variables and their conventions I was just
> wondering
> would it be bad to hide a special variable *foo* within a (defun foo ()
> *foo*)
> and a (defun (setf foo) (new-value) (setf *foo* new-value))?
The only problem I see with that is that you still have to deal with the
variable itself if you want to rebind it with LET or LAMBDA. (Of course,
you can write your own rebinding macro as well.)
> Also is there an idiot's guid to loop?
Not as far as I know.
E.
Erann Gat wrote:
> In article <············@news.ox.ac.uk>, "Rmagere"
> <·······@*the-mail-that-burns*.*figure-it-out*> wrote:
>
>> Within the topic of special variables and their conventions I was
>> just wondering
>> would it be bad to hide a special variable *foo* within a (defun
>> foo () *foo*)
>> and a (defun (setf foo) (new-value) (setf *foo* new-value))?
>
> The only problem I see with that is that you still have to deal with
> the variable itself if you want to rebind it with LET or LAMBDA. (Of
> course, you can write your own rebinding macro as well.)
>
You are perfectly right, completly forgot about that - I doubt I would
be able to write my own rebinding macro (but I'll give it a look as who
knows it might make me a better programmer) just as a starting point
can you give me an idea of how I would go about changing it? i.e. how
do I find the source code from which I should take inspiration (I am
using ACL 5.01 without the source code available).