Two things to get out of the way at the outset:
1. Note that the title of this post is *HOW* CL sucks, not *WHY* it
sucks. The difference is significant. Please take the time to
understand it before you flame me.
2. I'm not going to say anything I haven't said a thousand times
before, so those of you who know me (that means you, Kenny) will not
find anything new here so you may as well not even bother.
I am writing this because of the debate surrounding Steve Yegge's recent
blog entries on Lisp. It is unfortunate that he made so many technical
mistakes in his posts because they distract people from the fact that
underneath all the errors he is actually making a valid point, that
being that CL has very significant problems that are barriers to its
adoption. (Some people think this is a feature, that having a few
obstacles to overcome keeps out the rif raf. I suppose this is a
defensible position, but I don't subscribe to it.)
I'm going to point out just three problems with CL. There are more.
None of these are original observations.
1. CL lacks standardized support for many operations that are
necessities in today's world (e.g. sockets, database connectivity,
foreign functions). Moreover, it lacks any mechanism by which these
features could be standardized. It is claimed that there are portable
libraries that work across implementations that provide de facto
standards, e.g. UFFI, but these claims are false. I don't have time to
get into details at the moment, but the fact of the matter is that
trying to use Lisp for e.g. writing a Web server is an incredibly
painful experience compared to doing the same thing in e.g. Python.
The Balkanization of the CL implementation space also has the
consequence that one must choose between using implementation-specific
features and thus limiting the potential audience for one's code to a
niche within a niche, or writing to the least common denominator, which
generally means writing an awful lot of #+ reader macros.
2. Even for the one thing that CL claims to be particularly good at --
as a platform for embedding domain-specific languages -- it has
significant limits. To embed languages that differ from CL's semantics
in certain ways requires significant effort. To cite but one example: I
would like to embed a language that is very similar to Common Lisp, but
which differs in how it handles global variable references (to use
global lexical environments) and ((function-returning-a-function)
arguments) syntax. The former can be done using symbol macros, but only
if the top-level definitions precede their first use. If you reference
a global before defining it then you're screwed. The latter cannot be
done at all within CL unless you write a full code walker. But adding
this capability is utterly trivial within an implementation. In MCL it
takes two lines of code. And if it were done it would result in
strictly greater expressive power. Furthermore, it is not even
necessary to agree on the semantics of ((...) ...). One could simply
add a new macro defining form (or even a global variable) to set a
user-definable hook for transforming expressions whose CARs are lists
that do not begin with LAMDBA. All that would need to be agreed upon is
the name of this form. Furthermore, this would result in strictly
greater expressive power. It would be strictly backwards-compatible.
And It would serve the needs of a number of users who are not currently
being served (e.g. those who prefer to do functional-style programming
without having to type FUNCALL all the time.)
But despite the fact that this change is easy and only good could come
of it, it does not happen because there is no process by which this
change can be effected (which is, I believe, a direct consequence of the
fact that the realities of CL politics are that CL is utterly resistant
to all change, though I would dearly love to be proven wrong on that).
(Oh, and anyone who wishes to prove me wrong, please not that there is a
big big difference between effecting change in CL and effecting change
in an implementation of CL.)
3. Much of CL's core is badly designed. For example, consider NTH and
ELT. The functionality of ELT is a strict superset of NTH, so why have
NTH cluttering up the language? (To say nothing of the fact that the
order of the arguments in these two functions are gratuitously
reversed.) Why is the function that computes the difference of two sets
called SET-DIFFERENCE, but the function that computes the intersection
of two sets called simply INTERSECTION? And why do all of these
functions operate on lists, not sets? It's because there are no sets in
CL, which means that CL leads one to prematurely "optimize" sets as
lists. (I put optimize in scare quotes because in fact this is rarely
an optimization, especially when your sets get big, and most of the time
you have to go back and rip out huge chunks of code to replace your
lists with hash tables or binary trees.) I could go on and on.
Now, for those of you who wish to respond I ask you to keep in mind the
following:
1. The details of my criticisms are mostly irrelevant. What matters is
that CL is far from perfect, and that it has no mechanism for change.
So don't bother picking a nit about one of my specific criticisms unless
you wish to argue that CL is perfect and doesn't need to change.
2. I know a lot more about Lisp that Steve Yegge. I spent twenty years
programming in Lisp for a living. I have authored some highly
referenced papers on Lisp. I am far from the world's foremost expert,
but I'm no newbie. If you think I'm wrong about a technical point you
should think twice.
3. I do not hate Lisp. It is and has always been my favorite
programming languages. My love for Lisp pretty much destroyed my career
as a programmer. My motivation for criticising Lisp is not to convince
people not to use it. It is to effect changes that I believe are
necessary to get more people to use it. To quote Paul Graham, "It's not
Lisp that sucks, it's Common Lisp that sucks." And actually, I would
soften that somewhat: it's not Common Lisp that sucks, it's some parts
of Common Lisp that suck. But make no mistake, some parts of Common
Lisp really do suck, and unless they are fixed a lot of people -- myself
included -- won't be able to use it even though they may want to really
badly.
rg
Well written. I'm am almost a complete newbie at Lisp, so please take
what I say with big grains of salt.
It appears to me that the CL community has a lot of inertia, the
language and the spec are old (read mature if you prefer), but few
implementations actually have full ANSI compliance. Isn't there
something wrong when there are no ANSI compliant free implementations
20 years after the spec was written? Most implementations are probably
very close, but there are probably still weird little cracks where
stuff falls out.
I don't think that CL will ever change, there is too much inertia. I
personally think that the only way to get a better Lisp is to start
fresh, like Paul Graham is supposedly doing with Arc. But he should
have released it rather than just talking about it. I recently read
about ISLISP, which looks like it was trying to shed some of CL's
history, get a smaller spec and become a modern Lisp - but it appears
to have not gotten far from the ground.
In my very humble opinion, the only way to get a better CL is to take
the good bits of CL, Scheme, ML, etc and write a new Lisp
implementation. Make the goals of the language sexy and cool so you
get nerds interested in the language and in helping implement it. Make
interfacing to existing C/C++ and CL libraries as easy as possible to
leverage existing code. Make performance a goal, not a side effect -
some people want to write code fast, lots of others want to write fast
code. Many newer languages like Python don't get traction in places
where they would work well, not because the actual performance would
suck too bad, but because the perception that Python is slow.
Anyhow, my thoughts are that pushing for change in CL is like trying to
push water up hill and the only way to make a better Lisp is to not use
the name Common Lisp.
Cheers
Brad
bradb wrote:
> In my very humble opinion, the only way to get a better CL is to take
> the good bits of CL, Scheme, ML, etc and write a new Lisp
> implementation.
You mean like lush, Stella, Dylan, EuLisp, L Sharp, Le Lisp, ISLISP,
NewLisp, etc.?
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
Yes, like those ones. But good enough that it is so much better than
CL that the CL community wants to use it. Maybe the very nature of the
CL community would make it impossible to convert them to something
better - who knows?
Brad
bradb wrote:
> Yes, like those ones. But good enough that it is so much better than
> CL that the CL community wants to use it. Maybe the very nature of the
> CL community would make it impossible to convert them to something
> better - who knows?
It's hard to develop a Lisp dialect with the feature set that Common
Lisp already provides. In spite of its quirks, Common Lisp integrates
all these features very well. See http://www.lisp.org/table/objects.htm
for a characterization that hits the nail on the head.
Sure, some languages are better at functional programming. Sure, some
languages provide objects from the ground up. Sure, some programming
languages make it easier to write efficient code. Sure, some programming
languages make it safer to provide your own language extensions. But I
am not aware of another language that provides all of these things and
is so complete and so well integrated.
This is very hard to beat and probably not worth the effort. It's likely
that the end result of any new attempt will have similar messy odds and
ends as Common Lisp currently has. I think this is an inevitable side
effect of the goal to integrate a large number of features, and an
inevitable side effect of a language that has been organically grown
over several decades. Not even Scheme seems to be able to avoid these
issues, if you look closely enough. The idea that choosing a minimalist
approach is a remedy here doesn't seem to work either. [1]
Maybe it's a hard idea to grasp, but there are people who choose Common
Lisp _because_ it is the way it is.
Pascal
[1] Maybe Smalltalk is an exception here, but the idea of Smalltalk
seems to be that there should be no language. So instead of adding new
language construct, they add new tools to their development
environments, which poses similar issues.
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
Thank you for the very well written and reasoned post. I suspect you
may be right - for all the warts and bumps that CL has, it is pretty
darned good & any new language will probably get it's own ugliness at
around the same time it really useful.
Cheers
Brad
Pascal Costanza wrote:
> Maybe it's a hard idea to grasp, but there are people who choose Common
> Lisp _because_ it is the way it is.
>
>
> Pascal
>
Thank you.
It is Exactly like that.
dg
--
*It is easy to lie with statistics, but it's a lot easier to lie without
them.
There is no need for something better than Lisp. Not that Lisp is
perfect, but the real issue here is not the quality of the language but
the lack of libraries and tools. Lisp is too weird and its community
too hostile and fragmented to attract the legions of people it takes to
build a platform. These people have nicer, closer knit communities and
good enough Lisp approximations in Python and Ruby.
The best vehicle for wide spread Lisp usage would be an excellent
implementation that can behave as a 1st class citizen on someone else's
already massively popular platform (that would mean .NET or Java).
-pp
"bradb" <··············@gmail.com> writes:
> Well written. I'm am almost a complete newbie at Lisp, so please
> take what I say with big grains of salt. It appears to me that the
> CL community has a lot of inertia, the language and the spec are old
> (read mature if you prefer), but few implementations actually have
> full ANSI compliance. Isn't there something wrong when there are no
> ANSI compliant free implementations 20 years after the spec was
> written? Most implementations are probably very close, but there are
> probably still weird little cracks where stuff falls out.
So what areas of non-compliance in what implementations are causing
you pain? As far as I can tell, all the serious commercial and free
implementations work quite hard to conform to the spec and I can't
think, offhand, of any areas where implementations intentionally
deviate from the spec with no intention of fixing it when they get
around to it.
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
There are none that bother me, and none I can specifically put my
finger on. But most implementation docs that I have read use phrases
like "we aim to adhere to the ANSI spec". My real point was that the
hyperspec is a fairly lengthy document - does it really need to be
quite so big? But, as I say - I'm a noob :) I've never read the C
ANSI documents, maybe they are huge too.
Don't get me wrong, I really enjoy learning about and using CL - it's
just that in a few places I've been left with the impression that life
could be better. For the curious, my personal pain is in not knowing
how the underlying code is generated. I know C pretty well, I can tell
from C code roughly how the assembly output will look, and from C
structs exactly how the memory will be laid out. I can't tell this
with Lisp. Most of the time it doesn't matter, but sometimes I'd
really like to be able to use statically typed code within Lisp, so
that the assembler output is predictable.
Probably I am just new to Lisp though and it will come with time :)
Brad
bradb wrote:
> There are none that bother me, and none I can specifically put my
> finger on. But most implementation docs that I have read use phrases
> like "we aim to adhere to the ANSI spec". My real point was that the
> hyperspec is a fairly lengthy document - does it really need to be
> quite so big?
Well this is the funny part. First they complain the spec is too big,
then they complain that it does not cover FFI, sockets, DB access, threads.
Paging Yogi Berra....
As a salesman once told me, "If you are not being shot at, then you are
not over the target."
ken
--
Cells: http://common-lisp.net/project/cells/
"Have you ever been in a relationship?"
Attorney for Mary Winkler, confessed killer of her
minister husband, when asked if the couple had
marital problems.
"bradb" <··············@gmail.com> writes:
> There are none that bother me, and none I can specifically put my
> finger on. But most implementation docs that I have read use phrases
> like "we aim to adhere to the ANSI spec".
Since there's no test suite as part of the standard there's no much
else they *can* say. To then run around saying "there are no ANSI
compliant free implementations 20 years after the spec was written" is
a bit inflamatory. The ANSI CL spec is a lot more useful than, say,
the ANSI C99 spec which essentially can't be used for writing portable
code because Microsoft's C compilers don't, and apparently, never will
even try to conform to it.
> My real point was that the hyperspec is a fairly lengthy document -
> does it really need to be quite so big? But, as I say - I'm a noob
> :) I've never read the C ANSI documents, maybe they are huge too.
Well, most folks seem to be complaining that it's too short--that they
didn't find room to standardize threading, networking, etc, etc.
Anyway, speaking as someone who tends to read specifications when
they're available, the Common Lisp spec is a remarkably high-quality
piece of work.
> Don't get me wrong, I really enjoy learning about and using CL -
> it's just that in a few places I've been left with the impression
> that life could be better.
Life can always be better. The question is what can one do about it.
> For the curious, my personal pain is in not knowing how the
> underlying code is generated. I know C pretty well, I can tell from
> C code roughly how the assembly output will look, and from C structs
> exactly how the memory will be laid out. I can't tell this with
> Lisp.
Well, Lisp can tell you:
CL-USER> (defun foo (x y) (+ x y))
FOO
CL-USER> (disassemble 'foo)
;; disassembly of #<Function (:ANONYMOUS-LAMBDA 12) @ #x107aecca>
;; formals: X Y
;; code start: #x107aec5c:
0: 7c0802a6 [mfspr] mflr r0
4: 9421ffc0 stwu r1,-64(r1)
8: 90010048 stw r0,72(r1)
12: 91a1000c stw r13,12(r1)
16: 0f100002 twnei r16,2 "number of args"
20: 82520007 lwz r18,7(r18)
24: 7c732378 or r19,r3,r4
28: 72600003 andi. r0,r19,3
32: 4f800000 mcrf 7,0
36: 7e632415 addco. r19,r3,r4
40: 409e0024 bne cr7,76 lb2
44: 41830020 bso 76 lb2
48: 62630000 [ori] lr r3,r19
52: 3a000001 [addi] lil r16,1
lb1:
56: 80010048 lwz r0,72(r1)
60: 30210040 addic r1,r1,64
64: 7c0803a6 [mtspr] mtlr r0
68: 81a1000c lwz r13,12(r1)
72: 4e800020 blr
lb2:
76: 7ea903a6 [mtspr] mtctr r21 "symbol_trampoline"
80: 828fff8f lwz r20,-113(r15) EXCL::+_2OP
84: 3a000002 [addi] lil r16,2
88: 4e800421 bctrl
92: 4bffffdc b 56 lb1
; No value
Now let's see what effect some declarations have:
CL-USER> (defun foo (x y)
(declare (optimize (speed 3) (safety 0)))
(declare (fixnum x y))
(+ x y))
FOO
CL-USER> (disassemble 'foo)
;; disassembly of #<Function (:ANONYMOUS-LAMBDA 13) @ #x107c84c2>
;; formals: X Y
;; code start: #x107c84a4:
0: 7c632014 addc r3,r3,r4
4: 3a000001 [addi] lil r16,1
8: 81a1000c lwz r13,12(r1)
12: 4e800020 blr
; No value
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
Peter Seibel wrote:
> "bradb" <··············@gmail.com> writes:
> else they *can* say. To then run around saying "there are no ANSI
> compliant free implementations 20 years after the spec was written" is
> a bit inflamatory. The ANSI CL spec is a lot more useful than, say,
You're right - I didn't mean for it to be inflamatory. As I've said
before, I'm new here - though I may express my naive opinion a little
freely :)
> the ANSI C99 spec which essentially can't be used for writing portable
> code because Microsoft's C compilers don't, and apparently, never will
> even try to conform to it.
I guess that the reason the C world has less implementation issues is
because 95%+ of the market uses either MSVC or GCC, Lisp has many more
choices.
> Well, most folks seem to be complaining that it's too short--that they
> didn't find room to standardize threading, networking, etc, etc.
> Anyway, speaking as someone who tends to read specifications when
> they're available, the Common Lisp spec is a remarkably high-quality
> piece of work.
Good point. But you have to admit there is at least _some_ legacy and
redundant code, NTH vs ELT.
> > exactly how the memory will be laid out. I can't tell this with
> > Lisp.
>
> Well, Lisp can tell you:
Yes, but I don't think this is a real solution. Very rarely do I
examine the disassembly output of C code, because the output is
generally pretty predictable.
I don't want to have to mess with the machine code to confirm that a
statically typed section of code has compiled to more or less what I
expected - that doesn't scale up. Though this could just be a learning
curve thing, I _am_ starting to understand the optimisations a little
more.
Cheers
Brad
"bradb" <··············@gmail.com> writes:
>> the ANSI C99 spec which essentially can't be used for writing portable
>> code because Microsoft's C compilers don't, and apparently, never will
>> even try to conform to it.
> I guess that the reason the C world has less implementation issues is
> because 95%+ of the market uses either MSVC or GCC, Lisp has many more
> choices.
This may be so, but I have always had to deal with more than just these
two on any large software project save for embedded work. Right now I
regularly struggle with keeping one large product compiling with gcc
(3.2, 3.3, and 3.4), MS VC 6 (yuck!) and 7.1, XLC 6 and 7, aCC 3.51, Sun
CC 5.7, Compaq CC 6.5, and MIPSPro 7.4, and mostly I am thankful I don't
have to work with the weird platforms (like the S/390). All those
compilers are actively used by customers of this product, otherwise we
wouldn't maintain ports for them.
When I go home and work in Common Lisp, I breathe a sigh of relief, as
so many of the portability issues are gone. For the most part, those
that remain are reasonable differences between implementations that I'm
willing to accept. I'd hate to see CL get locked into POSIX the same
way so many small-time languages these days have. (That's not to say it
wouldn't be just fine to have a nice, defacto-standard POSIX interface
library for CL; we'd be one ahead of Java at that point. ;-))
> Yes, but I don't think this is a real solution. Very rarely do I
> examine the disassembly output of C code, because the output is
> generally pretty predictable.
Although these days, sufficiently smart compilers frequently produce
very interesting (sometimes unexpected) output. I look at the assembly
output of good C compilers sometimes to learn new optimization tricks,
and I have long since stopped trying to rearrange my code "for the
compiler's benefit" without having verified that my compiler really
sucks.
> I don't want to have to mess with the machine code to confirm that a
> statically typed section of code has compiled to more or less what I
> expected - that doesn't scale up. Though this could just be a learning
> curve thing, I _am_ starting to understand the optimisations a little
> more.
Presumably, in any language, if you're optimizing a section of code,
(which you know to be hot, from profiling), you're going to end up
looking at it from many directions, including the compiler's output,
when trying to improve the speed. Anything else is dangerously close to
cargo cult optimization.
Cheers.
--
Julian Squires
Peter Seibel <·····@gigamonkeys.com> writes:
> Now let's see what effect some declarations have:
>
> CL-USER> (defun foo (x y)
> (declare (optimize (speed 3) (safety 0)))
> (declare (fixnum x y))
> (+ x y))
> FOO
> CL-USER> (disassemble 'foo)
> ;; disassembly of #<Function (:ANONYMOUS-LAMBDA 13) @ #x107c84c2>
> ;; formals: X Y
>
> ;; code start: #x107c84a4:
> 0: 7c632014 addc r3,r3,r4
> 4: 3a000001 [addi] lil r16,1
> 8: 81a1000c lwz r13,12(r1)
> 12: 4e800020 blr
Isn't this quite a bad example to use when demonstrating things for a
newbie, given that it is nonconforming output? [ I believe Allegro
documents this deviation, but try (foo most-positive-fixnum
most-positive-fixnum) ]
Christophe
Christophe Rhodes <·····@cam.ac.uk> writes:
> Peter Seibel <·····@gigamonkeys.com> writes:
>
>> Now let's see what effect some declarations have:
>>
>> CL-USER> (defun foo (x y)
>> (declare (optimize (speed 3) (safety 0)))
>> (declare (fixnum x y))
>> (+ x y))
>> FOO
>> CL-USER> (disassemble 'foo)
>> ;; disassembly of #<Function (:ANONYMOUS-LAMBDA 13) @ #x107c84c2>
>> ;; formals: X Y
>>
>> ;; code start: #x107c84a4:
>> 0: 7c632014 addc r3,r3,r4
>> 4: 3a000001 [addi] lil r16,1
>> 8: 81a1000c lwz r13,12(r1)
>> 12: 4e800020 blr
>
> Isn't this quite a bad example to use when demonstrating things for a
> newbie, given that it is nonconforming output? [ I believe Allegro
> documents this deviation, but try (foo most-positive-fixnum
> most-positive-fixnum) ]
Sure. Out of curiosity, is it non-conforming given that I declared
safety 0? Or is the implementation still required to produce correct
results? Which would mean I'd technically have to explicitly mask the
result of (+ x y) down to fixnum bits. And then Allegro doesn't
optimize away the LOGAND. Does SBCL. I.e. if I write:
(defun foo (x y)
(declare (optimize (speed 3) (safety 0)))
(declare (fixnum x y))
(the fixnum (logand (+ x y) #.(1- (expt 2 (integer-length most-positive-fixnum))))))
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
Peter Seibel <·····@gigamonkeys.com> wrote:
> Sure. Out of curiosity, is it non-conforming given that I declared
> safety 0? Or is the implementation still required to produce correct
> results? Which would mean I'd technically have to explicitly mask the
> result of (+ x y) down to fixnum bits. And then Allegro doesn't
> optimize away the LOGAND. Does SBCL. I.e. if I write:
>
> (defun foo (x y)
> (declare (optimize (speed 3) (safety 0)))
> (declare (fixnum x y))
> (the fixnum (logand (+ x y) #.(1- (expt 2 (integer-length most-positive-fixnum))))))
No, the LOGAND can't be reasonably optimized away, since the sign bit
needs to be cleared. Consider, for example, (FOO -1 -1) and (FOO
MOST-POSITIVE-FIXNUM 1).
--
Juho Snellman
Juho Snellman <······@iki.fi> writes:
> Peter Seibel <·····@gigamonkeys.com> wrote:
>> Sure. Out of curiosity, is it non-conforming given that I declared
>> safety 0? Or is the implementation still required to produce correct
>> results? Which would mean I'd technically have to explicitly mask the
>> result of (+ x y) down to fixnum bits. And then Allegro doesn't
>> optimize away the LOGAND. Does SBCL. I.e. if I write:
>>
>> (defun foo (x y)
>> (declare (optimize (speed 3) (safety 0)))
>> (declare (fixnum x y))
>> (the fixnum (logand (+ x y) #.(1- (expt 2 (integer-length most-positive-fixnum))))))
>
> No, the LOGAND can't be reasonably optimized away, since the sign bit
> needs to be cleared. Consider, for example, (FOO -1 -1) and (FOO
> MOST-POSITIVE-FIXNUM 1).
Ah, good point.
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
From: Christophe Rhodes
Subject: One way CL doesn't suck (was Re: How Common Lisp sucks)
Date:
Message-ID: <sqzmijc4tq.fsf_-_@cam.ac.uk>
Peter Seibel <·····@gigamonkeys.com> writes:
> Christophe Rhodes <·····@cam.ac.uk> writes:
>
>> Peter Seibel <·····@gigamonkeys.com> writes:
>>
>>> Now let's see what effect some declarations have:
>>>
>>> CL-USER> (defun foo (x y)
>>> (declare (optimize (speed 3) (safety 0)))
>>> (declare (fixnum x y))
>>> (+ x y))
>>> FOO
>>> CL-USER> (disassemble 'foo)
>>> ;; disassembly of #<Function (:ANONYMOUS-LAMBDA 13) @ #x107c84c2>
>>> ;; formals: X Y
>>>
>>> ;; code start: #x107c84a4:
>>> 0: 7c632014 addc r3,r3,r4
>>> 4: 3a000001 [addi] lil r16,1
>>> 8: 81a1000c lwz r13,12(r1)
>>> 12: 4e800020 blr
>>
>> Isn't this quite a bad example to use when demonstrating things for a
>> newbie, given that it is nonconforming output? [ I believe Allegro
>> documents this deviation, but try (foo most-positive-fixnum
>> most-positive-fixnum) ]
>
> Sure. Out of curiosity, is it non-conforming given that I declared
> safety 0? Or is the implementation still required to produce correct
> results?
Yes. 0 safety does not permit an implementation which purports to
conform to ANSI to give the wrong results if none of the constraints
(including user type declarations) are violated. [ My interpretation
of the spec only, yadda yadda; the good people at Franz may not have
more pedantic language lawyers, but they almost certainly have better
law lawyers :-) ]
> Which would mean I'd technically have to explicitly mask the
> result of (+ x y) down to fixnum bits. And then Allegro doesn't
> optimize away the LOGAND. Does SBCL. I.e. if I write:
>
> (defun foo (x y)
> (declare (optimize (speed 3) (safety 0)))
> (declare (fixnum x y))
> (the fixnum (logand (+ x y) #.(1- (expt 2 (integer-length most-positive-fixnum))))))
Well, no, but that's because here your LOGAND doesn't do what I think
you think it does, because a FIXNUM is a signed quantity. The LOGAND
isn't optimized away, but it does compile to two machine instructions
(x86 this time):
; 0A85BCEC: 01FA ADD EDX, EDI ; no-arg-parsing entry point
; CEE: 81E2FFFFFF1F AND EDX, 536870911
; [+ return sequence ]
If instead you do
(defun sfoo (x y)
(declare (optimize (speed 3) (safety 0)))
(declare (fixnum x y))
(sb-c::mask-signed-field 30 (+ x y))) ; 30 fixnum bits on x86
you get just the add:
; 0AA4221E: 01FA ADD EDX, EDI ; no-arg-parsing entry point
; [+ return sequence ]
MASK-SIGNED-FIELD, or some equivalent, will eventually make it to
documented and exported status in SBCL, because this is a thing that
Lisp coders want to do; the contortion of an extra operator is needed
because there's no signed equivalent to LOGAND or LDB, which express
the equivalent unsigned operation.
I wouldn't recommend using FIXNUM declarations, though; they're not
only machine-dependent but implementation-dependent too. Use
(signed-byte 32) or (unsigned-byte 32) (or 64 bits, if that's what
your algorithm needs, or (signed-byte 19) come to that).
Christophe
From: Peter Seibel
Subject: Re: One way CL doesn't suck (was Re: How Common Lisp sucks)
Date:
Message-ID: <m2mzei52ln.fsf@gigamonkeys.com>
Christophe Rhodes <·····@cam.ac.uk> writes:
> MASK-SIGNED-FIELD, or some equivalent, will eventually make it to
> documented and exported status in SBCL, because this is a thing that
> Lisp coders want to do; the contortion of an extra operator is
> needed because there's no signed equivalent to LOGAND or LDB, which
> express the equivalent unsigned operation.
I have thought (when implementing things like CRC functions) that it'd
be handy to have a macro WITH-MODULAR-ARITHMETIC that would let you
say things like:
(with-modular-arithmetic ((expt 2 32))
;; do a bunch of arithmetic
)
and have all the arithmetic operations be transformed into C-style
modular arithmetic. The hope would be that when the modulus was
matched to the hardware architecture this would get compiled into
efficient code but you could also use it more generally:
(with-modular-arithmetic (13) ...)
This is obviously a macro that'd be easier to implement from within a
Lisp implementation than from without, given the need to code-walk the
body and control code generation in particular ways.
Or is this just crack headed?
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
Peter Seibel <·····@gigamonkeys.com> writes:
> I have thought (when implementing things like CRC functions) that it'd
> be handy to have a macro WITH-MODULAR-ARITHMETIC that would let you
> say things like:
>
> (with-modular-arithmetic ((expt 2 32))
> ;; do a bunch of arithmetic
> )
>
> and have all the arithmetic operations be transformed into C-style
> modular arithmetic.
I think it is a good trap for a code like
(with-modular-arithmetic ((expt 2 8))
(+ (aref v i) (aref v (1+ i))))
;; ^^^^^^
or (even worse)
(with-modular-arithmetic ((expt 2 8))
(cl*:loop for i below (length v) sum (aref v i)))
I prefer intentions to be expressed more clearly.
--
Regards,
Alexey Dejneka
"Alas, the spheres of truth are less transparent than those of
illusion." -- L.E.J. Brouwer
Alexey Dejneka <········@tochka.ru> writes:
> Peter Seibel <·····@gigamonkeys.com> writes:
>
>> I have thought (when implementing things like CRC functions) that it'd
>> be handy to have a macro WITH-MODULAR-ARITHMETIC that would let you
>> say things like:
>>
>> (with-modular-arithmetic ((expt 2 32))
>> ;; do a bunch of arithmetic
>> )
>>
>> and have all the arithmetic operations be transformed into C-style
>> modular arithmetic.
>
> I think it is a good trap for a code like
>
> (with-modular-arithmetic ((expt 2 8))
> (+ (aref v i) (aref v (1+ i))))
You're worried that the coder wasn't thinking about the fact that
arithmetic was modular when he wrote the (1+ i) expression? I.e. what
he really meant was:
(with-modular-arithmetic ((expt 2 8))
(+ (aref v i) (aref v (with-lisp-arithmetic (1+ i)))))
That is a possible pitfall, I suppose. Maybe something like:
(with-modular-arithmetic ((expt 2 8) :ops (+ - * /))
(+ (aref v i) (aref v (1+ i))))
to specify the ops that should be modularized. Or maybe you just live
with the trap.
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
Christophe Rhodes <·····@cam.ac.uk> writes:
> (I'm still not convinced that your construct would prove useful in
> practice, while at least the (LOGAND #xFF ...) thing is demonstrably
> useful in that there are libraries using it.)
That's no proof whatsoever. Any library can use any ill-defined or
contorted construct -- which makes me think of Python (language) :-)
LOGAND is what SBCL recommends (these days), DECLARE is what Allegro
recommends, xyz is what ZYX recommends etc.
Peter Seibel <·····@gigamonkeys.com> writes:
> I have thought (when implementing things like CRC functions) that it'd
> be handy to have a macro WITH-MODULAR-ARITHMETIC that would let you
> say things like:
I immediately come to think this would be a misdesign in CL. Others
quickly pointed you to the problems. If some macro in the body
introduces some arithmetic, it was not necessarily meant modular.
Alexey Dejnka's example:
> (with-modular-arithmetic ((expt 2 8))
> (cl*:loop for i below (length v) sum (aref v i)))
I think this design could be used in Scheme instead, given Scheme's
bias towards lexical scoping & modularization. There, a macro would
refer to the original definition of +, not the modular one, and not
break code.
For CL, you'll need something different. It seems like you need to
distinguish literal code from code imported via macroexpansion. I
have no idea how.
This remembers me of the COVER Lisp package for doing coverage
analysis, which faces similar problems: presumably you want to test
coverage of literal Lisp code inside your DEFUN, not complicated macro
expansions of e.g. LOOP. Ideally, both forms should be analysable
(and I managed to do so with COVER).
Regards,
Jorg Hohle
Telekom/T-Systems Technology Center
From: Christophe Rhodes
Subject: Re: One way CL doesn't suck
Date:
Message-ID: <sqd5fdziug.fsf@cam.ac.uk>
Joerg Hoehle <······@users.sourceforge.net> writes:
> Christophe Rhodes <·····@cam.ac.uk> writes:
>> (I'm still not convinced that your construct would prove useful in
>> practice, while at least the (LOGAND #xFF ...) thing is demonstrably
>> useful in that there are libraries using it.)
>
> That's no proof whatsoever. Any library can use any ill-defined or
> contorted construct -- which makes me think of Python (language) :-)
Spoken like a true mathematician; however, empirically, if we are to
make progress in essentially social disciplines such as programming,
we have to accept lower standards of knowledge than proof from
universally-accepted axioms.
> LOGAND is what SBCL recommends (these days), DECLARE is what Allegro
> recommends, xyz is what ZYX recommends etc.
Well, yes, except that LOGAND expresses the algorithm that people
wanting modular arithmetic are writing, and additionally permits the
compiler to generate the code that those wanting hardware modular
arithmetic desire. That is to say, my claim is that LOGAND is
"better" (for an ill-specified metric of preferences, if the scare
quotes aren't enough) than these non-standard or anti-standard things
like Allegro's FIXNUM switch because it expresses both the meaning
desired and the ability to optimize in a compact and unambiguous
fashion.
Christophe
Hello,
Joerg Hoehle <······@users.sourceforge.net> writes:
> Christophe Rhodes <·····@cam.ac.uk> writes:
>> (I'm still not convinced that your construct would prove useful in
>> practice, while at least the (LOGAND #xFF ...) thing is demonstrably
>> useful in that there are libraries using it.)
> That's no proof whatsoever. Any library can use any ill-defined or
> contorted construct -- which makes me think of Python (language) :-)
> LOGAND is what SBCL recommends (these days), DECLARE is what Allegro
> recommends,
What is ill-defined in (LOGAND #xFF (+ X Y))?! It is just a question
of implementation whether a compiler will convert it to bignum
addition and taking of a lower byte, or just adds lower bytes of the
arguments - the result will be the same.
> Peter Seibel <·····@gigamonkeys.com> writes:
>> I have thought (when implementing things like CRC functions) that it'd
>> be handy to have a macro WITH-MODULAR-ARITHMETIC that would let you
>> say things like:
>
> I immediately come to think this would be a misdesign in CL. Others
> quickly pointed you to the problems. If some macro in the body
> introduces some arithmetic, it was not necessarily meant modular.
>
> Alexey Dejnka's example:
>> (with-modular-arithmetic ((expt 2 8))
>> (cl*:loop for i below (length v) sum (aref v i)))
>
> I think this design could be used in Scheme instead, given Scheme's
> bias towards lexical scoping & modularization. There, a macro would
> refer to the original definition of +, not the modular one, and not
> break code.
I think it will not work in Scheme for the reason you mentioned:
Scheme will probably use global + for both summing and stepping; in
contrast
(logand #xff (cl*:loop for i below (length v) sum (aref v i)))
has a precisely specfied meaning, and it is a question of
implementation whether it will keep unneccessary higher bytes of
temporals.
--
Regards,
Alexey Dejneka
"Alas, the spheres of truth are less transparent than those of
illusion." -- L.E.J. Brouwer
Peter Seibel <·····@gigamonkeys.com> wrote:
> Christophe Rhodes <·····@cam.ac.uk> writes:
>> Isn't this quite a bad example to use when demonstrating things for a
>> newbie, given that it is nonconforming output? [ I believe Allegro
>> documents this deviation, but try (foo most-positive-fixnum
>> most-positive-fixnum) ]
>
> Sure. Out of curiosity, is it non-conforming given that I declared safety 0
> ? Or is the implementation still required to produce correct results ? Which
> would mean I'd technically have to explicitly mask the result of (+ x y)
> down to fixnum bits.
Actually, ACL has a flag called DECLARED-FIXNUMS-REMAIN-FIXNUMS-SWITCH
that is automatically enabled[1] when safety is 0 and speed is 3. This flag
makes ACL assume that (+ FIXNUM FIXNUM) remains a FIXNUM, so it's just as if
ACL had inserted (the fixnum ...) for you.
Footnotes:
[1] I find this behavior utterly annoying BTW
--
Didier Verna, ······@lrde.epita.fr, http://www.lrde.epita.fr/~didier
EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 44 08 01 85
94276 Le Kremlin-Bic�tre, France Fax.+33 (1) 53 14 59 22 ······@xemacs.org
bradb wrote:
> There are none that bother me, and none I can specifically put my
> finger on. But most implementation docs that I have read use phrases
> like "we aim to adhere to the ANSI spec". My real point was that the
> hyperspec is a fairly lengthy document - does it really need to be
> quite so big?
Some people think it's not big enough. ;)
(These two criticisms of Common Lisp are indeed incompatible: Some say
the specification is too big, others say that it doesn't include
"modern" features that are typically part of other languages nowadays.
Something doesn't compute here...)
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
Pascal Costanza wrote:
> bradb wrote:
>
>> There are none that bother me, and none I can specifically put my
>> finger on. But most implementation docs that I have read use phrases
>> like "we aim to adhere to the ANSI spec". My real point was that the
>> hyperspec is a fairly lengthy document - does it really need to be
>> quite so big?
>
>
> Some people think it's not big enough. ;)
>
> (These two criticisms of Common Lisp are indeed incompatible: Some say
> the specification is too big, others say that it doesn't include
> "modern" features that are typically part of other languages nowadays.
> Something doesn't compute here...)
I don't know why. I think it's too big in terms of some cruft that
could be cleaned up and chunks deprecated, and also that some stuff like
sockets and threads should be added. No necessary contradiction.
--Larry
Larry Elmore <·········@comcast.net> writes:
> Pascal Costanza wrote:
>> bradb wrote:
>>
>>> There are none that bother me, and none I can specifically put my
>>> finger on. But most implementation docs that I have read use phrases
>>> like "we aim to adhere to the ANSI spec". My real point was that the
>>> hyperspec is a fairly lengthy document - does it really need to be
>>> quite so big?
>>
>>
>> Some people think it's not big enough. ;)
>>
>> (These two criticisms of Common Lisp are indeed incompatible: Some say
>> the specification is too big, others say that it doesn't include
>> "modern" features that are typically part of other languages nowadays.
>> Something doesn't compute here...)
>
> I don't know why. I think it's too big in terms of some cruft that
> could be cleaned up and chunks deprecated, and also that some stuff like
> sockets and threads should be added. No necessary contradiction.
Yes, but really, if you think there's cruft, you can always use
FMAKUNBOUND and MKUNBOUND.
--
__Pascal Bourguignon__ http://www.informatimago.com/
You never feed me.
Perhaps I'll sleep on your face.
That will sure show you.
Pascal Bourguignon wrote:
> Larry Elmore <·········@comcast.net> writes:
>
>> Pascal Costanza wrote:
>>> bradb wrote:
>>>
>>>> There are none that bother me, and none I can specifically put my
>>>> finger on. But most implementation docs that I have read use phrases
>>>> like "we aim to adhere to the ANSI spec". My real point was that the
>>>> hyperspec is a fairly lengthy document - does it really need to be
>>>> quite so big?
>>>
>>> Some people think it's not big enough. ;)
>>>
>>> (These two criticisms of Common Lisp are indeed incompatible: Some say
>>> the specification is too big, others say that it doesn't include
>>> "modern" features that are typically part of other languages nowadays.
>>> Something doesn't compute here...)
>> I don't know why. I think it's too big in terms of some cruft that
>> could be cleaned up and chunks deprecated, and also that some stuff like
>> sockets and threads should be added. No necessary contradiction.
>
> Yes, but really, if you think there's cruft, you can always use
> FMAKUNBOUND and MKUNBOUND.
ROTFL
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
bradb schrieb:
> There are none that bother me, and none I can specifically put my
> finger on. But most implementation docs that I have read use phrases
> like "we aim to adhere to the ANSI spec". My real point was that the
> hyperspec is a fairly lengthy document - does it really need to be
> quite so big? But, as I say - I'm a noob :) I've never read the C
> ANSI documents, maybe they are huge too.
>
> Don't get me wrong, I really enjoy learning about and using CL - it's
> just that in a few places I've been left with the impression that life
> could be better. For the curious, my personal pain is in not knowing
> how the underlying code is generated. I know C pretty well, I can tell
> from C code roughly how the assembly output will look, and from C
> structs exactly how the memory will be laid out. I can't tell this
> with Lisp. Most of the time it doesn't matter, but sometimes I'd
> really like to be able to use statically typed code within Lisp, so
> that the assembler output is predictable.
>
> Probably I am just new to Lisp though and it will come with time :)
>
> Brad
I am new to lisp. The hyperspec is long but very good for newcomers
like me. It not only shows me how to do something but also gives me an
(good) explaination of why to do it like that, and I always find what I
need with some examples.
Thanks to the committee for the great effort.
keyboard
"bradb" <··············@gmail.com> writes:
> There are none that bother me, and none I can specifically put my
> finger on. But most implementation docs that I have read use phrases
> like "we aim to adhere to the ANSI spec". My real point was that the
> hyperspec is a fairly lengthy document - does it really need to be
> quite so big? But, as I say - I'm a noob :) I've never read the C
> ANSI documents, maybe they are huge too.
>
> Don't get me wrong, I really enjoy learning about and using CL - it's
> just that in a few places I've been left with the impression that life
> could be better. For the curious, my personal pain is in not knowing
> how the underlying code is generated. I know C pretty well, I can tell
> from C code roughly how the assembly output will look, and from C
> structs exactly how the memory will be laid out. I can't tell this
> with Lisp. Most of the time it doesn't matter, but sometimes I'd
> really like to be able to use statically typed code within Lisp, so
> that the assembler output is predictable.
>
> Probably I am just new to Lisp though and it will come with time :)
I suspect part of it is newness to the language. However, my personal
experience has been that the hardest part to come to terms with in CL
is that because the language is so powerful and expressive, there are
many many different ways of approaching the problem and no easy way
apart from experience to tell which is the best solution. Nearly all
the CL code I've written has multiple different solutions and
implementations, which to my new eyes seem equally valid.
I beleive this makes new users a bit uncomfortable because they are
not use to this. In languages like C, Java, C++ etc, you quickly find
out what the language is and is not good at and this constrains your
solution space somewhat. As a newbie, this is comforting, but as you
become more experienced it soon becomes frustrating. CL strikes me as
being the opposite - its quite uncomfortable (but fun) at the
beginning and only becomes really comfortable with experience - as
others have said, lisp is easy to learn, but hard to master.
Tim
>
--
tcross (at) rapttech dot com dot au
Peter Seibel <·····@gigamonkeys.com> writes:
> "bradb" <··············@gmail.com> writes:
>
>> Well written. I'm am almost a complete newbie at Lisp, so please
>> take what I say with big grains of salt. It appears to me that the
>> CL community has a lot of inertia, the language and the spec are old
>> (read mature if you prefer), but few implementations actually have
>> full ANSI compliance. Isn't there something wrong when there are no
>> ANSI compliant free implementations 20 years after the spec was
>> written? Most implementations are probably very close, but there are
>> probably still weird little cracks where stuff falls out.
>
> So what areas of non-compliance in what implementations are causing
> you pain? As far as I can tell, all the serious commercial and free
> implementations work quite hard to conform to the spec and I can't
> think, offhand, of any areas where implementations intentionally
> deviate from the spec with no intention of fixing it when they get
> around to it.
PROG2.
Christophe
Christophe Rhodes <·····@cam.ac.uk> writes:
>> So what areas of non-compliance in what implementations are causing
>> you pain? As far as I can tell, all the serious commercial and free
>> implementations work quite hard to conform to the spec and I can't
>> think, offhand, of any areas where implementations intentionally
>> deviate from the spec with no intention of fixing it when they get
>> around to it.
>
> PROG2.
>
> Christophe
What does this mean?
Bill Atkins <············@rpi.edu> wrote:
> Christophe Rhodes <·····@cam.ac.uk> writes:
> > Peter Seibel <·····@gigamonkeys.com> writes:
> >> I can't think, offhand, of any areas where implementations
> >> intentionally deviate from the spec with no intention of fixing it when
> >> they get around to it.
> >
> > PROG2.
>
> What does this mean?
PROG2 is specified as being equivalent to PROG1. See the Description at
<http://www.lispworks.com/documentation/HyperSpec/Body/m_prog1c.htm>:
| prog2 evaluates first-form, then second-form, and then forms,
| yielding as its only value the primary value yielded by first-form.
This is usually regarded as an accident and an error. Consequently
implementations write it as people expect rather than as specified.
(But not all of them document their wilfully deviant behaviour...)
--
Duncan Harvey
Duncan Harvey <··············@abbrvtd.org.uk> wrote:
+---------------
| Bill Atkins <············@rpi.edu> wrote:
| > Christophe Rhodes <·····@cam.ac.uk> writes:
| > > Peter Seibel <·····@gigamonkeys.com> writes:
| > >> I can't think, offhand, of any areas where implementations
| > >> intentionally deviate from the spec with no intention of
| > >> fixing it when they get around to it.
| > >
| > > PROG2.
| >
| > What does this mean?
|
| PROG2 is specified as being equivalent to PROG1. See the Description at
| <http://www.lispworks.com/documentation/HyperSpec/Body/m_prog1c.htm>:
|
| | prog2 evaluates first-form, then second-form, and then forms,
| | yielding as its only value the primary value yielded by first-form.
|
| This is usually regarded as an accident and an error. Consequently
| implementations write it as people expect rather than as specified.
| (But not all of them document their wilfully deviant behaviour...)
+---------------
But the "Syntax:" & "Arguments and Values:" sections *above* the part
you quoted strongly supports the interpretation that the "Description:"
text is the typo "accident", since the former two say this:
prog2 first-form second-form form* => result-2
...
result-2---the primary value resulting from the evaluation of second-form
So returning the second-form *IS* "as specified", if you take the
specification in the syntax/args section as being definitive rather
than the conflicting description text.
Unfortunately, neither "1.4.4 Interpreting Dictionary Entries"
nor "1.4.3 Sections Not Formally Part Of This Standard" deals
with the proper interpretation between conflicting texts which
*are* all formally part of the standard.[1] So we have these
silly arguments, even when it's *obvious* which is correct... ;-}
-Rob
[1] Well, "1.5.1.4.1 Resolution of Apparent Conflicts in Exceptional
Situations" covers one case, but that's not germane here.
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
····@rpw3.org (Rob Warnock) writes:
> So returning the second-form *IS* "as specified", if you take the
> specification in the syntax/args section as being definitive rather
> than the conflicting description text.
It's also exemplified ...
(setq temp 1) => 1
(prog2 (incf temp) (incf temp) (incf temp)) => 3
temp => 4
(prog2 1 (values 2 3 4) 5) => 2
While the examples are not part of the standard, CLHS 1.4.4.9, they
ratify one of the two meanings that are given by the standard. This
is a strong indicator of the intended meaning of the standard. If the
example conformed to neither statement in the standard, then it would
be an incorrect example, but as it is the example is perfectly
consistent with one of the meanings in the standard.
Ron,
Where's your proposed solution?
Pissing on people's legs to get their attention is rarely a great way
of convincing them to change. Stop alienating yourself if you want to
bring some value into the community.
Erik.
In article <························@e56g2000cwe.googlegroups.com>,
"Erik Enge" <·········@gmail.com> wrote:
> Ron,
>
> Where's your proposed solution?
I don't have one. I'm still at the stage of trying to convince people
that there is a problem.
> Pissing on people's legs to get their attention is rarely a great way
> of convincing them to change. Stop alienating yourself if you want to
> bring some value into the community.
Sorry, I don't accept the proposition that pointing out problems equates
to "pissing on people's legs." That's one of the problems with CL. The
community has this
you're-either-with-us-or-you're-with-the-Perl-terrorists point of view.
This is an impediment to progress (and not just in the realm of
programming languages).
rg
Ron Garret wrote:
> I don't have one. I'm still at the stage of trying to convince people
> that there is a problem.
This will get you nowhere. If you wanted change you would've
approached the community with more respect and constructive ideas
instead of just trying to get us to agree that there's a problem while
being patronizing. You don't even have to be a parent or a
psychologist to realize this.
> Sorry, I don't accept the proposition that pointing out problems equates
> to "pissing on people's legs." That's one of the problems with CL.
No, that's not one of the problems with Common Lisp. There's a
difference between pointing out problems in a constructive, productive
way and just being a troll. If you really cared about making a
difference you would've applied more effort in the delivery of your
message.
Erik.
Ron Garret <·········@flownet.com> writes:
> In article <························@e56g2000cwe.googlegroups.com>,
> "Erik Enge" <·········@gmail.com> wrote:
>
>> Ron,
>>
>> Where's your proposed solution?
>
> I don't have one. I'm still at the stage of trying to convince people
> that there is a problem.
>
>> Pissing on people's legs to get their attention is rarely a great way
>> of convincing them to change. Stop alienating yourself if you want to
>> bring some value into the community.
>
> Sorry, I don't accept the proposition that pointing out problems equates
> to "pissing on people's legs." That's one of the problems with CL. The
> community has this
> you're-either-with-us-or-you're-with-the-Perl-terrorists point of view.
> This is an impediment to progress (and not just in the realm of
> programming languages).
>
> rg
The problem with this is that pointing out problems doesn't create
progress - it just points out problems. To get progress, you need to
do both - point out problems and propose a solution to resolve the
problem. Your solution might get ripped apart, but that IMO is
progress because now people are thinking about the solution and not
just hearing yet another list of problems which get repeated with
monotonous regularity in this group.
I also think pointing out problems is easy and lazy - I can sit all
day pointing out problems about the world, but it has absolutely no
impact and really costs me nothing in effort. Trying to also suggest
constructive annd practicle solutions is much more difficult and I
think a far more worthy effort.
Tim
--
tcross (at) rapttech dot com dot au
In article <··············@tiger.rapttech.com.au>,
Tim X <····@nospam.dev.null> wrote:
> Ron Garret <·········@flownet.com> writes:
>
> > In article <························@e56g2000cwe.googlegroups.com>,
> > "Erik Enge" <·········@gmail.com> wrote:
> >
> >> Ron,
> >>
> >> Where's your proposed solution?
> >
> > I don't have one. I'm still at the stage of trying to convince people
> > that there is a problem.
> >
> >> Pissing on people's legs to get their attention is rarely a great way
> >> of convincing them to change. Stop alienating yourself if you want to
> >> bring some value into the community.
> >
> > Sorry, I don't accept the proposition that pointing out problems equates
> > to "pissing on people's legs." That's one of the problems with CL. The
> > community has this
> > you're-either-with-us-or-you're-with-the-Perl-terrorists point of view.
> > This is an impediment to progress (and not just in the realm of
> > programming languages).
> >
> > rg
>
> The problem with this is that pointing out problems doesn't create
> progress - it just points out problems. To get progress, you need to
> do both - point out problems and propose a solution to resolve the
> problem. Your solution might get ripped apart, but that IMO is
> progress because now people are thinking about the solution and not
> just hearing yet another list of problems which get repeated with
> monotonous regularity in this group.
>
> I also think pointing out problems is easy and lazy - I can sit all
> day pointing out problems about the world, but it has absolutely no
> impact and really costs me nothing in effort. Trying to also suggest
> constructive annd practicle solutions is much more difficult and I
> think a far more worthy effort.
>
> Tim
Yes, I mostly agree with you. That's why I don't do this sort of thing
much any more. The only reason I piped up this time is because SteveY
was being ripped to shreds for the wrong reasons. Since I agreed with
the point he was making I felt duty-bound to stand up.
rg
Ron Garret wrote:
> 3. I do not hate Lisp. It is and has always been my favorite
> programming languages. My love for Lisp pretty much destroyed my career
> as a programmer. My motivation for criticising Lisp is not to convince
> people not to use it. It is to effect changes that I believe are
> necessary to get more people to use it.
Since you wrote this to effect changes, do you have any proposals on
how to achieve these changes?
When I first looked at clrfi I thought this would be the way to do
additions to the ansi-standard (processes, sockets, ...) , but it seems
that it is simply not working for whatever (legal ?) reason.
I spent this afternoon hacking cl-http on a platform it was not
developed for, so I can confirm, that the situation is improvable but
not hopeless.
salud2
Karsten
In article <························@i39g2000cwa.googlegroups.com>,
"karsten" <·············@gmail.com> wrote:
> Ron Garret wrote:
> > 3. I do not hate Lisp. It is and has always been my favorite
> > programming languages. My love for Lisp pretty much destroyed my career
> > as a programmer. My motivation for criticising Lisp is not to convince
> > people not to use it. It is to effect changes that I believe are
> > necessary to get more people to use it.
> Since you wrote this to effect changes, do you have any proposals on
> how to achieve these changes?
Nope. CLRFI seems like a step in the right direction, but this is not
my call. My mission is just to convince people that this is a goal
worth striving for.
> When I first looked at clrfi I thought this would be the way to do
> additions to the ansi-standard (processes, sockets, ...) , but it seems
> that it is simply not working for whatever (legal ?) reason.
Yep, I don't understand this either.
> I spent this afternoon hacking cl-http on a platform it was not
> developed for, so I can confirm, that the situation is improvable but
> not hopeless.
That's the spirit!
rg
In article <························@i39g2000cwa.googlegroups.com>,
"karsten" <·············@gmail.com> wrote:
> Ron Garret wrote:
> > 3. I do not hate Lisp. It is and has always been my favorite
> > programming languages. My love for Lisp pretty much destroyed my career
> > as a programmer. My motivation for criticising Lisp is not to convince
> > people not to use it. It is to effect changes that I believe are
> > necessary to get more people to use it.
> Since you wrote this to effect changes, do you have any proposals on
> how to achieve these changes?
>
> When I first looked at clrfi I thought this would be the way to do
> additions to the ansi-standard (processes, sockets, ...) , but it seems
> that it is simply not working for whatever (legal ?) reason.
>
> I spent this afternoon hacking cl-http on a platform it was not
> developed for, so I can confirm, that the situation is improvable but
> not hopeless.
>
> salud2
>
> Karsten
He, I also was hacking today CL-HTTP related code (web log analysis)
on a platform CL-HTTP is (!) developed
for: LispWorks on Mac OS X. I was reviving some code
I wrote maybe eight years ago on my Symbolics MacIvory.
There were almost zero porting issues. I spend
the day enhancing the code and writing web log reports.
That's also the beauty of Common Lisp: I can come
back to old code, understand easily it after years and
enhance it.
I would expect that much of my code runs mostly
unchanged on, say, five different operating systems
(Windows, Mac OS X, Genera, Linux, ...)
and, say. five different Common Lisp implementions
(CMUCL , Genera, LispWorks, Allegro CL, MCL, ...).
Well, for me this is enough.
For me CL-HTTP provides the networking library on these
platforms.
Other than that I was just checking in a OODB database
written in a more than ten thousand lines of Common Lisp
in my home Subversion repository. The software sits
on top of a very extensive layer of compatibility
code (locks, processes, data types, byte-order,
defsystem, once-only, queues, semaphores, ...).
That's the way many larger Lisp software tends to be written:
based on some portability layer. With that it is not
too difficult to move Common Lisp code around between
platforms. It takes just a bit of Lisp software engineering.
Currently I have zero interest in new Lisp dialects.
What currently interests and faszinates me: how to make
use of the tremendous power of current Common Lisp
implementations.
--
http://lispm.dyndns.org/
In article <····························@news-europe.giganews.com>,
Rainer Joswig <······@lisp.de> wrote:
> That's the way many larger Lisp software tends to be written:
> based on some portability layer.
Why "some" portability layer? Why not just one? Maintaining multiple
portability layers seems like a waste of effort.
BTW, your portability layer sounds pretty wizzy. Is it available?
rg
Rainer Joswig <······@lisp.de> writes:
>
> He, I also was hacking today CL-HTTP related code (web log analysis)
> on a platform CL-HTTP is (!) developed
> for: LispWorks on Mac OS X. I was reviving some code
> I wrote maybe eight years ago on my Symbolics MacIvory.
> There were almost zero porting issues. I spend
> the day enhancing the code and writing web log reports.
> That's also the beauty of Common Lisp: I can come
> back to old code, understand easily it after years and
> enhance it.
Eeks how old fashioned you are ;-). Your dare to come back to your
code?
Ah, yes that's something different with "modern" languages. Write
once, run maybe, maybe not, maybe ....
Happy lisping
Friedrich
--
Please remove just-for-news- to reply via e-mail.
Ron Garret <·········@flownet.com> writes:
> Two things to get out of the way at the outset:
>
> 1. Note that the title of this post is *HOW* CL sucks, not *WHY* it
> sucks. The difference is significant. Please take the time to
> understand it before you flame me.
>
> 2. I'm not going to say anything I haven't said a thousand times
> before, so those of you who know me (that means you, Kenny) will not
> find anything new here so you may as well not even bother.
>
> I am writing this because of the debate surrounding Steve Yegge's recent
> blog entries on Lisp. It is unfortunate that he made so many technical
> mistakes in his posts because they distract people from the fact that
> underneath all the errors he is actually making a valid point, that
> being that CL has very significant problems that are barriers to its
> adoption. (Some people think this is a feature, that having a few
> obstacles to overcome keeps out the rif raf. I suppose this is a
> defensible position, but I don't subscribe to it.)
>
> I'm going to point out just three problems with CL. There are more.
> None of these are original observations.
>
> 1. CL lacks standardized support for many operations that are
> necessities in today's world (e.g. sockets, database connectivity,
> foreign functions). Moreover, it lacks any mechanism by which these
> features could be standardized. It is claimed that there are portable
> libraries that work across implementations that provide de facto
> standards, e.g. UFFI, but these claims are false. I don't have time to
> get into details at the moment, but the fact of the matter is that
> trying to use Lisp for e.g. writing a Web server is an incredibly
> painful experience compared to doing the same thing in e.g. Python.
>
> The Balkanization of the CL implementation space also has the
> consequence that one must choose between using implementation-specific
> features and thus limiting the potential audience for one's code to a
> niche within a niche, or writing to the least common denominator, which
> generally means writing an awful lot of #+ reader macros.
Add a compat.lisp file to your source tree. Keep all the code that
relies on conditional read macros in there. In the one project I've
done where cross-Lisp compatability mattered, this was sufficient.
You're too busy to go into the details, so I'm not sure where the
trivial-* packages, etc. fall short for you, but they've worked pretty
well in my own experience.
> 2. Even for the one thing that CL claims to be particularly good at --
> as a platform for embedding domain-specific languages -- it has
> significant limits. To embed languages that differ from CL's semantics
> in certain ways requires significant effort. To cite but one example: I
> would like to embed a language that is very similar to Common Lisp, but
> which differs in how it handles global variable references (to use
> global lexical environments) and ((function-returning-a-function)
> arguments) syntax. The former can be done using symbol macros, but only
> if the top-level definitions precede their first use. If you reference
> a global before defining it then you're screwed. The latter cannot be
> done at all within CL unless you write a full code walker. But adding
> this capability is utterly trivial within an implementation. In MCL it
> takes two lines of code. And if it were done it would result in
> strictly greater expressive power. Furthermore, it is not even
> necessary to agree on the semantics of ((...) ...). One could simply
> add a new macro defining form (or even a global variable) to set a
> user-definable hook for transforming expressions whose CARs are lists
> that do not begin with LAMDBA. All that would need to be agreed upon is
> the name of this form. Furthermore, this would result in strictly
> greater expressive power. It would be strictly backwards-compatible.
> And It would serve the needs of a number of users who are not currently
> being served (e.g. those who prefer to do functional-style programming
> without having to type FUNCALL all the time.)
>
> But despite the fact that this change is easy and only good could come
> of it, it does not happen because there is no process by which this
> change can be effected (which is, I believe, a direct consequence of the
> fact that the realities of CL politics are that CL is utterly resistant
> to all change, though I would dearly love to be proven wrong on that).
>
> (Oh, and anyone who wishes to prove me wrong, please not that there is a
> big big difference between effecting change in CL and effecting change
> in an implementation of CL.)
>
> 3. Much of CL's core is badly designed. For example, consider NTH and
> ELT. The functionality of ELT is a strict superset of NTH, so why have
> NTH cluttering up the language? (To say nothing of the fact that the
Yes, this is an issue that often comes up when programming. I want to
get an element in a sequence by index. I start to use ELT, but then I
realize that NTH is in the language, too, and I spend a couple of
hours considering the profound philosophical implications of this.
> order of the arguments in these two functions are gratuitously
> reversed.) Why is the function that computes the difference of two sets
The reversal of arguments _is_ truly annoying.
> called SET-DIFFERENCE, but the function that computes the intersection
> of two sets called simply INTERSECTION? And why do all of these
> functions operate on lists, not sets? It's because there are no sets in
> CL, which means that CL leads one to prematurely "optimize" sets as
> lists. (I put optimize in scare quotes because in fact this is rarely
> an optimization, especially when your sets get big, and most of the time
> you have to go back and rip out huge chunks of code to replace your
> lists with hash tables or binary trees.) I could go on and on.
This is not a fault in the language, as far as I'm concerned. The
operations you mention are often useful for lists. Is it really a
problem that set terminology is used to describe these functions? A
programmer ought to understand that if he or she wants the behavior of
an actual set data structure, then these functions will not do. But
they are often convenient because these operations are fairly commonly
performed on lists.
This point seems comically pedantic. What is your proposal? Take
out the set functions because their names are confusing? Add a
full-fledged set data structure? How does this "problem" demonstrate
the bad design of CL's core?
>
> Now, for those of you who wish to respond I ask you to keep in mind the
> following:
>
> 1. The details of my criticisms are mostly irrelevant. What matters is
> that CL is far from perfect, and that it has no mechanism for change.
> So don't bother picking a nit about one of my specific criticisms unless
> you wish to argue that CL is perfect and doesn't need to change.
>
> 2. I know a lot more about Lisp that Steve Yegge. I spent twenty years
> programming in Lisp for a living. I have authored some highly
> referenced papers on Lisp. I am far from the world's foremost expert,
> but I'm no newbie. If you think I'm wrong about a technical point you
> should think twice.
>
> 3. I do not hate Lisp. It is and has always been my favorite
> programming languages. My love for Lisp pretty much destroyed my career
> as a programmer. My motivation for criticising Lisp is not to convince
> people not to use it. It is to effect changes that I believe are
> necessary to get more people to use it. To quote Paul Graham, "It's not
> Lisp that sucks, it's Common Lisp that sucks." And actually, I would
> soften that somewhat: it's not Common Lisp that sucks, it's some parts
> of Common Lisp that suck. But make no mistake, some parts of Common
> Lisp really do suck, and unless they are fixed a lot of people -- myself
> included -- won't be able to use it even though they may want to really
> badly.
>
> rg
In article <··············@rpi.edu>, Bill Atkins <············@rpi.edu>
wrote:
> > order of the arguments in these two functions are gratuitously
> > reversed.) Why is the function that computes the difference of two sets
>
> The reversal of arguments _is_ truly annoying.
>
> > called SET-DIFFERENCE, but the function that computes the intersection
> > of two sets called simply INTERSECTION? And why do all of these
> > functions operate on lists, not sets? It's because there are no sets in
> > CL, which means that CL leads one to prematurely "optimize" sets as
> > lists. (I put optimize in scare quotes because in fact this is rarely
> > an optimization, especially when your sets get big, and most of the time
> > you have to go back and rip out huge chunks of code to replace your
> > lists with hash tables or binary trees.) I could go on and on.
>
> This is not a fault in the language, as far as I'm concerned. The
> operations you mention are often useful for lists. Is it really a
> problem that set terminology is used to describe these functions?
Yes. It confuses newcomers. It encourages them to prematurely
"optimize" set operations by implementing them using lists. And it
consumes valuable namespace real estate. SET-DIFFERENCE ought to be a
function that computes the difference of sets, nothing else. And
forcing it to be something else IN THE STANDARD is an abomination.
> A programmer ought to understand that if he or she wants the behavior of
> an actual set data structure, then these functions will not do.
Of course. Programmers ought to understand all sorts of things. But
they don't, especially not when they are new.
rg
Ron Garret <·········@flownet.com> writes:
> In article <··············@rpi.edu>, Bill Atkins <············@rpi.edu>
> wrote:
>
>> > order of the arguments in these two functions are gratuitously
>> > reversed.) Why is the function that computes the difference of two sets
>>
>> The reversal of arguments _is_ truly annoying.
>>
>> > called SET-DIFFERENCE, but the function that computes the intersection
>> > of two sets called simply INTERSECTION? And why do all of these
>> > functions operate on lists, not sets? It's because there are no sets in
>> > CL, which means that CL leads one to prematurely "optimize" sets as
>> > lists. (I put optimize in scare quotes because in fact this is rarely
>> > an optimization, especially when your sets get big, and most of the time
>> > you have to go back and rip out huge chunks of code to replace your
>> > lists with hash tables or binary trees.) I could go on and on.
>>
>> This is not a fault in the language, as far as I'm concerned. The
>> operations you mention are often useful for lists. Is it really a
>> problem that set terminology is used to describe these functions?
>
> Yes. It confuses newcomers. It encourages them to prematurely
> "optimize" set operations by implementing them using lists. And it
> consumes valuable namespace real estate. SET-DIFFERENCE ought to be a
> function that computes the difference of sets, nothing else. And
> forcing it to be something else IN THE STANDARD is an abomination.
Many things confuse newcomers - that's hardly sufficient grounds to
remove them from the language. I don't think anyone is trying to pass
off the set functions as "optimizations" nor do I think anyone could
reasonably come to the conclusion that treating lists as sets should
somehow be more "optimized" than using an actual set data structure.
I'm not sure where you see optimization fitting into this.
I think having these functions in the standard is as far from an
abomination as possible. These are useful functions. If you have
problems with the naming, then maybe you can recommend some new names.
But I think naming these after the set operations makes it immediately
clear what these functions will do to their arguments. I do not think
they give any impression that they will provide greater performance.
>> A programmer ought to understand that if he or she wants the behavior of
>> an actual set data structure, then these functions will not do.
>
> Of course. Programmers ought to understand all sorts of things. But
> they don't, especially not when they are new.
>
> rg
--
Bill
In article <··············@rpi.edu>, Bill Atkins <············@rpi.edu>
wrote:
> Many things confuse newcomers - that's hardly sufficient grounds to
> remove them from the language.
It is if you care about attracting new users.
rg
Ron Garret <·········@flownet.com> writes:
> In article <··············@rpi.edu>, Bill Atkins <············@rpi.edu>
> wrote:
>
>> Many things confuse newcomers - that's hardly sufficient grounds to
>> remove them from the language.
>
> It is if you care about attracting new users.
>
> rg
New users are only new users for a little while. It's more important
to provide useful features than to keep newcomers happy for the couple
of months they can be called newcomers.
Macros and CLOS are very confusing to newcomers (if my experience can
be considered typical) and yet these are part of what makes Lisp such
a great environment to program in. Removing them would definitely not
be a win - nor would dumbing them down for the sake of newbies. A
better strategy is to rely on great books like Practical Common Lisp
to teach newcomers the ins and outs of Lisp and then to support
features that make the language more convenient for use in the real
world.
--
Bill
In article <·······························@news.gha.chartermi.net>,
Ron Garret <·········@flownet.com> wrote:
> 1. CL lacks standardized support for many operations that are
> necessities in today's world (e.g. sockets, database connectivity,
> foreign functions).
So do C, C++, and Perl. To get these things in most languages you need
to make use of libraries or standards beyond the core language. For
instance, sockets are not part of C, they're part of POSIX.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
In article <····························@comcast.dca.giganews.com>,
Barry Margolin <······@alum.mit.edu> wrote:
>In article <·······························@news.gha.chartermi.net>,
> Ron Garret <·········@flownet.com> wrote:
>
>> 1. CL lacks standardized support for many operations that are
>> necessities in today's world (e.g. sockets, database connectivity,
>> foreign functions).
>
>So do C, C++, and Perl. To get these things in most languages you need
>to make use of libraries or standards beyond the core language. For
>instance, sockets are not part of C, they're part of POSIX.
Indeed, so in a way it is not a fair comparison. Nonetheless, it is
the comparison that matters.
When I write threaded C code using POSIX pthreads the same application
works with any compiler.
I am using SBCL, which turns out only supports (a non-standard)
threads API on Linux x86. Is there even any free lisp which supports
threads on Linux x86, Solaris (x86 & SPARC) and OS X?
For now I'm using lisp as a scripting language while learning, so I'm
not going to worry about that. I'll try to figure out a solution when
I need it. But I know it's a looming problem on the horizon.
--
Jyri J. Virkki - Santa Cruz, CA
Jyri J. Virkki <·······@localhost.localdomain> wrote:
> I am using SBCL, which turns out only supports (a non-standard)
> threads API on Linux x86.
And Linux/x86-64.
> Is there even any free lisp which supports
> threads on Linux x86, Solaris (x86 & SPARC) and OS X?
A development branch of SBCL also has thread support on Solaris/x86,
FreeBSD/x86 and OS X/x86. (Though it's only truly stable on Solaris
and Linux at the moment; some of the thread-related tests in the SBCL
regression suite tend to cause kernel panics on OS X and FreeBSD).
--
Juho Snellman
Ron Garret <·········@flownet.com> writes:
> 2. I'm not going to say anything I haven't said a thousand times
> before, so those of you who know me (that means you, Kenny) will not
> find anything new here so you may as well not even bother.
Which raises the question: why? Last time I saw you, you were running
around looking for somewhere to invest your Googlebucks. So presumably
you have both free time and some financial resources to play with.
Given that, and assuming you really do care about the increasing the
adoption of Common Lisp, is posting the same argument to
comp.lang.lisp every six months really the best strategy you can come
up with for effecting some sort of change? Or to put it another way,
what, in the best case scenario, would you like to see happen as a
result of this most-recent post?
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
Peter Seibel wrote:
> Ron Garret <·········@flownet.com> writes:
>
>
>>2. I'm not going to say anything I haven't said a thousand times
>>before, so those of you who know me (that means you, Kenny) will not
>>find anything new here so you may as well not even bother.
>
>
> Which raises the question: why? <snip>....is posting the same argument to
> comp.lang.lisp every six months really the best strategy you can come
> up with for effecting some sort of change?
He must be looking for support from noobs. Trouble is they are either
code-nothing groupies (and what a fun army that would be to lead) or
they have work to do and have brushed off any trivial annoyances having
discovered what a joy and powerhouse is Lisp.
I am reminded of doing my first FFI bindings. A week of misery even with
UFFI, which was a great help, but drawing me on was the prospect of a
portable event-loop (FreeGlut). Now I can bind up a library in a couple
of days, and Swig or Vzn could make that even faster some day.
Anyway, if someone is not actually trying to do anything, bindings seem
like a problem. Not really, just part of the job. And of course Lisp
makes it easier -- a little macrology and I was able to do a poor-man's
FFI autogen.
ken
--
Cells: http://common-lisp.net/project/cells/
"Have you ever been in a relationship?"
Attorney for Mary Winkler, confessed killer of her
minister husband, when asked if the couple had
marital problems.
Ken Tilton wrote:
> I am reminded of doing my first FFI bindings. A week of misery even with
> UFFI, which was a great help, but drawing me on was the prospect of a
> portable event-loop (FreeGlut). Now I can bind up a library in a couple
> of days, and Swig or Vzn could make that even faster some day.
BTW: with callbacks there are interesting issues with stdcall versus cdecl.
GLUT uses cdecl, while the GLU tesselation callback functions use stdcall.
I've talked to Lu�s Oliveira on #lisp about this and maybe there will be
the ability to specify the calling convention in a new CFFI release.
With tesselation for concave polygons and my own line join implementation
(OpenGL doesn't do line joins at all for thick lines) now my 2D OpenGL code
is much more useful:
http://www.frank-buss.de/tmp/opengl2d3.png
http://www.frank-buss.de/tmp/flags.gif
http://www.frank-buss.de/tmp/opengl2d3.lisp.txt
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
In article <··············@gigamonkeys.com>,
Peter Seibel <·····@gigamonkeys.com> wrote:
> Ron Garret <·········@flownet.com> writes:
>
> > 2. I'm not going to say anything I haven't said a thousand times
> > before, so those of you who know me (that means you, Kenny) will not
> > find anything new here so you may as well not even bother.
>
> Which raises the question: why?
To annoy Kenny of course. That is my new purpose in life.
Seriously, it's because I thought SteveY raised a valid point, and I
didn't want that to get overshadowed by his technical errors.
> Last time I saw you, you were running
> around looking for somewhere to invest your Googlebucks. So presumably
> you have both free time and some financial resources to play with.
Less and less with every passing day.
> Given that, and assuming you really do care about the increasing the
> adoption of Common Lisp, is posting the same argument to
> comp.lang.lisp every six months really the best strategy you can come
> up with for effecting some sort of change?
Yep. And believe me, it's not for lack of trying that I can't come up
with anything better.
> Or to put it another way,
> what, in the best case scenario, would you like to see happen as a
> result of this most-recent post?
I don't have a single best-case scenario in mind. I would like to see
*some* process for managing change in CL emerge from somewhere and be
adopted by a big enough chunk of the community to matter. But for that
to happen I think the first step is to convince a critical mass of
people that this is even desirable. At the moment I feel like a voice
in the wilderness.
rg
Look, it seems that you want to improve, rather than replace, CL. If
that's correct, then you can split your proposed changes in 3
categories: those that can be done in portable CL, those that can be
done in CL but must use implementation-specific stuff within each
individual lisp, and those that must be within implementations. The
first category you can probably knock out in a few months/weeks, maybe
less. The second is libraries, which we are going to work on in SOC.
Help us! The third seems to me to be CLRFI territory. It would be
helpful, both to people who want to improve CL and to those who want to
design something better, if you wrote up the whole list of things that
are broken about CL, why it matters, and how they could be fixed. Then
there could be a huge discussion, historical context for the various
brokennesses would be brought forth, and maybe CLRFI would get started.
If nothing else, getting all the brokennesses in one spot would mean
that there is a central place to go to find things to fix.
In article <······················@v46g2000cwv.googlegroups.com>,
···········@gmail.com wrote:
> Look, it seems that you want to improve, rather than replace, CL.
I want *someone* to be able to improve it. Not necessarily me.
> if you wrote up the whole list of things that
> are broken about CL, why it matters, and how they could be fixed. Then
> there could be a huge discussion, historical context for the various
> brokennesses would be brought forth, and maybe CLRFI would get started.
Been there. Done that. Believe me, the limiting factor in improving CL
is not my pointing out what I think is wrong with it.
> If nothing else, getting all the brokennesses in one spot would mean
> that there is a central place to go to find things to fix.
Yes, wouldn't that be nice?
rg
Ron Garret <·········@flownet.com> writes:
> I don't have a single best-case scenario in mind. I would like to
> see *some* process for managing change in CL emerge from somewhere
> and be adopted by a big enough chunk of the community to matter. But
> for that to happen I think the first step is to convince a critical
> mass of people that this is even desirable. At the moment I feel
> like a voice in the wilderness.
Well, FWIW, I think a lot of people all ready agree with the broadest
strokes of your position.[1] What is lacking--as far as I can
tell--are simply resources. It really, really, really, seems to me
that spending more time writing code or documentation or politicking
implementors to adopt defacto standards or helping to organize the
efforts of other people who are interested in doing those things is
going to be far more likely to achieve the kinds of changes you claim
to care about than periodically posting your list of gripes about
Common Lisp. But you do what you want to do.
-Peter
[1] By "broadest strokes" I mean that many folks see ways that Common
Lisp the language + readily available libraries + documentation +
resources for new commers could fruitfully be improved and agree that
it would be a good thing if people could find the time to make those
improvements. As to whether there should be a "process for managing
change in CL", it's hard to say whether folks agree or not because it
depends a lot on what you mean by that. I'm with Pascal Costanza on
this--there already is a process: 1) write code 2) publish it 3)
evangelize it. But that apparently doesn't meet your criteria. So I'd
say the ball is in your court to propose a different process. Or at
least make explicit what your criteria for an acceptable process are.
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
In article <··············@gigamonkeys.com>,
Peter Seibel <·····@gigamonkeys.com> wrote:
> Ron Garret <·········@flownet.com> writes:
>
> > I don't have a single best-case scenario in mind. I would like to
> > see *some* process for managing change in CL emerge from somewhere
> > and be adopted by a big enough chunk of the community to matter. But
> > for that to happen I think the first step is to convince a critical
> > mass of people that this is even desirable. At the moment I feel
> > like a voice in the wilderness.
>
> Well, FWIW, I think a lot of people all ready agree with the broadest
> strokes of your position.[1] What is lacking--as far as I can
> tell--are simply resources. It really, really, really, seems to me
> that spending more time writing code or documentation or politicking
> implementors to adopt defacto standards
IMO the fact that it is necessary to politick (all of the) individual
implementors if one desires a change in the language is a symptom of the
underlying problem.
> or helping to organize the
> efforts of other people who are interested in doing those things is
> going to be far more likely to achieve the kinds of changes you claim
> to care about than periodically posting your list of gripes about
> Common Lisp. But you do what you want to do.
I do what I have time for.
> [1] By "broadest strokes" I mean that many folks see ways that Common
> Lisp the language + readily available libraries + documentation +
> resources for new commers could fruitfully be improved and agree that
> it would be a good thing if people could find the time to make those
> improvements. As to whether there should be a "process for managing
> change in CL", it's hard to say whether folks agree or not because it
> depends a lot on what you mean by that. I'm with Pascal Costanza on
> this--there already is a process: 1) write code 2) publish it 3)
> evangelize it. But that apparently doesn't meet your criteria. So I'd
> say the ball is in your court to propose a different process. Or at
> least make explicit what your criteria for an acceptable process are.
The criterion is that the process have an identifiable resolution. Are
Gray Streams "part of" CL yet? At the moment there is no way to know
(except perhaps by polling every available implementation, and even then
you always run the risk of someone writing a new one that doesn't have
them).
rg
Why not make a new library collection, for example we will call it
Alexandria ?
There's a plenty of proven code that isn't GPL licensed so commercial
vendors could pack it too, and ship the Alexandria with their
implementation.
We could pack staff like : Araneida, CL-SQL, ASDF, CFFI, Cello etc with
all their dependancies that the lisp newbie will get all of this with
their implementation or download Alexandria and here it is:
(require 'araneida) is all it needs.
No searching over internet , questionening etc.
Anybody who agrees post yea.
bobi
Ron Garret <·········@flownet.com> writes:
> In article <··············@gigamonkeys.com>,
> Peter Seibel <·····@gigamonkeys.com> wrote:
>> [1] By "broadest strokes" I mean that many folks see ways that
>> Common Lisp the language + readily available libraries +
>> documentation + resources for new commers could fruitfully be
>> improved and agree that it would be a good thing if people could
>> find the time to make those improvements. As to whether there
>> should be a "process for managing change in CL", it's hard to say
>> whether folks agree or not because it depends a lot on what you
>> mean by that. I'm with Pascal Costanza on this--there already is a
>> process: 1) write code 2) publish it 3) evangelize it. But that
>> apparently doesn't meet your criteria. So I'd say the ball is in
>> your court to propose a different process. Or at least make
>> explicit what your criteria for an acceptable process are.
>
> The criterion is that the process have an identifiable resolution.
> Are Gray Streams "part of" CL yet? At the moment there is no way to
> know (except perhaps by polling every available implementation, and
> even then you always run the risk of someone writing a new one that
> doesn't have them).
Okay. Suppose the ANSI process were reopened and the Gray Streams
proposal was munged around a bit and added to CL2006 (as if it would
be done in 2006 but we can dream.) Now suppose, say, the SBCL and
Allegro implementors decide that the munging went off the rails and
decide not to even "purport to conform" to CL2006. The process had an
identifiable resolution (per ANSI rules) but it hasn't actually
resolved anything and might actually make things more splintered since
now there would be not only multiple implementations but multiple
"official" standards.
I'd argue that the only resolution that *really* matters is the
resolution by critical mass. If enough implementations support Gray
Streams and enough libraries exist and are used by enough users that
implementation that *don't* support them become marginalized, then I'd
say they are part of CL for all practical purposes. If not then no
decree by any standard's body is going to fix it.
That said, there is useful work that could be done to build critical
mass. For instance someone with taste and good judgement could start
building a "CL Standard Library" by gathering together and packaging
in some uniform way the best libraries for doing various things and
packaging them up into a single distribution that can be easily
downloaded and installed into all the major CL implementations.
There's nothing to stop a single person from getting started on that
project today. And if they in fact have taste and good judgement *and*
the time and energy to carry through the first iteration or so, they
might even attract some like-minded folks to help them out. If it
really takes off, then maybe some implementations would start
including it in their own distributions and pretty soon CL would be
perceived as a "batteries included" kind of language and the
differences between implementations would become less significant as
percentage of the total language experience. And, for folks who want a
benevolent dictator, the CL Standard Library project could be run on
that model, assuming you can find a satisfactory dictator.
That's just one of many ideas. Since you seem to be short on time, and
perhaps inclination, to take on this kind of project yourslf, and
*are* interested, as I understand it, in learning the investment game,
maybe you should set up a small non-profit foundation that raises
money and dispenses grants to folks who want to do things like this
but still need to figure out how to make their mortgage payments. Or
approach the ALU about funding such a project within that organization
since the ALU has already jumped through all the hoops to incorporate
as a non-profit.
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
He wants to see Yahoo Stores Part II: The Return of the Wizards.
I'd like to see that.
Don
+++++++++++++++++++++++++++++++++++++++++++++++++++
Don Lindsay (jr) don.lindsay(at)gmail.com
"The good is sometimes the enemy of the great."
- Unknown
Ron Garret <·········@flownet.com> wrote:
> trying to use Lisp for e.g. writing a Web server is an incredibly
> painful experience compared to doing the same thing in e.g. Python.
I could list some web servers written in Common Lisp. And one of
them was the first HTTP 1.1 compliant server and used by the W3C
to debug the HTTP 1.1 reference implementation.
And the youngest of the Common Lisp web servers was first
released on 2005-12-31.
In article <······················@parsec.no-spoon.de>,
Stefan Scholl <······@no-spoon.de> wrote:
> Ron Garret <·········@flownet.com> wrote:
> > trying to use Lisp for e.g. writing a Web server is an incredibly
> > painful experience compared to doing the same thing in e.g. Python.
>
> I could list some web servers written in Common Lisp.
Yes, and it's probably a very long list. (And one of the items on that
list would be http://www.cliki.net/HTTP%20dot%20LSP.)
Now, compare any of those to the effort required to write a web server
in Python, where you can do:
import BaseHTTPServer
rg
Ron Garret <·········@flownet.com> writes:
> In article <······················@parsec.no-spoon.de>,
> Stefan Scholl <······@no-spoon.de> wrote:
>
>> Ron Garret <·········@flownet.com> wrote:
>> > trying to use Lisp for e.g. writing a Web server is an incredibly
>> > painful experience compared to doing the same thing in e.g. Python.
>>
>> I could list some web servers written in Common Lisp.
>
> Yes, and it's probably a very long list. (And one of the items on that
> list would be http://www.cliki.net/HTTP%20dot%20LSP.)
>
> Now, compare any of those to the effort required to write a web server
> in Python, where you can do:
>
> import BaseHTTPServer
>
> rg
That has nothing to do with the flaws or merits of Common Lisp, and by
no stretch of the imagination can that be considered "writing" a web
server.
--
Bill
In article <··············@rpi.edu>, Bill Atkins <············@rpi.edu>
wrote:
> Ron Garret <·········@flownet.com> writes:
>
> > In article <······················@parsec.no-spoon.de>,
> > Stefan Scholl <······@no-spoon.de> wrote:
> >
> >> Ron Garret <·········@flownet.com> wrote:
> >> > trying to use Lisp for e.g. writing a Web server is an incredibly
> >> > painful experience compared to doing the same thing in e.g. Python.
> >>
> >> I could list some web servers written in Common Lisp.
> >
> > Yes, and it's probably a very long list. (And one of the items on that
> > list would be http://www.cliki.net/HTTP%20dot%20LSP.)
> >
> > Now, compare any of those to the effort required to write a web server
> > in Python, where you can do:
> >
> > import BaseHTTPServer
> >
> > rg
>
> That has nothing to do with the flaws or merits of Common Lisp,
Of course it does.
In CL there are a lot of web servers because CL doesn't come with one
and none of the ones people have written are sufficient, otherwise
people would not keep writing new ones.
> and by
> no stretch of the imagination can that be considered "writing" a web
> server.
What difference does it make? The indisputable point is that to get a
web server up and running using Python takes substantially less effort
than to get one up and running using CL.
rg
Ron Garret <·········@flownet.com> writes:
> In article <··············@rpi.edu>, Bill Atkins <············@rpi.edu>
> wrote:
>
>> Ron Garret <·········@flownet.com> writes:
>>
>> > In article <······················@parsec.no-spoon.de>,
>> > Stefan Scholl <······@no-spoon.de> wrote:
>> >
>> >> Ron Garret <·········@flownet.com> wrote:
>> >> > trying to use Lisp for e.g. writing a Web server is an incredibly
>> >> > painful experience compared to doing the same thing in e.g. Python.
>> >>
>> >> I could list some web servers written in Common Lisp.
>> >
>> > Yes, and it's probably a very long list. (And one of the items on that
>> > list would be http://www.cliki.net/HTTP%20dot%20LSP.)
>> >
>> > Now, compare any of those to the effort required to write a web server
>> > in Python, where you can do:
>> >
>> > import BaseHTTPServer
>> >
>> > rg
>>
>> That has nothing to do with the flaws or merits of Common Lisp,
>
> Of course it does.
>
> In CL there are a lot of web servers because CL doesn't come with one
> and none of the ones people have written are sufficient, otherwise
> people would not keep writing new ones.
>
>> and by
>> no stretch of the imagination can that be considered "writing" a web
>> server.
>
> What difference does it make? The indisputable point is that to get a
> web server up and running using Python takes substantially less effort
> than to get one up and running using CL.
Your example does not set up a running web server. It includes the
library that would make that possible, but any language is going to
require more code to make the webserver do your bidding than merely
including the library.
For what it's worth, this is not so hard in Common Lisp:
(require :araneida)
or if you're not into the whole brevity thing:
(asdf:oos 'asdf:load-op :araneida)
But these examples don't prove much about the language. I take issue
with your claim that Python's web server is sufficient. I would
prefer a server that could be compiled to native code and that has
support for threads (e.g. Araneida) to one running on an interpreted
language.
> rg
Bill Atkins wrote:
> Ron Garret <·········@flownet.com> writes:
>
>> In article <··············@rpi.edu>, Bill Atkins <············@rpi.edu>
>> wrote:
>>
>>> Ron Garret <·········@flownet.com> writes:
[...]
>>>> Now, compare any of those to the effort required to write a web server
>>>> in Python, where you can do:
>>>>
>>>> import BaseHTTPServer
>>> That has nothing to do with the flaws or merits of Common Lisp,
>> Of course it does.
>>
>> In CL there are a lot of web servers because CL doesn't come with one
>> and none of the ones people have written are sufficient, otherwise
>> people would not keep writing new ones.
>>
>>> and by
>>> no stretch of the imagination can that be considered "writing" a web
>>> server.
>> What difference does it make? The indisputable point is that to get a
>> web server up and running using Python takes substantially less effort
>> than to get one up and running using CL.
>
> Your example does not set up a running web server. It includes the
> library that would make that possible, but any language is going to
> require more code to make the webserver do your bidding than merely
> including the library.
>
> For what it's worth, this is not so hard in Common Lisp:
>
> (require :araneida)
>
> or if you're not into the whole brevity thing:
>
> (asdf:oos 'asdf:load-op :araneida)
>
> But these examples don't prove much about the language. I take issue
> with your claim that Python's web server is sufficient. I would
> prefer a server that could be compiled to native code and that has
> support for threads (e.g. Araneida) to one running on an interpreted
> language.
One problem with this discussion is that "sufficient" depends enormously
on the power of a language and the inclinations of the people using it.
Whenever I pick up someone else's Lisp code for use, I have to
deliberately restrain myself from mucking with it, because it's so easy
and fun to tweak so that it does exactly what I want instead of just
enough of what I want to get the job done. I seldom if ever have that
inclination when picking up libraries or applications written in other
languages; instead, I'll put more effort into figuring out how to wring
what I need out of the stuff that's already there, because modifying it
is too much of a pain.
When you see only one of some library, feature or service available for
a particular language, that's typically not because it's so perfect but
because making it was so obviously (or apparently) difficult and painful
that no one else wants to start on that path. Better to use something
lousy than get nowhere. (Of course, the impression of power is where
Lisp sucks you in.)
paul
Ron Garret <·········@flownet.com> writes:
> In article <··············@rpi.edu>, Bill Atkins <············@rpi.edu>
> wrote:
>
>> Ron Garret <·········@flownet.com> writes:
>>
>> > In article <··············@rpi.edu>, Bill Atkins <············@rpi.edu>
>> > wrote:
>> >
>> >> Ron Garret <·········@flownet.com> writes:
>> >>
>> >> > In article <······················@parsec.no-spoon.de>,
>> >> > Stefan Scholl <······@no-spoon.de> wrote:
>> >> >
>> >> >> Ron Garret <·········@flownet.com> wrote:
>> >> >> > trying to use Lisp for e.g. writing a Web server is an incredibly
>> >> >> > painful experience compared to doing the same thing in e.g. Python.
>> >> >>
>> >> >> I could list some web servers written in Common Lisp.
>> >> >
>> >> > Yes, and it's probably a very long list. (And one of the items on that
>> >> > list would be http://www.cliki.net/HTTP%20dot%20LSP.)
>> >> >
>> >> > Now, compare any of those to the effort required to write a web server
>> >> > in Python, where you can do:
>> >> >
>> >> > import BaseHTTPServer
>> >> >
>> >> > rg
>> >>
>> >> That has nothing to do with the flaws or merits of Common Lisp,
>> >
>> > Of course it does.
>> >
>> > In CL there are a lot of web servers because CL doesn't come with one
>> > and none of the ones people have written are sufficient, otherwise
>> > people would not keep writing new ones.
>> >
>> >> and by
>> >> no stretch of the imagination can that be considered "writing" a web
>> >> server.
>> >
>> > What difference does it make? The indisputable point is that to get a
>> > web server up and running using Python takes substantially less effort
>> > than to get one up and running using CL.
>>
>> Your example does not set up a running web server.
>
> I never said it did. But it is a good first step.
>
>
>> For what it's worth, this is not so hard in Common Lisp:
>>
>> (require :araneida)
>>
>> or if you're not into the whole brevity thing:
>>
>> (asdf:oos 'asdf:load-op :araneida)
>
> Except it doesn't work:
It doesn't work because the software isn't installed. It's no more
than a coincidence that Python comes with a web server and that you
want to use a web server. Imagine that instead you want to install
database bindings (which I am assuming don't come with Python - if
they do, we'll use the example of a GUI). They need to be installed
in either language. This is not an inherent advantage in Python; it
is a consequence of the fact that software cannot be run until it's
loaded into memory.
>
>
>
> [···@Mini:~]$ sbcl
> This is SBCL 0.9.7, an implementation of ANSI Common Lisp.
> More information about SBCL is available at <http://www.sbcl.org/>.
>
> SBCL is free software, provided as is, with absolutely no warranty.
> It is mostly in the public domain; some portions are provided under
> BSD-style licenses. See the CREDITS and COPYING files in the
> distribution for more information.
> * (require :araneida)
>
> debugger invoked on a SB-INT:EXTENSION-FAILURE:
> Don't know how to REQUIRE ARANEIDA.
> See also:
> The SBCL Manual, Variable *MODULE-PROVIDER-FUNCTIONS*
> The SBCL Manual, Function REQUIRE
>
> Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
>
> restarts (invokable by number or by possibly-abbreviated name):
> 0: [ABORT] Exit debugger, returning to top level.
>
> (SB-IMPL::REQUIRE-ERROR "Don't know how to ~S ~A.")
> 0] ^D
> * (asdf:oos 'asdf:load-op :araneida)
>
> debugger invoked on a SB-KERNEL:READER-PACKAGE-ERROR:
> READER-ERROR at 609 on #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN*
> {8015F41}>:
> package "ASDF" not found
>
> Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
>
> restarts (invokable by number or by possibly-abbreviated name):
> 0: [ABORT] Exit debugger, returning to top level.
>
> (SB-IMPL::READ-TOKEN #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN* {8015F41}>
> #\a)
> 0]
>
>
>
> It gets worse. When you try to exit the debugger at this point you get:
>
>
>
> debugger invoked on a SB-KERNEL:READER-PACKAGE-ERROR:
> READER-ERROR at 783 on #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN*
> {8015F41}>:
> package "ASDF" not found
>
> Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
>
> restarts (invokable by number or by possibly-abbreviated name):
> 0: [ABORT] Exit debugger, returning to top level.
>
> (SB-IMPL::READ-TOKEN #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN* {8015F41}>
> #\a)
> 0] ^D
> *
> :ARANEIDA
> *
> debugger invoked on a READER-ERROR:
> READER-ERROR at 967 on #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN*
> {8015F41}>:
> unmatched close parenthesis
>
> Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
>
> restarts (invokable by number or by possibly-abbreviated name):
> 0: [ABORT] Exit debugger, returning to top level.
>
> (SB-IMPL::%READER-ERROR
> #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN* {8015F41}>
> "unmatched close parenthesis")
> 0] ^D
> *
>
>
> Try to look at the above from the point of view of a newcomer, and
> compare the experience the corresponding one in Python.
This is a problem of public relations, not of technology, and just a
plain silly argument. I could complain that as a newcomer to Python,
the significant whitespace would be confusing. Look:
····@lambda /home/bill % python 5:21PM
Python 2.4.2 (#2, Sep 30 2005, 21:19:01)
[GCC 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu8)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> a = 45 +
File "<stdin>", line 1
a = 45 +
^
SyntaxError: invalid syntax
I'm a confused newcomer and I assume that lines in Python are
terminated with semicolons and can be continued onto other lines.
What should my reaction be to this error? I should go out and read up
on Python, like the hypothetical user in your example should go out
and read up on SLIME.
It would be unfair for me to claim this as a drawback to using Python
because NEWCOMERS ARE ALWAYS CONFUSED UNTIL THEY LEARN WHAT THEY'RE
DOING. This is almost not worth saying, but you seem to disagree.
Technical issues should be addressed. I agree with you that it would
be nice to have threads standardized, and sockets too. I don't agree
that the existence of NTH is a huge problem in Lisp usage. I don't
agree that the lack of a packaged-in web server is a problem, and I
don't agree that SBCL's restart prompts are a problem because new
users might not understand what they mean.
> rg
Bill Atkins <············@rpi.edu> writes:
> Ron Garret <·········@flownet.com> writes:
>
>> In article <··············@rpi.edu>, Bill Atkins <············@rpi.edu>
>> wrote:
>>
>>> Ron Garret <·········@flownet.com> writes:
>>>
>>> > What difference does it make? The indisputable point is that to get a
>>> > web server up and running using Python takes substantially less effort
>>> > than to get one up and running using CL.
>>>
>>> Your example does not set up a running web server.
>>
>> I never said it did. But it is a good first step.
>>
>>
>>> For what it's worth, this is not so hard in Common Lisp:
>>>
>>> (require :araneida)
>>>
>>> or if you're not into the whole brevity thing:
>>>
>>> (asdf:oos 'asdf:load-op :araneida)
>>
>> Except it doesn't work:
>
> It doesn't work because the software isn't installed. It's no more
> than a coincidence that Python comes with a web server and that you
> want to use a web server. Imagine that instead you want to install
> database bindings (which I am assuming don't come with Python
Didn't use to, but apparently, the Python 2.5 standard library will
include an sqlite module. [1]
> - if they do, we'll use the example of a GUI).
Python comes with Tkinter, an interface to Tcl/Tk.
> They need to be installed in either language. This is not an
> inherent advantage in Python;
You're right, it's not an advantage of the language itself, but it's
an advantage of Python's standard library. Here are some other things
that are part of Python's library:
- very good (IMO) string services
- regular expressions
- generic OS module (pathnames, processes etc.)
- XML parser (both SAX and DOM)
- threads & locks
- an FTP module
- CGI module
- gzip, tar, bz2 modules
The list continues (read more here [2]). I don't know how it is with
commercial Common Lisps, but what I've seen so far in open source
implementations doesn't seem to compare.
The point is: while I agree that CL is more powerful as a language
than Python, Python's standard library still makes it very attractive.
For bigger projects, the effort required to locate the right libraries
may be less of an issue, but for smaller stuff, chances are, if you
use Python, you'll just have to connect the dots. Or as Paul Graham
puts it in his essay "Being Popular" [3]:
Of course the ultimate in brevity is to have the program already
written for you, and merely to call it. And this brings us to what I
think will be an increasingly important feature of programming
languages: library functions. Perl wins because it has large
libraries for manipulating strings. This class of library functions
are especially important for throwaway programs, which are often
originally written for converting or extracting data. Many Perl
programs probably begin as just a couple library calls stuck
together.
I think a lot of the advances that happen in programming languages
in the next fifty years will have to do with library functions. I
think future programming languages will have libraries that are as
carefully designed as the core language. Programming language design
will not be about whether to make your language strongly or weakly
typed, or object oriented, or functional, or whatever, but about how
to design great libraries. The kind of language designers who like
to think about how to design type systems may shudder at this. It's
almost like writing applications! Too bad. Languages are for
programmers, and libraries are what programmers need.
Regards
Wolfram
Footnotes:
[1] <http://docs.python.org/dev/whatsnew/node15.html>
[2] <http://docs.python.org/lib/lib.html>
[3] <http://www.paulgraham.com/popular.html>
In article <··············@rpi.edu>, Bill Atkins <············@rpi.edu>
wrote:
> > Except it doesn't work:
>
> It doesn't work because the software isn't installed.
Yes, of course. But with Python you don't have this problem. Batteries
are included.
> It's no more
> than a coincidence that Python comes with a web server and that you
> want to use a web server.
No, it's by design. Lots of people want to write web servers nowadays,
so Python comes with code to support that.
> Imagine that instead you want to install
> database bindings (which I am assuming don't come with Python - if
> they do, we'll use the example of a GUI).
No collection of libraries is ever complete. The point is, Python comes
out of the box with enough stuff to do some useful things. Lisp doesn't
(unless you're doing AI research).
> This is a problem of public relations, not of technology, and just a
> plain silly argument.
Why? PR problems aren't problems?
> I could complain that as a newcomer to Python,
> the significant whitespace would be confusing.
People do complain about that, and it's one of the reasons that Python
loses people to Ruby.
> It would be unfair for me to claim this as a drawback to using Python
> because NEWCOMERS ARE ALWAYS CONFUSED UNTIL THEY LEARN WHAT THEY'RE
> DOING. This is almost not worth saying, but you seem to disagree.
Of course. There is nothing you can do in Lisp that you can't do in
assembler, so why bother to use Lisp? The whole point of having a high
level language is so that you don't have to know as much about what
you're doing to get useful work done.
rg
Ron Garret <·········@flownet.com> writes:
> In article <··············@rpi.edu>, Bill Atkins <············@rpi.edu>
> wrote:
>
>> > Except it doesn't work:
>>
>> It doesn't work because the software isn't installed.
>
> Yes, of course. But with Python you don't have this problem. Batteries
> are included.
>
>> It's no more
>> than a coincidence that Python comes with a web server and that you
>> want to use a web server.
>
> No, it's by design. Lots of people want to write web servers nowadays,
> so Python comes with code to support that.
What kind of a doofus programmer would write anything but toys using
the web server built into Python?
As Pascal mentions elsewhere, the fact that a library has been
committed to a language's distribution does not automatically make it
the best choice. LOOP, for example, is built into Common Lisp but few
would argue that its mere inclusion into Lisp makes it superior to
ITERATE.
>> Imagine that instead you want to install
>> database bindings (which I am assuming don't come with Python - if
>> they do, we'll use the example of a GUI).
>
> No collection of libraries is ever complete. The point is, Python comes
> out of the box with enough stuff to do some useful things. Lisp doesn't
> (unless you're doing AI research).
>
>
>> This is a problem of public relations, not of technology, and just a
>> plain silly argument.
>
> Why? PR problems aren't problems?
Sure they are. But they don't necessitate some kind of arbitrating
committee, just better tutorials.
>> I could complain that as a newcomer to Python,
>> the significant whitespace would be confusing.
>
> People do complain about that, and it's one of the reasons that Python
> loses people to Ruby.
My point, if it was unclear, was not that significant whitespace as a
concept is bad (although I personally feel that it is), but rather
that a newbie who was unaware that Python uses significant whitespace
would not get very useful information if he entered the code sample I
gave and that this would be an absurd reason to abandon Python -
i.e. because the user didn't bother to learn the language before
attempting to evaluate it.
>> It would be unfair for me to claim this as a drawback to using Python
>> because NEWCOMERS ARE ALWAYS CONFUSED UNTIL THEY LEARN WHAT THEY'RE
>> DOING. This is almost not worth saying, but you seem to disagree.
>
> Of course. There is nothing you can do in Lisp that you can't do in
> assembler, so why bother to use Lisp? The whole point of having a high
> level language is so that you don't have to know as much about what
> you're doing to get useful work done.
What's this in my mouth? Oh no, it's words! And they're not mine!
Your retort has nothing whatever to do with my point. I claim that a
newcomer's perspective on a language does not determine that
language's position on the continuum of absolute language goodness.
VB is very easy to pick up for newcomers, but it is nonetheless a
hideous language. Aiming a language at newcomers is foolish; only a
very small percentage of a language's users are newcomers at any given
time, and they are only newcomers for a very brief time. A better
approach is to make your language great for actual use and then wait
for good introductions (like PCL) to show up.
> rg
Bill Atkins <············@rpi.edu> writes:
> Ron Garret <·········@flownet.com> writes:
>
>> In article <··············@rpi.edu>, Bill Atkins <············@rpi.edu>
>> wrote:
>>
>>> It's no more
>>> than a coincidence that Python comes with a web server and that you
>>> want to use a web server.
>>
>> No, it's by design. Lots of people want to write web servers nowadays,
>> so Python comes with code to support that.
>
> What kind of a doofus programmer would write anything but toys using
> the web server built into Python?
... or the built-in regular expressions, Unicode strings, the XML
parser, the gettext module, the CGI module, ... . Either you have a
serious case of the not-invented-here-syndrome or you just don't want
to see the point. Standard libraries aren't just for "doofus
programmers."
> As Pascal mentions elsewhere, the fact that a library has been
> committed to a language's distribution does not automatically make
> it the best choice. LOOP, for example, is built into Common Lisp
> but few would argue that its mere inclusion into Lisp makes it
> superior to ITERATE.
If people don't like LOOP, they *can* just ignore it. But if they did
like it and it wasn't in the standard, they'd *have to* get it
somewhere else. It's all about options.
Wolfram
"Wolfram Fenske" <·····@gmx.net> writes:
> Bill Atkins <············@rpi.edu> writes:
>
>> Ron Garret <·········@flownet.com> writes:
>>
>>> In article <··············@rpi.edu>, Bill Atkins <············@rpi.edu>
>>> wrote:
>>>
>>>> It's no more
>>>> than a coincidence that Python comes with a web server and that you
>>>> want to use a web server.
>>>
>>> No, it's by design. Lots of people want to write web servers nowadays,
>>> so Python comes with code to support that.
>>
>> What kind of a doofus programmer would write anything but toys using
>> the web server built into Python?
>
> ... or the built-in regular expressions, Unicode strings, the XML
> parser, the gettext module, the CGI module, ... . Either you have a
> serious case of the not-invented-here-syndrome or you just don't want
> to see the point. Standard libraries aren't just for "doofus
> programmers."
Apples and oranges. All of the things you mention are indeed useful
as libraries. But running an application on a web server running on
an interpreted language is silly - unless you're writing a toy or
something meant for very limited use. I think you can agree with
that.
>> As Pascal mentions elsewhere, the fact that a library has been
>> committed to a language's distribution does not automatically make
>> it the best choice. LOOP, for example, is built into Common Lisp
>> but few would argue that its mere inclusion into Lisp makes it
>> superior to ITERATE.
>
> If people don't like LOOP, they *can* just ignore it. But if they did
> like it and it wasn't in the standard, they'd *have to* get it
> somewhere else. It's all about options.
>
>
> Wolfram
Bill Atkins <············@rpi.edu> writes:
> "Wolfram Fenske" <·····@gmx.net> writes:
>
>> Bill Atkins <············@rpi.edu> writes:
>>
>>> Ron Garret <·········@flownet.com> writes:
>>>
>>>> In article <··············@rpi.edu>, Bill Atkins <············@rpi.edu>
>>>> wrote:
>>>>
>>>>> It's no more
>>>>> than a coincidence that Python comes with a web server and that you
>>>>> want to use a web server.
>>>>
>>>> No, it's by design. Lots of people want to write web servers nowadays,
>>>> so Python comes with code to support that.
>>>
>>> What kind of a doofus programmer would write anything but toys using
>>> the web server built into Python?
>>
>> ... or the built-in regular expressions, Unicode strings, the XML
>> parser, the gettext module, the CGI module, ... . Either you have a
>> serious case of the not-invented-here-syndrome or you just don't want
>> to see the point. Standard libraries aren't just for "doofus
>> programmers."
>
> Apples and oranges.
True, they're not related to web servers, but my point was that all
these things come with Python, which I think is very useful.
> All of the things you mention are indeed useful as libraries. But
> running an application on a web server running on an interpreted
> language is silly - unless you're writing a toy or something meant
> for very limited use. I think you can agree with that.
In theory, I would agree. Yet, there is Plone [1], an open source
content management framework written purely in Python. It certainly
doesn't have the fastest web server ever known to mankind, but it's
still quite usable. Among others, the FSF uses it [2].
Another example would be Paul Graham's Viaweb software, which,
according to Wikipedia, was run on CLISP [3]. I probably shouldn't
have mentioned that one as it proves that one can get insanely rich
without having all those neat libraries that Python has ;-). But I
still think it's very convenient to have all this stuff onboard.
Wolfram
Footnotes:
[1] <http://plone.org/>
[2] <http://www.fsf.org/>
[3] <http://en.wikipedia.org/wiki/CLISP>
To be exact, it doesn't specifically say that the web server was
running on CLISP, too. Maybe only the backend was running on
CLISP.
Wolfram Fenske <·····@gmx.net> wrote:
> Another example would be Paul Graham's Viaweb software, which,
> according to Wikipedia, was run on CLISP [3]. I probably shouldn't
And edited with VIM, by the way.
Stefan Scholl <······@no-spoon.de> writes:
> Wolfram Fenske <·····@gmx.net> wrote:
>> Another example would be Paul Graham's Viaweb software, which,
>> according to Wikipedia, was run on CLISP [3]. I probably shouldn't
>
> And edited with VIM, by the way.
Yeah, just read that yesterday [1]. Didn't see *that* coming ...
Regards
Wolfram
Footnotes:
[1] <http://reddit.com/info/21918/comments#c2315>
In article <··············@rpi.edu>, Bill Atkins <············@rpi.edu> wrote:
> Apples and oranges. All of the things you mention are indeed useful
> as libraries. But running an application on a web server running on
> an interpreted language is silly - unless you're writing a toy or
> something meant for very limited use. I think you can agree with
> that.
I don't; I think you've got the wrong intuition about the balance
between the amount of bandwidth and the amount of computation a given
numer of dollars would buy. You've hundreds of CPU cycles available
per bit transmitted; space enough to stick in even Python.
Tom
In article <··············@rpi.edu>, Bill Atkins <············@rpi.edu>
wrote:
> Ron Garret <·········@flownet.com> writes:
>
> > In article <··············@rpi.edu>, Bill Atkins <············@rpi.edu>
> > wrote:
> >
> >> > Except it doesn't work:
> >>
> >> It doesn't work because the software isn't installed.
> >
> > Yes, of course. But with Python you don't have this problem. Batteries
> > are included.
> >
> >> It's no more
> >> than a coincidence that Python comes with a web server and that you
> >> want to use a web server.
> >
> > No, it's by design. Lots of people want to write web servers nowadays,
> > so Python comes with code to support that.
>
> What kind of a doofus programmer would write anything but toys using
> the web server built into Python?
What difference does that make?
> As Pascal mentions elsewhere, the fact that a library has been
> committed to a language's distribution does not automatically make it
> the best choice. LOOP, for example, is built into Common Lisp but few
> would argue that its mere inclusion into Lisp makes it superior to
> ITERATE.
Please stop making straw-man arguments. No one ever said that the
libraries built into Python are the best, or even that that they are
good, only that they exist. (In fact, most of the built-in libraries
are quite good because a lot of people use them, and so there is a lot
of incentive for people to improve them.)
> >> Imagine that instead you want to install
> >> database bindings (which I am assuming don't come with Python - if
> >> they do, we'll use the example of a GUI).
> >
> > No collection of libraries is ever complete. The point is, Python comes
> > out of the box with enough stuff to do some useful things. Lisp doesn't
> > (unless you're doing AI research).
> >
> >
> >> This is a problem of public relations, not of technology, and just a
> >> plain silly argument.
> >
> > Why? PR problems aren't problems?
>
> Sure they are. But they don't necessitate some kind of arbitrating
> committee, just better tutorials.
Quite true, but the current Balkanization of Lisp makes "better
tutorials" very hard to write. That is the reason that there is to my
knowledge no tutorial that would help a newcomer past the particular
problem that I cited.
By way of contrast, in Python everything is standardized, even the
methodology for installing new libraries (via distutils) so Python
tutorials can include complete step-by-step instructions that Just Work.
This is a direct consequence of the fact that Python has a process for
managing ongoing change.
> >> I could complain that as a newcomer to Python,
> >> the significant whitespace would be confusing.
> >
> > People do complain about that, and it's one of the reasons that Python
> > loses people to Ruby.
>
> My point, if it was unclear, was not that significant whitespace as a
> concept is bad (although I personally feel that it is),
I agree FWIW.
> but rather
> that a newbie who was unaware that Python uses significant whitespace
> would not get very useful information if he entered the code sample I
> gave and that this would be an absurd reason to abandon Python -
> i.e. because the user didn't bother to learn the language before
> attempting to evaluate it.
I disagree. I think that would be a fine reason to abandon Python and
seek out a language that has all of the features that Python has but
without the brain damaged syntax. Like Ruby.
> >> It would be unfair for me to claim this as a drawback to using Python
> >> because NEWCOMERS ARE ALWAYS CONFUSED UNTIL THEY LEARN WHAT THEY'RE
> >> DOING. This is almost not worth saying, but you seem to disagree.
> >
> > Of course. There is nothing you can do in Lisp that you can't do in
> > assembler, so why bother to use Lisp? The whole point of having a high
> > level language is so that you don't have to know as much about what
> > you're doing to get useful work done.
>
> What's this in my mouth? Oh no, it's words! And they're not mine!
OK, try this:
C++ newbie: "I'm trying to learn C++ and I'm horribly confused. It seems
to me that C++ has a lot of gratuitous complexity."
C++ guru: "Don't worry, NEWCOMERS ARE ALWAYS CONFUSED UNTIL THEY LEARN
WHAT THEY'RE DOING. The fact that you are having problems is
in no way a negative reflection on the language."
> Your retort has nothing whatever to do with my point. I claim that a
> newcomer's perspective on a language does not determine that
> language's position on the continuum of absolute language goodness.
>
> VB is very easy to pick up for newcomers, but it is nonetheless a
> hideous language.
With a very large user base despite the fact that it is a hideous
language.
> Aiming a language at newcomers is foolish;
Now you're putting words in my mouth. I never said CL should be aimed
at newcomers. I said it would benefit from being made more accessible
to newcomers. These are not the same thing.
> only a
> very small percentage of a language's users are newcomers at any given
> time,
That is only true if the user base is not growing rapidly.
> and they are only newcomers for a very brief time. A better
> approach is to make your language great for actual use and then wait
> for good introductions (like PCL) to show up.
With all respect to Peter Seibel, the negative effects of Lisp's
Balkanization can be seen even in PCL. For example, there is no mention
of how to interface to a real database. (The database in chapter 3 is,
at best, a toy. I chose this example because you attached some
importance to that sort of thing earlier.) I don't know if that was an
intentional omission or not, but it would be very difficult to write a
comprehensive tutorial on interfacing CL to a relational database given
the current state of things.
I'll also note in passing the existence of:
http://www.awaretek.com/tutorials.html
rg
Ron Garret <·········@flownet.com> writes:
> In article <··············@rpi.edu>, Bill Atkins <············@rpi.edu>
> wrote:
>
>> Ron Garret <·········@flownet.com> writes:
>>
>> > In article <··············@rpi.edu>, Bill Atkins <············@rpi.edu>
>> > wrote:
>> >
>> >> > Except it doesn't work:
>> >>
>> >> It doesn't work because the software isn't installed.
>> >
>> > Yes, of course. But with Python you don't have this problem. Batteries
>> > are included.
>> >
>> >> It's no more
>> >> than a coincidence that Python comes with a web server and that you
>> >> want to use a web server.
>> >
>> > No, it's by design. Lots of people want to write web servers nowadays,
>> > so Python comes with code to support that.
>>
>> What kind of a doofus programmer would write anything but toys using
>> the web server built into Python?
>
> What difference does that make?
Because in real life, a programmer would have to examine several
different web servers, several different web server-Python bridges and
pick the one that meets his needs.
>> As Pascal mentions elsewhere, the fact that a library has been
>> committed to a language's distribution does not automatically make it
>> the best choice. LOOP, for example, is built into Common Lisp but few
>> would argue that its mere inclusion into Lisp makes it superior to
>> ITERATE.
>
> Please stop making straw-man arguments. No one ever said that the
> libraries built into Python are the best, or even that that they are
> good, only that they exist. (In fact, most of the built-in libraries
Fair enough. My point is only that having a library built into the
language does not sidestep the issue of having to evaluate different
implementations of roughly the same functionality.
> are quite good because a lot of people use them, and so there is a lot
> of incentive for people to improve them.)
>
>> >> Imagine that instead you want to install
>> >> database bindings (which I am assuming don't come with Python - if
>> >> they do, we'll use the example of a GUI).
>> >
>> > No collection of libraries is ever complete. The point is, Python comes
>> > out of the box with enough stuff to do some useful things. Lisp doesn't
>> > (unless you're doing AI research).
>> >
>> >
>> >> This is a problem of public relations, not of technology, and just a
>> >> plain silly argument.
>> >
>> > Why? PR problems aren't problems?
>>
>> Sure they are. But they don't necessitate some kind of arbitrating
>> committee, just better tutorials.
>
> Quite true, but the current Balkanization of Lisp makes "better
> tutorials" very hard to write. That is the reason that there is to my
> knowledge no tutorial that would help a newcomer past the particular
> problem that I cited.
>
> By way of contrast, in Python everything is standardized, even the
> methodology for installing new libraries (via distutils) so Python
> tutorials can include complete step-by-step instructions that Just Work.
> This is a direct consequence of the fact that Python has a process for
> managing ongoing change.
But it's merely an accident of history that Python can do this kind of
thing. Suppose Python had forked in the past and evolved into a
couple different implementations that were very different in serious
ways (commercial vs. free, interpreted vs. native-compiled, etc.).
Would you dismiss Python because of the forking it underwent? This is
not a rhetorical question. Would you consider Python less valuable
because there were divergent implementations of it? If so, what good
would Python's process for change be?
>> >> I could complain that as a newcomer to Python,
>> >> the significant whitespace would be confusing.
>> >
>> > People do complain about that, and it's one of the reasons that Python
>> > loses people to Ruby.
>>
>> My point, if it was unclear, was not that significant whitespace as a
>> concept is bad (although I personally feel that it is),
>
> I agree FWIW.
>
>> but rather
>> that a newbie who was unaware that Python uses significant whitespace
>> would not get very useful information if he entered the code sample I
>> gave and that this would be an absurd reason to abandon Python -
>> i.e. because the user didn't bother to learn the language before
>> attempting to evaluate it.
>
> I disagree. I think that would be a fine reason to abandon Python and
> seek out a language that has all of the features that Python has but
> without the brain damaged syntax. Like Ruby.
>
>> >> It would be unfair for me to claim this as a drawback to using Python
>> >> because NEWCOMERS ARE ALWAYS CONFUSED UNTIL THEY LEARN WHAT THEY'RE
>> >> DOING. This is almost not worth saying, but you seem to disagree.
>> >
>> > Of course. There is nothing you can do in Lisp that you can't do in
>> > assembler, so why bother to use Lisp? The whole point of having a high
>> > level language is so that you don't have to know as much about what
>> > you're doing to get useful work done.
>>
>> What's this in my mouth? Oh no, it's words! And they're not mine!
>
> OK, try this:
>
> C++ newbie: "I'm trying to learn C++ and I'm horribly confused. It seems
> to me that C++ has a lot of gratuitous complexity."
> C++ guru: "Don't worry, NEWCOMERS ARE ALWAYS CONFUSED UNTIL THEY LEARN
> WHAT THEY'RE DOING. The fact that you are having problems is
> in no way a negative reflection on the language."
The difference is that the newbie's complaint still applies after
becoming a guru. Ha ha, only serious.
>> Your retort has nothing whatever to do with my point. I claim that a
>> newcomer's perspective on a language does not determine that
>> language's position on the continuum of absolute language goodness.
>>
>> VB is very easy to pick up for newcomers, but it is nonetheless a
>> hideous language.
>
> With a very large user base despite the fact that it is a hideous
> language.
>
>> Aiming a language at newcomers is foolish;
>
> Now you're putting words in my mouth. I never said CL should be aimed
> at newcomers. I said it would benefit from being made more accessible
> to newcomers. These are not the same thing.
>
>> only a
>> very small percentage of a language's users are newcomers at any given
>> time,
>
> That is only true if the user base is not growing rapidly.
>
>> and they are only newcomers for a very brief time. A better
>> approach is to make your language great for actual use and then wait
>> for good introductions (like PCL) to show up.
>
> With all respect to Peter Seibel, the negative effects of Lisp's
> Balkanization can be seen even in PCL. For example, there is no mention
> of how to interface to a real database. (The database in chapter 3 is,
> at best, a toy. I chose this example because you attached some
> importance to that sort of thing earlier.) I don't know if that was an
> intentional omission or not, but it would be very difficult to write a
> comprehensive tutorial on interfacing CL to a relational database given
> the current state of things.
Why would it be hard? CLSQL runs on nearly every modern Lisp
implementation (except CLISP?). Assuming ASDF had been covered
earlier, there's no reason this should be especially hard to write.
> I'll also note in passing the existence of:
> http://www.awaretek.com/tutorials.html
>
> rg
In article <··············@rpi.edu>, Bill Atkins <············@rpi.edu>
wrote:
> >> What kind of a doofus programmer would write anything but toys using
> >> the web server built into Python?
> >
> > What difference does that make?
>
> Because in real life, a programmer would have to examine several
> different web servers, several different web server-Python bridges and
> pick the one that meets his needs.
Only if the built-in one didn't meet their needs.
> >> As Pascal mentions elsewhere, the fact that a library has been
> >> committed to a language's distribution does not automatically make it
> >> the best choice. LOOP, for example, is built into Common Lisp but few
> >> would argue that its mere inclusion into Lisp makes it superior to
> >> ITERATE.
> >
> > Please stop making straw-man arguments. No one ever said that the
> > libraries built into Python are the best, or even that that they are
> > good, only that they exist. (In fact, most of the built-in libraries
>
> Fair enough. My point is only that having a library built into the
> language does not sidestep the issue of having to evaluate different
> implementations of roughly the same functionality.
Sure it does, if the built-in one meets their needs.
> > are quite good because a lot of people use them, and so there is a lot
> > of incentive for people to improve them.)
> >
> >> >> Imagine that instead you want to install
> >> >> database bindings (which I am assuming don't come with Python - if
> >> >> they do, we'll use the example of a GUI).
> >> >
> >> > No collection of libraries is ever complete. The point is, Python comes
> >> > out of the box with enough stuff to do some useful things. Lisp doesn't
> >> > (unless you're doing AI research).
> >> >
> >> >
> >> >> This is a problem of public relations, not of technology, and just a
> >> >> plain silly argument.
> >> >
> >> > Why? PR problems aren't problems?
> >>
> >> Sure they are. But they don't necessitate some kind of arbitrating
> >> committee, just better tutorials.
> >
> > Quite true, but the current Balkanization of Lisp makes "better
> > tutorials" very hard to write. That is the reason that there is to my
> > knowledge no tutorial that would help a newcomer past the particular
> > problem that I cited.
> >
> > By way of contrast, in Python everything is standardized, even the
> > methodology for installing new libraries (via distutils) so Python
> > tutorials can include complete step-by-step instructions that Just Work.
> > This is a direct consequence of the fact that Python has a process for
> > managing ongoing change.
>
> But it's merely an accident of history that Python can do this kind of
> thing.
No it's not, it's a result of deliberate design.
> Suppose Python had forked in the past and evolved into a
> couple different implementations that were very different in serious
> ways (commercial vs. free, interpreted vs. native-compiled, etc.).
> Would you dismiss Python because of the forking it underwent?
I don't know. It depends on how well the different versions were
managed.
> This is not a rhetorical question.
I didn't think it was rhetorical. It is, however, mostly hypothetical.
(It's only mostly hypothetical because Python does have at least one
significant fork: stackless Python. But no one uses it, so it can be
safely ignored.)
(Actually, a better example is Linux, which does have significant
divergence, and this is actually causing the Linux community a certain
amount of pain. But again, they do have a process for managing change
in the kernel, which is their equivalent of the core language, and that
helps a lot.)
> > With all respect to Peter Seibel, the negative effects of Lisp's
> > Balkanization can be seen even in PCL. For example, there is no mention
> > of how to interface to a real database. (The database in chapter 3 is,
> > at best, a toy. I chose this example because you attached some
> > importance to that sort of thing earlier.) I don't know if that was an
> > intentional omission or not, but it would be very difficult to write a
> > comprehensive tutorial on interfacing CL to a relational database given
> > the current state of things.
>
> Why would it be hard? CLSQL runs on nearly every modern Lisp
> implementation (except CLISP?). Assuming ASDF had been covered
> earlier, there's no reason this should be especially hard to write.
Not working with CLisp is significant IMO. A lot of people use CLisp.
It also doesn't work with MCL. And it doesn't work with Corman Lisp.
rg
Ron Garret <·········@flownet.com> writes:
>> Why would it be hard? CLSQL runs on nearly every modern Lisp
>> implementation (except CLISP?). Assuming ASDF had been covered
>> earlier, there's no reason this should be especially hard to write.
>
> Not working with CLisp is significant IMO. A lot of people use CLisp.
> It also doesn't work with MCL. And it doesn't work with Corman Lisp.
CLSQL works (fsvo workingness) with CLISP. See an example:
http://lists.b9.com/pipermail/clsql-devel/2006-April/000556.html
Nobody has yet bothered to send the *very* trivial patch to make it work
out of the box. If you, or anyone else, thinks CLSQL's CLISP support is
significant, you should send that trivial patch.
Have you ever *used* Corman Lisp? It'll probably work with that trivial
patch except I suspect nobody has ever tried to run CLSQL with Corman
Lisp.
MCL is dead, doesn't provide a _decent_ demo/trial to work with and
refuses to provide documentation for people who are interested in
porting stuff like CLSQL to it. Dead.
--
Luís Oliveira
luismbo (@) gmail (.) com
Equipa Portuguesa do Translation Project
http://www.iro.umontreal.ca/translation/registry.cgi?team=pt
"Marko Kocic" <···········@gmail.com> writes:
> On http://cliki.net/clsql I adde info how to run clsql in clisp
Certainly you don't expect CLSQL's maintainer to regularly check that
page for patches do you?
--
Luís Oliveira
luismbo (@) gmail (.) com
Equipa Portuguesa do Translation Project
http://www.iro.umontreal.ca/translation/registry.cgi?team=pt
Not, but since someon asked how to use clsql and clisp ;)
Btw, mail with posting a patch to clsql mailing list was rejected
because I was not subscribed to that list (and didn't want to just to
send a small and simple patch).
As a side note, maintainers of major libs _should_ check cliki pages
that are mentioning their projects just because of the fact that if one
is looking for info on some library (how to get it, does it work with
implementation x, where is the source, simple examples, etc) it is most
likely to be http://cliki.net/library-name. And based on what's there,
one (ok, me) could even decide is it worth further looking at.
Ron Garret wrote:
> In article <··············@deadspam.com>,
> ·············@deadspam.com (Luís Oliveira) wrote:
>
> > MCL is dead,
>
> Is he right? Is MCL dead?
>
Shot tragically by an enraged thief in downtown LA while
running errands for the wife. When a criminal demanded
the car, M.C. passed him '1-pickup dry cleaning.' :-)
Seriously, it's hard to tell because Digitool updates their
web pages once every 16 or so blue moons.
--
Geoff
Ron Garret <·········@flownet.com> writes:
> In article <··············@deadspam.com>,
> ·············@deadspam.com (Luís Oliveira) wrote:
>
> > MCL is dead,
>
> Is he right? Is MCL dead?
Not entirely, but we recently had a bit of difficulty reaching them so
that we could order upgrades and a site license. I'm not sure what the
actual viability of Digitool is. Certainly the switch to Intel is
causing a hiccup for MCL and OpenMCL.
OpenMCL, by the way, works just fine with CLSQL. MCL 5.0 does not have
some of the MOP features (I think it was the MOP) needed to work with
CLSQL.
--
Thomas A. Russ, USC/Information Sciences Institute
> OpenMCL, by the way, works just fine with CLSQL. MCL 5.0 does not have
> some of the MOP features (I think it was the MOP) needed to work with
> CLSQL.
MCL 5.1 supports MOP. It is alive.
In article <·····················@192.168.1.2>,
····@gol.com (Takehiko Abe) wrote:
> > OpenMCL, by the way, works just fine with CLSQL. MCL 5.0 does not have
> > some of the MOP features (I think it was the MOP) needed to work with
> > CLSQL.
>
> MCL 5.1 supports MOP. It is alive.
I think there is even a 5.2 beta ...
--
http://lispm.dyndns.org/
Ron Garret wrote:
> In article <··············@deadspam.com>,
> ·············@deadspam.com (Luís Oliveira) wrote:
>
>> MCL is dead,
>
> Is he right? Is MCL dead?
No. It just smells funny. ;)
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
Ron Garret <·········@flownet.com> writes:
> ·············@deadspam.com (Luis Oliveira) wrote:
>> MCL is dead,
>
> Is he right? Is MCL dead?
Like I said, the way I see it, if MCL doesn't offer a usable demo/trial
or documentation for library developers to work with it's either dead or
waiting to die.
OpenMCL, on the other hand, is alive and well.
--
Luís Oliveira
luismbo (@) gmail (.) com
Equipa Portuguesa do Translation Project
http://www.iro.umontreal.ca/translation/registry.cgi?team=pt
·············@deadspam.com (Luís Oliveira) writes:
> Like I said, the way I see it, if MCL doesn't offer a usable demo/trial
> or documentation for library developers to work with it's either dead or
> waiting to die.
But there is a demo version of MCL 5.1 available from the Digitool
website:
http://www.digitool.com/download.html
or directly from
ftp://ftp.digitool.com/mcl/demos/MCL-5.1-Demo.dmg.bin
Anyway, we finally did get our order in, so I should be getting the 5.1
release sometime soon.
--
Thomas A. Russ, USC/Information Sciences Institute
···@sevak.isi.edu (Thomas A. Russ) writes:
> ·············@deadspam.com (Luis Oliveira) writes:
>> Like I said, the way I see it, if MCL doesn't offer a usable demo/trial
>> or documentation for library developers to work with it's either dead or
>> waiting to die.
>
> But there is a demo version of MCL 5.1 available from the Digitool
> website:
Sure, but it's not very usable is it? You can only use it 15 minutes at
a time (though, to be fair, you can mail them and ask for a password
that'll give you unlimited use until the end of the month). And again,
it doesn't have any documentation.
--
Luís Oliveira
luismbo (@) gmail (.) com
Equipa Portuguesa do Translation Project
http://www.iro.umontreal.ca/translation/registry.cgi?team=pt
Some entity AKA Ron Garret <·········@flownet.com>
wrote this mindboggling stuff:
(selectively-snipped-or-not-p)
>
> With all respect to Peter Seibel, the negative effects of Lisp's
> Balkanization can be seen even in PCL. For example, there is no mention
> of how to interface to a real database.
Please, O Great Guru and allknowing Entity, enlighten this unworthy
humble peasant as to what an unreal database is.
To which Devine purpose does Thou, Great Lord an Master of this
Eternal Databasical Heaven in thou Univers, whises to cast His
mighty wrath upon the humble newbie.
We, the simple ignorants of the mortal realm do not posess
the allmighty knowledge and awareness alike Thou Birth included.
Alas, Great Lord, Devine Allknowing Entity, tho that we are condemned
to learn by simple steps to come to any light at all.
For She, who knows the last word will inherit the earth.
Cor
--
I do NOT use any Windows(TM) products, therefore
I do NOT fear mail from strangers http://www.clsnet.nl/mail.html
If everything else failed to satisfy you, try reading The Frign' Manual
(defvar My-Computer '((OS . "GNU/Emacs") (IPL . "GNU/Linux")))
In article <··············@atthis.clsnet.nl>, Cor Gest <···@clsnet.nl>
wrote:
> Some entity AKA Ron Garret <·········@flownet.com>
> wrote this mindboggling stuff:
>
> (selectively-snipped-or-not-p)
> >
> > With all respect to Peter Seibel, the negative effects of Lisp's
> > Balkanization can be seen even in PCL. For example, there is no mention
> > of how to interface to a real database.
>
> Please, O Great Guru and allknowing Entity, enlighten this unworthy
> humble peasant as to what an unreal database is.
It's one where everything is stored in memory instead of on disk.
The reason this is not a real database is that storing everything in
memory sidesteps all the hard problems of database design.
rg
Some entity AKA Ron Garret <·········@flownet.com>
wrote this mindboggling stuff:
(selectively-snipped-or-not-p)
> > Please, O Great Guru and allknowing Entity, enlighten this unworthy
> > humble peasant as to what an unreal database is.
>
> It's one where everything is stored in memory instead of on disk.
>
> The reason this is not a real database is that storing everything in
> memory sidesteps all the hard problems of database design.
My my, You're saying that these datathingies are just like
people, are you now ?
Like, the real simple ones who resort to fingers and those more
educated who take to calculus to count their blessings.
So, one ought to be tought quantummechanics and relativity instead
of that simple newtonian stuff, ... in kindergarten.
Cor
--
I do NOT use any Windows(TM) products, therefore
I do NOT fear mail from strangers http://www.clsnet.nl/mail.html
If everything else failed to satisfy you, try reading The Frign' Manual
(defvar My-Computer '((OS . "GNU/Emacs") (IPL . "GNU/Linux")))
In article <··············@atthis.clsnet.nl>, Cor Gest <···@clsnet.nl>
wrote:
> Some entity AKA Ron Garret <·········@flownet.com>
> wrote this mindboggling stuff:
>
> (selectively-snipped-or-not-p)
>
> > > Please, O Great Guru and allknowing Entity, enlighten this unworthy
> > > humble peasant as to what an unreal database is.
> >
> > It's one where everything is stored in memory instead of on disk.
> >
> > The reason this is not a real database is that storing everything in
> > memory sidesteps all the hard problems of database design.
>
> My my, You're saying that these datathingies are just like
> people, are you now ?
> Like, the real simple ones who resort to fingers and those more
> educated who take to calculus to count their blessings.
> So, one ought to be tought quantummechanics and relativity instead
> of that simple newtonian stuff, ... in kindergarten.
No, but if you're claiming to teach people "practical" things I think
it's better to teach them to, for example, use one of these:
http://shorterlink.com/?F3NKMK
instead of how to tie two cans together with a piece of string. Modern
data bases have very easily learned user interfaces that hide much of
the underlying complexity.
And that will be the last time I respond to you unless you drop the
condescending tone (and learn to spell).
rg
Some entity AKA Ron Garret <·········@flownet.com>
wrote this mindboggling stuff:
(selectively-snipped-or-not-p)
> > So, one ought to be tought quantummechanics and relativity instead
> > of that simple newtonian stuff, ... in kindergarten.
>
> No, but if you're claiming to teach people "practical" things I think
> it's better to teach them to, for example, use one of these:
>
> http://shorterlink.com/?F3NKMK
>
> instead of how to tie two cans together with a piece of string.
That is just your explanation to the context of "practical".
That chappter was _not_ how to learn how to develop databasesystems,
but merely to show a newbie how to muck about with to those dreaded
parenthesis in a somewhat more familiar context.
Just like I learned the kids to warn-off once and then kick straight
and hard into the balls.
I definitely claim that to be very "practical", and they surely would
use that can-contraption as a bola and aim for the neck.
Oh, by the way, english is merely a 4th lingo here and since any
native will beat me to a pulitzer anyway you'll just have to endure.
so, stop that petty attitude, it is not becomming.
Cor
--
I do NOT use any Windows(TM) products, therefore
I do NOT fear mail from strangers http://www.clsnet.nl/mail.html
If everything else failed to satisfy you, try reading The Frign' Manual
(defvar My-Computer '((OS . "GNU/Emacs") (IPL . "GNU/Linux")))
Ron Garret <·········@flownet.com> writes:
> With all respect to Peter Seibel, the negative effects of Lisp's
> Balkanization can be seen even in PCL. For example, there is no
> mention of how to interface to a real database. (The database in
> chapter 3 is, at best, a toy. I chose this example because you
> attached some importance to that sort of thing earlier.) I don't
> know if that was an intentional omission or not, but it would be
> very difficult to write a comprehensive tutorial on interfacing CL
> to a relational database given the current state of things.
As it turns out, connecting to an RDBMS was something that was
definitely on the list and got cut because I ran out of time and
space. I can't say for sure, since I never really started working on
it, but I don't think it would have been too bad. I probably would
have written about CLSQL which appears to run on all the major
implementations except for CLISP and can connect to a half-dozen
different RDMBSes.
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
With debian i can do:
$ sudo apt-get install python
$ python
>>> import SimpleHTTPServer
>>> SimpleHTTPServer.test()
Serving HTTP on 0.0.0.0 port 8000 ...
Trying the same with clisp:
$ sudo apt-get install clisp
$ clisp
[1]> (require :araneida)
*** - LOAD: A file with name araneida does not exist
Break 1 [2]> ^D
[3]> (asdf:oos 'asdf:load-op :araneida)
*** - Condition of type ASDF:MISSING-COMPONENT.
$ apt-cache search araneida
nothing found
This is Pythons "everything and the kitchen sink" style, which seems to
be quite successful. This is newbie-friendly, because they get
something working to play with quickly.
So what, you only proved that Debian is missing the sewer of the
kitchensink
Cor
--
I do NOT use any Windows(TM) products, therefore
I do NOT fear mail from strangers http://www.clsnet.nl/mail.html
If everything else failed to satisfy you, try reading The Frign' Manual
(defvar My-Computer '((OS . "GNU/Emacs") (IPL . "GNU/Linux")))
"beza1e1" <···············@googlemail.com> writes:
> With debian i can do:
> $ sudo apt-get install python
> $ python
>>>> import SimpleHTTPServer
>>>> SimpleHTTPServer.test()
> Serving HTTP on 0.0.0.0 port 8000 ...
>
> Trying the same with clisp:
>
> $ sudo apt-get install clisp
> $ clisp
> [1]> (require :araneida)
> *** - LOAD: A file with name araneida does not exist
> Break 1 [2]> ^D
> [3]> (asdf:oos 'asdf:load-op :araneida)
> *** - Condition of type ASDF:MISSING-COMPONENT.
>
> $ apt-cache search araneida
> nothing found
>
> This is Pythons "everything and the kitchen sink" style, which seems to
> be quite successful. This is newbie-friendly, because they get
> something working to play with quickly.
You've got the wrong distribution.
Or you just need to do some custom configuration or instalation, it's
not hard, just run:
(asdf-install:install :araneida)
before:
(asdf:oos 'asdf:load-op :araneida)
;; Loading file /home/pjb/.clisprc.lisp ...
;; Reading ASDF packages from /home/pjb/asdf-central-registry.data...
; loading system definition from /usr/local/share/lisp/packages/net/sourceforge/cclan/asdf-install/asdf-install.asd into #<PACKAGE ASDF4250>
; registering #<SYSTEM ASDF-INSTALL #x204E116E> as ASDF-INSTALL
0 errors, 0 warnings
[1]> (asdf:oos 'asdf:load-op :trivial-http)
; loading system definition from /usr/local/asdf-install/site-systems/trivial-http.asd into #<PACKAGE ASDF5168>
;;; ...
;; Loaded file /local/asdf-install/site/trivial-http-1.1/OBJ-CLISP-238-I686/trivial-http.fas
0 errors, 0 warnings
NIL
[2]> (trivial-http:http-get "http://www.informatimago.com/develop/lisp/")
(200
((:DATE . "Wed, 19 Apr 2006 22:17:30 GMT")
(:SERVER . "Apache/1.3.20 (Linux/SuSE)")
(:LAST-MODIFIED . "Sun, 18 Dec 2005 16:56:46 GMT")
(:ETAG . "\"1c859-5099-43a594ce\"") (:ACCEPT-RANGES . "bytes")
(:CONTENT-LENGTH . "20633") (:CONNECTION . "close")
(:CONTENT-TYPE . "text/html"))
#<IO UNBUFFERED SOCKET-STREAM CHARACTER www.informatimago.com:80>)
[3]> (read-line (third *))
"<!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.01 Strict//EN\" \"http://www.w3.org/TR/html4/strict.dtd\">" ;
NIL
[4]>
--
__Pascal Bourguignon__ http://www.informatimago.com/
This is a signature virus. Add me to your signature and help me to live.
In article <··············@thalassa.informatimago.com>,
Pascal Bourguignon <···@informatimago.com> wrote:
> "beza1e1" <···············@googlemail.com> writes:
>
> > With debian i can do:
> > $ sudo apt-get install python
> > $ python
> >>>> import SimpleHTTPServer
> >>>> SimpleHTTPServer.test()
> > Serving HTTP on 0.0.0.0 port 8000 ...
> >
> > Trying the same with clisp:
> >
> > $ sudo apt-get install clisp
> > $ clisp
> > [1]> (require :araneida)
> > *** - LOAD: A file with name araneida does not exist
> > Break 1 [2]> ^D
> > [3]> (asdf:oos 'asdf:load-op :araneida)
> > *** - Condition of type ASDF:MISSING-COMPONENT.
> >
> > $ apt-cache search araneida
> > nothing found
> >
> > This is Pythons "everything and the kitchen sink" style, which seems to
> > be quite successful. This is newbie-friendly, because they get
> > something working to play with quickly.
>
> You've got the wrong distribution.
But that is precisely the point. It takes a lot less effort to find the
"right" Python distribution than the "right" Lisp distribution.
rg
Ron Garret wrote:
> In article <··············@thalassa.informatimago.com>,
> Pascal Bourguignon <···@informatimago.com> wrote:
>
> > "beza1e1" <···············@googlemail.com> writes:
> >
> > > With debian i can do:
> > > $ sudo apt-get install python
> > > $ python
> > >>>> import SimpleHTTPServer
> > >>>> SimpleHTTPServer.test()
> > > Serving HTTP on 0.0.0.0 port 8000 ...
> > >
> > > Trying the same with clisp:
> > >
> > > $ sudo apt-get install clisp
> > > $ clisp
> > > [1]> (require :araneida)
> > > *** - LOAD: A file with name araneida does not exist
> > > Break 1 [2]> ^D
> > > [3]> (asdf:oos 'asdf:load-op :araneida)
> > > *** - Condition of type ASDF:MISSING-COMPONENT.
> > >
> > > $ apt-cache search araneida
> > > nothing found
> > >
> > > This is Pythons "everything and the kitchen sink" style, which seems to
> > > be quite successful. This is newbie-friendly, because they get
> > > something working to play with quickly.
> >
> > You've got the wrong distribution.
>
> But that is precisely the point. It takes a lot less effort to find the
> "right" Python distribution than the "right" Lisp distribution.
>
> rg
If you're spending weeks/months/years on a project does it matter if it
takes you all day as opposed to 10 minutes to install your development
tools.
IMHO just because something takes a while to learn or set up does not
exclude it from professional users, it only excludes it from casual
users or those without technical skills.
That's not to say that we shouldn't keep working on making lisp easy to
find, easy to add libraries to etc, but the difficulties are not a nail
in the coffin for a language when it comes to professional long term
use.
Justin
In article <························@t31g2000cwb.googlegroups.com>,
"justinhj" <········@gmail.com> wrote:
> If you're spending weeks/months/years on a project does it matter if it
> takes you all day as opposed to 10 minutes to install your development
> tools.
>
> IMHO just because something takes a while to learn or set up does not
> exclude it from professional users, it only excludes it from casual
> users or those without technical skills.
So why not use C++?
> That's not to say that we shouldn't keep working on making lisp easy to
> find, easy to add libraries to etc, but the difficulties are not a nail
> in the coffin for a language when it comes to professional long term
> use.
I'm not sure what you mean by "a nail in the coffin." Inaccessibility
will not outright kill Lisp, but it will reduce the number of new users,
which shrinks the Lisp economy, which is a bad thing IMO.
Try this experiment: type "python programmer" into Google and look at
the ads. Now do the same with "java programmer."
Now try "Cobol programmer."
Finally, try "Lisp programmer."
rg
Ron Garret wrote:
> In article <························@t31g2000cwb.googlegroups.com>,
> "justinhj" <········@gmail.com> wrote:
> > IMHO just because something takes a while to learn or set up does not
> > exclude it from professional users, it only excludes it from casual
> > users or those without technical skills.
>
> So why not use C++?
Professionally I do, but only because in my industry there is little
choice.
But to answer your question from the point of view of someone who is
not forced to use C++ , I'd love to work in lisp all the time because I
enjoy programming with it and I am more productive.
> > That's not to say that we shouldn't keep working on making lisp easy to
> > find, easy to add libraries to etc, but the difficulties are not a nail
> > in the coffin for a language when it comes to professional long term
> > use.
>
> I'm not sure what you mean by "a nail in the coffin." Inaccessibility
> will not outright kill Lisp, but it will reduce the number of new users,
> which shrinks the Lisp economy, which is a bad thing IMO.
I meant by that "inaccessiblity" in terms of how long it takes to be
useful in the language should not be considered a bad thing for
professional users that will be spending many years with their language
of choice. We should not abandon common lisp simply because it's too
hard for a lot of people to learn.
The fact that many programmers prefer python and ruby over java and c++
still does not make python or ruby a better language to use for many
applications.
I keep thinking of Neil Stephenson's essay on a powerful drill vs
weaker safer consumer drills:
http://www.team.net/mjb/hawg.html
He's using his drill analogy to explain how the linux command line
(powerful and sophisticated) compares to a typical gui (simple and less
powerful).
So what if it takes a while to learn to use lisp, if at the other end
of the learning process you are in a more productive, more powerful
environment?
We should all try to change common lisp for the better I agree with
you, but the focus on competing with scripting languages designed for
light weight use is misdirected imho.
Justin
Seems that I am a week late to this thread but I wanted to point out,
for future generations, that in debian you can do approximately the
same thing for any lisp.
sudo apt-get install araneida
clisp
(clc:clc-require :araneida)
I did the install of araneida just for this post and it worked
beautifully. I didn't do a copy and paste because there was a lot of
output from the compile.
see http://www.cliki.net/common-lisp-control.
Ron Garret <·········@flownet.com> writes:
> In article <··············@rpi.edu>, Bill Atkins <············@rpi.edu>
> wrote:
>
>> Ron Garret <·········@flownet.com> writes:
>>
>> > In article <··············@rpi.edu>, Bill Atkins <············@rpi.edu>
>> > wrote:
>> >
>> >> Ron Garret <·········@flownet.com> writes:
>> >>
>> >> > In article <······················@parsec.no-spoon.de>,
>> >> > Stefan Scholl <······@no-spoon.de> wrote:
>> >> >
>> >> >> Ron Garret <·········@flownet.com> wrote:
>> >> >> > trying to use Lisp for e.g. writing a Web server is an incredibly
>> >> >> > painful experience compared to doing the same thing in e.g. Python.
>> >> >>
>> >> >> I could list some web servers written in Common Lisp.
>> >> >
>> >> > Yes, and it's probably a very long list. (And one of the items on that
>> >> > list would be http://www.cliki.net/HTTP%20dot%20LSP.)
>> >> >
>> >> > Now, compare any of those to the effort required to write a web server
>> >> > in Python, where you can do:
>> >> >
>> >> > import BaseHTTPServer
>> >> >
>> >> > rg
>> >>
>> >> That has nothing to do with the flaws or merits of Common Lisp,
>> >
>> > Of course it does.
>> >
>> > In CL there are a lot of web servers because CL doesn't come with one
>> > and none of the ones people have written are sufficient, otherwise
>> > people would not keep writing new ones.
>> >
>> >> and by
>> >> no stretch of the imagination can that be considered "writing" a web
>> >> server.
>> >
>> > What difference does it make? The indisputable point is that to get a
>> > web server up and running using Python takes substantially less effort
>> > than to get one up and running using CL.
>>
>> Your example does not set up a running web server.
>
> I never said it did. But it is a good first step.
>
>
>> For what it's worth, this is not so hard in Common Lisp:
>>
>> (require :araneida)
>>
>> or if you're not into the whole brevity thing:
>>
>> (asdf:oos 'asdf:load-op :araneida)
>
> Except it doesn't work:
>
>
>
> [···@Mini:~]$ sbcl
> This is SBCL 0.9.7, an implementation of ANSI Common Lisp.
> More information about SBCL is available at <http://www.sbcl.org/>.
>
> SBCL is free software, provided as is, with absolutely no warranty.
> It is mostly in the public domain; some portions are provided under
> BSD-style licenses. See the CREDITS and COPYING files in the
> distribution for more information.
> * (require :araneida)
>
> debugger invoked on a SB-INT:EXTENSION-FAILURE:
> Don't know how to REQUIRE ARANEIDA.
> See also:
> The SBCL Manual, Variable *MODULE-PROVIDER-FUNCTIONS*
> The SBCL Manual, Function REQUIRE
>
> Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
>
> restarts (invokable by number or by possibly-abbreviated name):
> 0: [ABORT] Exit debugger, returning to top level.
>
> (SB-IMPL::REQUIRE-ERROR "Don't know how to ~S ~A.")
> 0] ^D
> * (asdf:oos 'asdf:load-op :araneida)
>
> debugger invoked on a SB-KERNEL:READER-PACKAGE-ERROR:
> READER-ERROR at 609 on #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN*
> {8015F41}>:
> package "ASDF" not found
>
> Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
>
> restarts (invokable by number or by possibly-abbreviated name):
> 0: [ABORT] Exit debugger, returning to top level.
>
> (SB-IMPL::READ-TOKEN #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN* {8015F41}>
> #\a)
> 0]
>
>
>
> It gets worse. When you try to exit the debugger at this point you get:
>
>
>
> debugger invoked on a SB-KERNEL:READER-PACKAGE-ERROR:
> READER-ERROR at 783 on #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN*
> {8015F41}>:
> package "ASDF" not found
>
> Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
>
> restarts (invokable by number or by possibly-abbreviated name):
> 0: [ABORT] Exit debugger, returning to top level.
>
> (SB-IMPL::READ-TOKEN #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN* {8015F41}>
> #\a)
> 0] ^D
> *
> :ARANEIDA
> *
> debugger invoked on a READER-ERROR:
> READER-ERROR at 967 on #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN*
> {8015F41}>:
> unmatched close parenthesis
>
> Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
>
> restarts (invokable by number or by possibly-abbreviated name):
> 0: [ABORT] Exit debugger, returning to top level.
>
> (SB-IMPL::%READER-ERROR
> #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN* {8015F41}>
> "unmatched close parenthesis")
> 0] ^D
> *
>
>
> Try to look at the above from the point of view of a newcomer, and
> compare the experience the corresponding one in Python.
>
> rg
Hello, I'm a lisp newbie, using CL for only 2 years.
From this: `[···@Mini:~]$ sbcl', I think maybe you're using some version of
RedHat Linux, and installed sbcl yourself. I've using Debian GNU/Linux for
over 4 years. In Debian GNU/Linux, setup a Common Lisp programming environment
is very easy. I can install sbcl and araneida using this command:
# apt-get install sbcl araneida
And there's a package named `common-lisp-controller' and 'cl-asdf' will also
be installer automatically. Then compiling & loading the araneida Web Server
just need this:
······@binghe:~$ sbcl
This is SBCL 0.9.11, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.
SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
* (clc:clc-require :araneida)
;;; Please wait, recompiling library...
T
Acturally, I also write this in sbcl's startup scripts (~/.sbclrc):
#+COMMON-LISP-CONTROLLER
(defmacro r (p)
`(clc:clc-require ,p))
;; Check for --no-linedit command-line option.
#+COMMON-LISP-CONTROLLER
(if (member "--linedit" sb-ext:*posix-argv* :test 'equal)
(when (interactive-stream-p *terminal-io*)
(require :sb-aclrepl)
(funcall (intern "CLC-REQUIRE" :clc) :linedit)
(funcall (intern "INSTALL-REPL" :linedit) :wrap-current t))
(setf sb-ext:*posix-argv*
(remove "--linedit" sb-ext:*posix-argv* :test 'equal)))
#+COMMON-LISP-CONTROLLER
(if (member "--asdf-install" sb-ext:*posix-argv* :test 'equal)
(when (interactive-stream-p *terminal-io*)
(require :asdf-install))
(setf sb-ext:*posix-argv*
(remove "--linedit" sb-ext:*posix-argv* :test 'equal)))
#+COMMON-LISP-CONTROLLER
(if (member "--swank" sb-ext:*posix-argv* :test 'equal)
(when (interactive-stream-p *terminal-io*)
(r :swank)
;; start swank
(setf (symbol-value (intern "*USE-DEDICATED-OUTPUT-STREAM*" :swank)) nil)
(funcall (intern "CREATE-SERVER" :swank)
:dont-close t :external-format :utf-8-unix))
(setf sb-ext:*posix-argv*
(remove "--swank" sb-ext:*posix-argv* :test 'equal)))
Now I can start sbcl very easily to use asdf-install, swank & SLIME, and Linedit:
$ sbcl --linedit --swank --asdf-install
······@binghe:~$ sbcl --linedit --swank --asdf-install
This is SBCL 0.9.11, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.
SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
STYLE-WARNING: redefining GETENV in DEFUN
STYLE-WARNING: implicitly creating new generic function BACKEND-COLUMNS
STYLE-WARNING: implicitly creating new generic function BACKEND-LINES
STYLE-WARNING: implicitly creating new generic function BACKEND-INIT
STYLE-WARNING: implicitly creating new generic function BACKEND-CLOSE
STYLE-WARNING: implicitly creating new generic function READ-CHORD
STYLE-WARNING: implicitly creating new generic function BEEP
STYLE-WARNING: implicitly creating new generic function PAGE
STYLE-WARNING: implicitly creating new generic function PRINT-IN-COLUMNS
STYLE-WARNING: implicitly creating new generic function PRINT-IN-LINES
STYLE-WARNING: implicitly creating new generic function NEWLINE
STYLE-WARNING: implicitly creating new generic function REWIND-STATE
; loading system definition from
; /usr/lib/sbcl/sb-bsd-sockets/sb-bsd-sockets.asd into #<PACKAGE "ASDF0">
; registering #<SYSTEM SB-BSD-SOCKETS {AFB5DB1}> as SB-BSD-SOCKETS
; registering #<SYSTEM SB-BSD-SOCKETS-TESTS {B363619}> as SB-BSD-SOCKETS-TESTS
STYLE-WARNING: redefining PREFERRED-COMMUNICATION-STYLE NIL in DEFMETHOD
STYLE-WARNING: redefining CALL-WITHOUT-INTERRUPTS (T) in DEFMETHOD
STYLE-WARNING: redefining LISP-IMPLEMENTATION-TYPE-NAME NIL in DEFMETHOD
STYLE-WARNING: redefining CALL-WITH-SYNTAX-HOOKS (T) in DEFMETHOD
STYLE-WARNING: redefining DEFAULT-READTABLE-ALIST NIL in DEFMETHOD
STYLE-WARNING: redefining ARGLIST (T) in DEFMETHOD
STYLE-WARNING: redefining INSTALL-DEBUGGER-GLOBALLY (T) in DEFMETHOD
STYLE-WARNING: redefining CALL-WITH-DEBUGGER-HOOK (T T) in DEFMETHOD
STYLE-WARNING: redefining FORMAT-SLDB-CONDITION (T) in DEFMETHOD
STYLE-WARNING: redefining CONDITION-REFERENCES (T) in DEFMETHOD
STYLE-WARNING: redefining UNPROFILE-ALL NIL in DEFMETHOD
STYLE-WARNING: implicitly creating new generic function STARTUP-MULTIPROCESSING
WARNING: DEFIMPLEMENTATION of undefined interface (STARTUP-MULTIPROCESSING)
STYLE-WARNING: redefining THREAD-NAME (T) in DEFMETHOD
STYLE-WARNING: redefining THREAD-STATUS (T) in DEFMETHOD
STYLE-WARNING: redefining MAKE-LOCK NIL in DEFMETHOD
STYLE-WARNING: redefining CALL-WITH-LOCK-HELD (T T) in DEFMETHOD
STYLE-WARNING: redefining CURRENT-THREAD NIL in DEFMETHOD
STYLE-WARNING: redefining KILL-THREAD (T) in DEFMETHOD
STYLE-WARNING: redefining THREAD-ALIVE-P (T) in DEFMETHOD
STYLE-WARNING: redefining MAKE-STREAM-INTERACTIVE (T) in DEFMETHOD
STYLE-WARNING: redefining BUFFER-FIRST-CHANGE (T) in DEFMETHOD
STYLE-WARNING:
implicitly creating new generic function STREAM-READ-CHAR-WILL-HANG-P
STYLE-WARNING:
implicitly creating new generic function INSPECT-BIGGER-PIECE-ACTIONS
STYLE-WARNING:
implicitly creating new generic function INSPECT-WHOLE-THING-ACTION
STYLE-WARNING: implicitly creating new generic function INSPECT-SHOW-MORE-ACTION
STYLE-WARNING:
implicitly creating new generic function MENU-CHOICES-FOR-PRESENTATION
;; Swank started at port: 4005.
Linedit version 0.15.12 [smart mode]
CL-USER(1):
Thanks of many lisp programmers' contribute, programming in lisp are very
convenient!
In article <··············@binghe.163.org>,
········@corp.netease.com (Chun Tian (binghe)) wrote:
> Hello, I'm a lisp newbie, using CL for only 2 years.
>
> From this: `[···@Mini:~]$ sbcl', I think maybe you're using some version of
> RedHat Linux, and installed sbcl yourself.
It's a Mac mini actually.
> I've using Debian GNU/Linux for
> over 4 years. In Debian GNU/Linux, setup a Common Lisp programming
> environment is very easy.
I'm pleased that it worked for you.
rg
Ron Garret <·········@flownet.com> writes:
> In article <··············@rpi.edu>, Bill Atkins <············@rpi.edu>
> wrote:
>
>> Ron Garret <·········@flownet.com> writes:
>>
>> > In article <······················@parsec.no-spoon.de>,
>> > Stefan Scholl <······@no-spoon.de> wrote:
>> >
>> >> Ron Garret <·········@flownet.com> wrote:
>> >> > trying to use Lisp for e.g. writing a Web server is an incredibly
>> >> > painful experience compared to doing the same thing in e.g. Python.
>> >>
>> >> I could list some web servers written in Common Lisp.
>> >
>> > Yes, and it's probably a very long list. (And one of the items on that
>> > list would be http://www.cliki.net/HTTP%20dot%20LSP.)
>> >
>> > Now, compare any of those to the effort required to write a web server
>> > in Python, where you can do:
>> >
>> > import BaseHTTPServer
>> >
>> > rg
>>
>> That has nothing to do with the flaws or merits of Common Lisp,
>
> Of course it does.
>
> In CL there are a lot of web servers because CL doesn't come with one
> and none of the ones people have written are sufficient, otherwise
> people would not keep writing new ones.
>
>> and by
>> no stretch of the imagination can that be considered "writing" a web
>> server.
>
> What difference does it make? The indisputable point is that to get a
> web server up and running using Python takes substantially less effort
> than to get one up and running using CL.
>
Afraid I lost you with this one Ron. This is not about the weaknesses
of the language, just about available libraries - all that complexity
in the server referenced by you at the cliki site is just hidden under
the import statement in python. Using pythons import statement is
pretty similar to using a single asdf line to load portable aserve.
Granted the popularity of python has created a wealth of libraries
which are readily available and there is some justification to an
argument that CL would benefit from a standardised and centrally
managed library repository etc. However, this has nothing to do with
limitations in the language or any of the original points you stated.
Tim
--
tcross (at) rapttech dot com dot au
Ron Garret <·········@flownet.com> wrote:
> Stefan Scholl <······@no-spoon.de> wrote:
>> I could list some web servers written in Common Lisp.
>
> Yes, and it's probably a very long list. (And one of the items on that
> list would be http://www.cliki.net/HTTP%20dot%20LSP.)
>
> Now, compare any of those to the effort required to write a web server
> in Python, where you can do:
>
> import BaseHTTPServer
(require :araneida) ;-)
Ron Garret wrote:
> In article <······················@parsec.no-spoon.de>,
> Stefan Scholl <······@no-spoon.de> wrote:
>
>
>>Ron Garret <·········@flownet.com> wrote:
>>
>>>trying to use Lisp for e.g. writing a Web server is an incredibly
>>>painful experience compared to doing the same thing in e.g. Python.
>>
>>I could list some web servers written in Common Lisp.
>
>
> Yes, and it's probably a very long list. (And one of the items on that
> list would be http://www.cliki.net/HTTP%20dot%20LSP.)
>
> Now, compare any of those to the effort required to write a web server
> in Python, where you can do:
>
> import BaseHTTPServer
>
This is a very sad example, because this is exactly what
newbies, especially teenage hacker dudes are interested
in these days. If a programming infrastructure fails
to provide batteries included in order to make their ideas
fly, then they will take their business to a programming
infrastructure that does. And teenage hacker dudes grow
up and vote. And who can blame them if they stick to
their trusty perl or python or VB that made their eyes light
up with glee when their first web- or socket-thingy just
worked?
Lisp's outlandish syntax and questionable reputation in
the mainstream are problematic enough in the competition
for the hearts and minds of newbies. It really takes some
maturity as a programmer or exceptional vision or both
to see the beauty in this beast, if you catch my drift.
What's more, Lisp has a more complex theoretical
underpinning than the p* languages. Most programming
cadets either
- want to emulate what they see and admire, and
this is 3D computer games and web stuff
or
- want to solve a problem, like laying pipes between
MS Office- or Unix applications
Now try to imagine someone who wants to put up a website
or wants to write a simple frontend to an Access database
application and is looking for some toolset to enable him to
do that. Even if some OSS Lisp-implementation had drop-in
support for this, it is hard to imagine that such an
adventurous soon-to-be geek would opt for Lisp, not even
if a friend or local authority would recommend it to him.
The adventurous soon-to-be geek would dismiss Lisp very
soon, because with her concepts of passing around functions,
Lukasiewicz-notation and drawings of cons-cells it is
not competitive with more conventional languages using
infix-notation and less obvious concepts.
Precisely these concepts give Lisp her power, alright,
but this power shines for handling complex sophisticated
data structures and building clever abstractions. This
is not what beginners need, this is something SOME computer
scientists and SOME people with the scars of C++- and Java-agonies
appreciate. More often than not, however, not even this demography
sees the advantages of Lisp, because they dismissed Lisp
early on and gave the simpler languages the opportunity
to shape their thinking in their formative years. Again,
even WITH a drop-in webserver (or other equivalents to
popular CPAN-libs) Lisp had a hard time competing
with p* or Java. She's just a little too odd and too
kinky for conventional wisdom. As an aside, similiar
effects make C++ a little too cumbersome for the conventional
wisdom, thus it will be retired together with the people
who had their formative years in the pre-perl, pre-Java
and pre-C#-days. In a word, failing to delight ASPIRING
programmers is a serious obstacle on the road to world-domination.
The problem with programming languages (or software in
general) is, that there is no middle ground between world
domination and total obscurity. Those who have will get more.
In this light, it is a testament to Lisp's power that
a miniscule community can actually build libraries and
components that are competitive in functionality with
the equivalents in more popular languages. They are not
quite as polished, but I understand that this is exactly what
Peter Seibel's Gardeners are trying to fix.
You can come to two contradicting conclusions based on
this observations:
- Give up on the aspiring programmers who just want to
script, because it's a lost cause anyway, but this
means giving up on Lisp. The aspiring and the casual
geeks make or break a language's popularity
- Try harder to make Lisp a "batteries included" language
like python (or, even more so, perl, although she doesn't
have that slogan)
I'm pessimistic about the former. I don't think that
ANY set of libraries can compensate for Lisp's weirdness.
However, what I don't really understand is Lisp's low acceptance among
experienced programmers, especially those who don't need
drop-in libraries for piping between server apps, Windows
apps or scripting. There are many complex problems in niche
domains that typically fail because they turn into a flea circus
due to language brittleness (ask EDS or your favourite random
Fortune 500 IT contractor). The more plausible attitude
toward Lisp in these circles should be "Okay guys, let's get
real. Java might be the right hammer to do some enterprise
toilet paper web procurement service, but our proposed
air-flight reservation system requires something more
professional. Silly parentheses and closures, you say?
Get out of your dress..." The steep learning curve should not deter a
real programmer, and real programmers WANT to be real
programmers, and Lisp would be an ideal opportunity to show
off their mojo, to separate the boys from the men.
What's more, large and sophisticated
projects are planned for years, so even months of intense
training are a low price for proven increased productivity,
especially if the domain itself requires specialized and
expensive education.
Professional barbers don't use Gilettes or electric shavers,
they use straight razors because they give a better shave
and they are faster. A straight razor is not a consumer- or
convenience product, because it requires skill and you
can hurt yourself; but skill and a focus on faster
and better results is what makes a professional a professional.
In a related metaphor, this is the reason why sane IT shops don't use
Windows as a server platform, but favor the much less consumery
Unix. Windows is optimized for office babes, just
like a Philishave, and this gets in the way for SERIOUS
computing needs. Unix requires more training and touch-typing, but
those who have gone thru the training
are rewarded with faster and better results. Unix, however,
has less of a problem getting this message thru than Lisp.
"command line > drag & drop" is obviously more plausible
in computing than "s-expressions > Java". This lack of insight
gets even more puzzling while watching the pathetic attempts
in enterprise computing that try to address things like
code reuse, "programmer automation", domain-specific languages
and less bugs. I think most of us laugh at all the fads that
fail to live up to their corresponding promises
(UML, XML-based programming languages, code generators,
*-driven programming, CASE-tools, etc.) The pointy-haired
bosses are looking at all the wrong places and stubbornly
refuse to even notice or discuss Lisp for some reason.
Laughing at them is not enough, however. I have no idea how
to pull this off (I'm an armchair-revolutionary, you see),
but I wonder if the PHBs' desperation is not ripe for exploitation
by Lisp-pundits, but there is no Lisp-pundit with enough
ambition or credibility. Maybe Paul Graham is THE ONE as soon
as his wealth surpasses that of Billy or Stevo. Money sells.
Maybe we should buy more of Paul Graham's books.
What do we learn from that? Well, nothing. This is just another
Lisp-musing from someone who has promoted himself from
Lisp-newbie to armchair-Lispnik. I'm jealous for Ron Garret,
by the way. I understand that Ron Garret is rich, but far
more attractive and enviable is his spending 20 years as a Lisp
programmer. Better a poor Lisper than a rich Javamonkey, I really mean
that. And "my programming career has been destroyed" is a somewhat
weird testimonial for one who has ended up with a fortune (did I get
that right, Ron? How did THAT happen?)
Ron Garret <·········@flownet.com> wrote:
> niche within a niche, or writing to the least common denominator, which
> generally means writing an awful lot of #+ reader macros.
You'll receive the #+ reader macros from interested users.
Ron Garret wrote:
> Two things to get out of the way at the outset:
>
> 1. Note that the title of this post is *HOW* CL sucks, not *WHY* it
> sucks. The difference is significant. Please take the time to
> understand it before you flame me.
The title "How some aspects of Common Lisp suck" would have been even
more appropriate, especially considering your own final remarks.
> I am writing this because of the debate surrounding Steve Yegge's recent
> blog entries on Lisp. It is unfortunate that he made so many technical
> mistakes in his posts because they distract people from the fact that
> underneath all the errors he is actually making a valid point, that
> being that CL has very significant problems that are barriers to its
> adoption. (Some people think this is a feature, that having a few
> obstacles to overcome keeps out the rif raf. I suppose this is a
> defensible position, but I don't subscribe to it.)
There must be a bottom line somewhere. I don't think you would want the
authors of the entries in the Daily WTF as a target audience
> I'm going to point out just three problems with CL. There are more.
> None of these are original observations.
>
> 1. CL lacks standardized support for many operations that are
> necessities in today's world (e.g. sockets, database connectivity,
> foreign functions). Moreover, it lacks any mechanism by which these
> features could be standardized.
It lacks any _sanctioned_ mechanism for standardization. There is
certainly a mechanism for creating defacto standards.
> It is claimed that there are portable
> libraries that work across implementations that provide de facto
> standards, e.g. UFFI, but these claims are false.
You probably don't mean what you say here. There are definitely portable
libraries out there. Maybe not for foreign function interfaces (I can't
judge this), but certainly for other things.
> The Balkanization of the CL implementation space also has the
> consequence that one must choose between using implementation-specific
> features and thus limiting the potential audience for one's code to a
> niche within a niche, or writing to the least common denominator, which
> generally means writing an awful lot of #+ reader macros.
...or writing compatibility layers.
> 2. Even for the one thing that CL claims to be particularly good at --
> as a platform for embedding domain-specific languages -- it has
> significant limits. To embed languages that differ from CL's semantics
> in certain ways requires significant effort. To cite but one example: I
> would like to embed a language that is very similar to Common Lisp, but
> which differs in how it handles global variable references (to use
> global lexical environments) and ((function-returning-a-function)
> arguments) syntax. The former can be done using symbol macros, but only
> if the top-level definitions precede their first use.
The same holds for global dynamic variables: If you use them before you
have defined them, you are invoking undefined behavior. So there is no
difference between global dynamic and global lexical variables here.
> If you reference
> a global before defining it then you're screwed. The latter cannot be
> done at all within CL unless you write a full code walker. But adding
> this capability is utterly trivial within an implementation. In MCL it
> takes two lines of code. And if it were done it would result in
> strictly greater expressive power.
The difference between (funcall (some-expression)) and
((some-expression)) is not that of fundamentally different expressive
power. You get an increase in expressiveness when you can avoid having
to touch various places in your source code by using a single construct.
The switch from (funcall (some-expression)) to ((some-expression)) is a
strictly local change.
For example, the addition of call/cc would indeed be an increase in
expressive power.
(Note that increased expressive power is not necessarily a good thing.
Consider the "come from" statement in Intercal as a counter example,
which also mean an increase in expressive power when added to Common Lisp.)
> Furthermore, it is not even
> necessary to agree on the semantics of ((...) ...). One could simply
> add a new macro defining form (or even a global variable) to set a
> user-definable hook for transforming expressions whose CARs are lists
> that do not begin with LAMDBA. All that would need to be agreed upon is
> the name of this form. Furthermore, this would result in strictly
> greater expressive power. It would be strictly backwards-compatible.
> And It would serve the needs of a number of users who are not currently
> being served (e.g. those who prefer to do functional-style programming
> without having to type FUNCALL all the time.)
You would have to define a way to delimit the scope of the different
possible hooks, otherwise it becomes a nightmare to try to mix and match
different third-party libraries.
> But despite the fact that this change is easy and only good could come
> of it, it does not happen because there is no process by which this
> change can be effected (which is, I believe, a direct consequence of the
> fact that the realities of CL politics are that CL is utterly resistant
> to all change, though I would dearly love to be proven wrong on that).
The change you propose is easy to make, but the consequences of it are
not necessarily easy to deal with.
I don't have the impression that the CL community is resistant to
change. See the various projects in various places that are quite
healthy, as far as I can tell. (If I remember corretly,
http://cl-user.net counts more than 600 entries.)
> (Oh, and anyone who wishes to prove me wrong, please not that there is a
> big big difference between effecting change in CL and effecting change
> in an implementation of CL.)
Sure. But do note that the language constructs that are part of Common
Lisp have been tried in other Lisp dialects before. I think that picking
a single Common Lisp implementation and experimenting with language
constructs there to see whether they pay off before proposing them as
official features is the healthier approach.
> 3. Much of CL's core is badly designed. For example, consider NTH and
> ELT. The functionality of ELT is a strict superset of NTH, so why have
> NTH cluttering up the language? (To say nothing of the fact that the
> order of the arguments in these two functions are gratuitously
> reversed.) Why is the function that computes the difference of two sets
> called SET-DIFFERENCE, but the function that computes the intersection
> of two sets called simply INTERSECTION? And why do all of these
> functions operate on lists, not sets? It's because there are no sets in
> CL, which means that CL leads one to prematurely "optimize" sets as
> lists. (I put optimize in scare quotes because in fact this is rarely
> an optimization, especially when your sets get big, and most of the time
> you have to go back and rip out huge chunks of code to replace your
> lists with hash tables or binary trees.) I could go on and on.
These features exist all for backwards compatibility. They could at most
be deprecated, otherwise you would break a lot of existing code. I am
certain that this would do more harm than bring any benefits because the
community is, I think, not large enough to rewrite the large amount of
useful code that does exist.
It's trivial to define your own package with the name and argument
conventions that you prefer. There is no need to force anyone else to
use the same conventions.
> Now, for those of you who wish to respond I ask you to keep in mind the
> following:
>
> 1. The details of my criticisms are mostly irrelevant. What matters is
> that CL is far from perfect, and that it has no mechanism for change.
> So don't bother picking a nit about one of my specific criticisms unless
> you wish to argue that CL is perfect and doesn't need to change.
These nits would have to be picked in case we had an official mechanism
for change. So it's a good exercise to do this already, in order to be
able to estimate whether the installation of an official mechanism would
be worthwhile.
I think there are better examples than the ones you propose. See for
example
http://www.cliki.net/Proposed%20ANSI%20Revisions%20and%20Clarifications
> 2. I know a lot more about Lisp that Steve Yegge. I spent twenty years
> programming in Lisp for a living. I have authored some highly
> referenced papers on Lisp. I am far from the world's foremost expert,
> but I'm no newbie. If you think I'm wrong about a technical point you
> should think twice.
>
> 3. I do not hate Lisp. It is and has always been my favorite
> programming languages. My love for Lisp pretty much destroyed my career
> as a programmer. My motivation for criticising Lisp is not to convince
> people not to use it. It is to effect changes that I believe are
> necessary to get more people to use it. To quote Paul Graham, "It's not
> Lisp that sucks, it's Common Lisp that sucks." And actually, I would
> soften that somewhat: it's not Common Lisp that sucks, it's some parts
> of Common Lisp that suck. But make no mistake, some parts of Common
> Lisp really do suck, and unless they are fixed a lot of people -- myself
> included -- won't be able to use it even though they may want to really
> badly.
Maybe.
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
Pascal Costanza wrote:
> Ron Garret wrote:
>
>> Two things to get out of the way at the outset:
>>
>> 1. Note that the title of this post is *HOW* CL sucks, not *WHY* it
>> sucks. The difference is significant. Please take the time to
>> understand it before you flame me.
>
>
> The title "How some aspects of Common Lisp suck" would have been even
> more appropriate, especially considering your own final remarks.
Or try the title Yegge seems to have in the end come round to: "Lisp
Rocks! Now if only there were standard sockets, threads, and GUI!"
Well, sure. It seems we all agree, except for thread titles, and it will
be hard to get people seeking attention to eschew "Lisp Sucks!".
btw, I think LTk is a nice start on the GUI bit, because Tcl/Tk offers
other platform-independent goodies and nothing about it is
Lisp-implementation specific.
My question is, why is it such a big deal for the other stuff to be
standardized? I mean, how many app developers are bouncing from Lisp
implementation to Lisp implementation? As for library authors, shucks,
we work pretty hard anyway, a little featurization is not going to kill
us, esp. since, as someone already noted, those come from others on
other platforms if one has built a fun library.
I say again, the good news is that Lisp has so much mindshare now that
people can use it to draw attention to themselves. Hmmm...
ken
--
Cells: http://common-lisp.net/project/cells/
"Have you ever been in a relationship?"
Attorney for Mary Winkler, confessed killer of her
minister husband, when asked if the couple had
marital problems.
In article <··············@individual.net>,
Pascal Costanza <··@p-cos.net> wrote:
> > I'm going to point out just three problems with CL. There are more.
> > None of these are original observations.
> >
> > 1. CL lacks standardized support for many operations that are
> > necessities in today's world (e.g. sockets, database connectivity,
> > foreign functions). Moreover, it lacks any mechanism by which these
> > features could be standardized.
>
> It lacks any _sanctioned_ mechanism for standardization. There is
> certainly a mechanism for creating defacto standards.
That's news to me. What is it?
> > It is claimed that there are portable
> > libraries that work across implementations that provide de facto
> > standards, e.g. UFFI, but these claims are false.
>
> You probably don't mean what you say here. There are definitely portable
> libraries out there. Maybe not for foreign function interfaces (I can't
> judge this), but certainly for other things.
Of course there are portable libraries, just not for the things that
matter in today's world.
> The same holds for global dynamic variables: If you use them before you
> have defined them, you are invoking undefined behavior. So there is no
> difference between global dynamic and global lexical variables here.
Aw, geez, let's not descend into quibbling over these details. You know
perfectly well that every implementation handles an undeclared free
variable reference by assuming it's a dynamic reference.
> > If you reference
> > a global before defining it then you're screwed. The latter cannot be
> > done at all within CL unless you write a full code walker. But adding
> > this capability is utterly trivial within an implementation. In MCL it
> > takes two lines of code. And if it were done it would result in
> > strictly greater expressive power.
>
> The difference between (funcall (some-expression)) and
> ((some-expression)) is not that of fundamentally different expressive
> power.
You're right, I misspoke. It's not a matter of expressiveness, it's a
matter of verbosity. ((...) ...) is spelled (funcall (...) ...). But
my point is that if you don't like all that extra verbiage there's no
way to change it, and no good reason why you shouldn't be able to.
> (Note that increased expressive power is not necessarily a good thing.
> Consider the "come from" statement in Intercal as a counter example,
> which also mean an increase in expressive power when added to Common Lisp.)
Yes, a good point.
> > Furthermore, it is not even
> > necessary to agree on the semantics of ((...) ...). One could simply
> > add a new macro defining form (or even a global variable) to set a
> > user-definable hook for transforming expressions whose CARs are lists
> > that do not begin with LAMDBA. All that would need to be agreed upon is
> > the name of this form. Furthermore, this would result in strictly
> > greater expressive power. It would be strictly backwards-compatible.
> > And It would serve the needs of a number of users who are not currently
> > being served (e.g. those who prefer to do functional-style programming
> > without having to type FUNCALL all the time.)
>
> You would have to define a way to delimit the scope of the different
> possible hooks, otherwise it becomes a nightmare to try to mix and match
> different third-party libraries.
Fine, make it a hook function then. Now all we need to agree on is the
name of the variable.
> > But despite the fact that this change is easy and only good could come
> > of it, it does not happen because there is no process by which this
> > change can be effected (which is, I believe, a direct consequence of the
> > fact that the realities of CL politics are that CL is utterly resistant
> > to all change, though I would dearly love to be proven wrong on that).
>
> The change you propose is easy to make, but the consequences of it are
> not necessarily easy to deal with.
>
> I don't have the impression that the CL community is resistant to
> change.
Really? Then why has there been no change in CL in a decade?
> See the various projects in various places that are quite
> healthy, as far as I can tell. (If I remember corretly,
> http://cl-user.net counts more than 600 entries.)
Non-sequitur. There is a big difference between writing code in the
language and making changes to the language.
> > (Oh, and anyone who wishes to prove me wrong, please not that there is a
> > big big difference between effecting change in CL and effecting change
> > in an implementation of CL.)
>
> Sure. But do note that the language constructs that are part of Common
> Lisp have been tried in other Lisp dialects before. I think that picking
> a single Common Lisp implementation and experimenting with language
> constructs there to see whether they pay off before proposing them as
> official features is the healthier approach.
Indeed. I'm not saying that we should dive wholesale into a redesign.
All I'm saying is that there ought to be an end-game for the process.
> > 3. Much of CL's core is badly designed. For example, consider NTH and
> > ELT. The functionality of ELT is a strict superset of NTH, so why have
> > NTH cluttering up the language? (To say nothing of the fact that the
> > order of the arguments in these two functions are gratuitously
> > reversed.) Why is the function that computes the difference of two sets
> > called SET-DIFFERENCE, but the function that computes the intersection
> > of two sets called simply INTERSECTION? And why do all of these
> > functions operate on lists, not sets? It's because there are no sets in
> > CL, which means that CL leads one to prematurely "optimize" sets as
> > lists. (I put optimize in scare quotes because in fact this is rarely
> > an optimization, especially when your sets get big, and most of the time
> > you have to go back and rip out huge chunks of code to replace your
> > lists with hash tables or binary trees.) I could go on and on.
>
> These features exist all for backwards compatibility. They could at most
> be deprecated, otherwise you would break a lot of existing code. I am
> certain that this would do more harm than bring any benefits because the
> community is, I think, not large enough to rewrite the large amount of
> useful code that does exist.
IMO, just having the ability to (semi-)officially deprecate cruft, even
if it never actually goes away, I think would have enormous payoffs.
But we don't currently have that ability.
> It's trivial to define your own package with the name and argument
> conventions that you prefer. There is no need to force anyone else to
> use the same conventions.
Yes there is: it makes life VASTLY easier for newcomers if the actual
language (as opposed to someone's private library) is not full of random
crap.
This, by the way, is the crux of SteveY's point. It often gets
overlooked so it bears repeating: it's all about how accessible the
language is to newcomers. If the language is full of random crap then
it becomes less accessible to newcomers. A library that covers up the
crap doesn't help nearly as much as actually cleaning the crap up.
> > Now, for those of you who wish to respond I ask you to keep in mind the
> > following:
> >
> > 1. The details of my criticisms are mostly irrelevant. What matters is
> > that CL is far from perfect, and that it has no mechanism for change.
> > So don't bother picking a nit about one of my specific criticisms unless
> > you wish to argue that CL is perfect and doesn't need to change.
>
> These nits would have to be picked in case we had an official mechanism
> for change. So it's a good exercise to do this already, in order to be
> able to estimate whether the installation of an official mechanism would
> be worthwhile.
No, because in the absence of a process the argument can be sustained
indefinitely with no resolution. Those who oppose change will falsely
claim that this is evidence that adopting a process for managing change
is hopeless (or useless, or some such thing).
> I think there are better examples than the ones you propose.
Of course there are. If you think that is relevant then you have
completely missed the point.
rg
On Mon, 17 Apr 2006 21:28:39 -0700, Ron Garret <·········@flownet.com> wrote:
>
> In article <··············@individual.net>,
> Pascal Costanza <··@p-cos.net> wrote:
>
> >
> > It lacks any _sanctioned_ mechanism for standardization. There is
> > certainly a mechanism for creating defacto standards.
>
> That's news to me. What is it?
defacto standards come into being; they are not created.
--
Jack Unrue
In article <··································@4ax.com>,
Jack Unrue <·······@example.tld> wrote:
> On Mon, 17 Apr 2006 21:28:39 -0700, Ron Garret <·········@flownet.com> wrote:
> >
> > In article <··············@individual.net>,
> > Pascal Costanza <··@p-cos.net> wrote:
> >
> > >
> > > It lacks any _sanctioned_ mechanism for standardization. There is
> > > certainly a mechanism for creating defacto standards.
> >
> > That's news to me. What is it?
>
> defacto standards come into being; they are not created.
If they are not created then how can there be a mechanism for creating
them?
rg
Ron Garret wrote:
> In article <··············@individual.net>,
> Pascal Costanza <··@p-cos.net> wrote:
>
>>> I'm going to point out just three problems with CL. There are more.
>>> None of these are original observations.
>>>
>>> 1. CL lacks standardized support for many operations that are
>>> necessities in today's world (e.g. sockets, database connectivity,
>>> foreign functions). Moreover, it lacks any mechanism by which these
>>> features could be standardized.
>> It lacks any _sanctioned_ mechanism for standardization. There is
>> certainly a mechanism for creating defacto standards.
>
> That's news to me. What is it?
It's a three-step process, and consists of: 1. Writing code, 2.
publishing it, 3. getting acceptance of a considerable number of members
in the Common Lisp community.
>>> It is claimed that there are portable
>>> libraries that work across implementations that provide de facto
>>> standards, e.g. UFFI, but these claims are false.
>> You probably don't mean what you say here. There are definitely portable
>> libraries out there. Maybe not for foreign function interfaces (I can't
>> judge this), but certainly for other things.
>
> Of course there are portable libraries, just not for the things that
> matter in today's world.
What matters in today's world varies heavily across different users of
Common Lisp. A sanctioned standardization process would have to somehow
deal with making a decision what comes first. This has the danger of
leading to a large amount of bureaucracy, and furthermore doesn't
guarantee in any way that newbies' needs are addressed.
>> The same holds for global dynamic variables: If you use them before you
>> have defined them, you are invoking undefined behavior. So there is no
>> difference between global dynamic and global lexical variables here.
>
> Aw, geez, let's not descend into quibbling over these details. You know
> perfectly well that every implementation handles an undeclared free
> variable reference by assuming it's a dynamic reference.
No, I don't know that perfectly well. I try to stick what ANSI Common
Lisp specifies as far as possible in order to be sure to be portable, so
that I have to worry less. Furthermore, I had the impression that you
are concerned about sanctioned standards. Now you are apparently
invoking a defacto standard.
I think that 'always define variables before you use them' is a far
better description for a newbie than 'define special variables whenever
you want because most implementations treat references to such variables
as special anyway; if you happen to encounter an implementation that
doesn't do this, you're screwed, and then you have to rearrange your
code; nevertheless, symbol macros should always be defined before their
use'. There's something wrong here.
>>> If you reference
>>> a global before defining it then you're screwed. The latter cannot be
>>> done at all within CL unless you write a full code walker. But adding
>>> this capability is utterly trivial within an implementation. In MCL it
>>> takes two lines of code. And if it were done it would result in
>>> strictly greater expressive power.
>> The difference between (funcall (some-expression)) and
>> ((some-expression)) is not that of fundamentally different expressive
>> power.
>
> You're right, I misspoke. It's not a matter of expressiveness, it's a
> matter of verbosity. ((...) ...) is spelled (funcall (...) ...). But
> my point is that if you don't like all that extra verbiage there's no
> way to change it, and no good reason why you shouldn't be able to.
There is a way to change this. I have a fully working embedding of a
Lisp-1 in Common Lisp, including a large subset of R4RS Scheme lying
around. (It's not published yet, I still want to polish and document it.)
It's sufficient if this is done once, you don't a general mechanism to
allow this being done several times.
>>> Furthermore, it is not even
>>> necessary to agree on the semantics of ((...) ...). One could simply
>>> add a new macro defining form (or even a global variable) to set a
>>> user-definable hook for transforming expressions whose CARs are lists
>>> that do not begin with LAMDBA. All that would need to be agreed upon is
>>> the name of this form. Furthermore, this would result in strictly
>>> greater expressive power. It would be strictly backwards-compatible.
>>> And It would serve the needs of a number of users who are not currently
>>> being served (e.g. those who prefer to do functional-style programming
>>> without having to type FUNCALL all the time.)
>> You would have to define a way to delimit the scope of the different
>> possible hooks, otherwise it becomes a nightmare to try to mix and match
>> different third-party libraries.
>
> Fine, make it a hook function then. Now all we need to agree on is the
> name of the variable.
How do you ensure that hook function 1 is used in your library but hook
function 2 is used in mine, when both libraries should be used in the
same program?
>>> But despite the fact that this change is easy and only good could come
>>> of it, it does not happen because there is no process by which this
>>> change can be effected (which is, I believe, a direct consequence of the
>>> fact that the realities of CL politics are that CL is utterly resistant
>>> to all change, though I would dearly love to be proven wrong on that).
>> The change you propose is easy to make, but the consequences of it are
>> not necessarily easy to deal with.
>>
>> I don't have the impression that the CL community is resistant to
>> change.
>
> Really? Then why has there been no change in CL in a decade?
I cannot judge the last decade because I have only entered the scene a
few years before. But I have already noticed a lot of change in that
short period of time. Nothing of this is sanctioned by some authority,
but I don't have the impression that this is strictly necessary. Peter
Seibel has done a very good job of attracting newbies without any change
to the language at all.
Sooner or later, a more official process will emerge. The failure of
CLRFI shows that there wasn't the right the time yet for something like
this. We first need a larger user base before we can get something like
this off the ground. I know, it's a chicken-and-egg problem, but that's
like it is.
>> See the various projects in various places that are quite
>> healthy, as far as I can tell. (If I remember corretly,
>> http://cl-user.net counts more than 600 entries.)
>
> Non-sequitur. There is a big difference between writing code in the
> language and making changes to the language.
I strongly disagree. We can get quite far in Common Lisp, even for
things that some people have considered to be only doable by changes to
the language in the past. It's a good idea to explore the boundaries first.
>>> (Oh, and anyone who wishes to prove me wrong, please not that there is a
>>> big big difference between effecting change in CL and effecting change
>>> in an implementation of CL.)
>> Sure. But do note that the language constructs that are part of Common
>> Lisp have been tried in other Lisp dialects before. I think that picking
>> a single Common Lisp implementation and experimenting with language
>> constructs there to see whether they pay off before proposing them as
>> official features is the healthier approach.
>
> Indeed. I'm not saying that we should dive wholesale into a redesign.
> All I'm saying is that there ought to be an end-game for the process.
...and this is exactly where the problem starts: The CLRFI process had
the problem that it was overengineered, too bureaucratic, and since the
people behind it didn't have the resources (mostly time) to really
support it, it didn't get off the ground. The overengineering came, I
think, from the fear that CLRFI submitters would go too far, and that's
exactly an issue that a sanctioned process would have to deal with:
where to draw the line between changes that go too far and changes that
are ok. I mean, would a proposal to change Common Lisp into a Lisp-1 be
acceptable? Addition of call/cc? Removal of LOOP and replacement with
iterate? Removal of CLOS, to make the language smaller?
> IMO, just having the ability to (semi-)officially deprecate cruft, even
> if it never actually goes away, I think would have enormous payoffs.
> But we don't currently have that ability.
Some people think that the existing deprecations in ANSI Common Lisp
should be removed...
>> It's trivial to define your own package with the name and argument
>> conventions that you prefer. There is no need to force anyone else to
>> use the same conventions.
>
> Yes there is: it makes life VASTLY easier for newcomers if the actual
> language (as opposed to someone's private library) is not full of random
> crap.
Here is a suggestion: Provide an embedding of ISLISP in Common Lisp. You
would have a language subset that conforms to a newer standard than ANSI
Common Lisp, you would have a cleaner subset, and you would have a
language that is easier to teach to newbies. Yet, they could still move
from there to Common Lisp without having to "unlearn" any substantial
concepts. That would be a good start, wouldn't it? And it wouldn't
require the installment of a new sanctioned process.
>> I think there are better examples than the ones you propose.
>
> Of course there are. If you think that is relevant then you have
> completely missed the point.
It is relevant. It shows that the psychological strain isn't high
enough, because even the better examples don't make Common Lispers say
that installing a new sanctioned process should have a high priority.
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
In article <··············@individual.net>,
Pascal Costanza <··@p-cos.net> wrote:
a few remarks to some parts
> Ron Garret wrote:
> > In article <··············@individual.net>,
> > Pascal Costanza <··@p-cos.net> wrote:
> >
> >>> I'm going to point out just three problems with CL. There are more.
> >>> None of these are original observations.
> >>>
> >>> 1. CL lacks standardized support for many operations that are
> >>> necessities in today's world (e.g. sockets, database connectivity,
> >>> foreign functions). Moreover, it lacks any mechanism by which these
> >>> features could be standardized.
> >> It lacks any _sanctioned_ mechanism for standardization. There is
> >> certainly a mechanism for creating defacto standards.
> >
> > That's news to me. What is it?
>
> It's a three-step process, and consists of: 1. Writing code, 2.
> publishing it, 3. getting acceptance of a considerable number of members
> in the Common Lisp community.
Yeah, writing real Lisp code. A novel approach. Got to try that soon. ;-)
>
> There is a way to change this. I have a fully working embedding of a
> Lisp-1 in Common Lisp, including a large subset of R4RS Scheme lying
> around. (It's not published yet, I still want to polish and document it.)
and
> Here is a suggestion: Provide an embedding of ISLISP in Common Lisp. You
> would have a language subset that conforms to a newer standard than ANSI
> Common Lisp, you would have a cleaner subset, and you would have a
> language that is easier to teach to newbies. Yet, they could still move
> from there to Common Lisp without having to "unlearn" any substantial
> concepts. That would be a good start, wouldn't it? And it wouldn't
> require the installment of a new sanctioned process.
Actually I don't think that's a useful approach. Adding slighty
semantically different languages on top Common Lisp will
confuse people even more. I'd better think Common Lisp should be
slightly improved without big changes.
I would propose:
Stick to Common Lisp. It is there and it has great implementations.
Contrary to public believe you can write software in Common Lisp.
And this it is not THAT difficult.
The language is there and it is fine enough.
The larger problem is this:
Even Common Lisp is a Lisp. One of the core ideas of Lisp is
flexibility. With Lisp you have lots of flexibility. And that's
actually a problem. You can even change the language to be
much more expressive towards your problem. We all know
the mechanisms that Common Lisp provides (macros, reader macros,
CLOS MOP, ...).
Now people want to write software with Common Lisp. And you have
all this power. Probably too much power.
What really is needed is to educate Lisp developers how to
use the language and its implementations effectively,
given the thousands of possibilities to shoot yourself
into the foot. Unfortunately there isn't much standard
literature on that. Historically Common Lisp has been
often a testbed for new ideas. But how do you develop
a CLOS-based software architecture for an email server?
That's why I think Peter Seibel's book is so important.
I can easily imagine lots of books to be written
on that topic. ;-)
It is my impression that people don't struggle to much
with the language, but they struggle how to apply
the language and an implementation to a problem and
how to implement a solution.
Summary:
- we don't need more experiments with the language. The
language is there and good enough. It is not likely
that within the next decade something better (for
various dimensions of better) will appear.
- we need more certainty to write quality software in
Lisp and how to do it. Lisp-based software engineering
principles.
--
http://lispm.dyndns.org/
In article <··············@qrnik.zagroda>,
Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> wrote:
> Ron Garret <·········@flownet.com> writes:
>
> > What if I don't want a Lisp-1? What if I want a Lisp-2 that handles
> > ((...) ...)?
>
> This would be inconsistent: you would be able to put as the function
> to be applied any expression *except* a variable reference or symbol
> macro.
Right. So?
rg
Ron Garret <·········@flownet.com> writes:
>> > What if I don't want a Lisp-1? What if I want a Lisp-2 that handles
>> > ((...) ...)?
>>
>> This would be inconsistent: you would be able to put as the function
>> to be applied any expression *except* a variable reference or symbol
>> macro.
>
> Right. So?
It's ugly and surprising. For me it's worse than either Lisp-1 (which
I prefer) or Lisp-2.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
In article <··············@qrnik.zagroda>,
Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> wrote:
> Ron Garret <·········@flownet.com> writes:
>
> >> > What if I don't want a Lisp-1? What if I want a Lisp-2 that handles
> >> > ((...) ...)?
> >>
> >> This would be inconsistent: you would be able to put as the function
> >> to be applied any expression *except* a variable reference or symbol
> >> macro.
> >
> > Right. So?
>
> It's ugly and surprising. For me it's worse than either Lisp-1 (which
> I prefer) or Lisp-2.
You're entitled to your opinion, but I don't think it's inherently ugly
to (be able to) spell (funcall (...) ...) as ((...) ...). For certain
programming styles it can save a lot of typing.
rg
Ron Garret wrote:
> In article <··············@qrnik.zagroda>,
> Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> wrote:
>
>> Ron Garret <·········@flownet.com> writes:
>>
>>>>> What if I don't want a Lisp-1? What if I want a Lisp-2 that handles
>>>>> ((...) ...)?
>>>> This would be inconsistent: you would be able to put as the function
>>>> to be applied any expression *except* a variable reference or symbol
>>>> macro.
>>> Right. So?
>> It's ugly and surprising. For me it's worse than either Lisp-1 (which
>> I prefer) or Lisp-2.
>
> You're entitled to your opinion, but I don't think it's inherently ugly
> to (be able to) spell (funcall (...) ...) as ((...) ...). For certain
> programming styles it can save a lot of typing.
Consider this:
(defmacro foo () 'bar)
(let ((bar (lambda () 'a)))
(flet ((bar () 'b))
((foo))))
Which result do you want? Why?
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
In article <··············@individual.net>,
Pascal Costanza <··@p-cos.net> wrote:
> Ron Garret wrote:
> > In article <··············@qrnik.zagroda>,
> > Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> wrote:
> >
> >> Ron Garret <·········@flownet.com> writes:
> >>
> >>>>> What if I don't want a Lisp-1? What if I want a Lisp-2 that handles
> >>>>> ((...) ...)?
> >>>> This would be inconsistent: you would be able to put as the function
> >>>> to be applied any expression *except* a variable reference or symbol
> >>>> macro.
> >>> Right. So?
> >> It's ugly and surprising. For me it's worse than either Lisp-1 (which
> >> I prefer) or Lisp-2.
> >
> > You're entitled to your opinion, but I don't think it's inherently ugly
> > to (be able to) spell (funcall (...) ...) as ((...) ...). For certain
> > programming styles it can save a lot of typing.
>
> Consider this:
>
> (defmacro foo () 'bar)
>
> (let ((bar (lambda () 'a)))
> (flet ((bar () 'b))
> ((foo))))
>
> Which result do you want? Why?
Well, personally I would expand ((foo)) to (funcall (foo)), at which
point the standard CL semantics take over. But with a user-definable
macro expansion for ((...) ...) one could make this work however one
wished.
rg
Ron Garret wrote:
> In article <··············@individual.net>,
> Pascal Costanza <··@p-cos.net> wrote:
>
>> Ron Garret wrote:
>>>>> 1. CL lacks standardized support for many operations that are
>>>>> necessities in today's world (e.g. sockets, database connectivity,
>>>>> foreign functions). Moreover, it lacks any mechanism by which these
>>>>> features could be standardized.
>>>> It lacks any _sanctioned_ mechanism for standardization. There is
>>>> certainly a mechanism for creating defacto standards.
>>> That's news to me. What is it?
>> It's a three-step process, and consists of: 1. Writing code, 2.
>> publishing it, 3. getting acceptance of a considerable number of members
>> in the Common Lisp community.
>
> "Considerable number?" That's pretty vague, isn't it? And what
> constitutes acceptance?
I know it when I see it. ;) Yes, that's vague, but it's good enough.
(Consider something in an official standard that noone uses. Would you
call that "accepted"? I wouldn't.)
>> What matters in today's world varies heavily across different users of
>> Common Lisp. A sanctioned standardization process would have to somehow
>> deal with making a decision what comes first. This has the danger of
>> leading to a large amount of bureaucracy, and furthermore doesn't
>> guarantee in any way that newbies' needs are addressed.
>
> True, but the lack of any such process guarantees that these needs will
> not be addressed.
Only if that were the only way to address these needs.
> Es ist nicht gesagt das es besser wird wenn es anders wird. Wenn es
> aber besser werden soll, muss es anders werden.
Es ist aber schon auch wichtig, was das genau bedeuten soll, denn es
sollte klar sein, dass nicht jeder beliebige andere Weg zur Verbesserung
beitragen kann.
>>>> The same holds for global dynamic variables: If you use them before you
>>>> have defined them, you are invoking undefined behavior. So there is no
>>>> difference between global dynamic and global lexical variables here.
>>> Aw, geez, let's not descend into quibbling over these details. You know
>>> perfectly well that every implementation handles an undeclared free
>>> variable reference by assuming it's a dynamic reference.
>> No, I don't know that perfectly well. I try to stick what ANSI Common
>> Lisp specifies as far as possible in order to be sure to be portable, so
>> that I have to worry less. Furthermore, I had the impression that you
>> are concerned about sanctioned standards. Now you are apparently
>> invoking a defacto standard.
>
> This is one of the very few instances of behavior outside the standard
> where every single implementation works in exactly the same way, and in
> the one case where an implementation didn't work that way (CMUCL) people
> screamed loudly until they changed it.
Doesn't matter. It's not covered by a sanctioned process, it doesn't
support your point of view.
>> I think that 'always define variables before you use them' is a far
>> better description for a newbie than 'define special variables whenever
>> you want because most implementations treat references to such variables
>> as special anyway; if you happen to encounter an implementation that
>> doesn't do this, you're screwed, and then you have to rearrange your
>> code; nevertheless, symbol macros should always be defined before their
>> use'. There's something wrong here.
>
> How about, "If you forget to declare a global variable before you use it
> then it will be treated according to the code transformation specified
> in the built-in global variable *undefined-global-reference-hook*. By
> default this hook generates an error (which on a strict reading of the
> standard it is), but you can redefine this behavior if you find it
> annoying.
This would have unpleasant side effects on other parts of the ANSI
Common Lisp standard, and it would be a daunting process to figure out
all the consequences. For what purpose? I still think my explanation is
easier to understand by a newbie than yours, your suggestion rather
looks like a hook "for experts", so I don't think this would attract
more newbies.
Meta-comment: Such a discussion is important. If we don't find a single
example for changing the language in a fundamental way that would
actually make the language easier to understand for newbies without
loosing expressiveness (!), then this point is moot.
> What if I don't want a Lisp-1? What if I want a Lisp-2 that handles
> ((...) ...)?
That would lead to an inconsistent language.
>>>>> Furthermore, it is not even
>>>>> necessary to agree on the semantics of ((...) ...). One could simply
>>>>> add a new macro defining form (or even a global variable) to set a
>>>>> user-definable hook for transforming expressions whose CARs are lists
>>>>> that do not begin with LAMDBA. All that would need to be agreed upon is
>>>>> the name of this form. Furthermore, this would result in strictly
>>>>> greater expressive power. It would be strictly backwards-compatible.
>>>>> And It would serve the needs of a number of users who are not currently
>>>>> being served (e.g. those who prefer to do functional-style programming
>>>>> without having to type FUNCALL all the time.)
>>>> You would have to define a way to delimit the scope of the different
>>>> possible hooks, otherwise it becomes a nightmare to try to mix and match
>>>> different third-party libraries.
>>> Fine, make it a hook function then. Now all we need to agree on is the
>>> name of the variable.
>> How do you ensure that hook function 1 is used in your library but hook
>> function 2 is used in mine, when both libraries should be used in the
>> same program?
>
> (EVAL-WHEN (LOAD-TOPLEVEL) ; or whatever the right one is -- these
> always confused me
> (SETF *NON-LAMBDA-LIST-CAR-MACRO-EXPANDER-HOOK* ...))
What would be the effect on code generated by macros from another
library? What if you use different macros of different libraries in the
same form? Should code generated by a macro be all the same, or is code
that is passed to a macro as a parameter handled differently?
Is this really worth the fuzz? Does this make the language easier to
understand / more attractive to newbies?
>>>>> But despite the fact that this change is easy and only good could come
>>>>> of it, it does not happen because there is no process by which this
>>>>> change can be effected (which is, I believe, a direct consequence of the
>>>>> fact that the realities of CL politics are that CL is utterly resistant
>>>>> to all change, though I would dearly love to be proven wrong on that).
>>>> The change you propose is easy to make, but the consequences of it are
>>>> not necessarily easy to deal with.
>>>>
>>>> I don't have the impression that the CL community is resistant to
>>>> change.
>>> Really? Then why has there been no change in CL in a decade?
>> I cannot judge the last decade because I have only entered the scene a
>> few years before. But I have already noticed a lot of change in that
>> short period of time.
>
> Like what? Just writing code isn't the same thing as a change in the
> language.
We need a convincing example that would justify changing the language.
(Like: Integrating the CLOS MOP.)
>> Peter
>> Seibel has done a very good job of attracting newbies without any change
>> to the language at all.
>
> Just think how many more he might have attracted if he could have
> included an HTTP client as an example in his book.
>
>> Sooner or later, a more official process will emerge.
>
> From your lips to God's ear.
I am a notorious optimist. You have to deal with this. ;)
>>>> See the various projects in various places that are quite
>>>> healthy, as far as I can tell. (If I remember corretly,
>>>> http://cl-user.net counts more than 600 entries.)
>>> Non-sequitur. There is a big difference between writing code in the
>>> language and making changes to the language.
>> I strongly disagree. We can get quite far in Common Lisp, even for
>> things that some people have considered to be only doable by changes to
>> the language in the past. It's a good idea to explore the boundaries first.
>
> You mean like http://www.flownet.com/gat/locales.pdf for example?
Yep. I think we can get even farther than that.
>>>>> (Oh, and anyone who wishes to prove me wrong, please not that there is a
>>>>> big big difference between effecting change in CL and effecting change
>>>>> in an implementation of CL.)
>>>> Sure. But do note that the language constructs that are part of Common
>>>> Lisp have been tried in other Lisp dialects before. I think that picking
>>>> a single Common Lisp implementation and experimenting with language
>>>> constructs there to see whether they pay off before proposing them as
>>>> official features is the healthier approach.
>>> Indeed. I'm not saying that we should dive wholesale into a redesign.
>>> All I'm saying is that there ought to be an end-game for the process.
>> ...and this is exactly where the problem starts: The CLRFI process had
>> the problem that it was overengineered, too bureaucratic, and since the
>> people behind it didn't have the resources (mostly time) to really
>> support it, it didn't get off the ground. The overengineering came, I
>> think, from the fear that CLRFI submitters would go too far
>
> Yes. "Fear of going too far" is a source of much of the resistance to
> change in the CL community.
I agree.
> I repeat my slogan (in English this time):
> different is not necessarily better. But better is necessarily
> different.
However, it's also important what this should exactly mean, because it's
also clear that not any different way will actually lead to an improvement.
>> and that's
>> exactly an issue that a sanctioned process would have to deal with:
>> where to draw the line between changes that go too far and changes that
>> are ok. I mean, would a proposal to change Common Lisp into a Lisp-1 be
>> acceptable? Addition of call/cc? Removal of LOOP and replacement with
>> iterate? Removal of CLOS, to make the language smaller?
>
> Deprecating NTH in favor of ELT?
That's all? ;)
(Note that my list was a list of examples that were actually discussed
as part of the ANSI standardization process, if I understand correctly.)
>>> IMO, just having the ability to (semi-)officially deprecate cruft, even
>>> if it never actually goes away, I think would have enormous payoffs.
>>> But we don't currently have that ability.
>> Some people think that the existing deprecations in ANSI Common Lisp
>> should be removed...
>
> And your point would be?
It's hard to get an agreement on these things, and it's hard to avoid
making the language even more complex than it is. Here are two passages
from the "The Evolution of Lisp" by Gabriel/Steele:
"Once there is a cleanup format for changes, there are a raft of changes
made to Common Lisp. Hundreds of changes are made, many for no
compelling reason."
"Though this might seem funny, it shows how a process of increasing
desire for expressiveness, intensified attention to getting the details
right (even for details that almost never matter), the need for
individuals to make their mark, and a seemingly deliberate blind eye
towards commercial realities can lead to an unintended result�a large,
unwieldy language that few can completely understand."
In other words, the danger that the result could be even worse than what
we currently have is a real one. This needs to be addressed.
BTW, we haven't even touched the question on how to evaluate whether the
resulting language will actually be easier to understand by newbies or
not. I guess that different people also have different ideas in this regard.
> I have actually tried to design a more easily learned Lisp that could be
> embedded in CL and I keep running headlong into certain fundamental
> limitations, like the inability to intercept the handling of undeclared
> globals.
Why don't you write an interpreter first? That should be easier.
>>>> I think there are better examples than the ones you propose.
>>> Of course there are. If you think that is relevant then you have
>>> completely missed the point.
>> It is relevant. It shows that the psychological strain isn't high
>> enough, because even the better examples don't make Common Lispers say
>> that installing a new sanctioned process should have a high priority.
>
> Yes, that is clearly true. IMO it is lamentable.
Maybe, maybe not. It's how it is.
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
In article <··············@individual.net>,
Pascal Costanza <··@p-cos.net> wrote:
> > What if I don't want a Lisp-1? What if I want a Lisp-2 that handles
> > ((...) ...)?
>
> That would lead to an inconsistent language.
Why?
> > (EVAL-WHEN (LOAD-TOPLEVEL) ; or whatever the right one is -- these
> > always confused me
> > (SETF *NON-LAMBDA-LIST-CAR-MACRO-EXPANDER-HOOK* ...))
>
> What would be the effect on code generated by macros from another
> library? What if you use different macros of different libraries in the
> same form? Should code generated by a macro be all the same, or is code
> that is passed to a macro as a parameter handled differently?
These would cause potentially harmful interactions. Much like mucking
with *READTABLE* can do today. If either of these ever became serious
issues they could be addressed at that time.
> Is this really worth the fuzz? Does this make the language easier to
> understand / more attractive to newbies?
I don't know. Maybe, maybe not. Like I keep saying, the specific
examples don't matter. Unless you wish to argue that Lisp is not
capable of being improved it necessarily follows that somewhere out
there is an example that would improve it. Whether I am actually
capable of generating one doesn't matter.
> We need a convincing example that would justify changing the language.
> (Like: Integrating the CLOS MOP.)
Fine, pick that as your example then. How many times do I have to say
that the example doesn't matter?
(The problem with picking an example is that there will always be
someone out there who can shoot it down. If you pick a big example like
the MOP then people object because it's too big and hairy and there's no
hope of getting everyone to agree. If you pick a little example like
cleaning up ELT and NTH then people shoot it down because it's trivial
and because it can be fixed within the language (though this doesn't
help the textbook writers who have to teach the standard). If you pick
an example that can't be fixed within the language like ((...) ...) then
people complain that it's unimportant.)
> > Deprecating NTH in favor of ELT?
>
> That's all? ;)
See what I mean?
> >>> IMO, just having the ability to (semi-)officially deprecate cruft, even
> >>> if it never actually goes away, I think would have enormous payoffs.
> >>> But we don't currently have that ability.
> >> Some people think that the existing deprecations in ANSI Common Lisp
> >> should be removed...
> >
> > And your point would be?
>
> It's hard to get an agreement on these things, and it's hard to avoid
> making the language even more complex than it is.
Of course it is. Worthwhile things are rarely easy.
> In other words, the danger that the result could be even worse than what
> we currently have is a real one. This needs to be addressed.
Of course. There is no reward without risk.
> > I have actually tried to design a more easily learned Lisp that could be
> > embedded in CL and I keep running headlong into certain fundamental
> > limitations, like the inability to intercept the handling of undeclared
> > globals.
>
> Why don't you write an interpreter first? That should be easier.
Because interpreters are slow, and the whole point of CL is supposed to
be that you can extend it via macros and read macros to *embed*
customized languages within CL so that they can be compiled without
having to write a new compiler. By embedding a language it becomes
strictly as powerful as CL in every respect (since it is a superset of
CL) and therefore much more likely to be used than a slow interpreted
orthogonal language.
rg
On Wed, 19 Apr 2006 12:16:25 -0700, Ron Garret wrote:
> I don't know. Maybe, maybe not. Like I keep saying, the specific
> examples don't matter. Unless you wish to argue that Lisp is not
> capable of being improved it necessarily follows that somewhere out
> there is an example that would improve it. Whether I am actually
> capable of generating one doesn't matter.
Except specific examples _do_ matter. Besides being intellectually lazy,
discounting your inability to provide compelling examples as irrelevant
dilutes what little credibility you have on the subject.
To put it another way-- how can we take you seriously? Without
specificity, it's easy to get people to agree with you. When you are
specific, we find out that your gripes are not our gripes, that your ideal
process and "improvements" to the language are half-baked, and that you
are really an outsider posing as an insider: a Pythonista with an axe to
grind against the language that has let you down, seemingly out of touch
with the tools and processes that Lispers productively use to get real
work done every day.
Or maybe you just like trolling. Certainly you caught me.
Matt
--
"You do not really understand something unless you can
explain it to your grandmother." - Albert Einstein.
In article <······························@c.net>,
"Matthew D. Swank" <·······································@c.net>
wrote:
> On Wed, 19 Apr 2006 12:16:25 -0700, Ron Garret wrote:
>
> > I don't know. Maybe, maybe not. Like I keep saying, the specific
> > examples don't matter. Unless you wish to argue that Lisp is not
> > capable of being improved it necessarily follows that somewhere out
> > there is an example that would improve it. Whether I am actually
> > capable of generating one doesn't matter.
>
> Except specific examples _do_ matter. Besides being intellectually lazy,
> discounting your inability to provide compelling examples as irrelevant
> dilutes what little credibility you have on the subject.
Well, it's not like I haven't given any examples. The problem is that
no matter what example I give, someone will shoot it down. If I give a
big example (like the lack of modules) then someone will shoot it down
saying it's too much work to settle on a standard. If I give a little
problem (like ((...) ...) syntax or NTH/ELT) then someone will shoot it
down because it's too trivial to bother with. And all this shooting
down detracts from the point that I'm actually trying to make, which is
not about any of these specific problems at all, but rather about the
process (or lack thereof) of dealing with them.
> To put it another way-- how can we take you seriously? Without
> specificity, it's easy to get people to agree with you. When you are
> specific, we find out that your gripes are not our gripes, that your ideal
> process and "improvements" to the language are half-baked, and that you
> are really an outsider posing as an insider: a Pythonista with an axe to
> grind against the language that has let you down, seemingly out of touch
> with the tools and processes that Lispers productively use to get real
> work done every day.
Well, that's not so far from the truth. Nowadays I am a Pythonista,
though reluctantly so. I don't know if I have an axe to grind, but I do
have an agenda. I don't think the language has let me down, but the
community surrounding the language certainly has by creating an
environment where it is impossible for me to use the language even
though I very much want to. As for being out of touch, I am certainly
not up on all the latest developments, but I don't have to be in order
to see the huge difference in user experience between Lisp and Python.
> Or maybe you just like trolling.
No. Believe me, I'm not having any fun doing this.
rg
Ron Garret wrote:
> In article <··············@individual.net>,
> Pascal Costanza <··@p-cos.net> wrote:
>
>>> What if I don't want a Lisp-1? What if I want a Lisp-2 that handles
>>> ((...) ...)?
>> That would lead to an inconsistent language.
>
> Why?
See my other post.
>>> (EVAL-WHEN (LOAD-TOPLEVEL) ; or whatever the right one is -- these
>>> always confused me
>>> (SETF *NON-LAMBDA-LIST-CAR-MACRO-EXPANDER-HOOK* ...))
>> What would be the effect on code generated by macros from another
>> library? What if you use different macros of different libraries in the
>> same form? Should code generated by a macro be all the same, or is code
>> that is passed to a macro as a parameter handled differently?
>
> These would cause potentially harmful interactions. Much like mucking
> with *READTABLE* can do today. If either of these ever became serious
> issues they could be addressed at that time.
This is handwaving. The comparison to *readtable* doesn't hold because
after the code has been read, the setting of *readtable* doesn't have
any effect anymore. What you propose has to be dealt with at a later
stage, so you indeed get undesirable interactions between different
parts of code that you wouldn't get with different readtables.
A deeper analysis would be required here.
>> Is this really worth the fuzz? Does this make the language easier to
>> understand / more attractive to newbies?
>
> I don't know. Maybe, maybe not. Like I keep saying, the specific
> examples don't matter. Unless you wish to argue that Lisp is not
> capable of being improved it necessarily follows that somewhere out
> there is an example that would improve it. Whether I am actually
> capable of generating one doesn't matter.
Yes, it does matter. We need at least one example. Preferably many.
Otherwise, we would create a process for no purpose.
>> We need a convincing example that would justify changing the language.
>> (Like: Integrating the CLOS MOP.)
>
> Fine, pick that as your example then. How many times do I have to say
> that the example doesn't matter?
Sorry, I disagree. The example does matter.
> (The problem with picking an example is that there will always be
> someone out there who can shoot it down. If you pick a big example like
> the MOP then people object because it's too big and hairy and there's no
> hope of getting everyone to agree.
The CLOS MOP specification itself states very clearly that it is not
supposed to be the final word. There are a number of problems in that
spec that need to be addressed first before it could be standardized.
Addressing those problems is much more important than the
standardization itself. (I am actually doing something in that area to
improve things. I am happy that other people are investing time in other
issues.)
> If you pick a little example like
> cleaning up ELT and NTH then people shoot it down because it's trivial
> and because it can be fixed within the language (though this doesn't
> help the textbook writers who have to teach the standard).
Textbook writers have to pick a subset of the language anyway if they
want to address newcomers. Alternatively, by the time a textbook has
explained the whole language, then readers will probably already know
how to work around the issues. (They will know how to do a (shadow 'nth).)
> If you pick
> an example that can't be fixed within the language like ((...) ...) then
> people complain that it's unimportant.)
No, the hard part here is getting the semantics right.
>> It's hard to get an agreement on these things, and it's hard to avoid
>> making the language even more complex than it is.
>
> Of course it is. Worthwhile things are rarely easy.
So do you agree that the details of the actual process are important? Or
do you think that any old process would do?
>> In other words, the danger that the result could be even worse than what
>> we currently have is a real one. This needs to be addressed.
>
> Of course. There is no reward without risk.
Sure.
>>> I have actually tried to design a more easily learned Lisp that could be
>>> embedded in CL and I keep running headlong into certain fundamental
>>> limitations, like the inability to intercept the handling of undeclared
>>> globals.
>> Why don't you write an interpreter first? That should be easier.
>
> Because interpreters are slow, and the whole point of CL is supposed to
> be that you can extend it via macros and read macros to *embed*
> customized languages within CL so that they can be compiled without
> having to write a new compiler. By embedding a language it becomes
> strictly as powerful as CL in every respect (since it is a superset of
> CL) and therefore much more likely to be used than a slow interpreted
> orthogonal language.
Sure, but the context is experimenting with language features that
cannot be embedded, so embedding them is by definition not an option.
Apparently, you would like to see standardization first, and then trying
out whether things actually work. This gives you crap like J2EE. It's
better to first try things out, and when you know that they work and
they are useful (at best by having some users) to attempt to standardize
them.
The thing about interpreters is irrelevant. Most successful language
concepts have first been implemented in interpreted languages. The fact
that Python, Ruby, Perl, etc., are interpreted didn't keep them from
succeeding, either.
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
In article <··············@individual.net>,
Pascal Costanza <··@p-cos.net> wrote:
> Ron Garret wrote:
> > In article <··············@individual.net>,
> > Pascal Costanza <··@p-cos.net> wrote:
> >
> >>> What if I don't want a Lisp-1? What if I want a Lisp-2 that handles
> >>> ((...) ...)?
> >> That would lead to an inconsistent language.
> >
> > Why?
>
> See my other post.
Which other post?
Look, I'll just state flat out that you're wrong, and I know that you're
wrong because I've actually implemented this so that constitutes an
existence proof that it would not be inconsistent. You might not find
the resulting semantics aesthetically pleasing, but they are certainly
not inconsistent.
> >>> (EVAL-WHEN (LOAD-TOPLEVEL) ; or whatever the right one is -- these
> >>> always confused me
> >>> (SETF *NON-LAMBDA-LIST-CAR-MACRO-EXPANDER-HOOK* ...))
> >> What would be the effect on code generated by macros from another
> >> library? What if you use different macros of different libraries in the
> >> same form? Should code generated by a macro be all the same, or is code
> >> that is passed to a macro as a parameter handled differently?
> >
> > These would cause potentially harmful interactions. Much like mucking
> > with *READTABLE* can do today. If either of these ever became serious
> > issues they could be addressed at that time.
>
> This is handwaving. The comparison to *readtable* doesn't hold because
> after the code has been read, the setting of *readtable* doesn't have
> any effect anymore.
It isn't handwaving because after the code has been compiled the setting
of *NON-LAMBDA-LIST-CAR-MACRO-EXPANDER-HOOK* doesn't have any effect any
more.
> >> Is this really worth the fuzz? Does this make the language easier to
> >> understand / more attractive to newbies?
> >
> > I don't know. Maybe, maybe not. Like I keep saying, the specific
> > examples don't matter. Unless you wish to argue that Lisp is not
> > capable of being improved it necessarily follows that somewhere out
> > there is an example that would improve it. Whether I am actually
> > capable of generating one doesn't matter.
>
> Yes, it does matter. We need at least one example. Preferably many.
> Otherwise, we would create a process for no purpose.
I have already given so many examples that I'm blue in the face. You
have given some examples yourself (the MOP, the outstanding ANSI
issues). Choose any one you like.
> >> It's hard to get an agreement on these things, and it's hard to avoid
> >> making the language even more complex than it is.
> >
> > Of course it is. Worthwhile things are rarely easy.
>
> So do you agree that the details of the actual process are important?
Yes.
> Or do you think that any old process would do?
Obviously not, or I would be content with the current process (or lack
thereof as the case may be).
> >>> I have actually tried to design a more easily learned Lisp that could be
> >>> embedded in CL and I keep running headlong into certain fundamental
> >>> limitations, like the inability to intercept the handling of undeclared
> >>> globals.
> >> Why don't you write an interpreter first? That should be easier.
> >
> > Because interpreters are slow, and the whole point of CL is supposed to
> > be that you can extend it via macros and read macros to *embed*
> > customized languages within CL so that they can be compiled without
> > having to write a new compiler. By embedding a language it becomes
> > strictly as powerful as CL in every respect (since it is a superset of
> > CL) and therefore much more likely to be used than a slow interpreted
> > orthogonal language.
>
> Sure, but the context is experimenting with language features that
> cannot be embedded, so embedding them is by definition not an option.
No, that's just one set of issues. Libraries can be embedded, but the
language would still benefit from having them (or at least their
interfaces) standardized.
> Apparently, you would like to see standardization first, and then trying
> out whether things actually work.
No. Where did I say that?
> This gives you crap like J2EE. It's
> better to first try things out, and when you know that they work and
> they are useful (at best by having some users) to attempt to standardize
> them.
Yes, I agree. But it is still beneficial at some point to be able to
say, "OK, we're done evaluating, we are now deciding to go with X from
this point on." That is what CL cannot currently do.
> The thing about interpreters is irrelevant.
Not to me. One of the things I like about CL is that native code
compilers are available for it. Why should I have to have to give that
up to do what I want to do?
> Most successful language
> concepts have first been implemented in interpreted languages. The fact
> that Python, Ruby, Perl, etc., are interpreted didn't keep them from
> succeeding, either.
True, but I think they all would have been even more successful if they
had compilers.
rg
Ron Garret wrote:
> In article <··············@individual.net>,
> Pascal Costanza <··@p-cos.net> wrote:
>
>> Ron Garret wrote:
>>> In article <··············@individual.net>,
>>> Pascal Costanza <··@p-cos.net> wrote:
>>>
>>>>> What if I don't want a Lisp-1? What if I want a Lisp-2 that handles
>>>>> ((...) ...)?
>>>> That would lead to an inconsistent language.
>>> Why?
>> See my other post.
>
> Which other post?
>
> Look, I'll just state flat out that you're wrong, and I know that you're
> wrong because I've actually implemented this so that constitutes an
> existence proof that it would not be inconsistent. You might not find
> the resulting semantics aesthetically pleasing, but they are certainly
> not inconsistent.
>
>>>>> (EVAL-WHEN (LOAD-TOPLEVEL) ; or whatever the right one is -- these
>>>>> always confused me
>>>>> (SETF *NON-LAMBDA-LIST-CAR-MACRO-EXPANDER-HOOK* ...))
>>>> What would be the effect on code generated by macros from another
>>>> library? What if you use different macros of different libraries in the
>>>> same form? Should code generated by a macro be all the same, or is code
>>>> that is passed to a macro as a parameter handled differently?
>>> These would cause potentially harmful interactions. Much like mucking
>>> with *READTABLE* can do today. If either of these ever became serious
>>> issues they could be addressed at that time.
>> This is handwaving. The comparison to *readtable* doesn't hold because
>> after the code has been read, the setting of *readtable* doesn't have
>> any effect anymore.
>
> It isn't handwaving because after the code has been compiled the setting
> of *NON-LAMBDA-LIST-CAR-MACRO-EXPANDER-HOOK* doesn't have any effect any
> more.
What happens in code that is not compiled? What happens if I want to
combine macros from different libraries that use different settings for
your hook? How do I write code walkers in the face of your proposed
extension? Have you checked the side effects of combining your feature
with each and every other feature that's already part of Common Lisp?
The important thing here is that standardization is the trivial part.
Getting the details right is the hard part.
>> Apparently, you would like to see standardization first, and then trying
>> out whether things actually work.
>
> No. Where did I say that?
I don't have the impression that you have thought your suggestions
through in all necessary details. (Maybe that's my problem.)
For example, CL-PPCRE is apparently a defacto standard not because
someone sanctioned it, but because Edi got the details right. I think
getting the details right is more important.
Again, I am very optimistic that the necessary infrastructure for easing
installation of libraries will be in place in a few years from now the
latest. People are actually working on the details for this.
>> This gives you crap like J2EE. It's
>> better to first try things out, and when you know that they work and
>> they are useful (at best by having some users) to attempt to standardize
>> them.
>
> Yes, I agree. But it is still beneficial at some point to be able to
> say, "OK, we're done evaluating, we are now deciding to go with X from
> this point on." That is what CL cannot currently do.
That's correct, but I don't think that's nearly as important as you
think it is. The community is growing, libraries are being developed and
published, the infrastructure is improving, people are meeting to
discuss issues, and so on, and so forth. We must be doing something
right, right? ;)
Of course, there is always room for improvement. But things can also
grow too fast. Apparently, the time wasn't ripe yet for something like
CLRFI, otherwise it would have just worked (tm). In the meantime,
repositories like cl-user.net are built that can be the foundations for
what will eventually be useful in an assessment of what and what doesn't
exist, and how we can proceed from there.
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
In article <··············@individual.net>,
Pascal Costanza <··@p-cos.net> wrote:
> >>>>> (EVAL-WHEN (LOAD-TOPLEVEL) ; or whatever the right one is -- these
> >>>>> always confused me
> >>>>> (SETF *NON-LAMBDA-LIST-CAR-MACRO-EXPANDER-HOOK* ...))
> >>>> What would be the effect on code generated by macros from another
> >>>> library? What if you use different macros of different libraries in the
> >>>> same form? Should code generated by a macro be all the same, or is code
> >>>> that is passed to a macro as a parameter handled differently?
> >>> These would cause potentially harmful interactions. Much like mucking
> >>> with *READTABLE* can do today. If either of these ever became serious
> >>> issues they could be addressed at that time.
> >> This is handwaving. The comparison to *readtable* doesn't hold because
> >> after the code has been read, the setting of *readtable* doesn't have
> >> any effect anymore.
> >
> > It isn't handwaving because after the code has been compiled the setting
> > of *NON-LAMBDA-LIST-CAR-MACRO-EXPANDER-HOOK* doesn't have any effect any
> > more.
>
> What happens in code that is not compiled?
It's implementation-dependent, since the spec does not specify when
macros are expanded in that case. In theory this could cause problems,
but since it is exceedingly rare to run library code uncompiled this is
unlikely to be a problem in practice.
> What happens if I want to
> combine macros from different libraries that use different settings for
> your hook?
Then you would compile those libraries. The code for each library would
set the hook appropriately for that library.
> How do I write code walkers in the face of your proposed
> extension?
The same way you do now, except that there would one additional clause
in the central dispatcher to handle the ((...) ...) case. It would
simply call the function bound to
*NON-LAMBDA-LIST-CAR-MACRO-EXPANDER-HOOK* with the form as an argument
and pass the result back to the code walker.
> Have you checked the side effects of combining your feature
> with each and every other feature that's already part of Common Lisp?
Not explicitly, no. But since this is a strictly backwards-compatible
extension it cannot possibly cause problems for any existing correct
code.
> The important thing here is that standardization is the trivial part.
> Getting the details right is the hard part.
Not in this case. This example was very carefully designed to be
absolutely unambiguously a win. There is no possible legitimate
technical objection to this proposal. The only possible objections are
aesthetic.
And BTW, just so we don't lose sight of it, my objective in raising this
point is not that I particularly want to see this extension made to CL.
It is to demonstrate that people WILL RAISE those aesthetic objections,
that those aesthetic objections will cause the proposal to not be
adopted, and this therefore proves SteveY's point that CL is a religion
with the Hyperspec as its holy text to which no alterations may be made.
> >> Apparently, you would like to see standardization first, and then trying
> >> out whether things actually work.
> >
> > No. Where did I say that?
>
> I don't have the impression that you have thought your suggestions
> through in all necessary details. (Maybe that's my problem.)
You keep missing the process forest by focusing on the example trees.
Just suspend your disbelief for a moment and imagine that I have thought
through every detail and I have in fact identified a change to the
language that for whatever reason is an unambiguous win. Now what?
> Again, I am very optimistic that the necessary infrastructure for easing
> installation of libraries will be in place in a few years from now the
> latest. People are actually working on the details for this.
So should I give up on CL for now and try again in a few years?
(Remember, this is a customer asking, not a member of the community.)
> >> This gives you crap like J2EE. It's
> >> better to first try things out, and when you know that they work and
> >> they are useful (at best by having some users) to attempt to standardize
> >> them.
> >
> > Yes, I agree. But it is still beneficial at some point to be able to
> > say, "OK, we're done evaluating, we are now deciding to go with X from
> > this point on." That is what CL cannot currently do.
>
> That's correct, but I don't think that's nearly as important as you
> think it is. The community is growing, libraries are being developed and
> published, the infrastructure is improving, people are meeting to
> discuss issues, and so on, and so forth. We must be doing something
> right, right? ;)
Maybe. How many new commercial CL projects have been launched this
calendar year?
> Of course, there is always room for improvement. But things can also
> grow too fast. Apparently, the time wasn't ripe yet for something like
> CLRFI, otherwise it would have just worked (tm).
The "time not being right" is a self-fulfilling prophecy. The community
is very effective at applying pressure on e.g. vendors to conform to the
spec (witness the fate of ACL's modern mode). If the same pressure had
been applied for everyone to use CLRFI it would have worked.
rg
Ron Garret wrote:
> In article <··············@individual.net>,
> Pascal Costanza <··@p-cos.net> wrote:
>
>>>>>>> (EVAL-WHEN (LOAD-TOPLEVEL) ; or whatever the right one is -- these
>>>>>>> always confused me
>>>>>>> (SETF *NON-LAMBDA-LIST-CAR-MACRO-EXPANDER-HOOK* ...))
>>>>>> What would be the effect on code generated by macros from another
>>>>>> library? What if you use different macros of different libraries in the
>>>>>> same form? Should code generated by a macro be all the same, or is code
>>>>>> that is passed to a macro as a parameter handled differently?
>>>>> These would cause potentially harmful interactions. Much like mucking
>>>>> with *READTABLE* can do today. If either of these ever became serious
>>>>> issues they could be addressed at that time.
>>>> This is handwaving. The comparison to *readtable* doesn't hold because
>>>> after the code has been read, the setting of *readtable* doesn't have
>>>> any effect anymore.
>>> It isn't handwaving because after the code has been compiled the setting
>>> of *NON-LAMBDA-LIST-CAR-MACRO-EXPANDER-HOOK* doesn't have any effect any
>>> more.
>> What happens in code that is not compiled?
>
> It's implementation-dependent, since the spec does not specify when
> macros are expanded in that case. In theory this could cause problems,
> but since it is exceedingly rare to run library code uncompiled this is
> unlikely to be a problem in practice.
I don't think it's exceedingly rare to run uncompiled code. For
short-lived code generated at runtime, it's the best approach to run it
uncompiled.
>> What happens if I want to
>> combine macros from different libraries that use different settings for
>> your hook?
>
> Then you would compile those libraries. The code for each library would
> set the hook appropriately for that library.
Doesn't help. I want to combine macros from different libraries.
If a macro generates ((foo a b c) x y z), is the first entry supposed to
be handled according to the setting of the hook for that macro, or for
the code into which it is being generated? Does it matter whether that
code originally was a parameter for that macro, or should this happen to
any code that is generated by that macro? Does it matter whether code is
passed from one macro to another?
In other words: Do we need a reflective tower for macro expansion in
order to make it work?
>> How do I write code walkers in the face of your proposed
>> extension?
>
> The same way you do now, except that there would one additional clause
> in the central dispatcher to handle the ((...) ...) case. It would
> simply call the function bound to
> *NON-LAMBDA-LIST-CAR-MACRO-EXPANDER-HOOK* with the form as an argument
> and pass the result back to the code walker.
The hook has to be part of the compilation environment in order to be
accessible by the macro expander. If you need a reflective tower for
macros, you probably need a way to rebind the hook locally. You cannot
do this with a simple let, you rather need something like compiler-let,
but that doesn't exist in Common Lisp. So the hook probably needs to be
a symbol macro, or what?
>> Have you checked the side effects of combining your feature
>> with each and every other feature that's already part of Common Lisp?
>
> Not explicitly, no. But since this is a strictly backwards-compatible
> extension it cannot possibly cause problems for any existing correct
> code.
I don't believe it is.
>> The important thing here is that standardization is the trivial part.
>> Getting the details right is the hard part.
>
> Not in this case. This example was very carefully designed to be
> absolutely unambiguously a win. There is no possible legitimate
> technical objection to this proposal. The only possible objections are
> aesthetic.
I don't think so.
> And BTW, just so we don't lose sight of it, my objective in raising this
> point is not that I particularly want to see this extension made to CL.
> It is to demonstrate that people WILL RAISE those aesthetic objections,
> that those aesthetic objections will cause the proposal to not be
> adopted, and this therefore proves SteveY's point that CL is a religion
> with the Hyperspec as its holy text to which no alterations may be made.
My objections are not aesthetic ones.
>>>> Apparently, you would like to see standardization first, and then trying
>>>> out whether things actually work.
>>> No. Where did I say that?
>> I don't have the impression that you have thought your suggestions
>> through in all necessary details. (Maybe that's my problem.)
>
> You keep missing the process forest by focusing on the example trees.
> Just suspend your disbelief for a moment and imagine that I have thought
> through every detail and I have in fact identified a change to the
> language that for whatever reason is an unambiguous win. Now what?
Publish your extension, preferably as an implementation, and see whether
it catches on.
>> Again, I am very optimistic that the necessary infrastructure for easing
>> installation of libraries will be in place in a few years from now the
>> latest. People are actually working on the details for this.
>
> So should I give up on CL for now and try again in a few years?
> (Remember, this is a customer asking, not a member of the community.)
So you're a customer who asks for this particular extension so that the
((foo a b c) x y z) syntax works. For what purpose do you need this
extension? Maybe there is a workaround that is good enough for your
needs? For example, we could provide you with a macro that simulates a
Lisp-1 locally. Is this sufficient for your purposes?
>>>> This gives you crap like J2EE. It's
>>>> better to first try things out, and when you know that they work and
>>>> they are useful (at best by having some users) to attempt to standardize
>>>> them.
>>> Yes, I agree. But it is still beneficial at some point to be able to
>>> say, "OK, we're done evaluating, we are now deciding to go with X from
>>> this point on." That is what CL cannot currently do.
>> That's correct, but I don't think that's nearly as important as you
>> think it is. The community is growing, libraries are being developed and
>> published, the infrastructure is improving, people are meeting to
>> discuss issues, and so on, and so forth. We must be doing something
>> right, right? ;)
>
> Maybe. How many new commercial CL projects have been launched this
> calendar year?
I don't know, but I don't think the number is zero.
How many new commercial Java projects have been launched this calendar year?
>> Of course, there is always room for improvement. But things can also
>> grow too fast. Apparently, the time wasn't ripe yet for something like
>> CLRFI, otherwise it would have just worked (tm).
>
> The "time not being right" is a self-fulfilling prophecy. The community
> is very effective at applying pressure on e.g. vendors to conform to the
> spec (witness the fate of ACL's modern mode).
Modern mode is still there and is being used, as far as I can tell.
> If the same pressure had
> been applied for everyone to use CLRFI it would have worked.
I don't think so.
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
In article <··············@individual.net>,
Pascal Costanza <··@p-cos.net> wrote:
> Ron Garret wrote:
> > In article <··············@individual.net>,
> > Pascal Costanza <··@p-cos.net> wrote:
> >
> >>>>>>> (EVAL-WHEN (LOAD-TOPLEVEL) ; or whatever the right one is -- these
> >>>>>>> always confused me
> >>>>>>> (SETF *NON-LAMBDA-LIST-CAR-MACRO-EXPANDER-HOOK* ...))
> >>>>>> What would be the effect on code generated by macros from another
> >>>>>> library? What if you use different macros of different libraries in
> >>>>>> the
> >>>>>> same form? Should code generated by a macro be all the same, or is
> >>>>>> code
> >>>>>> that is passed to a macro as a parameter handled differently?
> >>>>> These would cause potentially harmful interactions. Much like mucking
> >>>>> with *READTABLE* can do today. If either of these ever became serious
> >>>>> issues they could be addressed at that time.
> >>>> This is handwaving. The comparison to *readtable* doesn't hold because
> >>>> after the code has been read, the setting of *readtable* doesn't have
> >>>> any effect anymore.
> >>> It isn't handwaving because after the code has been compiled the setting
> >>> of *NON-LAMBDA-LIST-CAR-MACRO-EXPANDER-HOOK* doesn't have any effect any
> >>> more.
> >> What happens in code that is not compiled?
> >
> > It's implementation-dependent, since the spec does not specify when
> > macros are expanded in that case. In theory this could cause problems,
> > but since it is exceedingly rare to run library code uncompiled this is
> > unlikely to be a problem in practice.
>
> I don't think it's exceedingly rare to run uncompiled code.
I didn't say it was rare to run uncompiled code. I said it was rare to
run uncompiled LIBRARY code. Please pay attention.
> >> What happens if I want to
> >> combine macros from different libraries that use different settings for
> >> your hook?
> >
> > Then you would compile those libraries. The code for each library would
> > set the hook appropriately for that library.
>
> Doesn't help. I want to combine macros from different libraries.
Then you already have potential problems if, to cite but one example,
one of those libraries starts mucking around with *MACROEXPAND-HOOK*.
> If a macro generates ((foo a b c) x y z), is the first entry supposed to
> be handled according to the setting of the hook for that macro, or for
> the code into which it is being generated? Does it matter whether that
> code originally was a parameter for that macro, or should this happen to
> any code that is generated by that macro? Does it matter whether code is
> passed from one macro to another?
>
> In other words: Do we need a reflective tower for macro expansion in
> order to make it work?
No, though I do not dispute that this feature could be used to shoot
yourself in the foot. It could also be used to produce libraries that
are mutually incompatible. But such is already the case. Either this
is livable, in which case it is not a legitimate objection to my
proposal, or it is not, in which case changes to e.g. *macroexpand-hook*
are necessary. Whatever problems there may be with my proposal, CL
already has them.
> >> How do I write code walkers in the face of your proposed
> >> extension?
> >
> > The same way you do now, except that there would one additional clause
> > in the central dispatcher to handle the ((...) ...) case. It would
> > simply call the function bound to
> > *NON-LAMBDA-LIST-CAR-MACRO-EXPANDER-HOOK* with the form as an argument
> > and pass the result back to the code walker.
>
> The hook has to be part of the compilation environment in order to be
> accessible by the macro expander. If you need a reflective tower for
> macros, you probably need a way to rebind the hook locally. You cannot
> do this with a simple let, you rather need something like compiler-let,
> but that doesn't exist in Common Lisp. So the hook probably needs to be
> a symbol macro, or what?
I have no idea. Whatever it is, the situation is equivalent to
*macroexpand-hook*.
> >> Have you checked the side effects of combining your feature
> >> with each and every other feature that's already part of Common Lisp?
> >
> > Not explicitly, no. But since this is a strictly backwards-compatible
> > extension it cannot possibly cause problems for any existing correct
> > code.
>
> I don't believe it is.
You are mistaken. As long as *NON-LAMBDA-LIST-CAR-MACRO-EXPANDER-HOOK*
is bound to a function that generates an error the behavior of the
resulting system is unchanged. (It's exactly the same as the situation
with *macroexand-hook*. As soon as you set it to something other than
funcall all bets are off.)
> >> The important thing here is that standardization is the trivial part.
> >> Getting the details right is the hard part.
> >
> > Not in this case. This example was very carefully designed to be
> > absolutely unambiguously a win. There is no possible legitimate
> > technical objection to this proposal. The only possible objections are
> > aesthetic.
>
> I don't think so.
You are mistaken.
> > And BTW, just so we don't lose sight of it, my objective in raising this
> > point is not that I particularly want to see this extension made to CL.
> > It is to demonstrate that people WILL RAISE those aesthetic objections,
> > that those aesthetic objections will cause the proposal to not be
> > adopted, and this therefore proves SteveY's point that CL is a religion
> > with the Hyperspec as its holy text to which no alterations may be made.
>
> My objections are not aesthetic ones.
Your objections are not legitimate, as they apply equally to existing
features in the language.
> >>>> Apparently, you would like to see standardization first, and then trying
> >>>> out whether things actually work.
> >>> No. Where did I say that?
> >> I don't have the impression that you have thought your suggestions
> >> through in all necessary details. (Maybe that's my problem.)
> >
> > You keep missing the process forest by focusing on the example trees.
> > Just suspend your disbelief for a moment and imagine that I have thought
> > through every detail and I have in fact identified a change to the
> > language that for whatever reason is an unambiguous win. Now what?
>
> Publish your extension, preferably as an implementation, and see whether
> it catches on.
You are missing the point again.
> >> Again, I am very optimistic that the necessary infrastructure for easing
> >> installation of libraries will be in place in a few years from now the
> >> latest. People are actually working on the details for this.
> >
> > So should I give up on CL for now and try again in a few years?
> > (Remember, this is a customer asking, not a member of the community.)
>
> So you're a customer who asks for this particular extension so that the
> ((foo a b c) x y z) syntax works. For what purpose do you need this
> extension? Maybe there is a workaround that is good enough for your
> needs? For example, we could provide you with a macro that simulates a
> Lisp-1 locally. Is this sufficient for your purposes?
No. I don't want a Lisp-1. (Been there. Done that.) I want exactly
CL, but with (funcall (...) ...) spelled ((...) ...).
> >>>> This gives you crap like J2EE. It's
> >>>> better to first try things out, and when you know that they work and
> >>>> they are useful (at best by having some users) to attempt to standardize
> >>>> them.
> >>> Yes, I agree. But it is still beneficial at some point to be able to
> >>> say, "OK, we're done evaluating, we are now deciding to go with X from
> >>> this point on." That is what CL cannot currently do.
> >> That's correct, but I don't think that's nearly as important as you
> >> think it is. The community is growing, libraries are being developed and
> >> published, the infrastructure is improving, people are meeting to
> >> discuss issues, and so on, and so forth. We must be doing something
> >> right, right? ;)
> >
> > Maybe. How many new commercial CL projects have been launched this
> > calendar year?
>
> I don't know, but I don't think the number is zero.
How about it, folks... anyone know of any commercial CL projects
launched this year?
> How many new commercial Java projects have been launched this calendar year?
Why do you keep bringing up Java? Java is a straw man. No one here is
defending Java.
> >> Of course, there is always room for improvement. But things can also
> >> grow too fast. Apparently, the time wasn't ripe yet for something like
> >> CLRFI, otherwise it would have just worked (tm).
> >
> > The "time not being right" is a self-fulfilling prophecy. The community
> > is very effective at applying pressure on e.g. vendors to conform to the
> > spec (witness the fate of ACL's modern mode).
>
> Modern mode is still there and is being used, as far as I can tell.
But it is no longer the default.
> > If the same pressure had
> > been applied for everyone to use CLRFI it would have worked.
>
> I don't think so.
We'll never know, will we? That's the problem with self-fulfilling
prophecies. They are in fact correct.
rg
Ron Garret <·········@flownet.com> writes:
> How about it, folks... anyone know of any commercial CL projects
> launched this year?
I know of at least one - mine.
In article <··············@rpi.edu>, Bill Atkins <············@rpi.edu>
wrote:
> Ron Garret <·········@flownet.com> writes:
>
> > How about it, folks... anyone know of any commercial CL projects
> > launched this year?
>
> I know of at least one - mine.
Would you mind providing a few details please?
rg
Ron Garret <·········@flownet.com> writes:
> In article <··············@rpi.edu>, Bill Atkins <············@rpi.edu>
> wrote:
>
>> Ron Garret <·········@flownet.com> writes:
>>
>> > How about it, folks... anyone know of any commercial CL projects
>> > launched this year?
>>
>> I know of at least one - mine.
>
> Would you mind providing a few details please?
>
> rg
I'm not too keen on publishing a lot of information about a
stealth-mode startup on Usenet, but I guess the technical aspects of
it are not really worth keeping secret. Roughly speaking, the product
is a Web-based application for managing small businesses in a
particular industry. The idea is a few months old, but the actual
implementation is only barely begun.
It is of course written in Common Lisp, running on SBCL with Araneida
serving pages through lighttpd. I'm using Marco Baringer's YACLML
library for generating HTML, CLSQL for database access. Development
is done in SLIME. Putting together these libraries was pretty
painless, but I suppose I would have disregarded them had they
appeared, because the sweet payoff of seeing a Lisp program come
together is IMO well worth any initial installation hassles.
I was involved in another startup earlier in the year where Lisp was
also the primary language. It fell through, though, for nontechnical
reasons. So I suppose we can add another 0.5 to the count.
Bill
Bill Atkins <············@rpi.edu> writes:
> is done in SLIME. Putting together these libraries was pretty
> painless, but I suppose I would have disregarded them had they
> appeared, because the sweet payoff of seeing a Lisp program come
Sloppy editing - "would have disregarded any hassles."
--
"...and when, another time, I discovered that he considered not
unworthy of reflection in one of those mirrors of absolute truth which
were his writings a remark similar to one which I had had occasion to
make about our friend M. Legrandin, ...then it was suddenly revealed
to me that my own humble existence and the realms of the true were
less widely separated than I had supposed, that at certain points they
actually collided, and in my newfound confidence and joy, I had wept
upon his printed page as in the arms of a long-lost father."
Bill Atkins wrote:
> Ron Garret <·········@flownet.com> writes:
>
>
>>How about it, folks... anyone know of any commercial CL projects
>>launched this year?
>
>
> I know of at least one - mine.
Two.
Ken
--
Cells: http://common-lisp.net/project/cells/
"Have you ever been in a relationship?"
Attorney for Mary Winkler, confessed killer of her
minister husband, when asked if the couple had
marital problems.
Ron Garret wrote:
> In article <··············@individual.net>,
> Pascal Costanza <··@p-cos.net> wrote:
>
>> Ron Garret wrote:
>>> In article <··············@individual.net>,
>>> Pascal Costanza <··@p-cos.net> wrote:
>>>
>>>>>>>>> (EVAL-WHEN (LOAD-TOPLEVEL) ; or whatever the right one is -- these
>>>>>>>>> always confused me
>>>>>>>>> (SETF *NON-LAMBDA-LIST-CAR-MACRO-EXPANDER-HOOK* ...))
>>>>>>>> What would be the effect on code generated by macros from another
>>>>>>>> library? What if you use different macros of different libraries in
>>>>>>>> the
>>>>>>>> same form? Should code generated by a macro be all the same, or is
>>>>>>>> code
>>>>>>>> that is passed to a macro as a parameter handled differently?
>>>>>>> These would cause potentially harmful interactions. Much like mucking
>>>>>>> with *READTABLE* can do today. If either of these ever became serious
>>>>>>> issues they could be addressed at that time.
>>>>>> This is handwaving. The comparison to *readtable* doesn't hold because
>>>>>> after the code has been read, the setting of *readtable* doesn't have
>>>>>> any effect anymore.
>>>>> It isn't handwaving because after the code has been compiled the setting
>>>>> of *NON-LAMBDA-LIST-CAR-MACRO-EXPANDER-HOOK* doesn't have any effect any
>>>>> more.
>>>> What happens in code that is not compiled?
>>> It's implementation-dependent, since the spec does not specify when
>>> macros are expanded in that case. In theory this could cause problems,
>>> but since it is exceedingly rare to run library code uncompiled this is
>>> unlikely to be a problem in practice.
>> I don't think it's exceedingly rare to run uncompiled code.
>
> I didn't say it was rare to run uncompiled code. I said it was rare to
> run uncompiled LIBRARY code. Please pay attention.
OK, sorry for that. Nevertheless, you still keep the issue with
uncompiled code.
>>>> What happens if I want to
>>>> combine macros from different libraries that use different settings for
>>>> your hook?
>>> Then you would compile those libraries. The code for each library would
>>> set the hook appropriately for that library.
>> Doesn't help. I want to combine macros from different libraries.
>
> Then you already have potential problems if, to cite but one example,
> one of those libraries starts mucking around with *MACROEXPAND-HOOK*.
To cite from the HyperSpec:
"Users or user programs can assign this variable to customize or trace
the macro expansion mechanism. Note, however, that this variable is a
global resource, potentially shared by multiple programs; as such, if
any two programs depend for their correctness on the setting of this
variable, those programs may not be able to run in the same Lisp image.
For this reason, it is frequently best to confine its uses to debugging
situations."
Your suggestion is not intended for debugging but for changing the
semantics. So this comparison doesn't hold.
"Users who put their own function into *macroexpand-hook* should
consider saving the previous value of the hook, and calling that value
from their own."
This wouldn't work in your case, as far as I can tell.
>>>> Again, I am very optimistic that the necessary infrastructure for easing
>>>> installation of libraries will be in place in a few years from now the
>>>> latest. People are actually working on the details for this.
>>> So should I give up on CL for now and try again in a few years?
>>> (Remember, this is a customer asking, not a member of the community.)
>> So you're a customer who asks for this particular extension so that the
>> ((foo a b c) x y z) syntax works. For what purpose do you need this
>> extension? Maybe there is a workaround that is good enough for your
>> needs? For example, we could provide you with a macro that simulates a
>> Lisp-1 locally. Is this sufficient for your purposes?
>
> No. I don't want a Lisp-1. (Been there. Done that.) I want exactly
> CL, but with (funcall (...) ...) spelled ((...) ...).
So for what purpose do you need this?
>>>> Of course, there is always room for improvement. But things can also
>>>> grow too fast. Apparently, the time wasn't ripe yet for something like
>>>> CLRFI, otherwise it would have just worked (tm).
>>> The "time not being right" is a self-fulfilling prophecy. The community
>>> is very effective at applying pressure on e.g. vendors to conform to the
>>> spec (witness the fate of ACL's modern mode).
>> Modern mode is still there and is being used, as far as I can tell.
>
> But it is no longer the default.
Sure, the community voted differently. You'd probably get the same
result in a sanctioned process.
>>> If the same pressure had
>>> been applied for everyone to use CLRFI it would have worked.
>> I don't think so.
>
> We'll never know, will we? That's the problem with self-fulfilling
> prophecies. They are in fact correct.
Don't tell me about self-fulfilling prophecies. You are the pessimist,
not me.
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
In article <··············@individual.net>,
Pascal Costanza <··@p-cos.net> wrote:
> > I didn't say it was rare to run uncompiled code. I said it was rare to
> > run uncompiled LIBRARY code. Please pay attention.
>
> OK, sorry for that. Nevertheless, you still keep the issue with
> uncompiled code.
Yes, I have already conceded as much. If you insist on running two
uncompiled libraries that make mutually incompatible use of
*NLLCME-HOOK* then you're screwed.
> >>>> What happens if I want to
> >>>> combine macros from different libraries that use different settings for
> >>>> your hook?
> >>> Then you would compile those libraries. The code for each library would
> >>> set the hook appropriately for that library.
> >> Doesn't help. I want to combine macros from different libraries.
> >
> > Then you already have potential problems if, to cite but one example,
> > one of those libraries starts mucking around with *MACROEXPAND-HOOK*.
>
> To cite from the HyperSpec:
>
> "Users or user programs can assign this variable to customize or trace
> the macro expansion mechanism. Note, however, that this variable is a
> global resource, potentially shared by multiple programs; as such, if
> any two programs depend for their correctness on the setting of this
> variable, those programs may not be able to run in the same Lisp image.
> For this reason, it is frequently best to confine its uses to debugging
> situations."
>
> Your suggestion is not intended for debugging but for changing the
> semantics. So this comparison doesn't hold.
>
> "Users who put their own function into *macroexpand-hook* should
> consider saving the previous value of the hook, and calling that value
> from their own."
>
> This wouldn't work in your case, as far as I can tell.
Here's the corresponding disclaimer:
"Users or programs can assign this variable to control the manner in
which ((...) ...) syntax is handled. Note, however, that this variable
is a global resource, potentially shared by multiple programs; as such,
if any two programs depend for their correctness on the setting of this
variable, those programs may not be able to run in the same Lisp image.
This problem can be ameliorated in two ways:
1. Compile your libraries so that macro expansion does not occur at run
time. Compile incompatible libraries separately, with an appropriate
compile-time setting of *NLLCME-HOOK* for each library.
2. Users who put their own function into *NLLCME-HOOK* should consider
setting it to (lambda (form) (cons 'cl:funcall form)) unless they have a
compelling reason to do something different.
> >>>> Again, I am very optimistic that the necessary infrastructure for easing
> >>>> installation of libraries will be in place in a few years from now the
> >>>> latest. People are actually working on the details for this.
> >>> So should I give up on CL for now and try again in a few years?
> >>> (Remember, this is a customer asking, not a member of the community.)
> >> So you're a customer who asks for this particular extension so that the
> >> ((foo a b c) x y z) syntax works. For what purpose do you need this
> >> extension? Maybe there is a workaround that is good enough for your
> >> needs? For example, we could provide you with a macro that simulates a
> >> Lisp-1 locally. Is this sufficient for your purposes?
> >
> > No. I don't want a Lisp-1. (Been there. Done that.) I want exactly
> > CL, but with (funcall (...) ...) spelled ((...) ...).
>
> So for what purpose do you need this?
To make a certain style of functional programming less verbose. And to
prevent people from getting confused trying to puzzle out why ((lambda
() ...) ...) works but e.g. ((if ... 'car 'cdr) ...) doesn't.
> >>>> Of course, there is always room for improvement. But things can also
> >>>> grow too fast. Apparently, the time wasn't ripe yet for something like
> >>>> CLRFI, otherwise it would have just worked (tm).
> >>> The "time not being right" is a self-fulfilling prophecy. The community
> >>> is very effective at applying pressure on e.g. vendors to conform to the
> >>> spec (witness the fate of ACL's modern mode).
> >> Modern mode is still there and is being used, as far as I can tell.
> >
> > But it is no longer the default.
>
> Sure, the community voted differently. You'd probably get the same
> result in a sanctioned process.
And your point is....?
> >>> If the same pressure had
> >>> been applied for everyone to use CLRFI it would have worked.
> >> I don't think so.
> >
> > We'll never know, will we? That's the problem with self-fulfilling
> > prophecies. They are in fact correct.
>
> Don't tell me about self-fulfilling prophecies. You are the pessimist,
> not me.
Don't confuse pessimism with a desire to change (certain aspects of) the
status quo. They are not the same thing.
rg
Ron Garret wrote:
> In article <··············@individual.net>,
> Pascal Costanza <··@p-cos.net> wrote:
>
>>> I didn't say it was rare to run uncompiled code. I said it was rare to
>>> run uncompiled LIBRARY code. Please pay attention.
>> OK, sorry for that. Nevertheless, you still keep the issue with
>> uncompiled code.
>
> Yes, I have already conceded as much. If you insist on running two
> uncompiled libraries that make mutually incompatible use of
> *NLLCME-HOOK* then you're screwed.
That would be reason enough for me to vote against this feature. Too
much fuzz for too little added value. On the other hand, generating code
at runtime and running it uncompiled for efficiency is more important.
>> So for what purpose do you need this?
>
> To make a certain style of functional programming less verbose. And to
> prevent people from getting confused trying to puzzle out why ((lambda
> () ...) ...) works but e.g. ((if ... 'car 'cdr) ...) doesn't.
You wouldn't get very far this. Programming in a higher-order functional
style doesn't only mean to return closures, but also to pass closures
around as parameters. However, for example the following code will never
do what you expect:
(defun foo (bar)
(bar ...))
In order to make this work, you need a Lisp-1.
>>>>>> Of course, there is always room for improvement. But things can also
>>>>>> grow too fast. Apparently, the time wasn't ripe yet for something like
>>>>>> CLRFI, otherwise it would have just worked (tm).
>>>>> The "time not being right" is a self-fulfilling prophecy. The community
>>>>> is very effective at applying pressure on e.g. vendors to conform to the
>>>>> spec (witness the fate of ACL's modern mode).
>>>> Modern mode is still there and is being used, as far as I can tell.
>>> But it is no longer the default.
>> Sure, the community voted differently. You'd probably get the same
>> result in a sanctioned process.
>
> And your point is....?
We have a process. You don't like its outcome. Changing the process is
not necessarily likely to change the outcome.
>>>>> If the same pressure had
>>>>> been applied for everyone to use CLRFI it would have worked.
>>>> I don't think so.
>>> We'll never know, will we? That's the problem with self-fulfilling
>>> prophecies. They are in fact correct.
>> Don't tell me about self-fulfilling prophecies. You are the pessimist,
>> not me.
>
> Don't confuse pessimism with a desire to change (certain aspects of) the
> status quo. They are not the same thing.
If I understand you correctly, what you are saying is that if the Common
Lisp community doesn't change in a certain way, it will perish. I call
that pessimism.
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
Pascal Costanza <··@p-cos.net> writes:
> You wouldn't get very far this. Programming in a higher-order
> functional style doesn't only mean to return closures, but also to
> pass closures around as parameters. However, for example the following
> code will never do what you expect:
>
> (defun foo (bar)
> (bar ...))
>
> In order to make this work, you need a Lisp-1.
Bah, all you need to write is:
(defun foo (bar)
((identity bar) ...))
which is infinitely better than using funcall, apparently.
--
/|_ .-----------------------.
,' .\ / | Free Mumia Abu-Jamal! |
,--' _,' | Abolish the racist |
/ / | death penalty! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'
In article <··············@individual.net>,
Pascal Costanza <··@p-cos.net> wrote:
> Ron Garret wrote:
> > In article <··············@individual.net>,
> > Pascal Costanza <··@p-cos.net> wrote:
> >
> >>> I didn't say it was rare to run uncompiled code. I said it was rare to
> >>> run uncompiled LIBRARY code. Please pay attention.
> >> OK, sorry for that. Nevertheless, you still keep the issue with
> >> uncompiled code.
> >
> > Yes, I have already conceded as much. If you insist on running two
> > uncompiled libraries that make mutually incompatible use of
> > *NLLCME-HOOK* then you're screwed.
>
> That would be reason enough for me to vote against this feature. Too
> much fuzz for too little added value.
Too little added value for you, or too little value added for everyone?
In other words, are you assessing the value to yourself alone, or the
value to every potential user of CL now and in the future?
> On the other hand, generating code
> at runtime and running it uncompiled for efficiency is more important.
UNcompiled for efficiency? Huh?
> >> So for what purpose do you need this?
> >
> > To make a certain style of functional programming less verbose. And to
> > prevent people from getting confused trying to puzzle out why ((lambda
> > () ...) ...) works but e.g. ((if ... 'car 'cdr) ...) doesn't.
>
> You wouldn't get very far this. Programming in a higher-order functional
> style doesn't only mean to return closures, but also to pass closures
> around as parameters. However, for example the following code will never
> do what you expect:
>
> (defun foo (bar)
> (bar ...))
>
> In order to make this work, you need a Lisp-1.
Not so. I can think of many ways to make this work without a Lisp-1.
> >>>>>> Of course, there is always room for improvement. But things can also
> >>>>>> grow too fast. Apparently, the time wasn't ripe yet for something like
> >>>>>> CLRFI, otherwise it would have just worked (tm).
> >>>>> The "time not being right" is a self-fulfilling prophecy. The
> >>>>> community
> >>>>> is very effective at applying pressure on e.g. vendors to conform to
> >>>>> the
> >>>>> spec (witness the fate of ACL's modern mode).
> >>>> Modern mode is still there and is being used, as far as I can tell.
> >>> But it is no longer the default.
> >> Sure, the community voted differently. You'd probably get the same
> >> result in a sanctioned process.
> >
> > And your point is....?
>
> We have a process. You don't like its outcome.
True, but I think you are mistaken about the aspect of the outcome I
don't like. You think that the aspect of the outcome I don't like is
that my proposals aren't adopted. You are wrong. The aspect of the
outcome that I don't like is that Lisp is not economically viable.
> >>>>> If the same pressure had
> >>>>> been applied for everyone to use CLRFI it would have worked.
> >>>> I don't think so.
> >>> We'll never know, will we? That's the problem with self-fulfilling
> >>> prophecies. They are in fact correct.
> >> Don't tell me about self-fulfilling prophecies. You are the pessimist,
> >> not me.
> >
> > Don't confuse pessimism with a desire to change (certain aspects of) the
> > status quo. They are not the same thing.
>
> If I understand you correctly, what you are saying is that if the Common
> Lisp community doesn't change in a certain way, it will perish.
No, that is not what I am saying. Lisp will surely not perish. But I
don't think it is likely to thrive without change.
> I call that pessimism.
And what do you call the tendency to put the worst possibly spin on
someone else's words?
rg
Ron Garret <·········@flownet.com> writes:
> In article <··············@individual.net>,
> Pascal Costanza <··@p-cos.net> wrote:
>
>> Ron Garret wrote:
>> > In article <··············@individual.net>,
>> > Pascal Costanza <··@p-cos.net> wrote:
>> >
>> >>> I didn't say it was rare to run uncompiled code. I said it was rare to
>> >>> run uncompiled LIBRARY code. Please pay attention.
>> >> OK, sorry for that. Nevertheless, you still keep the issue with
>> >> uncompiled code.
>> >
>> > Yes, I have already conceded as much. If you insist on running two
>> > uncompiled libraries that make mutually incompatible use of
>> > *NLLCME-HOOK* then you're screwed.
>>
>> That would be reason enough for me to vote against this feature. Too
>> much fuzz for too little added value.
>
> Too little added value for you, or too little value added for everyone?
> In other words, are you assessing the value to yourself alone, or the
> value to every potential user of CL now and in the future?
>
>> On the other hand, generating code
>> at runtime and running it uncompiled for efficiency is more important.
>
> UNcompiled for efficiency? Huh?
This is not so strange. Optimizing compilers can spend a lot of time
getting the compilation right - if you're generating throwaway code
then shaving off the overhead of compilation could be useful.
>
>> >> So for what purpose do you need this?
>> >
>> > To make a certain style of functional programming less verbose. And to
>> > prevent people from getting confused trying to puzzle out why ((lambda
>> > () ...) ...) works but e.g. ((if ... 'car 'cdr) ...) doesn't.
>>
>> You wouldn't get very far this. Programming in a higher-order functional
>> style doesn't only mean to return closures, but also to pass closures
>> around as parameters. However, for example the following code will never
>> do what you expect:
>>
>> (defun foo (bar)
>> (bar ...))
>>
>> In order to make this work, you need a Lisp-1.
>
> Not so. I can think of many ways to make this work without a Lisp-1.
I haven't been following this, but has anyone brought up the idea of a
WITHOUT-FUNCALLS type macro where code walker could replace these
forms with FUNCALL's? You'd have to localize this "feature" to
specific code blocks, of course, but does that solve your problem?
>
>> >>>>>> Of course, there is always room for improvement. But things can also
>> >>>>>> grow too fast. Apparently, the time wasn't ripe yet for something like
>> >>>>>> CLRFI, otherwise it would have just worked (tm).
>> >>>>> The "time not being right" is a self-fulfilling prophecy. The
>> >>>>> community
>> >>>>> is very effective at applying pressure on e.g. vendors to conform to
>> >>>>> the
>> >>>>> spec (witness the fate of ACL's modern mode).
>> >>>> Modern mode is still there and is being used, as far as I can tell.
>> >>> But it is no longer the default.
>> >> Sure, the community voted differently. You'd probably get the same
>> >> result in a sanctioned process.
>> >
>> > And your point is....?
>>
>> We have a process. You don't like its outcome.
>
> True, but I think you are mistaken about the aspect of the outcome I
> don't like. You think that the aspect of the outcome I don't like is
> that my proposals aren't adopted. You are wrong. The aspect of the
> outcome that I don't like is that Lisp is not economically viable.
>
>
>> >>>>> If the same pressure had
>> >>>>> been applied for everyone to use CLRFI it would have worked.
>> >>>> I don't think so.
>> >>> We'll never know, will we? That's the problem with self-fulfilling
>> >>> prophecies. They are in fact correct.
>> >> Don't tell me about self-fulfilling prophecies. You are the pessimist,
>> >> not me.
>> >
>> > Don't confuse pessimism with a desire to change (certain aspects of) the
>> > status quo. They are not the same thing.
>>
>> If I understand you correctly, what you are saying is that if the Common
>> Lisp community doesn't change in a certain way, it will perish.
>
> No, that is not what I am saying. Lisp will surely not perish. But I
> don't think it is likely to thrive without change.
>
>> I call that pessimism.
>
> And what do you call the tendency to put the worst possibly spin on
> someone else's words?
A Ron Garret?
--
"...and when, another time, I discovered that he considered not
unworthy of reflection in one of those mirrors of absolute truth which
were his writings a remark similar to one which I had had occasion to
make about our friend M. Legrandin, ...then it was suddenly revealed
to me that my own humble existence and the realms of the true were
less widely separated than I had supposed, that at certain points they
actually collided, and in my newfound confidence and joy, I had wept
upon his printed page as in the arms of a long-lost father."
Ron Garret wrote:
> In article <··············@individual.net>,
> Pascal Costanza <··@p-cos.net> wrote:
>
> > Ron Garret wrote:
> > > In article <··············@individual.net>,
> > > Pascal Costanza <··@p-cos.net> wrote:
> > >
> > >>> I didn't say it was rare to run uncompiled code. I said it was rare to
> > >>> run uncompiled LIBRARY code. Please pay attention.
> > >> OK, sorry for that. Nevertheless, you still keep the issue with
> > >> uncompiled code.
> > >
> > > Yes, I have already conceded as much. If you insist on running two
> > > uncompiled libraries that make mutually incompatible use of
> > > *NLLCME-HOOK* then you're screwed.
> >
> > That would be reason enough for me to vote against this feature. Too
> > much fuzz for too little added value.
>
> Too little added value for you, or too little value added for everyone?
> In other words, are you assessing the value to yourself alone, or the
> value to every potential user of CL now and in the future?
What kind of question is that? I could ask the same about your
suggestion to add this feature.
"More added value for you, or more added value for everyone? In other
words, are you assessing the value to yourself alone, or the value to
every potential user of CL now and in the future?"
This is a public forum, right?
> > On the other hand, generating code
> > at runtime and running it uncompiled for efficiency is more important.
>
> UNcompiled for efficiency? Huh?
If you generate code at runtime, the time it takes to compile it is
additional overhead and has to be added to the time it takes to
actually execute it. The sum must be smaller than the time it takes to
just interpret it in order to be a net win.
> > We have a process. You don't like its outcome.
>
> True, but I think you are mistaken about the aspect of the outcome I
> don't like. You think that the aspect of the outcome I don't like is
> that my proposals aren't adopted. You are wrong. The aspect of the
> outcome that I don't like is that Lisp is not economically viable.
You are wrong. I understand what you don't like, I just think that what
you seem to be suggesting would make a big difference. (And contrary to
you I think the examples do matter.)
> > >> Don't tell me about self-fulfilling prophecies. You are the pessimist,
> > >> not me.
> > >
> > > Don't confuse pessimism with a desire to change (certain aspects of) the
> > > status quo. They are not the same thing.
> >
> > If I understand you correctly, what you are saying is that if the Common
> > Lisp community doesn't change in a certain way, it will perish.
>
> No, that is not what I am saying. Lisp will surely not perish. But I
> don't think it is likely to thrive without change.
>
> > I call that pessimism.
>
> And what do you call the tendency to put the worst possibly spin on
> someone else's words?
To quote from a few of your postings:
"[...] some parts of Common Lisp really do suck, and unless they are
fixed a lot of people -- myself included -- won't be able to use it
even though they may want to really badly."
"Inaccessibility will not outright kill Lisp, but it will reduce the
number of new users, which shrinks the Lisp economy, which is a bad
thing IMO."
...and...
>> - Do you agree that the fact that the situation is better than five
>> years ago indicate that things are improving?
>
> If they are improving, the pace is glacial.
>
>> - Why should this all suddenly stop?
>
> Because the current burst of exuberance could abate once reality sets in?
I call this pessimism. The situation is much better than that.
Pascal
In article <························@v46g2000cwv.googlegroups.com>,
"Pascal Costanza" <··@p-cos.net> wrote:
> Ron Garret wrote:
> > In article <··············@individual.net>,
> > Pascal Costanza <··@p-cos.net> wrote:
> >
> > > Ron Garret wrote:
> > > > In article <··············@individual.net>,
> > > > Pascal Costanza <··@p-cos.net> wrote:
> > > >
> > > >>> I didn't say it was rare to run uncompiled code. I said it was rare
> > > >>> to
> > > >>> run uncompiled LIBRARY code. Please pay attention.
> > > >> OK, sorry for that. Nevertheless, you still keep the issue with
> > > >> uncompiled code.
> > > >
> > > > Yes, I have already conceded as much. If you insist on running two
> > > > uncompiled libraries that make mutually incompatible use of
> > > > *NLLCME-HOOK* then you're screwed.
> > >
> > > That would be reason enough for me to vote against this feature. Too
> > > much fuzz for too little added value.
> >
> > Too little added value for you, or too little value added for everyone?
> > In other words, are you assessing the value to yourself alone, or the
> > value to every potential user of CL now and in the future?
>
> What kind of question is that?
The kind that would expose the bankruptcy of your position if you would
actually answer it.
> I could ask the same about your suggestion to add this feature.
I have already answered it. Several times.
> > > On the other hand, generating code
> > > at runtime and running it uncompiled for efficiency is more important.
> >
> > UNcompiled for efficiency? Huh?
>
> If you generate code at runtime, the time it takes to compile it is
> additional overhead and has to be added to the time it takes to
> actually execute it. The sum must be smaller than the time it takes to
> just interpret it in order to be a net win.
That is absolutely false. You are tacitly assuming that the code only
runs once, that the compile time is significant, that run-time is your
only performance metric, and probably half a dozen other things.
> > > We have a process. You don't like its outcome.
> >
> > True, but I think you are mistaken about the aspect of the outcome I
> > don't like. You think that the aspect of the outcome I don't like is
> > that my proposals aren't adopted. You are wrong. The aspect of the
> > outcome that I don't like is that Lisp is not economically viable.
>
> You are wrong. I understand what you don't like,
I doubt that very much.
rg
Ron Garret <·········@flownet.com> writes:
> In article <························@v46g2000cwv.googlegroups.com>,
> "Pascal Costanza" <··@p-cos.net> wrote:
>
>> Ron Garret wrote:
>> > UNcompiled for efficiency? Huh?
>>
>> If you generate code at runtime, the time it takes to compile it is
>> additional overhead and has to be added to the time it takes to
>> actually execute it. The sum must be smaller than the time it takes to
>> just interpret it in order to be a net win.
> That is absolutely false. You are tacitly assuming that the code
> only runs once,
Before you go flinging around phrases like "absolutely false", you
should look again at what he said. He didn't say anything about how
many times it would be run; he merely posited some "time it takes to
just interpret it". That could be running the code once or a million
times.
> that the compile time is significant,
Well that's sort of the question isn't it? Whether
(> (+ compile-time run-time-of-compiled-code) run-time-of-uncompiled-code)
> that run-time is your only performance metric,
Yes. Though it is hardly unheared of, in the field of programming, for
the unqualified term "efficiency" to be understood as having to do
with speed of execution. Since you bring it up, do you have some other
measure of "efficiency" for which compiling generated code is *always*
a win?
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
In article <··············@gigamonkeys.com>,
Peter Seibel <·····@gigamonkeys.com> wrote:
> Ron Garret <·········@flownet.com> writes:
>
> > In article <························@v46g2000cwv.googlegroups.com>,
> > "Pascal Costanza" <··@p-cos.net> wrote:
> >
> >> Ron Garret wrote:
>
> >> > UNcompiled for efficiency? Huh?
> >>
> >> If you generate code at runtime, the time it takes to compile it is
> >> additional overhead and has to be added to the time it takes to
> >> actually execute it. The sum must be smaller than the time it takes to
> >> just interpret it in order to be a net win.
>
> > That is absolutely false. You are tacitly assuming that the code
> > only runs once,
>
> Before you go flinging around phrases like "absolutely false", you
> should look again at what he said. He didn't say anything about how
> many times it would be run; he merely posited some "time it takes to
> just interpret it". That could be running the code once or a million
> times.
Can you show me a piece of code that takes a million times longer to
compile than to interpret?
> > that the compile time is significant,
>
> Well that's sort of the question isn't it? Whether
>
> (> (+ compile-time run-time-of-compiled-code) run-time-of-uncompiled-code)
>
> > that run-time is your only performance metric,
>
> Yes. Though it is hardly unheared of, in the field of programming, for
> the unqualified term "efficiency" to be understood as having to do
> with speed of execution. Since you bring it up, do you have some other
> measure of "efficiency" for which compiling generated code is *always*
> a win?
OK, I was too hasty when I wrote that. What I had in mind was that
end-to-end run time does not necessarily correlate with the number of
processor cycles it takes to execute the code. Memory usage, for
example, can be significant. If your code takes half as many cycles but
consumes twice as much memory it might actually run ten times slower (or
makes other parts of the system run ten times slower).
(Yes, I know that the compiler consumes memory too. I use MCL, whose
compiler is so small and fast that the only time it interprets code is
when you're single-stepping.)
rg
Ron Garret <·········@flownet.com> writes:
> In article <··············@gigamonkeys.com>,
> Peter Seibel <·····@gigamonkeys.com> wrote:
>
>> Ron Garret <·········@flownet.com> writes:
>> > That is absolutely false. You are tacitly assuming that the code
>> > only runs once,
>>
>> Before you go flinging around phrases like "absolutely false", you
>> should look again at what he said. He didn't say anything about how
>> many times it would be run; he merely posited some "time it takes
>> to just interpret it". That could be running the code once or a
>> million times.
>
> Can you show me a piece of code that takes a million times longer to
> compile than to interpret?
Nope. Luckily that has no effect on my point.
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
Ron Garret <·········@flownet.com> wrote:
> Can you show me a piece of code that takes a million times longer to
> compile than to interpret?
Sure.
(defun make-tree (vars n)
(if (zerop n)
`(if (< ,(car vars) ,n)
t
nil)
`(if (< ,(car vars) ,n)
,(make-tree vars (1- n))
,(make-tree (cdr vars) (1- n)))))
(defun make-tree-fun (n)
(let ((vars (loop repeat (1+ n) collect (gensym))))
`(lambda (skip &optional ,@vars)
(unless skip
,(make-tree vars n)))))
(let ((fun (eval (make-tree-fun 12))))
(time (funcall fun t))
(time (funcall (compile nil fun) t)))
Adjust N to taste. With clisp 2.38 I get a time of 0.0 seconds for
interpreted version and 52 seconds for the compiled one. This is, of
course, a completely artifical example, but that's what you get when
you ask for a factor of a million.
But the issue of evaluator vs. compiler speed is not just theoretical,
there are real-life programs where this matters. Even though as a
developer of a compiler-only CL implementation I wish it weren't so...
--
Juho Snellman
On Sun, 23 Apr 2006 22:40:43 +0000, Juho Snellman wrote:
>
> Ron Garret <·········@flownet.com> wrote:
>> Can you show me a piece of code that takes a million times longer to
>> compile than to interpret?
>
> Sure.
>
> (defun make-tree (vars n)
> (if (zerop n)
> `(if (< ,(car vars) ,n)
> t
> nil)
> `(if (< ,(car vars) ,n)
> ,(make-tree vars (1- n))
> ,(make-tree (cdr vars) (1- n)))))
>
>
> (defun make-tree-fun (n)
> (let ((vars (loop repeat (1+ n) collect (gensym))))
> `(lambda (skip &optional ,@vars)
> (unless skip
> ,(make-tree vars n)))))
>
> (let ((fun (eval (make-tree-fun 12))))
> (time (funcall fun t))
> (time (funcall (compile nil fun) t)))
>
> Adjust N to taste. With clisp 2.38 I get a time of 0.0 seconds for
> interpreted version and 52 seconds for the compiled one.
Is this because the compiler has to generate code for all the branches
whether they are taken or not?
Matt
--
"You do not really understand something unless you can
explain it to your grandmother." - Albert Einstein.
Ron Garret wrote:
>> If you generate code at runtime, the time it takes to compile it is
>> additional overhead and has to be added to the time it takes to
>> actually execute it. The sum must be smaller than the time it takes to
>> just interpret it in order to be a net win.
>
> That is absolutely false. You are tacitly assuming that the code only
> runs once, that the compile time is significant, that run-time is your
> only performance metric, and probably half a dozen other things.
No, I am not making these assumptions. Look up "dynamic compilation" in
google. BTW, you have actually worked for one of the guys who has
pioneered some of the techniques in this area.
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
Some entity AKA "Pascal Costanza" <··@p-cos.net>
wrote this mindboggling stuff:
(selectively-snipped-or-not-p)
> > And what do you call the tendency to put the worst possibly spin on
> > someone else's words?
>
> To quote from a few of your postings:
>
> "[...] some parts of Common Lisp really do suck, and unless they are
> fixed a lot of people -- myself included -- won't be able to use it
> even though they may want to really badly."
>
> "Inaccessibility will not outright kill Lisp, but it will reduce the
> number of new users, which shrinks the Lisp economy, which is a bad
> thing IMO."
>
> ...and...
>
> >> - Do you agree that the fact that the situation is better than five
> >> years ago indicate that things are improving?
> >
> > If they are improving, the pace is glacial.
> >
> >> - Why should this all suddenly stop?
> >
> > Because the current burst of exuberance could abate once reality sets in?
>
>
> I call this pessimism. The situation is much better than that.
No Pascal, I do no think this is pessimism, fear is more likely.
Allready there is a broad independant movement in the ICT world that
has cut their shackles and enjoys their freedom to do their
things their way in a unencumbered way.
Ofcourse there are frictions on issues but these are just minor
nuisances at best.
And reality allready has set in.
Now that CL, a very powerfull tool, is started moving in the same
direction of freedom from the dictates of the powers that be,
this action is very frightening to those powers.
Surely this is a real economically frightening reallity to them.
The more diversity there is the less chance there will be that users
and the commercial providers of CL will be driven to a submissive state
were tools and methods will be dictated only to serve some usurpator's
biddings and coffers.
I do not think anyone would really like to see that happen.
Cor
--
I do NOT use any Windows(TM) products, therefore
I do NOT fear mail from strangers http://www.clsnet.nl/mail.html
If everything else failed to satisfy you, try reading The Frign' Manual
(defvar My-Computer '((OS . "GNU/Emacs") (IPL . "GNU/Linux")))
Ron Garret <·········@flownet.com> writes:
> IMO, just having the ability to (semi-)officially deprecate cruft, even
> if it never actually goes away, I think would have enormous payoffs.
> But we don't currently have that ability.
> Yes there is: it makes life VASTLY easier for newcomers if the actual
> language (as opposed to someone's private library) is not full of random
> crap.
> This, by the way, is the crux of SteveY's point. It often gets
> overlooked so it bears repeating: it's all about how accessible the
> language is to newcomers. If the language is full of random crap then
> it becomes less accessible to newcomers. A library that covers up the
> crap doesn't help nearly as much as actually cleaning the crap up.
Have you missed that almost no one agrees with you on what is "crap"
in CL? Short of making yourself benevolent dictator etc. for CL, I
don't see how "we" being able to change the language would make you
any happier in the end.
Bj�rn
In article <···············@muvclx01.cadence.com>,
·····@runa.se (Bj�rn Lindberg) wrote:
> Ron Garret <·········@flownet.com> writes:
>
> > IMO, just having the ability to (semi-)officially deprecate cruft, even
> > if it never actually goes away, I think would have enormous payoffs.
> > But we don't currently have that ability.
>
> > Yes there is: it makes life VASTLY easier for newcomers if the actual
> > language (as opposed to someone's private library) is not full of random
> > crap.
>
> > This, by the way, is the crux of SteveY's point. It often gets
> > overlooked so it bears repeating: it's all about how accessible the
> > language is to newcomers. If the language is full of random crap then
> > it becomes less accessible to newcomers. A library that covers up the
> > crap doesn't help nearly as much as actually cleaning the crap up.
>
> Have you missed that almost no one agrees with you on what is "crap"
> in CL?
Doesn't matter. The fact is that a lot of people agree *that* there is
(I am going to belatedly attempt to switch to more polite terminology)
historical baggage in CL. Whether or not the particular examples I
picked are the same as what the community would identify is irrelevant.
> Short of making yourself benevolent dictator etc. for CL,
<shudder>
> I don't see how "we" being able to change the language would make you
> any happier in the end.
Here's how I can write an HTTP client in Python:
import urllib
def urlget(url):
s = urllib.urlopen(url)
s1 = s.read()
s.close
return s1
This works in Python "out of the box".
To do this in CL I have to first find and install an HTTP client
library, which probably means I have to find and install ASDF and UFFI,
all of which may or may not work with the Lisp I'm using (because UFFI
isn't). And then if I later decide I need threads and I happen to be
using CLisp then I have to start all over again from the beginning.
Having the ability to canonicalize (I don't want to say standardize
because that is a loaded word here) changes to the language would open
up the possibility that I could write an HTTP client in Lisp with the
same ease as I can currently write one in Python. Being able to do that
would, I believe, attract more new users. Having more CL users would
open up the possibility that the world will some day realize the
horrible folly of XML and it will be abandoned in favor of
S-expressions. And no longer having to deal with XML would make me
very, very happy.
For example.
rg
Ron
If you're talking re libraries packed and ready to work out-of-box I'm
100%
behind you and I feel that all of the Gates kids like me agree.
Read my post above.
bobi
http://blazeski.blogspot.com/
Ron Garret wrote:
> In article <················@fe11.lga>,
> Ken Tilton <·········@gmail.com> wrote:
>
>
>>Shoo! Go away!
>
>
> Everybody pay attention to Kenny. He knows exactly how to attract new
> users.
Thanks, Ron. I try. I was happy to see Mr. Yegge (your inspiration) cite
my "Road to Lisp Survey" as common knowledge. That was quite a lot of
work, especially when the yobbos threw it off Cliki as "non-free". <sigh>
As for all the Lisp drinking societies out there, yeah, I was a
co-founder of the first, but Marco Antoniotti should get the credit. And
to be honest, I was just there for the beer and camaraderie, who knew it
would attract more noobs than Lispniks? That has been the LispNYC
experience, anyway.
I have to admit my free educational "Lisp With Kenny" never got far, but
I tried and it did lead to a connection which led to another which
became the LispNYC music sig.
But with most of your antagonists this time, what matters is code, code,
and code. I think my biggest contribution has been in open source,
combined with the Google SoC '05.
While you and your sorry band are polluting usenet, some of us are
creating bindings to cool libraries. Edi, Marc, and now I see noobs
putting up libs. How cools is that?
For SoC I proposed and mentored a project which became Lusi Oliveira's
rounding out of James Bielman's CFFI. I notice you are not whining about
non-standard FFI this time around. Guess why. [btw, yeah, I proposed it,
but Luis did an amazing job, and James not only gave him a good start
but also helped tremendously -- I actually did nothing but read progress
reports.]
Verazzano, the other project, succeeded in automatically generating CFFI
(and potentially other, but why?) bindings for /any/ C/C++ library. That
project could be picked up if Swig is not fulfilling that role (or if we
like the idea of a pure Lisp solution). Those two, CFFI and Vzn, squash
like a bug the whole "no libraries" whine, tho it makes only C/C++
effectively also Lisp libraries. Fortunately a few got written before
Java blocked out the sun.
Another proposal was for cl-sockets, which but for pilot error would
have been (well, perhaps merely only begun) the elimination of another
of your whines.
As for "where's the GUI?", I have recently released my second take at
blending Cells and LTk, and I am using it (Celtk) for commercial
development. The nice thing about Tcl/Tk is that it pulls in non-GUI
portability, such as taking file directories. And now that I am
programming a Real Application all day using Cells, uh-oh, looks like I
undersold the damn thing. I cannot believe how fast this very complex
app is coming together (and I should know, because I am redoing from
scratch what I wrote in 100kloc of "C" before my salvation.)
It is surprising I have time to hang out here on c.l.l. and help newbies
with their code, but their questions are usually easy and I used to be a
teacher and I always enjoy helping people enjoy the things I enjoy, so
it is a nice break from programming all day.
Now cheer up, you are being a total buzz-kill. You pose as a champion of
newbies, while doing nothing to improve their lot. I do not even see you
educating noobs on c.l.l. tsk tsk.
Why not resurrect Verrazano? It's author has gone MIA. I do not want to
screw with Swig. Thanks.
ken
--
Cells: http://common-lisp.net/project/cells/
"Have you ever been in a relationship?"
Attorney for Mary Winkler, confessed killer of her
minister husband, when asked if the couple had
marital problems.
In article <·················@fe12.lga>,
Ken Tilton <·········@gmail.com> wrote:
> As for all the Lisp drinking societies out there,
Oh, thanks for reminding me.
Start a Lisp user group? Yeah, been there, done that too. (Alas, CRACL
has since died for lack of interest.)
rg
Ron Garret wrote:
> In article <·················@fe12.lga>,
> Ken Tilton <·········@gmail.com> wrote:
>
>
>>As for all the Lisp drinking societies out there,
>
>
> Oh, thanks for reminding me.
>
> Start a Lisp user group? Yeah, been there, done that too. (Alas, CRACL
> has since died for lack of interest.)
Oh shut up and go get Pfc Shrager who followed you into this train wreck
you call Lisp advocacy. The Savages of c.l.l. left him for dead, see
what you can do for him.
ken
--
Cells: http://common-lisp.net/project/cells/
"Have you ever been in a relationship?"
Attorney for Mary Winkler, confessed killer of her
minister husband, when asked if the couple had
marital problems.
Ron Garret wrote:
> In article <·················@fe12.lga>,
> Ken Tilton <·········@gmail.com> wrote:
>
>> As for all the Lisp drinking societies out there,
>
> Oh, thanks for reminding me.
>
> Start a Lisp user group? Yeah, been there, done that too. (Alas, CRACL
> has since died for lack of interest.)
>
> rg
I am sure you were the life of the party Ron.
Act I - First CRACL Meeting
Moderator: "Welcome Everyone! Perhaps we could start by introducing
ourselves and say something about our experiences
with Lisp, and what we would like to happen."
Bob J. Niceguy: "Hi I'm Bob. Been using Lisp for about 2 years.
Wrote a little program for teaching my kids
math. Lisp is great, looking forward to learning
more."
Ron Garret: "Hi I'm Ron. Lisp has wrecked me a programmer. I was
black-balled at my job for using it. I am here to
talk about how Lisp sucks. Hopefully enough of you
will feel the same to get enthused about it."
Jane Cobol: "Be right back, just have to go to the restroom"
Act II - Next Meeting
Ron Garret: "Hey where is everybody?"
....
Marvin in Hitch Hikers Guide To The Galaxy has nothing on you Ron.
Wade
Wade Humeniuk wrote:
> Ron Garret wrote:
>
>> In article <·················@fe12.lga>,
>> Ken Tilton <·········@gmail.com> wrote:
>>
>>> As for all the Lisp drinking societies out there,
>>
>>
>> Oh, thanks for reminding me.
>>
>> Start a Lisp user group? Yeah, been there, done that too. (Alas,
>> CRACL has since died for lack of interest.)
>>
>> rg
>
>
> I am sure you were the life of the party Ron.
>
> Act I - First CRACL Meeting
>
> Moderator: "Welcome Everyone! Perhaps we could start by introducing
> ourselves and say something about our experiences
> with Lisp, and what we would like to happen."
>
> Bob J. Niceguy: "Hi I'm Bob. Been using Lisp for about 2 years.
> Wrote a little program for teaching my kids
> math. Lisp is great, looking forward to learning
> more."
>
> Ron Garret: "Hi I'm Ron. Lisp has wrecked me a programmer. I was
> black-balled at my job for using it. I am here to
> talk about how Lisp sucks. Hopefully enough of you
> will feel the same to get enthused about it."
>
"And now it's time for the Kool-Aid drinking practice...."
:)
ken
--
Cells: http://common-lisp.net/project/cells/
"Have you ever been in a relationship?"
Attorney for Mary Winkler, confessed killer of her
minister husband, when asked if the couple had
marital problems.
Ken Tilton <·········@gmail.com> wrote:
[...]
>
> It is surprising I have time to hang out here on c.l.l. and help newbies
> with their code, but their questions are usually easy and I used to be a
> teacher and I always enjoy helping people enjoy the things I enjoy, so
> it is a nice break from programming all day.
And we appreciate it... If I started mentioning names I'd
unintentionaly leave someone out. You know who you are. Thank you!
>
> Now cheer up, you are being a total buzz-kill. You pose as a champion of
> newbies, while doing nothing to improve their lot. I do not even see you
> educating noobs on c.l.l. tsk tsk.
>
Ron's not a total buzz-kill. I've been programming for 30 years and,
while Lisp isn't perfect, I wish I had learned it a lot sooner. I'm
enjoying it, warts and all. It may be that in a little while I'll want
to port Lisp to a Linux-MIPS platform (but I'm nowhere near capable,
yet), and will take a huge interest in threading, graphics, and
interfaces to other languages. But for now, to co-opt BBEdit's motto:
Lisp sucks less. IMO, YMMV.
--
NewsGuy.Com 30Gb $9.95 Carry Forward and On Demand Bandwidth
>>>>> "Bob" == Bob Felts <····@stablecross.com> writes:
Bob> a lot sooner. I'm enjoying it, warts and all. It may be
Bob> that in a little while I'll want to port Lisp to a Linux-MIPS
Bob> platform (but I'm nowhere near capable, yet), and will take a
I don't use a MIPS platform, but Debian claims to have sbcl on MIPS
(big and little endian). Debian does not make such claims lightly....
http://packages.debian.org/stable/devel/sbcl
Cheers!
Shyamal
Bob Felts wrote:
> Ken Tilton <·········@gmail.com> wrote:
>
> [...]
>
>
>>It is surprising I have time to hang out here on c.l.l. and help newbies
>>with their code, but their questions are usually easy and I used to be a
>>teacher and I always enjoy helping people enjoy the things I enjoy, so
>>it is a nice break from programming all day.
>
>
> And we appreciate it... If I started mentioning names I'd
> unintentionaly leave someone out. You know who you are. Thank you!
The best thing is how much I learn myself from these exchanges.
>
>
>>Now cheer up, you are being a total buzz-kill. You pose as a champion of
>>newbies, while doing nothing to improve their lot. I do not even see you
>>educating noobs on c.l.l. tsk tsk.
>>
>
>
> Ron's not a total buzz-kill.
Tell me that again after you have thru two or three more of his
semi-annual wrist-slitting orgies. :)
> I've been programming for 30 years and,
> while Lisp isn't perfect, I wish I had learned it a lot sooner. I'm
> enjoying it, warts and all. It may be that in a little while I'll want
> to port Lisp to a Linux-MIPS platform (but I'm nowhere near capable,
> yet), and will take a huge interest in threading, graphics, and
> interfaces to other languages.
Sounds like you are prepared to <gasp!> Write Code. That's all we ask.
ken
--
Cells: http://common-lisp.net/project/cells/
"Have you ever been in a relationship?"
Attorney for Mary Winkler, confessed killer of her
minister husband, when asked if the couple had
marital problems.
Ken Tilton <·········@gmail.com> wrote:
> Bob Felts wrote:
[...]
> >
> > Ron's not a total buzz-kill.
>
> Tell me that again after you have thru two or three more of his
> semi-annual wrist-slitting orgies. :)
>
Ron's complaints aren't any different from those I've heard about other
languages at other times. I agree with him that Lisp isn't perfect.
> > I've been programming for 30 years and,
> > while Lisp isn't perfect, I wish I had learned it a lot sooner. I'm
> > enjoying it, warts and all. It may be that in a little while I'll want
> > to port Lisp to a Linux-MIPS platform (but I'm nowhere near capable,
> > yet), and will take a huge interest in threading, graphics, and
> > interfaces to other languages.
>
> Sounds like you are prepared to <gasp!> Write Code. That's all we ask.
>
I am, and I've fallen in love with programming all over again.
Sometimes we forget what caused us to fall in love in the first place.
;-)
--
NewsGuy.Com 30Gb $9.95 Carry Forward and On Demand Bandwidth
Bob Felts wrote:
> I am, and I've fallen in love with programming all over again.
> Sometimes we forget what caused us to fall in love in the first place.
Yep. I'll put you in the RtL Highlight Film under "The Hedonsists", not
too close to Doug Tolton so it does not sound like a me-too.
ken
ps. The great thing about this exchange is how much I learned about
possible Web application stacks. And it was great seeing not one but two
specifications for a cl-sockets package. Coming up with that was our
first concern during SoC 2005.
No one has to sell me on the need, hell, I am the one writing code
precisely to fill in those check boxes. FFI, done. GUI, done if you like Tk.
(Except now I am trying to put some bread on the table, so this Open
Source fairy is resting his wings.)
I appreciate Jeff's enthusiasm and actual $$$, but I do not think yet
another committee is the answer. Someone should just do CFFI bindings to
winsock and BSD sockets, take the specs folks pointed out, and start
writing some code. Meanwhile this thread just drags on...
Well, looks like LoL is getting picked up for SoC by LispNYC. cl-sockets
"Strikes Back" is available. Hello? (But after last time, watch out for
the interview process <g>.)
k
--
Cells: http://common-lisp.net/project/cells/
"Have you ever been in a relationship?"
Attorney for Mary Winkler, confessed killer of her
minister husband, when asked if the couple had
marital problems.
Ron Garret wrote:
> In article <················@fe11.lga>,
> Ken Tilton <·········@gmail.com> wrote:
>
> > Shoo! Go away!
>
> Everybody pay attention to Kenny. He knows exactly how to attract new
> users.
>
> rg
Carefull Ron.
For every line whining against Lisp you must have at least one
line of code contributed so you could back it up that you really care
And I really want to see your contribution.
Else stick yourself to Python Lisp doesn't need any more crybabies.
Or returning ones.
bobi
Ron Garret wrote:
> In article <···············@muvclx01.cadence.com>,
> ·····@runa.se (Bj�rn Lindberg) wrote:
>
>
>>Ron Garret <·········@flownet.com> writes:
>>
>>
>>>IMO, just having the ability to (semi-)officially deprecate cruft, even
>>>if it never actually goes away, I think would have enormous payoffs.
>>>But we don't currently have that ability.
>>
>>>Yes there is: it makes life VASTLY easier for newcomers if the actual
>>>language (as opposed to someone's private library) is not full of random
>>>crap.
>>
>>
>>
>>>This, by the way, is the crux of SteveY's point. It often gets
>>>overlooked so it bears repeating: it's all about how accessible the
>>>language is to newcomers. If the language is full of random crap then
>>>it becomes less accessible to newcomers. A library that covers up the
>>>crap doesn't help nearly as much as actually cleaning the crap up.
>>
>>Have you missed that almost no one agrees with you on what is "crap"
>>in CL?
>
>
> Doesn't matter. The fact is that a lot of people agree...
Yeah, Ilias, Yegge, Tinman... nutjobs and trolls, what a posse!
I'm staying out of this as you begged me to -- too busy writing Actual
Lisp Code not to comply --- but it does not seem to be helping you much.
:)
ken
--
Cells: http://common-lisp.net/project/cells/
"Have you ever been in a relationship?"
Attorney for Mary Winkler, confessed killer of her
minister husband, when asked if the couple had
marital problems.
Ron Garret <·········@flownet.com> writes:
> In article <···············@muvclx01.cadence.com>,
> ·····@runa.se (Björn Lindberg) wrote:
>
>> Ron Garret <·········@flownet.com> writes:
>>
>> > IMO, just having the ability to (semi-)officially deprecate cruft, even
>> > if it never actually goes away, I think would have enormous payoffs.
>> > But we don't currently have that ability.
>>
>> > Yes there is: it makes life VASTLY easier for newcomers if the actual
>> > language (as opposed to someone's private library) is not full of random
>> > crap.
>>
>> > This, by the way, is the crux of SteveY's point. It often gets
>> > overlooked so it bears repeating: it's all about how accessible the
>> > language is to newcomers. If the language is full of random crap then
>> > it becomes less accessible to newcomers. A library that covers up the
>> > crap doesn't help nearly as much as actually cleaning the crap up.
>>
>> Have you missed that almost no one agrees with you on what is "crap"
>> in CL?
>
> Doesn't matter. The fact is that a lot of people agree *that* there is
> (I am going to belatedly attempt to switch to more polite terminology)
> historical baggage in CL. Whether or not the particular examples I
> picked are the same as what the community would identify is irrelevant.
>
>> Short of making yourself benevolent dictator etc. for CL,
>
> <shudder>
>
>> I don't see how "we" being able to change the language would make you
>> any happier in the end.
>
> Here's how I can write an HTTP client in Python:
>
> import urllib
>
> def urlget(url):
> s = urllib.urlopen(url)
> s1 = s.read()
> s.close
> return s1
>
> This works in Python "out of the box".
>
> To do this in CL I have to first find and install an HTTP client
> library, which probably means I have to find and install ASDF and UFFI,
> all of which may or may not work with the Lisp I'm using (because UFFI
> isn't). And then if I later decide I need threads and I happen to be
> using CLisp then I have to start all over again from the beginning.
Assuming you have asdf.lisp and asdf-install downloaded (as in a fresh
SBCL install):
(require 'asdf-install)
(asdf-install:install :trivial-http)
Then:
(require :trivial-http)
(defun urlget (url)
(third (trivial-http:http-get url))
> Having the ability to canonicalize (I don't want to say standardize
> because that is a loaded word here) changes to the language would open
> up the possibility that I could write an HTTP client in Lisp with the
But how is this a change to the language? This involves external
libraries. Where does Common Lisp have to change to accomodate the
above code?
> same ease as I can currently write one in Python. Being able to do that
> would, I believe, attract more new users. Having more CL users would
> open up the possibility that the world will some day realize the
> horrible folly of XML and it will be abandoned in favor of
> S-expressions. And no longer having to deal with XML would make me
> very, very happy.
Agreed.
> For example.
>
> rg
Bill Atkins wrote:
> Assuming you have asdf.lisp and asdf-install downloaded (as in a fresh
> SBCL install):
>
> (require 'asdf-install)
> (asdf-install:install :trivial-http)
>
> Then:
>
> (require :trivial-http)
> (defun urlget (url)
> (third (trivial-http:http-get url))
>
Although I've played about with cl-curl in the past, just out of
curiosity I decided to give this a whirl:
CL-USER> (asdf-install:install :trivial-http)
Install where?
1) System-wide install:
System in /usr/lib/sbcl/site-systems/
Files in /usr/lib/sbcl/site/
2) Personal installation:
System in /home/cody/.sbcl/systems/
Files in /home/cody/.sbcl/site/
--> 2
Downloading 3427 bytes from
http://www.unmutual.info/software/trivial-http-1.1.tar.gz ...
Server responded 404 for GET
http://www.unmutual.info/software/trivial-http-1.1.tar.gz.asc
[Condition of type ASDF-INSTALL::DOWNLOAD-ERROR]
Hrrm . . . from a newbie point of view, that's pretty weak. Cant
recall the last time a cpan mirror lacked a file.
What's more, even if I were able to get the file, what would your
example do with:
(urlget "https://some-url-that-needs-cookies.com")
Yes, I know lisp is a 'better' language for some value of better, but
when perl can solve that common problem in < 10 minutes, is it any
wonder people are regularly employed to write one and not the other?
··············@gmail.com" <·············@gmail.com> writes:
> Bill Atkins wrote:
>
>> Assuming you have asdf.lisp and asdf-install downloaded (as in a fresh
>> SBCL install):
>>
>> (require 'asdf-install)
>> (asdf-install:install :trivial-http)
>>
>> Then:
>>
>> (require :trivial-http)
>> (defun urlget (url)
>> (third (trivial-http:http-get url))
>>
>
>
> Although I've played about with cl-curl in the past, just out of
> curiosity I decided to give this a whirl:
>
> CL-USER> (asdf-install:install :trivial-http)
> Install where?
> 1) System-wide install:
> System in /usr/lib/sbcl/site-systems/
> Files in /usr/lib/sbcl/site/
> 2) Personal installation:
> System in /home/cody/.sbcl/systems/
> Files in /home/cody/.sbcl/site/
> --> 2
> Downloading 3427 bytes from
> http://www.unmutual.info/software/trivial-http-1.1.tar.gz ...
>
> Server responded 404 for GET
> http://www.unmutual.info/software/trivial-http-1.1.tar.gz.asc
> [Condition of type ASDF-INSTALL::DOWNLOAD-ERROR]
>
>
> Hrrm . . . from a newbie point of view, that's pretty weak. Cant
> recall the last time a cpan mirror lacked a file.
Yes, we'd need as many mirrors as CPAN.
> What's more, even if I were able to get the file, what would your
> example do with:
>
> (urlget "https://some-url-that-needs-cookies.com")
This is trivial-http, not sophisticated-http. We also need more
programmers to build more comprehensive libraries.
> Yes, I know lisp is a 'better' language for some value of better, but
> when perl can solve that common problem in < 10 minutes, is it any
> wonder people are regularly employed to write one and not the other?
Also, it should be easier to write a more comprehensive library in
Lisp than in perl, so we can only wonder in what state we'd be if all
these perl programmers had invested their effort in Lisp instead of
CPAN...
Now, this is YOUR opportunity!
Write a sophisticated-http, and make you a name!
--
__Pascal Bourguignon__ http://www.informatimago.com/
"Do not adjust your mind, there is a fault in reality"
-- on a wall many years ago in Oxford.
In article <·······························@news.gha.chartermi.net>,
Ron Garret <·········@flownet.com> wrote:
> In article <···············@muvclx01.cadence.com>,
> ·····@runa.se (Bj�rn Lindberg) wrote:
>
> > Ron Garret <·········@flownet.com> writes:
> >
> > > IMO, just having the ability to (semi-)officially deprecate cruft, even
> > > if it never actually goes away, I think would have enormous payoffs.
> > > But we don't currently have that ability.
> >
> > > Yes there is: it makes life VASTLY easier for newcomers if the actual
> > > language (as opposed to someone's private library) is not full of random
> > > crap.
> >
> > > This, by the way, is the crux of SteveY's point. It often gets
> > > overlooked so it bears repeating: it's all about how accessible the
> > > language is to newcomers. If the language is full of random crap then
> > > it becomes less accessible to newcomers. A library that covers up the
> > > crap doesn't help nearly as much as actually cleaning the crap up.
> >
> > Have you missed that almost no one agrees with you on what is "crap"
> > in CL?
>
> Doesn't matter. The fact is that a lot of people agree *that* there is
> (I am going to belatedly attempt to switch to more polite terminology)
> historical baggage in CL. Whether or not the particular examples I
> picked are the same as what the community would identify is irrelevant.
>
> > Short of making yourself benevolent dictator etc. for CL,
>
> <shudder>
>
> > I don't see how "we" being able to change the language would make you
> > any happier in the end.
>
> Here's how I can write an HTTP client in Python:
>
> import urllib
>
> def urlget(url):
> s = urllib.urlopen(url)
> s1 = s.read()
> s.close
> return s1
>
> This works in Python "out of the box".
For Lisp systems this stuff also works out of the box.
I either use a Lisp written HTTP client or call out to 'curl'.
Ron, are these really the problems you have? I can't
believe it that you struggle with such things.
--
http://lispm.dyndns.org/
Ron Garret wrote:
> Second, yes, I really do have these problems. I go back to CL every now
> and then just to keep abreast of the current state of things, so I can
> tell you from firsthand experience (at least as of several months ago):
> there is really a significant amount of brokenness in CL-land. But the
> experienced people don't see it because they have long ago figured out
> ways to work around it.
See also http://public.research.att.com/~bs/bs_faq.html#compare
Maybe it's easier to import an http library in Python, but I don't think
there are no problems in Python-land.
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
In article <··············@individual.net>,
Pascal Costanza <··@p-cos.net> wrote:
> Ron Garret wrote:
>
> > Second, yes, I really do have these problems. I go back to CL every now
> > and then just to keep abreast of the current state of things, so I can
> > tell you from firsthand experience (at least as of several months ago):
> > there is really a significant amount of brokenness in CL-land. But the
> > experienced people don't see it because they have long ago figured out
> > ways to work around it.
>
> See also http://public.research.att.com/~bs/bs_faq.html#compare
>
> Maybe it's easier to import an http library in Python, but I don't think
> there are no problems in Python-land.
Of course. The difference is that when there are problems in Python
land they have a mechanism by which these problems can be addressed. (I
wonder if the fact that Lisp has no such mechanism accounts for the
rabid attacks on anyone who suggests that Lisp could benefit from
change.)
rg
Ron Garret wrote:
> In article <··············@individual.net>,
> Pascal Costanza <··@p-cos.net> wrote:
>
>> Ron Garret wrote:
>>
>>> Second, yes, I really do have these problems. I go back to CL every now
>>> and then just to keep abreast of the current state of things, so I can
>>> tell you from firsthand experience (at least as of several months ago):
>>> there is really a significant amount of brokenness in CL-land. But the
>>> experienced people don't see it because they have long ago figured out
>>> ways to work around it.
>> See also http://public.research.att.com/~bs/bs_faq.html#compare
>>
>> Maybe it's easier to import an http library in Python, but I don't think
>> there are no problems in Python-land.
>
> Of course. The difference is that when there are problems in Python
> land they have a mechanism by which these problems can be addressed. (I
> wonder if the fact that Lisp has no such mechanism accounts for the
> rabid attacks on anyone who suggests that Lisp could benefit from
> change.)
OK, let's try to summarize a bit: It seems to me that you indeed make
two different proposals. The first one is that there should be a process
for making changes to Common Lisp, the language, that cannot be
addressed by merely writing libraries. The second is that it should be
simpler to include libraries, especially for stuff that considered
important nowadays.
I am very sure wrt the second proposal that this is going to happen
sooner or later - let's make a wild guess, with the next couple of
years. asdf-install is actually already quite close, there are people
who are actively thinking about how to improve it, and a number of
implementations have started to include it as part of their standard
distribution, including commercial ones (at least that's the case for
asdf). As soon as some of the more tricky issues are resolved, the
necessary machinery will be installed to make "automagical" installation
of libraries a non-issue.
Wrt the first proposal, it is your turn to show that a change in the
language itself would substantially improve the language. This is
important because changes in the language have to be weighed against the
cost of spurious breaking of legacy code. If your goal is to make the
language easier to learn (without losing expressiveness!), then you have
to show that your changes would indeed make the language easier to learn
(for example, by conducting a study with beginners - your own
perceptions about what is easy to learn and what not can be very wrong
when you are an expert Lisper yourself). And the result may not be that
desirable: For example my boss is convinced that removing anonymous
closures from a Lisp-like language indeed makes it easier to learn, as
well as switching from an s-expression-based syntax to a more
conventional syntax. He indeed has evidence to support his claim. (He
claims that he manages to teach beginners concepts in his own language
Pico in half the amount of time that he needs for the same concepts in
Scheme.) The important point here is that you too probably have a bottom
line below which you are not willing to change the language just for
making newcomers' life easier. So this whole thing would be in need of a
discussion what that bottom line actually is.
I still think the only option you have is to implement the changes that
you have in mind yourself, publish them, and convince a considerable
amount of people that you indeed made a substantial improvement. I don't
think this is impossible, and I think it is a healthy process.
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
In article <··············@individual.net>,
Pascal Costanza <··@p-cos.net> wrote:
> Ron Garret wrote:
> > In article <··············@individual.net>,
> > Pascal Costanza <··@p-cos.net> wrote:
> >
> >> Ron Garret wrote:
> >>
> >>> Second, yes, I really do have these problems. I go back to CL every now
> >>> and then just to keep abreast of the current state of things, so I can
> >>> tell you from firsthand experience (at least as of several months ago):
> >>> there is really a significant amount of brokenness in CL-land. But the
> >>> experienced people don't see it because they have long ago figured out
> >>> ways to work around it.
> >> See also http://public.research.att.com/~bs/bs_faq.html#compare
> >>
> >> Maybe it's easier to import an http library in Python, but I don't think
> >> there are no problems in Python-land.
> >
> > Of course. The difference is that when there are problems in Python
> > land they have a mechanism by which these problems can be addressed. (I
> > wonder if the fact that Lisp has no such mechanism accounts for the
> > rabid attacks on anyone who suggests that Lisp could benefit from
> > change.)
>
> OK, let's try to summarize a bit: It seems to me that you indeed make
> two different proposals. The first one is that there should be a process
> for making changes to Common Lisp, the language, that cannot be
> addressed by merely writing libraries.
No. There should be a process for managing changes for both libraries
(or at least their interfaces) and the core language.
> The second is that it should be
> simpler to include libraries, especially for stuff that considered
> important nowadays.
More or less. It should be easier to *find* them. I would like to see
a (which is to say ONE) CL equivalent of
http://www.python.org/doc/current/modindex.html.
> I am very sure wrt the second proposal that this is going to happen
> sooner or later - let's make a wild guess, with the next couple of
> years.
Better late than never I suppose, but that's still a long time.
[snip]
> I still think the only option you have is to implement the changes that
> you have in mind yourself, publish them, and convince a considerable
> amount of people that you indeed made a substantial improvement. I don't
> think this is impossible, and I think it is a healthy process.
I think you are misunderstanding two things: First, I don't care nearly
as much about any specific proposal for change as I do about the (lack
of a) process for managing change. And second, I am not making these
proposals as a member of the Lisp community. (I think my membership has
actually lapsed at this point.) I am making these proposals as a (past
and potential future) customer, one who potentially represents the views
of a significant community of potential users who are rarely heard from
because when they dare to speak up they tend to get their heads bitten
off.
And third, I'm getting really, really tired.
rg
Ron Garret wrote:
> In article <··············@individual.net>,
> Pascal Costanza <··@p-cos.net> wrote:
>
>> Ron Garret wrote:
>>> In article <··············@individual.net>,
>>> Pascal Costanza <··@p-cos.net> wrote:
>>>
>>>> Maybe it's easier to import an http library in Python, but I don't think
>>>> there are no problems in Python-land.
>>> Of course. The difference is that when there are problems in Python
>>> land they have a mechanism by which these problems can be addressed. (I
>>> wonder if the fact that Lisp has no such mechanism accounts for the
>>> rabid attacks on anyone who suggests that Lisp could benefit from
>>> change.)
>> OK, let's try to summarize a bit: It seems to me that you indeed make
>> two different proposals. The first one is that there should be a process
>> for making changes to Common Lisp, the language, that cannot be
>> addressed by merely writing libraries.
>
> No. There should be a process for managing changes for both libraries
> (or at least their interfaces) and the core language.
OK
>> The second is that it should be
>> simpler to include libraries, especially for stuff that considered
>> important nowadays.
>
> More or less. It should be easier to *find* them. I would like to see
> a (which is to say ONE) CL equivalent of
> http://www.python.org/doc/current/modindex.html.
Ah, but that's already done. See http://cl-user.net
>> I am very sure wrt the second proposal that this is going to happen
>> sooner or later - let's make a wild guess, with the next couple of
>> years.
>
> Better late than never I suppose, but that's still a long time.
I thought you had more in mind. It seems that you're asking for (wrt
finding libraries) already exists.
>> I still think the only option you have is to implement the changes that
>> you have in mind yourself, publish them, and convince a considerable
>> amount of people that you indeed made a substantial improvement. I don't
>> think this is impossible, and I think it is a healthy process.
>
> I think you are misunderstanding two things: First, I don't care nearly
> as much about any specific proposal for change as I do about the (lack
> of a) process for managing change.
OK
> And second, I am not making these
> proposals as a member of the Lisp community. (I think my membership has
> actually lapsed at this point.)
That's a pity.
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
In article <··············@individual.net>,
Pascal Costanza <··@p-cos.net> wrote:
> >> The second is that it should be
> >> simpler to include libraries, especially for stuff that considered
> >> important nowadays.
> >
> > More or less. It should be easier to *find* them. I would like to see
> > a (which is to say ONE) CL equivalent of
> > http://www.python.org/doc/current/modindex.html.
>
> Ah, but that's already done. See http://cl-user.net
Just as an experiment I decided to try to use cl-user.net to get an HTTP
server up and running in Lisp. Here's a real-time log:
Found CL-HTTP almost right away. Site notes that it is NOT
asdf-installable. Uh-oh.
Found the download page. No version available for SBCL. Try the CMUCL
version (noting in passing that a newbie might not know that SBCL is a
derivative of CMUCL and might therefore very well be stuck at this
point).
Hm, that link doesn't actually download CL-HTTP, but takes me to another
page where I have a choice between "PC and Unix" and "MCL". OK, I
suppose I want "PC and Unix."
Downloaded and unpacked with no problem. There are readme files for
ACL, LCL (whatever that is -- Liquid Common Lisp perhaps?), and MCL.
Nothing for SBCL or CMUCL.
OK, let's try acl-read-me.text. Oh, this is rich. The contents of the
file are:
===
To run in Allegro Common Lisp for UNIX. Please see the file
http:acl;-read-me-.text.
===
WTF? At this point I don't even have to put on my newbie hat to be
genuinely confused.
OK, well, let's try something else. Let's see, there's a CMUCL
directory. That looks promising. Inside there's a file called
start.lisp. Very promising. But alas:
* (load "start.lisp")
debugger invoked on a SB-INT:SIMPLE-FILE-ERROR:
"target:pcl/pclload.lisp" does not exist.
OK, maybe there are instructions back on the web page, but no, the web
page just says the instructions are in the distro. Maybe I missed a doc
directory somewhere? Nope. And now I am stuck.
Now, don't bother telling me where I went wrong. The specifics of this
experience are beside the point. The point is that this is a very
typical experience. I've tried this experiment more than once with many
different libraries and many different implementations. NOT ONCE has
something Just Worked. By way of start contrast, I have never used a
Python library that didn't Just Work.
> >> I am very sure wrt the second proposal that this is going to happen
> >> sooner or later - let's make a wild guess, with the next couple of
> >> years.
> >
> > Better late than never I suppose, but that's still a long time.
>
> I thought you had more in mind. It seems that you're asking for (wrt
> finding libraries) already exists.
Nope. Not even close.
> > And second, I am not making these
> > proposals as a member of the Lisp community. (I think my membership has
> > actually lapsed at this point.)
>
> That's a pity.
Sorry, the membership dues are too steep (and the hazing is getting a
little old too).
rg
Ron Garret wrote:
> Now, don't bother telling me where I went wrong. The specifics of this
> experience are beside the point. The point is that this is a very
> typical experience. I've tried this experiment more than once with many
> different libraries and many different implementations. NOT ONCE has
> something Just Worked. By way of start contrast, I have never used a
> Python library that didn't Just Work.
Yes, that is the big issue with Common Lisp, I suspect. Whenever I
install any CL library, I assume it's not going to work, and that I'll
have to fix it. Generally that assumption is correct.
I can think of individual libs in other languages which didn't work
properly, like Java's Tomcat, but I don't know of a language which
systematically has such problems across so many of its libraries.
I tend not to believe in "community problems," but this is one -- no
one warns people of the install problems. The main reason I dislike the
apocalyptic "I've proven Lisp sucks" slams is because there are
important problems to communicate to people... but these critics
absolutely fail to mention them. And so energy is expended defending
Lisp from defamation, rather than discussing the real problems.
(That said, I'm more willing to fix Lisp libraries than those of other
languages. But it's still tiresome and destructive to morale.)
Tayssir
Tayssir John Gabbour wrote:
> The main reason I dislike the
> apocalyptic "I've proven Lisp sucks" slams is because there are
> important problems to communicate to people... but these critics
> absolutely fail to mention them.
Incidentally, since you (Ron Garret) just mentioned it, present company
is excepted...
Tayssir
In article <························@t31g2000cwb.googlegroups.com>,
"Tayssir John Gabbour" <···········@yahoo.com> wrote:
> Tayssir John Gabbour wrote:
> > The main reason I dislike the
> > apocalyptic "I've proven Lisp sucks" slams is because there are
> > important problems to communicate to people... but these critics
> > absolutely fail to mention them.
>
> Incidentally, since you (Ron Garret) just mentioned it, present company
> is excepted...
>
> Tayssir
Thank you for noticing.
rg
Ron Garret wrote:
> In article <························@t31g2000cwb.googlegroups.com>,
> "Tayssir John Gabbour" <···········@yahoo.com> wrote:
>
> > Tayssir John Gabbour wrote:
> > > The main reason I dislike the
> > > apocalyptic "I've proven Lisp sucks" slams is because there are
> > > important problems to communicate to people... but these critics
> > > absolutely fail to mention them.
> >
> > Incidentally, since you (Ron Garret) just mentioned it, present company
> > is excepted...
>
> Thank you for noticing.
I actually had forgotten I was writing on a "Lisp sucks" thread until I
looked up... ;) I was thinking of the other ones we frequently see on
blogs.
Tayssir
Ron Garret <·········@flownet.com> writes:
> Just as an experiment I decided to try to use cl-user.net to get an HTTP
> server up and running in Lisp. Here's a real-time log:
[...]
> Found the download page. No version available for SBCL. Try the CMUCL
> version (noting in passing that a newbie might not know that SBCL is a
> derivative of CMUCL and might therefore very well be stuck at this
> point).
From the CL Directory entry for SBCL:
http://www.cl-user.net/asp/impl/sbcl
Steel Bank Common Lisp is a Common Lisp implementation based on the
CMUCL sources, but it puts a greater emphasis on maintainability.
Paolo
--
Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
The Common Lisp Directory: http://www.cl-user.net
Paolo Amoroso <·······@mclink.it> writes:
>
>> Just as an experiment I decided to try to use cl-user.net to get an HTTP
>> server up and running in Lisp. Here's a real-time log:
> [...]
>> Found the download page. No version available for SBCL. Try the CMUCL
>> version (noting in passing that a newbie might not know that SBCL is a
>> derivative of CMUCL and might therefore very well be stuck at this
>> point).
>
> From the CL Directory entry for SBCL:
>
> http://www.cl-user.net/asp/impl/sbcl
>
> Steel Bank Common Lisp is a Common Lisp implementation based on the
> CMUCL sources, but it puts a greater emphasis on maintainability.
But is a new SBCL user who's trying to install an HTTP server going to
know that? _Should_ he?
--
Robert Uhl <http://public.xdi.org/=ruhl>
From empirical experience, your Exchange admin needs to put down the
crack pipe and open a window to disperse the fumes. --Joe Thompson
Ron Garret wrote:
> In article <··············@individual.net>,
> Pascal Costanza <··@p-cos.net> wrote:
>
>>>> The second is that it should be
>>>> simpler to include libraries, especially for stuff that considered
>>>> important nowadays.
>>> More or less. It should be easier to *find* them. I would like to see
>>> a (which is to say ONE) CL equivalent of
>>> http://www.python.org/doc/current/modindex.html.
>> Ah, but that's already done. See http://cl-user.net
>
> Just as an experiment I decided to try to use cl-user.net to get an HTTP
> server up and running in Lisp. Here's a real-time log:
>
> Found CL-HTTP almost right away. Site notes that it is NOT
> asdf-installable. Uh-oh.
>
> Found the download page. No version available for SBCL. Try the CMUCL
> version (noting in passing that a newbie might not know that SBCL is a
> derivative of CMUCL and might therefore very well be stuck at this
> point).
Since when is not reading the manual considered part of a reasonable
approach? From the CL-HTTP website:
"Douglas Thomas Crosher (···@cmucl.cons.org) developed a port CL-HTTP to
CMU Common Lisp which runs on current releases of CMUCL. This port is
considered beta-test software when running multi-threaded on Intel X86
hardware under FreeBSD and Linux, and alpha-test on the other ports."
> Hm, that link doesn't actually download CL-HTTP, but takes me to another
> page where I have a choice between "PC and Unix" and "MCL". OK, I
> suppose I want "PC and Unix."
>
> Downloaded and unpacked with no problem. There are readme files for
> ACL, LCL (whatever that is -- Liquid Common Lisp perhaps?), and MCL.
> Nothing for SBCL or CMUCL.
>
> OK, let's try acl-read-me.text. Oh, this is rich. The contents of the
> file are:
>
> ===
> To run in Allegro Common Lisp for UNIX. Please see the file
> http:acl;-read-me-.text.
> ===
>
> WTF? At this point I don't even have to put on my newbie hat to be
> genuinely confused.
"CL-HTTP runs acceptably under ACL, but these ports may not be 100%
complete nor heavily tuned for production level performance."
I wouldn't bet on that either.
> OK, well, let's try something else. Let's see, there's a CMUCL
> directory. That looks promising. Inside there's a file called
> start.lisp. Very promising. But alas:
>
> * (load "start.lisp")
>
> debugger invoked on a SB-INT:SIMPLE-FILE-ERROR:
> "target:pcl/pclload.lisp" does not exist.
See above.
> OK, maybe there are instructions back on the web page, but no, the web
> page just says the instructions are in the distro. Maybe I missed a doc
> directory somewhere? Nope. And now I am stuck.
Check out the downloads page.
> Now, don't bother telling me where I went wrong. The specifics of this
> experience are beside the point.
No, they are not. You expected production-level quality from
beta-quality software. I guess that wouldn't even work in Python-land.
> The point is that this is a very
> typical experience. I've tried this experiment more than once with many
> different libraries and many different implementations. NOT ONCE has
> something Just Worked. By way of start contrast, I have never used a
> Python library that didn't Just Work.
Here is a counter example: I would like to use a framework for
continuation-based web applications in Python. I type 'python
continuation-based webframework' into Google. The third link sounds
promising (luckily, I understand German).
When I click on the link, I get a "page not found" error.
I go back and see that the name of the framework is CherryFlow. So I
type CherryFlow into Google. The first link gives a webpage that looks
promising, so I click on it. Contrary to you, I tend to read before I
download. Unfortunately, the page says the following:
"The only catch is the back and refresh buttons won't work unless you
run Stackless or Statesaver. Continuations aren't a core feature of
Python, so you need an extension to get them to work. This means that
CherryFlow is really not useful at all unless you have one or the other.
Statesaver is your best bet."
The rest on that page doesn't really sound newbie-friendly at all to me.
It tells me to download CherryFlow, download statesaver - I choose the
Mac OS X binary, and then it gives an example, saying that if I have
everything installed, I can just run that example. I try it, and get the
following output:
Traceback (most recent call last):
File "devworks.py", line 1, in ?
from cherrypy import cpg
ImportError: No module named cherrypy
Now I, as a Python newbie, am stuck. What am I supposed to do at this point?
Doesn't seem to me that experiences are that different.
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
Ron Garret <·········@flownet.com> writes:
> [...good factual info...]
> ===
> To run in Allegro Common Lisp for UNIX. Please see the file
> http:acl;-read-me-.text.
> ===
>
> WTF? At this point I don't even have to put on my newbie hat to be
> genuinely confused.
So, you're saying that we're too exigent to ask newbies to learn the
language before trying to download a library and develop a web site or
anything else? Do they start using CPAN before learning to write
programs in perl?
I mean serriously, DO THEY REALLY START BY DOWNLOADING PYTHON, RUBY,
OR PERL LIBRARIES AND WRITING A WEB SITE EVEN BEFORE KNOWING HOW TO
WRITE A PROGRAM?
(Oh, and I'm not confused, it's clearly a logical pathname; the only
ambiguity may be in the logical host, but I'd bet we can assume that
it's the current directory or one of its children).
--
__Pascal Bourguignon__ http://www.informatimago.com/
"Debugging? Klingons do not debug! Our software does not coddle the
weak."
Pascal Bourguignon <···@informatimago.com> writes:
> I mean serriously, DO THEY REALLY START BY DOWNLOADING PYTHON, RUBY,
> OR PERL LIBRARIES AND WRITING A WEB SITE EVEN BEFORE KNOWING HOW TO
> WRITE A PROGRAM?
Well, a few years ago it worked just like that. But after having been
picked up from under a bridge somewhere, they were given half a day
to get sober and read "Perl For Dummies In One Day" before they
started downloading those libraries ;-)
--
(espen)
From: Holger Schauer
Subject: Re: How Common Lisp sucks
Date:
Message-ID: <yxzwtdf0z76.fsf@gmx.de>
On 4614 September 1993, Ron Garret wrote:
> Found CL-HTTP almost right away. Site notes that it is NOT
> asdf-installable. Uh-oh.
What you describe below is roughly my experience with CL-HTTP from
five years ago. On the other hand, see what I get on my Ubuntu system:
[elendil->~]apt-cache search web server lisp
libapache-mod-lisp - An Apache module that interfaces with Lisp environments
wl - Yet Another Message Interface on Emacsen
wl-beta - Yet Another Message Interface on Emacsen (developing version)
araneida - A programmable web server written and extended in Lisp
cl-aserve - Portable Aserve
cl-kpax - A Common Lisp Application Framework
cl-tbnl - A toolkit for building dynamic websites with Common Lisp
Of these, araneida and aserve are both webservers written in CL,
AFAIK, and modlisp is an interface between Apache and Lisp. I haven't
tried (yet), but I bet you won't run into the same problems with these
packages. For me, this situation looks equivalent to most Perl or
Python libraries: e.g. to use tkinter I need to install (via the tools
my Unix distribution provides) a separate library, so nothing new
here.
>> I thought you had more in mind. It seems that you're asking for (wrt
>> finding libraries) already exists.
> Nope. Not even close.
We seem to get there.
"Crawling can be beautiful it sure beats standing still
Crawling on your hands and knees takes self-control and skill."
-- Les Savy Fav, "Crawling can be beautiful"
:-D
Holger
--
--- http://www.coling.uni-freiburg.de/~schauer/ ---
Fachbegriffe der Informatik - Einfach erkl�rt
153: h�flich
Abwesenheit von absichtlichen Beleidigungen. (Lars
Marowsky-Br�e)
Pascal Costanza <··@p-cos.net> writes:
> > And second, I am not making these proposals as a member of the Lisp
> > community. (I think my membership has actually lapsed at this
> > point.)
>
> That's a pity.
Hmm. Maybe we (or someone more likely (closer to the US?) to convince
him) should give Ron a lisp job offer and see if we can get him happy
hacking lisp again?
(And then, next year around this time: Ron starts a "How Common Lisp
wins" thread ;-P)
--
(espen)
In article <··············@mordac.netfonds.no>,
Espen Vestre <·····@vestre.net> wrote:
> Pascal Costanza <··@p-cos.net> writes:
>
> > > And second, I am not making these proposals as a member of the Lisp
> > > community. (I think my membership has actually lapsed at this
> > > point.)
> >
> > That's a pity.
>
> Hmm. Maybe we (or someone more likely (closer to the US?) to convince
> him) should give Ron a lisp job offer and see if we can get him happy
> hacking lisp again?
Do you really think that would help?
> (And then, next year around this time: Ron starts a "How Common Lisp
> wins" thread ;-P)
Believe me, I would like nothing better than to be able to write that
post.
rg
Ron Garret <·········@flownet.com> writes:
> > Hmm. Maybe we (or someone more likely (closer to the US?) to convince
> > him) should give Ron a lisp job offer and see if we can get him happy
> > hacking lisp again?
>
> Do you really think that would help?
It's difficult to answer that question - I'm not sure of what kind of
help for whom or what you're thinking of...
> Believe me, I would like nothing better than to be able to write that
> post.
That's good - does this mean that after all, you haven't actually
cancelled your membership in the lisp community?
--
(espen)
In article <··············@vestre.net>, Espen Vestre <·····@vestre.net>
wrote:
> Ron Garret <·········@flownet.com> writes:
>
> > > Hmm. Maybe we (or someone more likely (closer to the US?) to convince
> > > him) should give Ron a lisp job offer and see if we can get him happy
> > > hacking lisp again?
> >
> > Do you really think that would help?
>
> It's difficult to answer that question - I'm not sure of what kind of
> help for whom or what you're thinking of...
You're the one who made the suggestion, you tell me. (BTW, I'm not
actually available at the moment, just on the (very) off chance that
anyone is seriously considering this.)
> > Believe me, I would like nothing better than to be able to write that
> > post.
>
> That's good - does this mean that after all, you haven't actually
> cancelled your membership in the lisp community?
<shrug> That's up to the community. My membership has always been a bit
tenuous. I am not really a hacker (though I can fake it pretty well
when I have to), which has always made me a bit of an oddball around
here. (Ironically, this is exactly the reason I love Lisp, because for
many years it let me get useful work done without having to be a
hacker.) My attempts to contribute over the years have met with, let's
be polite, mixed reviews. Nowadays I have a lot of other fish to fry,
but Lisp will always be my first love. I am deeply saddened by the fact
that stating my sincere (and not altogether uninformed) belief that
"shut up and hack" is not the best way to make progress makes me a
pariah.
rg
Ron Garret <·········@flownet.com> writes:
> You're the one who made the suggestion, you tell me.
Well, I didn't really imply anything else than that you might be a
happy lisper if you were working in a friendly lisp company ;)
--
(espen)
From: Holger Schauer
Subject: Re: How Common Lisp sucks
Date:
Message-ID: <yxzzmii1q0d.fsf@gmx.de>
On 4612 September 1993, Ron Garret wrote:
>> > Here's how I can write an HTTP client in Python:
[...]
> Again, this is precisely the point. First, the problems I have are
> irrelevant. It is the problems that newcomers have that count.
Of course, having some kind of library for some common problem is a
nice thing. What I experience for different languages, however, is
that for each one, you have some library readily available and the
next one missing. Try parsing XML files with Perl, for instance. Go
figure the miriads of libraries. Actually, I like having different
choices, in either language. From your posts I get the impression you
don't like "TMTOWTDI" that e.g. Perl promotes or at least don't like
the confusion that might trigger in newcomers.
I wouldn't sell choice for simplicity, however, and I don't buy the
argument that programming languages should cater to newcomers mainly,
either. I agree that there are some dark corners where CL has pitfalls
for newbies (and returners, too, since I'm happy to fall into them
whenever I haven't touched CL for some time).
> Second, yes, I really do have these problems. I go back to CL every now
> and then just to keep abreast of the current state of things, so I can
> tell you from firsthand experience (at least as of several months ago):
These problems differ in magnitude depending on the domain you want to
tackle. For instance, on my Debian-Linux based systems, installing and
using cl-ppcre (which seems to be the de-facto standard for regular
expressions) was as easy as installing some lisp implementation (which
automatically pulled in asdf) and then enchanting the magic
asdf-loading-op. On the other hand, getting ucw running was quite a
bit of hassle. Which is not that surprising, given that ucw is
still a much faster moving (and probably also larger) target.
To me it seems that wrt. the problems with libraries that you
describe, things actually have gotten a lot better over the last
years. In the 90s, when the web hype was really hot, there was not
much Lisp could offer besides CL-HTTP. With the various open-source
projects around, I think the situation has drastically improved. YMMV.
I agree that a lot of popular scripting languages are way ahead in a
lot of areas, though.
Are we there yet? Standarize the de-facto standards? I don't really
dare a judgement but from what I've seen recently, I don't think so.
Holger
--
--- http://www.coling.uni-freiburg.de/~schauer/ ---
Fachbegriffe der Informatik - Einfach erkl�rt
25: Multithreaded
Wir mu�ten ein Flu�diagramm malen, um es zu debuggen.
(Kristian K�hntopp)
Ron Garret wrote:
> In article <···············@muvclx01.cadence.com>,
> ·····@runa.se (Bj�rn Lindberg) wrote:
>
>
>>Ron Garret <·········@flownet.com> writes:
>>
>>
>>>IMO, just having the ability to (semi-)officially deprecate cruft, even
>>>if it never actually goes away, I think would have enormous payoffs.
>>>But we don't currently have that ability.
>>
>>>Yes there is: it makes life VASTLY easier for newcomers if the actual
>>>language (as opposed to someone's private library) is not full of random
>>>crap.
>>
>>
>>
>>>This, by the way, is the crux of SteveY's point. It often gets
>>>overlooked so it bears repeating: it's all about how accessible the
>>>language is to newcomers. If the language is full of random crap then
>>>it becomes less accessible to newcomers. A library that covers up the
>>>crap doesn't help nearly as much as actually cleaning the crap up.
>>
>>Have you missed that almost no one agrees with you on what is "crap"
>>in CL?
>
>
> Doesn't matter. The fact is that a lot of people agree *that* there is
> (I am going to belatedly attempt to switch to more polite terminology)
> historical baggage in CL. Whether or not the particular examples I
> picked are the same as what the community would identify is irrelevant.
Exactly. To quote Scott Adams on dilbertblog:
"I respect the Mormons for doing a great job of creating good citizens.
Whatever they�re doing seems to be working. You rarely hear about a gang
of violent Mormons terrorizing a town. But must I also respect their
practice of wearing special underpants to ward off evil? Is it a package
deal, no pun intended?"
...
"I fantasize about becoming President one day and insisting on settling
the question of which religion is �right.� I�d assemble all the experts
on history and religious and science, and televise them arguing the
merits and evidence of their sides, with cross-examination and � most
important � mocking. There would be no stop date for this debate. It
would continue until even a child could recognize which positions are
the most easily mocked. Sometimes that�s as close to wisdom as we can get."
http://dilbertblog.typepad.com/the_dilbert_blog/2006/04/respecting_the_.html
Certainly there's some historical cruft that could be deprecated.
Certainly Lisp could benefit from having some things more standardized.
Why does the fact that C doesn't have sockets or threading specified in
its standard (which *does* cause portability headaches in C) mean that
Lisp can't settle on a standard (and ease portability headaches)?
--Larry
Ron Garret <·········@flownet.com> writes:
> In article <···············@muvclx01.cadence.com>,
> ·····@runa.se (Bj�rn Lindberg) wrote:
>
> > Ron Garret <·········@flownet.com> writes:
> >
> > > IMO, just having the ability to (semi-)officially deprecate cruft, even
> > > if it never actually goes away, I think would have enormous payoffs.
> > > But we don't currently have that ability.
> >
> > > Yes there is: it makes life VASTLY easier for newcomers if the actual
> > > language (as opposed to someone's private library) is not full of random
> > > crap.
> >
> > > This, by the way, is the crux of SteveY's point. It often gets
> > > overlooked so it bears repeating: it's all about how accessible the
> > > language is to newcomers. If the language is full of random crap then
> > > it becomes less accessible to newcomers. A library that covers up the
> > > crap doesn't help nearly as much as actually cleaning the crap up.
> >
> > Have you missed that almost no one agrees with you on what is "crap"
> > in CL?
>
> Doesn't matter. The fact is that a lot of people agree *that* there is
> (I am going to belatedly attempt to switch to more polite terminology)
> historical baggage in CL. Whether or not the particular examples I
> picked are the same as what the community would identify is irrelevant.
So, basically you are hoping to stir up enough dissatisfaction with CL
that some change occurs, even if that change turns out to be for the
worse? I don't buy that kind of "change is good for its own sake"
style of argument. In fact, in a very general sense a much better case
can be made for "keeping things the same for its own sake".
> > Short of making yourself benevolent dictator etc. for CL,
>
> <shudder>
>
> > I don't see how "we" being able to change the language would make you
> > any happier in the end.
>
> Here's how I can write an HTTP client in Python:
>
> import urllib
>
> def urlget(url):
> s = urllib.urlopen(url)
> s1 = s.read()
> s.close
> return s1
>
> This works in Python "out of the box".
And why does it work? Is it because Python has standardized support
for it? No. Is it because Python is particularly good at embedding
domain-specific languages? No. Is it because Python's core is very
well designed? Not likely. This begs the question what this example
has got to do with your inital three points. (I also don't get why you
are writing this in your reply to *me*, since I raised a completely
different question, but nevermind.)
> To do this in CL I have to first find and install an HTTP client
> library, which probably means I have to find and install ASDF and UFFI,
> all of which may or may not work with the Lisp I'm using (because UFFI
> isn't). And then if I later decide I need threads and I happen to be
> using CLisp then I have to start all over again from the beginning.
As someone else has shown, apparently your theorization above is
inaccurate. It seems that doing it in CL requires even fewer lines
than in Python.
> Having the ability to canonicalize (I don't want to say standardize
> because that is a loaded word here) changes to the language would open
> up the possibility that I could write an HTTP client in Lisp with the
> same ease as I can currently write one in Python. Being able to do that
> would, I believe, attract more new users. Having more CL users would
> open up the possibility that the world will some day realize the
> horrible folly of XML and it will be abandoned in favor of
> S-expressions. And no longer having to deal with XML would make me
> very, very happy.
>
> For example.
Considering how different Lisp is, and the normal reactions to
everything where Lisp separates itself from the standard stock of
programming languages, do you really think that there is a
significantly sized group of newbies going: "Hm, Python and Lisp are
more or less equal in my mind, but I'll go with Python because it has
such good builtin support for downloading web pages." Some things are
much easier to do in Lisp than in Python, yet I don't see them
dragging lots of newbies over.
Bj�rn
Ron Garret <·········@flownet.com> writes:
>> > It is claimed that there are portable
>> > libraries that work across implementations that provide de facto
>> > standards, e.g. UFFI, but these claims are false.
>>
>> You probably don't mean what you say here. There are definitely portable
>> libraries out there. Maybe not for foreign function interfaces (I can't
>> judge this), but certainly for other things.
>
> Of course there are portable libraries, just not for the things that
> matter in today's world.
Please, tell me what matters in today's world so that I can work on
that.
I am, obviously, being slightly sarcastic: I won't stop helping maintain
and develop my current CL projects just because you say they don't
matter in today's world but, I'm interested in helping make CL better
and in fighting my HCGS[1].
[1] http://dilbertblog.typepad.com/the_dilbert_blog/2006/04/helpful_critica.html
--
Luís Oliveira
luismbo (@) gmail (.) com
Equipa Portuguesa do Translation Project
http://www.iro.umontreal.ca/translation/registry.cgi?team=pt
In article <··············@deadspam.com>,
·············@deadspam.com (Luís Oliveira) wrote:
> Ron Garret <·········@flownet.com> writes:
> >> > It is claimed that there are portable
> >> > libraries that work across implementations that provide de facto
> >> > standards, e.g. UFFI, but these claims are false.
> >>
> >> You probably don't mean what you say here. There are definitely portable
> >> libraries out there. Maybe not for foreign function interfaces (I can't
> >> judge this), but certainly for other things.
> >
> > Of course there are portable libraries, just not for the things that
> > matter in today's world.
>
> Please, tell me what matters in today's world so that I can work on
> that.
Sockets. Database connectivity. Threads.
rg
Ron Garret <·········@flownet.com> writes:
>> Please, tell me what matters in today's world so that I can work on
>> that.
>
> Sockets. Database connectivity. Threads.
Ok, so let's tackle each one of those objectively:
1. Sockets. There are many simple compatibility layers including
trivial-sockets, the socket stuff in kmrcl, etc...
There are also at least two more ambitious projects that I know of.
usockets and cffi-net. They are pursuing different approaches.
So, people are working on this.
2. Database connectivity. We have CLSQL and a couple of others. From
what I hear, CLSQL supports more database backends than other
libraries in other popular languages (but I haven't confirmed this).
3. Threads. Besides compatibility layers such as kmrcl and others,
there's bordeaux-mp.
I think I have communicated with pretty much everyone who is involved in
the projects I mention above (the virtues of a relatively small
community!) and they seem to have it covered.
Please, go on. What else matters in today's world that CL lacks?
--
Luís Oliveira
luismbo (@) gmail (.) com
Equipa Portuguesa do Translation Project
http://www.iro.umontreal.ca/translation/registry.cgi?team=pt
In article <··············@thalassa.informatimago.com>,
Pascal Bourguignon <···@informatimago.com> wrote:
> Ron Garret <·········@flownet.com> writes:
> > And how am I as a newcomer supposed to know all this?
>
> Using http://www.google.com/ ?
> Browsing http://www.cliki.net/ ?
> Asking on news:comp.lang.lisp ?
> Asking on irf://irc.freenode.org/#lisp ?
>
> We've always welcomed such questions.
Fair enough, but now put yourself in a newcomer's shoes and compare that
situation to what happens when you type "Python" into Google.
rg
Ron Garret <·········@flownet.com> writes:
> In article <··············@thalassa.informatimago.com>,
> Pascal Bourguignon <···@informatimago.com> wrote:
>
>> Ron Garret <·········@flownet.com> writes:
>> > And how am I as a newcomer supposed to know all this?
>>
>> Using http://www.google.com/ ?
>> Browsing http://www.cliki.net/ ?
>> Asking on news:comp.lang.lisp ?
>> Asking on irf://irc.freenode.org/#lisp ?
>>
>> We've always welcomed such questions.
>
> Fair enough, but now put yourself in a newcomer's shoes and compare that
> situation to what happens when you type "Python" into Google.
Try it. Python or Lisp. Both return all relevant links on the top of
the first page (the only links ever seen).
--
__Pascal Bourguignon__ http://www.informatimago.com/
"A TRUE Klingon warrior does not comment his code!"
In article <··············@thalassa.informatimago.com>,
Pascal Bourguignon <···@informatimago.com> wrote:
> Ron Garret <·········@flownet.com> writes:
>
> > In article <··············@thalassa.informatimago.com>,
> > Pascal Bourguignon <···@informatimago.com> wrote:
> >
> >> Ron Garret <·········@flownet.com> writes:
> >> > And how am I as a newcomer supposed to know all this?
> >>
> >> Using http://www.google.com/ ?
> >> Browsing http://www.cliki.net/ ?
> >> Asking on news:comp.lang.lisp ?
> >> Asking on irf://irc.freenode.org/#lisp ?
> >>
> >> We've always welcomed such questions.
> >
> > Fair enough, but now put yourself in a newcomer's shoes and compare that
> > situation to what happens when you type "Python" into Google.
>
> Try it. Python or Lisp. Both return all relevant links on the top of
> the first page (the only links ever seen).
The first link for "Python" is www.pythong.org, where the very first
thing on the upper left hand corner of the screen is "Getting started".
From there it is an almost linear path to getting Python up and running,
with all its standard libraries. (In fact, "Download 2.4.2" and
"Beginner's guide" show up as sub-links on the Google results page).
The first result for "Lisp" is the ALU home page. The first thing on
the upper left hand corner is "History." There are no implementations,
no "getting started" link. It could hardly be more hostile to newcomers
if it tried.
You have to have some pretty serious blinders on not to appreciate the
difference between these two experiences.
rg
Ron Garret <·········@flownet.com> writes:
> In article <··············@thalassa.informatimago.com>,
> Pascal Bourguignon <···@informatimago.com> wrote:
>
> > Ron Garret <·········@flownet.com> writes:
> >
> > > In article <··············@thalassa.informatimago.com>,
> > > Pascal Bourguignon <···@informatimago.com> wrote:
> > >
> > >> Ron Garret <·········@flownet.com> writes:
> > >> > And how am I as a newcomer supposed to know all this?
> > >>
> > >> Using http://www.google.com/ ?
> > >> Browsing http://www.cliki.net/ ?
> > >> Asking on news:comp.lang.lisp ?
> > >> Asking on irf://irc.freenode.org/#lisp ?
> > >>
> > >> We've always welcomed such questions.
> > >
> > > Fair enough, but now put yourself in a newcomer's shoes and compare that
> > > situation to what happens when you type "Python" into Google.
> >
> > Try it. Python or Lisp. Both return all relevant links on the top of
> > the first page (the only links ever seen).
>
> The first link for "Python" is www.pythong.org, where the very first
> thing on the upper left hand corner of the screen is "Getting started".
> From there it is an almost linear path to getting Python up and running,
> with all its standard libraries. (In fact, "Download 2.4.2" and
> "Beginner's guide" show up as sub-links on the Google results page).
>
> The first result for "Lisp" is the ALU home page. The first thing on
> the upper left hand corner is "History." There are no implementations,
> no "getting started" link. It could hardly be more hostile to newcomers
> if it tried.
>
> You have to have some pretty serious blinders on not to appreciate the
> difference between these two experiences.
Very well. But how would addressing your inital three points improve
this siutation? I am sure that you are right in your observation that
newbies are helped by beginner's documentation, but your initial
problem points did not touch upon that at all.
Bj�rn
In article <···············@muvclx01.cadence.com>,
·····@runa.se (Bj�rn Lindberg) wrote:
> Ron Garret <·········@flownet.com> writes:
>
> > In article <··············@thalassa.informatimago.com>,
> > Pascal Bourguignon <···@informatimago.com> wrote:
> >
> > > Ron Garret <·········@flownet.com> writes:
> > >
> > > > In article <··············@thalassa.informatimago.com>,
> > > > Pascal Bourguignon <···@informatimago.com> wrote:
> > > >
> > > >> Ron Garret <·········@flownet.com> writes:
> > > >> > And how am I as a newcomer supposed to know all this?
> > > >>
> > > >> Using http://www.google.com/ ?
> > > >> Browsing http://www.cliki.net/ ?
> > > >> Asking on news:comp.lang.lisp ?
> > > >> Asking on irf://irc.freenode.org/#lisp ?
> > > >>
> > > >> We've always welcomed such questions.
> > > >
> > > > Fair enough, but now put yourself in a newcomer's shoes and compare
> > > > that
> > > > situation to what happens when you type "Python" into Google.
> > >
> > > Try it. Python or Lisp. Both return all relevant links on the top of
> > > the first page (the only links ever seen).
> >
> > The first link for "Python" is www.pythong.org, where the very first
> > thing on the upper left hand corner of the screen is "Getting started".
> > From there it is an almost linear path to getting Python up and running,
> > with all its standard libraries. (In fact, "Download 2.4.2" and
> > "Beginner's guide" show up as sub-links on the Google results page).
> >
> > The first result for "Lisp" is the ALU home page. The first thing on
> > the upper left hand corner is "History." There are no implementations,
> > no "getting started" link. It could hardly be more hostile to newcomers
> > if it tried.
> >
> > You have to have some pretty serious blinders on not to appreciate the
> > difference between these two experiences.
>
> Very well. But how would addressing your inital three points improve
> this siutation? I am sure that you are right in your observation that
> newbies are helped by beginner's documentation, but your initial
> problem points did not touch upon that at all.
The first one should be obvious: A set of standardized libraries would
allow newcomers to write useful applications out of the box instead of
having to spend time figuring out which combination of implementations
and libraries will work for them.
The second issue I raised -- ((...) ...) syntax -- is really a surrogate
to illustrate that some thing really do require a change to the
language. A better example would have been the MOP, or the unresolved
ANSI issues, or (my personal favorite) the lack of a real module system.
(Packages are used instead, and this causes no end of confusion, even
among experienced programmers.)
Third, cleaning up some of the cruft would allow tutorials to be written
that don't have to dance around and be apologetic for the cruft (e.g.
http://www.flownet.com/ron/specials.pdf, especially page 6).
rg
Ron Garret <·········@flownet.com> writes:
> In article <···············@muvclx01.cadence.com>,
> ·····@runa.se (Bj�rn Lindberg) wrote:
>
> > Ron Garret <·········@flownet.com> writes:
> >
> > > In article <··············@thalassa.informatimago.com>,
> > > Pascal Bourguignon <···@informatimago.com> wrote:
> > >
> > > > Ron Garret <·········@flownet.com> writes:
> > > >
> > > > > In article <··············@thalassa.informatimago.com>,
> > > > > Pascal Bourguignon <···@informatimago.com> wrote:
> > > > >
> > > > >> Ron Garret <·········@flownet.com> writes:
> > > > >> > And how am I as a newcomer supposed to know all this?
> > > > >>
> > > > >> Using http://www.google.com/ ?
> > > > >> Browsing http://www.cliki.net/ ?
> > > > >> Asking on news:comp.lang.lisp ?
> > > > >> Asking on irf://irc.freenode.org/#lisp ?
> > > > >>
> > > > >> We've always welcomed such questions.
> > > > >
> > > > > Fair enough, but now put yourself in a newcomer's shoes and compare
> > > > > that
> > > > > situation to what happens when you type "Python" into Google.
> > > >
> > > > Try it. Python or Lisp. Both return all relevant links on the top of
> > > > the first page (the only links ever seen).
> > >
> > > The first link for "Python" is www.pythong.org, where the very first
> > > thing on the upper left hand corner of the screen is "Getting started".
> > > From there it is an almost linear path to getting Python up and running,
> > > with all its standard libraries. (In fact, "Download 2.4.2" and
> > > "Beginner's guide" show up as sub-links on the Google results page).
> > >
> > > The first result for "Lisp" is the ALU home page. The first thing on
> > > the upper left hand corner is "History." There are no implementations,
> > > no "getting started" link. It could hardly be more hostile to newcomers
> > > if it tried.
> > >
> > > You have to have some pretty serious blinders on not to appreciate the
> > > difference between these two experiences.
> >
> > Very well. But how would addressing your inital three points improve
> > this siutation? I am sure that you are right in your observation that
> > newbies are helped by beginner's documentation, but your initial
> > problem points did not touch upon that at all.
>
> The first one should be obvious: A set of standardized libraries would
> allow newcomers to write useful applications out of the box instead of
> having to spend time figuring out which combination of implementations
> and libraries will work for them.
Asdf has become the standard system definition facility, without any
institutionalized mechanism for change of the language. I suspect that
as CL gains momentum more libraries will reach such a status. Your
first point does not require anything that is not here today.
> The second issue I raised -- ((...) ...) syntax -- is really a surrogate
> to illustrate that some thing really do require a change to the
> language. A better example would have been the MOP, or the unresolved
> ANSI issues, or (my personal favorite) the lack of a real module system.
> (Packages are used instead, and this causes no end of confusion, even
> among experienced programmers.)
I like your first example, since it is so ridiculous. It shows the
dangers of opening up the language as a whole to just any change. One
of the values Common Lisp was built upon was that of legacy and
backwards compatibility. There are certainly many good things to be
gained from that, and the kind of cosmetic change you suggested runs
completely contrary to it. For people sharing your interest in
changing details of the language, creating a new dialect and trying to
get people interested in it would be much more appropriate. I suspect
that you do not do this because you percieve it to be easier to change
CL than to get the same level of interest for a new dialect. I think
that this is a mistaken belief, and that your chances of succeeding
with a new dialect are higher than your chances of changing Common
Lisp. I am happy about that, as I value stability and backwards
compatibility higher than correcting small cosmetic defects.
About packages then, I think that they fit in well with the dynamic
nature of Common Lisp and its macros, and I have never felt a need for
a module system in CL (though I see the value of them in other
languages).
Bj�rn
Bj�rn Lindberg wrote:
> Asdf has become the standard system definition facility, without any
> institutionalized mechanism for change of the language. I suspect that
> as CL gains momentum more libraries will reach such a status.
Yes. And I think there are problems with that. Earlier in this thread,
it was suggested that the equivalent to Python's
> $ python
>>>> import SimpleHTTPServer
>>>> SimpleHTTPServer.test()
> Serving HTTP on 0.0.0.0 port 8000 ...
might be
(asdf:oos 'asdf:load-op :araneida)
I can figure out what's going on in the Python code, even though I've
not used or studied Python. If much Python code were like that, I could
envision myself picking up the language just from reading example code.
The Lisp equivalent is, to someone who doesn't know Lisp, inscrutable.
Even to someone who does know ANSI CL, there's precious few clues as to
what might be going on, save that one verb 'load'. People might be
forgiven for thinking that the name ASDF is deliberately obtuse, often
standing as it does for a not-even-random keyboard riff when one doesn't
have the time or energy to actually convey meaning, and that Araneida
relies on one making the connection between latin names for spiders and
the habit of early web denizens to pun on spiders and webs, before
surfing became the preferred informal nomenclature.
This is a theme running through the libraries that slowly become
assimilated into the CL canon - they're named whimsically or eponomously
or with reference to the historical divide in the Lisp community that
the library bridges rather than much clue as to its actual function,
e.g. ACL-COMPAT. As such, we're building ourselves a language full of
self-referential puns and historical reminders, rather than the more
helpful simple verbs and nouns common in other programming languages.
For the old hand who only has to learn one of these words at a time, the
burden is not too great and the aides-memoire might bring back fond
memories of earlier periods in his Lisp career. For the newbie, the code
becomes completely inscrutable, not to mention the poor computer
historian two hundred years hence.
If there were some kind of change process, there might be a point in it
where someone said "That's a good implementation but a bad name. Let's
make it more self-explanatory since we control the namespace and this is
going to be the only officially endorsed library with this function."
Cameron MacKinnon <··········@clearspot.net> wrote:
+---------------
| Bj�rn Lindberg wrote:
| > Asdf has become the standard system definition facility...
|
| Yes. And I think there are problems with that. ...
...
| (asdf:oos 'asdf:load-op :araneida)
...
| The Lisp equivalent is, to someone who doesn't know Lisp, inscrutable.
+---------------
Which is why I have the following function in my "~/.cmucl-init"!! ;-}
;;; Save a bunch of typing:
(defun asdf (&rest systems)
(if systems
(dolist (system systems)
(asdf:operate 'asdf:load-op system))
;; ·@#$%^ "library:local/systems/*.asd" lists everything *twice*!
(let ((all-asd
(directory "/usr/local/lib/cmucl/lib/local/systems/*.asd")))
(format t "Available systems:~%~a~%"
(sort (mapcar #'pathname-name all-asd) #'string<)))))
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Ron Garret <·········@flownet.com> writes:
> The first result for "Lisp" is the ALU home page. The first thing on
> the upper left hand corner is "History." There are no implementations,
> no "getting started" link. It could hardly be more hostile to newcomers
> if it tried.
>
> You have to have some pretty serious blinders on not to appreciate the
> difference between these two experiences.
I appreciate the difference!
Short story: someone well-intentioned once decided that the lisp.org
web site should be about the Lisp language and the alu.org web site
should have content related to the ALU and Lisp community. The split
never really happened and the world was left with a mediocre web site
that can be hardly considered a good face for Lisp or the ALU.
In theory this problem shouldn't have been so difficult to correct,
but finding somebody who has the time and facility to reorganize the
web site, add an anesthetically pleasing facade, and do it all for
zero bucks, is difficult.
If anyone wants to put forth the effort to correct this problem I can
give anyone truly interested and committed the access to change the
lisp.org home page. (If this sounds like you, contact me privately.)
Ron Garret <·········@flownet.com> writes:
> In article <··············@deadspam.com>,
> ·············@deadspam.com (LuÃs Oliveira) wrote:
>
>> Ron Garret <·········@flownet.com> writes:
>> >> Please, tell me what matters in today's world so that I can work on
>> >> that.
>> >
>> > Sockets. Database connectivity. Threads.
>>
>> Ok, so let's tackle each one of those objectively:
>>
>> 1. Sockets. There are many simple compatibility layers including
>> trivial-sockets, the socket stuff in kmrcl, etc...
>>
>> There are also at least two more ambitious projects that I know of.
>> usockets and cffi-net. They are pursuing different approaches.
>> So, people are working on this.
>>
>>
>> 2. Database connectivity. We have CLSQL and a couple of others. From
>> what I hear, CLSQL supports more database backends than other
>> libraries in other popular languages (but I haven't confirmed this).
>>
>>
>> 3. Threads. Besides compatibility layers such as kmrcl and others,
>> there's bordeaux-mp.
>
>
> And how am I as a newcomer supposed to know all this?
>
> rg
By reading! By posting to comp.lang.lisp! By asking on #lisp! How
are you supposed to know _anything_ without going out and making an
effort to learn it?
In article <··············@rpi.edu>, Bill Atkins <············@rpi.edu>
wrote:
> Ron Garret <·········@flownet.com> writes:
>
> > In article <··············@deadspam.com>,
> > ·············@deadspam.com (LuΧs Oliveira) wrote:
> >
> >> Ron Garret <·········@flownet.com> writes:
> >> >> Please, tell me what matters in today's world so that I can work on
> >> >> that.
> >> >
> >> > Sockets. Database connectivity. Threads.
> >>
> >> Ok, so let's tackle each one of those objectively:
> >>
> >> 1. Sockets. There are many simple compatibility layers including
> >> trivial-sockets, the socket stuff in kmrcl, etc...
> >>
> >> There are also at least two more ambitious projects that I know of.
> >> usockets and cffi-net. They are pursuing different approaches.
> >> So, people are working on this.
> >>
> >>
> >> 2. Database connectivity. We have CLSQL and a couple of others. From
> >> what I hear, CLSQL supports more database backends than other
> >> libraries in other popular languages (but I haven't confirmed this).
> >>
> >>
> >> 3. Threads. Besides compatibility layers such as kmrcl and others,
> >> there's bordeaux-mp.
> >
> >
> > And how am I as a newcomer supposed to know all this?
> >
> > rg
>
> By reading! By posting to comp.lang.lisp! By asking on #lisp! How
> are you supposed to know _anything_ without going out and making an
> effort to learn it?
Well, for Python I can just go to www.python.org (the first result of a
Google search for "Python") and get all the code and information I need
to write complete web applications, including things like XML parsers,
regular expressions, etc. I don't have to find and visit half a dozen
web sites, decide between half a dozen implementations ,download and
install half a dozen packages, which may or may not all work with the
implementation I have chosen or with each other. There is a very
straightforward path with one-stop shopping.
Of course one has to make an effort. But for a newcomer the effort
required by Python is considerably less than that required for Lisp.
rg
Ron Garret <·········@flownet.com> writes:
> In article <··············@rpi.edu>, Bill Atkins <············@rpi.edu>
> wrote:
>
> Well, for Python I can just go to www.python.org (the first result of a
> Google search for "Python") and get all the code and information I need
> to write complete web applications, including things like XML parsers,
> regular expressions, etc. I don't have to find and visit half a dozen
> web sites, decide between half a dozen implementations ,download and
> install half a dozen packages, which may or may not all work with the
> implementation I have chosen or with each other. There is a very
> straightforward path with one-stop shopping.
OK. Try http://www.franz.com/
One-stop shopping for all of that stuff as well.
--
Thomas A. Russ, USC/Information Sciences Institute
Ron Garret <·········@flownet.com> writes:
>
> Well, for Python I can just go to www.python.org (the first result of
> a Google search for "Python") and get all the code and information I
> need to write complete web applications, including things like XML
> parsers, regular expressions, etc. I don't have to find and visit
> half a dozen web sites, decide between half a dozen implementations
> ,download and install half a dozen packages, which may or may not all
> work with the implementation I have chosen or with each other. There
> is a very straightforward path with one-stop shopping.
>
> Of course one has to make an effort. But for a newcomer the effort
> required by Python is considerably less than that required for Lisp.
Writing as someone who's been mildly interested in programming languages
in general and Lisp in particular for years, I can vouch for exactly
this difference. Until very recently it was simplicity itself to find
good, free, online introductions & tutorials for Python--meanwhile,
searches for Lisp material were never successful.
PCL was the first good Common Lisp introduction I found, and it was real
eye-opener.
I think that most free CL implementations seem to be written by experts
for experts--I remember downloading several and finding that not a
single one had any information to help someone just learning the
language. This is very different from just about every other language
out there.
With most languages, the fans want you to use the language and seem to
go out of their way to show you how and why; with Lisp it seems that
they just expect you to recognise how cool it is. Until PCL, that was
not really very clear...
--
Robert Uhl <http://public.xdi.org/=ruhl>
What, you don't think 'insmod emacs' is a good idea? --Joe Moore
Luís Oliveira wrote:
> Ron Garret <·········@flownet.com> writes:
> >> Please, tell me what matters in today's world so that I can work on
> >> that.
> 2. Database connectivity. We have CLSQL and a couple of others. From
> what I hear, CLSQL supports more database backends than other
> libraries in other popular languages (but I haven't confirmed this).
I used CLSQL for something a year or two ago. It didn't work- just
hung. A quick look at the source showed why- in the postgres socket
branch 'force-output' was never called. I guess that the implementation
that was used for writing that branch called it automatically. Mine
didn't. Lisp is terrible...
But wait a sec- I fixed it in about 5 minutes, and... it was an easy
bug to find, 'cause I could run it in the interpreter, and it was an
easy bug to fix 'cause the code wasn't alll *&····@ (and I say that as
a reasonably decent Perl programmer, but a lousy golfer). If you had
started using Perl in the early days you might have been called on to
fix some bugs too. I'm not personally a big fan of having to patch
things, but really... too many people these days think that programming
is a bit of glue between libraries.
Anyway, I don't even remember the code now, but I think we've done
several millions of dollars through that script, so... I think that
qualifies as real world.
In article <·······························@news.gha.chartermi.net>,
Ron Garret <·········@flownet.com> wrote:
> In article <··············@deadspam.com>,
> ·············@deadspam.com (Luís Oliveira) wrote:
>
> > Ron Garret <·········@flownet.com> writes:
> > >> > It is claimed that there are portable
> > >> > libraries that work across implementations that provide de facto
> > >> > standards, e.g. UFFI, but these claims are false.
> > >>
> > >> You probably don't mean what you say here. There are definitely portable
> > >> libraries out there. Maybe not for foreign function interfaces (I can't
> > >> judge this), but certainly for other things.
> > >
> > > Of course there are portable libraries, just not for the things that
> > > matter in today's world.
> >
> > Please, tell me what matters in today's world so that I can work on
> > that.
>
> Sockets. Database connectivity. Threads.
>
> rg
Lisp implementations have all these. Choose one.
--
http://lispm.dyndns.org/
In article <····························@news-europe.giganews.com>,
Rainer Joswig <······@lisp.de> wrote:
> In article <·······························@news.gha.chartermi.net>,
> Ron Garret <·········@flownet.com> wrote:
>
> > In article <····························@news-europe.giganews.com>,
> > Rainer Joswig <······@lisp.de> wrote:
> >
> > > In article <·······························@news.gha.chartermi.net>,
> > > Ron Garret <·········@flownet.com> wrote:
> > >
> > > > In article <··············@deadspam.com>,
> > > > ·············@deadspam.com (Luís Oliveira) wrote:
> > > >
> > > > > Ron Garret <·········@flownet.com> writes:
> > > > > >> > It is claimed that there are portable
> > > > > >> > libraries that work across implementations that provide de facto
> > > > > >> > standards, e.g. UFFI, but these claims are false.
> > > > > >>
> > > > > >> You probably don't mean what you say here. There are definitely
> > > > > >> portable
> > > > > >> libraries out there. Maybe not for foreign function interfaces (I
> > > > > >> can't
> > > > > >> judge this), but certainly for other things.
> > > > > >
> > > > > > Of course there are portable libraries, just not for the things
> > > > > > that
> > > > > > matter in today's world.
> > > > >
> > > > > Please, tell me what matters in today's world so that I can work on
> > > > > that.
> > > >
> > > > Sockets. Database connectivity. Threads.
> > > >
> > > > rg
> > >
> > > Lisp implementations have all these. Choose one.
> >
> > Fine. I choose MCL. How do I connect to a database?
> >
> > Or I choose CLisp. How do I get threads?
> >
> > Or I choose SBCL running on OS X. How do I get threads?
> >
> > rg
>
> Make a better choice.
I did. I chose Python.
rg
In article <······························@ram.dialup.fu-berlin.de>,
···@zedat.fu-berlin.de (Stefan Ram) wrote:
> Rainer Joswig <······@lisp.de> writes:
> >> Sockets. Database connectivity. Threads.
> >Lisp implementations have all these. Choose one.
>
> Not /implementations/ are requested, but a /standard/
> /specification/ for the /interface/ of such components.
Thank you. Sometimes when the arrows are flying I forget to keep my eye
on the ball (if you'll pardon a mixed metaphor).
rg
Ron Garret <·········@flownet.com> wrote:
+---------------
| ·············@deadspam.com (Luís Oliveira) wrote:
| > Please, tell me what matters in today's world so that I
| > can work on that.
|
| Sockets. Database connectivity. Threads.
+---------------
Which is why I love Lisp!! For my very first serious production
Common Lisp app[1] I whipped up a persistent application server
behind Apache, connecting with a "mod_lisp"-like protocol via
Unix-domain sockets to CMUCL -- creating a new CMUCL thread for
each HTTP request -- talking to PostgreSQL with Eric Marsden's
PG library. [And Tim Bradshaw's HTOUT, though you didn't ask
about HTML generation...] All of my time was spent on making
my app do the right *application* stuff [and a certain amount of
web-page design tweaking]; the socket/SQL/thread stuff "just worked".
So... What was the problem again?
-Rob
[1] Written in Fall 2002/Winter 2003, and still running. The CMUCL
server runs continuously [except when they take the co-lo host
down for some kind of maintenance], and I've updated the app
several times without stopping or reloading it. It just keeps
runnning & running & running..
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Rob Warnock wrote:
> Ron Garret <·········@flownet.com> wrote:
> +---------------
> | ·············@deadspam.com (Luís Oliveira) wrote:
> | > Please, tell me what matters in today's world so that I
> | > can work on that.
> |
> | Sockets. Database connectivity. Threads.
> +---------------
>
> Which is why I love Lisp!! For my very first serious production
> Common Lisp app[1] I whipped up a persistent application server
> behind Apache, connecting with a "mod_lisp"-like protocol via
> Unix-domain sockets to CMUCL -- creating a new CMUCL thread for
> each HTTP request
This, honestly, would make me nervous- that's not necessarily a
criticism though- could just be that I am overly conservative about
things like this. How many page views do you serve in a day? I am
developing a new lisp based system like this and have chosen to use
lispworks, partially because $1000.00 (x a few servers) is a small
price to pay to have someone to complain to if things go wrong ;). I am
a bit wary of CMUCL's threading- I just don't want to be the first
person to exercise it really heavily.
I have to serve at least half a million page views a day through this
system, and maybe as many as a million, but they are not evenly
distributed- 75% of the page views will come between 1 PM and 8 PM EST,
with the bulk of that falling between 2PM and 5 PM.
That would be a pretty light load if we were serving flat html, but
some of this is inherently dynamic, and requires a database call (I am
also using postgres) for each request. No matter what else I do, I will
have to pool connections. I think I may have as much experience as
anyone else in the world when it comes to dealing with really high load
on a postgres installation. My experience is with 7.x, so it may be
moot with the 8.x release, but it tells me that making connections to
postgres is really expensive- if you don't pool connections, and you
are using postgres, you should probably not worry about optimizing
anything else (unless you are doing something ridiculously expensive in
your code).
I don't take a lot of the criticisms of CL made in this thread very
seriously- many of them seem to me to be comparable to the difficulties
that you would have with any language/implementation. But it would be
nice to see a really good DB library with connection pooling. The
obvious response is that I should write it (maybe as an add-on to
clsql), for my project, and then contribute it, but there are some
difficulties there, that I can't go into beyond saying that it would be
hard to get that approved. Never let it be said that I lit a candle
rather than cursing the darkness ;).
Tagore Smith <······@tagoresmith.com> wrote:
+---------------
| Rob Warnock wrote:
| > Ron Garret <·········@flownet.com> wrote:
| > +---------------
| > | Sockets. Database connectivity. Threads.
| > +---------------
| >
| > Which is why I love Lisp!! For my very first serious production
| > Common Lisp app[1] I whipped up a persistent application server
| > behind Apache, connecting with a "mod_lisp"-like protocol via
| > Unix-domain sockets to CMUCL -- creating a new CMUCL thread for
| > each HTTP request
|
| This, honestly, would make me nervous- that's not necessarily a
| criticism though- could just be that I am overly conservative about
| things like this. How many page views do you serve in a day?
+---------------
Dunno, probably a peak of 2-3/s, which would would be ~200K/day,
except that such peaks tend to be only a few minutes in length
at most, so it's probably more like a few K/day on average.
"Very light", in other words. ;-} ;-}
+---------------
| I am developing a new lisp based system like this and have chosen to
| use lispworks, partially because $1000.00 (x a few servers) is a small
| price to pay to have someone to complain to if things go wrong ;).
+---------------
That's your decision. I was doing the work pro-bono for a non-profit
that didn't have any money at all to spend on the project, so free
tools were a consideration. And I'd already been using CMUCL for some
time on other stuff, so I was reasonably comfortable with it.
+---------------
| I am a bit wary of CMUCL's threading- I just don't want to be the
| first person to exercise it really heavily.
+---------------
Again, that's certainly your prerogative, though as part of my
development I stressed it fairly hard (~80 HTTP req/s) with no
issues that I could see. And I'm still using a slow development
hack that fork/execs a small C-based CGI trampoline per request.
Using real "mod_lisp" people have reported *much* better performance
than that -- e.g., >500 req/s or more [including dynamic HTML
construction but excluding database accesses].
+---------------
| I have to serve at least half a million page views a day through
| this system, and maybe as many as a million, but they are not evenly
| distributed- 75% of the page views will come between 1 PM and 8 PM EST,
| with the bulk of that falling between 2PM and 5 PM.
+---------------
That's not too bad. Assuming half your traffic is during the peak
three hours, that's 0.5 Mreq in 10800 s, or ~46 req/s.
+---------------
| That would be a pretty light load if we were serving flat html, but
| some of this is inherently dynamic, and requires a database call
| (I am also using postgres) for each request. No matter what else I
| do, I will have to pool connections.
+---------------
Clearly! On the server I used for the above, starting up a new
SQL connection takes ~250 ms [PostgreSQL 7.3.x], so even the
modest performance needs mentioned above required at least minimal
connection pooling, in this case re-using the same connection for
all SQL accesses during a single HTTP request. [Yes, the first
cut didn't even do *that*! But I was still learning SQL... ;-} ]
+---------------
| I think I may have as much experience as anyone else in the world
| when it comes to dealing with really high load on a postgres
| installation. My experience is with 7.x, so it may be moot with
| the 8.x release, but it tells me that making connections to postgres
| is really expensive- if you don't pool connections, and you are
| using postgres, you should probably not worry about optimizing
| anything else (unless you are doing something ridiculously expensive
| in your code).
+---------------
Based on my limited experience [see above], I agree completely,
though I've not yet been forced to work very hard at pooling.
Paying a single 250ms SQL connection cost for an HTTP request
that does at most a dozen SQL accesses was acceptable in the
above application, though it clearly would not be in yours.
+---------------
| I don't take a lot of the criticisms of CL made in this thread very
| seriously- many of them seem to me to be comparable to the difficulties
| that you would have with any language/implementation. But it would be
| nice to see a really good DB library with connection pooling.
+---------------
I used Eric Marsden's "Pg" library <http://www.cliki.net/Pg>, which
speaks the PostgreSQL socket protocol directly, and found it very
straightforward to use... and to understand, the once or twice I
had to look "under the covers". You might find that adding the
pooling you need to it would be simple enough. I would have already
added cross-request pooling myself except that the performance of
the web site was already "good enough" without it.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
"Tagore Smith" <······@tagoresmith.com> writes:
> I don't take a lot of the criticisms of CL made in this thread very
> seriously- many of them seem to me to be comparable to the difficulties
> that you would have with any language/implementation. But it would be
> nice to see a really good DB library with connection pooling.
Like CLSQL perhaps? Here's what i do to make sure each thread gets its
own connection (from the pool, in araneida) :
;;;; *** Allocate one database connection per request :
(defmethod araneida:handle-request-response
:around ((handler ucw::ucw-handler) method request)
(clsql:with-database (my-db '("localhost" "sunrise" "sunrise" "sr01")
:pool t)
(clsql:with-default-database (my-db)
(call-next-method))))
> The
> obvious response is that I should write it (maybe as an add-on to
> clsql),
Actually, the obvious response (IMHO) is to use the existing pooled
connection support in clsql.
try: http://clsql.b9.com/manual/connect.html
cheers,
drewc
Ron Garret wrote:
>>>....
Sorry to point on obvious, but there is no
such thing like "Perfect Language" in existence.
So all and every language is sucks on their own
way.
From my perspective, I find CL a very good complement
to my toolbox, which include Fortran for numerics and
C for system tasks and interfacing.
PS.from my experience cross compiler portability for
any significant project is an urban legend.
dg
--
*It is easy to lie with statistics, but it's a lot easier to lie without
them.
In article <············@emma.aioe.org>,
Dmitry Gorbatovsky <········@yahoo.com> wrote:
> Ron Garret wrote:
> >>>....
>
> Sorry to point on obvious, but there is no
> such thing like "Perfect Language" in existence.
> So all and every language is sucks on their own
> way.
Of course. Nothing is ever perfect. But that's no excuse for not
trying to improve things.
> PS.from my experience cross compiler portability for
> any significant project is an urban legend.
Cross-compiler portability for C and C++ is pretty good. It's even
pretty good for CL as long as you don't have to interface with the
outside world, which is exactly the problem.
rg
Ron Garret wrote:
> Of course. Nothing is ever perfect. But that's no excuse for not
> trying to improve things.
Isn't this exactly the much criticised Scheme way of doing things?
Schneewittchen
In article <·······················@i39g2000cwa.googlegroups.com>,
"F�rster vom Silberwald" <··········@hotmail.com> wrote:
> Ron Garret wrote:
>
> > Of course. Nothing is ever perfect. But that's no excuse for not
> > trying to improve things.
>
> Isn't this exactly the much criticised Scheme way of doing things?
Is it? Scheme actually changes from time to time, albeit slowly. I
think the problem with Scheme is that nothing ever gets in until it is
perceived to be perfect. That makes for very slow progress.
rg
Ron Garret wrote:
> In article <·······················@i39g2000cwa.googlegroups.com>,
> "F�rster vom Silberwald" <··········@hotmail.com> wrote:
>
>> Ron Garret wrote:
>>
>>> Of course. Nothing is ever perfect. But that's no excuse for not
>>> trying to improve things.
>> Isn't this exactly the much criticised Scheme way of doing things?
>
> Is it? Scheme actually changes from time to time, albeit slowly. I
> think the problem with Scheme is that nothing ever gets in until it is
> perceived to be perfect. That makes for very slow progress.
One problem with Scheme is that code that is about 10 years old or older
doesn't work anymore. I am not making this up - I wanted to understand
the code that was presented in an appendix of a paper by simply trying
it out. I basically had to reimplement a considerable amount from
scratch because the semantics of the macro system used has changed in
between and it wasn't documented how.
Of course, it is not a goal of Scheme to be backwards compatible, so
this is not a criticism of Scheme, but a criticism of its goals.
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
Ron Garret wrote:
> Is it? Scheme actually changes from time to time, albeit slowly. I
> think the problem with Scheme is that nothing ever gets in until it is
> perceived to be perfect. That makes for very slow progress.
I am not an active Lisp user. However, I regularily watch
comp.lang.lisp (once you are used to comp.lang.lisp it turns out really
very friendly and informative as opposed to lets say fucking
comp.lang.python).
However, as a Bigloo user I wondered all day long after reading the
blog: was the blogger talking about Scheme or Common Lisp.
What are now the differences between Common Lisp (Lisp) and Scheme when
we take all aspects (portability, different user system architectures,
etc.) into account.
I always thought Common Lisp doesn't have all the (alleged) problems
such as Scheme.
The discussions recently came suprisingly at least for me.
Schneewittchen
F�rster vom Silberwald wrote:
> Ron Garret wrote:
>
>> Is it? Scheme actually changes from time to time, albeit slowly. I
>> think the problem with Scheme is that nothing ever gets in until it is
>> perceived to be perfect. That makes for very slow progress.
>
> I am not an active Lisp user. However, I regularily watch
> comp.lang.lisp (once you are used to comp.lang.lisp it turns out really
> very friendly and informative as opposed to lets say fucking
> comp.lang.python).
>
> However, as a Bigloo user I wondered all day long after reading the
> blog: was the blogger talking about Scheme or Common Lisp.
>
> What are now the differences between Common Lisp (Lisp) and Scheme when
> we take all aspects (portability, different user system architectures,
> etc.) into account.
>
> I always thought Common Lisp doesn't have all the (alleged) problems
> such as Scheme.
>
> The discussions recently came suprisingly at least for me.
It's a gradual thing, not an either/or thing. (That's why we also don't
an earth-shattering sudden change, but a healthy evolutionary growth.)
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
Ron Garret <·········@flownet.com> writes:
> In article <············@emma.aioe.org>,
> Dmitry Gorbatovsky <········@yahoo.com> wrote:
>
>> Ron Garret wrote:
>> >>>....
>>
>> Sorry to point on obvious, but there is no
>> such thing like "Perfect Language" in existence.
>> So all and every language is sucks on their own
>> way.
>
> Of course. Nothing is ever perfect. But that's no excuse for not
> trying to improve things.
>
>> PS.from my experience cross compiler portability for
>> any significant project is an urban legend.
>
> Cross-compiler portability for C and C++ is pretty good. It's even
> pretty good for CL as long as you don't have to interface with the
> outside world, which is exactly the problem.
I don't think so. Try to link a library compiled for the Darwin/ppc
virtual machine with your program compiled for the Linux/x86 virtual
machine.
By the same token, it's hard to interface a library compiled for the
SBCL/x86 virtual machine with a program compiled for the clisp virtual
machine. Or a library compiled for the Linux/x86 virtual machine with
a program compiled for the clisp virtual machine, even if it's easier
(and possible) than linking a library compiled for the SBCL/x86
virtual machine.
I'd love to see them C programmers struggling in a world of Lisp
Machines...
--
__Pascal Bourguignon__ http://www.informatimago.com/
This is a signature virus. Add me to your signature and help me to live.
In article <··············@thalassa.informatimago.com>,
Pascal Bourguignon <···@informatimago.com> wrote:
> Ron Garret <·········@flownet.com> writes:
>
> > In article <············@emma.aioe.org>,
> > Dmitry Gorbatovsky <········@yahoo.com> wrote:
> >
> >> Ron Garret wrote:
> >> >>>....
> >>
> >> Sorry to point on obvious, but there is no
> >> such thing like "Perfect Language" in existence.
> >> So all and every language is sucks on their own
> >> way.
> >
> > Of course. Nothing is ever perfect. But that's no excuse for not
> > trying to improve things.
> >
> >> PS.from my experience cross compiler portability for
> >> any significant project is an urban legend.
> >
> > Cross-compiler portability for C and C++ is pretty good. It's even
> > pretty good for CL as long as you don't have to interface with the
> > outside world, which is exactly the problem.
>
> I don't think so. Try to link a library compiled for the Darwin/ppc
> virtual machine with your program compiled for the Linux/x86 virtual
> machine.
>
> By the same token, it's hard to interface a library compiled for the
> SBCL/x86 virtual machine with a program compiled for the clisp virtual
> machine. Or a library compiled for the Linux/x86 virtual machine with
> a program compiled for the clisp virtual machine, even if it's easier
> (and possible) than linking a library compiled for the SBCL/x86
> virtual machine.
You are confusing cross-compiler portability (which is not uncommon)
with cross-architecture portability (which is virtually non-existent).
These are not the same thing.
rg
Ron Garret <·········@flownet.com> writes:
>> > Cross-compiler portability for C and C++ is pretty good. It's even
>> > pretty good for CL as long as you don't have to interface with the
>> > outside world, which is exactly the problem.
>>
>> I don't think so. Try to link a library compiled for the Darwin/ppc
>> virtual machine with your program compiled for the Linux/x86 virtual
>> machine.
>>
>> By the same token, it's hard to interface a library compiled for the
>> SBCL/x86 virtual machine with a program compiled for the clisp virtual
>> machine. Or a library compiled for the Linux/x86 virtual machine with
>> a program compiled for the clisp virtual machine, even if it's easier
>> (and possible) than linking a library compiled for the SBCL/x86
>> virtual machine.
>
> You are confusing cross-compiler portability (which is not uncommon)
> with cross-architecture portability (which is virtually non-existent).
> These are not the same thing.
No, I'm not. I'm arguing that each Lisp implementation is another
virtual machine.
Can you use the python compiler inside cmucl to compile a CL program
and run it on clisp virtual machine? No, no more than you can use
Intel C compiler to compile a C program and run it on Darwin/ppc
virtual machine, and no more than you can use Watcom C compiler (which
targets the MS-Windows/x86 virtual machine) and run the program on
Linux/x86 virtual machine.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"Specifications are for the weak and timid!"
Pascal Bourguignon <···@informatimago.com> writes:
> No, I'm not. I'm arguing that each Lisp implementation is another
> virtual machine.
Explaining the reason of lack of interoperability on this level
doesn't help in archieving it.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
In article <··············@thalassa.informatimago.com>,
Pascal Bourguignon <···@informatimago.com> wrote:
>Ron Garret <·········@flownet.com> writes:
>
>> Cross-compiler portability for C and C++ is pretty good. It's even
>> pretty good for CL as long as you don't have to interface with the
>> outside world, which is exactly the problem.
>
>I don't think so. Try to link a library compiled for the Darwin/ppc
>virtual machine with your program compiled for the Linux/x86 virtual
>machine.
I can't tell if this response was just meant to be silly or not;
apologies if misunderstood. I bet the original poster meant source
portability, not attempting to link shared objects from different
platforms into one executable..
Source cross-compiler portability for C and C++ is indeed quite good.
In my day job my product is largely C/C++ (with parts in Java and a
smattering of scripting languages around the edges). While I do all my
work on Solaris, the product ships on at least 5 different OS's across
several hardware architectures, using different compilers on every
platform. It is not a problem.
>By the same token, it's hard to interface a library compiled for the
>SBCL/x86 virtual machine with a program compiled for the clisp virtual
>machine.
And yet it is not a problem with Java (or perl/python/ruby/..). In my
free time I sometimes write code for friends, some of whom run windows
(they are decent people otherwise). As I don't own any windows
machines at home, I write such code in Java, compile it into class
files on either Linux, Solaris or OS X and send the jar files to
friends who run the applications on windows. It Just Works. Is there
any way I can pull this off using lisp? (Serious question, I'd love to try!)
None of this is meant to detract from lisp. Lisp is fun and I'm
enjoying it a lot. But if we're going to compare languages, it's good
to be objectively honest about the facts. Some of the problems with
lisp are non-issues in other languages. Of course it cuts both ways,
obnoxious problems in other languages can become non-issues in lisp.
--
Jyri J. Virkki - Santa Cruz, CA
·······@localhost.localdomain (Jyri J. Virkki) writes:
> In article <··············@thalassa.informatimago.com>,
> Pascal Bourguignon <···@informatimago.com> wrote:
>>Ron Garret <·········@flownet.com> writes:
>>
>>> Cross-compiler portability for C and C++ is pretty good. It's even
>>> pretty good for CL as long as you don't have to interface with the
>>> outside world, which is exactly the problem.
>>
>>I don't think so. Try to link a library compiled for the Darwin/ppc
>>virtual machine with your program compiled for the Linux/x86 virtual
>>machine.
>
> I can't tell if this response was just meant to be silly or not;
> apologies if misunderstood. I bet the original poster meant source
> portability, not attempting to link shared objects from different
> platforms into one executable..
Yes, I was answering to the general meaning of the message, not
necessarily to the exact formal sentences.
What I mean is that people find that it's easy to link and use
libraries with their C programs, and then are surprised that it may
not be so easy to use libraries in various CL implementations. Ron
expressed this.
The reason is that while the C "environment" is one "virtual" machine,
where all the libraries and compilers are integrated into it, each of
the CL implementation is its own "virtual" machine. Even CL compilers
that target a native processor still have a garbage collector and data
structure formats that are totally different from those of the
programming language implementations that target vanilla OS/processor
"virtual" machine. This explains why library interoperability is hard
between CL implementations, and why library interoperability is hard
between a given CL implementation and the other common "virtual"
machines.
We may have good FFI (Clisp FFI or CFFI), but we cannot use directly C
headers because the semantics are incompatible: we need to hand-write
the FFI definitions to do the gateway. C libraries cannot directly
use our data, we need to translate it for them because they target the
standard OS/processor "virtual" machines instead of targeting the
"Lisp Machines" on which CL implementations run.
Actually, this is the same kind of problems with have with the
different object models. You cannot easily use Objective-C libraries
with Eiffel, ObjectPascal, Java or C++, because they target different
"virtual" machines, even if they run on the same processor. Sometimes
you can use C as a gateway between objects written in different
languages (eg ObjC++), but that's all.
> [...]
> And yet it is not a problem with Java (or perl/python/ruby/..). In my
> free time I sometimes write code for friends, some of whom run windows
> (they are decent people otherwise). As I don't own any windows
> machines at home, I write such code in Java, compile it into class
> files on either Linux, Solaris or OS X and send the jar files to
> friends who run the applications on windows. It Just Works. Is there
> any way I can pull this off using lisp? (Serious question, I'd love to try!)
Well, you could use ABCL, which targets the JVM.
Another solution would be to define a LVM and implement it ubiquituously.
> None of this is meant to detract from lisp. Lisp is fun and I'm
> enjoying it a lot. But if we're going to compare languages, it's good
> to be objectively honest about the facts. Some of the problems with
> lisp are non-issues in other languages. Of course it cuts both ways,
> obnoxious problems in other languages can become non-issues in lisp.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Small brave carnivores
Kill pine cones and mosquitoes
Fear vacuum cleaner
·······@localhost.localdomain (Jyri J. Virkki) writes:
> >By the same token, it's hard to interface a library compiled for the
> >SBCL/x86 virtual machine with a program compiled for the clisp virtual
> >machine.
> And yet it is not a problem with Java (or perl/python/ruby/..). In my
> free time I sometimes write code for friends, some of whom run windows
> (they are decent people otherwise). As I don't own any windows
> machines at home, I write such code in Java, compile it into class
> files on either Linux, Solaris or OS X and send the jar files to
> friends who run the applications on windows. It Just Works. Is there
> any way I can pull this off using lisp? (Serious question, I'd love to try!)
Well, if you count perl & python & ruby in this list, then you either
distribute source code, or you count on a particular version of perl
or python on both sides to be able to read your .pyc (Python compiled
files). So why wouldn't you distribute .lisp source files?
There was a time where CLISP's compiled .fas file could be exchanged
between different systems (of the same version, but never the .mem
image files, unlike Smalltalk). If it doesn't wok nowadays (I haven't
tried), it's because nobody was interested in this feature. You could
try to make a case for this.
I'm sure there are quite some people here which mix&match the code
they write between MS-Window, Linux and MacOS, without trouble
(granted, after they added some infrastructure, e.g. libraries).
Regards,
Jorg Hohle
Telekom/T-Systems Technology Center
Joerg Hoehle <······@users.sourceforge.net> writes:
> There was a time where CLISP's compiled .fas file could be exchanged
> between different systems (of the same version, but never the .mem
> image files, unlike Smalltalk). If it doesn't wok nowadays (I haven't
> tried), it's because nobody was interested in this feature.
IME, it does. (not that I've ever specifically needed it, but the
various defaults being what they are -- non-platform-specific fasl
file extension (".fas") and no platform-specific fasl directories in
ASDF -- sort of forced me to rely on this).
cheers,
--m
Ron Garret wrote:
> In article <············@emma.aioe.org>,
> Dmitry Gorbatovsky <········@yahoo.com> wrote:
>
>> Ron Garret wrote:
>> >>>....
>>
>> Sorry to point on obvious, but there is no
>> such thing like "Perfect Language" in existence.
>> So all and every language is sucks on their own
>> way.
>
> Of course. Nothing is ever perfect. But that's no excuse for not
> trying to improve things.
I mean that among other industrial solutions CL is a leader, taking on the
account expressiveness/standardization/efficiency/flexibility in equal
proportions.
If one biased toward one of that or other criteria, one may find another
solution.
>> PS.from my experience cross compiler portability for
>> any significant project is an urban legend.
> Cross-compiler portability for C and C++ is pretty good. It's even
> pretty good for CL as long as you don't have to interface with the
> outside world, which is exactly the problem.
I mean that porting any significant project to another compiler is a non
trivial effort in a majority of situations.And in any case it "generally
means writing an awful lot of #+ reader macros" or something equal awful.
Indeed CL would be much better tool if implement standart "interface with
the outside world". Agree on 100%.
I am not raising my voice on the matter since don't have knowledge nor
resources for that kind of task.
dg
--
*Maybe it's a hard idea to grasp, but there are people who choose Common
Lisp because it is the way it is.
Pascal Costanza
Ron Garret <·········@flownet.com> writes:
>
> 1. CL lacks standardized support for many operations that are
> necessities in today's world (e.g. sockets, database connectivity,
> foreign functions). Moreover, it lacks any mechanism by which these
> features could be standardized. It is claimed that there are portable
> libraries that work across implementations that provide de facto
> standards, e.g. UFFI, but these claims are false. I don't have time to
> get into details at the moment, but the fact of the matter is that
> trying to use Lisp for e.g. writing a Web server is an incredibly
> painful experience compared to doing the same thing in e.g. Python.
Very funny, I don't know of any standardization in C about Sockets,
Database connectivity and probably a few others, does that harm the
success of C? That it just happens that the modern scripting languages
have this stuff is nice, but none of them has anything but a reference
implementation.
>
> The Balkanization of the CL implementation space also has the
> consequence that one must choose between using implementation-specific
> features and thus limiting the potential audience for one's code to a
> niche within a niche, or writing to the least common denominator, which
> generally means writing an awful lot of #+ reader macros.
So what if you don't care about it what stop you from choosing one
implementation and "use" it?
Regards
Friedrich
--
Please remove just-for-news- to reply via e-mail.
Ron Garret wrote:
> 1. The details of my criticisms are mostly irrelevant. What matters is
> that CL is far from perfect, and that it has no mechanism for change.
> So don't bother picking a nit about one of my specific criticisms unless
> you wish to argue that CL is perfect and doesn't need to change.
Here is another thought: For important branches of industry, it is an
absolutely safe bet to base your software solutions on Java, Eclipse,
Enterprise JavaBeans and the apache web server. Other popular
technologies include Python and apparently Ruby. None of these
technologies have an officially sanctioned mechanism for change: Java is
basically controlled by Sun, Eclipse by IBM and Python and Ruby by their
respective designers. (I am not so sure about apache.) Try suggesting to
add macros to Java, a Lisp-based scripting language to Eclipse, closures
to Python, or multiple dispatch to Ruby.
The gist of this is that an official mechanism for changing a technology
is _not_ what makes a technology successful. What makes a technology
successful is the notion of a "killer application": For Java, it was
applets, for Ruby it's Ruby on Rails, for Python Zope (?), for Eclipse
and apache the respective software itself, for Perl processing cgi
requests, for C direct access to the operating system, and so on.
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
In article <··············@individual.net>,
Pascal Costanza <··@p-cos.net> wrote:
> Ron Garret wrote:
>
> > 1. The details of my criticisms are mostly irrelevant. What matters is
> > that CL is far from perfect, and that it has no mechanism for change.
> > So don't bother picking a nit about one of my specific criticisms unless
> > you wish to argue that CL is perfect and doesn't need to change.
>
> Here is another thought: For important branches of industry, it is an
> absolutely safe bet to base your software solutions on Java, Eclipse,
> Enterprise JavaBeans and the apache web server. Other popular
> technologies include Python and apparently Ruby. None of these
> technologies have an officially sanctioned mechanism for change:
Of course they do. How else do you think they advanced beyond version
1.0?
> Java is
> basically controlled by Sun, Eclipse by IBM and Python and Ruby by their
> respective designers. (I am not so sure about apache.) Try suggesting to
> add macros to Java, a Lisp-based scripting language to Eclipse, closures
> to Python, or multiple dispatch to Ruby.
Python actually *did* add closures in version 2.2.
Are you the same Pascal Costanza who took SteveY to task for criticizing
Lisp from a position of ignorance?
> The gist of this is that an official mechanism for changing a technology
> is _not_ what makes a technology successful.
In light of the above, do you want to rethink this claim?
> What makes a technology
> successful is the notion of a "killer application":
No doubt this helps. But it remains an open question which of these are
necessary, which are sufficient, and which are merely helpful.
So where is CL's killer app?
rg
Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> writes:
> Pascal Costanza <··@p-cos.net> writes:
>
> >> Python actually *did* add closures in version 2.2.
> >
> > ...and removed them again in a later version. Guido van Rossum
> > thinks they suck, so they won't be part of Python anymore.
>
> Python hasn't removed anything related to closures. I have no idea
> what are you talking about.
Indeed.
>
> There are plans to remove 'lambda' eventually.
Not any more.
'as
Alexander Schmolck wrote:
> Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> writes:
>
>> Pascal Costanza <··@p-cos.net> writes:
>>
>>>> Python actually *did* add closures in version 2.2.
>>> ...and removed them again in a later version. Guido van Rossum
>>> thinks they suck, so they won't be part of Python anymore.
>> Python hasn't removed anything related to closures. I have no idea
>> what are you talking about.
>
> Indeed.
I had "anonymous closures" in mind when I have written "closures." Sorry.
>> There are plans to remove 'lambda' eventually.
>
> Not any more.
Interesting. How come?
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
Pascal Costanza wrote:
> Alexander Schmolck wrote:
> > Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> writes:
> >> There are plans to remove 'lambda' eventually.
> >
> > Not any more.
>
> Interesting. How come?
http://mail.python.org/pipermail/python-dev/2006-February/060415.html
see also
http://www.artima.com/weblogs/viewpost.jsp?thread=147358
-Jonathan
Ron Garret wrote:
> In article <··············@individual.net>,
> Pascal Costanza <··@p-cos.net> wrote:
>
>> Ron Garret wrote:
>>> In article <··············@individual.net>,
>>> Pascal Costanza <··@p-cos.net> wrote:
>>>
>>>> Ron Garret wrote:
>>>>
>>>>> 1. The details of my criticisms are mostly irrelevant. What matters is
>>>>> that CL is far from perfect, and that it has no mechanism for change.
>>>>> So don't bother picking a nit about one of my specific criticisms unless
>>>>> you wish to argue that CL is perfect and doesn't need to change.
>>>> Here is another thought: For important branches of industry, it is an
>>>> absolutely safe bet to base your software solutions on Java, Eclipse,
>>>> Enterprise JavaBeans and the apache web server. Other popular
>>>> technologies include Python and apparently Ruby. None of these
>>>> technologies have an officially sanctioned mechanism for change:
>>> Of course they do. How else do you think they advanced beyond version
>>> 1.0?
>> My impression was that you want to have a say in what should change in
>> Common Lisp or not. Yes, these projects have moved beyond 1.0, but do
>> you really think you would be able to convince them to make significant
>> changes?
>
> Certainly having a say would be nice all else being equal. But that has
> never been my primary goal (notwithstanding all the people out there who
> are convinced that this is all just a big ego trip for me). Actually,
> it's becoming less and less of a consideration all the time. I'm frying
> other fish now. The only reason I'm even engaging in this discussion is
> (as I've said) that I thought SteveY is making valid points that are
> being overshadowed by (irrelevant) technical errors.
>
>>>> Java is
>>>> basically controlled by Sun, Eclipse by IBM and Python and Ruby by their
>>>> respective designers. (I am not so sure about apache.) Try suggesting to
>>>> add macros to Java, a Lisp-based scripting language to Eclipse, closures
>>>> to Python, or multiple dispatch to Ruby.
>>> Python actually *did* add closures in version 2.2.
>> ...and removed them again in a later version. Guido van Rossum thinks
>> they suck, so they won't be part of Python anymore.
>
> So what? The fact that the outcome of their process is not what you or
> I might have liked does not change the fact that they have a process.
You missed the important point here: These technologies are controlled
by their respective "authorities" (think: "benevolent" dictators). By
definition, there is no process that gives users a vote in how the
respective technologies should be changed (other than by convincing the
respective authority).
I don't think that's what you want for Common Lisp. I certainly wouldn't
want it.
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
In article <··············@individual.net>,
Pascal Costanza <··@p-cos.net> wrote:
> Ron Garret wrote:
> > In article <··············@individual.net>,
> > Pascal Costanza <··@p-cos.net> wrote:
> >
> >> Ron Garret wrote:
> >>> In article <··············@individual.net>,
> >>> Pascal Costanza <··@p-cos.net> wrote:
> >>>
> >>>> Ron Garret wrote:
> >>>>
> >>>>> 1. The details of my criticisms are mostly irrelevant. What matters
> >>>>> is
> >>>>> that CL is far from perfect, and that it has no mechanism for change.
> >>>>> So don't bother picking a nit about one of my specific criticisms
> >>>>> unless
> >>>>> you wish to argue that CL is perfect and doesn't need to change.
> >>>> Here is another thought: For important branches of industry, it is an
> >>>> absolutely safe bet to base your software solutions on Java, Eclipse,
> >>>> Enterprise JavaBeans and the apache web server. Other popular
> >>>> technologies include Python and apparently Ruby. None of these
> >>>> technologies have an officially sanctioned mechanism for change:
> >>> Of course they do. How else do you think they advanced beyond version
> >>> 1.0?
> >> My impression was that you want to have a say in what should change in
> >> Common Lisp or not. Yes, these projects have moved beyond 1.0, but do
> >> you really think you would be able to convince them to make significant
> >> changes?
> >
> > Certainly having a say would be nice all else being equal. But that has
> > never been my primary goal (notwithstanding all the people out there who
> > are convinced that this is all just a big ego trip for me). Actually,
> > it's becoming less and less of a consideration all the time. I'm frying
> > other fish now. The only reason I'm even engaging in this discussion is
> > (as I've said) that I thought SteveY is making valid points that are
> > being overshadowed by (irrelevant) technical errors.
> >
> >>>> Java is
> >>>> basically controlled by Sun, Eclipse by IBM and Python and Ruby by their
> >>>> respective designers. (I am not so sure about apache.) Try suggesting to
> >>>> add macros to Java, a Lisp-based scripting language to Eclipse, closures
> >>>> to Python, or multiple dispatch to Ruby.
> >>> Python actually *did* add closures in version 2.2.
> >> ...and removed them again in a later version. Guido van Rossum thinks
> >> they suck, so they won't be part of Python anymore.
> >
> > So what? The fact that the outcome of their process is not what you or
> > I might have liked does not change the fact that they have a process.
>
> You missed the important point here: These technologies are controlled
> by their respective "authorities" (think: "benevolent" dictators). By
> definition, there is no process that gives users a vote in how the
> respective technologies should be changed (other than by convincing the
> respective authority).
Their process isn't democratic, but it is a process nonetheless.
> I don't think that's what you want for Common Lisp. I certainly wouldn't
> want it.
Sure, but anarchy is not the only alternative to dictatorship.
rg
Ron Garret wrote:
>> You missed the important point here: These technologies are controlled
>> by their respective "authorities" (think: "benevolent" dictators). By
>> definition, there is no process that gives users a vote in how the
>> respective technologies should be changed (other than by convincing the
>> respective authority).
>
> Their process isn't democratic, but it is a process nonetheless.
With very obvious downsides. Consider the replacement of the once
nearly-defacto-standard for containers in Java with the much worse
official Java collection library. Or consider the insane generic types
in Java, that are everything but certainly not addressed at the original
target audience of Java ("untrained" programmers). Apparently, a process
doesn't guarantee to achieve your goals, at least not any old process.
>> I don't think that's what you want for Common Lisp. I certainly wouldn't
>> want it.
>
> Sure, but anarchy is not the only alternative to dictatorship.
Please refrain from putting words in my mouth. That's not what I am
suggesting. Thank you.
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
In article <··············@individual.net>,
Pascal Costanza <··@p-cos.net> wrote:
> Ron Garret wrote:
>
> >> You missed the important point here: These technologies are controlled
> >> by their respective "authorities" (think: "benevolent" dictators). By
> >> definition, there is no process that gives users a vote in how the
> >> respective technologies should be changed (other than by convincing the
> >> respective authority).
> >
> > Their process isn't democratic, but it is a process nonetheless.
>
> With very obvious downsides. Consider the replacement of the once
> nearly-defacto-standard for containers in Java with the much worse
> official Java collection library. Or consider the insane generic types
> in Java, that are everything but certainly not addressed at the original
> target audience of Java ("untrained" programmers). Apparently, a process
> doesn't guarantee to achieve your goals, at least not any old process.
Of course. And your point would be...?
> >> I don't think that's what you want for Common Lisp. I certainly wouldn't
> >> want it.
> >
> > Sure, but anarchy is not the only alternative to dictatorship.
>
> Please refrain from putting words in my mouth. That's not what I am
> suggesting. Thank you.
Isn't it? Then what are you suggesting?
rg
Ron Garret wrote:
> In article <··············@individual.net>,
> Pascal Costanza <··@p-cos.net> wrote:
>
>> Ron Garret wrote:
>>
>>>> You missed the important point here: These technologies are controlled
>>>> by their respective "authorities" (think: "benevolent" dictators). By
>>>> definition, there is no process that gives users a vote in how the
>>>> respective technologies should be changed (other than by convincing the
>>>> respective authority).
>>> Their process isn't democratic, but it is a process nonetheless.
>> With very obvious downsides. Consider the replacement of the once
>> nearly-defacto-standard for containers in Java with the much worse
>> official Java collection library. Or consider the insane generic types
>> in Java, that are everything but certainly not addressed at the original
>> target audience of Java ("untrained" programmers). Apparently, a process
>> doesn't guarantee to achieve your goals, at least not any old process.
>
> Of course. And your point would be...?
We should do things where we have a higher level of certainty that they
actually benefit the community.
>>>> I don't think that's what you want for Common Lisp. I certainly wouldn't
>>>> want it.
>>> Sure, but anarchy is not the only alternative to dictatorship.
>> Please refrain from putting words in my mouth. That's not what I am
>> suggesting. Thank you.
>
> Isn't it? Then what are you suggesting?
Piecemeal growth.
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
In article <··············@individual.net>,
Pascal Costanza <··@p-cos.net> wrote:
> Ron Garret wrote:
> > In article <··············@individual.net>,
> > Pascal Costanza <··@p-cos.net> wrote:
> >
> >> Ron Garret wrote:
> >>
> >>>> You missed the important point here: These technologies are controlled
> >>>> by their respective "authorities" (think: "benevolent" dictators). By
> >>>> definition, there is no process that gives users a vote in how the
> >>>> respective technologies should be changed (other than by convincing the
> >>>> respective authority).
> >>> Their process isn't democratic, but it is a process nonetheless.
> >> With very obvious downsides. Consider the replacement of the once
> >> nearly-defacto-standard for containers in Java with the much worse
> >> official Java collection library. Or consider the insane generic types
> >> in Java, that are everything but certainly not addressed at the original
> >> target audience of Java ("untrained" programmers). Apparently, a process
> >> doesn't guarantee to achieve your goals, at least not any old process.
> >
> > Of course. And your point would be...?
>
> We should do things where we have a higher level of certainty that they
> actually benefit the community.
Fair enough. Do you think having more users would benefit the
community? Not everybody does. There is a faction in the community
that believes that Lisp ought to be a language for experts only, that
the barriers to entry are a feature that keeps out the rif raf. Do you
subscribe to that view? If you do then we'll just have to agree to
disagree, and you can skip the following.
Do you agree that Python has had more success than Lisp in attracting
new users? If not then once again we'll just have to agree to disagree.
If so, to what do you attribute their success? Is it just that people
are stupid and so are naturally attracted to inferior products, or is
there something about Python that actually makes it worthy of its larger
user base? If so, do you think any of the factors contributing to
Python's success could be adapted to help grow the Lisp user base?
> >>>> I don't think that's what you want for Common Lisp. I certainly wouldn't
> >>>> want it.
> >>> Sure, but anarchy is not the only alternative to dictatorship.
> >> Please refrain from putting words in my mouth. That's not what I am
> >> suggesting. Thank you.
> >
> > Isn't it? Then what are you suggesting?
>
> Piecemeal growth.
That's not a process, it's an outcome.
rg
Ron Garret wrote:
> In article <··············@individual.net>,
> Pascal Costanza <··@p-cos.net> wrote:
>
>> Ron Garret wrote:
>>> In article <··············@individual.net>,
>>> Pascal Costanza <··@p-cos.net> wrote:
>>>
>> We should do things where we have a higher level of certainty that they
>> actually benefit the community.
>
> Fair enough. Do you think having more users would benefit the
> community?
Yes, absolutely.
> Not everybody does. There is a faction in the community
> that believes that Lisp ought to be a language for experts only, that
> the barriers to entry are a feature that keeps out the rif raf. Do you
> subscribe to that view? If you do then we'll just have to agree to
> disagree, and you can skip the following.
>
> Do you agree that Python has had more success than Lisp in attracting
> new users?
Yes. I don't think it will have a lasting effect, though. I remember
times when Turbo-Pascal was very succesful because it was very friendly
to newbies. Common Lisp still exists.
> If not then once again we'll just have to agree to disagree.
>
> If so, to what do you attribute their success? Is it just that people
> are stupid and so are naturally attracted to inferior products, or is
> there something about Python that actually makes it worthy of its larger
> user base?
Python is a language that is very attractive for occasional programmers.
Python achieves its attractiveness by removing a lot of things that are
typically considered to increase the expressiveness of other languages
in a positive way. In this way, Python is more easily accessible by a
lot of people who don't like to go into too many technical details. The
"batteries included" helps to make Python attractive for developing
currently popular kinds of applications. It's not a language designed
for stretching its boundaries or for trying out new and untried ideas
that go substantially beyond what the designers of Python had in mind.
That's one reason why it is a relatively simple language, which
contributes to its attractiveness for occasional programmers. (Note that
this doesn't mean that there are no programmers that use Python on a
regular basis. Also note that I don't think that occasional programmers
are stupid. They just focus on other things than regular programmers.)
> If so, do you think any of the factors contributing to
> Python's success could be adapted to help grow the Lisp user base?
I would be against an approach that attempts to simplify Lisp to the
degree that its expressiveness is being hurt. (Think MockLisp.) I think
this implies a "natural" limit to the degree to which we can be as
successful as languages like Python, Ruby, etc.
I think the ease of use of Python is a result of its popularity, not the
other way around. Again, the Lisp community is growing, and I am very
optimistic that we will reach a critical mass that will lead to a
considerable improvement of the infrastructure, just because there will
be enough people to take care of these things. But this won't happen
overnight.
Here are three simple questions for you:
- Do you think that the current situation is better than, say, five
years ago? (Back then, something like cl-user.net didn't even exist, right?)
- Do you agree that the fact that the situation is better than five
years ago indicate that things are improving?
- Why should this all suddenly stop?
>>>>>> I don't think that's what you want for Common Lisp. I certainly wouldn't
>>>>>> want it.
>>>>> Sure, but anarchy is not the only alternative to dictatorship.
>>>> Please refrain from putting words in my mouth. That's not what I am
>>>> suggesting. Thank you.
>>> Isn't it? Then what are you suggesting?
>> Piecemeal growth.
>
> That's not a process, it's an outcome.
I cite from Richard Gabriel's "Patterns of Software":
"Finally, if Alexander�s lesson applies to software, it implies that a
development project ought to have less of a plan in place than current
thinking allows. This provides a mechanism for motivation and a sense of
responsibility to those developers who later must work with the code.
"Alexander goes on:
The principle of organic order: Planning and construction
[implementation, in our context] will be guided by a process
which allows the whole to emerge gradually from local acts.
(Alexander 1975)
"This [is] just piecemeal growth. Here is how Alexander puts it:
[E]ach new building is not a �finished� thing. . . . They are
never torn down, never erased; instead they are always
embellished, modified, reduced, enlarged, improved. This
attitude to the repair of the environment has been commonplace
for thousands of years in traditional cultures. We may summarize
the point of view behind this attitude in one phrase: piecemeal
growth. (Alexander 1975)
"Piecemeal growth is a reality. What gets in its way and prevents
software habitability is overdesign, overabstraction, and the beautiful,
taut monument of software. Alexander calls this large lump development:
Large lump development hinges on a view of the environment which
is static and discontinuous; piecemeal growth hinges on a view
of the environment which is dynamic and continuous. . . .
According to the large lump point of view, each act of design or
construction is an isolated event which creates an isolated
building � �perfect� at the time of its construction, and then
abandoned by its builders and designers forever. According to
the piecemeal point of view, every environment is changing and
growing all the time, in order to keep its use in balance; and
the quality of the environment is a kind of semi-stable
equilibrium in the flux of time. . . . Large lump development is
based on the idea of replacement. Piecemeal growth is based on
the idea of repair. (Alexander 1975)
[...]
"Piecemeal growth is the process of design and implementation in which
software is embellished, modified, reduced, enlarged, and improved
through a process of repair rather than of replacement."
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
In article <··············@individual.net>,
Pascal Costanza <··@p-cos.net> wrote:
> Here are three simple questions for you:
>
> - Do you think that the current situation is better than, say, five
> years ago?
In some ways yes, in some ways no. On the plus side, there certainly
seems to have been some progress in libraries, though not nearly as much
as one might have hoped for in that amount of time. Five years is an
eternity in most of the technology world.
On the minus side, we seem to have actually lost Digitool, which IMHBO
(in my highly biased opinion) is most unfortunate. It's hard to weigh
these. At best I'd say it's a wash.
Since you invoke the spirits of the past, imagine how different the
world would be if CL had been ready for prime time in 2000 when I tried
to convince Urs Hoelzle to let me use it to write AdWords.
Opportunities like that do not come along every day, and they must be
seized when they present themselves or it is too late.
> (Back then, something like cl-user.net didn't even exist, right?)
True, but cl-user.net is of questionable value. It freely combines
useful items with ones that are not ready for prime time (e.g. ABCL) and
ones that are badly out of date (e.g. Golden CL), leaving the burden on
the user to determine which is which.
> - Do you agree that the fact that the situation is better than five
> years ago indicate that things are improving?
If they are improving, the pace is glacial.
> - Why should this all suddenly stop?
Because the current burst of exuberance could abate once reality sets in?
> >>>>>> I don't think that's what you want for Common Lisp. I certainly
> >>>>>> wouldn't
> >>>>>> want it.
> >>>>> Sure, but anarchy is not the only alternative to dictatorship.
> >>>> Please refrain from putting words in my mouth. That's not what I am
> >>>> suggesting. Thank you.
> >>> Isn't it? Then what are you suggesting?
> >> Piecemeal growth.
> >
> > That's not a process, it's an outcome.
[snip]
> "Piecemeal growth is the process of design and implementation in which
> software is embellished, modified, reduced, enlarged, and improved
> through a process of repair rather than of replacement."
OK, fine, but if you really believe that piecemeal growth is a good
thing then why should we adhere to the hyperspec?
You can't have it both ways. Either specs are beneficial, in which case
having the ability to generate new and improved ones is good, or they
are not, in which case the existing specs should be discarded. Or
perhaps you believe "the age of prophecy is past" and that there was
something unique about the people who wrote the hyperscripture that can
never again be reproduced?
rg
Ron Garret wrote:
> In article <··············@individual.net>,
> Pascal Costanza <··@p-cos.net> wrote:
>
>> Here are three simple questions for you:
>>
>> - Do you think that the current situation is better than, say, five
>> years ago?
>
> In some ways yes, in some ways no. On the plus side, there certainly
> seems to have been some progress in libraries, though not nearly as much
> as one might have hoped for in that amount of time. Five years is an
> eternity in most of the technology world.
A measure of the amount of work that can get done is the product of time
and people. The fact that not more has been done is an indication for
the size of the community. Maybe you are just asking too much.
> On the minus side, we seem to have actually lost Digitool, which IMHBO
> (in my highly biased opinion) is most unfortunate. It's hard to weigh
> these. At best I'd say it's a wash.
We haven't lost Digitool yet.
> Since you invoke the spirits of the past, imagine how different the
> world would be if CL had been ready for prime time in 2000 when I tried
> to convince Urs Hoelzle to let me use it to write AdWords.
They would have probably started a rewrite in some other language a few
years after. These decisions are not technically-driven anyway, no
matter how hard you try to make it that way.
>> (Back then, something like cl-user.net didn't even exist, right?)
>
> True, but cl-user.net is of questionable value. It freely combines
> useful items with ones that are not ready for prime time (e.g. ABCL) and
> ones that are badly out of date (e.g. Golden CL), leaving the burden on
> the user to determine which is which.
...but these things are documented at cl-user.net. So it's possible to
get a good picture over there.
Recall that cl-user.net is an effort by a few people (mainly two) since
last December. So it's quite natural that there is room for improvement.
What do you suggest? How can cl-user.net be improved?
>> "Piecemeal growth is the process of design and implementation in which
>> software is embellished, modified, reduced, enlarged, and improved
>> through a process of repair rather than of replacement."
>
> OK, fine, but if you really believe that piecemeal growth is a good
> thing then why should we adhere to the hyperspec?
I didn't say so. I think it's a good idea that legacy code still works,
because otherwise we would lose accumulated wisdom. That's my personal
view. Apparently, the community agrees. With some stretch of imagination
you could say that that's the result of the process that's currently in
place.
If the majority of Common Lisp users would think otherwise, this would
change.
> You can't have it both ways. Either specs are beneficial, in which case
> having the ability to generate new and improved ones is good, or they
> are not, in which case the existing specs should be discarded.
I'd like to remind you of Ron Garret's first law: All extreme positions
are wrong. ;)
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
In article <··············@individual.net>,
Pascal Costanza <··@p-cos.net> wrote:
> Ron Garret wrote:
> > In article <··············@individual.net>,
> > Pascal Costanza <··@p-cos.net> wrote:
> >
> >> Here are three simple questions for you:
> >>
> >> - Do you think that the current situation is better than, say, five
> >> years ago?
> >
> > In some ways yes, in some ways no. On the plus side, there certainly
> > seems to have been some progress in libraries, though not nearly as much
> > as one might have hoped for in that amount of time. Five years is an
> > eternity in most of the technology world.
>
> A measure of the amount of work that can get done is the product of time
> and people. The fact that not more has been done is an indication for
> the size of the community. Maybe you are just asking too much.
You have the cart before the horse. I am not asking (directly) for more
rapid progress. Actually, I am not asking for anything. I am
suggesting that if the community adopted a process for managing change
that would make the language more accessible to newcomers, which would
increase the size of the community, which would make more people
available to work on things, which would result in faster progress (to
say nothing of all manner of ancillary benefits, like increasing the
size of the market for commercial Lisp implementations, making it easier
for people to make the case for using Lisp to their employers, etc. etc.)
> > On the minus side, we seem to have actually lost Digitool, which IMHBO
> > (in my highly biased opinion) is most unfortunate. It's hard to weigh
> > these. At best I'd say it's a wash.
>
> We haven't lost Digitool yet.
That's reassuring. Except for the "yet" part.
> > Since you invoke the spirits of the past, imagine how different the
> > world would be if CL had been ready for prime time in 2000 when I tried
> > to convince Urs Hoelzle to let me use it to write AdWords.
>
> They would have probably started a rewrite in some other language a few
> years after.
You can't know that. Just because Yahoo did that with ViaWeb is no
reason to believe that Google would have done the same with AdWords.
(For one thing, if AdWords were written in Lisp I'd probably still be
working there.)
> These decisions are not technically-driven anyway, no
> matter how hard you try to make it that way.
They are at Google. Google is a company run by hackers. Very, very
smart hackers.
> >> (Back then, something like cl-user.net didn't even exist, right?)
> >
> > True, but cl-user.net is of questionable value. It freely combines
> > useful items with ones that are not ready for prime time (e.g. ABCL) and
> > ones that are badly out of date (e.g. Golden CL), leaving the burden on
> > the user to determine which is which.
>
> ...but these things are documented at cl-user.net. So it's possible to
> get a good picture over there.
>
> Recall that cl-user.net is an effort by a few people (mainly two) since
> last December. So it's quite natural that there is room for improvement.
>
> What do you suggest? How can cl-user.net be improved?
Adopt a process for managing change to make it easier for the people
running cl-user.net to track the current state of things.
> > You can't have it both ways. Either specs are beneficial, in which case
> > having the ability to generate new and improved ones is good, or they
> > are not, in which case the existing specs should be discarded.
>
> I'd like to remind you of Ron Garret's first law: All extreme positions
> are wrong. ;)
Touche. Although I don't think advocating the adoption of a process for
managing change is an extreme position.
rg
Ron Garret wrote:
> In article <··············@individual.net>,
> Pascal Costanza <··@p-cos.net> wrote:
>
>> Ron Garret wrote:
>>> In article <··············@individual.net>,
>>> Pascal Costanza <··@p-cos.net> wrote:
>>>
>>>> Here are three simple questions for you:
>>>>
>>>> - Do you think that the current situation is better than, say, five
>>>> years ago?
>>> In some ways yes, in some ways no. On the plus side, there certainly
>>> seems to have been some progress in libraries, though not nearly as much
>>> as one might have hoped for in that amount of time. Five years is an
>>> eternity in most of the technology world.
>> A measure of the amount of work that can get done is the product of time
>> and people. The fact that not more has been done is an indication for
>> the size of the community. Maybe you are just asking too much.
>
> You have the cart before the horse. I am not asking (directly) for more
> rapid progress. Actually, I am not asking for anything. I am
> suggesting that if the community adopted a process for managing change
> that would make the language more accessible to newcomers, which would
> increase the size of the community, which would make more people
> available to work on things, which would result in faster progress (to
> say nothing of all manner of ancillary benefits, like increasing the
> size of the market for commercial Lisp implementations, making it easier
> for people to make the case for using Lisp to their employers, etc. etc.)
You're making quite a lot of assumptions here that do not necessarily hold.
For a counter view on a not completely unrelated matter, see
http://daringfireball.net/2006/04/asinine_and_or_risky_ideas
The analogy may not hold, but it is a hint that the "obvious right"
ideas may not always be the best ones.
>>> Since you invoke the spirits of the past, imagine how different the
>>> world would be if CL had been ready for prime time in 2000 when I tried
>>> to convince Urs Hoelzle to let me use it to write AdWords.
>> They would have probably started a rewrite in some other language a few
>> years after.
>
> You can't know that. Just because Yahoo did that with ViaWeb is no
> reason to believe that Google would have done the same with AdWords.
> (For one thing, if AdWords were written in Lisp I'd probably still be
> working there.)
Yes, we all can only speculate.
>> Recall that cl-user.net is an effort by a few people (mainly two) since
>> last December. So it's quite natural that there is room for improvement.
>>
>> What do you suggest? How can cl-user.net be improved?
>
> Adopt a process for managing change to make it easier for the people
> running cl-user.net to track the current state of things.
Apparently, you're too single-minded, or I don't understand you. Assume
the realistic scenario that we won't get a sanctioned process soon.
What's the next best thing that we could do? For example, what can the
maintainers of cl-user.net concretely do to improve the situation?
>>> You can't have it both ways. Either specs are beneficial, in which case
>>> having the ability to generate new and improved ones is good, or they
>>> are not, in which case the existing specs should be discarded.
>> I'd like to remind you of Ron Garret's first law: All extreme positions
>> are wrong. ;)
>
> Touche. Although I don't think advocating the adoption of a process for
> managing change is an extreme position.
It is if you present it as the only viable option.
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
In article <··············@individual.net>,
Pascal Costanza <··@p-cos.net> wrote:
> Ron Garret wrote:
> > In article <··············@individual.net>,
> > Pascal Costanza <··@p-cos.net> wrote:
> >
> >> Ron Garret wrote:
> >>> In article <··············@individual.net>,
> >>> Pascal Costanza <··@p-cos.net> wrote:
> >>>
> >>>> Here are three simple questions for you:
> >>>>
> >>>> - Do you think that the current situation is better than, say, five
> >>>> years ago?
> >>> In some ways yes, in some ways no. On the plus side, there certainly
> >>> seems to have been some progress in libraries, though not nearly as much
> >>> as one might have hoped for in that amount of time. Five years is an
> >>> eternity in most of the technology world.
> >> A measure of the amount of work that can get done is the product of time
> >> and people. The fact that not more has been done is an indication for
> >> the size of the community. Maybe you are just asking too much.
> >
> > You have the cart before the horse. I am not asking (directly) for more
> > rapid progress. Actually, I am not asking for anything. I am
> > suggesting that if the community adopted a process for managing change
> > that would make the language more accessible to newcomers, which would
> > increase the size of the community, which would make more people
> > available to work on things, which would result in faster progress (to
> > say nothing of all manner of ancillary benefits, like increasing the
> > size of the market for commercial Lisp implementations, making it easier
> > for people to make the case for using Lisp to their employers, etc. etc.)
>
> You're making quite a lot of assumptions here that do not necessarily hold.
>
> For a counter view on a not completely unrelated matter, see
> http://daringfireball.net/2006/04/asinine_and_or_risky_ideas
>
> The analogy may not hold, but it is a hint that the "obvious right"
> ideas may not always be the best ones.
I fail to see the point. Are you saying that my ideas are wrong because
they're obviously right?
> >> Recall that cl-user.net is an effort by a few people (mainly two) since
> >> last December. So it's quite natural that there is room for improvement.
> >>
> >> What do you suggest? How can cl-user.net be improved?
> >
> > Adopt a process for managing change to make it easier for the people
> > running cl-user.net to track the current state of things.
>
> Apparently, you're too single-minded, or I don't understand you. Assume
> the realistic scenario that we won't get a sanctioned process soon.
Sanctioned? Did you not ask me not to put words in your mouth? I would
appreciate you extending me the same courtesy.
> What's the next best thing that we could do? For example, what can the
> maintainers of cl-user.net concretely do to improve the situation?
I have no idea.
> >>> You can't have it both ways. Either specs are beneficial, in which case
> >>> having the ability to generate new and improved ones is good, or they
> >>> are not, in which case the existing specs should be discarded.
> >> I'd like to remind you of Ron Garret's first law: All extreme positions
> >> are wrong. ;)
> >
> > Touche. Although I don't think advocating the adoption of a process for
> > managing change is an extreme position.
>
> It is if you present it as the only viable option.
Are you saying that I did that? When?
rg
Ron Garret wrote:
> In article <··············@individual.net>,
> Pascal Costanza <··@p-cos.net> wrote:
>
>> For a counter view on a not completely unrelated matter, see
>> http://daringfireball.net/2006/04/asinine_and_or_risky_ideas
>>
>> The analogy may not hold, but it is a hint that the "obvious right"
>> ideas may not always be the best ones.
>
> I fail to see the point. Are you saying that my ideas are wrong because
> they're obviously right?
If that article doesn't work in this context, forget about it. It's
probably too far-fetched.
>>>> Recall that cl-user.net is an effort by a few people (mainly two) since
>>>> last December. So it's quite natural that there is room for improvement.
>>>>
>>>> What do you suggest? How can cl-user.net be improved?
>>> Adopt a process for managing change to make it easier for the people
>>> running cl-user.net to track the current state of things.
>> Apparently, you're too single-minded, or I don't understand you. Assume
>> the realistic scenario that we won't get a sanctioned process soon.
>
> Sanctioned? Did you not ask me not to put words in your mouth? I would
> appreciate you extending me the same courtesy.
In what way have I put words in your mouth? I have conceded that I might
not understand you, and I didn't claim that a sanctioned process is what
you are looking for. Nevertheless, it would be interesting to hear what
kind of process you would like to see in place, if the one that is
currently in place isn't enough but a sanctioned (in whatever sense of
the word) process would goes too far.
That's why I asked the following question:
>> What's the next best thing that we could do? For example, what can the
>> maintainers of cl-user.net concretely do to improve the situation?
>
> I have no idea.
>
>>>>> You can't have it both ways. Either specs are beneficial, in which case
>>>>> having the ability to generate new and improved ones is good, or they
>>>>> are not, in which case the existing specs should be discarded.
>>>> I'd like to remind you of Ron Garret's first law: All extreme positions
>>>> are wrong. ;)
>>> Touche. Although I don't think advocating the adoption of a process for
>>> managing change is an extreme position.
>> It is if you present it as the only viable option.
>
> Are you saying that I did that? When?
Well, there are postings of yours that seem to imply that if we don't
adopt a certain kind of process for change, we will all be going down
the drains (in economical terms). Wrong impression?
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
In article <··············@individual.net>,
Pascal Costanza <··@p-cos.net> wrote:
> >>>>> You can't have it both ways. Either specs are beneficial, in which
> >>>>> case
> >>>>> having the ability to generate new and improved ones is good, or they
> >>>>> are not, in which case the existing specs should be discarded.
> >>>> I'd like to remind you of Ron Garret's first law: All extreme positions
> >>>> are wrong. ;)
> >>> Touche. Although I don't think advocating the adoption of a process for
> >>> managing change is an extreme position.
> >> It is if you present it as the only viable option.
> >
> > Are you saying that I did that? When?
>
> Well, there are postings of yours that seem to imply that if we don't
> adopt a certain kind of process for change, we will all be going down
> the drains (in economical terms). Wrong impression?
YOU are the one who is talking about Lisp "perishing" and "going down
the drains", not me. When have I ever used those terms? Those ideas
came out of YOUR head, not mine. (And you call ME a pessimist?)
This actually gets back to the original point, which was SteveY's claim
that CL has become a religion. Fundamentalists sometimes claim that
e.g. efforts to separate church and state are in fact an assault on
their religion, a thin cover for a hidden agenda to persecute Christians
and drive religion underground or some such paranoid fantasy. The
strategy is often accompanied by disingenuous tactics like preceding
outrageous claims with the phrase, "Some people say..." without ever
specifying who those "some people" are, making the claim impossible to
refute. (The equivalent in this case is your use of the phrase "There
are postings of yours that seem to imply..." without saying which
postings those are.)
A similar dynamic seems to be in play here. I come in and say, "I think
the rate of progress and growth could be improved if we do X," and it's
interpreted as "If you do not bow down to me as Ruler Of The Future Lisp
then CL is doomed. DOOMED! BWAHAHAHAHA!" You'd think in the era of
the Google groups search it would not be necessary for me to say "I
never said ..." Alas...
rg
Ron Garret <·········@flownet.com> writes:
> True, but cl-user.net is of questionable value. It freely combines
> useful items with ones that are not ready for prime time (e.g. ABCL) and
> ones that are badly out of date (e.g. Golden CL), leaving the burden on
> the user to determine which is which.
I personally think that this is a feature of the CL Directory:
Why the CL Directory also lists old and non-working software
http://www.paoloamoroso.it/log/060207.html
As for the burden of determining which items are ready for prime time
or up to date, this is what the "Version" and "Maturity" fields of
entries are for. I always try to provide that information and keep it
up to date.
By the way, this list of Perl modules at CPAN also includes entries
that date back to 1995:
CPAN's 9876 modules distributions
http://www.cpan.org/modules/01modules.index.html
Paolo
--
Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
The Common Lisp Directory: http://www.cl-user.net
Pascal Costanza <··@p-cos.net> writes:
>
> You missed the important point here: These technologies are controlled
> by their respective "authorities" (think: "benevolent" dictators). By
> definition, there is no process that gives users a vote in how the
> respective technologies should be changed (other than by convincing
> the respective authority).
>
> I don't think that's what you want for Common Lisp. I certainly
> wouldn't want it.
Why not? I for one would welcome a Common Lisp community more like
Python, with one canonical, free implementation which get the vast
majority of developer attention, and maybe a few hangers-on at the edges
doing neat stuff. And yes, folks always say, 'just treat a single
Common Lisp implementation as the canonical one.' This doesn't work,
because developer attention is fragmented: feature X works with SBCL and
CMUCL; library Y wants CMUCL or ACL; tool Z needs ACL or SBCL--this is
in contrast with Python where the very great majority of libraries and
tools work with Python, and a relative few need JPython or Stackless
Python or what-have-you.
Also, a single canonical implementation could fix nuisances like nth/elt
and elt/gethash and so forth, instead of everyone hewing to an old
standard.
--
Robert Uhl <http://public.xdi.org/=ruhl>
Among other evils which being unarmed brings you, it causes you to be
despised. --Niccolo Machiavelli
Robert Uhl <·········@NOSPAMgmail.com> writes:
> Also, a single canonical implementation could fix nuisances like nth/elt
> and elt/gethash and so forth, instead of everyone hewing to an old
> standard.
Why are they nuisances? These are the features that allow you to take
a library written twenty years ago and still make it work on today
implementations!
Why do you need a specific implementation to fix them? You can
perfectly write a portable library "fixing" them:
(defpackage "FIXED-COMMON-LISP"
(:nicknames "FIXED-CL")
(:use "COMMON-LISP"))
(in-package "FIXED-COMMON-LISP)
(SHADOW 'elt)
(defun elt (collection key)
(etypecase collection
(list (cl:nth key collection)) ; we could remove two
(hashtable (cl:gethash key collection)) ; cases, but for fun...
(vector (cl:aref collection key))
(sequence (cl:elt collection key))))
;; We re-export all the COMMON-LISP symbols but the "fixed" ones:
(LET ((SYMLIST '()))
(DO-EXTERNAL-SYMBOLS (SYM "COMMON-LISP") (PUSH SYM SYMLIST))
(EXPORT (union '(elt) (set-difference SYMLIST '(nth elt gethash)))
#.(FIND-PACKAGE "FIXED-COMMON-LISP")))
(defpackage "FIXED-COMMON-LISP-USER"
(:nicknames "FIXED-CL-USER")
(:use "FIXED-COMMON-LISP"))
(in-package "FIXED-COMMON-LISP-USER")
and then on just write:
(defpackage "MYAPP" (:use "FIXED-CL"))
instead of:
(defpackage "MYAPP" (:use "CL"))
** Instant fix for all implementations! No need for a Standard Commitee!!!
--
__Pascal Bourguignon__ http://www.informatimago.com/
"Klingon function calls do not have "parameters" -- they have
"arguments" and they ALWAYS WIN THEM."
Pascal Bourguignon wrote:
> Robert Uhl <·········@NOSPAMgmail.com> writes:
> > Also, a single canonical implementation could fix nuisances like nth/elt
> > and elt/gethash and so forth, instead of everyone hewing to an old
> > standard.
>
> Why are they nuisances? These are the features that allow you to take
> a library written twenty years ago and still make it work on today
> implementations!
Yes, old code frequently has more profound thoughts than what language
designers express. Wasting that profundity is a cost weighed against
any spec improvement. As a Lisp user, I am concerned with the entire
basket of what a tool's ecosystem provides, not just one little part.
(So for example, a new spec mandating NTH to be more like ELT is such a
superficial thing to do relative to the brilliant code which would
break.)
There exist spec changes which are worth the cost; however, we rarely
hear about those reasonable ones, which is probably why there's such
pushback when someone brings up the subject.
Tayssir
Robert Uhl wrote:
> Pascal Costanza <··@p-cos.net> writes:
>> You missed the important point here: These technologies are controlled
>> by their respective "authorities" (think: "benevolent" dictators). By
>> definition, there is no process that gives users a vote in how the
>> respective technologies should be changed (other than by convincing
>> the respective authority).
>>
>> I don't think that's what you want for Common Lisp. I certainly
>> wouldn't want it.
>
> Why not? I for one would welcome a Common Lisp community more like
> Python, with one canonical, free implementation which get the vast
> majority of developer attention, and maybe a few hangers-on at the edges
> doing neat stuff. And yes, folks always say, 'just treat a single
> Common Lisp implementation as the canonical one.' This doesn't work,
> because developer attention is fragmented: feature X works with SBCL and
> CMUCL; library Y wants CMUCL or ACL; tool Z needs ACL or SBCL--this is
> in contrast with Python where the very great majority of libraries and
> tools work with Python, and a relative few need JPython or Stackless
> Python or what-have-you.
What you suggest requires a decision which one of the many existing
Common Lisp implementations will be that single canonical
implementation. Who do you think is going to make that decision for you?
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
Pascal Costanza <··@p-cos.net> writes:
> Ron Garret wrote:
>
>> 1. The details of my criticisms are mostly irrelevant. What
>> matters is that CL is far from perfect, and that it has no mechanism
>> for change. So don't bother picking a nit about one of my specific
>> criticisms unless you wish to argue that CL is perfect and doesn't
>> need to change.
>
> Here is another thought: For important branches of industry, it is an
> absolutely safe bet to base your software solutions on Java, Eclipse,
> Enterprise JavaBeans and the apache web server. Other popular
> technologies include Python and apparently Ruby. None of these
> technologies have an officially sanctioned mechanism for change: Java
> is basically controlled by Sun, Eclipse by IBM and Python and Ruby by
> their respective designers. (I am not so sure about apache.) Try
> suggesting to add macros to Java, a Lisp-based scripting language to
> Eclipse, closures to Python, or multiple dispatch to Ruby.
>
> The gist of this is that an official mechanism for changing a
> technology is _not_ what makes a technology successful. What makes a
> technology successful is the notion of a "killer application": For
> Java, it was applets, for Ruby it's Ruby on Rails, for Python Zope
> (?), for Eclipse and apache the respective software itself, for Perl
> processing cgi requests, for C direct access to the operating system,
> and so on.
>
Spot on. Extremely good analysis.
--
Surendra Singhi
http://ssinghi.kreeti.com/
,----
| "All animals are equal, but some animals are more equal than others."
| -- Orwell, Animal Farm, 1945
`----
In article <··············@individual.net>,
Pascal Costanza <··@p-cos.net> wrote:
>
>None of these technologies have an officially sanctioned mechanism
>for change: Java is basically controlled by Sun, Eclipse by IBM and
>Python and Ruby by their respective designers.
I am not familiar enough with the development process of the others to
comment but you're incorrect with respect to Java. The mechanism for
change is JCP (http://jcp.org).
As one concrete example of many, take a look at the util.concurrent[1]
library. After some years of evolution it went through the JCP[2] and
as of JDK 1.5 it became part of the standard library. There are
benefits to such library standardization; developers can start to
assume the support will be there in all deployments, no special
documentation or installation hoops to jump through.
Think of Java 10 years ago in 1996. Very primitive and slow, useful
for some simplistic web page animations. Java today is several orders
of magnitude improved, with a solid track record of industrial
strength server applications. Evolution is a good thing.
A few weeks ago here there was a long thread on lisp's lack of good
module/packaging support that I found interesting as I'd just spent
some hours trying to figure it out. I spent some time googling around
for more info and found very similar threads on this same newsgroup
going back years into the 90s. It is disheartening to see the same
issues go back so far and they haven't been solved once and for all in
a standard way already.
As a newbie to lisp, none of this is really going to keep me from
continuing to learn more about it. I'm enjoying the language quite a
bit and using it wherever applicable. But at the end of the day it is
about end-to-end productivity. The answers vary for each project, but
a mediocre language with excellent standard libraries can beat an good
language.
[1]
http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html
[2] http://jcp.org/en/jsr/detail?id=166
--
Jyri J. Virkki - Santa Cruz, CA
Jyri J. Virkki wrote:
> In article <··············@individual.net>,
> Pascal Costanza <··@p-cos.net> wrote:
>> None of these technologies have an officially sanctioned mechanism
>> for change: Java is basically controlled by Sun, Eclipse by IBM and
>> Python and Ruby by their respective designers.
>
> I am not familiar enough with the development process of the others to
> comment but you're incorrect with respect to Java. The mechanism for
> change is JCP (http://jcp.org).
Who do you think controls that process?
> As one concrete example of many, take a look at the util.concurrent[1]
> library. After some years of evolution it went through the JCP[2] and
> as of JDK 1.5 it became part of the standard library. There are
> benefits to such library standardization; developers can start to
> assume the support will be there in all deployments, no special
> documentation or installation hoops to jump through.
There are also downsides. It is quite often the case that the default
Java libraries are not the best for the respective tasks at hand.
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
Pascal Costanza <··@p-cos.net> writes:
> Jyri J. Virkki wrote:
>
>> There are benefits to such library standardization; developers can
>> start to assume the support will be there in all deployments, no
>> special documentation or installation hoops to jump through.
>
> There are also downsides. It is quite often the case that the default
> Java libraries are not the best for the respective tasks at hand.
That sounds like premature optimization to me. I think the question
is if the standard libraries are good enough. And even if they're
not, you still have the option of using non-standard libraries.
Besides, what prevents non-standardized libraries from not being "the
best for the respective tasks at hand?" Nothing. And since
standardized libraries went through a whole standardization process
and have thousands of users, chances are they're less buggy and
perform better than the non-standardized ones.
If Java's standard libraries aren't very good, as you say, that means
their standardization process needs improvement. It doesn't mean that
the idea per se is bad.
Regards
Wolfram
Wolfram Fenske wrote:
> Pascal Costanza <··@p-cos.net> writes:
>
>> Jyri J. Virkki wrote:
>>
>>> There are benefits to such library standardization; developers can
>>> start to assume the support will be there in all deployments, no
>>> special documentation or installation hoops to jump through.
>> There are also downsides. It is quite often the case that the default
>> Java libraries are not the best for the respective tasks at hand.
>
> That sounds like premature optimization to me.
I think that premature standardization is worse than premature
optimization. ;)
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
Pascal Costanza <··@p-cos.net> writes:
> Wolfram Fenske wrote:
>> Pascal Costanza <··@p-cos.net> writes:
>>
>>> Jyri J. Virkki wrote:
>>>
>>>> There are benefits to such library standardization; developers can
>>>> start to assume the support will be there in all deployments, no
>>>> special documentation or installation hoops to jump through.
>>> There are also downsides. It is quite often the case that the default
>>> Java libraries are not the best for the respective tasks at hand.
>> That sounds like premature optimization to me.
>
> I think that premature standardization is worse than premature
> optimization. ;)
Maybe, maybe not -- it's a tough question. What's important, is that
you don't seem to disagree that having more standard libraries in CL
*could* be a good thing. That's something, because IMO, Jyri has hit
the nail on the hat.
Wolfram
Wolfram Fenske wrote:
> Pascal Costanza <··@p-cos.net> writes:
>
>> Wolfram Fenske wrote:
>>> Pascal Costanza <··@p-cos.net> writes:
>>>
>>>> Jyri J. Virkki wrote:
>>>>
>>>>> There are benefits to such library standardization; developers can
>>>>> start to assume the support will be there in all deployments, no
>>>>> special documentation or installation hoops to jump through.
>>>> There are also downsides. It is quite often the case that the default
>>>> Java libraries are not the best for the respective tasks at hand.
>>> That sounds like premature optimization to me.
>> I think that premature standardization is worse than premature
>> optimization. ;)
>
> Maybe, maybe not -- it's a tough question. What's important, is that
> you don't seem to disagree that having more standard libraries in CL
> *could* be a good thing.
I don't have a specific opinion wrt whether more standard libraries in
CL would be good or not. I don't care enough in this regard because it
doesn't matter a lot to me. I prefer to refrain from making judgements
on things that don't affect me. This should rather be addressed by
people who actually need the libraries in question. Common Lisp was
never designed with newcomers in mind, but only with people actually
using the language (and using it extensively). I prefer to trust such
people's judgement. (Note that I am referring here to libraries that are
supposedly important in the "modern" world. Of course, there are
libraries that do affect me, but there I don't think that the lack of a
standardization process is the most pressing issue.)
A downside I'd see in standardizing libraries is that things that are
important nowadays, but could become irrelevant in, say, 10 or 20 years
from now, would still have to be supported then for backwards
compatibility reason. I tend to think that a language should rather
focus on core programming language issues, and standard libraries should
be defined outside of a programming language. How this is achieved is a
secondary thing. But again, I am not picky here.
I do most certainly think that standardization for standardization's
sake is a very bad idea.
> That's something, because IMO, Jyri has hit
> the nail on the hat.
I don't think so. Java is mostly hype. I have started to distrust
standardization processes when the nearly-defacto-standard library JGL
was replaced by the Java collection framework. People who think that the
Java collection framework is a good idea don't know what they are
talking about. There are more of such examples. For example, Sun
internally had an already working implementation of full closures for
Java, including write access to lexical variables, as part of anonymous
inner classes. It was scrapped and replaced by read-only access to final
lexical variables, purportedly for efficiency reasons, as sanctioned by
some standardization (or maybe not, I don't remember). _These_ are the
things that make you jump through hoops, not the lack of some stupid
libraries that you can easily find by investing some time searching the web.
Where are the macros in Python? ;)
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
Pascal Costanza <··@p-cos.net> writes:
> Wolfram Fenske wrote:
>> Pascal Costanza <··@p-cos.net> writes:
>>
>>> Wolfram Fenske wrote:
>>>> Pascal Costanza <··@p-cos.net> writes:
>>>>
>>>>> Jyri J. Virkki wrote:
>>>>>
>>>>>> There are benefits to such library standardization; developers can
>>>>>> start to assume the support will be there in all deployments, no
>>>>>> special documentation or installation hoops to jump through.
>>>>> There are also downsides. It is quite often the case that the default
>>>>> Java libraries are not the best for the respective tasks at hand.
>>>> That sounds like premature optimization to me.
>>> I think that premature standardization is worse than premature
>>> optimization. ;)
>> Maybe, maybe not -- it's a tough question. What's important, is that
>> you don't seem to disagree that having more standard libraries in CL
>> *could* be a good thing.
>
> I don't have a specific opinion wrt whether more standard libraries
> in CL would be good or not. [...] (Note that I am referring here to
> libraries that are supposedly important in the "modern" world. Of
> course, there are libraries that do affect me, but there I don't
> think that the lack of a standardization process is the most
> pressing issue.)
I'm not knowledgeable enough in that area to argue with you. What do
you think is the problem? Too few people actually writing and
maintaining the libraries?
> A downside I'd see in standardizing libraries is that things that are
> important nowadays, but could become irrelevant in, say, 10 or 20
> years from now, would still have to be supported then for backwards
> compatibility reason.
That's a good point. The process would have to be flexible enough to
deprecate and finally remove those parts of the library whose user
base isn't sufficiently large anymore. I suppose this is a lot easier
for Java, Python, and Ruby, all of which more or less are centrally
controlled.
> I tend to think that a language should rather focus on core
> programming language issues, and standard libraries should be
> defined outside of a programming language.
I agree, and on the language front, I don't see a problem in CL.
> How this is achieved is a secondary thing. But again, I am not picky
> here.
IMO, the "Alexandria" thing that was proposed in another post [1] in
this thread and the thread "Do Lispers need libraries packed that will
work out of box?" were interesting. It sounded very similar to
e. g. NetBSD's pkg_src or the FreeBSD ports collection. I think
that'd be useful.
> I do most certainly think that standardization for standardization's
> sake is a very bad idea.
True.
>> [...] IMO, Jyri has hit the nail on the hat.
>
> I don't think so. Java is mostly hype.
I was referring to the part where "developers can start to assume the
support will be there in all deployments." In a way, this makes
e. g. Python more lightweight than CL: I can use my Python program
anywhere that Python is installed, whereas I need to install
additional libraries for an equivalent CL program. IMO, this mostly
disqualifies CL for writing small throwaway apps (scripts), which is
sad because I think that as a language, it would be very suited to
those tasks. I completely agree about Java being hype, though. ;-)
> I have started to distrust standardization processes when the
> nearly-defacto-standard library JGL was replaced by the Java
> collection framework. People who think that the Java collection
> framework is a good idea don't know what they are talking
> about. There are more of such examples. [...]
Apparently, Java is not a good example. I think Python and Ruby are.
> _These_ are the things that make you jump through hoops, not the
> lack of some stupid libraries that you can easily find by investing
> some time searching the web.
Still, should it be necessary to search for, say, regular expressions
or a portable ffi when the more experienced Lisp users know that
CL-PPCRE or UFFI are the way to go? I mean, it's not like Guido has
written all the Python libraries himself: e. g. Python 2.5 will have
an sqlite module, but that's just pysqlite, originally an independent
project which has been around for quite some time.
> Where are the macros in Python? ;)
Don't think I don't miss them! ;-)
Wolfram
Footnotes:
[1]
<http://groups.google.de/group/comp.lang.lisp/browse_thread/thread/18cc7a823112559c/fad29b60ca5c63a1?q=alexandria&rnum=1#fad29b60ca5c63a1>
Wolfram Fenske wrote:
> Pascal Costanza <··@p-cos.net> writes:
>
>> Wolfram Fenske wrote:
>>> Pascal Costanza <··@p-cos.net> writes:
>>>
>>>> Wolfram Fenske wrote:
>>>>> Pascal Costanza <··@p-cos.net> writes:
>>>>>
>>>>>> Jyri J. Virkki wrote:
>>>>>>
>>>>>>> There are benefits to such library standardization; developers can
>>>>>>> start to assume the support will be there in all deployments, no
>>>>>>> special documentation or installation hoops to jump through.
>>>>>> There are also downsides. It is quite often the case that the default
>>>>>> Java libraries are not the best for the respective tasks at hand.
>>>>> That sounds like premature optimization to me.
>>>> I think that premature standardization is worse than premature
>>>> optimization. ;)
>>> Maybe, maybe not -- it's a tough question. What's important, is that
>>> you don't seem to disagree that having more standard libraries in CL
>>> *could* be a good thing.
>> I don't have a specific opinion wrt whether more standard libraries
>> in CL would be good or not. [...] (Note that I am referring here to
>> libraries that are supposedly important in the "modern" world. Of
>> course, there are libraries that do affect me, but there I don't
>> think that the lack of a standardization process is the most
>> pressing issue.)
>
> I'm not knowledgeable enough in that area to argue with you. What do
> you think is the problem? Too few people actually writing and
> maintaining the libraries?
I am thinking about the CLOS MOP spec here, which contains a number of
problems that cannot be easily fixed from outside the language. The
issue is that on the one hand the spec itself needs to be fixed and on
the other hand you can only do that by having a considerable amount of
actually working CLOS MOP code, because only if you know what you
actually want to do with the CLOS MOP can you know how to specify the
respective parts in the spec. (That's true of any reflective / open
system, BTW.) I don't see how a standardization process would help here,
which can only become useful here as soon as those issues are dealt with.
>> A downside I'd see in standardizing libraries is that things that are
>> important nowadays, but could become irrelevant in, say, 10 or 20
>> years from now, would still have to be supported then for backwards
>> compatibility reason.
>
> That's a good point. The process would have to be flexible enough to
> deprecate and finally remove those parts of the library whose user
> base isn't sufficiently large anymore. I suppose this is a lot easier
> for Java, Python, and Ruby, all of which more or less are centrally
> controlled.
Central control is a bad idea. Unless the central authority is
democratically controlled (but even then there are some issues left).
The concept of a central control assumes that the people in charge know
what's "good" for the community. The application areas of Lisp are so
diverse that I don't see how this could possibly work out.
Languages like Java, Perl, Ruby, Python have been designed with certain
specific applications in mind. Lisp is a true general-purpose language.
For example, why should a web server library be more important than a
library for genome sequences? Because "everyone" does web servers but
"noone" does genome sequences? Nah...
>> I tend to think that a language should rather focus on core
>> programming language issues, and standard libraries should be
>> defined outside of a programming language.
>
> I agree, and on the language front, I don't see a problem in CL.
Good. ;)
>> How this is achieved is a secondary thing. But again, I am not picky
>> here.
>
> IMO, the "Alexandria" thing that was proposed in another post [1] in
> this thread and the thread "Do Lispers need libraries packed that will
> work out of box?" were interesting. It sounded very similar to
> e. g. NetBSD's pkg_src or the FreeBSD ports collection. I think
> that'd be useful.
Maybe.
>> I do most certainly think that standardization for standardization's
>> sake is a very bad idea.
>
> True.
>
>>> [...] IMO, Jyri has hit the nail on the hat.
>> I don't think so. Java is mostly hype.
>
> I was referring to the part where "developers can start to assume the
> support will be there in all deployments."
But that _is_ standardization for the sake of standardization.
(Standardized libraries are typically preferred over non-standardized
ones, although they may not be the best for the task at hand. That's not
a good idea.)
> In a way, this makes
> e. g. Python more lightweight than CL: I can use my Python program
> anywhere that Python is installed, whereas I need to install
> additional libraries for an equivalent CL program. IMO, this mostly
> disqualifies CL for writing small throwaway apps (scripts), which is
> sad because I think that as a language, it would be very suited to
> those tasks.
This is an incorrect comparison. You don't have to stick to Common Lisp
only. For example, if you require that clisp (or some other Common Lisp
for that matter) is installed, you can immediately make a lot more
assumptions about what is there and what is not.
> Still, should it be necessary to search for, say, regular expressions
> or a portable ffi when the more experienced Lisp users know that
> CL-PPCRE or UFFI are the way to go? I mean, it's not like Guido has
> written all the Python libraries himself: e. g. Python 2.5 will have
> an sqlite module, but that's just pysqlite, originally an independent
> project which has been around for quite some time.
It shouldn't be necessary to search for such libraries, but this doesn't
mean that standardization is the best solution. asdf-install and
cl-user.net are closer, IMHO. (No central control is the important thing
here.)
>> Where are the macros in Python? ;)
>
> Don't think I don't miss them! ;-)
;)
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
Pascal Costanza <··@p-cos.net> writes:
> Wolfram Fenske wrote:
>> Pascal Costanza <··@p-cos.net> writes:
>>
>> [...]
>>> I don't have a specific opinion wrt whether more standard libraries
>>> in CL would be good or not. [...] (Note that I am referring here to
>>> libraries that are supposedly important in the "modern" world. Of
>>> course, there are libraries that do affect me, but there I don't
>>> think that the lack of a standardization process is the most
>>> pressing issue.)
>> I'm not knowledgeable enough in that area to argue with you. What do
>> you think is the problem? Too few people actually writing and
>> maintaining the libraries?
>
> I am thinking about the CLOS MOP spec here, which contains a number
> of problems that cannot be easily fixed from outside the
> language. [...]
Sorry, I don't know anything about that.
>>> A downside I'd see in standardizing libraries is that things that are
>>> important nowadays, but could become irrelevant in, say, 10 or 20
>>> years from now, would still have to be supported then for backwards
>>> compatibility reason.
>> That's a good point. The process would have to be flexible enough to
>> deprecate and finally remove those parts of the library whose user
>> base isn't sufficiently large anymore. I suppose this is a lot easier
>> for Java, Python, and Ruby, all of which more or less are centrally
>> controlled.
>
> Central control is a bad idea. Unless the central authority is
> democratically controlled (but even then there are some issues
> left).
What I meant was that the situation of Python or Java makes it easier
for them to change the language or its standard libraries: they just
do it and that's it. The implementation _is_ the standard. I didn't
say that I wanted that for CL or that it was necessary in order to
have a standard library as big as Python's.
Besides, central control doesn't have to mean dictatorship (I guess my
examples were a bit misleading.). It can also mean something like the
Boost library for C++, which, as far as I can tell, is mostly a
community thing with some sort of review process. For things that can
be solved from within the language, like e. g. regular expressions or
XML parsers, this should be workable for CL.
> The concept of a central control assumes that the people in charge
> know what's "good" for the community. The application areas of Lisp
> are so diverse that I don't see how this could possibly work out.
But surely there are some areas that are basic enough as to be
relevant to more or less everyone. Take for example the C++ Standard
Template Library. IMO, it makes C++ so much more usable. Or the
Boost Library. Other examples would be Unicode strings, regular
expression engines, streams, threads, sockets, IPC. I would even go
as far as saying that stuff like XML parsers or HTTP clients are basic
enough to be put in a standard library, at least for now. In fact, if
someone has written a decent open source library that is of some
general interest, why *not* make it part of the standard library, so
that everybody can use it out of the box?
> Languages like Java, Perl, Ruby, Python have been designed with
> certain specific applications in mind.
Even if that is true, they tend to be used for all sorts of things,
especially Java. There may never be an OS written in Perl or Ruby,
but I don't see a real reason why one shouldn't use them for pretty
much everything else.
> Lisp is a true general-purpose language. For example, why should a
> web server library be more important than a library for genome
> sequences? Because "everyone" does web servers but "noone" does
> genome sequences? Nah...
Web servers tend to be of a more general interest than libraries for
genome sequences. It's the very same reason why DO, DOLIST, DOTIMES,
DEFUN and many more are part of CL.
The fact that there's a central place to get the web server doesn't
mean people can't get their genome sequence library somewhere else or
write it themselves.
> [...]
>
>>> I do most certainly think that standardization for standardization's
>>> sake is a very bad idea.
>> True.
>>
>>>> [...] IMO, Jyri has hit the nail on the hat.
>>> I don't think so. Java is mostly hype.
>> I was referring to the part where "developers can start to assume the
>> support will be there in all deployments."
>
> But that _is_ standardization for the sake of standardization.
> (Standardized libraries are typically preferred over
> non-standardized ones, although they may not be the best for the
> task at hand. That's not a good idea.)
IMO, that very much depends. I use Python's regular expressions and
Unicode strings all the time. And even for less basic stuff, like
e. g. XML parsers, why shouldn't I use what's in the standard library
if it does what I want? Using external libraries is always going to
mean more trouble setup-wise. If the standard stuff doesn't perform,
I can still use something else.
Also, I assume that there will be some kind of evolutionary principle
at work: stuff in the library is likely to get improved because it has
a lot of users that want to use it. And if some new library comes
along that is much better, it'll complement or replace what's in the
standard. With software, things tend to be "winner takes all,"
anyway. One just needs to make sure that the winner tends to be
what's in the standard library more often than not.
>> In a way, this makes e. g. Python more lightweight than CL: I can
>> use my Python program anywhere that Python is installed, whereas I
>> need to install additional libraries for an equivalent CL program.
>> IMO, this mostly disqualifies CL for writing small throwaway apps
>> (scripts), which is sad because I think that as a language, it
>> would be very suited to those tasks.
>
> This is an incorrect comparison. You don't have to stick to Common
> Lisp only. For example, if you require that clisp (or some other
> Common Lisp for that matter) is installed, you can immediately make a
> lot more assumptions about what is there and what is not.
Even so, I still think Python (or Ruby or Java) is a lot more usable
out of the box than Clisp. The larger the project and the more
experienced you are, the less this matters, but IMO the "batteries
included" approach has definitive advantages.
>> Still, should it be necessary to search for, say, regular expressions
>> or a portable ffi when the more experienced Lisp users know that
>> CL-PPCRE or UFFI are the way to go? I mean, it's not like Guido has
>> written all the Python libraries himself: e. g. Python 2.5 will have
>> an sqlite module, but that's just pysqlite, originally an independent
>> project which has been around for quite some time.
>
> It shouldn't be necessary to search for such libraries, but this
> doesn't mean that standardization is the best solution. asdf-install
> and cl-user.net are closer, IMHO.
So these are quasi standards. I can live with that.
> (No central control is the important thing here.)
I'm beginning to suspect you have a problem with authority ... ;-) But
kidding aside, I believe we don't want so different things after all.
I only used Python as an example because I know it quite well. Python
just happens to be controlled by only a few people. If there are
other ways to make CL more "batteries included," then I'm all for it.
It's just my opinion that some amount of central control is bound to
come with every such (quasi) standard. That's what keeps it together.
Even if it's a "collective effort": that just means everybody agrees
to control themselves. But I didn't start this branch in the
discussion to defend central control. I started it because I think a
big standard library ("batteries included") is a good thing and would
benefit CL. I still do.
> [...]
Regards
Wolfram
Wolfram Fenske wrote:
> Pascal Costanza <··@p-cos.net> writes:
>
>> Wolfram Fenske wrote:
>>> Pascal Costanza <··@p-cos.net> writes:
>>>
>>> [...]
>>>> I don't have a specific opinion wrt whether more standard libraries
>>>> in CL would be good or not. [...] (Note that I am referring here to
>>>> libraries that are supposedly important in the "modern" world. Of
>>>> course, there are libraries that do affect me, but there I don't
>>>> think that the lack of a standardization process is the most
>>>> pressing issue.)
>>> I'm not knowledgeable enough in that area to argue with you. What do
>>> you think is the problem? Too few people actually writing and
>>> maintaining the libraries?
>> I am thinking about the CLOS MOP spec here, which contains a number
>> of problems that cannot be easily fixed from outside the
>> language. [...]
>
> Sorry, I don't know anything about that.
If I were a "benevolent dictator", I would tell you to just trust me and
my instincts. Since I am not, I am working on a report that points out
the problems, in the hope that this will improve things in that regard
in the long run.
> Besides, central control doesn't have to mean dictatorship (I guess my
> examples were a bit misleading.). It can also mean something like the
> Boost library for C++, which, as far as I can tell, is mostly a
> community thing with some sort of review process. For things that can
> be solved from within the language, like e. g. regular expressions or
> XML parsers, this should be workable for CL.
I agree, but I don't think you need central control for that.
>> The concept of a central control assumes that the people in charge
>> know what's "good" for the community. The application areas of Lisp
>> are so diverse that I don't see how this could possibly work out.
>
> But surely there are some areas that are basic enough as to be
> relevant to more or less everyone. Take for example the C++ Standard
> Template Library. IMO, it makes C++ so much more usable. Or the
> Boost Library. Other examples would be Unicode strings, regular
> expression engines, streams, threads, sockets, IPC. I would even go
> as far as saying that stuff like XML parsers or HTTP clients are basic
> enough to be put in a standard library, at least for now. In fact, if
> someone has written a decent open source library that is of some
> general interest, why *not* make it part of the standard library, so
> that everybody can use it out of the box?
Even for simple things like XML parsers, there are very different ways
to implement them, with respective advantages and disadvantages that can
be important. It's not a good idea, IMHO, to paper over such issues.
>> Languages like Java, Perl, Ruby, Python have been designed with
>> certain specific applications in mind.
>
> Even if that is true, they tend to be used for all sorts of things,
> especially Java. There may never be an OS written in Perl or Ruby,
> but I don't see a real reason why one shouldn't use them for pretty
> much everything else.
They are moving targets. This creates maintenance problems in the long run.
>>> Still, should it be necessary to search for, say, regular expressions
>>> or a portable ffi when the more experienced Lisp users know that
>>> CL-PPCRE or UFFI are the way to go? I mean, it's not like Guido has
>>> written all the Python libraries himself: e. g. Python 2.5 will have
>>> an sqlite module, but that's just pysqlite, originally an independent
>>> project which has been around for quite some time.
>> It shouldn't be necessary to search for such libraries, but this
>> doesn't mean that standardization is the best solution. asdf-install
>> and cl-user.net are closer, IMHO.
>
> So these are quasi standards. I can live with that.
>
>> (No central control is the important thing here.)
>
> I'm beginning to suspect you have a problem with authority ... ;-) But
> kidding aside, I believe we don't want so different things after all.
> I only used Python as an example because I know it quite well. Python
> just happens to be controlled by only a few people. If there are
> other ways to make CL more "batteries included," then I'm all for it.
> It's just my opinion that some amount of central control is bound to
> come with every such (quasi) standard. That's what keeps it together.
> Even if it's a "collective effort": that just means everybody agrees
> to control themselves. But I didn't start this branch in the
> discussion to defend central control. I started it because I think a
> big standard library ("batteries included") is a good thing and would
> benefit CL. I still do.
We're in agreement. Things like asdf-install and cl-user.net are steps
in the right direction. There are still some issues to solve, but people
are working on them.
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
Wolfram Fenske wrote:
> What I meant was that the situation of Python or Java makes it easier
> for them to change the language or its standard libraries: they just
> do it and that's it. The implementation _is_ the standard. I didn't
> say that I wanted that for CL or that it was necessary in order to
> have a standard library as big as Python's.
I think it is an illusion to think you can change any reasonable
popular language. Take Java, in 1.0 AWT was the GUI toolkit and
most classes where synchronized to make them thread-safe. But when
it was determined that AWT needed substantial improvement and that
synchronized classes were to slow, too many Java programs where
out in the wild noone wanted to break. So they invented completely
new APIs to address the problems, enter Swing and the collection
framework - but did keep the old APIs around.
Peter
--
Ltk, the easy lisp gui http://www.peter-herth.de/ltk/
In article <··············@individual.net>,
Pascal Costanza <··@p-cos.net> wrote:
>Jyri J. Virkki wrote:
>> In article <··············@individual.net>,
>> Pascal Costanza <··@p-cos.net> wrote:
>>>
>>> None of these technologies have an officially sanctioned mechanism
>>> for change: Java is basically controlled by Sun, Eclipse by IBM and
>>> Python and Ruby by their respective designers.
>>
>> I am not familiar enough with the development process of the others to
>> comment but you're incorrect with respect to Java. The mechanism for
>> change is JCP (http://jcp.org).
>
>Who do you think controls that process?
Sun, to greater or lesser extent (more than it probably should but
less than I suspect you imply). I have participated in a couple JSR
expert groups but I haven't really looked at the political details.
I'm pretty sure if you had a proposal for a general purpose library to
add to the JDK and enough people agree, you can get it in.
Anyway the details of java's particular process are not at all
interesting in c.l.l. I was merely responding to "None of these
technologies have an officially sanctioned mechanism for change" with
a counterexample. For whatever ills it has, it achieves progress on
average (comparing JDK 1.0 to JDK 1.5 is sufficient proof).
The lisp 'community' doesn't seem to have anything equivalent, which
shows in the fact that there are discussions on usenet going back a
decade talking about the same issues.
>There are also downsides. It is quite often the case that the default
>Java libraries are not the best for the respective tasks at hand.
There are no downsides.
Common libraries cover the vast majority of use cases. For the rare
occasions where they fall short either in functionality or performance
you're still free to write a custom version. The benefit is you don't
have to write that custom version the other 98% of the time and you
can count on those libraries always being there out of the box (a.k.a
"batteries included").
--
Jyri J. Virkki - Santa Cruz, CA
Ron Garret <·········@flownet.com> writes:
> Two things to get out of the way at the outset:
>
> Now, for those of you who wish to respond I ask you to keep in mind the
> following:
>
> 1. The details of my criticisms are mostly irrelevant. What matters is
> that CL is far from perfect, and that it has no mechanism for change.
> So don't bother picking a nit about one of my specific criticisms unless
> you wish to argue that CL is perfect and doesn't need to change.
>
I agree CL is not perfect, but at the same time, I've never seen any
programming language which is perfect. Much of what you have outlined
could be said about most other languages. I just think this is part of
life and we need to just accept it. While I find it difficult to
absolutely disagree with some of your statements, I do find it hard to
either see any substantial point beyond stating things which are
fairly self evident.
For example, your criticism of the multiple implementations. This is
not unique to Lisp (C, C++, Pascal and in fact most non-compiled
languages have multiple implementations). I also think the benefits of
the single implementation is often over stated. For example, the great
claim of java that it would run on any architecture and behave the
same was soon shown to be a harder to achieve goal than expected -
anyone who has done substantial java apps knows you have to run it on
every platform you will support and expect to get diffeences and bugs
which are platform specific. Perl, well the fact you have books on
programming perl and programming perl on the Windows shows things are
different etc.
A single canonical implementation certainly has some theoretical
benefits, but also limitations and to some extent, it potentially
retards innovation. The fact we have so many good different
implementations pretty much means the genie is out of the bottle and
while some may see this as regrettable, I don't see any practicle
solution - we just have to live with it.
Many of your other points are interesting, but either don't seem to be
specific to CL or while possibly quite valid, fail to recognise CL is
still one of the better (some may say best) at dealing with the issue
of all the choices available. I have no problem with working to see
things improve, but feel we do need to recognise what we already have
- not perfect, but still pretty bloody good in comparison and more fun
to use than most other languages.
I do have to admit still having some issues with posts like yours -
not so much because I disagree, but more because its been said before
by many others and still nothing has changed or will change. I cannot
see many of your points having any real impact in changing CL - in
fact, I don't think CL can change or should change (for many reasons -
too much legacy code would break, too many old habits would need to be
modified, too many committees, etc etc).
I would have a lot more respect for posts which say "I feel CL has a
number of fundamental limitations which cannot easily be resolved and
am interested in getting other like minded lispers to join me in
creating a new improved lisp dialect etc. while this in itself is a
daunting task, its likely to be easier to achieve than many of the
changes you would like to the existing CL spec. If, as you beleive,
these are real problems, then others should also be in agreement and
finding a team to develop something new and improved shouldn't be too
difficult. to me, it certainly seems like a more viable direction than
attempting to get coordination within the existing CL framework with
its diverse implementations and existing history. If you cannot get
the support, then unfortunately, you are stuck in the wilderness and
will either have to accept it or do it all yourself and hope in the
end you will be prooven right and there will be a massive movement to
your new lisp dialect which has taken the best from the last 50 years
of lisp implementations.
Good luck
Tim
--
tcross (at) rapttech dot com dot au
In article <··············@tiger.rapttech.com.au>,
Tim X <····@nospam.dev.null> wrote:
> I would have a lot more respect for posts which say "I feel CL has a
> number of fundamental limitations which cannot easily be resolved and
> am interested in getting other like minded lispers to join me in
> creating a new improved lisp dialect etc.
http://www.flownet.com/gat/ciel.pdf
rg
In article <····························@news-europe.giganews.com>,
Rainer Joswig <······@lisp.de> wrote:
> In article <·······························@news.gha.chartermi.net>,
> Ron Garret <·········@flownet.com> wrote:
>
> > In article <····························@news-europe.giganews.com>,
> > Rainer Joswig <······@lisp.de> wrote:
> >
> > > In article <·······························@news.gha.chartermi.net>,
> > > Ron Garret <·········@flownet.com> wrote:
> > >
> > > > In article <··············@tiger.rapttech.com.au>,
> > > > Tim X <····@nospam.dev.null> wrote:
> > > >
> > > > > I would have a lot more respect for posts which say "I feel CL has a
> > > > > number of fundamental limitations which cannot easily be resolved and
> > > > > am interested in getting other like minded lispers to join me in
> > > > > creating a new improved lisp dialect etc.
> > > >
> > > > http://www.flownet.com/gat/ciel.pdf
> > > >
> > > > rg
> > >
> > > And where is it?
> >
> > It's nowhere, of course. (Well, that's not quite true. I actually have
> > a little implementation that I was futzing around with to try out some
> > ideas, but it is far from ready for prime time. And it is my attempts
> > to embed Ciel in CL that have made me keely aware of CL's shortcomings.
> > There aren't many, but those that do exist are quite significant IMO.)
> >
> > My point in citing Ciel is not that Ciel is going to be the savior of
> > Lisp. My point was merely that I actually did try Tim X's suggestion.
> > I have at one time or another tried most, of not all, of the things that
> > people have suggested I do to improve CL.
> >
> > Write code and contribute it to the community? Did that.
> > http://www.cliki.net/HTTP%20dot%20LSP
> >
> > Use Lisp in real world applications that could be cited as success
> > stories? Did that. Three or four times depending on how you count.
> >
> > Write guides to help newbies understand Lisp? Did that. Twice. (See
> > my home page.)
> >
> > Find ways to add useful features to the language within the language?
> > Did that. http://www.flownet.com/gat/locales.pdf
> >
> > Procure financial support for other people to do useful work for the
> > community? Did that (OpenMCL). Still doing it.
> >
> > Been there. Done that.
> >
> > rg
>
> That's fine. And thanks for the OpenMCL support. ;-)
>
It was my pleasure. Working with Gary Byers was a rare privilege.
> What you might need is some way where this gets more
> 'systematic' and others can join. Publish a plan.
> Set up a fund. May be others join, maybe not.
>
> Maybe again I'm naive, but a posting like
> 'my plan to make Common Lisp suck less' would
> find more support.
Been there. Done that. Failed miserably. :-( I'm hoping some young
blood will see this and come up with something innovative. I'll help in
any way I can. But I'm too busy (or maybe I should say old and tired)
to take the lead.
> Especially from someone who
> is for such a long time in the Lisp community.
> Sharing your frustrations is not that interesting
> for me. If you have again a some more exciting story I
> surely would be interested - but for now I'm out of
> this discussion...
Frankly, it isn't that much fun for me either.
rg
>
> http://www.flownet.com/gat/ciel.pdf
>
The text says, every data structure is just a special case of an
associative map, even a function. But I think it should be the other way
round, a map is a special case of a function (having a finite domain). I
think I even saw an OO language having Map inherit from Function.
The rest sounds pretty interesting, especially the
don't-manipulate-text-part, which I do think for quite a while...
Regards,
Benjamin
Ron Garret wrote:
> some good stuff here.
>
Ron, I'd really like to speak with you offline about LISP and the
comments you
have made. Please can you email me so we can start the conversation.
My email is: j l a d d @ i i n e t . n e t . a u without the spaces.
I look forward to your email.
Rgs, James.
Ron Garret <·········@flownet.com> writes:
> Two things to get out of the way at the outset:
>
> 1. Note that the title of this post is *HOW* CL sucks, not *WHY* it
> sucks. The difference is significant. Please take the time to
> understand it before you flame me.
>
> 2. I'm not going to say anything I haven't said a thousand times
> before, so those of you who know me (that means you, Kenny) will not
> find anything new here so you may as well not even bother.
>
> I am writing this because of the debate surrounding Steve Yegge's recent
> blog entries on Lisp. It is unfortunate that he made so many technical
> mistakes in his posts because they distract people from the fact that
> underneath all the errors he is actually making a valid point, that
> being that CL has very significant problems that are barriers to its
> adoption. (Some people think this is a feature, that having a few
> obstacles to overcome keeps out the rif raf. I suppose this is a
> defensible position, but I don't subscribe to it.)
>
> I'm going to point out just three problems with CL. There are more.
> None of these are original observations.
>
> 1. CL lacks standardized support for many operations that are
> necessities in today's world (e.g. sockets, database connectivity,
> foreign functions). Moreover, it lacks any mechanism by which these
> features could be standardized. It is claimed that there are portable
> libraries that work across implementations that provide de facto
> standards, e.g. UFFI, but these claims are false. I don't have time to
> get into details at the moment, but the fact of the matter is that
> trying to use Lisp for e.g. writing a Web server is an incredibly
> painful experience compared to doing the same thing in e.g. Python.
>
> The Balkanization of the CL implementation space also has the
> consequence that one must choose between using implementation-specific
> features and thus limiting the potential audience for one's code to a
> niche within a niche, or writing to the least common denominator, which
> generally means writing an awful lot of #+ reader macros.
>
> 2. Even for the one thing that CL claims to be particularly good at --
> as a platform for embedding domain-specific languages -- it has
> significant limits. To embed languages that differ from CL's semantics
> in certain ways requires significant effort. To cite but one example: I
> would like to embed a language that is very similar to Common Lisp, but
> which differs in how it handles global variable references (to use
> global lexical environments) and ((function-returning-a-function)
> arguments) syntax. The former can be done using symbol macros, but only
> if the top-level definitions precede their first use. If you reference
> a global before defining it then you're screwed. The latter cannot be
> done at all within CL unless you write a full code walker. But adding
> this capability is utterly trivial within an implementation. In MCL it
> takes two lines of code. And if it were done it would result in
> strictly greater expressive power. Furthermore, it is not even
> necessary to agree on the semantics of ((...) ...). One could simply
> add a new macro defining form (or even a global variable) to set a
> user-definable hook for transforming expressions whose CARs are lists
> that do not begin with LAMDBA. All that would need to be agreed upon is
> the name of this form. Furthermore, this would result in strictly
> greater expressive power. It would be strictly backwards-compatible.
> And It would serve the needs of a number of users who are not currently
> being served (e.g. those who prefer to do functional-style programming
> without having to type FUNCALL all the time.)
>
> But despite the fact that this change is easy and only good could come
> of it, it does not happen because there is no process by which this
> change can be effected (which is, I believe, a direct consequence of the
> fact that the realities of CL politics are that CL is utterly resistant
> to all change, though I would dearly love to be proven wrong on that).
>
> (Oh, and anyone who wishes to prove me wrong, please not that there is a
> big big difference between effecting change in CL and effecting change
> in an implementation of CL.)
>
> 3. Much of CL's core is badly designed. For example, consider NTH and
> ELT. The functionality of ELT is a strict superset of NTH, so why have
> NTH cluttering up the language? (To say nothing of the fact that the
> order of the arguments in these two functions are gratuitously
> reversed.) Why is the function that computes the difference of two sets
> called SET-DIFFERENCE, but the function that computes the intersection
> of two sets called simply INTERSECTION? And why do all of these
> functions operate on lists, not sets? It's because there are no sets in
> CL, which means that CL leads one to prematurely "optimize" sets as
> lists. (I put optimize in scare quotes because in fact this is rarely
> an optimization, especially when your sets get big, and most of the time
> you have to go back and rip out huge chunks of code to replace your
> lists with hash tables or binary trees.) I could go on and on.
>
> Now, for those of you who wish to respond I ask you to keep in mind the
> following:
>
> 1. The details of my criticisms are mostly irrelevant. What matters is
> that CL is far from perfect, and that it has no mechanism for change.
> So don't bother picking a nit about one of my specific criticisms unless
> you wish to argue that CL is perfect and doesn't need to change.
>
> 2. I know a lot more about Lisp that Steve Yegge. I spent twenty years
> programming in Lisp for a living. I have authored some highly
> referenced papers on Lisp. I am far from the world's foremost expert,
> but I'm no newbie. If you think I'm wrong about a technical point you
> should think twice.
>
> 3. I do not hate Lisp. It is and has always been my favorite
> programming languages. My love for Lisp pretty much destroyed my career
> as a programmer. My motivation for criticising Lisp is not to convince
> people not to use it. It is to effect changes that I believe are
> necessary to get more people to use it. To quote Paul Graham, "It's not
> Lisp that sucks, it's Common Lisp that sucks." And actually, I would
> soften that somewhat: it's not Common Lisp that sucks, it's some parts
> of Common Lisp that suck. But make no mistake, some parts of Common
> Lisp really do suck, and unless they are fixed a lot of people -- myself
> included -- won't be able to use it even though they may want to really
> badly.
>
> rg
I view this whole situation as somewhat analogous to the state of
Linux. A newbie to these systems might be as overwhelmed with the
choices available to him/her, and our hypothetical newbie would
probably also have trouble getting started with Linux if he had had no
experience with it. They would definitely run into differences
between the distributions, like trying to follow a tutorial written
for apt-get but on a gentoo system, or trying to compile
BSD-specific programs on a Linux machine.
Yet I don't think anyone would, with a straight face, approach
comp.os.unix arguing that these efforts should (or even could) be
consolidated into one system. There is POSIX to keep these systems
similar enough to prevent anarchy (much like the CL spec) but there
are still numerous differences between each and it is still not easy
for a total newbie to get started.
But these kinds of problems have not been addressed by appointing a
benevolent dictator of the free UNIXes (I think you'll agree this is
probably not possible). Instead, the community itself has evolved to
make things better. Ubuntu has appeared and made it easy for newbies
to get to started (not to imply that it's only for newbies; I use
Ubuntu on all of my machines); Gentoo was built for those who hold to
the delusion that spending hours compiling their software and/or
watching it break is productive, Lindows (is it Lindash now?) for
those who don't believe in security, Debian for those who want
stability and/or are advocates of Free software.
Like the Linux/BSD community, the CL community is growing organically
and without central management, but I don't think this is a bad thing.
I think talking about stopping this process makes as much sense as it
would in the Linux/BSD analogy. It is important to keep in mind (as
several others have mentioned) that the latest wave of Lisp interest
is not much more than five or six years old and that Python in 1995
was certainly not as polished as it might appear today. Likewise, the
Linux community was small potatos five or six years into its lifetime,
at least compared to its current state. I am not arguing that things
shouldn't change, but I am arguing against the idea that Lisp needs
central control or that Lisp is doomed to failure because five years
into its resurrection it has yet to build the infrastructure that
15-year-old languages have built. I think what we actually have is
tremendously impressive - three open-source native-compiling Lisp
implementations, McCLIM, UncommonWeb, Climacs, Cliki, Araneida, CLSQL,
SLIME. This is a lot of good software for a tiny and relatively
newish community.
Bill
--
"...and when, another time, I discovered that he considered not
unworthy of reflection in one of those mirrors of absolute truth which
were his writings a remark similar to one which I had had occasion to
make about our friend M. Legrandin, ...then it was suddenly revealed
to me that my own humble existence and the realms of the true were
less widely separated than I had supposed, that at certain points they
actually collided, and in my newfound confidence and joy, I had wept
upon his printed page as in the arms of a long-lost father."
In article <··············@rpi.edu>, Bill Atkins <············@rpi.edu>
wrote:
> I view this whole situation as somewhat analogous to the state of
> Linux.
Except that Linux has a process for managing change, which IMO
contributes significantly to its success.
rg
Ron Garret <·········@flownet.com> writes:
> In article <··············@rpi.edu>, Bill Atkins <············@rpi.edu>
> wrote:
>
>> I view this whole situation as somewhat analogous to the state of
>> Linux.
>
> Except that Linux has a process for managing change, which IMO
> contributes significantly to its success.
>
> rg
If you are referring to the kernel proper, then yes. But if you are
referring to the operating system created by a distro, then there is
no central control except the distro's.
--
"...and when, another time, I discovered that he considered not
unworthy of reflection in one of those mirrors of absolute truth which
were his writings a remark similar to one which I had had occasion to
make about our friend M. Legrandin, ...then it was suddenly revealed
to me that my own humble existence and the realms of the true were
less widely separated than I had supposed, that at certain points they
actually collided, and in my newfound confidence and joy, I had wept
upon his printed page as in the arms of a long-lost father."
In article <··············@rpi.edu>, Bill Atkins <············@rpi.edu>
wrote:
> Ron Garret <·········@flownet.com> writes:
>
> > In article <··············@rpi.edu>, Bill Atkins <············@rpi.edu>
> > wrote:
> >
> >> I view this whole situation as somewhat analogous to the state of
> >> Linux.
> >
> > Except that Linux has a process for managing change, which IMO
> > contributes significantly to its success.
> >
> > rg
>
> If you are referring to the kernel proper, then yes. But if you are
> referring to the operating system created by a distro, then there is
> no central control except the distro's.
Correct. I would say that the kernel plays a role analogous to the
hyperspec in CL, and the fact that Linux has a process for managing
change in the kernel contributes to its success.
If Linux were like CL, the kernel design would have been frozen at some
point in its history. I think it's pretty clear that if that had
happened Linux would not be nearly as successful as it is today.
rg
Ron Garret wrote:
> In article <··············@rpi.edu>, Bill Atkins <············@rpi.edu>
> wrote:
>
> Correct. I would say that the kernel plays a role analogous to the
> hyperspec in CL, and the fact that Linux has a process for managing
> change in the kernel contributes to its success.
That's a category error: the hyperspec is a *specification*, the linux
kernel is a program (which may or may not correspond to some
specification).
>
> If Linux were like CL, the kernel design would have been frozen at some
> point in its history. I think it's pretty clear that if that had
> happened Linux would not be nearly as successful as it is today.
And, of course, that is exactly what *has* happened, once you fix the
category error: at some point in time various specifications for
Unix-like systems appeared, and the various implementations adhere, or
try to, to these specifications (the Linux kernel is but one instance
of an implementation of part of one of these specifications, and not
even a very accurate implementation). Of course the various
implementations also have a bunch of extensions for which either no
specifications or no standard specifications exist (for instance there
is no standard for Solaris zones). That's exactly the same situation as
CL is in.
--tim
In article <······················@u72g2000cwu.googlegroups.com>,
"Tim Bradshaw" <··········@tfeb.org> wrote:
> Ron Garret wrote:
> > In article <··············@rpi.edu>, Bill Atkins <············@rpi.edu>
> > wrote:
> >
> > Correct. I would say that the kernel plays a role analogous to the
> > hyperspec in CL, and the fact that Linux has a process for managing
> > change in the kernel contributes to its success.
>
> That's a category error: the hyperspec is a *specification*, the linux
> kernel is a program (which may or may not correspond to some
> specification).
It is not impossible for objects in two different categories to serve an
analogous role in two different processes.
> > If Linux were like CL, the kernel design would have been frozen at some
> > point in its history. I think it's pretty clear that if that had
> > happened Linux would not be nearly as successful as it is today.
>
> And, of course, that is exactly what *has* happened, once you fix the
> category error: at some point in time various specifications for
> Unix-like systems appeared, and the various implementations adhere, or
> try to, to these specifications (the Linux kernel is but one instance
> of an implementation of part of one of these specifications, and not
> even a very accurate implementation). Of course the various
> implementations also have a bunch of extensions for which either no
> specifications or no standard specifications exist (for instance there
> is no standard for Solaris zones). That's exactly the same situation as
> CL is in.
Not quite.
First, the Linux kernel (and Python and Ruby) have only a single
implementation. That implementation's behavior provides an implicit
specification. Furthermore, the implementation typically comes with
documentation which serves as an explicit specification. Both the
implicit and explicit specifications evolve over time in a more or less
orderly manner. In particular, it is easy for an outsider to tell (
when a certain set of changes has been "officially" adopted and they can
reasonably begin to rely on them.
Second, the distribution-specific extensions to Linux are typically not
things that constitute crucial core functionality, or that are barriers
to sharing code written on one distribution with another. There are
exceptions to this, of course, but most of them are of the category of
not having the right version of some library or other. Thus, even when
such problems are encountered, the source of the problem and the actions
needed to remedy it are usually readily apparent. This is often not the
case when code written in one CL implementation fails to run in another.
In a few cases there is Balkanization even in the Linux world e.g. on
the desktop. The negative consequences are apparent: Linux has not
succeeded on the desktop nearly as well as it has in the server market.
rg
Ron Garret <·········@flownet.com> writes:
> In article <······················@u72g2000cwu.googlegroups.com>,
> First, the Linux kernel (and Python and Ruby) have only a single
> implementation. That implementation's behavior provides an implicit
> specification. Furthermore, the implementation typically comes with
> documentation which serves as an explicit specification. Both the
> implicit and explicit specifications evolve over time in a more or less
> orderly manner. In particular, it is easy for an outsider to tell (
> when a certain set of changes has been "officially" adopted and they can
> reasonably begin to rely on them.
You missed the analogy. SBCL is to Common Lisp as Linux is to POSIX.
Rewriting your paragraph:
SBCL has only a single implementation. That implementation's behavior
provides an implicit specification. Furthermore, the implementation
typically comes with documentation which serves as an explicit
specification. Both the implicit and explicit specification evolve
over time in a more or less orderly manner. In particular, it is easy
for an outsider to tell when a certain set of changes has been
"officially" adopted and they can reasonably begin to rely on them.
No, let's try adding a fact:
The SBCL specification, whether you mean the implicit or explicit one,
contains a full implementation of the Common Lisp specification.
It's too bad that this fact does not apply to the "Linux is to POSIX"
half of the analogy, but that only further weakens your point than the
analogy itself has.
> In a few cases there is Balkanization even in the Linux world e.g. on
> the desktop. The negative consequences are apparent: Linux has not
> succeeded on the desktop nearly as well as it has in the server market.
However, POSIX has succeeded sufficiently in both the desktop and
server markets as to be more or less implemented by every major
operating system.
In article <··············@hermes.theari.com>,
Ari Johnson <·········@gmail.com> wrote:
> Ron Garret <·········@flownet.com> writes:
>
> > In article <······················@u72g2000cwu.googlegroups.com>,
> > First, the Linux kernel (and Python and Ruby) have only a single
> > implementation. That implementation's behavior provides an implicit
> > specification. Furthermore, the implementation typically comes with
> > documentation which serves as an explicit specification. Both the
> > implicit and explicit specifications evolve over time in a more or less
> > orderly manner. In particular, it is easy for an outsider to tell (
> > when a certain set of changes has been "officially" adopted and they can
> > reasonably begin to rely on them.
>
> You missed the analogy. SBCL is to Common Lisp as Linux is to POSIX.
Except for one thing: scale. Linux is large enough that it has had
another level of splitting, into multiple distributions. If SBCL were
as successful as Linux we would not be having this conversation. (Heck,
if all of CL were as successful as even one Linux distro we would not be
having this conversation!)
rg
Ron Garret <·········@flownet.com> writes:
> In article <··············@hermes.theari.com>,
> Ari Johnson <·········@gmail.com> wrote:
>
>> Ron Garret <·········@flownet.com> writes:
>>
>> > In article <······················@u72g2000cwu.googlegroups.com>,
>> > First, the Linux kernel (and Python and Ruby) have only a single
>> > implementation. That implementation's behavior provides an implicit
>> > specification. Furthermore, the implementation typically comes with
>> > documentation which serves as an explicit specification. Both the
>> > implicit and explicit specifications evolve over time in a more or less
>> > orderly manner. In particular, it is easy for an outsider to tell (
>> > when a certain set of changes has been "officially" adopted and they can
>> > reasonably begin to rely on them.
>>
>> You missed the analogy. SBCL is to Common Lisp as Linux is to POSIX.
>
> Except for one thing: scale. Linux is large enough that it has had
> another level of splitting, into multiple distributions. If SBCL were
> as successful as Linux we would not be having this conversation. (Heck,
> if all of CL were as successful as even one Linux distro we would not be
> having this conversation!)
Linux did not "split" into multiple distributions any more than SBCL
and OpenMCL are splits from Common Lisp. And that just puts you one
level further away from a formally-specified standard, even if there
were a split (which there is not - Debian GNU/Linux uses the same
Linux as does Fedora Core).
Scale is not relevant to standards. Either there is a
formally-specified standard or there is not. For POSIX and for Common
Lisp, there are formal standards. For Linux and SBCL, there are not.
I do personally wish that there were only one implementation of Common
Lisp, and that it was free and ran on every platform. There's not.
The solutions are:
1. Use one implementation and base your application on its extensions.
This is perfectly viable, just as it's perfectly viable to build your
application on a Debian GNU/Linux server and not worry if it will be
portable to IRIX.
2. Use a compatibility layer, optionally one that you've written. Any
application large enough to care about portability in its future will
have a portability layer anyhow, just on account of the good
programming practice of modular code.
3. Change the Common Lisp specification until it meets the needs of
your application without the need for any implementation-specific
extensions. See Peter Seibel's thread on features that can only be
provided by the implementation for a place to be constructive on this
point.
Ron Garret <·········@flownet.com> writes:
> In article <··············@hermes.theari.com>,
> Ari Johnson <·········@gmail.com> wrote:
>
>> Ron Garret <·········@flownet.com> writes:
>>
>> > In article <······················@u72g2000cwu.googlegroups.com>,
>> > First, the Linux kernel (and Python and Ruby) have only a single
>> > implementation. That implementation's behavior provides an implicit
>> > specification. Furthermore, the implementation typically comes with
>> > documentation which serves as an explicit specification. Both the
>> > implicit and explicit specifications evolve over time in a more or less
>> > orderly manner. In particular, it is easy for an outsider to tell (
>> > when a certain set of changes has been "officially" adopted and they can
>> > reasonably begin to rely on them.
>>
>> You missed the analogy. SBCL is to Common Lisp as Linux is to POSIX.
>
> Except for one thing: scale. Linux is large enough that it has had
> another level of splitting, into multiple distributions. If SBCL were
> as successful as Linux we would not be having this conversation. (Heck,
> if all of CL were as successful as even one Linux distro we would not be
> having this conversation!)
>
> rg
Lets be a little consistent here. It was established quite a few posts
back that we were referring to the kernel when discussing linux, not
the distributions (thats a whole different kettle of fish).
I'd also argue that SBCL, CMUCL and various other CL implementations
have been way more successful than many Linux distributions - many of
which seem to have just vanished or are only just hanging in there -
Caldera and Yellow Dog are two which come to mind. Others are famous
for the difficulties associated with installing them, like Gentoo.
Its a pretty weak analagy really - A linux distribution is really just
a convenient collection and packaging of a whole heap of different
things, many of which are not related to each other. While there are
some emerging standards, such as the Linux Standard Base and the Linux
filesystem specification, the extent to which distributions adhere to
these standards varies wildly and there is still a lot of debate
regarding the specifications.
However, maybe this does raise a possibility for addressing some of
your original concerns, namely making CL as accessible as python, perl
or even (gasp) Java. Why not put together a CL specific Linux
distribution. It could be based on Debian (as Debian already has
really quite nice support for CL.
The distribution would come with debian packaged versions of a set of
useful CL libraries (it already has quite a few), emacs, slime, maybe
the vi-slime project stuff, asdf, etc. The web server could have
mod_lisp installed by default or perhaps even use a CL web server
rather than apache and as far as possible, all the useful little
utilities that come with distributions (and which are part of what
differentiates them) could be written in lisp.
In fact, if we made it a 'lisp family' distribution, we could also
leverage of all the good stuff using things like rep (the X windows
manager could be either sawfish or stumpwm), utilities could be
written in CL, rep, scsh, lush etc - maybe even include the CLIMACS
stuff.
The speed of modern desktops now makes running linux from a CD not
only possible, but quite usable, so there isn't any reason windows
users could also try it out.
I guess its like taking "lisp in a box" to the next level - a whole
development environment customized/tailored for lisp hacking and based
on lisp as far as possible.
Given what Debian does in support of lisp, this is quite an achievable
goal for someone with the time to work on it. Currently, Debian
provides a nice environment in which you can run multiple CL
implementations and everything is setup to use the lisp controller and
asdf. In fact, its largely due to the really nice lisp support wthin
Debian that I don't agree with many of your points - I actually
already have a CL envrionment which allows me to switch between
different implementations, install libraries as easily as apt-get
install library-name and then use those libraries with a simple asdf
load command. All thats really needed now is for more CL libraries
which have been 'debianised' - but that just depends on someone
willing to create the packages. When I find a need a package which
isn't already debianised, I'll do this myself. So far, everything I've
needed has already been done.
The only possible sticking point is that Debian has a very strict
licensing policy - which is a good thing for what they are trying to
achieve. The normal Debian license may not be liberal enough for the
CL community - but then again, maybe it would be fine if we just
wanted to make a distro which was friendly to new users and which
would allow them to get up and become productive within a short period
(similar to python/perl/java users).
Tim
--
tcross (at) rapttech dot com dot au
In article <··············@tiger.rapttech.com.au>,
Tim X <····@nospam.dev.null> wrote:
> Ron Garret <·········@flownet.com> writes:
>
> > In article <··············@hermes.theari.com>,
> > Ari Johnson <·········@gmail.com> wrote:
> >
> >> Ron Garret <·········@flownet.com> writes:
> >>
> >> > In article <······················@u72g2000cwu.googlegroups.com>,
> >> > First, the Linux kernel (and Python and Ruby) have only a single
> >> > implementation. That implementation's behavior provides an implicit
> >> > specification. Furthermore, the implementation typically comes with
> >> > documentation which serves as an explicit specification. Both the
> >> > implicit and explicit specifications evolve over time in a more or less
> >> > orderly manner. In particular, it is easy for an outsider to tell (
> >> > when a certain set of changes has been "officially" adopted and they can
> >> > reasonably begin to rely on them.
> >>
> >> You missed the analogy. SBCL is to Common Lisp as Linux is to POSIX.
> >
> > Except for one thing: scale. Linux is large enough that it has had
> > another level of splitting, into multiple distributions. If SBCL were
> > as successful as Linux we would not be having this conversation. (Heck,
> > if all of CL were as successful as even one Linux distro we would not be
> > having this conversation!)
> >
> > rg
>
> Lets be a little consistent here. It was established quite a few posts
> back that we were referring to the kernel when discussing linux, not
> the distributions (thats a whole different kettle of fish).
Right. I only brought up the distros to illustrate my point about
scale. I did not intend for them to be part of the analogy.
> Its a pretty weak analagy really
Yes. I'm beginning to regret bringing it up.
> However, maybe this does raise a possibility for addressing some of
> your original concerns, namely making CL as accessible as python, perl
> or even (gasp) Java. Why not put together a CL specific Linux
> distribution. It could be based on Debian (as Debian already has
> really quite nice support for CL.
Not a bad idea.
rg
Ron Garret wrote:
>> However, maybe this does raise a possibility for addressing some of
>> your original concerns, namely making CL as accessible as python, perl
>> or even (gasp) Java. Why not put together a CL specific Linux
>> distribution. It could be based on Debian (as Debian already has
>> really quite nice support for CL.
>
> Not a bad idea.
Lisp in a box is a step in that direction, no?
See http://www.gigamonkeys.com/book/lispbox/ and
http://common-lisp.net/project/lispbox/
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
Ron Garret wrote:
> It is not impossible for objects in two different categories to serve an
> analogous role in two different processes.
>
Not, it isn't. But your analogy is obviously not very useful because
it leads to lots of wildly innacurate conclusions (for instance the
difference in effort to produce a minimal OS based on the Linux kernel
vs that of producing a minimal CL based on the CL standard).
Fortunately there is a much closer analogy which is that in both areas
there are specifications (POSIX say, and the CL standard) each with
multiple implementations (Linux, Solaris etc and LispWorks, CMUCL etc).
Those implementations have varying extensions to the standards they
implement, the quality of the implementation, their commercial status,
open sourceness &c &c.
And if you can take off your Linux goggles for a minute, you'll see
that the situation with the various Unix-like OS implementations is
really very close to that with CL.
--tim
Ron Garret <·········@flownet.com> writes:
> In article <··············@rpi.edu>, Bill Atkins <············@rpi.edu>
> wrote:
>
>> Ron Garret <·········@flownet.com> writes:
>>
>> > In article <··············@rpi.edu>, Bill Atkins <············@rpi.edu>
>> > wrote:
>> >
>> >> I view this whole situation as somewhat analogous to the state of
>> >> Linux.
>> >
>> > Except that Linux has a process for managing change, which IMO
>> > contributes significantly to its success.
>> >
>> > rg
>>
>> If you are referring to the kernel proper, then yes. But if you are
>> referring to the operating system created by a distro, then there is
>> no central control except the distro's.
>
> Correct. I would say that the kernel plays a role analogous to the
> hyperspec in CL, and the fact that Linux has a process for managing
> change in the kernel contributes to its success.
>
> If Linux were like CL, the kernel design would have been frozen at some
> point in its history. I think it's pretty clear that if that had
> happened Linux would not be nearly as successful as it is today.
>
> rg
As you're so fond of pointing out, the details are not important here.
But, to clarify, Linux and BSD are both implementations of POSIX as
SBCL, CLISP, Allegro, etc. are implementations of Common Lisp. This
is what's important for understanding my analogy. What you're talking
about would be analogous to SBCL, for example, freezing its features.
But really, the details don't matter. The gist of my argument is that
once fragmentation occurs, it's not always possible to unify the
differing implementations. POSIX and Common Lisp were both created
because fragmentation was causing significant problems in their
respective industries. If the UNIX industry had collapsed soon after
POSIX was created, it doesn't seem economically reasonable that any
great effort would be made to go through the expense and the
politicking necessary to keep the standard updated.
How do you suggest we build "a process for change" in light of these
facts? You claimed in a recent post that you had made suggestions on
how to fix things; I don't remember reading anything even remotely
like that. Do you disagree that de facto standards are not a
reasonable bridge to get Lisp from near-oblivion to some shadow of its
former glory?
Also, why have you failed to produce any more than two or three
laughably trivial examples to explain why Common Lisp "sucks"? NTH
and ELT may be cruft, but so what? strtok is deprecated in the C
library, but I have yet to see C implode because of it. Eliminating
FUNCALL's? Why? If it matters, why is a macro to transform your
syntax into FUNCALL's insufficient? Initial investment in setting up
libraries is not something I personally care about - if the
productivity gains involved from using Lisp dominate the upfront
hassle of making sure a library works on your implementation or of
implementing a compatibility layer, is it not better to use Lisp and
spend some time gettings things set up? If you truly do care about
installing libraries, why not sit down and write some code to fix it,
instead of clogging up comp.lang.lisp with this rubbish?
Bill Atkins <············@rpi.edu> writes:
> like that. Do you disagree that de facto standards are not a
> reasonable bridge to get Lisp from near-oblivion to some shadow of its
> former glory?
Do you disagree that de facto standards *are* a reasonable bridge to
get Lisp ....
--
In article <··············@rpi.edu>, Bill Atkins <············@rpi.edu>
wrote:
> Ron Garret <·········@flownet.com> writes:
>
> > In article <··············@rpi.edu>, Bill Atkins <············@rpi.edu>
> > wrote:
> >
> >> Ron Garret <·········@flownet.com> writes:
> >>
> >> > In article <··············@rpi.edu>, Bill Atkins <············@rpi.edu>
> >> > wrote:
> >> >
> >> >> I view this whole situation as somewhat analogous to the state of
> >> >> Linux.
> >> >
> >> > Except that Linux has a process for managing change, which IMO
> >> > contributes significantly to its success.
> >> >
> >> > rg
> >>
> >> If you are referring to the kernel proper, then yes. But if you are
> >> referring to the operating system created by a distro, then there is
> >> no central control except the distro's.
> >
> > Correct. I would say that the kernel plays a role analogous to the
> > hyperspec in CL, and the fact that Linux has a process for managing
> > change in the kernel contributes to its success.
> >
> > If Linux were like CL, the kernel design would have been frozen at some
> > point in its history. I think it's pretty clear that if that had
> > happened Linux would not be nearly as successful as it is today.
> >
> > rg
>
> As you're so fond of pointing out, the details are not important here.
> But, to clarify, Linux and BSD are both implementations of POSIX as
> SBCL, CLISP, Allegro, etc. are implementations of Common Lisp. This
> is what's important for understanding my analogy. What you're talking
> about would be analogous to SBCL, for example, freezing its features.
No. The POSIX standard is analogous to the hyperspec. Linux and BSD,
as implementations of Posix, are analogous to, say, SBCL and CLisp.
There are two significant differences between the Posix community and
the CL community.
First, the Posix community has processes for developing and evolving
standards beyond Posix (e.g. the standard C library, the C++ template
library, etc.). The CL community has no analogous process.
Second, the size of each branch of the POSIX community is vastly larger
than the entire CL community all put together. So the posix community
is better able to withstand the negative consequences of Balkanization
than the CL community can.
> But really, the details don't matter. The gist of my argument is that
> once fragmentation occurs, it's not always possible to unify the
> differing implementations.
You don't have to unify the implementations, just (certain parts of)
their APIs.
> How do you suggest we build "a process for change" in light of these
> facts?
It seems pointless to answer that question in the absence of agreement
that there is a problem that is worth addressing.
> You claimed in a recent post that you had made suggestions on
> how to fix things; I don't remember reading anything even remotely
> like that. Do you disagree that de facto standards are not a
> reasonable bridge to get Lisp from near-oblivion to some shadow of its
> former glory?
I think it's important that the standards be codified and that there be
some mechanism for "officially" marking the transition between "under
consideration" (or under development) and "adopted." Right now the
transition is too fuzzy. It makes it too hard to tell whether one can
rely on a particular feature.
> Also, why have you failed to produce any more than two or three
> laughably trivial examples to explain why Common Lisp "sucks"?
I don't think that the lack of a standard sockets API is laughably
trivial.
I chose a few trivial examples because it's easier to argue the merits
of trivial examples than complicated ones, and I didn't want to get too
bogged down in arguing the benefits because that's not the point.
If you want non-trivial examples, there are lots of those too. The MOP
for example. Or anything listed here:
http://www.cs.cmu.edu/Groups/AI/html/hyperspec/HyperSpec/Issues/Issues-Ca
tegorized.html
Imagine how out of control the discussion could get if we started
drilling down into those details here.
> if the
> productivity gains involved from using Lisp dominate the upfront
> hassle of making sure a library works on your implementation or of
> implementing a compatibility layer, is it not better to use Lisp and
> spend some time gettings things set up?
No, because in addition to the up-front costs, I also have to accept the
risk that nasty surprises are lurking. For example, suppose I get
everything up and running and then find that under heavy load my Lisp
implementation crashes. The developers of my implementation may or may
not be able to help, and switching to another implementation may or may
not work. The only data point I have to help me assess the probability
of this scenario is that it already happened in one very prominent case
(Reddit). That makes me very leery.
If there were e.g. standardized library APIs that would help by making
it easier to assess how many implementations out there conformed to the
particular APIs that I was relying on. Looking at the specs to see if
an implementation conforms (or at least purports to conform) to
specification X, Y and Z is a lot easier and cheaper than actually
trying it (especially if in addition to trying it you actually have to
generate specifications X, Y and Z).
> If you truly do care about
> installing libraries, why not sit down and write some code to fix it,
> instead of clogging up comp.lang.lisp with this rubbish?
Because the problem I am talking about cannot be effectively addressed
merely by writing code. If you think it can then you have not
understood the problem.
rg
Ron Garret <·········@flownet.com> writes:
> In article <··············@rpi.edu>, Bill Atkins <············@rpi.edu>
> wrote:
>
>> Ron Garret <·········@flownet.com> writes:
>>
>> > In article <··············@rpi.edu>, Bill Atkins <············@rpi.edu>
>> > wrote:
>> >
>> >> Ron Garret <·········@flownet.com> writes:
>> >>
>> >> > In article <··············@rpi.edu>, Bill Atkins <············@rpi.edu>
>> >> > wrote:
>> >> >
>> >> >> I view this whole situation as somewhat analogous to the state of
>> >> >> Linux.
>> >> >
>> >> > Except that Linux has a process for managing change, which IMO
>> >> > contributes significantly to its success.
>> >> >
>> >> > rg
>> >>
>> >> If you are referring to the kernel proper, then yes. But if you are
>> >> referring to the operating system created by a distro, then there is
>> >> no central control except the distro's.
>> >
>> > Correct. I would say that the kernel plays a role analogous to the
>> > hyperspec in CL, and the fact that Linux has a process for managing
>> > change in the kernel contributes to its success.
>> >
>> > If Linux were like CL, the kernel design would have been frozen at some
>> > point in its history. I think it's pretty clear that if that had
>> > happened Linux would not be nearly as successful as it is today.
>> >
>> > rg
>>
>> As you're so fond of pointing out, the details are not important here.
>> But, to clarify, Linux and BSD are both implementations of POSIX as
>> SBCL, CLISP, Allegro, etc. are implementations of Common Lisp. This
>> is what's important for understanding my analogy. What you're talking
>> about would be analogous to SBCL, for example, freezing its features.
>
> No. The POSIX standard is analogous to the hyperspec. Linux and BSD,
> as implementations of Posix, are analogous to, say, SBCL and CLisp.
I don't get it. Isn't that exactly what I just said?
> There are two significant differences between the Posix community and
> the CL community.
>
> First, the Posix community has processes for developing and evolving
> standards beyond Posix (e.g. the standard C library, the C++ template
> library, etc.). The CL community has no analogous process.
POSIX has economic justification for maintaning its process for
change.
> Second, the size of each branch of the POSIX community is vastly larger
> than the entire CL community all put together. So the posix community
> is better able to withstand the negative consequences of Balkanization
> than the CL community can.
>
>> But really, the details don't matter. The gist of my argument is that
>> once fragmentation occurs, it's not always possible to unify the
>> differing implementations.
>
> You don't have to unify the implementations, just (certain parts of)
> their APIs.
>
>
>> How do you suggest we build "a process for change" in light of these
>> facts?
>
> It seems pointless to answer that question in the absence of agreement
> that there is a problem that is worth addressing.
Nice try. Answer it anyway.
>> You claimed in a recent post that you had made suggestions on
>> how to fix things; I don't remember reading anything even remotely
>> like that. Do you disagree that de facto standards are not a
>> reasonable bridge to get Lisp from near-oblivion to some shadow of its
>> former glory?
>
> I think it's important that the standards be codified and that there be
> some mechanism for "officially" marking the transition between "under
> consideration" (or under development) and "adopted." Right now the
> transition is too fuzzy. It makes it too hard to tell whether one can
> rely on a particular feature.
>
>> Also, why have you failed to produce any more than two or three
>> laughably trivial examples to explain why Common Lisp "sucks"?
>
> I don't think that the lack of a standard sockets API is laughably
> trivial.
Hence compatibility layers. You keep all the low-level networking
code together in one file - you should be doing this even if you're
not worried about having to switch to a different socket
implementation. If you decide you need another implementation, you
drop in a new version of that file. Simple.
> I chose a few trivial examples because it's easier to argue the merits
> of trivial examples than complicated ones, and I didn't want to get too
> bogged down in arguing the benefits because that's not the point.
>
> If you want non-trivial examples, there are lots of those too. The MOP
> for example. Or anything listed here:
>
> http://www.cs.cmu.edu/Groups/AI/html/hyperspec/HyperSpec/Issues/Issues-Ca
> tegorized.html
>
> Imagine how out of control the discussion could get if we started
> drilling down into those details here.
>
>> if the
>> productivity gains involved from using Lisp dominate the upfront
>> hassle of making sure a library works on your implementation or of
>> implementing a compatibility layer, is it not better to use Lisp and
>> spend some time gettings things set up?
>
> No, because in addition to the up-front costs, I also have to accept the
> risk that nasty surprises are lurking. For example, suppose I get
> everything up and running and then find that under heavy load my Lisp
> implementation crashes. The developers of my implementation may or may
> not be able to help, and switching to another implementation may or may
> not work. The only data point I have to help me assess the probability
> of this scenario is that it already happened in one very prominent case
> (Reddit). That makes me very leery.
And if you find out CPython can't handle your application, how are you
in a better position?
> If there were e.g. standardized library APIs that would help by making
> it easier to assess how many implementations out there conformed to the
> particular APIs that I was relying on. Looking at the specs to see if
> an implementation conforms (or at least purports to conform) to
> specification X, Y and Z is a lot easier and cheaper than actually
> trying it (especially if in addition to trying it you actually have to
> generate specifications X, Y and Z).
>
>> If you truly do care about
>> installing libraries, why not sit down and write some code to fix it,
>> instead of clogging up comp.lang.lisp with this rubbish?
>
> Because the problem I am talking about cannot be effectively addressed
> merely by writing code. If you think it can then you have not
> understood the problem.
>
> rg
In article <··············@rpi.edu>, Bill Atkins <············@rpi.edu>
wrote:
> Ron Garret <·········@flownet.com> writes:
>
> > In article <··············@rpi.edu>, Bill Atkins <············@rpi.edu>
> > wrote:
> >
> >> Ron Garret <·········@flownet.com> writes:
> >>
> >> > In article <··············@rpi.edu>, Bill Atkins <············@rpi.edu>
> >> > wrote:
> >> >
> >> >> Ron Garret <·········@flownet.com> writes:
> >> >>
> >> >> > In article <··············@rpi.edu>, Bill Atkins
> >> >> > <············@rpi.edu>
> >> >> > wrote:
> >> >> >
> >> >> >> I view this whole situation as somewhat analogous to the state of
> >> >> >> Linux.
> >> >> >
> >> >> > Except that Linux has a process for managing change, which IMO
> >> >> > contributes significantly to its success.
> >> >> >
> >> >> > rg
> >> >>
> >> >> If you are referring to the kernel proper, then yes. But if you are
> >> >> referring to the operating system created by a distro, then there is
> >> >> no central control except the distro's.
> >> >
> >> > Correct. I would say that the kernel plays a role analogous to the
> >> > hyperspec in CL, and the fact that Linux has a process for managing
> >> > change in the kernel contributes to its success.
> >> >
> >> > If Linux were like CL, the kernel design would have been frozen at some
> >> > point in its history. I think it's pretty clear that if that had
> >> > happened Linux would not be nearly as successful as it is today.
> >> >
> >> > rg
> >>
> >> As you're so fond of pointing out, the details are not important here.
> >> But, to clarify, Linux and BSD are both implementations of POSIX as
> >> SBCL, CLISP, Allegro, etc. are implementations of Common Lisp. This
> >> is what's important for understanding my analogy. What you're talking
> >> about would be analogous to SBCL, for example, freezing its features.
> >
> > No. The POSIX standard is analogous to the hyperspec. Linux and BSD,
> > as implementations of Posix, are analogous to, say, SBCL and CLisp.
>
> I don't get it. Isn't that exactly what I just said?
The part I took issue with was: "What you're talking about would be
analogous to SBCL, for example, freezing its features." That certainly
doesn't sound like what I'm after, which is a process for managing
change. "Freezing" anything sounds to me like the exact opposite of
what I want.
Also, because the CL community is much smaller than the posix community
there is a real danger of losing crtical mass if it fragments across
multiple implementations the way posix has.
> > I don't think that the lack of a standard sockets API is laughably
> > trivial.
>
> Hence compatibility layers.
Developing and maintaining them can involve significant effort. That
effort might be more profitably spent elsewhere, like developing new
functionality. CL is not exactly flush with resources as far as I can
tell.
> >> if the
> >> productivity gains involved from using Lisp dominate the upfront
> >> hassle of making sure a library works on your implementation or of
> >> implementing a compatibility layer, is it not better to use Lisp and
> >> spend some time gettings things set up?
> >
> > No, because in addition to the up-front costs, I also have to accept the
> > risk that nasty surprises are lurking. For example, suppose I get
> > everything up and running and then find that under heavy load my Lisp
> > implementation crashes. The developers of my implementation may or may
> > not be able to help, and switching to another implementation may or may
> > not work. The only data point I have to help me assess the probability
> > of this scenario is that it already happened in one very prominent case
> > (Reddit). That makes me very leery.
>
> And if you find out CPython can't handle your application, how are you
> in a better position?
That depends on exactly *how* it can't handle the application.
Different problems have different solutions. If it's too slow, for
example, I might address that by buying more servers. But CPython is
VERY unlikely to give me the kind of nasty surprise that requires me to
give up and try over again (like random crashes). Too many people are
using it for that kind of bug to go unnoticed for long.
Here's another anecdote: while I was still at JPL I whipped up a thing
called SDS (State Database System). It was a pretty standard web app.
Exactly what it did doesn't matter. I wrote it in MCL and used the
included database (called WOOD -- William's Object Oriented Database)
for non-volatile storage. It worked like a charm -- for a while. Then
one day the database was corrupted. I don't know why, and I probably
never will, because I'm pretty sure I am the only person on the planet
who has ever used WOOD for a real application. And I will probably be
the last too (which is unfortunate, because in some ways WOOD was really
cool).
But I will never again entrust important data to anything but MySQL.
rg
Ron Garret <·········@flownet.com> wrote:
+---------------
| But I will never again entrust important data to anything but MySQL.
+---------------
Hmmm... It was precisely the problems I saw people having with MySQL
that caused me to pick PostgreSQL. So far [~4yrs], it seems to have
been the right move.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Ron Garret wrote:
> In article <··············@rpi.edu>, Bill Atkins <············@rpi.edu>
> wrote:
>
>> Hence compatibility layers.
>
> Developing and maintaining them can involve significant effort. That
> effort might be more profitably spent elsewhere, like developing new
> functionality. CL is not exactly flush with resources as far as I can
> tell.
This is not an either/or situation. My work on Closer to MOP (a
compatibility layer for the CLOS MOP) consists, among other things, of
documenting where CL implementations that claim to support the CLOS MOP
deviate from the CLOS MOP specification. This has already made vendors
change their CLOS MOP implementations to better adhere to the
specification, including commercial and open-source vendors.
Another element of this work is that I have, I think, a good idea where
the CLOS MOP specification itself needs work - there are several parts
which are just too loosely specified, consist of ambiguous wording, or
are simply missing elements that would be important in a "finalized"
specification. My hope is that this can lead to an improvement of the
CLOS MOP specification in the long run.
Overall, the goal of the Closer to MOP project is to become obsolete in
the long run.
Other people are working on similar projects for other areas of the
language.
There won't be a noticeable big bang solution here because all these
things need work, and that work is, I believe, necessary. The hard part
is getting the details right, not getting libraries stamped.
(And in order to make things absolutely clear: What I am saying here
does not preclude someone starting to work on some kind of packaged
collection of libraries that are known to work across several CL
implementations, which would address some of the needs you have stated.)
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
Ron Garret <·········@flownet.com> writes:
>
> But I will never again entrust important data to anything but MySQL.
>
OMG - you trust mysql with important data! While mysql isn't too bad
as an extremely basic relational database, I'd be very careful about
assuming it is robust and you won't get currupted data. I've found
mysql does well enough for small data requirements, but for larger
datasets, be careful. I've worked on a number of projects where a big
part of what I've had to do is recover data out of currupted mysql
databases[1].
These days I prefer postgres - in some ways, its not as fast as mysql,
but it does support a wider range of constraints, triggers and stored
procedures, plus it supports a more complete SQL command set. I much
prefer placing as much of the data model into the database rather than
your application as experience has shown me this is more likely to
lead to a more robust model and you can add to the application layer
much faster (and in various languages) without having to ensure you
maintain consistency throughout the application regarding constraints
and relationships etc.
[1] I know that more recent versions of mysql have advanced
significantly and I believe it now supports more constraint types and
nested selects etc. Most of my mysql work was done during the later
half of the 90's up until 2001, so I'm more than willing to accept it
has improved - I just don't know by how much. Has the rather limiting
datafile size limit been increased?
Tim
--
tcross (at) rapttech dot com dot au
In article <··············@tiger.rapttech.com.au>,
Tim X <····@nospam.dev.null> wrote:
> Ron Garret <·········@flownet.com> writes:
>
> >
> > But I will never again entrust important data to anything but MySQL.
> >
>
> OMG - you trust mysql with important data!
Yep. So does Google. (But I keep update logs. So does Google. :-)
> While mysql isn't too bad
> as an extremely basic relational database
What wrong with basic? (Actually, MySQL was "basic" five years ago.
Not any more.)
> These days I prefer postgres
Many people do. I'm not one of them.
> - in some ways, its not as fast as mysql,
> but it does support a wider range of constraints, triggers and stored
> procedures, plus it supports a more complete SQL command set.
I prefer to do my programming in a programming language. To me a
database is just a non-volatile store plus indexing. But that's just me.
rg
Ron Garret <·········@flownet.com> writes:
> I prefer to do my programming in a programming language. To me a
> database is just a non-volatile store plus indexing. But that's just me.
MySQL is only non-volatile if you don't consider lack of referential
integrity to be a form of volatility. You also must prefer to do much
of your programming more than once, since that's what you end up doing
to get any kind of referential integrity without the database
providing it.
Ron Garret <·········@flownet.com> writes:
> In article <··············@tiger.rapttech.com.au>,
> Tim X <····@nospam.dev.null> wrote:
>
> > Ron Garret <·········@flownet.com> writes:
> >
> > >
>
> > - in some ways, its not as fast as mysql,
> > but it does support a wider range of constraints, triggers and stored
> > procedures, plus it supports a more complete SQL command set.
>
> I prefer to do my programming in a programming language. To me a
> database is just a non-volatile store plus indexing. But that's just me.
>
Then you are building your data-model into your app, not the database.
Thats probably but not automatically bad, it means for anything but a
trivial database schema, complex queries are diffused into the app and
very possibly inefficient because the database engine is not exploited
to reduce the workload on the app. It also means that interfacing your
database to another app potentially requires duplication of the database
interface logic in your app.
The aforementioned features of the SQL command set are there for good
technical reasons. If nothing else, they help enforce consistency in
the database which is otherwise left to the app (and its bugs). Not
using them for doctrinal reasons is prematurely limiting efficiency and
robustness.
Gregm
>>>>> "Ron" == Ron Garret <·········@flownet.com> writes:
>> Hence compatibility layers.
Ron> Developing and maintaining them can involve significant effort.
But changing the language also involves signifcant effort. Updating or
writing a spec is only a part of the job. If the implementations do
not take the new spec to heart and change accordingly, nothing is gained.
And much of this discussion also seem to assume that there always a
single given answer. If we were to add regexps to the language, which
system should we pick? Emacs, perl, awk, ed? Personally, I find it
hard to justify picking any one of those on behalf of the entire
community.
------------------------+-----------------------------------------------------
Christian Lynbech | christian ··@ defun #\. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- ·······@hal.com (Michael A. Petonic)
Ron Garret wrote:
> > How do you suggest we build "a process for change" in light of these
> > facts?
>
> It seems pointless to answer that question in the absence of agreement
> that there is a problem that is worth addressing.
I don't think anyone is claiming that there is no problem. The trouble
is that the *solution* adopted by the Unix communitiy - spending an
enormous amount of money on standards work - is not available to the CL
community because its members do not have the enormous amounts of money
needed (tens or hundreds of millions of dollars) to do this.
So you have two options:
1. Live with it, and try and bootstrap standard extensions. Working on
one would be a good start: there are lots of interesting ones, and I'd
suggest picking low-hanging fruit first.
2. Pick an implementation and don't worry, but just rely on its
extensions. This is what I did when I still wrote significant CL - I
used LW and all its extensions, and it all worked fine. This is *just*
the same as picking, say, perl.
--tim
>>>>> "Ron" == Ron Garret <·········@flownet.com> writes:
Ron> First, the Posix community has processes for developing and evolving
Ron> standards beyond Posix (e.g. the standard C library, the C++ template
Ron> library, etc.). The CL community has no analogous process.
I am curious. What is the process for evolving standards beyond POSIX?
I know the GNU project is developing one implementation of the
standard C library and there is obviously processes for getting
enhancements into that, but how would that be any different from
getting enhancements into, say, SBCL?
------------------------+-----------------------------------------------------
Christian Lynbech | christian ··@ defun #\. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- ·······@hal.com (Michael A. Petonic)
>>>>> "Ron" == Ron Garret <·········@flownet.com> writes:
Ron> Correct. I would say that the kernel plays a role analogous to the
Ron> hyperspec in CL, ...
Ah, come on, this is not how it is. The Linux kernel is to a distro
like Debian as the Conses chapter is to Common Lisp. An indispensible
part yes, but not nowhere near all there is to say on the subject.
In fact, the average user spend a lot less time thinking about the
kernel gthan he does thinking about firefox and thunderbird and KDE
or Gnome. It is the apps that matters to most, not the kernel.
Ron> ... and the fact that Linux has a process for managing change in the
Ron> kernel contributes to its success.
By this I suppose you mean that Linus Torvalds basically approves
everything going onto the kernel. And yes, having a single
implementation thingy just as with Java, Perl and Python make many
things easier.
But Common Lisp is no such thing. It was created as a compromise
between a number of existing implementations and this is messy and
difficult to add to, at least if any additions aspires to carry the
same weight as the base.
But I fail to see that Common Lisp is alone in this situation. It is
not that there is no process for improving it; it "merely" involves
restarting the ANSI standardisation process. The barrier for doing
such a thing is however much higher than the currently perceived need,
but this is hardly any different than for a lot of other
multi-vendor/multi-implementation languages such as C or Cobol.
Common Lisp is not perfect, but which language is that?
------------------------+-----------------------------------------------------
Christian Lynbech | christian ··@ defun #\. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- ·······@hal.com (Michael A. Petonic)
Christian Lynbech wrote:
>>>>>>"Ron" == Ron Garret <·········@flownet.com> writes:
>
>
>
> Ron> Correct. I would say that the kernel plays a role analogous to the
> Ron> hyperspec in CL, ...
>
> Ah, come on, this is not how it is. The Linux kernel is to a distro
> like Debian as the Conses chapter is to Common Lisp. An indispensible
> part yes, but not nowhere near all there is to say on the subject.
>
> In fact, the average user spend a lot less time thinking about the
> kernel gthan he does thinking about firefox and thunderbird and KDE
> or Gnome. It is the apps that matters to most, not the kernel.
>
> Ron> ... and the fact that Linux has a process for managing change in the
> Ron> kernel contributes to its success.
>
> By this I suppose you mean that Linus Torvalds basically approves
> everything going onto the kernel. And yes, having a single
> implementation thingy just as with Java, Perl and Python make many
> things easier.
>
> But Common Lisp is no such thing. It was created as a compromise
> between a number of existing implementations and this is messy and
> difficult to add to, at least if any additions aspires to carry the
> same weight as the base.
>
> But I fail to see that Common Lisp is alone in this situation. It is
> not that there is no process for improving it; it "merely" involves
> restarting the ANSI standardisation process. The barrier for doing
> such a thing is however much higher than the currently perceived need,
> but this is hardly any different than for a lot of other
> multi-vendor/multi-implementation languages such as C or Cobol.
Well, those languages at least seem to realize that there are areas of
improvement to be made since they *do* have a process for introducing
change into either the core language or the libraries, however gradual.
Even Ada and Scheme are revising their standards. Some languages don't
do so, but in most cases I can think of, it's due to lack of use.
> Common Lisp is not perfect, but which language is that?
None, but the Lisp community seems to be singular in its almost
religious devotion to the canon.
I have to laugh when in response to some criticism of the current
standard, a CL-er says, "But all you have to do is write a page of code
like this: (insert handwaving) and, voila, problem mostly solved!" Cut
to earlier scene, some of the same people criticizing Scheme for it's
tiny standard (and many non-standard extensions to do commmon things)
and laughing at Schemers who say, "But all you have to do is write a
page of code like this: (insert handwaving) and, voila, problem mostly
solved!" And the irony is completely lost on some of them.
--Larry
Larry Elmore wrote:
>
>> Common Lisp is not perfect, but which language is that?
>
> None, but the Lisp community seems to be singular in its almost
> religious devotion to the canon.
>
So you are faulting someone for saying the truth.
Do you have a superior perspective?
Pray Tell, What Is It?
Wade
Wade Humeniuk wrote:
> Larry Elmore wrote:
>
>>
>>> Common Lisp is not perfect, but which language is that?
>>
>>
>> None, but the Lisp community seems to be singular in its almost
>> religious devotion to the canon.
>>
>
> So you are faulting someone for saying the truth.
> Do you have a superior perspective?
> Pray Tell, What Is It?
You're not making any sense. Try again.
--Larry
Larry Elmore wrote:
>> So you are faulting someone for saying the truth.
>> Do you have a superior perspective?
>> Pray Tell, What Is It?
>
> You're not making any sense. Try again.
>
Sure, to mix threads together,
CL-USER 20 > (scramble-text "So you are faulting someone for saying the truth.
Do you have a superior perspective?
Pray Tell, What Is It?
Wade")
"So you are faniultg smoonee for syiang the ttruh.
Do you hvae a spuireor pesprivtece?
Pary Tell, Waht Is It?
Wade"
CL-USER 21 >
Wade Humeniuk wrote:
> Larry Elmore wrote:
>
>>> So you are faulting someone for saying the truth.
>>> Do you have a superior perspective?
>>> Pray Tell, What Is It?
>>
>>
>> You're not making any sense. Try again.
>>
>
> Sure, to mix threads together,
>
> CL-USER 20 > (scramble-text "So you are faulting someone for saying the
> truth.
> Do you have a superior perspective?
> Pray Tell, What Is It?
>
> Wade")
> "So you are faniultg smoonee for syiang the ttruh.
> Do you hvae a spuireor pesprivtece?
> Pary Tell, Waht Is It?
>
> Wade"
>
> CL-USER 21 >
nuisee ahhrkkimennt. phueic aaehph.
>>>>> "Larry" == Larry Elmore <·········@comcast.net> writes:
>> But I fail to see that Common Lisp is alone in this situation. It is
>> not that there is no process for improving it; it "merely" involves
>> restarting the ANSI standardisation process. The barrier for doing
>> such a thing is however much higher than the currently perceived need,
>> but this is hardly any different than for a lot of other
>> multi-vendor/multi-implementation languages such as C or Cobol.
Larry> Well, those languages at least seem to realize that there are areas of
Larry> improvement to be made since they *do* have a process for introducing
Larry> change into either the core language or the libraries, however gradual.
Ehh, just what is the process for introducing changes to C or Cobol?
As far as can remember, there has only something like one update to
the C standard. Cobol has gone through a handful of revisions I
believe.
But isn't all that done in the context of standards comittees?
What prevents Common Lisp from doing the same? Nothing!
Certainly, despite the constant raving here, nobody among the vendors
has found a positive business case in starting a new standardization
process but couldn't that not just as well be because the existing
standard is good enough? (In relation to the pains and costs of
evolving the standard, that is.)
------------------------+-----------------------------------------------------
Christian Lynbech | christian ··@ defun #\. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- ·······@hal.com (Michael A. Petonic)
Christian Lynbech wrote:
>>>>>>"Larry" == Larry Elmore <·········@comcast.net> writes:
>
>
>>>But I fail to see that Common Lisp is alone in this situation. It is
>>>not that there is no process for improving it; it "merely" involves
>>>restarting the ANSI standardisation process. The barrier for doing
>>>such a thing is however much higher than the currently perceived need,
>>>but this is hardly any different than for a lot of other
>>>multi-vendor/multi-implementation languages such as C or Cobol.
>
>
> Larry> Well, those languages at least seem to realize that there are areas of
> Larry> improvement to be made since they *do* have a process for introducing
> Larry> change into either the core language or the libraries, however gradual.
>
> Ehh, just what is the process for introducing changes to C or Cobol?
>
> As far as can remember, there has only something like one update to
> the C standard. Cobol has gone through a handful of revisions I
> believe.
No one's saying it something that should be done every 5 years. But if
you go to http://www.open-std.org/jtc1/sc22/wg14/, you'll see that the
process for C didn't just die with the release of C99. Nor has C++.
> But isn't all that done in the context of standards comittees?
> What prevents Common Lisp from doing the same? Nothing!
>
> Certainly, despite the constant raving here, nobody among the vendors
> has found a positive business case in starting a new standardization
> process but couldn't that not just as well be because the existing
> standard is good enough? (In relation to the pains and costs of
> evolving the standard, that is.)
That may very well be. On the other hand, if I had a lot invested in a
particular way of doing things, *I* might not want the standards process
restarted again because the necessary changes to my product might cost
me more than the perceived possible gain for me, and that may or may not
have anything to do with whether the community as a whole might benefit.
The only thing I've seen here lately that comes close to "raving" is
some people's reaction to the idea that CL, like some holy books I might
mention, might not have been as close to perfection as humans can get
back when it was standardized. Which seems silly considering the
political process of standardization, and the weight of historical
baggage that the process started with. Given the intensity of feeling
by some to change nothing at all, any new process would probably be
doomed to failure anyway.
--Larry
>>>>> "Larry" == Larry Elmore <·········@comcast.net> writes:
Larry> No one's saying it something that should be done every 5 years. But if
Larry> you go to http://www.open-std.org/jtc1/sc22/wg14/, you'll see that the
Larry> process for C didn't just die with the release of C99. Nor has C++.
But I fail to see how Common Lisp is formally in any different. I
believe there is a standard committe with a chair and all. So nothing
formally prevents CL standardisation from goign forward.
That there is a lack of personel and funding is another matter. The
Common Lisp community, and the market it addresses, is not very
big. It is likely that the various vendors and projects will feel
compelled to change just because a group within the community feel
they should?
I for one do not recall ever having said that Common Lisp is perfect
or beyond modification, but I can easily see that standardisation in
the areas that CL is lacking involves a number of really really tough
issues and I see no indications that those in charge of the various
implementartions feel a dire need to invest in such a huge project.
But if you or anybody else feels that such an undertaking is easy or
fun or a fundamental necessity, by all means go ahead and work on
it.
I personally do not see the major problem, at least not when comparing
to the size of the task. Yes, it is mildly embarrassing that there is
no CL standard for stuff like multiprocessing or FFI, but it is not
keeping me from sleeping at night.
------------------------+-----------------------------------------------------
Christian Lynbech | christian ··@ defun #\. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- ·······@hal.com (Michael A. Petonic)
Christian Lynbech <·········@defun.dk> writes:
>
> Certainly, despite the constant raving here, nobody among the vendors
> has found a positive business case in starting a new standardization
> process but couldn't that not just as well be because the existing
> standard is good enough? (In relation to the pains and costs of
> evolving the standard, that is.)
Is standardisation _ever_ a good thing for vendors? It means that their
customers can more easily shift to another vendor, after all (and, to be
fair, that customers can shift to them as well--but then the
implementations are just commodities). Standards serve language users
more than language vendors, methinks. Seen from that angle, it's not
surprising that Common Lisp hasn't evolved--relatively few users.
And it's not surprising that a lot more folks seem to be pushing for
change now: more users, who would very much like for implementations to
be much more interchangeable. This is probably a good thing.
--
Robert Uhl <http://public.xdi.org/=ruhl>
Give a man a fish and you feed him for a day; give him a freshly-charged
Electric Eel and chances are he won't bother you for anything ever again.
--Tanuki in asr
>>>>> "Robert" == Robert Uhl <·········@NOSPAMgmail.com> writes:
Robert> Christian Lynbech <·········@defun.dk> writes:
>>
>> Certainly, despite the constant raving here, nobody among the vendors
>> has found a positive business case in starting a new standardization
>> process but couldn't that not just as well be because the existing
>> standard is good enough? (In relation to the pains and costs of
>> evolving the standard, that is.)
Robert> Is standardisation _ever_ a good thing for vendors?
Probably not directly. A new standard means new ways of doing things
which again means things to change or add for the vendor.
But this does not mean that vendors never feel a need to enter a
standardisation process. There can be a widely perceived need, whether
true or false, for alignment and if standardisation seems inevitable
(or rather the cost of not doing it outweighs the cost of doing it)
vendors probably will flock to the process in order to drive
standardisation in their direction to minimize the amount of change
they need.
In fact, as I remember it, this was exactly the case with the Common
Lisp standardisation effort. It was not out of great love of the idea
but rather a feeling of necessity in order to be attrative to the big
players in the emerging AI boom that brought enough critical mass to
the initial process. Once critical mass is ensured, the rest of the
vendors will logically need to follow.
It is actually a bit funny to think that if the Common Lisp effort had
NOT happened, we most likely would not have this recurring discussion
about new versions of the standard. Instead we would (most likely)
have a set of distinct lisp dialects (interlisp, maclisp, Franz Lisp,
Zeta lisp etc) and *within* each camp, differences between individual
implementations (to the extent they existed) would drown in the
differences *between* camps.
At the present time, the entire lisp market is, I think, simply too
small to be able to support a positive business case for the vendors
to enter into such an expensive undertaking. While it may be nice for
the users to have alignment, it is not easy to see how that would
increase in any significant way the lisp business for any particular
vendor.
------------------------+-----------------------------------------------------
Christian Lynbech | christian ··@ defun #\. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- ·······@hal.com (Michael A. Petonic)
Robert Uhl <·········@NOSPAMgmail.com> writes:
> Is standardisation _ever_ a good thing for vendors? It means that their
> customers can more easily shift to another vendor, after all (and, to be
> fair, that customers can shift to them as well--but then the
> implementations are just commodities). Standards serve language users
> more than language vendors, methinks. Seen from that angle, it's not
> surprising that Common Lisp hasn't evolved--relatively few users.
For the vendors, the point of standardization is to expand the market.
Good for large vendors, who have the capacity to produce. Small vendors
participate to get info to adjust timely to the market change.
The standardization of telefax is a good example. Standardization of
railways also had the market-expanding effect.
It is not obvious that further standardization of CL will do the same
thing now.
Larry Elmore <·········@comcast.net> writes:
> Well, those languages at least seem to realize that there are areas of
> improvement to be made since they *do* have a process for introducing
> change into either the core language or the libraries, however gradual.
The process of improvement of C, AFAISI, involves independant
individual creating Objective-C or C++. Later, some of these improved
features are retrofited into a new version of C.
We have:
- Lush,
- newLISP,
- Arc (vaporware),
- what else?
- anybody can write his own improvement.
I'm sure a new round of standardization will happen, later, when we'll
be ready for a new concensus...
> [...]
> I have to laugh when in response to some criticism of the current
> standard, a CL-er says, "But all you have to do is write a page of code
> like this: (insert handwaving) and, voila, problem mostly solved!" Cut
> to earlier scene, some of the same people criticizing Scheme for it's
> tiny standard (and many non-standard extensions to do commmon things)
> and laughing at Schemers who say, "But all you have to do is write a
> page of code like this: (insert handwaving) and, voila, problem mostly
> solved!" And the irony is completely lost on some of them.
>
> --Larry
--
__Pascal Bourguignon__ http://www.informatimago.com/
IMPORTANT NOTICE TO PURCHASERS: The entire physical universe,
including this product, may one day collapse back into an
infinitesimally small space. Should another universe subsequently
re-emerge, the existence of this product in that universe cannot be
guaranteed.
Pascal Bourguignon wrote:
> Larry Elmore <·········@comcast.net> writes:
>
>>Well, those languages at least seem to realize that there are areas of
>>improvement to be made since they *do* have a process for introducing
>>change into either the core language or the libraries, however gradual.
>
>
> The process of improvement of C, AFAISI, involves independant
> individual creating Objective-C or C++. Later, some of these improved
> features are retrofited into a new version of C.
>
> We have:
> - Lush,
> - newLISP,
> - Arc (vaporware),
> - what else?
> - anybody can write his own improvement.
>
> I'm sure a new round of standardization will happen, later, when we'll
> be ready for a new concensus...
Okay, yeah, no doubt. It's just very striking to me the visceral
response of some people to the suggestion that CL might need any changes
at all.
--Larry
Larry Elmore <·········@comcast.net> writes:
> Pascal Bourguignon wrote:
>> Larry Elmore <·········@comcast.net> writes:
>>
>>>Well, those languages at least seem to realize that there are areas of
>>>improvement to be made since they *do* have a process for introducing
>>>change into either the core language or the libraries, however gradual.
>>
>>
>> The process of improvement of C, AFAISI, involves independant
>> individual creating Objective-C or C++. Later, some of these improved
>> features are retrofited into a new version of C.
>>
>> We have:
>> - Lush,
>> - newLISP,
>> - Arc (vaporware),
>> - what else?
>> - anybody can write his own improvement.
>>
>> I'm sure a new round of standardization will happen, later, when we'll
>> be ready for a new concensus...
>
> Okay, yeah, no doubt. It's just very striking to me the visceral
> response of some people to the suggestion that CL might need any changes
> at all.
I don't have any problem with people pointing out that CL might need
changes. It is annoying, though, when claims are made that Lisp
"sucks" or is "unusable" because the standard has no official
mechanism for change. The implication that the community is somehow
at fault for not solving a very, very difficult problem on its own
also rankles.
Bill Atkins wrote:
> Larry Elmore <·········@comcast.net> writes:
>
>
>>Pascal Bourguignon wrote:
>>
>>>Larry Elmore <·········@comcast.net> writes:
>>>
>>>
>>>>Well, those languages at least seem to realize that there are areas of
>>>>improvement to be made since they *do* have a process for introducing
>>>>change into either the core language or the libraries, however gradual.
>>>
>>>
>>>The process of improvement of C, AFAISI, involves independant
>>>individual creating Objective-C or C++. Later, some of these improved
>>>features are retrofited into a new version of C.
>>>
>>>We have:
>>>- Lush,
>>>- newLISP,
>>>- Arc (vaporware),
>>>- what else?
>>>- anybody can write his own improvement.
>>>
>>>I'm sure a new round of standardization will happen, later, when we'll
>>>be ready for a new concensus...
>>
>>Okay, yeah, no doubt. It's just very striking to me the visceral
>>response of some people to the suggestion that CL might need any changes
>>at all.
>
>
> I don't have any problem with people pointing out that CL might need
> changes. It is annoying, though, when claims are made that Lisp
> "sucks" or is "unusable" because the standard has no official
> mechanism for change. The implication that the community is somehow
> at fault for not solving a very, very difficult problem on its own
> also rankles.
Well, the blog entry that started the current debate certainly rankled.
I thought Ron's suggestions, and even the title of this thread, have
nothing to do with "CL (as a whole) sucks," but that "Some things about
CL suck, we should fix them." Lord knows, one could submit a list of
things that suck about any other language out there, most especially the
other Lispy languages like Scheme, and get loud choruses of agreement.
Is CL *really* that much better than anything else out there that it
doesn't suck in any way at all?
> The implication that the community is somehow
> at fault for not solving a very, very difficult problem on its own
> also rankles.
Not to be rude, but who else is supposed to do it? While a lot of
people don't seem to think there's any problem at all, let alone a
difficult one, a vocal group seems to think that anybody suggesting that
there may be a problem is to be shouted down. That may be the right
thing sometimes, but the reaction here just seems a bit severe to me.
Too much like the Forth religious wars.
--Larry
In article <··············@rpi.edu>, Bill Atkins <············@rpi.edu>
wrote:
> It is annoying, though, when claims are made that Lisp
> "sucks" or is "unusable" because the standard has no official
> mechanism for change.
OK, I take it back. Common Lisp doesn't suck. But aspects of the
language (both core and libraries) could be improved.
> The implication that the community is somehow
> at fault for not solving a very, very difficult problem on its own
> also rankles.
I don't fault the community for not solving this problem. I do believe
that a significant portion of the community doesn't believe it is a
problem. That is the major source of disagreement.
rg
Ron Garret wrote:
> In article <··············@rpi.edu>, Bill Atkins <············@rpi.edu>
> wrote:
>
>> It is annoying, though, when claims are made that Lisp
>> "sucks" or is "unusable" because the standard has no official
>> mechanism for change.
>
> OK, I take it back. Common Lisp doesn't suck. But aspects of the
> language (both core and libraries) could be improved.
Of course it is the case that these aspects can be improved.
>> The implication that the community is somehow
>> at fault for not solving a very, very difficult problem on its own
>> also rankles.
>
> I don't fault the community for not solving this problem. I do believe
> that a significant portion of the community doesn't believe it is a
> problem. That is the major source of disagreement.
No, I think the major source of disagreement is the approach that should
be taken to trigger improvements.
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
Bill Atkins <············@rpi.edu> writes:
> 15-year-old languages have built. I think what we actually have is
> tremendously impressive - three open-source native-compiling Lisp
> implementations, McCLIM, UncommonWeb, Climacs, Cliki, Araneida, CLSQL,
> SLIME. This is a lot of good software for a tiny and relatively
> newish community.
I forgot ASDF, asdf-install, cl-ppcre, and YACLML (and probably some
more too).
--
"...and when, another time, I discovered that he considered not
unworthy of reflection in one of those mirrors of absolute truth which
were his writings a remark similar to one which I had had occasion to
make about our friend M. Legrandin, ...then it was suddenly revealed
to me that my own humble existence and the realms of the true were
less widely separated than I had supposed, that at certain points they
actually collided, and in my newfound confidence and joy, I had wept
upon his printed page as in the arms of a long-lost father."
Ron Garret wrote:
> Two things to get out of the way at the outset:
>
> 1. Note that the title of this post is *HOW* CL sucks, not *WHY* it
> sucks. The difference is significant. Please take the time to
> understand it before you flame me.
I think I've understood you, after reading a fair number (though not
all, by any means) of the responses to your post, and your responses to
them. Can I flame you now ;)?
I don't entirely disagree with the points you make- the things you
bring up here, and in follow-ups, are clearly obstacles to CL being
adopted in a Perl-like (or Python-like, or Ruby-like, or VB-like)
fashion. If they were solved, would CL then be adopted as these other
languages are (though I have reservations when it comes to Python and
Ruby, in this respect- there are far more enthusiasts of these
languages than there are jobs that require them as primary programming
languages- and I do, in fact, administer a Zope based site- bit of a
nightmare, really)?
I don't think so. If you are waiting for CL to become the scripting
language du jour, I think you had better pack a lunch- that, or call
ahead to Godot catering; they are notoriously slow, but the deliveryman
will arrive before CL becomes Perl. I don't think that your points,
some of which are valid, are the bottleneck when it comes to CL
adoption. If you eliminated every single one of the problems you cite,
CL would... still not become popular, aside from cites by Slashdot
poseurs who couldn't write "Hello World" in CL if John McCarthy bit
them on the ass.
> 2. I'm not going to say anything I haven't said a thousand times
> before, so those of you who know me (that means you, Kenny) will not
> find anything new here so you may as well not even bother.
Honestly (and, despite my tone, I don't actually mean to flame you), I
would have heard this a thousand times already _even if I had never
read any of your posts_. That you post this is evidence that it is
still necessary to bother. In some cases I agree more with you than
with those who bother, but I think your main thrust is misguided- more
below.
> I am writing this because of the debate surrounding Steve Yegge's recent
> blog entries on Lisp.
I've read just one of these, in order to know what you are talking
about....
> It is unfortunate that he made so many technical
> mistakes in his posts
The post I read is at:
http://steve-yegge.blogspot.com/2006/04/lisp-is-not-acceptable-lisp.html
Again, I could have summarized it without having read it, just as I can
relate the substance of the average bodice ripper to you without having
to actually read about the sultry night, or the details of the rended
undergarments. This sort of Lisp journalism should be recognized as a
genre at this point, awards handed out at each equinox- I favor "The
Frilly" as the name of the statue awarded.
The problems with this post are not primarily technical points:
"Macros are one of the worst problems with Lisp, or at least they're
one of the biggest unsolved problems."
Really? You don't actually have to write macros... in fact, I was
introduced to both Scheme and CL at University, in a decent CS program,
and macros were never explicitly introduced. I still liked both
languages.
"Yes, they're amazingly powerful and critically important and blah Blah
BLAH"
Now I'm convinced that macros are EVIL! The escalation from blah to
Blah to BLAH is hard to argue with.
"But they're fraught with problems. One is that they're not hygienic."
Really? Why? If you want to implement hygienic macros in CL, go ahead.
If you want them built-in there are a number of Schemes available. I
wonder if the author understands the difference between a Lisp-1 and a
Lisp-2, and why the distinction matters. If the author had actually
offered a critique of "real" macros ( ;), sorry schemers), I would
know.... but he just tells us that they are "fraught with problems".
Does that mean "I got stuck on chapter 10 of OnLisp, right about where
gensyms were introduced"? The whole article is like that. "Math is
hard" is not a good argument against the various calculi.
> because they distract people from the fact that
> underneath all the errors he is actually making a valid point, that
> being that CL has very significant problems that are barriers to its
> adoption. (Some people think this is a feature, that having a few
> obstacles to overcome keeps out the rif raf. I suppose this is a
> defensible position, but I don't subscribe to it.)
It's not so much that I like the fact that Lisp keeps out the
riff-raff. It's that it offers advantages to some programmers that are
not available to all programmers. I would welcome a single free easy to
use default cross-platform implementation with lots of useable
libraries that required no background to get started with, frankly. I
wouldn't welcome it enough for it to be worth it to me to build it, as
I see no commercial future in it, and I am a bit busy writing CL code,
along with code in almost every other language lately presented as a
panacea, for an ongoing enterprise that pays my salary.
I will say that CL has one great advantage when it comes to hiring... I
have to hire people occasionally, and their resumes sometimes include
some Lisp. I think they put it on there because they are sure that they
won't be challenged on it. A surprising number of people with Lisp or
Scheme on the resume do not know _the first thing_ about either. I'm
afraid that some of these folks have taken CS classes that were taught
in these languages, and all they remember is parentheses....
> I'm going to point out just three problems with CL. There are more.
> None of these are original observations.
Your first points can be simply addressed: pick an implementation,
based on what you need, and pay for it if necessary. You will always be
wishing for features in another implementation, but that is just 'cause
the other implementations exist. You don't wish for features in a
different Python (Perl, Ruby) because there isn't really a different
Python (and yes, I know all about stackless, and Jython, etc.).
> 3. I do not hate Lisp. It is and has always been my favorite
> programming languages. My love for Lisp pretty much destroyed my career
> as a programmer.
Nonsense. There are a lot of startups in the world- attach yourself to
one as lead programmer. Once you have a position of authority use CL,
if you think it is the best language for the job, but make sure to
follow through. It's not polite to talk about salary, but I think I do
substantially better than most programmers, even with the handicap of
preferring CL to Python.
> My motivation for criticising Lisp is not to convince
> people not to use it. It is to effect changes that I believe are
> necessary to get more people to use it. To quote Paul Graham, "It's not
> Lisp that sucks, it's Common Lisp that sucks."
I breathlessly await ARC.
> And actually, I would
> soften that somewhat: it's not Common Lisp that sucks, it's some parts
> of Common Lisp that suck. But make no mistake, some parts of Common
> Lisp really do suck, and unless they are fixed a lot of people -- myself
> included -- won't be able to use it even though they may want to really
> badly.
I actually agree with you here, but I agree with you as a _professional
CL programmer_. I haven't been programming in Lisp for 20 years- maybe
10 ;). I also program, professionally, in a number of different
languages, as I have to manage a few different systems... but I am
converting most of them to CL- I find that CL's disadvantages are
smaller, for me, than the disadvantages of most other languages.
I won't argue against anything anyone does to make the language I use
better, or easier to use, but... the argument you are making is old,
and Yegge's article is hard to take seriously.
CL will _never_ be adopted as a popular language among the bulk of
people who now use Perl and Python and Ruby. They suffered enough
learning to put one statement after another, and they will react badly
to any attempt to explain that that is not the only way to program, as
learning another would entail further suffering. PHP is popular for a
reason. That PHP is popular is not a good criticism of CL.
In article <························@e56g2000cwe.googlegroups.com>,
"Tagore Smith" <······@tagoresmith.com> wrote:
> Ron Garret wrote:
> > Two things to get out of the way at the outset:
> >
> > 1. Note that the title of this post is *HOW* CL sucks, not *WHY* it
> > sucks. The difference is significant. Please take the time to
> > understand it before you flame me.
>
> I think I've understood you, after reading a fair number (though not
> all, by any means) of the responses to your post, and your responses to
> them. Can I flame you now ;)?
Sure, why should you be the only one missing out on all the fun?
> I don't entirely disagree with the points you make- the things you
> bring up here, and in follow-ups, are clearly obstacles to CL being
> adopted in a Perl-like (or Python-like, or Ruby-like, or VB-like)
> fashion. If they were solved, would CL then be adopted as these other
> languages are (though I have reservations when it comes to Python and
> Ruby, in this respect- there are far more enthusiasts of these
> languages than there are jobs that require them as primary programming
> languages- and I do, in fact, administer a Zope based site- bit of a
> nightmare, really)?
>
> I don't think so.
How can you possibly know without trying? Besides, you're asking the
wrong question. The proper question is not: would CL be as popular as
Perl/Python/Ruby/whatever if we did X, Y and Z. The proper question is,
would CL become more popular as a result of X, Y, and Z? (I think it
would.) And would this be a good thing? (I think it would.) And would
the benefit be worth the cost? On that last one I am having grave
doubts.
> If you are waiting for CL to become the scripting
> language du jour,
I am not.
[I'm snipping out a lot of stuff based on similar false premises.]
> The problems with this post are not primarily technical points:
>
> "Macros are one of the worst problems with Lisp, or at least they're
> one of the biggest unsolved problems."
>
> Really? You don't actually have to write macros...
If you don't write macros, how does Lisp win? What is the point of all
the parentheses?
> > because they distract people from the fact that
> > underneath all the errors he is actually making a valid point, that
> > being that CL has very significant problems that are barriers to its
> > adoption. (Some people think this is a feature, that having a few
> > obstacles to overcome keeps out the rif raf. I suppose this is a
> > defensible position, but I don't subscribe to it.)
>
> It's not so much that I like the fact that Lisp keeps out the
> riff-raff. It's that it offers advantages to some programmers that are
> not available to all programmers.
The same can be said for C++.
> > 3. I do not hate Lisp. It is and has always been my favorite
> > programming languages. My love for Lisp pretty much destroyed my career
> > as a programmer.
>
> Nonsense. There are a lot of startups in the world- attach yourself to
> one as lead programmer. Once you have a position of authority use CL,
> if you think it is the best language for the job, but make sure to
> follow through. It's not polite to talk about salary, but I think I do
> substantially better than most programmers, even with the handicap of
> preferring CL to Python.
You are missing something very fundamental here: I AM in a position of
authority. And from that point of view, CL is NOT the best language to
use. I wish it were, but it isn't.
rg
Ron Garret wrote:
> In article <························@e56g2000cwe.googlegroups.com>,
> "Tagore Smith" <······@tagoresmith.com> wrote:
>
> > Ron Garret wrote:
> > > Two things to get out of the way at the outset:
> > >
> > > 1. Note that the title of this post is *HOW* CL sucks, not *WHY* it
> > > sucks. The difference is significant. Please take the time to
> > > understand it before you flame me.
> >
> > I think I've understood you, after reading a fair number (though not
> > all, by any means) of the responses to your post, and your responses to
> > them. Can I flame you now ;)?
>
> Sure, why should you be the only one missing out on all the fun?
Well, I think you've been a bit mishandled- your points are not
inconsequential, and you shouldn't be treated as if you were a troll.
The problem is that a lot of trolls make exactly the points that you
make.
> > I don't entirely disagree with the points you make- ...
> > I don't think so.
> How can you possibly know without trying?
> Besides, you're asking the
> wrong question. The proper question is not: would CL be as popular as
> Perl/Python/Ruby/whatever if we did X, Y and Z. The proper question is,
> would CL become more popular as a result of X, Y, and Z? (I think it
> would.)
Actually, I agree with you here, if you are willing to admit that that
will still leave Lisp a very marginal language, popularity-wise. I
think that a lot of great work has been done in the last few years, and
CL is more usable now than it was a few years ago. I'm grateful to the
people who have done the bulk of the work.
>And would this be a good thing? (I think it would.) And would
> the benefit be worth the cost? On that last one I am having grave
> doubts.
What benefit? What cost?
> > If you are waiting for CL to become the scripting
> > language du jour,
>
> I am not.
>
> [I'm snipping out a lot of stuff based on similar false premises.]
You agree that CL is not likely to become the scripting language du
jour, and then snip similar statements because they are false? At the
least, you should explain.
> > The problems with this post are not primarily technical points:
> >
> > "Macros are one of the worst problems with Lisp, or at least they're
> > one of the biggest unsolved problems."
> >
> > Really? You don't actually have to write macros...
>
> If you don't write macros, how does Lisp win? What is the point of all
> the parentheses?
Look at SICP sometime (and yes, I know you are familiar with it- the
reference is rhetorical). Not a lot of macros. I had decided that I
preferred Lisp, and Scheme, to the popular imperative languages well
before I learned much about Lisp macros.
I happen to think that CL's macros are one of the great strengths of
the language, but I don't think it's worth explaining why to someone
who cavalierly states that "Macros are one of the worst problems with
Lisp, or at least they're one of the biggest unsolved problems.". Some
things aren't worth arguing about- you either get it, or you refuse to.
I note that you snipped my query about lisp-1 versus Lisp-2 and
hygiene. That was not inconsequential.
> > > because they distract people from the fact that
> > > underneath all the errors he is actually making a valid point, that
> > > being that CL has very significant problems that are barriers to its
> > > adoption. (Some people think this is a feature, that having a few
> > > obstacles to overcome keeps out the rif raf. I suppose this is a
> > > defensible position, but I don't subscribe to it.)
> >
> > It's not so much that I like the fact that Lisp keeps out the
> > riff-raff. It's that it offers advantages to some programmers that are
> > not available to all programmers.
>
> The same can be said for C++.
I'll agree with that, with a qualification. The best C++ progreammers
can do amazing things with C++, but only by torturing the language out
of all recognition. I'm working from purely anecdotal evidence here,
but I think that a good CL programmer can run rings around a _great_
C++ programmer, productivity wise.
> > > 3. I do not hate Lisp. It is and has always been my favorite
> > > programming languages. My love for Lisp pretty much destroyed my career
> > > as a programmer.
> >
> > Nonsense. There are a lot of startups in the world- attach yourself to
> > one as lead programmer. Once you have a position of authority use CL,
> > if you think it is the best language for the job, but make sure to
> > follow through. It's not polite to talk about salary, but I think I do
> > substantially better than most programmers, even with the handicap of
> > preferring CL to Python.
>
> You are missing something very fundamental here: I AM in a position of
> authority. And from that point of view, CL is NOT the best language to
> use. I wish it were, but it isn't.
OK, but you made a very strong claim- that your career is ruined- and
you blamed it on Lisp. I'm willing to believe you when you say that CL
is not the best language to use for some things you do- I am also in a
position of authority, and I have a fiduciary responsibility to
shareholders in my company. In some cases I have decided to use CL, as
it is the best option, in my opinion. In some cases I have decided not
to. As much as I like CL, I don't consider my career ruined if I have
to program in another language sometimes. If I disliked the programming
that I do now enough to think that my career were ruined, I would seek
another job.
I think that the current state of CL is not as good as it could be, in
an ideal world. I could say the same about lots of other things,
political and otherwise. I don't mean to be disrespectful- I'm sure
that you are a very good, and very experienced programmer. But to me,
it seems that you are mostly venting frustration, rather than making
serious, constructive criticisms.
In article <·······················@i40g2000cwc.googlegroups.com>,
"Tagore Smith" <······@tagoresmith.com> wrote:
> Ron Garret wrote:
> > In article <························@e56g2000cwe.googlegroups.com>,
> > "Tagore Smith" <······@tagoresmith.com> wrote:
> >
> > > Ron Garret wrote:
> > > > Two things to get out of the way at the outset:
> > > >
> > > > 1. Note that the title of this post is *HOW* CL sucks, not *WHY* it
> > > > sucks. The difference is significant. Please take the time to
> > > > understand it before you flame me.
> > >
> > > I think I've understood you, after reading a fair number (though not
> > > all, by any means) of the responses to your post, and your responses to
> > > them. Can I flame you now ;)?
> >
> > Sure, why should you be the only one missing out on all the fun?
>
> Well, I think you've been a bit mishandled- your points are not
> inconsequential, and you shouldn't be treated as if you were a troll.
> The problem is that a lot of trolls make exactly the points that you
> make.
Just because someone is a troll doesn't necessarily mean they are wrong.
> > Besides, you're asking the
> > wrong question. The proper question is not: would CL be as popular as
> > Perl/Python/Ruby/whatever if we did X, Y and Z. The proper question is,
> > would CL become more popular as a result of X, Y, and Z? (I think it
> > would.)
>
> Actually, I agree with you here, if you are willing to admit that that
> will still leave Lisp a very marginal language, popularity-wise.
That depends on the magnitude of the changes. If all we do is deprecate
nth then I agree that will not have a major impact.
> I think that a lot of great work has been done in the last few years, and
> CL is more usable now than it was a few years ago. I'm grateful to the
> people who have done the bulk of the work.
Likewise. But as far as I can tell, no one is making any money yet as a
result of all this work.
> >And would this be a good thing? (I think it would.) And would
> > the benefit be worth the cost? On that last one I am having grave
> > doubts.
>
> What benefit? What cost?
Time mainly. If it's this much work just trying to convince people
there's a problem imagine how much work it will be to actually fix it.
> > > If you are waiting for CL to become the scripting
> > > language du jour,
> >
> > I am not.
> >
> > [I'm snipping out a lot of stuff based on similar false premises.]
>
> You agree that CL is not likely to become the scripting language du
> jour
No, I do not agree with that. I said I am not *waiting* for it.
> and then snip similar statements because they are false? At the
> least, you should explain.
Sorry, I don't have time for that right now. Go back and read what I've
already written more carefully.
> > > The problems with this post are not primarily technical points:
> > >
> > > "Macros are one of the worst problems with Lisp, or at least they're
> > > one of the biggest unsolved problems."
> > >
> > > Really? You don't actually have to write macros...
> >
> > If you don't write macros, how does Lisp win? What is the point of all
> > the parentheses?
>
> Look at SICP sometime (and yes, I know you are familiar with it- the
> reference is rhetorical). Not a lot of macros. I had decided that I
> preferred Lisp, and Scheme, to the popular imperative languages well
> before I learned much about Lisp macros.
I don't think you are typical.
> I happen to think that CL's macros are one of the great strengths of
> the language, but I don't think it's worth explaining why to someone
> who cavalierly states that "Macros are one of the worst problems with
> Lisp, or at least they're one of the biggest unsolved problems."
That is, I think, an attitude typical of the CL community, and one of
the fundamental disagreements I have with you/them. They/you say, "If
someone doesn't understand X it's their problem." I say, if enough
people don't understand X (and I think by now it's pretty clear that
there is a very large population out there that doesn't Get It) then
it's our problem. It might not be our *fault*, but it's our problem.
> > > > because they distract people from the fact that
> > > > underneath all the errors he is actually making a valid point, that
> > > > being that CL has very significant problems that are barriers to its
> > > > adoption. (Some people think this is a feature, that having a few
> > > > obstacles to overcome keeps out the rif raf. I suppose this is a
> > > > defensible position, but I don't subscribe to it.)
> > >
> > > It's not so much that I like the fact that Lisp keeps out the
> > > riff-raff. It's that it offers advantages to some programmers that are
> > > not available to all programmers.
> >
> > The same can be said for C++.
>
> I'll agree with that, with a qualification. The best C++ progreammers
> can do amazing things with C++, but only by torturing the language out
> of all recognition.
So?
> I'm working from purely anecdotal evidence here,
> but I think that a good CL programmer can run rings around a _great_
> C++ programmer, productivity wise.
If that were true (and I agree that it is), then it should be possible
to use Lisp to compete successfully against C++ and make tons of money.
Why are so few people doing that?
> > > > 3. I do not hate Lisp. It is and has always been my favorite
> > > > programming languages. My love for Lisp pretty much destroyed my career
> > > > as a programmer.
> > >
> > > Nonsense. There are a lot of startups in the world- attach yourself to
> > > one as lead programmer. Once you have a position of authority use CL,
> > > if you think it is the best language for the job, but make sure to
> > > follow through. It's not polite to talk about salary, but I think I do
> > > substantially better than most programmers, even with the handicap of
> > > preferring CL to Python.
> >
> > You are missing something very fundamental here: I AM in a position of
> > authority. And from that point of view, CL is NOT the best language to
> > use. I wish it were, but it isn't.
>
> OK, but you made a very strong claim- that your career is ruined- and
> you blamed it on Lisp.
No, I said my career AS A PROGRAMMER was ruined, which is true. I have,
however, managed to land on my feet. :-)
> I think that the current state of CL is not as good as it could be, in
> an ideal world. I could say the same about lots of other things,
> political and otherwise. I don't mean to be disrespectful- I'm sure
> that you are a very good, and very experienced programmer. But to me,
> it seems that you are mostly venting frustration, rather than making
> serious, constructive criticisms.
Well, my central frustration is that there are (apparently) so few
people using the leverage Lisp provides to get rich. I'm frankly a
little surprised that frustration isn't shared by more people.
rg
Ron Garret wrote:
> In article <·······················@i40g2000cwc.googlegroups.com>,
> "Tagore Smith" <······@tagoresmith.com> wrote:
>
>> I'm working from purely anecdotal evidence here,
>> but I think that a good CL programmer can run rings around a _great_
>> C++ programmer, productivity wise.
>
> If that were true (and I agree that it is), then it should be possible
> to use Lisp to compete successfully against C++ and make tons of money.
> Why are so few people doing that?
...because there are more worthwhile goals in life than making tons of
money?
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
Pascal Costanza wrote:
> Ron Garret wrote:
>> In article <·······················@i40g2000cwc.googlegroups.com>,
>> "Tagore Smith" <······@tagoresmith.com> wrote:
>>
>>> I'm working from purely anecdotal evidence here,
>>> but I think that a good CL programmer can run rings around a _great_
>>> C++ programmer, productivity wise.
>>
>> If that were true (and I agree that it is), then it should be possible
>> to use Lisp to compete successfully against C++ and make tons of
>> money. Why are so few people doing that?
>
> ...because there are more worthwhile goals in life than making tons of
> money?
...and in order not to step into the eurocentricity trap again: Compared
to others, many of us are already making tons of money.
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
In article <···············@individual.net>,
Pascal Costanza <··@p-cos.net> wrote:
> Pascal Costanza wrote:
> > Ron Garret wrote:
> >> In article <·······················@i40g2000cwc.googlegroups.com>,
> >> "Tagore Smith" <······@tagoresmith.com> wrote:
> >>
> >>> I'm working from purely anecdotal evidence here,
> >>> but I think that a good CL programmer can run rings around a _great_
> >>> C++ programmer, productivity wise.
> >>
> >> If that were true (and I agree that it is), then it should be possible
> >> to use Lisp to compete successfully against C++ and make tons of
> >> money. Why are so few people doing that?
> >
> > ...because there are more worthwhile goals in life than making tons of
> > money?
Like what?
> ...and in order not to step into the eurocentricity trap again: Compared
> to others, many of us are already making tons of money.
So which is it? Is it not a worthwhile goal, or is the community
already achieving it?
rg
Ron Garret wrote:
> In article <···············@individual.net>,
> Pascal Costanza <··@p-cos.net> wrote:
>
>
>>Pascal Costanza wrote:
>>
>>>Ron Garret wrote:
>>>
>>>>In article <·······················@i40g2000cwc.googlegroups.com>,
>>>> "Tagore Smith" <······@tagoresmith.com> wrote:
>>>>
>>>>
>>>>>I'm working from purely anecdotal evidence here,
>>>>>but I think that a good CL programmer can run rings around a _great_
>>>>>C++ programmer, productivity wise.
>>>>
>>>>If that were true (and I agree that it is), then it should be possible
>>>>to use Lisp to compete successfully against C++ and make tons of
>>>>money. Why are so few people doing that?
>>>
>>>...because there are more worthwhile goals in life than making tons of
>>>money?
>
>
> Like what?
According to Donald Trump, helping others. I saw it on TV.
>
>
>>...and in order not to step into the eurocentricity trap again: Compared
>>to others, many of us are already making tons of money.
>
>
> So which is it? Is it not a worthwhile goal, or is the community
> already achieving it?
I think he meant we have food and shelter and health care, making us
pretty damn well off. We are also, most of us, not being bombed into
oblivion by the US or subjected to other lovely macro state-originated
man's-inhumanity-to-man escapades.
ken
--
Cells: http://common-lisp.net/project/cells/
"Have you ever been in a relationship?"
Attorney for Mary Winkler, confessed killer of her
minister husband, when asked if the couple had
marital problems.
In article <··············@fe10.lga>, Ken Tilton <·········@gmail.com>
wrote:
> Ron Garret wrote:
> > In article <···············@individual.net>,
> > Pascal Costanza <··@p-cos.net> wrote:
> >
> >
> >>Pascal Costanza wrote:
> >>
> >>>Ron Garret wrote:
> >>>
> >>>>In article <·······················@i40g2000cwc.googlegroups.com>,
> >>>> "Tagore Smith" <······@tagoresmith.com> wrote:
> >>>>
> >>>>
> >>>>>I'm working from purely anecdotal evidence here,
> >>>>>but I think that a good CL programmer can run rings around a _great_
> >>>>>C++ programmer, productivity wise.
> >>>>
> >>>>If that were true (and I agree that it is), then it should be possible
> >>>>to use Lisp to compete successfully against C++ and make tons of
> >>>>money. Why are so few people doing that?
> >>>
> >>>...because there are more worthwhile goals in life than making tons of
> >>>money?
> >
> >
> > Like what?
>
> According to Donald Trump, helping others. I saw it on TV.
Must be true then. Would not having a lot of money would enable you to
help others more?
> >>...and in order not to step into the eurocentricity trap again: Compared
> >>to others, many of us are already making tons of money.
> >
> >
> > So which is it? Is it not a worthwhile goal, or is the community
> > already achieving it?
>
> I think he meant we have food and shelter and health care, making us
> pretty damn well off. We are also, most of us, not being bombed into
> oblivion by the US or subjected to other lovely macro state-originated
> man's-inhumanity-to-man escapades.
Yes, but I suspect that most people reading this who have those things
still have to work full time to maintain those things. That leaves less
time available for helping others.
For example, with enough money you can go out and buy yourself some
Congressmen so that you could get them to impeach G.W. Bush so we could
stop bombing people into oblivion. (I don't want this to degenerate
into a political argument. I just want to make the point that *if* you
believe that the U.S. bombing people into oblivion is a bad thing, then
having more money enables you to do more about it than having less.)
rg
On 2006-04-28, Ron Garret <·········@flownet.com> wrote:
>
> For example, with enough money you can go out and buy yourself some
> Congressmen so that you could get them to impeach G.W. Bush so we could
> stop bombing people into oblivion. (I don't want this to degenerate
You should study the constitution, you would need to buy senators.
They are the ones who serve as the jury in this case.
marc
--
······@sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org
In article <·····················@sdf.lonestar.org>,
marc spitzer <······@sdf.lonestar.org> wrote:
> On 2006-04-28, Ron Garret <·········@flownet.com> wrote:
> >
> > For example, with enough money you can go out and buy yourself some
> > Congressmen so that you could get them to impeach G.W. Bush so we could
> > stop bombing people into oblivion. (I don't want this to degenerate
>
>
> You should study the constitution, you would need to buy senators.
> They are the ones who serve as the jury in this case.
Constitution of the United States, Article I, Section 2, last sentence:
"The House of Representatives ... shall have the sole Power of
Impeachment."
You should study the dictionary. Impeachment refers only to the
indictment, not the actual removal from office. (It is not at all clear
that removal from office would improve the situation considering who is
currently VP. The Bush dynasty has actually shown uncanny skill in
selecting their running mates so as to make their removal from office
quite the unappetizing proposition.)
But since you mention it, OK, I'll take a few senators as well. Oh,
and throw in an order of fries while your at it.
rg
On 2006-04-29, Ron Garret <·········@flownet.com> wrote:
> In article <·····················@sdf.lonestar.org>,
> marc spitzer <······@sdf.lonestar.org> wrote:
>>
>> You should study the constitution, you would need to buy senators.
>> They are the ones who serve as the jury in this case.
>
> Constitution of the United States, Article I, Section 2, last sentence:
> "The House of Representatives ... shall have the sole Power of
> Impeachment."
To impeach the President you need a guilty vote by the senators. The House
can start the process but the Senate is who votes to impeach or not to. I
stand by what I orignally said.
marc
marc spitzer <······@sdf.lonestar.org> writes:
> On 2006-04-29, Ron Garret <·········@flownet.com> wrote:
>> In article <·····················@sdf.lonestar.org>,
>> marc spitzer <······@sdf.lonestar.org> wrote:
>>>
>>> You should study the constitution, you would need to buy senators.
>>> They are the ones who serve as the jury in this case.
>>
>> Constitution of the United States, Article I, Section 2, last sentence:
>> "The House of Representatives ... shall have the sole Power of
>> Impeachment."
>
> To impeach the President you need a guilty vote by the senators. The House
> can start the process but the Senate is who votes to impeach or not to. I
> stand by what I orignally said.
You stand incorrect. Impeachment is the act the House takes. The
Senate decides guilt and passes sentence. The two are different
things. The definition of "impeachment" intended by the Constitution
is this one, #1 from my dictionary: "to bring an accusation against;
to charge with a crime or misdemeanor; specifically : to charge (a
public official) before a competent tribunal with misconduct in
office."
Ari Johnson <················@gmail.com> writes:
> marc spitzer <······@sdf.lonestar.org> writes:
>
>> On 2006-04-29, Ron Garret <·········@flownet.com> wrote:
>>> In article <·····················@sdf.lonestar.org>,
>>> marc spitzer <······@sdf.lonestar.org> wrote:
>>>>
>>>> You should study the constitution, you would need to buy senators.
>>>> They are the ones who serve as the jury in this case.
>>>
>>> Constitution of the United States, Article I, Section 2, last sentence:
>>> "The House of Representatives ... shall have the sole Power of
>>> Impeachment."
>>
>> To impeach the President you need a guilty vote by the senators. The House
>> can start the process but the Senate is who votes to impeach or not to. I
>> stand by what I orignally said.
>
> You stand incorrect. Impeachment is the act the House takes. The
> Senate decides guilt and passes sentence. The two are different
> things. The definition of "impeachment" intended by the Constitution
> is this one, #1 from my dictionary: "to bring an accusation against;
> to charge with a crime or misdemeanor; specifically : to charge (a
> public official) before a competent tribunal with misconduct in
> office."
Re-reading your post - you were correct originally but not in your
second post. It's merely a matter of terminology. :)
FWIW, you're not the first person to get lost in the terminology. At
least one of my American History teachers in high school got it wrong,
too. :(
On 2006-05-05, Ari Johnson <················@gmail.com> wrote:
> Ari Johnson <················@gmail.com> writes:
>
>> marc spitzer <······@sdf.lonestar.org> writes:
>>
>>> On 2006-04-29, Ron Garret <·········@flownet.com> wrote:
>>>> In article <·····················@sdf.lonestar.org>,
>>>> marc spitzer <······@sdf.lonestar.org> wrote:
>>>>>
>>>>> You should study the constitution, you would need to buy senators.
>>>>> They are the ones who serve as the jury in this case.
>>>>
>>>> Constitution of the United States, Article I, Section 2, last sentence:
>>>> "The House of Representatives ... shall have the sole Power of
>>>> Impeachment."
>>>
>>> To impeach the President you need a guilty vote by the senators. The House
>>> can start the process but the Senate is who votes to impeach or not to. I
>>> stand by what I orignally said.
>>
>> You stand incorrect. Impeachment is the act the House takes. The
>> Senate decides guilt and passes sentence. The two are different
>> things. The definition of "impeachment" intended by the Constitution
>> is this one, #1 from my dictionary: "to bring an accusation against;
>> to charge with a crime or misdemeanor; specifically : to charge (a
>> public official) before a competent tribunal with misconduct in
>> office."
>
> Re-reading your post - you were correct originally but not in your
> second post. It's merely a matter of terminology. :)
>
> FWIW, you're not the first person to get lost in the terminology. At
> least one of my American History teachers in high school got it wrong,
> too. :(
What was talked about was removing a sitting president from office. To
do that you need a guilty vote. So you would need to buy Senators not
Congressmen. Impeachement is the *process* by which a vote is taken by
the Senate on wether or not to impeach the President, the trial not the
verdict. And the context of Ron's message was "to remove a sitting President
from office durring his term" and you need a guilty vote to do that. So
buy Senators not Congressmen
marc
--
······@sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org
marc spitzer <······@sdf.lonestar.org> writes:
> On 2006-05-05, Ari Johnson <················@gmail.com> wrote:
>> Ari Johnson <················@gmail.com> writes:
>>
>>> marc spitzer <······@sdf.lonestar.org> writes:
>>>
>>>> On 2006-04-29, Ron Garret <·········@flownet.com> wrote:
>>>>> In article <·····················@sdf.lonestar.org>,
>>>>> marc spitzer <······@sdf.lonestar.org> wrote:
>>>>>>
>>>>>> You should study the constitution, you would need to buy senators.
>>>>>> They are the ones who serve as the jury in this case.
>>>>>
>>>>> Constitution of the United States, Article I, Section 2, last sentence:
>>>>> "The House of Representatives ... shall have the sole Power of
>>>>> Impeachment."
>>>>
>>>> To impeach the President you need a guilty vote by the senators. The House
>>>> can start the process but the Senate is who votes to impeach or not to. I
>>>> stand by what I orignally said.
>>>
>>> You stand incorrect. Impeachment is the act the House takes. The
>>> Senate decides guilt and passes sentence. The two are different
>>> things. The definition of "impeachment" intended by the Constitution
>>> is this one, #1 from my dictionary: "to bring an accusation against;
>>> to charge with a crime or misdemeanor; specifically : to charge (a
>>> public official) before a competent tribunal with misconduct in
>>> office."
>>
>> Re-reading your post - you were correct originally but not in your
>> second post. It's merely a matter of terminology. :)
>>
>> FWIW, you're not the first person to get lost in the terminology. At
>> least one of my American History teachers in high school got it wrong,
>> too. :(
>
> What was talked about was removing a sitting president from office. To
> do that you need a guilty vote. So you would need to buy Senators not
> Congressmen. Impeachement is the *process* by which a vote is taken by
> the Senate on wether or not to impeach the President, the trial not the
> verdict. And the context of Ron's message was "to remove a sitting President
> from office durring his term" and you need a guilty vote to do that. So
> buy Senators not Congressmen
This is why I replied twice. You were correct in saying that you need
to buy Senators (although you have to buy Congressmen as well to start
the process). However, you are incorrect in your assertion that "to
impeach" means "to remove by a guilty verdict." Impeachment is the
bringing of charges by the House. The Constitution, the dictionary,
and history are all clear on this point.
Ron Garret <·········@flownet.com> writes:
> In article <···············@individual.net>,
> Pascal Costanza <··@p-cos.net> wrote:
>
> > Pascal Costanza wrote:
> > > Ron Garret wrote:
> > >> In article <·······················@i40g2000cwc.googlegroups.com>,
> > >> "Tagore Smith" <······@tagoresmith.com> wrote:
> > >>
> > >>> I'm working from purely anecdotal evidence here,
> > >>> but I think that a good CL programmer can run rings around a _great_
> > >>> C++ programmer, productivity wise.
> > >>
> > >> If that were true (and I agree that it is), then it should be possible
> > >> to use Lisp to compete successfully against C++ and make tons of
> > >> money. Why are so few people doing that?
> > >
> > > ...because there are more worthwhile goals in life than making tons of
> > > money?
>
> Like what?
Pretty much anything. However, it is true that _having_ "tons of
money" will open up and make viable a lot of the possibilities in the
space of "pretty much anything".
> > ...and in order not to step into the eurocentricity trap again: Compared
> > to others, many of us are already making tons of money.
>
> So which is it? Is it not a worthwhile goal, or is the community
> already achieving it?
You're confusing "having" and "making".
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
In article <··············@rigel.goldenthreadtech.com>,
jayessay <······@foo.com> wrote:
> Ron Garret <·········@flownet.com> writes:
>
> > In article <···············@individual.net>,
> > Pascal Costanza <··@p-cos.net> wrote:
> >
> > > Pascal Costanza wrote:
> > > > Ron Garret wrote:
> > > >> In article <·······················@i40g2000cwc.googlegroups.com>,
> > > >> "Tagore Smith" <······@tagoresmith.com> wrote:
> > > >>
> > > >>> I'm working from purely anecdotal evidence here,
> > > >>> but I think that a good CL programmer can run rings around a _great_
> > > >>> C++ programmer, productivity wise.
> > > >>
> > > >> If that were true (and I agree that it is), then it should be possible
> > > >> to use Lisp to compete successfully against C++ and make tons of
> > > >> money. Why are so few people doing that?
> > > >
> > > > ...because there are more worthwhile goals in life than making tons of
> > > > money?
> >
> > Like what?
>
> Pretty much anything. However, it is true that _having_ "tons of
> money" will open up and make viable a lot of the possibilities in the
> space of "pretty much anything".
Yes, that's the point I was leading towards by asking the question.
> > > ...and in order not to step into the eurocentricity trap again: Compared
> > > to others, many of us are already making tons of money.
> >
> > So which is it? Is it not a worthwhile goal, or is the community
> > already achieving it?
>
> You're confusing "having" and "making".
Making is generally a prerequisite to having.
rg
Ron Garret <·········@flownet.com> writes:
> In article <··············@rigel.goldenthreadtech.com>,
> jayessay <······@foo.com> wrote:
>
> > You're confusing "having" and "making".
>
> Making is generally a prerequisite to having.
Not in the case of "tons of money"; not unless you stretch the meaning
of "making" until it becomes pretty empty. Evidence suggests that
"having tons of money" has not much to do with "making" much of
anything and a whole lot to do with what would typically be termed
"luck".
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
jayessay wrote:
> Ron Garret <·········@flownet.com> writes:
>
>
>>In article <··············@rigel.goldenthreadtech.com>,
>> jayessay <······@foo.com> wrote:
>>
>>
>>>You're confusing "having" and "making".
>>
>>Making is generally a prerequisite to having.
>
>
> Not in the case of "tons of money"; not unless you stretch the meaning
> of "making" until it becomes pretty empty. Evidence suggests that
> "having tons of money" has not much to do with "making" much of
> anything and a whole lot to do with what would typically be termed
> "luck".
>
>
> /Jon
>
Actually, it usually consists mostly of "getting money from other people
who already have it". How much luck this contains is a debatable point.
--
The science of economics is the cleverest proof of free will yet
constructed.
Ron Garret wrote:
> Two things to get out of the way at the outset:
...
> 1. CL lacks standardized support for many operations that are
> necessities in today's world (e.g. sockets, database connectivity,
> foreign functions). Moreover, it lacks any mechanism by which these
> features could be standardized. It is claimed that there are portable
> libraries that work across implementations that provide de facto
> standards, e.g. UFFI, but these claims are false. I don't have time to
> get into details at the moment, but the fact of the matter is that
> trying to use Lisp for e.g. writing a Web server is an incredibly
> painful experience compared to doing the same thing in e.g. Python.
>
> The Balkanization of the CL implementation space also has the
> consequence that one must choose between using implementation-specific
> features and thus limiting the potential audience for one's code to a
> niche within a niche, or writing to the least common denominator, which
> generally means writing an awful lot of #+ reader macros.
The Common Lisp language is still evolving. New ideas are being explored
in the marketplace and among community driven projects. In time, pseudo
standards will emerge and then the community may choose to standardize on
them.
There are commercial vendors who would be happy to help you with support for
their implementation. I can say that the Scieneer CL implementation fully
supports CFFI and UFFI, and I'm sure other vendors would be quick to add
support or address any issues you have. There is also an active community of
volunteers who will likely offer free help, and may be available on commercial
terms to assist.
A wide choice of CL implementations and extensions is a sign of a healthy
community. The industry will standardize on future extensions once they have
been well tests in the market. CL vendors and community projects are busy
developing and refining extensions.
By utilizing support from a CL vendor, or perhaps even free support from the
community, you should be able to quickly smooth over any issues you have.
Regards
Douglas Crosher
Director
Scieneer Pty Ltd
In article <·························@lon-reader.news.telstra.net>,
Douglas Crosher <···@scieneer.com> wrote:
> Ron Garret wrote:
> > Two things to get out of the way at the outset:
> ...
>
> > 1. CL lacks standardized support for many operations that are
> > necessities in today's world (e.g. sockets, database connectivity,
> > foreign functions). Moreover, it lacks any mechanism by which these
> > features could be standardized. It is claimed that there are portable
> > libraries that work across implementations that provide de facto
> > standards, e.g. UFFI, but these claims are false. I don't have time to
> > get into details at the moment, but the fact of the matter is that
> > trying to use Lisp for e.g. writing a Web server is an incredibly
> > painful experience compared to doing the same thing in e.g. Python.
> >
> > The Balkanization of the CL implementation space also has the
> > consequence that one must choose between using implementation-specific
> > features and thus limiting the potential audience for one's code to a
> > niche within a niche, or writing to the least common denominator, which
> > generally means writing an awful lot of #+ reader macros.
>
> The Common Lisp language is still evolving.
It is? That's news to me. When was the last time a change was made to
the Common Lisp language?
> There are commercial vendors who would be happy to help you with support for
> their implementation. I can say that the Scieneer CL implementation fully
> supports CFFI and UFFI, and I'm sure other vendors would be quick to add
> support or address any issues you have. There is also an active community of
> volunteers who will likely offer free help, and may be available on commercial
> terms to assist.
All this is true, but completely misses the point.
> A wide choice of CL implementations and extensions is a sign of a healthy
> community.
Perhaps. Imagine how much better things would be if the code for
opening a TCP socket were the same in every implementation.
> The industry will standardize on future extensions once they have
> been well tests in the market. CL vendors and community projects are busy
> developing and refining extensions.
How long do I have to wait before TCP sockets are standardized? This is
not exactly bleeding-edge technology any more.
> By utilizing support from a CL vendor, or perhaps even free support from the
> community, you should be able to quickly smooth over any issues you have.
True, but once again this misses the point.
rg
···@zedat.fu-berlin.de (Stefan Ram) writes:
> Douglas Crosher <···@scieneer.com> writes:
>>By utilizing support from a CL vendor, or perhaps even free
>>support from the community, you should be able to quickly
>>smooth over any issues you have.
>
> Assume, I'd like to write a Common Lisp program with a small GUI.
>
> The issue is: This GUI can (AFAIK) not be done in a
> vendor-independent manner. I.e., my source code will not run
> under every conforming Common Lisp implementation, but needs
> to be adopted to a special GUI library, which is an extension
> to Common Lisp but not standardized by Common Lisp or by
> a supplement to the Common Lisp standard.
>
> How could »utilizing support from a CL vendor« help me to
> resolve this issue? This support could only help me to bind my
> code even closer to the special GUI library of this vendor.
>
http://www.peter-herth.de/ltk/
--
"...and when, another time, I discovered that he considered not
unworthy of reflection in one of those mirrors of absolute truth which
were his writings a remark similar to one which I had had occasion to
make about our friend M. Legrandin, ...then it was suddenly revealed
to me that my own humble existence and the realms of the true were
less widely separated than I had supposed, that at certain points they
actually collided, and in my newfound confidence and joy, I had wept
upon his printed page as in the arms of a long-lost father."
Stefan Ram wrote:
> Douglas Crosher <···@scieneer.com> writes:
> Assume, I'd like to write a Common Lisp program with a small GUI.
>
> The issue is: This GUI can (AFAIK) not be done in a
> vendor-independent manner. I.e., my source code will not run
> under every conforming Common Lisp implementation, but needs
> to be adopted to a special GUI library, which is an extension
> to Common Lisp but not standardized by Common Lisp or by
> a supplement to the Common Lisp standard.
>
> How could »utilizing support from a CL vendor« help me to
> resolve this issue? This support could only help me to bind my
> code even closer to the special GUI library of this vendor.
I think you're suffing from java envy. Unless you build your own
virtual platform from scratch like sun did with Java then there is no
GUI standard that works in every implementation of every language.
Common Lisp, as a general purpose programming language like C and C++
provides the power to write a Gui but is not IMHO also a platform for
providing a standard Gui library or even API.
Like many other languages you can use free of propriatory Gui libraries
as you see fit.
Justin
Stefan Ram wrote:
> Douglas Crosher <···@scieneer.com> writes:
> Assume, I'd like to write a Common Lisp program with a small GUI.
>
> The issue is: This GUI can (AFAIK) not be done in a
> vendor-independent manner. I.e., my source code will not run
> under every conforming Common Lisp implementation, but needs
> to be adopted to a special GUI library, which is an extension
> to Common Lisp but not standardized by Common Lisp or by
> a supplement to the Common Lisp standard.
>
> How could »utilizing support from a CL vendor« help me to
> resolve this issue? This support could only help me to bind my
> code even closer to the special GUI library of this vendor.
I think you're suffing from java envy. Unless you build your own
virtual platform from scratch like sun did with Java then there is no
GUI standard that works in every implementation of every language.
Common Lisp, as a general purpose programming language like C and C++
provides the power to write a Gui but is not IMHO also a platform for
providing a standard Gui library or even API.
Like many other languages you can use free or propriatory Gui libraries
as you see fit.
Justin
Stefan Ram wrote:
> Douglas Crosher <···@scieneer.com> writes:
>
>>By utilizing support from a CL vendor, or perhaps even free
>>support from the community, you should be able to quickly
>>smooth over any issues you have.
>
>
> Assume, I'd like to write a Common Lisp program with a small GUI.
>
> The issue is: This GUI can (AFAIK) not be done in a
> vendor-independent manner. I.e., my source code will not run
> under every conforming Common Lisp implementation, but needs
> to be adopted to a special GUI library, which is an extension
> to Common Lisp but not standardized by Common Lisp or by
> a supplement to the Common Lisp standard.
>
> How could �utilizing support from a CL vendor� help me to
> resolve this issue? This support could only help me to bind my
> code even closer to the special GUI library of this vendor.
Just choose a portable GUI and ask your vendors as add support if
necessary. There are many freely available GUI options out there.
The Scieneer CL supports: CLX, McCLIM, CL-SDL, Lambda-GTK, LTK, LGTK,
plus others, and for web based interfaces supports Portable
AllegroServe and CL-HTTP. Requests for other ports will be considered
and could be undertaken on commercial terms. Given that the Scieneer CL
fully supports CFFI and UFFI and also has a FFI largely compatible
with the popular CMUCL, porting applications is often easy.
If a commercially supported and portable GUI is a requirement for your work
then it is likely that someone will step forward to provide you a solution
on commercial terms, and I would encourage you to contact the authors of
some of the above freely available GUIs.
Your choices are experience will further help de facto standards emerge.
Regards
Douglas Crosher
Director
Scieneer Pty Ltd
Ron Garret wrote:
> 3. I do not hate Lisp. It is and has always been my favorite
> programming languages. My love for Lisp pretty much destroyed my career
> as a programmer. My motivation for criticising Lisp is not to convince
How did it do this?
In article <························@g10g2000cwb.googlegroups.com>,
"Jonathon McKitrick" <···········@bigfoot.com> wrote:
> Ron Garret wrote:
> > 3. I do not hate Lisp. It is and has always been my favorite
> > programming languages. My love for Lisp pretty much destroyed my career
> > as a programmer. My motivation for criticising Lisp is not to convince
>
> How did it do this?
That's a long story. Part of it is told here:
http://www.flownet.com/gat/jpl-lisp.html
and here:
http://groups.google.com/group/comp.lang.lisp/msg/6f75cfb5a289d3f6
But in the context of the current discussion I think it's worthwhile
giving an abridged version:
I first learned Lisp in the early 80's when I was still in high school.
I was interested in AI, and in those days Lisp was the lingua franca. I
took a little detour as an undergrad by getting a EE degree, but in grad
school in the mid-80's I went back to Lisp (mostly Scheme and Franz Lisp
back then, and later MacScheme and Coral Lisp, which would later morph
into MCL).
My colleagues were using C (K&R in those days) or Pascal. C++, Perl,
Java, Python, etc. didn't exist. When all those modern languages are
out of the picture, Lisp rocks. I mean it just blows everything else
clean out of the water. With a secret weapon like Lisp in my arsenal in
1986 I could blow my competition out of the water with one hand tied
behind my back and holding a martini in the other.
(I remember my compilers class in particular. What took my colleagues
reams and reams and reams of Pascal code took me a page of Lisp. This
was before networks became ubiquitous. We turned in assignments on
paper in those days. I still have my folder with all my homework
assignments from that class. It's about a quarter of an inch thick.)
That kind of competitive advantage continued throughout my graduate
career. The competition switched from Pascal to C, but it was still no
contest. Then they switched to C++ in the early 90's -- or at least
they tried. The state of C++ was so horrific back then that they were
forced to go back to Lisp because they just couldn't get things to run
in C++ even though they tried very very hard.
But a funny thing happened in the late 90's. C++ got its act together.
Java and Perl came along (and later, Python). Meanwhile, Lisp hadn't
advanced much in about a decade (since the ANSI spec was finalized). It
was still a win, but the competition had narrowed the field. Once upon
a time Lisp had a long list of features that no other language had (GC,
full numeric tower, CLOS, incremental development, macros) that list
kept getting shorter and shorter, and the case for Lisp, which had never
been easy even in the best of times, was getting harder and harder to
make.
So I went to Google in 2000 with this really impressive resume that I
had built using Lisp, and when I got there they said, "Glad you're here,
we want you to write Java code." Thing is, I had never really had to
learn Java, so I wasn't very good at it. On top of that, knowing Lisp
made me all too keenly aware of Java's shortcomings, and I had a very
hard time not being angry at how stupid it was that I was being forced
to use it. (If you want more details about that part of my life story,
read xooglers.)
But then a very strange thing happened: I noticed that all around me
people were writing code using C++ and Java and Python and even (gasp!)
Perl, and they were actually getting it to work without tearing their
hair out. In fact, in a number of cases I saw people whip things up in
Perl in a couple of hours that would have taken me days or weeks to do
in Lisp.
The conclusion was inescapable: the problem wasn't Perl or C++ or Java,
it was me. I just wasn't a very good programmer any more. Lisp's power
had made me complacent, and the world had passed me by. Looking back, I
actually don't think I was ever a very good programmer. I just happened
to have the good fortune to recognize a good thing when I saw it, and
used the resulting leverage to build a successful career. But I credit
much of my success to the people who designed Common Lisp.
It was nice while it lasted.
rg
From: Espen Vestre
Subject: Re: How knowing Lisp destroyed my programming career
Date:
Message-ID: <m11wvnwilv.fsf@vestre.net>
Ron Garret <·········@flownet.com> writes:
> But then a very strange thing happened: I noticed that all around me
> people were writing code using C++ and Java and Python and even (gasp!)
> Perl, and they were actually getting it to work without tearing their
> hair out. In fact, in a number of cases I saw people whip things up in
> Perl in a couple of hours that would have taken me days or weeks to do
> in Lisp.
I can imagine that at a place like Google, you'll get to work with
some really fantastic hackers that can do magic with about any
tool. And "whipping things up in Perl in a couple of hours" can be
both cool and useful, but afaik it's still not good for real systems
and applications building. Perl is still a WORN language! For me,
"coming home" to lisp from Perl some years ago was a real relief: I
needed a little more time to work out a few of the details, but my
code got an order of magnitude more maintainable, so as soon as I
started to modify, reuse and grow my code, I saved a lot of time and
pain.
--
(espen)
Espen Vestre <·····@vestre.net> writes:
> Ron Garret <·········@flownet.com> writes:
>
>> But then a very strange thing happened: I noticed that all around me
>> people were writing code using C++ and Java and Python and even (gasp!)
>> Perl, and they were actually getting it to work without tearing their
>> hair out. In fact, in a number of cases I saw people whip things up in
>> Perl in a couple of hours that would have taken me days or weeks to do
>> in Lisp.
>
> I can imagine that at a place like Google, you'll get to work with
> some really fantastic hackers that can do magic with about any
> tool. And "whipping things up in Perl in a couple of hours" can be
> both cool and useful, but afaik it's still not good for real systems
> and applications building. Perl is still a WORN language! For me,
> "coming home" to lisp from Perl some years ago was a real relief: I
> needed a little more time to work out a few of the details, but my
> code got an order of magnitude more maintainable, so as soon as I
> started to modify, reuse and grow my code, I saved a lot of time and
> pain.
> --
My experiences with perl have been similar - not bad for quick system
admin type scripts, log analysis and relatively trivial tasks.
However, I don't find it scales well into larger projects and
unfortunately, I feel one of the published "strengths" of perl is also
one of its main flaws when working on larger projects with multiple
developers - perls "Do it your way" - style and feature use in perl
can be so diverse, understanding contributions from multiple users can
be challenging (also one of the things I like about CL is a simple
consistent syntax which allows easy formatting into whatever style you
prefer and there is less variation to begin with).
for example, you have '||' and 'or' and '&&' and 'and', but they have
different precedence. You can use subroutine prototyping, which will
effect how you pass arguments and whether you call it as 'subroutine x y
z' or 'subroutine(x, y, z)' or '&subroutine(x, y, z)' etc.
Despite that, for smaller projects and quick hacks, its pretty good
and a tool I like to use from time to time. Howver, I have been using
CL a bit more recently - especially now we have the wonderful ppcre
library (sit down Ron :-).
Tim
--
tcross (at) rapttech dot com dot au
Tim X wrote:
> My experiences with perl have been similar - not bad for quick system
> admin type scripts, log analysis and relatively trivial tasks.
> However, I don't find it scales well into larger projects and
> unfortunately, I feel one of the published "strengths" of perl is also
> one of its main flaws when working on larger projects with multiple
> developers - perls "Do it your way" - style and feature use in perl
> can be so diverse, understanding contributions from multiple users can
> be challenging (also one of the things I like about CL is a simple
> consistent syntax which allows easy formatting into whatever style you
> prefer and there is less variation to begin with).
I think that you probably need some discipline (perhaps externally
imposed) for large Perl systems, but I think they're quite doable.
>
> for example, you have '||' and 'or' and '&&' and 'and', but they have
> different precedence. You can use subroutine prototyping, which will
> effect how you pass arguments and whether you call it as 'subroutine x y
> z' or 'subroutine(x, y, z)' or '&subroutine(x, y, z)' etc.
Well, CL has IF and COND and UNLESS and WHEN and AND, and (horror!)
user-defined conditionals too. And functions, macros, methods, macros
that look like functions but aren' tin obscure ways, an object system
which lets you define your own method combinations, a package system
which lets you make IF mean something completely different. Closures
which work except some stuff got left out for efficiency.
Just like Perl, CL is a language in which you can hang yourself
whichever way you like, and a language designed, above all, to get
stuff done. In all the ways that matter, Perl is by *far* the most
CL-like language I've ever used - far closer to it than Scheme or
Python, which are basically written by the kind of people who would
rather spend their time in some kind of monastry flagellating
themselves for crimes against Computer Science.
--tim
"Tim Bradshaw" <··········@tfeb.org> writes:
> Tim X wrote:
>> My experiences with perl have been similar - not bad for quick system
>> admin type scripts, log analysis and relatively trivial tasks.
>> However, I don't find it scales well into larger projects and
>> unfortunately, I feel one of the published "strengths" of perl is also
>> one of its main flaws when working on larger projects with multiple
>> developers - perls "Do it your way" - style and feature use in perl
>> can be so diverse, understanding contributions from multiple users can
>> be challenging (also one of the things I like about CL is a simple
>> consistent syntax which allows easy formatting into whatever style you
>> prefer and there is less variation to begin with).
>
> I think that you probably need some discipline (perhaps externally
> imposed) for large Perl systems, but I think they're quite doable.
>
>>
>> for example, you have '||' and 'or' and '&&' and 'and', but they have
>> different precedence. You can use subroutine prototyping, which will
>> effect how you pass arguments and whether you call it as 'subroutine x y
>> z' or 'subroutine(x, y, z)' or '&subroutine(x, y, z)' etc.
>
> Well, CL has IF and COND and UNLESS and WHEN and AND, and (horror!)
> user-defined conditionals too. And functions, macros, methods, macros
> that look like functions but aren' tin obscure ways, an object system
> which lets you define your own method combinations, a package system
> which lets you make IF mean something completely different. Closures
> which work except some stuff got left out for efficiency.
>
> Just like Perl, CL is a language in which you can hang yourself
> whichever way you like, and a language designed, above all, to get
> stuff done. In all the ways that matter, Perl is by *far* the most
> CL-like language I've ever used - far closer to it than Scheme or
> Python, which are basically written by the kind of people who would
> rather spend their time in some kind of monastry flagellating
> themselves for crimes against Computer Science.
>
I don't disagree with your basic argument - you can create a mess with
any tool if used incorrectly. Perl is a language I like using,
particularly if I'm using it on my own. However, in multi-developer
projects its another story. A programming style guide is almost a
necessity for perl in this sort of environment and while a style guide
wouldn't go astray in a lisp project, I don't think its quite as
critical.
With perl, I've seen some really nice code which was easy to read and
understand, but I've also seen code which looks like line noise and
working out what it does takes considerable effort. While you have a
lot of power to introduce new control structures and define domain
specific languuages with lisp, I personally don't find it anywhere
near as hard to read/follow. Although you can create non0\-lisp
looking constructs (i.e. loop), this seems to be rare. Perl, with its
implicit hidden variables, alternatively named control structures with
differend precedence, behavior which depends on whether a variable is
an lvalue/rvalue, used in scalar or list context, various subroutine
calling options etc, provides a lot more scope for developing
different coding styles and this can lead to considerable effort when
trying to work with others code.
I also find with perl I need to concentrate on readability a lot more
than I do with lisp. As long as I use meaningful names in lisp, it
seems anyone familiar with the language can follow what I've done with
minimal mental effort. With perl, this isn't always true.
Tim
--
tcross (at) rapttech dot com dot au
From: Ken Tilton
Subject: Re: How knowing Lisp destroyed my programming career
Date:
Message-ID: <mb63g.2$5T2.1@fe11.lga>
Ron Garret wrote:
> Looking back, I
> actually don't think I was ever a very good programmer. I just happened
> to have the good fortune to recognize a good thing when I saw it, and
> used the resulting leverage to build a successful career. But I credit
> much of my success to the people who designed Common Lisp.
So shouldn't the thread title be "How Lisp Made Me Look Good So I Could
Get Hired By A Booming Company and Get Rich Off Options"?
I think your only problem is with thread titles. Of course if you are
just trying to make yourself the center of attention...
:)
ken
--
Cells: http://common-lisp.net/project/cells/
"Have you ever been in a relationship?"
Attorney for Mary Winkler, confessed killer of her
minister husband, when asked if the couple had
marital problems.
In article <·············@fe11.lga>, Ken Tilton <·········@gmail.com>
wrote:
> I think your only problem is with thread titles.
Wow, what a relief. I was beginning to think I was a failure as a human
being.
rg
Don't give up !
I hire and lead a teams and right now they are using Java.
If I had someone with LISP on their resume I would hire them before the
other guys.
If I had someone with Smalltalk on their resume I would hire them
before the other guys.
(ie: before those without LISP and Smalltalk).
Why, because of the way you think in these languages. My bet is you
would be a better
Java programmer now or in the near future.
If your really keen on LISP then please send me an email as Im working
on a LISP and
I need keen people to provide all sorts of input.
j l a d d @ i i n e t . n e t . au (just remove the spaces)
Keep well,
Rgs, James.
Ron Garret <·········@flownet.com> writes:
>
> In article <·············@fe11.lga>, Ken Tilton <·········@gmail.com>
> wrote:
>
> > I think your only problem is with thread titles.
>
> Wow, what a relief. I was beginning to think I was a failure as a human
> being.
>
Your original thread title used a vulgar sexual reference
commonly deployed as a heightened expression of contempt by
those intent on provoking a quarrel. (Hint: what is it that
CL sucks?). Your post, though on a subject close to your
heart, started with a faux pas.
Alan Crowe
Ediburgh
Scotland
From: Ken Tilton
Subject: Re: How knowing Lisp destroyed my programming career
Date:
Message-ID: <ePs3g.5$Vp7.1@fe12.lga>
Alan Crowe wrote:
> Ron Garret <·········@flownet.com> writes:
>
>>In article <·············@fe11.lga>, Ken Tilton <·········@gmail.com>
>>wrote:
>>
>>
>>>I think your only problem is with thread titles.
>>
>>Wow, what a relief. I was beginning to think I was a failure as a human
>>being.
No, but the thread title problem speaks to your larger failure so far as
an evangelist.
>>
>
> Your original thread title used a vulgar sexual reference
> commonly deployed as a heightened expression of contempt by
> those intent on provoking a quarrel. (Hint: what is it that
> CL sucks?). Your post, though on a subject close to your
> heart, started with a faux pas.
>
Exactly. I recommend to Ron, the next time he tries, a more positive,
dare I say Kennyesque approach. "Hey, Lisp is really catching on! Let's
mop up these petty annoyances and really crush the scripting languages!!".
But then he should also make a positive step. Not Jeff's unspecific
committee thing, but something finite and achievable with a reasonable
amount of effort, such as cl-sockets.
Unfortunately, I think Ron actually enjoys being The Chew Toy of c.l.l.[1]
:)
ken
[1]
http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/c3f64ab2fe690306/1482301f72bcedb5?lnk=st&q=chew-toy+Erann&rnum=1#1482301f72bcedb5
--
Cells: http://common-lisp.net/project/cells/
"Have you ever been in a relationship?"
Attorney for Mary Winkler, confessed killer of her
minister husband, when asked if the couple had
marital problems.
In article <·············@fe12.lga>, Ken Tilton <·········@gmail.com>
wrote:
> Unfortunately, I think Ron actually enjoys being The Chew Toy of c.l.l.[1]
Oh, yeah, sure. I'm just having a blast out here. My life is just so
empty that I can't imagine anything else I'd rather be doing than taking
ad hominem attacks on Usenet. I live for this.
rg
Ken Tilton wrote:
>
>
> Alan Crowe wrote:
>
>> Ron Garret <·········@flownet.com> writes:
>>
>>> In article <·············@fe11.lga>, Ken Tilton <·········@gmail.com>
>>> wrote:
>>>
>>>
>>>> I think your only problem is with thread titles.
>>>
>>>
>>> Wow, what a relief. I was beginning to think I was a failure as a
>>> human being.
>
>
> No, but the thread title problem speaks to your larger failure so far as
> an evangelist.
>
>>>
>>
>> Your original thread title used a vulgar sexual reference
>> commonly deployed as a heightened expression of contempt by
>> those intent on provoking a quarrel. (Hint: what is it that
>> CL sucks?). Your post, though on a subject close to your
>> heart, started with a faux pas.
>>
>
> Exactly. I recommend to Ron, the next time he tries, a more positive,
> dare I say Kennyesque approach. "Hey, Lisp is really catching on! Let's
> mop up these petty annoyances and really crush the scripting languages!!".
>
> But then he should also make a positive step. Not Jeff's unspecific
> committee thing, but something finite and achievable with a reasonable
> amount of effort, such as cl-sockets.
>
Might I ask why CL absolutely has to be The Lisp Dialect?
--
The science of economics is the cleverest proof of free will yet
constructed.
From: Ken Tilton
Subject: Re: How knowing Lisp destroyed my programming career
Date:
Message-ID: <5WO3g.31$Ni3.25@fe10.lga>
Eli Gottlieb wrote:
> Ken Tilton wrote:
>
>>
>>
>> Alan Crowe wrote:
>>
>>> Ron Garret <·········@flownet.com> writes:
>>>
>>>> In article <·············@fe11.lga>, Ken Tilton
>>>> <·········@gmail.com> wrote:
>>>>
>>>>
>>>>> I think your only problem is with thread titles.
>>>>
>>>>
>>>>
>>>> Wow, what a relief. I was beginning to think I was a failure as a
>>>> human being.
>>
>>
>>
>> No, but the thread title problem speaks to your larger failure so far
>> as an evangelist.
>>
>>>>
>>>
>>> Your original thread title used a vulgar sexual reference
>>> commonly deployed as a heightened expression of contempt by
>>> those intent on provoking a quarrel. (Hint: what is it that
>>> CL sucks?). Your post, though on a subject close to your
>>> heart, started with a faux pas.
>>>
>>
>> Exactly. I recommend to Ron, the next time he tries, a more positive,
>> dare I say Kennyesque approach. "Hey, Lisp is really catching on!
>> Let's mop up these petty annoyances and really crush the scripting
>> languages!!".
>>
>> But then he should also make a positive step. Not Jeff's unspecific
>> committee thing, but something finite and achievable with a reasonable
>> amount of effort, such as cl-sockets.
>>
> Might I ask why CL absolutely has to be The Lisp Dialect?
>
Might I ask where you see someone saying it has to be?
There is no question in my mind, but that is a different matter. If you
were asking /that/, I could tell you. But it would be nothing not
covered in a kazillion CL-Scheme debates.
peace, kenny
--
Cells: http://common-lisp.net/project/cells/
"Have you ever been in a relationship?"
Attorney for Mary Winkler, confessed killer of her
minister husband, when asked if the couple had
marital problems.
Ken Tilton wrote:
>
>
> Eli Gottlieb wrote:
>
>> Ken Tilton wrote:
>>
>>>
>>>
>>> Alan Crowe wrote:
>>>
>>>> Ron Garret <·········@flownet.com> writes:
>>>>
>>>>> In article <·············@fe11.lga>, Ken Tilton
>>>>> <·········@gmail.com> wrote:
>>>>>
>>>>>
>>>>>> I think your only problem is with thread titles.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Wow, what a relief. I was beginning to think I was a failure as a
>>>>> human being.
>>>
>>>
>>>
>>>
>>> No, but the thread title problem speaks to your larger failure so far
>>> as an evangelist.
>>>
>>>>>
>>>>
>>>> Your original thread title used a vulgar sexual reference
>>>> commonly deployed as a heightened expression of contempt by
>>>> those intent on provoking a quarrel. (Hint: what is it that
>>>> CL sucks?). Your post, though on a subject close to your
>>>> heart, started with a faux pas.
>>>>
>>>
>>> Exactly. I recommend to Ron, the next time he tries, a more positive,
>>> dare I say Kennyesque approach. "Hey, Lisp is really catching on!
>>> Let's mop up these petty annoyances and really crush the scripting
>>> languages!!".
>>>
>>> But then he should also make a positive step. Not Jeff's unspecific
>>> committee thing, but something finite and achievable with a
>>> reasonable amount of effort, such as cl-sockets.
>>>
>> Might I ask why CL absolutely has to be The Lisp Dialect?
>>
>
> Might I ask where you see someone saying it has to be?
>
> There is no question in my mind, but that is a different matter. If you
> were asking /that/, I could tell you. But it would be nothing not
> covered in a kazillion CL-Scheme debates.
>
> peace, kenny
>
>
>
Where are those debates? I'd like to read them.
--
The science of economics is the cleverest proof of free will yet
constructed.
From: Ken Tilton
Subject: Re: How knowing Lisp destroyed my programming career
Date:
Message-ID: <8hP3g.21$xW4.9@fe12.lga>
>> There is no question in my mind, but that is a different matter. If
>> you were asking /that/, I could tell you. But it would be nothing not
>> covered in a kazillion CL-Scheme debates.
>>
> Where are those debates? I'd like to read them.
You must be new around these parts. :) I presume you know about Google
groups. I was involved in the last good one a couple years ago (we
really have tired of the debate), so searching on my name and scheme
might turn something up. Oh, you might look specifically for "off with
their heads" with me as the author.
Mind you, two of my favorite technologists are Jay Sulzberger and Joe
Marshall and they are dedicated Schemers, so their will likely be an
amnesty once CL takes over.
:)
kenny
--
Cells: http://common-lisp.net/project/cells/
"Have you ever been in a relationship?"
Attorney for Mary Winkler, confessed killer of her
minister husband, when asked if the couple had
marital problems.
Ken Tilton wrote:
>>> There is no question in my mind, but that is a different matter. If
>>> you were asking /that/, I could tell you. But it would be nothing not
>>> covered in a kazillion CL-Scheme debates.
>>>
>> Where are those debates? I'd like to read them.
>
>
> You must be new around these parts. :) I presume you know about Google
> groups. I was involved in the last good one a couple years ago (we
> really have tired of the debate), so searching on my name and scheme
> might turn something up. Oh, you might look specifically for "off with
> their heads" with me as the author.
>
> Mind you, two of my favorite technologists are Jay Sulzberger and Joe
> Marshall and they are dedicated Schemers, so their will likely be an
> amnesty once CL takes over.
>
> :)
>
> kenny
>
Read a 686 post long thread on the subject (and various other subjects,
as well). Pure religion, all of it.
--
The science of economics is the cleverest proof of free will yet
constructed.
+ Eli Gottlieb <···········@gmail.com>:
| Ken Tilton wrote:
|> But it would be nothing
|> not covered in a kazillion CL-Scheme debates.
|> peace, kenny
|>
| Where are those debates? I'd like to read them.
They're scattered over many years' worth of comp.lang.lisp and
comp.lang.scheme. I suspect that if you go to google groups and just
ask for articles crossposted to both groups, you'll get an idea.
Related are the Lisp-1 vs Lisp-2 debates, and anything mentioning
hygienic macros or call-with-current-continuation on this newsgroup
could be considered part of the same debate, even if Scheme is not
mentioned explicitly. Usenet being what it is, I'll think you will
find the nuggets few and far between.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
when there is no ground whatsoever for supposing it is true.
-- Bertrand Russell
Skimming this very long thread, it appeared to me that the state of CL can
be wastly improved if all the time spent arguing in this thread was
instead spent on:
1) Finding, fixing and releasing a CL unit test tool that has the
facilities neccesary to throughlerly test the majority of lisp libraries.
It does not count to roll your own, the tool has to work for all involved.
2) Then, each participant in this thread picks one CL library and writes
enough good unit tests for it, that he can say for sure that he cannot
find any more bugs or design defects in the library.
3) Finally all works together fixing the bugs and remedying the design
defects and other shortcomings that the tests unearthed.
At the end CL will have been significantly improved, by having a much more
stable and much more capable set of libraries that what CL has today.
This will make CL a viable language and library set for a larger set of
software development projects than it is today, and it will improve the
development projects that are already using CL today.
Kristian