How to get a wider audience for CL
Pascal Costanza
As most of you surely know by now I am still quite new to CL. Therefore
I have gained some knowledge about the unnecessary barriers to learning
CL from first-hand experience.
Now here are some of my thoughts about what could help or, in my
opinion, what is in fact needed to have CL reach a wider audience again.
In my opinion, you have to have some kind of "definitive" resource for a
language where you can find a complete and consistent definition. For
example for Java, this is the Java Language Specification and the Java
API documentation. My conjecture is that all successful languages have
these kind of definitive resources. (However, I haven't taken time yet
to collect evidence for this.)
CLtL2 and the ANSI specs are often pointed to as the definitive
resources. However, there are some drawbacks. 1) This is always
accompanied by cautions that CLtL2 is different from ANSI to some
extent. This is confusing for newbies because it consumes too much time
to figure out what this actually means. 2) Both are hard to read, for
different reasons: The ANSI specs doesn't provide rationales so you
can't understand the specifications if you haven't got an idea about the
topics upfront. CLtL2 is generally easier to understand, but your mind
has already switch to a "be careful" mode when reading because things
_might_ be different in ANSI CL. Furthermore, the deprecated sections
are highly confusing: first of all, a newbie (me, at least) doesn't care
at all wheter someone from a XJYIZ committee voted for this and that (I
am intentionally exaggerating here); this is (probably still)
interesting for historical reasons but not when you actually want to
learn the language. More often than not you try hard to understand a
complicated section, just to read that you can forget about it two
paragraphs later. This is very frustrating.
So what's needed is the following: CLtL2 and the ANSI specs should be
refactored into a single coherent document, with all the deprecated
stuff eliminated (including, for example, the appendices about "series"
and so on) in order to reflect the current state of affairs with useful
rationale, _and nothing more_. The ANSI glossary should be left in
because it is also quite useful. (We could use "CLtL3" as a working
title for such a refactoring?)
This already would mean a lot of work but would pay off in the long run
for the CL community.
As a next step, new material could be added to reflect more recent
de-facto standards, like the MOP, CLIM and so on. Perhaps this could be
a community-driven process, by some kind of "request for appendices". I
don't know.
What do you think?
Pascal
P.S.: Perhaps you need this background information: usually, I don't
read tutorials or introductions to languages on a tutorial level. I
highly prefer to learn languages from their specifications.
--
Pascal Costanza University of Bonn
mailto:cost...@web.de Institute of Computer Science III
http://www.pascalcostanza.de Römerstr. 164, D-53117 Bonn (Germany)
Friedrich Dominicus
> Hi,
>
> As most of you surely know by now I am still quite new to CL. Therefore
> I have gained some knowledge about the unnecessary barriers to learning
> CL from first-hand experience.
>
> Now here are some of my thoughts about what could help or, in my
> opinion, what is in fact needed to have CL reach a wider audience again.
>
> In my opinion, you have to have some kind of "definitive" resource for a
> language where you can find a complete and consistent definition.
The definitive guide is the Hyperspec. What more do you want? No one
has pointed out to use the CLtL2 as the specs.
> For
> example for Java, this is the Java Language Specification and the Java
> API documentation. My conjecture is that all successful languages have
> these kind of definitive resources. (However, I haven't taken time yet
> to collect evidence for this.)
>
> CLtL2 and the ANSI specs are often pointed to as the definitive
> resources.
that is hardly true and even in CLtL2 is is stated explicitly that
this is a document on the way to the specification.
In short I disagree, BTW how many people may know or have the ANSI
C specification? It's the definitive guide and you can buy it, but how
many do?
The Hyperspec is simply there you even do not have to pay for it.
Regards
Friedrich
Takehiko Abe
> So what's needed is the following: CLtL2 and the ANSI specs should be
> refactored into a single coherent document, [...]
I think that the single coherent document you're looking for is the
ANSI spec. The large portion of the original text of CLtL2 is taken
to the ANSI spec with all the confusing 'X3J13 voteed in ...' parts
dropped. The organization of the document is different from that of
CLtL2, and I found it better and easier to read than CLtL2.
And we have HyperSpec!
--
This message was not sent to you unsolicited.
Andreas Hinze
> As a next step, new material could be added to reflect more recent
> de-facto standards, like the MOP, CLIM and so on. Perhaps this could be
> a community-driven process, by some kind of "request for appendices". I
> don't know.
>
from yesterday and today. There i asked a question about activity in J13.
Kent Pitman and Christopher Brown wrote some interesting thinks about
the problems with ANSI spec changes.
Best
AHz
Barry Margolin
Pascal Costanza <cost...@web.de> wrote:
>CLtL2 and the ANSI specs are often pointed to as the definitive
>resources. However, there are some drawbacks. 1) This is always
>accompanied by cautions that CLtL2 is different from ANSI to some
>extent. This is confusing for newbies because it consumes too much time
>to figure out what this actually means.
IMHO, this warning is overblown. The differences between the language
described in CLTL2 and the ANSI spec are very few, and mostly in parts of
the language that beginners are very unlikely to encounter. It's important
to be cognizant of the differences when having detailed discussions of the
language in forums like this, but I find that CLTL2 is just as good as a
learning guide and quick reference, and I still find it more convenient to
work with a real book.
I can't recall the last time a question came up in this newsgroup where the
answer wasn't the same in the two references, just worded slightly
differently.
>So what's needed is the following: CLtL2 and the ANSI specs should be
>refactored into a single coherent document
What's need, then, is a volunteer to write CLTL3. If anyone were really
interested, I think it would have happened by now.
The ANSI specification is already over 1,000 pages long. Adding in
"user-friendly" stuff like rationales would make it even more unweildy. I
don't think one document can be both the precise specification and the
user-friendly explanation of the language -- that's too much to ask of one
text if you want it to be of a manageable size.
>P.S.: Perhaps you need this background information: usually, I don't
>read tutorials or introductions to languages on a tutorial level. I
>highly prefer to learn languages from their specifications.
Do you think you're typical? If not, how would doing something for you
"get a wider audience"?
I think most programmers make more use of textbooks and tutorials than the
official specifications.
--
Barry Margolin, bar...@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Christophe Rhodes
> In article <3D6CE6F9...@cs.uni-bonn.de>,
> Pascal Costanza <cost...@web.de> wrote:
> >CLtL2 and the ANSI specs are often pointed to as the definitive
> >resources. However, there are some drawbacks. 1) This is always
> >accompanied by cautions that CLtL2 is different from ANSI to some
> >extent. This is confusing for newbies because it consumes too much time
> >to figure out what this actually means.
>
> IMHO, this warning is overblown. The differences between the language
> described in CLTL2 and the ANSI spec are very few, and mostly in parts of
> the language that beginners are very unlikely to encounter. It's important
> to be cognizant of the differences when having detailed discussions of the
> language in forums like this, but I find that CLTL2 is just as good as a
> learning guide and quick reference, and I still find it more convenient to
> work with a real book.
>
> I can't recall the last time a question came up in this newsgroup where the
> answer wasn't the same in the two references, just worded slightly
> differently.
READ-SEQUENCE and WRITE-SEQUENCE aren't in CLTL2... and I remember,
though admittedly not terribly recently, questions about doing stream
IO more efficiently than with a loop around READ-/WRITE-BYTE.
Cheers,
Christophe
--
Jesus College, Cambridge, CB5 8BL +44 1223 510 299
http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)
Kaz Kylheku
> Hi,
>
> As most of you surely know by now I am still quite new to CL. Therefore
> I have gained some knowledge about the unnecessary barriers to learning
> CL from first-hand experience.
>
> Now here are some of my thoughts about what could help or, in my
> opinion, what is in fact needed to have CL reach a wider audience again.
>
> In my opinion, you have to have some kind of "definitive" resource for a
> language where you can find a complete and consistent definition. For
> example for Java, this is the Java Language Specification and the Java
> API documentation. My conjecture is that all successful languages have
> these kind of definitive resources. (However, I haven't taken time yet
> to collect evidence for this.)
>
> CLtL2 and the ANSI specs are often pointed to as the definitive
> resources. However, there are some drawbacks. 1) This is always
> accompanied by cautions that CLtL2 is different from ANSI to some
> extent.
This is a nice way of saying ``forget about cltl2''. The cltl2 is
to the Lisp world what K&R2 is to C. It's a nice book, but it differs
from ANSI C 89, and does not define the language, even though it's
predecessor was a base document for the standard.
As others have pointed out, the ANSI Lisp specification can be downloaded
or read online in a form called The Common Lisp HyperSpec, courtesy of Kent
Pitman.
I think you mistaken in your belief that the availability of a
language standard is somehow related to the popularity of a language.
Neither proceeds from the other.
C and C++ have ANSI/ISO standards, and most programmers who work
in these languages don't know that these documents even exist.
I wonder how many Java programmers actually know about the Java
Specification, versus how many rely on some 700 page
for dummies type book.
And then there are popular languages that have no specification
at all, other than the source code for their compiler or interpreter.
For example, Perl.
> This is confusing for newbies because it consumes too much time
> to figure out what this actually means. 2) Both are hard to read, for
Show me one programming language ANSI/ISO standard that is easy to read
for newbies.
> different reasons: The ANSI specs doesn't provide rationales so you
> can't understand the specifications if you haven't got an idea about the
> topics upfront.
I think that intelligent people can understand a specification without
requiring rationale. Rationale is for those who question the design
decisions described by the specification.
What assists learning is examples, and those are present.
Rationale is largely unnecessary because Lisp is a language that
does the right thing nearly everywhere. The answer to the question
``why is this done this way'' becomes obvious when you think
about it and use it.
Whereas other language specifications need rationales to explain or
apologize for their poor design decisions, kludges and hacks.
CLtL2 is generally easier to understand, but your mind
> has already switch to a "be careful" mode when reading because things
> _might_ be different in ANSI CL.
You would have to be in that same mode when reading any treatment
of the language other than the standard. Effectively, the cltl2
is just any other textbook about Lisp, except that it's formatted
as a detailed reference manual.
You might be better off with some textbook about Lisp programming.
Whatever constructs it teaches, look them up in the HyperSpec.
That way you learn about their detailed syntax with all its
variations, and spot any errors in the book.
> Furthermore, the deprecated sections
> are highly confusing: first of all, a newbie (me, at least) doesn't care
> at all wheter someone from a XJYIZ committee voted for this and that (I
> am intentionally exaggerating here); this is (probably still)
> interesting for historical reasons but not when you actually want to
> learn the language.
How does this give rise to confusion? Just skip it.
> More often than not you try hard to understand a
> complicated section, just to read that you can forget about it two
> paragraphs later. This is very frustrating.
Can you cite an example of this? It sounds like a defect.
Marc Spitzer
> Hi,
>
> As most of you surely know by now I am still quite new to CL. Therefore
> I have gained some knowledge about the unnecessary barriers to learning
> CL from first-hand experience.
>
> Now here are some of my thoughts about what could help or, in my
> opinion, what is in fact needed to have CL reach a wider audience again.
I honestly do not know if that is a good idea, heres why:
Cl is a tool that was built over several decades by exceptional people
for _exceptional people_.
Most programmers are not good, talented, properly educated people( as
programmers) and they are happy that way.
If you give these people cl they will not take the time to really
learn it. And they probably do not have the education to understand
it any way.
The way CL punishes these people and the companies that hire them. It
to allow them to write code that works, for some definition of works.
They only learn lists as data structures(etc.) and code accordingly.
You get real bad code that has the unfortunate side effect that it
"works". But the application fails and nobody is going to accept any
responsibility for the failure because the people who accept
responsibility for their work and the fact that it might have something
to do with the failure( perhaps I could have done something better)
get fired. So the language/compiler takes the hit.
Now if we could get more competent people involved then it would be a
big win.
marc
Erik Naggum
| BTW how many people may know or have the ANSI C specification? It's the
| definitive guide and you can buy it, but how many do?
It is available in PDF for USD 18.00 and should be on every C programmer's
disk. The same applies to the C++ standard. If you can't read the spec,
don't use the language.
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
Tim Bradshaw
> What's need, then, is a volunteer to write CLTL3. If anyone were
> really interested, I think it would have happened by now.
One thing that could be done would be to produce an `annotated
hyperspec'. I don't know how easy it is to do in practice but some
web browsers (amaya is one), let you define annotations on bits of web
pages. As far as I can see these can be stored in some central server
(which I think comes down to apache & mySQL and a few thousand
seething lines of perl), and can then be viewed by other people. This
would let people add explanatory commentaries - possibly quite large
ones - to things like the hyperspec, without ever touching it. I
guess a better approach would somehow be to view the spec through a
server which knew about all the annotations and added them in, so
ordinary browsers could see them. I expect there are millions of
implementations of things like this, all subtly broken.
The advantage of something like this is that it could be done
collaboratively. The disadvantage is basically the same - it would
likely end up as a mass of somewhat incoherent annotations, when what
is really needed, as you say, is a book. But books are so personally
expensive to write that I rather doubt any of the small number of
people who could write a definitive CL book would be able to justify
it.
--tim
Steve Long
<er...@naggum.no> wrote:
> * Friedrich Dominicus
> | BTW how many people may know or have the ANSI C specification? It's the
> | definitive guide and you can buy it, but how many do?
>
> It is available in PDF for USD 18.00 and should be on every C programmer's
> disk. The same applies to the C++ standard. If you can't read the spec,
> don't use the language.
I would add: If you can't read the spec don't ask me to debug your code.
sl
Adam Warner
> One thing that could be done would be to produce an `annotated
> hyperspec'.
...
It's a great idea Tim. What legal rights would we have to create such a
derived work? Would ANSI have to authorise it?
Regards,
Adam
Marc Spitzer
> * Barry Margolin wrote:
>
>> What's need, then, is a volunteer to write CLTL3. If anyone were
>> really interested, I think it would have happened by now.
>
> One thing that could be done would be to produce an `annotated
> hyperspec'. I don't know how easy it is to do in practice but some
> web browsers (amaya is one), let you define annotations on bits of web
> pages. As far as I can see these can be stored in some central server
> (which I think comes down to apache & mySQL and a few thousand
> seething lines of perl), and can then be viewed by other people. This
Well there are some alternatives to apache and especially mysql:
Database:
plob
firbird( was interbase)
sapdb
postgres
webserver
cl-httpd
alegroserv & portable alegroserve
aolserver
jetty
Application frameworks:
IMHO
openacs
enhydra
Now I personally have issues with mysql, the last time I looked
it was not ACID so I do not consider it a database. File system
with a SQL front end is more like it.
> would let people add explanatory commentaries - possibly quite large
> ones - to things like the hyperspec, without ever touching it. I
> guess a better approach would somehow be to view the spec through a
> server which knew about all the annotations and added them in, so
> ordinary browsers could see them. I expect there are millions of
> implementations of things like this, all subtly broken.
Take a look at openacs, it has that functionality out of the box
and a lot more stuff also(www.openacs.org). The comments get
appended to the end of the page.
>
> The advantage of something like this is that it could be done
> collaboratively. The disadvantage is basically the same - it would
> likely end up as a mass of somewhat incoherent annotations, when what
In openacs there are admins who can moderate part/all of the website.
just find some community minded person/people who are competent and let
them keep watch over there chunks. Perhaps a vendor might even
sponsor this work with time or funds.
> is really needed, as you say, is a book. But books are so personally
> expensive to write that I rather doubt any of the small number of
> people who could write a definitive CL book would be able to justify
> it.
Well the book exists, the ANSI standard. What happens when the new
book conflicts with the standard, the standard is right. 1 source
of truth for the definition of a technology is useful and the more
sources of truth there are the less useful they become. This applies
to defining a technology.
marc
>
> --tim
Marc Spitzer
Well if there was a comments only website, no ANSI material present
at all, you would have no infringement on ANSI property. You would
just need a link to the part of the standard you are commenting on
at the top of the page so you could read them side by side. Basically
shadow the hyperspec for comments.
marc
>
> Regards,
> Adam
Friedrich Dominicus
> * Friedrich Dominicus
> | BTW how many people may know or have the ANSI C specification? It's the
> | definitive guide and you can buy it, but how many do?
>
> It is available in PDF for USD 18.00 and should be on every C programmer's
> disk. The same applies to the C++ standard. If you can't read the spec,
> don't use the language.
I fully agree, just it's not what I found in lang.c groups. Well the
regulars know and act accordingly but the questions which are
definitly out of bound are the majority.
Regards
Friedrich
Raymond Wiker
Or even "If you can't read the spec, don't expect me to use your
libraries."
--
Raymond Wiker Mail: Raymon...@fast.no
Senior Software Engineer Web: http://www.fast.no/
Fast Search & Transfer ASA Phone: +47 23 01 11 60
P.O. Box 1677 Vika Fax: +47 35 54 87 99
NO-0120 Oslo, NORWAY Mob: +47 48 01 11 60
Try FAST Search: http://alltheweb.com/
Tim Bradshaw
> Well there are some alternatives to apache and especially mysql:
Yes, but the stuff that w3 support is apache, mysql and perl-based.
Obviously one could reimplement it all in, but it's probably just
easier to use what they have, if it works (I agree with you about
ACIDity, but this isn't the place to worry about that).
> Take a look at openacs, it has that functionality out of the box
> and a lot more stuff also(www.openacs.org). The comments get
> appended to the end of the page.
That looks like another such thing. This time in PHP I guess since
it's obviously a Greenspun thing.
> Well the book exists, the ANSI standard. What happens when the new
> book conflicts with the standard, the standard is right. 1 source
> of truth for the definition of a technology is useful and the more
> sources of truth there are the less useful they become. This applies
> to defining a technology.
I wasn't after another book which seeks to define CL.
--tim
Edi Weitz
> > Take a look at openacs, it has that functionality out of the box
> > and a lot more stuff also(www.openacs.org). The comments get
> > appended to the end of the page.
>
> That looks like another such thing. This time in PHP I guess since
> it's obviously a Greenspun thing.
It was Tcl orginally because it was based on AOLServer. After some
time they took the Java road and soon thereafter the VC guys kicked
Greenspun out of the company (and sold the remainders to Red Hat). You
can read the whole story on his website although it's surely biased.
Greenspun wrote a whole book about his ACS system
<http://www.amazon.com/exec/obidos/ASIN/1558605347> which is quite
entertaining although I can't agree with all of the stuff he's
writing. The book is available online at
<http://philip.greenspun.com/panda/>.
Edi.
Tim Bradshaw
> It was Tcl orginally because it was based on AOLServer. After some
> time they took the Java road and soon thereafter the VC guys kicked
> Greenspun out of the company (and sold the remainders to Red Hat).
yes, you are correct - he does stuff in TCL not PHP doesn't he. I get
this multiplicity of languages and enthusiasts confused.
> You can read the whole story on his website although it's surely
> biased.
I'm sure it is. Strange to think that all those dotcoms used to
seem so important once.
--tim
Marc Spitzer
> * Marc Spitzer wrote:
>
>> Well there are some alternatives to apache and especially mysql:
>
> Yes, but the stuff that w3 support is apache, mysql and perl-based.
> Obviously one could reimplement it all in, but it's probably just
> easier to use what they have, if it works (I agree with you about
> ACIDity, but this isn't the place to worry about that).
>
>> Take a look at openacs, it has that functionality out of the box
>> and a lot more stuff also(www.openacs.org). The comments get
>> appended to the end of the page.
>
> That looks like another such thing. This time in PHP I guess since
> it's obviously a Greenspun thing.
its in tcl and plpgsql(for postgres)
>
>> Well the book exists, the ANSI standard. What happens when the new
>> book conflicts with the standard, the standard is right. 1 source
>> of truth for the definition of a technology is useful and the more
>> sources of truth there are the less useful they become. This applies
>> to defining a technology.
>
> I wasn't after another book which seeks to define CL.
ok.
marc
>
> --tim
Erik Naggum
| Now here are some of my thoughts about what could help or, in my opinion,
| what is in fact needed to have CL reach a wider audience again.
More important than just a wider audience is where you will go to find the
wider audience. In other words, who to attract and whence.
| However, there are some drawbacks.
I think people who cannot read specifications need to learn to read
specifications -- and not just language specifications. Some think this an
arrogant and elitist position, but Common Lisp /has/ a specification and you
are expected to write to the specification, not only to the implementation.
So you do not try something you dream up and see if it works, you employ
yourself to understand what the language allows and then let your creativity
roam free when it has a sound foundation. Really nasty things happen to
people who randomly try something they envisioned in a pipe dream and wonder
what it means without any ability to predict the machine's response. Trial-
and-error mode is actually unsuitable for all languages, but some languages
have no specification and you /have to/ test things you dream up from
insufficient understanding and see if it "works" and even what it does. I
think it behooves a novice to Common Lisp to shed such notions of the only
proper approach to learn a programming language. Trial and error is based
on intuition, but you need to build that intuition first. Using intuition
from one language to be creative in another does not work very well.
Perhaps, however, the reason you still appear to be look at Common Lisp from
the outside.
| The ANSI specs doesn't provide rationales so you can't understand the
| specifications if you haven't got an idea about the topics upfront.
I spent a fair amount of time with Ada 83 and the development towards Ada
95. The annotated standard has an excellent rationale liberally sprinkled
throughout the entire document, and it is indeed very valuable. Back when C
was ANSI X3.159, it came with the rationale as a sort of add-on document.
However. the committee decisions for Common Lisp actually form a rationale
relative to the base document, which is CLtL1, the Silver Book.
| Furthermore, the deprecated sections are highly confusing: first of
| all, a newbie (me, at least) doesn't care at all wheter someone from a XJYIZ
| committee voted for this and that (I am intentionally exaggerating here);
| this is (probably still) interesting for historical reasons but not when you
| actually want to learn the language.
I think you should read more of these decisions before you dis them all.
| (We could use "CLtL3" as a working title for such a refactoring?)
But who would ensure that this new document agrees with the standard?
| This already would mean a lot of work but would pay off in the long run for
| the CL community.
I actually doubt that. So do all the others who have not started writing it.
| What do you think?
I think the HyperSpec is an amazingly high-quality document that it pays off
handsomely to learn to read and navigate and that it would /not/ pay off to
write another complete document. However, it would pay off to link from the
HyperSpec pages to "commentary" pages. This could be a useful thing to do
with cliki.
| P.S.: Perhaps you need this background information: usually, I don't read
| tutorials or introductions to languages on a tutorial level. I highly prefer
| to learn languages from their specifications.
Could it be that you lack the background to be able to read this particular
specification and that you would benefit from getting the conceptual models
right rather than read a tutorial? From reading your article, I trust that
you are quite capable of internalizing the fundamental concepts, but you
should consider the possibility that you started writing your article too
soon and that the thinking that would normally pulsate with the energy of
change have coagulated during the writing process that exposed them to your
conscious verbalization of these ideas. (I frequently find myself writing
both code and prose mainly to clarify my thinking on a subject, but there is
a level of commitment to that which has been expressed involved in publishing
or sharing that makes it surprisingly hard to revise in fundamental ways.
Annoyingly common psychology that is hard to beat.)
I do not think we gain anything if we attract people who do not know how to
program or how to read a specification -- the cost of entertaining them
could well be very more on the community than any benefits. Those who
desire to write tutorials should get paid for this by people who want to buy
the books or take the courses. Something on the level of How to Design
Programs for Common Lisp would be great (ignoring cost/benefit analyses),
but this has to be done in an existing educational setting. This quality
level is immensely expensive to attain.
I have written scattered sections of what could become a book under favorable
conditions. I have aimed to lead people from the Unix and C environment into
the Unix and Common Lisp environment, using Emacs. I am a firm non-believer
in the Windows experience for a large number of reasons, many political, but
Unix and Linux have some problems when it comes to Unicode support and the
entertainment industry. I believe people are more productive using Common
Lisp than C++ with the visually oriented programming environments for the
simple reason that you live within the evolving Common Lisp world, but more
work needs to be done on collaborative efforts, versioning not just of source
code but of loaded executable code, and some sort of Common Lisp server that
works like a database engine where an individual programmer has his own work
space that he commits to the system, much like CVS does today, but within
the Emacs/Common Lisp server world. I have also been dabbling in a Common
Lisp Emacs (clemacs) that would integrate all of these facets, but there are
features in Common Lisp that need to evolve and features in implementations
that are required to support this mode of work.
Many of the ideas that form the foundation for Common Lisp and Unix are
actually very similar and should have been able to work tightly and well
together. That they do not is perhaps one of the major failures of the
Common Lisp community.
Pascal Costanza
>
> Pascal Costanza <cost...@cs.uni-bonn.de> wrote in message news:<3D6CE6F9...@cs.uni-bonn.de>...
> > Hi,
> >
> > As most of you surely know by now I am still quite new to CL. Therefore
> > I have gained some knowledge about the unnecessary barriers to learning
> > CL from first-hand experience.
> >
> > Now here are some of my thoughts about what could help or, in my
> > opinion, what is in fact needed to have CL reach a wider audience again.
> >
> > In my opinion, you have to have some kind of "definitive" resource for a
> > language where you can find a complete and consistent definition. For
> > example for Java, this is the Java Language Specification and the Java
> > API documentation. My conjecture is that all successful languages have
> > these kind of definitive resources. (However, I haven't taken time yet
> > to collect evidence for this.)
[...]
> I think you mistaken in your belief that the availability of a
> language standard is somehow related to the popularity of a language.
> Neither proceeds from the other.
This was just a guess, I don't know. I still think there is some
relation but I have think about it more deeply which I haven't done
yet...
> C and C++ have ANSI/ISO standards, and most programmers who work
> in these languages don't know that these documents even exist.
> I wonder how many Java programmers actually know about the Java
> Specification, versus how many rely on some 700 page
> for dummies type book.
Most of the Java programmers I know rely on the Java lang spec and refer
to it regurarly. I am lucky that I don't know too many dummies. ;-)
> > This is confusing for newbies because it consumes too much time
> > to figure out what this actually means. 2) Both are hard to read, for
>
> Show me one programming language ANSI/ISO standard that is easy to read
> for newbies.
I didn't intend to say that the situation is particularly bad in the
case of Common Lisp with regard to the ANSI standard.
> > different reasons: The ANSI specs doesn't provide rationales so you
> > can't understand the specifications if you haven't got an idea about the
> > topics upfront.
>
> I think that intelligent people can understand a specification without
> requiring rationale. Rationale is for those who question the design
> decisions described by the specification.
I totally disagree. My working style in learning a new language is to
absorb its rationale first. I usually invest a lot of time there before
I begin to program in a new language. I don't think that I'm not
intelligent. ;-)
I think I would try too hard to imitate languages I already know in the
new language if I'd do it otherwise.
Your mileage may vary, of course. There's always more than path to
enlightenment and the more paths you provide the more people you
attract.
> Rationale is largely unnecessary because Lisp is a language that
> does the right thing nearly everywhere. The answer to the question
> ``why is this done this way'' becomes obvious when you think
> about it and use it.
I don't think it's that easy when you come from a different background.
> CLtL2 is generally easier to understand, but your mind
> > has already switch to a "be careful" mode when reading because things
> > _might_ be different in ANSI CL.
>
> You would have to be in that same mode when reading any treatment
> of the language other than the standard. Effectively, the cltl2
> is just any other textbook about Lisp, except that it's formatted
> as a detailed reference manual.
No, the case is different. When I am reading a textbook about ANSI
Common Lisp I expect it to be correct, and each deviation from the
standard to be a bug. When I am reading CLtL2 I know that I expect it to
be about a slightly different language.
> You might be better off with some textbook about Lisp programming.
> Whatever constructs it teaches, look them up in the HyperSpec.
> That way you learn about their detailed syntax with all its
> variations, and spot any errors in the book.
No, I don't learn that way, I learn languages by looking at their specs.
Sorry.
> > Furthermore, the deprecated sections
> > are highly confusing: first of all, a newbie (me, at least) doesn't care
> > at all wheter someone from a XJYIZ committee voted for this and that (I
> > am intentionally exaggerating here); this is (probably still)
> > interesting for historical reasons but not when you actually want to
> > learn the language.
>
> How does this give rise to confusion? Just skip it.
No, you can't - see below.
> > More often than not you try hard to understand a
> > complicated section, just to read that you can forget about it two
> > paragraphs later. This is very frustrating.
>
> Can you cite an example of this? It sounds like a defect.
Here is a quote from chapter 22.1.4. "Standard Dispatching Macro
Character Syntax"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#.
#.foo is read as the object resulting from the evaluation of the Lisp
object represented by foo, which may be the printed representation of
any Lisp object. The evaluation is done during the read process, when
the #. construct is encountered.
[
X3J13 voted in June 1989 (DATA-IO) to add a new reader control
variable, *read-eval*. If it is true, the #. reader macro behaves as
described above; if it is false, the #. reader macro signals an error.
]
The #. syntax therefore performs a read-time evaluation of foo. By
contrast, #, (see below) performs a load-time evaluation.
Both #. and #, allow you to include, in an expression being read, an
object that does not have a convenient printed representation; instead
of writing a representation for the object, you write an expression that
will compute the object.
{
#,
#,foo is read as the object resulting from the evaluation of the Lisp
object represented by foo, which may be the printed representation of
any Lisp object. The evaluation is done during the read process, unless
the compiler is doing the reading, in which case it is arranged that foo
will be evaluated when the file of compiled code is loaded. The #,
syntax therefore performs a load-time evaluation of foo. By contrast, #.
(see above) performs a read-time evaluation. In a sense, #, is like
specifying (eval load) to eval-when, whereas #. is more like specifying
(eval compile). It makes no difference when loading interpreted code;
when code is to be compiled, however, #. specifies compile-time
evaluation and #, specifies load-time evaluation.
}
[
X3J13 voted in January 1989 (SHARP-COMMA-CONFUSION) to remove #, from
the language. X3J13 noted that the first edition failed to make it clear
that #, can be meaningful only within quoted forms. All sorts of
anomalies can arise, including inconsistencies between the interpreter
and compiler, if #, is not properly restricted. See load-time-eval.
]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In this example, the section about #, provides essential information
that is relevant for understanding #. So you cannot just skip it. At
least not the first time.
Pascal
Pascal Costanza
>
> In article <3D6CE6F9...@cs.uni-bonn.de>,
> Pascal Costanza <cost...@web.de> wrote:
> >CLtL2 and the ANSI specs are often pointed to as the definitive
> >resources. However, there are some drawbacks. 1) This is always
> >accompanied by cautions that CLtL2 is different from ANSI to some
> >extent. This is confusing for newbies because it consumes too much time
> >to figure out what this actually means.
>
> IMHO, this warning is overblown. The differences between the language
> described in CLTL2 and the ANSI spec are very few, and mostly in parts of
> the language that beginners are very unlikely to encounter.
...but you know this because you have a good knowledge about Common
Lisp. This warning makes a newbie insecure.
> The ANSI specification is already over 1,000 pages long. Adding in
> "user-friendly" stuff like rationales would make it even more unweildy. I
> don't think one document can be both the precise specification and the
> user-friendly explanation of the language -- that's too much to ask of one
> text if you want it to be of a manageable size.
Hmmm, perhaps you're right. It works for other languages but they are
usually much smaller...
> >P.S.: Perhaps you need this background information: usually, I don't
> >read tutorials or introductions to languages on a tutorial level. I
> >highly prefer to learn languages from their specifications.
>
> Do you think you're typical? If not, how would doing something for you
> "get a wider audience"?
>
> I think most programmers make more use of textbooks and tutorials than the
> official specifications.
Is it important if I'm typical? I can only repeat myself: There's always
more than one path to enlightenment. The more paths you provide the more
people you attract.
Pascal
Pascal Costanza
>
> * Pascal Costanza
> | Now here are some of my thoughts about what could help or, in my opinion,
> | what is in fact needed to have CL reach a wider audience again.
>
> More important than just a wider audience is where you will go to find the
> wider audience. In other words, who to attract and whence.
I have made the experience that learning about the history of Lisp means
understanding a lot of fundamental concepts of computer science that are
not only relevant to the Lisp community. I have already had a great deal
of knowledge beforehand but sometimes, even the same concepts that are
also present in other languages get a much deeper meaning in conjunction
with Lisp.
I have an academic background as I currently work for a university, and
I am convinced that Lisp together with its historical perspective should
be on the curriculum for this reason. It's a pity that this is not taken
for granted in academia. I don't think about who and whence...
> | However, there are some drawbacks.
>
> I think people who cannot read specifications need to learn to read
> specifications -- and not just language specifications.
I totally agree. That should be part of a scientific education.
[...]
> Trial and error is based
> on intuition, but you need to build that intuition first.
Exactly - and CLtL2 provides the "intuition" in many cases.
> Using intuition
> from one language to be creative in another does not work very well.
> Perhaps, however, the reason you still appear to be look at Common Lisp from
> the outside.
Yes, I admit this is very likely to still be the case.
> | Furthermore, the deprecated sections are highly confusing: first of
> | all, a newbie (me, at least) doesn't care at all wheter someone from a XJYIZ
> | committee voted for this and that (I am intentionally exaggerating here);
> | this is (probably still) interesting for historical reasons but not when you
> | actually want to learn the language.
>
> I think you should read more of these decisions before you dis them all.
OK, thanks for this advice, I am going to do that.
> | What do you think?
>
> I think the HyperSpec is an amazingly high-quality document that it pays off
> handsomely to learn to read and navigate and that it would /not/ pay off to
> write another complete document. However, it would pay off to link from the
> HyperSpec pages to "commentary" pages. This could be a useful thing to do
> with cliki.
Great - this would be a good compromise!
> | P.S.: Perhaps you need this background information: usually, I don't read
> | tutorials or introductions to languages on a tutorial level. I highly prefer
> | to learn languages from their specifications.
>
> Could it be that you lack the background to be able to read this particular
> specification and that you would benefit from getting the conceptual models
> right rather than read a tutorial? From reading your article, I trust that
> you are quite capable of internalizing the fundamental concepts, but you
> should consider the possibility that you started writing your article too
> soon
[...]
OK, I will consider it. ;)
> and that the thinking that would normally pulsate with the energy of
> change have coagulated during the writing process that exposed them to your
> conscious verbalization of these ideas. (I frequently find myself writing
> both code and prose mainly to clarify my thinking on a subject, but there is
> a level of commitment to that which has been expressed involved in publishing
> or sharing that makes it surprisingly hard to revise in fundamental ways.
> Annoyingly common psychology that is hard to beat.)
The process of writing my guide to Lisp was an important step for me to
understand Lisp better. The feedback I have got from so many people
added a lot of value to this process, so I gained a lot from publishing
it. Don't worry, I intend to continue to improve. ;-)
Pascal
Barry Margolin
Pascal Costanza <cost...@web.de> wrote:
>Barry Margolin wrote:
>> Do you think you're typical? If not, how would doing something for you
>> "get a wider audience"?
>>
>> I think most programmers make more use of textbooks and tutorials than the
>> official specifications.
>
>Is it important if I'm typical? I can only repeat myself: There's always
>more than one path to enlightenment. The more paths you provide the more
>people you attract.
If we have limited resources, we should presumably use them to address the
problems that a large number of potential users have, rather than a tiny
minority. An improvement that only addresses atypical users will not have
a big impact. We should strive to get the most bang for our bucks.
With unlimited resources everyone's needs could be accomodated, but that's
not realistic. You're asking for significant amount of work to be done for
relatively little benefit.
Hannah Schroeter
Erik Naggum <er...@naggum.no> wrote:
>[...]
> It is available in PDF for USD 18.00 and should be on every C programmer's
But only if you already have a credit card, which isn't so commonplace
e.g. in Germany.
Kind regards,
Hannah.
Nils Goesche
> Erik Naggum <er...@naggum.no> wrote:
>
> > It is available in PDF for USD 18.00 and should be on every C programmer's
>
> But only if you already have a credit card, which isn't so
> commonplace e.g. in Germany.
Last thing I heard was that they give VISA cards even to 16 year olds
in Germany, nowadays. I can hardly imagine how anybody can survive
without a VISA card; getting one is probably even more important than
having a copy of the C standard :-)
Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x0655CFA0
Kaz Kylheku
Ah well, what can you do? You can't control the people who decide to
write books; the best that you can hope for is that they will be
responsible enough to do a thorough, accurate job and follow up with
errata.
> > You might be better off with some textbook about Lisp programming.
> > Whatever constructs it teaches, look them up in the HyperSpec.
> > That way you learn about their detailed syntax with all its
> > variations, and spot any errors in the book.
>
> No, I don't learn that way, I learn languages by looking at their specs.
> Sorry.
But you like specs to have non-spec material like rationale. ;)
Marco Antoniotti
Nils Goesche <car...@cartan.de> writes:
> han...@schlund.de (Hannah Schroeter) writes:
>
> > Erik Naggum <er...@naggum.no> wrote:
> >
> > > It is available in PDF for USD 18.00 and should be on every C programmer's
> >
> > But only if you already have a credit card, which isn't so
> > commonplace e.g. in Germany.
>
> Last thing I heard was that they give VISA cards even to 16 year olds
> in Germany, nowadays. I can hardly imagine how anybody can survive
> without a VISA card; getting one is probably even more important than
> having a copy of the C standard :-)
Especially when your economy is fueled by generalized deficit spending
in the form of debt toward the CC cards companies. :)
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
715 Broadway 10th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
Erik Naggum
| I fully agree, just it's not what I found in lang.c groups. Well the
| regulars know and act accordingly but the questions which are definitly out
| of bound are the majority.
This is not surprising. People are not taught to go read the specification
when they program C because so many things are explicitly implementation-
dependent that you basically cannot do very much if you write only to the
specification of C. There was not even consistency requirements among the
multiple implementation-dependencies in C-1989, but I seem to recall that
there are in the integrity amendment and in C-1999.
Erik Naggum
| I think that intelligent people can understand a specification without
| requiring rationale. Rationale is for those who question the design
| decisions described by the specification.
* Pascal Costanza
| I totally disagree. My working style in learning a new language is to
| absorb its rationale first. I usually invest a lot of time there before
| I begin to program in a new language. I don't think that I'm not
| intelligent. ;-)
I think you two are using "rationale" very differently. Kaz's usage is very
close to mine as I understand his last sentence, but it occurs to me that
Pascal uses it to mean something like the conceptual models of the language,
which is also a "rationale" but in a much broader sense. It is like those
two deeply intelligent questions "who are you" and "what do you want" in
Babylon 5, to which the answer is not your name and your dinner menu choice.
| No, the case is different. When I am reading a textbook about ANSI Common
| Lisp I expect it to be correct, and each deviation from the standard to be a
| bug. When I am reading CLtL2 I know that I expect it to be about a slightly
| different language.
I think your first expectation is faulty. I have come to believe, after a
long discussion tonight over Apple's invocation of the DMCA to prevent its
customers from burning DVDs on external drives, that many people discuss
things mainly to determine which "side" of an issue people are on, and seek
to learn who they agree and disagree with, long before any party understands
the issues involved. Some people on the Net seem to read what others write
with the express purpose to believe it rather than think about it. I write
mostly about what I think about and not what I believe. I read what others
write to think about it, not to believe it. Those who inject falsehoods into
the information flow, however, poison the well of thinking and reasoning.
However, that which is not false is not necessarily true. Many things can
be true at the same time depending on context, so it is hard to determine
that something is The Truth, but we can fairly easily determine that
something is false. If we limit the discussions to what has not already
been determined to be false, I believe the chance of finding more truth
increases dramatically compared to a forum where people either post
falsehoods or limit their discussion to what is already determined to be
true. The latter occurs when people are mainly concerned with believing
(in) what others say.
So, if you expect what people write to be correct, you will tend to believe
them before you have thought about what they say. This is bad for your
critical thinking ability. You should, however, expect what they say not to
be known (at the time it was written) to be false and that they wrote it
because they thought was valuable in some sense or another. The economy of
writing dictates that people do not both blabber endlessly and get published.
However, the situation that something was true but has become false over
time is so common in technical writing that I have some philosophical
problems understanding your position. You are not reading CLtL2 in order to
believe it to be useful, but to understand some of the historical record.
For the same reason, it is actually useful to read CLtL1 or the older Lisp
manuals. If your desire is to understand and not to believe, you will not
be derailed by historic information any more than you are derailed by past
knowledge that you have had to expire. It should still be valuable to you.
| No, I don't learn that way, I learn languages by looking at their specs.
| Sorry.
Sorry to correct you, but you have learned this way up until now. If your
past successes also determine your future options, you are likely to limit
yourself needlessly. My experience has been similar to yours, but then I
discovered that I had chosen to learn things that came easy to me. This
became quietly self-fulfilling. I decided to learn new things from the most
technical source available based on the assumption that it would be easy to
learn and lost interest in things that did not yield to this successful mode
of learning. Then I realized that I had happened on this mode of learning
by accident and that I had probably been exposed to a number of other modes
of learning that had not yielded results as quickly or as consistently and
had simply taken the path of least resistance. I decided to seek out paths
of significant resistance and actively to search out counter-information to
what I already believed to be true. I read things that I had previously
thought to be false, invested a lot of time in reading political theories
that I believed to be wrong and evil for the sole purpose of delaying the
impulse to agree or believe and to hone my critical thinking by learning to
listen to arguments before I decided on their truth status. It has helped
me /tremendously/ in dealing with issues that did not come easy to me, to
find that I, too, need to work hard to understand certain topics and most
topics beyond a certain level. I had dismissed a number of topics because
what people were talking about as if it were difficult were in fact trivial
and hence not worth my time. It turned out that the entry-level to these
areas of human knowledge was indeed trivial and boring beyond belief, but
that there was lots of interesting thinking going on among those who had
plowed through the tons of trivialties that had shaped their mode of
thinking and made them able to discuss topics based on massive background
information. Instead of reading the specification for the English language,
I read poetry and literature and found that literary criticism is not trivial
at all (despite the best efforts of my teachers to make it appear worse than
pedestrian, unrewarding, and dilettantish). I found, in brief, that the
kinds of things for which I /could/ read the specification and the highly
condensed formal presentations were limited and thus limited me instead of
making it possible for me to learn interesting things. I came to believe that
too much success too early in life in certain fundamentally simple approaches
could be a curse and not the gift it was touted to be at the time.
Sometimes, more information is passed to the reader in a tutorial than in
the reference for the same material. It therefore behooves the conscientious
student to read more than one tutorial to learn of more ways to approach the
same topic as seen by experts in both the field and in pedagogy. A critical
student should also study pedagogy in order to learn how to distinguish bad
teachers and textbooks from good. To understand pedagogical presentations
and their desired effect on readers is no small task. Most of us learn in
ways that are hard to communicate to others and the expectation that others
learn in the same way we do, given that we have chosen how to learn through
a series of accidentally positive feedback, not through deliberate selection
among the available learning modes. Since learning and thinking are not
taught in our schools, good methodology is largely unavailable until people
enter college or university, a decade later than it should have been taught.
I think this should be of value to the Feyerabend project. Comments?
| In this example, the section about #, provides essential information that is
| relevant for understanding #. So you cannot just skip it. At least not the
| first time.
There is something I do not quite understand about #,. The recommended way
to accomplish very similar results today is to use `load-time-value´. There
are some cases where #, and `load-time-value´would differ in semantics, but
I think it is such a verbose way to request this behavior that people are
unlikely to want to use it I think #,
should have been made to expand to a `load-time-value´ form.
Erik Naggum
| This warning makes a newbie insecure.
What this means is that there has been a dearth of teaching the necessary
reading skills. "Caveat lector" should be at least as important in people's
lives as the caveat emptor that has entered our common vocabulary and the
business ethics.
| Is it important if I'm typical? I can only repeat myself: There's always
| more than one path to enlightenment. The more paths you provide the more
| people you attract.
But have you followed this dictum yourself? You seem to be a firm believer
in your past successes in learning programming languages, even though you
appear to get the message that there is more to it than you have seen so far.
You realize, I hope, that your article will be another non-reference-material
resource on Common Lisp that you hope people will want to read when they
desire to learn Common Lisp. If you truly believed in the specification-only
learning mode, it seems to follow that you would not have written this text.
I take this to mean there is hope for your appreciation of other paths to
enlightenment that may go through both historic and tutorial documents.
One of the major attractions that Common Lisp offer me personally is that
there is just so much in and around it that I would benefit from. I came to
the point of SGML expertise where (I thought) I would not be able to develop
any further, where there would be nothing more for me to learn, and I found
myself always helping people without the reward of learning anything new.
This exhausted me and contributed strongly to abandoning 6 years of
concentrated effort on something I have additionally come to think of as
fundamentally braindamaged. I decided to work in an area where the
probability of dealing with people who were smarter than me was nonzero and
the Lisp and Scheme worlds offer this in abundance. To work in areas where
the sum total of knowledge is acquirable in your youth may seem exciting to
the youth, but to realize that you have wasted your most absorbent days on
something that would bore you when you exhausted the supply of ideas is
nothing but painful to the old.
Erik Naggum
| But only if you already have a credit card, which isn't so commonplace
| e.g. in Germany.
I find this absolutely astonishing. I hope you will not demand lower prices
because of your backward culture. :)
Norway may be highly advanced compared to other European countries, but both
VISA and MasterCard are really big over here. Banks offer debit and credit
cards that fit different credit ratings and other profiles. Other companies
have agreements with credit card companies to offer their most preferred
customers major credit cards. My preferred airline actually picks up my
annual credit card fees and offer free travel insurance when I pay for the
tickets with the credit card. I have come to rely so much on my credit card
that I do not leave home without it.