How Common Lisp sucks
Ron Garret
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
Stefan Scholl
> 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.
Stefan Scholl
> 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.
bradb
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
Bill Atkins
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.
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?
Pascal Costanza
> 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/
Erik Enge
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.
Pascal Costanza
> 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.?
karsten
> 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.
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
bradb
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
Dmitry Gorbatovsky
>>>....
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.
Rainer Joswig
"karsten" <karste...@gmail.com> wrote:
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.
Ken Tilton
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.
Pascal Costanza
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.
Dmitry Gorbatovsky
> 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.
bradb
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
Peter Seibel
> 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 * pe...@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
Ken Tilton
Peter Seibel wrote:
> Ron Garret <rNOS...@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.
Frank Buss
> 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, f...@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Barry Margolin
Ron Garret <rNOS...@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, bar...@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 ***
Peter Seibel
> 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.
bradb
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
Ken Tilton
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."
Peter Seibel
> 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
bradb
Peter Seibel wrote:
> "bradb" <brad.be...@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,
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
Ron Garret
Peter Seibel <pe...@gigamonkeys.com> wrote:
> Ron Garret <rNOS...@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
Ron Garret
Dmitry Gorbatovsky <finc...@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
> 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
Ron Garret
Rainer Joswig <jos...@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
Pascal Bourguignon
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.
Ron Garret
"Erik Enge" <erik...@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
matth...@gmail.com
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.
Ron Garret
Pascal Costanza <p...@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
Ron Garret
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
Jack Unrue
>
> In article <4aicgnF...@individual.net>,
> Pascal Costanza <p...@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
Ron Garret
Stefan Scholl <ste...@no-spoon.de> wrote:
> Ron Garret <rNOS...@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
Bill Atkins
> In article <87odz0x...@rpi.edu>, Bill Atkins <NOatki...@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
Bill Atkins
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
Friedrich Dominicus
>
> 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.
Christophe Rhodes
> "bradb" <brad.be...@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
> 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
Bill Atkins
>> 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?
Friedrich Dominicus
>
> 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
Ron Garret
wrote:
> Ron Garret <rNOS...@flownet.com> writes:
>
> > In article <0T333hfsIo3nNv8%ste...@parsec.no-spoon.de>,
> > Stefan Scholl <ste...@no-spoon.de> wrote:
> >
> >> Ron Garret <rNOS...@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
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
Jack Unrue <no....@example.tld> wrote:
If they are not created then how can there be a mechanism for creating
them?
rg
Ron Garret
Pascal Bourguignon <p...@informatimago.com> wrote:
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
matth...@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
Bill Atkins
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
Pascal Costanza
> 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/
Bill Atkins
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
Pascal Bourguignon
>> > 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 Costanza
> In article <4aicgnF...@individual.net>,
> Pascal Costanza <p...@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 Costanza
> 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.
Stefan Scholl
> Stefan Scholl <ste...@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) ;-)
Rainer Joswig
Pascal Costanza <p...@p-cos.net> wrote:
a few remarks to some parts
> Ron Garret wrote:
> > In article <4aicgnF...@individual.net>,
> > Pascal Costanza <p...@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.
Tim X
> 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
Tim X
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 X
> 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.
Marcin 'Qrczak' Kowalczyk
> 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
\__/ qrc...@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Tim X
> In article <1145306165.9...@e56g2000cwe.googlegroups.com>,
> "Erik Enge" <erik...@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.
Förster vom Silberwald
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
Dmitry Gorbatovsky
> In article <e20vrd$vu1$1...@emma.aioe.org>,
> Dmitry Gorbatovsky <finc...@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
Tin Gherdanarra
> In article <0T333hfsIo3nNv8%ste...@parsec.no-spoon.de>,
> Stefan Scholl <ste...@no-spoon.de> wrote:
>
>
>>Ron Garret <rNOS...@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?)
Björn Lindberg
> 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
Peter Seibel
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 * pe...@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
Didier Verna
> Christophe Rhodes <cs...@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, did...@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 did...@xemacs.org
Peter Seibel
> 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.
Surendra Singhi
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
`----
Erik Enge
> 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.
pp
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
Juho Snellman
> 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
Christophe Rhodes
> Christophe Rhodes <cs...@cam.ac.uk> writes:
>
>> Peter Seibel <pe...@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
Luís Oliveira
>> > 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
Peter Seibel
Peter Seibel
> 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?
Paul Wallich
>> wrote:
>>
>>> Ron Garret <rNOS...@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
luis.o...@deadspam.com (Luís Oliveira) wrote:
> Ron Garret <rNOS...@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
Peter Seibel <pe...@gigamonkeys.com> wrote:
> Ron Garret <rNOS...@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
Luís Oliveira
>> 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?
fireblade
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
Alexey Dejneka
> 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
Ron Garret
bj...@runa.se (Björn Lindberg) wrote:
> Ron Garret <rNOS...@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 Garret
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
Tim X <ti...@nospam.dev.null> wrote:
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
fireblade
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.
Peter Seibel
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
Ron Garret
Tim X <ti...@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
Rainer Joswig
Ron Garret <rNOS...@flownet.com> wrote:
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.
Rainer Joswig
Ron Garret <rNOS...@flownet.com> wrote:
Lisp implementations have all these. Choose one.
Peter Seibel
> Peter Seibel <pe...@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.
Ron Garret
Pascal Costanza <p...@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
Pascal Costanza
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/
Ken Tilton
Ron Garret wrote:
> In article <9mpvet7...@muvclx01.cadence.com>,
> bj...@runa.se (Björn Lindberg) wrote:
>
>
>>Ron Garret <rNOS...@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.
Ken Tilton
fireblade wrote:
> 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.
Gates kids?! Shoo! Go away! I hear your Mommy calling you!
Rainer Joswig
Ron Garret <rNOS...@flownet.com> wrote:
And where is it?
In the meantime Common Lisp implementations have been
ported to various 64bit machines, new operating systems,
we see a new multi-processor enabled implementation
with high-performance HTTP built-in, got
all kinds of interfaces to Microsoft stuff (.net),
web stuff, unix stuff, ....
- OpenMCL currently gets ported to 64bit AMDs running Linux
- GCL gets ANSI compliant, has some applications running
(Maxima, Axiom, Applicative Common Lisp, ...) on top...
- Allegro CL has been ported to a multitude of implementations,
has a new database, lots of libs, IDE on Linux
- LispWorks is currently being ported to 64bit machines,
gets an improved core, ...
(ftp://ftp.lispworks.com/pub/software_tools/downloads/Amsterdam2005/LW.pdf)
- ECL, SBCL and CMUCL have seen new releases
- Scieneer CL runs on multiprocessor machines
(http://www.scieneer.com/scl/index.html)
Why should the Common Lisp community give up all that? For 'ciel'.
No chance.
Side note:
Now that I might get a x86-based Mac this year, I am sure
that there will be atleast one Common Lisp for that platform.
Ah, wait, there are already some. With LispWorks and
Allegro CL following soon. For me that's a sign - a new
platform appears and how soon do I get a free and/or
commercial Common Lisp implementation for it. Since
there will be more then one, I think the situation looks
quite rosy - actually within a year I'd expect to see
atleast six implementations being ported to the Intel
Mac.
Ciel won't be there in ten years. Arc? I don't care.
Btw., I'm pretty sure all the Lisp implementations for
the Intel Mac OS X will have interfaces to sockets, threads,
and so on...
fireblade
Ken Tilton wrote:
> fireblade wrote:
> > 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.
>
> Gates kids?! Shoo! Go away! I hear your Mommy calling you!
>
> :)
>
> ken
We are the MS. Lower your listener and stop writing macros.
We will add your generics and technological distinctiveness to our own
(Visual Lisp Studio sharp .Net 2010 COM+ with ASP.Net XML ado etc).
Your culture will adapt to service us (No more closures, defun etc).
Resistance is futile you'll be assimilated
(or starved to death ).
Bill
Jack Unrue
>In article <rar8429ta9bl0qf9k...@4ax.com>,
> Jack Unrue <no....@example.tld> wrote:
>
>> On Mon, 17 Apr 2006 21:28:39 -0700, Ron Garret <rNOS...@flownet.com> wrote:
>> >
>> > In article <4aicgnF...@individual.net>,
>> > Pascal Costanza <p...@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?
>
Clearly I did not mean that code magically pops into
existence, and Pascal has spelled out what he meant in
a separate post. I was unsuccessfully trying to
differentiate between code in and of itself, and that
code being accepted as a "de facto" standard.
I would hope that any future standards effort, of the
kind you were referring to originally, would lean towards
codifying existing practice.
Surely you agree that de facto standards:
- are a solid basis from which to work
- arise even in programming languages that
have sanctioned standards processes, and
serve a critical role in maintaining
mindshare in those communities as well as
providing feedback into the official process(es)
- are in fact what constitute many of the features
considered "standard" in other languages which
are being held up as examples of shortcomings
in Common Lisp
--
Jack Unrue
Pascal Costanza
> In article <4ajmb0F...@individual.net>,
> Pascal Costanza <p...@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?
>> 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.
> Are you the same Pascal Costanza who took SteveY to task for criticizing
> Lisp from a position of ignorance?
Yes.
>> 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?
No.
>> 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.
Richard Gabriel has a very good analysis in his book "Patterns of
Software" of what makes a programming language successful or not. They
have analyzed past languages and their model seemed to work well for
those, and it was actually a good prediction for Java's success. (The
book was written before the advent of Java.)