Someone's got to write rebuttal
Ivan Shvedunov
http://steve-yegge.blogspot.com/2006/04/lisp-is-not-acceptable-lisp.html
There may be some valid points, but IMO not all of the points made are
valid. Unfortunatelly this article has potential of being widely used as
a reason not to touch CL at all. I'm not considering myself experienced
enough to write a proper rebuttal piece, but I think someone needs to do it.
Ivan
Eli Bendersky
Since you raise this topic in such an original way, it would be curious
to know first which points don't *you* agree with ?
Respectfully,
Eli
Ivan Shvedunov
(anonymous, forgot to sign :) comment here:
--
Mentioned valid points:
* case insensitivity may cause headaches sometimes;
* non-generic sequence functions (this can be fixed to some degree
though if you really need them).
Not mentioned - the actual problem with macros (difficulties
implementing code walkers) and others (you need to learn CL first to
properly understand most of them :)
Maybe I've missed something.
Most of other stuff is something you actually have in your head after a
year of learning CL. "Lisp is not something like My Previous Favorite
Language(s)" kind of stuff etc. It may take a lot of time to explain
this properly, I'll just mention one point now:
> Every single non-standard extension, everything not in the spec, is
"wrong" with Common Lisp. This includes any support for threads,
filesystem access, processes and IPC, operating system interoperability,
a GUI, Unicode, and the long list of other features missing from the
latest hyperspec.
The spec is actually a copy of language standard (ANSI X3.226-1994). For
languages that don't have standard the spec is NIL. So everything not in
spec of Ruby (Python) is wrong with Ruby => everything with wrong with
Ruby (Python), right? Not just threads, IPC, GUI? Moreover, there's no
threads/IPC/GUI/etc. in standards of such successful languages as C and C++.
Additional note concerning case insensitiveness: one should note that
it's default Lisp reader mode in CL which is case insensitive unless
symbols are escaped. Lisp symbol names themselves are case-sensitive.
Alan Manuel K. Gloria
out which lisp is good to use (some people have e-mailed me the
equivalent of "whichever you can run that has the features you need").
Also, the lack of standardized threads, sockets, etc. has been
heartbreaking (but some of the trivial-* libraries have taken up the
slack).
#3 and #4 seem to be rather... foo. Dunno, it looks like he doesn't
know macros that much, or was using them incorrectly. Macros are only
supposed to make things look prettier and/or do the equivalent of
constant folding (a la CL-PPCRE). I know CLOS was first
designed/tested as a set of macros, but IIRC when the final specs came
out CLOS already had to be built-in (because primitives began to have
types).
Rainer Joswig
<almk...@gmail.com> in
1145095708.9...@i40g2000cwc.googlegroups.com:
> I know CLOS was first
> designed/tested as a set of macros
Who told you that? That's confused and wrong.
CLOS is not a set of macros. And it was never. It was never intended that
way and it was not where it came from.
If you want to know how the first reference implementation got developed,
then look for the old PCL (Portable Common Loops) sources. CLOS was a merge
of ideas from New Flavors and LOOPS. PCL got developed out of Xerox'
implementation of Common LOOPS. Common LOOPS was an implementation
of LOOPS (Lisp Object-Oriented Programming System) for the old
Common Lisp of that time.
See also ["CommonLoops: Merging Lisp and Object-Oriented Programming", D.G.
Bobrow et al, SIGPLAN Notices 21(11):17-29 (Nov 1986)].
If you want to understand the background behind the design of CLOS then read
The Art of the Meta-Object Protocol. Alan Kay on this book (keynote OOPSLA
97): The Art of the Metaobject Protocol is the best book written in
computing in ten years.
Also this page contains excellent material about CLOS:
http://www.dreamsongs.com/CLOS.html
Highly recommended - You only have to read it...
Pascal Costanza
> I kind of agree with Stevey's #1 and #2. I've been trying to figure
> out which lisp is good to use (some people have e-mailed me the
> equivalent of "whichever you can run that has the features you need").
> Also, the lack of standardized threads, sockets, etc. has been
> heartbreaking (but some of the trivial-* libraries have taken up the
> slack).
Don't you think that the differencen to questions like the following is
only gradual:
- Which scripting language is good to use?
- Which programming language is good to use?
Do you think there is a fundamental difference in choosing between one
of the different Common Lisp or Scheme implementations and choosing
between one of Perl/Python/Ruby/PHP/whatever? Or Java or C#? Or JDK 1.3,
JDK 1.4 or JDK 1.5?
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
Pascal Bourguignon
I'm afraid to say, there's not one valid point in this blog, most of
his points are just plain wrong.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"You question the worthiness of my code? I should kill you where you
stand!"
Peter Seibel
Well, since Pascal C had already taken the high road, providing a
reasoned, rational response, I took the quick hit approach.
-Peter
--
Peter Seibel * pe...@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
Phil! Gregory
> Do you think there is a fundamental difference in choosing between one
> of the different Common Lisp or Scheme implementations and choosing
> between one of Perl/Python/Ruby/PHP/whatever?
Perhaps there's not a fundamental difference, but there's a perceptual
difference, I think. Perl, Python, and Ruby are indeed all scripting
languages, but they're obviously different languages, so they're obviously
different to the programmer who's choosing among them. Choosing between
languages is something that most programmers are used to, one way or
another. On the other hand, when a programmer decides, "Okay, I'm going
to go see what Common Lisp is all about," after making that familiar
decision about language, he then has to make another decision about the
implementation, but there's the catch-22 that it helps to already know the
language in order to discriminate between the significant differences in
the implementations.
Practically speaking, of course, newcomers to the language can to a large
degree just download any implementation and start using it, but I don't
think it's always obvious that that's the case. (In a way, this reminds
my of the way Lisp affected my programming when I was first learning it.
There's this sense of "I can do *anything*, so I have no idea where to
start.")
Relatedly, see Bill Clementson's recent blog post about "The Best Open
Source CL Implementation" where he awards that distinction to SBCL.
> Or JDK 1.3, JDK 1.4 or JDK 1.5?
This, I think, is a closer example, but it's still not exactly the same,
because the numbering gives a sense of structure. In absence of any other
obvious criteria, a new-to-Java programmer would probably just go with the
most recent version.
Wade Humeniuk
Nothing to see here, move along. Just some crazy drunk guy hit a dog
while combing his hair in a mirror. Move along.
Wade
Pascal Bourguignon
> * Pascal Costanza <p...@p-cos.net> [Sat, 15 Apr 2006 13:15:54 +0200]:
>> Do you think there is a fundamental difference in choosing between one
>> of the different Common Lisp or Scheme implementations and choosing
>> between one of Perl/Python/Ruby/PHP/whatever?
>
> Perhaps there's not a fundamental difference, but there's a perceptual
> difference, I think. Perl, Python, and Ruby are indeed all scripting
> languages, but they're obviously different languages, so they're obviously
> different to the programmer who's choosing among them. Choosing between
> languages is something that most programmers are used to, one way or
> another. On the other hand, when a programmer decides, "Okay, I'm going
> to go see what Common Lisp is all about," after making that familiar
> decision about language, he then has to make another decision about the
> implementation, but there's the catch-22 that it helps to already know the
> language in order to discriminate between the significant differences in
> the implementations.
Of course, this was not the question. The question is why should they
take against Common Lisp (the language) the choice users are given
between various implementations such as sbcl, cmucl, openmcl, clisp,
abcl, and perhaps a couple more, etc, but nobody takes it against C,
that users have to choose between: Sun Studio Compiler, OnBoard Suite,
Free Microsoft Visual C++ 2005 Express, Free Microsoft eMbedded Visual
C++, OpenWatcom C Compiler, Mingw32 C Compiler, Digital Mars C
Compiler, Intel C++ Compiler for Linux Non-Commercial Version, Borland
C++ Compiler, Apple's Macintosh Programmer's Workshop C compiler, UPS
Debugger (C Interpreter), HP-GCC, The BDS C Compiler, Cyclone C,
TenDRA C Compiler, GNU C, EGCS, Pelles C Compiler, Compaq C Compiler,
Ch Embeddable CInterpreter, DJGPP C Compilers, Reads51 Small C
Cross-Compiler, Cilk ANSI C Based Compiler, ANYC C Compiler, Sphinx
C-- Compiler, LSI C-86 C Compiler, ACC C Compiler, CINT C Interpreter,
SDCC C Cross-compiler, CC386 C Compiler, CC65 C Cross-Compiler, eC,
LCC, Pacific C Compiler, ATTOC C Compiler, Quincy C Interpreter, and
RSXNT C.
--
__Pascal_Bourguignon__ _ Software patents are endangering
() ASCII ribbon against html email (o_ the computer industry all around
/\ 1962:DO20I=1.100 //\ the world http://lpf.ai.mit.edu/
2001:my($f)=`fortune`; V_/ http://petition.eurolinux.org/
Cor Gest
wrote this mindboggling stuff:
(selectively-snipped-or-not-p)
> Phil! Gregory <phi...@pobox.com> writes:
>
> > * Pascal Costanza <p...@p-cos.net> [Sat, 15 Apr 2006 13:15:54 +0200]:
> >> Do you think there is a fundamental difference in choosing between one
> >> of the different Common Lisp or Scheme implementations and choosing
> >> between one of Perl/Python/Ruby/PHP/whatever?
> >
> > Perhaps there's not a fundamental difference, but there's a perceptual
> > difference, I think. Perl, Python, and Ruby are indeed all scripting
> > languages, but they're obviously different languages, so they're obviously
> > different to the programmer who's choosing among them. Choosing between
> > languages is something that most programmers are used to, one way or
> > another. On the other hand, when a programmer decides, "Okay, I'm going
> > to go see what Common Lisp is all about," after making that familiar
> > decision about language, he then has to make another decision about the
> > implementation, but there's the catch-22 that it helps to already know the
> > language in order to discriminate between the significant differences in
> > the implementations.
>
> Of course, this was not the question. The question is why should they
> take against Common Lisp (the language) the choice users are given
> between various implementations such as sbcl, cmucl, openmcl, clisp,
> abcl, and perhaps a couple more, etc, but nobody takes it against C,
> that users have to choose between:
They dont know the compiler from the source ...
Oand let's not forget the lyrics from Lex/Flex Yacc/Bison,
to do the nasty ...
to complete the whining song.
Cor
--
I do NOT use any Windows(TM) products, therefore
I do NOT fear mail from strangers http://www.clsnet.nl/mail.html
If everything else failed to satisfy you, try reading The Frign' Manual
(defvar My-Computer '((OS . "GNU/Emacs") (IPL . "GNU/Linux")))
Ken Tilton
Peter Seibel wrote:
> Ivan Shvedunov <iva...@depni.sinp.msu.ru> writes:
>
>
>>The following showed up on Reddit recently:
>>http://steve-yegge.blogspot.com/2006/04/lisp-is-not-acceptable-lisp.html
>>
>>There may be some valid points, but IMO not all of the points made are
>>valid. Unfortunatelly this article has potential of being widely used
>>as a reason not to touch CL at all. I'm not considering myself
>>experienced enough to write a proper rebuttal piece, but I think
>>someone needs to do it.
>
>
> Well, since Pascal C had already taken the high road, providing a
> reasoned, rational response, I took the quick hit approach.
No, that is not how these Good Bad Publicity things work. And more Lisp
newbies means more book sales, so get back in there. For me, more
Lispniks means more competition as a commercial vendor, so I am on
Steve's side. And responding to all of his mistakes would mean hours not
spent on my app.
The way these things work is some idiot gets a microphone and goes nuts.
Then reasonable folks shred him (it's always a him, according to
Dilbert) in incredible detail. The idiot responds to the exactly one
thing he think can be answered, or makes up new nonsense. the
well-informed Defenders of Lisp stay reasonable and just keep talking
about great things about lisp, and do not get sucked into silly
tit-for-tat.
in the end the idiot hates Lisp even more, but anyone reading the
exchange has a lot more information to use in making up their own mind.
hth, 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
Ivan Shvedunov wrote:
> The following showed up on Reddit recently:
> http://steve-yegge.blogspot.com/2006/04/lisp-is-not-acceptable-lisp.html
>
> There may be some valid points, ...
Oh, I missed those. :) Case sensitivity? You have two variables with the
same spelling but use case difference to specify the one you want? Stop
that.
> but IMO not all of the points made are
> valid. Unfortunatelly this article has potential of being widely used as
> a reason not to touch CL at all.
...by exactly the kind of people we do not want around here.
> I'm not considering myself experienced
> enough to write a proper rebuttal piece, but I think someone needs to do
> it.
No excuses. I see you replied a little. Get back in there and make some
noise. The noise is the only thing that matters, draws a crowd.
Ivan Shvedunov
>
>
> Ivan Shvedunov wrote:
>
>> The following showed up on Reddit recently:
>> http://steve-yegge.blogspot.com/2006/04/lisp-is-not-acceptable-lisp.html
>>
>> There may be some valid points, ...
>
>
> Oh, I missed those. :) Case sensitivity? You have two variables with the
> same spelling but use case difference to specify the one you want? Stop
> that.
Well, there's a problem with surrounding environment. E.g. when you need
to generate some XML/JavaScript/whatever from sexprs, stuff like
|EscapingThatPareditIsNotQuiteHappyWith| or something-like-this ->
SomethingLikeThis quirks. Not terribly bad, but sometimes unpleasant.
>> but IMO not all of the points made are valid. Unfortunatelly this
>> article has potential of being widely used as a reason not to touch CL
>> at all.
>
>
> ...by exactly the kind of people we do not want around here.
>
>> I'm not considering myself experienced enough to write a proper
>> rebuttal piece, but I think someone needs to do it.
>
>
> No excuses. I see you replied a little. Get back in there and make some
> noise. The noise is the only thing that matters, draws a crowd.
I've honestly tried to write some comments on reddit... But article's
score still went to stratosphere, and many of my comments were
downvoted. It's all percieved as "lisp weenie whining" or
manifestations of "superiority and persecution complexes" most of time.
Ivan
Ken Tilton
Ivan Shvedunov wrote:
> Ken Tilton wrote:
>> No excuses. I see you replied a little. Get back in there and make
>> some noise. The noise is the only thing that matters, draws a crowd.
>
>
> I've honestly tried to write some comments on reddit... But article's
> score still went to stratosphere, and many of my comments were
> downvoted. It's all percieved as "lisp weenie whining" or
> manifestations of "superiority and persecution complexes" most of time.
That's OK. Look past the trees to the forest. Lisp is now part of The
Debate. C++ and Java are not. It is down to Python, Ruby, and <gasp>
Common Lisp. To the old-timers, that alone is a win.
And anyone who /really/ likes CL looks at a Python-Ruby-CL "Final Three"
showdown and realizes, oh, game over.
ken
ps. Steve says "You've all read about the Road to Lisp.", linking to the
wiki survey. I missed the news. Did that get publicized someplace? k
Benjamin Teuber
(had a good lough about the "I can't make a gf called length" lie).
He also doesn't understand anything about macros - needless to mention
here...
But I would agree that although cl is by far the best thing that exists
(actually I'm not sure about cl vs. Scheme yet...), an even nicer Lisp
could be dreamed of - at least I'm dreaming about it :)
The good news is that most improvements to cl can be done from cl...
Barry Margolin
Ken Tilton <kent...@gmail.com> wrote:
> Ivan Shvedunov wrote:
> > The following showed up on Reddit recently:
> > http://steve-yegge.blogspot.com/2006/04/lisp-is-not-acceptable-lisp.html
> >
> > There may be some valid points, ...
>
> Oh, I missed those. :) Case sensitivity? You have two variables with the
> same spelling but use case difference to specify the one you want? Stop
> that.
I suspect the case-sensitivity thing that tends to catch newbies is
(intern "car") not doing what they expect. CL seems to be
case-insensitive, because you can type in any case, but functions like
INTERN and MAKE-SYMBOL expose the underlying case-sensitivity and the
fact that this is just a user interface trick.
--
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 ***
Tim X
You raised two very valid points. The initial selection of a lisp
implementation is largely irrelevant because at the learning stage,
all of them are pretty much equivalent. Its only when ou get to the
point of writing a real app which you want to run on multiple
platforms and possibly sell for money you really need to worry about
the idifferenses. Most people new to lisp will take a fair while
before they get to this point (if ever).
The other point you mention is probably the most critical and that is
your reference to being able to do anything and therefore not quite
knowing how to start. I think this is probably the most challenging
part of learning lisp. Its very quick and easy to get the basics down,
but getting to the point of mastering the language and really being
able to take advantage of its strenghts is *much* harder.
To some extent, this is possibly the major stumbling block and part of
why Peter's PCL is so popular. With languages like java, you can do
quite trivial things which look impressive very early in the learning
process. With lisp, its a bit harder. However, with languages like
Java, I found you 'hit the wall' fairly quickly. After a short time,
you know the language and what you can and cannot do with ease and
quickly recognise its limitations. Your ideas and design are quickly
limited by the language. Your designs are constrained by what you know
you can do easily.
With lisp, that wall is a lot further away. You spend a lot more time
with a little voice in the back of your head saying "Is this really
the best/right/efficient way to solve this problem" because there are
less constraints. In fact, it soon becomes evident the main constraint
is the programmers ability and skill rather than the language. Many
programmers find this an uncomfortable and confronting place. More
often than not, they run away from it and end up blaming the language
because thats better for their ego.
I quite enjoy seeing blogs like the one referenced in this thread. The
way I see it is that it confirms Lisp has something really unique to
offer. If the language was truely as poor as posts like this claim,
why do so many feel a need to criticise it. After all, if it is that
bad, surely it will just die a natural death in the long term.
Basically, I don't think people attack things unless they see them as
a threat.
To some extent, it is possible one of the reasons Lisp isn't gaining
even more support isn't due to a lack of a single canonical
implementation, network libraries or easy to use GUI toolkits. Rather,
it is a sign of how trivial most of what people are coding really is.
These are well understood problem domains and all the major languages
are quite adequate in dealing with them. Over the last 20 years, I've
seen quite a change in what programmers are doing and to a large
extent, most of it seems quite trivial compared to the majority of
problems being worked on 20 years ago. Lets face it, web apps,
database apps and transaction processing are where the majority of
programmers are working and all of these problems can be approached
quite adequately with any of the popular languages. However, when you
start to look at systems which are being more innovative, introducing
new development paradigms and attempting to solve difficult problems,
it seems you see a higher proportion of lisp derived languages.
Tim
--
tcross (at) rapttech dot com dot au
Jeffery Zhang
Yeah, just today I was thinking of how I can implement re-entrant
continuations in CL. Haven't figured out a good solution yet but it'd be
convenient to have.
Ron Garret
Jeffery Zhang <jz...@cornell.edu> wrote:
Or how to change the semantics of function calls so that top-level
functions are looked up in global lexical environments/modules/lexicons.
Or to make this syntax work:
((function-returning-a-function) ...)
rg
psch...@uci.edu
>> continuations in CL. Haven't figured out a good solution yet but it'd be
>> convenient to have.
> Or how to change the semantics of function calls so that top-level
> functions are looked up in global lexical environments/modules/lexicons.
>Or to make this syntax work:
> ((function-returning-a-function) ...)
you mean you want to use Scheme, so why not use Scheme? why try to hack
CL to be Scheme?
Ron Garret
psch...@uci.edu wrote:
> >> Yeah, just today I was thinking of how I can implement re-entrant
> >> continuations in CL. Haven't figured out a good solution yet but it'd be
> >> convenient to have.
>
> > Or how to change the semantics of function calls so that top-level
> > functions are looked up in global lexical environments/modules/lexicons.
>
> >Or to make this syntax work:
>
> > ((function-returning-a-function) ...)
>
> you mean you want to use Scheme
No, I do not mean that.
> so why not use Scheme? why try to hack
> CL to be Scheme?
Because I don't want to use Scheme. I want to extend CL to mimic one
aspect of Scheme's semantics. This is not the same thing as wanting to
use Scheme.
rg
Robert Uhl
>
>> The following showed up on Reddit recently:
>> http://steve-yegge.blogspot.com/2006/04/lisp-is-not-acceptable-lisp.html
>> There may be some valid points, ...
>
> Oh, I missed those. :) Case sensitivity? You have two variables with
> the same spelling but use case difference to specify the one you want?
> Stop that.
Oh, I dunno--I think that it'd be great if the sequence functions were
generic. In fact, nowadays I'd make _all_ functions generic. Although
I daresay that there are pitfalls to that which I can't foresee...
--
Robert Uhl <http://public.xdi.org/=ruhl>
`Courage is not the absence of fear, but rather the judgement that
something else is more important than fear.'
Förster vom Silberwald
Ivan Shvedunov wrote:
> The following showed up on Reddit recently:
> http://steve-yegge.blogspot.com/2006/04/lisp-is-not-acceptable-lisp.html
Thanks for the blog pointer. I am one of the last persons on earth
defending Lisp. However, it is also one of the silliest blogs out
there. The blogger raised a problem where there is no problem (okay, I
would write the same silly things about shit Python and useless
Fortran).
May I cite the appropiate answer to the blog:
==
John Foderaro said...
Your blog post shows a profound ignorance of Lisp. It reminds me of
FOX news. That so-called news program has been successful by telling a
target audience (the people in the red states) just what they want to
hear instead of the truth. The weak minded love to be told they are
right rather than being challenged with the reality. It makes them very
loyal. Likewise there are people who may have dabbled in Lisp but never
understood it and maybe this made them feel a bit stupid. Now you come
out and tell them that "you're not stupid, Lisp is just badly
designed". I'm sure you'll get a loyal following of people who now
quote your bogus posting as if it is evidence itself, when it simply
garbage.
==
Schneewittchen
C Y
I think Problem #1, about the difficulty of selecting from multiple
implementations, is probably true to some extent. I know you could
treat each implementation as its own language and ignore the others,
but the temptation to not do that is overpowering. They're all lisps,
darn it - why can't I have feature X in environment Y? I'm sure we
have all done that at least once. I think as the various platforms
strive for ANSI (GCL in particular) we will move closer to this ideal,
but there are some fundamental limits involved with different efforts
doing different things, or the same things in different ways - it looks
like a fragmentation of effort to new users. Python and friends
essentially are themselves "de-facto" standards by being unique
implementations, and sidestep the issue altogether. C and C++
compilers sometimes see the "different implementations" problems, but
since GCC rules the open source roost there is (again "de-facto") no
problem for most of the developers who might find their way to the free
Lisp community. Lisp is in something of a unique situation with
multiple viable implementations which are also freely available. This
is probably a good thing, even if it does look like fragmentation, but
it will be confusing. It might be less so if point #2 weren't correct.
OK, it's not correct - the spec is NOT worthless. However, it COULD be
a lot more worthwhile. Lisp, because of its having multiple viable
implementations, benefits FAR more from agreed upon standards than most
languages do. In most languages, one or two implementations dominate
and become spec-de-facto, sometimes overshadowing the spec-de-jure if
it exists. Lisp has a spec-de-jure, and no lisp implementation is
strong enough to be spec-de-facto. This means that proponents and
developers of the language do not center in and improve one
implementation of the language, but split their efforts over many. No
problem - free software is like that, and it allows for experimentation
and creativity (lord knows the world needs more of both.) However, the
features that will be most widely used and most useful (let's face it,
no one programs in isolation) are features that are common to all.
Using one lisp for a unique feature requires a commitment and an
abandonment of other features in other environments, and we would
prefer not to do that. In some cases, we can even all agree about the
best form a general solution could take. If not immediately,
experimentation over time produces results and merges toward a "good"
design. But EVEN IF WE AGREE, the spec is virtually set in stone. The
NCITS/J13 committee (http://www.franz.com/~smh/J13/) no longer has
enough active members to put through changes. There is no community
process for an informal spec which has achieved real "legitimacy", at
least not yet. The status of the draft spec documents, surely the best
starting point for informal improvements, is unclear. This is a
problem, and in particularl for Lisp, because we really NEED the
de-jure standards. We have no de-facto standard, and I doubt any of us
want one. But that means the de-jure standard assumes a much more
critical roll, and it is important to be able to update and add to the
spec as issues reach enough of a concensus. If we could have some kind
of agreeded upon standard for FFI, sockets, graphics, and maybe one or
two other common problems Lisp faces in a mondern computational
environment we would probably see a lot less of this kind of
discussion. I grant that whether or not we are ready to propose
standards for those things, even non-ANSI informal ones, is something
else again. But when we ARE ready an update of the spec-de-jure and
uniform compliance by the various lisps would be a big, big, big help,
IMHO anyway.
Cheers,
CY
Förster vom Silberwald
C Y wrote:
Lisp is in something of a unique situation with
> multiple viable implementations which are also freely available. This
> is probably a good thing, even if it does look like fragmentation, but
> it will be confusing. It might be less so if point #2 weren't correct.
I have to be to differ. Fortran is the prime example that there is a
standard but every larger and complex program (especially climate
models) need exactly that particular Fortran compiler on that
particular workstation.
Surely, most of the problems relating larger Fortran programs come from
the fact that they use some specific architecture dependent features
especially on workstation.
However, there is no such thing as to use your large Fortran program on
your Fortran compiler of your choice.
Schneewittchen
C Y
situation was a bit lacking, but I didn't know the situation was so
constrained in general.
Anyway, the point remains that a proper spec-de-jure and the use of
that spec is important when there are multiple competing
implementations of a language in wide use. Indeed, situations like the
current Lisp one and Fortran just provide more proof of that. What to
do about not having a good situation is a different question, but the
point remains.
Holger Schauer
> Of course, this was not the question. The question is why should they
> take against Common Lisp (the language) the choice users are given
> between various implementations such as sbcl, cmucl, openmcl, clisp,
> abcl, and perhaps a couple more, etc, but nobody takes it against C,
Actually, I have seen several such complaints in the past, mainly
accompanied by claims such as 'Portable C isn't portable'.
Holger
--
--- http://www.coling.uni-freiburg.de/~schauer/ ---
Fachbegriffe der Informatik - Einfach erklärt
25: Multithreaded
Wir mußten ein Flußdiagramm malen, um es zu debuggen.
(Kristian Köhntopp)
beli...@aol.com
> C Y wrote:
> Lisp is in something of a unique situation with
> > multiple viable implementations which are also freely available. This
> > is probably a good thing, even if it does look like fragmentation, but
> > it will be confusing. It might be less so if point #2 weren't correct.
>
> I have to be to differ. Fortran is the prime example that there is a
> standard but every larger and complex program (especially climate
> models) need exactly that particular Fortran compiler on that
> particular workstation.
I disagree with the "every". There have been several Fortran standards,
Fortran 77, 90, 95, and now 2003, and several Fortran 95 compilers
exist, including free ones g95 and gfortran. G95 probably became a
mature Fortran 95 compiler only in 2005, but it is able to compile many
production codes, listed at http://www.g95.org/g95_status.html , that
were developed earlier, using other compilers and on various platforms.
Probably the vast majority of the Fortran code that has been written
has been in Fortran 77 or an earlier version, and such codes do use
extensions, because F77 lacks (for example)
(1) user-defined types
(2) dynamic memory allocation
(3) pointers
(4) interoperability with C
(5) command line arguments
Fortran 77 compiler vendors often had not-quite-compatible extensions
to address these needs. Fortran 95 addresses the first three points,
and Fortran 2003 the next two. As Fortran has evolved, it has become
easier for a large production code to be standard-conforming, and this
ability is something that drives new standards.
Förster vom Silberwald
> Fortran 77 compiler vendors often had not-quite-compatible extensions
> to address these needs. Fortran 95 addresses the first three points,
> and Fortran 2003 the next two. As Fortran has evolved, it has become
> easier for a large production code to be standard-conforming, and this
> ability is something that drives new standards.
I must confess: I am really not representative for criticisms relating
Fortran. I often try hard not to use Fortran (this means freedom for
me).
I must also state that typical F77 programs are not that bad and most
of the time they work out of the box.
However, I made also the experience that some more complex and delicate
Fortran codes needed always some particular compiler.
Personally I think Fortran is a waste of time (for me) and a disservice
to the scientific community (yes, yes there are the climate models and
even during my PhD it happend that I had to steer by means of Bigloo
some external important Fortran code of radiative transfer through the
Earth's atmosphere ).
The g95 project is a good idea though. Once every important platform
runs g95 just like it is the case with gcc the world will become much
easier to cope with. g95 will make sure that one has not to learn
Fortran anymore since a lot of programs will run out of the box then
on every platform and one has not to fiddle around with Fortran code to
meet his specific Fortran compiler.
Schneewittchen