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.
Nicolas Neuss
Could you (or Erik or someone else) post a link where I can order it
for 18 USD? Of course, the quality should be good (I remember reading
in this newsgroup some time ago that there may be problems in this
respect).
Nicolas.
Erik Naggum
| Could you (or Erik or someone else) post a link where I can order it for 18
| USD?
http://webstore.ansi.org/ansidocstore/product.asp?sku=ISO%2FIEC+9899%3A1999
http://ftp2.ansi.org/download/free_download.asp?document=ISO%2FIEC+9899%2FCor1%3A2001
It goes for USD 26 today. The corrigendum is free.
| Of course, the quality should be good (I remember reading in this newsgroup
| some time ago that there may be problems in this respect).
That applies to the Common Lisp standard. The C standard is produced
properly.
thelifter
> 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.
>
I'm in the same position(lisp newbie) and I have come to the following
conclusion: The more I study Lisp(currently trough the book "On Lisp"
by Paul Graham which you can get for free at www.paulgraham.com), the
more it becomes clear that Lisp offers powerful abstractions.
Languages like C and Java OTOH are nothing more than high level
assemblers with little abstract concepts.
Now my point is: most people don't like abstract high-level languages
the same way that most don't like higher mathematics where you need to
think in abstract terms. So I think that will be a barrier to the
popularity of Lisp. The other day I asked a CS student about SCHEME(he
had taken a class in that). His answer: Ohh, it's a strange language
with lots of parentheses. He obviously didn't realize or wasn't
introduced to the powerfull abstractions that are possible with
Lisp/Scheme. And I think most people wouldn't like to think in
abstract terms. The average programmer likes simple concrete languages
like C.
> CLtL2 and the ANSI specs are often pointed to as the definitive
> resources. However, there are some drawbacks. 1) This is always
I think maybe Paul Graham is right when he says: a language created by
a committee is never a good language(or something similar). Common
Lisp is such a language created because there where so many dialects
and people wanted to create some standard. Probably a lot of
compromises where made as always is the case when a committee has to
agree on something.
So maybe the best idea would be to create a new language(together with
a specification), based on Lisp of course but with the advantage of
having the hindsight of 40 years of Lisp experience. Paul Graham is
doing this, just go to his site (www.paulgraham.com) to learn about
"Arc".
> This already would mean a lot of work but would pay off in the long run
> for the CL community.
But then why not reinvent Lisp? See above.
> 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.
Yes, same here. Thats why I like good specifications.
Best regards,...
Nicolas Neuss
> * Nicolas Neuss
> | Could you (or Erik or someone else) post a link where I can order it for 18
> | USD?
>
> http://webstore.ansi.org/ansidocstore/product.asp?sku=ISO%2FIEC+9899%3A1999
> http://ftp2.ansi.org/download/free_download.asp?document=ISO%2FIEC+9899%2FCor1%3A2001
>
> It goes for USD 26 today. The corrigendum is free.
Thanks for the links.
> | Of course, the quality should be good (I remember reading in this newsgroup
> | some time ago that there may be problems in this respect).
>
> That applies to the Common Lisp standard. The C standard is produced
> properly.
I admit that I lost track which standard document was the topic.
Since I don't program much in C anymore, I am more interested in the
CL standard (which costs 18 USD at the web address above). Could
someone who has got this pdf file tell me, if it is reasonable to buy
it (wrt printing quality)? (Alternatively, I could try to tex the
draft sources at www.alu.org or simply remain with the Hyperspec.)
Nicolas.
Lars Brinkhoff
> I am more interested in the CL standard (which costs 18 USD at the
> web address above). Could someone who has got this pdf file tell
> me, if it is reasonable to buy it (wrt printing quality)?
The PDF file contains pages scanned at a lowish resolution. Sometimes
(like page i) text has been cut out at the margin. It's not unreadable,
but it's not pretty either.
--
Lars Brinkhoff http://lars.nocrew.org/ Linux, GCC, PDP-10,
Brinkhoff Consulting http://www.brinkhoff.se/ HTTP programming
Espen Vestre
> conclusion: The more I study Lisp(currently trough the book "On Lisp"
> by Paul Graham which you can get for free at www.paulgraham.com), the
> more it becomes clear that Lisp offers powerful abstractions.
and the great thing is that "On Lisp" mainly concentrates on macros,
and there so many other powerful means of abstraction in Common Lisp!
> Now my point is: most people don't like abstract high-level languages
> the same way that most don't like higher mathematics where you need to
> think in abstract terms. So I think that will be a barrier to the
> popularity of Lisp.
Those who don't share the love for abstractions, should probably look
for a different thing to do. Like bit-level hacking. Or farming.
--
(espen)
Paolo Amoroso
> 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.
CLiki has a feature that might be useful for this. The following
formatting:
#H(SETQ)
generates a link to the appropriate section of the HyperSpec.
> 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.
Are there any particular projects worth working on, or ideas worth thinking
about and experimenting with?
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
Kaz Kylheku
> Erik Naggum wrote:
> >
> > * 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.
You may find the website www.lisp.org useful. It has links to many
useful materials related to Lisp, such as a history sub-page.
> 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...
I think it would be more useful for universities to use Common Lisp
as the basis for one of those two semester software engineering courses
that include a team project. This way, the teams could actually
achieve something meaningful in that timeframe, at least the bright
ones.
Pascal Costanza
>
> Pascal Costanza <cost...@cs.uni-bonn.de> wrote in message news:<3D6E2A6B...@cs.uni-bonn.de>...
> > > 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. ;)
Yes, exactly. ;-))
Pascal Costanza
Erik Naggum wrote:
>
> * Kaz Kylheku
> | 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.
Yes, there seems to be a misunderstanding. Perhaps, I should have used
the term "mental model". I need a mental model of the things concrete
constructs try to implement before I dig into the details. I also think
that in general, specs should provide such mental models.
> | 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.
You also wrote in another message:
> | 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.
Not quite: There are many paths to enlightenment and I think mine is one
of the valid ones. I don't say it's the only one, though. The reason for
my "wider audience" message was just to say that I might have given up
earlier had I not been so motivated (and now I am really glad that I
didn't give up). I just wanted to give my impression what could have
helped me. The guide I have written is partly meant to be a kind of
"work around".
However, I understand your objections and I am very thankful for your
comments. I will try to be more patient and learn even more, and in two
or three years, I will give you an interim report about how my world
view has changed. (This is only half-joking. ;)
Pascal Costanza
>
> Now my point is: most people don't like abstract high-level languages
> the same way that most don't like higher mathematics where you need to
> think in abstract terms. So I think that will be a barrier to the
> popularity of Lisp. The other day I asked a CS student about SCHEME(he
> had taken a class in that). His answer: Ohh, it's a strange language
> with lots of parentheses. He obviously didn't realize or wasn't
> introduced to the powerfull abstractions that are possible with
> Lisp/Scheme. And I think most people wouldn't like to think in
> abstract terms. The average programmer likes simple concrete languages
> like C.
I am not so sure about this statement. I think that most of the time,
languages are dismissed by purely superficial reasons. The fact that
this student complained about the parentheses doesn't necessarily mean
that he doesn't like abstractions. The parentheses in Lisp really do
scare people away who have grown up with Algol- and C-like languages.
This happens for the same reason that makes you avoid Sushi because you
think it's ugly to eat raw fish. Lisp is like Sushi - you can appreciate
it only when you taste it.
Dorai Sitaram
Pascal Costanza <cost...@web.de> wrote:
>
>I am not so sure about this statement. I think that most of the time,
>languages are dismissed by purely superficial reasons. The fact that
>this student complained about the parentheses doesn't necessarily mean
>that he doesn't like abstractions. The parentheses in Lisp really do
>scare people away who have grown up with Algol- and C-like languages.
>This happens for the same reason that makes you avoid Sushi because you
>think it's ugly to eat raw fish. Lisp is like Sushi - you can appreciate
>it only when you taste it.
Now you're scaring off all the vegetarians who
might have liked Lisp.
Tim Bradshaw
> Now you're scaring off all the vegetarians who
> might have liked Lisp.
vegetarian sushi is really nice.
Software Scavenger
> think it's ugly to eat raw fish. Lisp is like Sushi - you can appreciate
> it only when you taste it.
Do you eat it whole or remove the parentheses?
Hartmann Schaffer
Paolo Amoroso <amo...@mclink.it> writes:
> On 29 Aug 2002 13:39:08 +0000, Erik Naggum <er...@naggum.no> wrote:
>
>> 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.
>
> CLiki has a feature that might be useful for this. The following
> formatting:
>
> #H(SETQ)
>
> generates a link to the appropriate section of the HyperSpec.
wouldn't it be more useful to have a link from the hyperspec to the
commentary?
hs
--
don't use malice as an explanation when stupidity suffices
Erik Naggum
| Now my point is: most people don't like abstract high-level languages the
| same way that most don't like higher mathematics where you need to think in
| abstract terms. The average programmer likes simple concrete languages like
| C.
Rather, the abstractions that C offers are considered more "natural" than
those offered by the extended Lisp family.
| I think maybe Paul Graham is right when he says: a language created by a
| committee is never a good language (or something similar).
I think Paul Graham is /fundamentally/ clueless about the construction of
large systems. His desire to go back to basics to design Arc is a symptom
of the intelligent, but socially immature hacker who thinks he knows things
better than most people and /therefore/ think that other people are wrong,
making sure there is a community consensus behind decisions and that you
have to accomodate more than one person to make something succeed. Some
people succeed in making communities -- Perl and C++ and Java come to mind
-- and some people fail miserably because they think too much in "my way or
no way" terms.
| Paul Graham is doing this, just go to his site (www.paulgraham.com) to learn
| about "Arc".
He is just another disgruntled Lisper who disrespects everybody who thinks
different from himself. The announcement of "Arc" destroyed much of my
respect for Paul Graham as an authority.
| But then why not reinvent Lisp? See above.
Because you end up worse than what we already have.
How come people with the most misguided political ideas believe revolution
is the answer and people with reasonable political ideas manage to succeed
in slowly transforming their society to their liking? Please think about it.
Erik Naggum
| Could someone who has got this pdf file tell me, if it is reasonable to buy
| it (wrt printing quality)? (Alternatively, I could try to tex the draft
| sources at www.alu.org or simply remain with the Hyperspec.)
I bought the actual standard and it nicely printed and bound. (The only
objection I have against the standard qua publication is that it uses the
butt-ugly default TeX fonts.) In order to know whether it was advisable for
me to recommend that others spend the USD 18 on the PDF file, I bought it
only to discover that there are things worse than almost computer modern --
almost computer modern printed scanned back in at 150 dpi by a person with a
serious grudge against attention to detail. The bad PDF document looks like
evidence of a passive-aggressive personality disorder hard at work. You
could not make something that ugly unless you were deliberately trying to
punish people for wanting to buy the standard, especially since ANSI had the
original postscript files, from which they should have been able to destill
a PDF. But then again, ANSI even failed to list the Common Lisp standard
properly in their catalog.
Now, the obvious conclusion from the above is that I should no longer advise
people to purchase the PDF document. But it is also the wrong conclusion.
You need the real thing and the ANSI document is the real thing. USD 18
will set you back one good meal or a movie and a burger date, but you are
single, anyway, right? (But purchase the actual document and you may have
to forgo real food and eat rice for a month or more. Obesity has become an
epidemic in Western cultures and asceticism quite undervalued, but one may
still find cause to prioritize food over standards.) So the only reason you
want this document is that you want to ascertain that what you read elsewhere
is the true standard. It may not be a great read -- for that, the postscript
files are still available or get the TeX sources and compile your own -- but
there are some differences between the abject representational poverty of
HTML and the paper version has a very different feel than any of the HTML
versions available.
Since I mentioned it, I got quite a handsome number of positive responses,
so I think I shall go forward with an idea I got as I came across amazingly
beautifully printed and bound versions of the Bible and the Qur'an (which are
admittedly aimed at larger markets than standards) and noticed that Webster's
New World College Dictionary comes in a black leather-bound and gilded
edition for their 50th anniversary. As a bibliophile I would so very much
like to produce the last public draft of the Common Lisp standard in a nicer
font and in the high-quality binding that I think it deserves. Since it is
not going to change any time soon and we should try not to worry about its
status as ANSI standard, I should hope there is a sufficiently large market
that I am willing to take on the job of producing this book in a lasting and
beautiful version. The problems are the print run, the cost of the binding,
and the financial risks involved. I have no idea what the costs might be,
but will investigate in the coming week. It will be substantially more than
the USD 18 for the PDF file, however. Please indicate your preliminary
interest to me by mail with some indication of the price level at which that
interest would wane.
Erik Naggum
| Are there any particular projects worth working on, or ideas worth thinking
| about and experimenting with?
Several years ago, I started to write glue code to talk to Unix from CMUCL
and then from Allegro CL, and called it clunix. (The people who have taken
all the domain names have indeed been true to the intended pronunciation --
clue-nix.) Basically what the Perl, Python, or Ruby people have been doing,
but with palatable syntax and abstraction traditions.
As for the primary similarity between Unix and Common Lisp, an interactive
environment where you can define functions and run them in a shell, I keep
wondering why nobody have thought of Common Lisp for the shell. `scsh´ is
not a bad idea, but whatever elegance Scheme has appears to have drowned, as
it so often does when Scheme is exposed to the real world, like `guile´.
Tim Bradshaw
> wouldn't it be more useful to have a link from the hyperspec to the
> commentary?
Yes, and that's what amaya's annotations do by some magic, and what I
was suggesting could probably also be done for ordinary browsers by
something that interposed itself between the spec and the user.
--tim
Johannes Grødem
> As for the primary similarity between Unix and Common Lisp, an interactive
> environment where you can define functions and run them in a shell, I keep
> wondering why nobody have thought of Common Lisp for the shell.
It seems somebody has:
http://clisp.sourceforge.net/clash.html
--
johs
ilias
> So maybe the best idea would be to create a new language(together with
> a specification), based on Lisp of course but with the advantage of
> having the hindsight of 40 years of Lisp experience. Paul Graham is
> doing this, just go to his site (www.paulgraham.com) to learn about
> "Arc".
> But then why not reinvent Lisp? See above.
Paul Graham is doing the 'right' thing and i know (intuitive) that he'll
have an excellent result.
This of course only, if he manages to follow the rules he has set up in
his articles.
But i don't think that it will be the exceptional, breaking-through new
language.
His mind is trained to think in the paths of LISP.
An for creating exceptional, breaking-through technology, you need
'virgin' brains (free and uninfluenced thinking paths) with exceptional
analytic strength and creativity.
And where to find them?
Hannah Schroeter
Nils Goesche <car...@cartan.de> wrote:
>[...]
>Last thing I heard was that they give VISA cards even to 16 year olds
>in Germany, nowadays.
If you pay for it, and probably with a not so high credit amount...
>I can hardly imagine how anybody can survive
>without a VISA card;
In Germany? You can pay cash almost everywhere, and the rest can be
done by bank money orders (Überweisungen) or deduction permits
(Abbuchungsgenehmigung). I don't know any kind of domestic money
transaction in Germany where you *need* credit cards for, in fact.
>getting one is probably even more important than
>having a copy of the C standard :-)
That might still be true, even if the priority to get credit cards
isn't all too high, as described above :-)
>[...]
Kind regards,
Hannah.
thelifter
> How come people with the most misguided political ideas believe revolution
> is the answer and people with reasonable political ideas manage to succeed
> in slowly transforming their society to their liking? Please think about it.
Hmmm, maybe we should still all be using Fortran?
...
ilias
> Hmmm, maybe we should still all be using Fortran?
maybe.
may you have a good read-in line (fortran) for me?
Hannah Schroeter
What's that?!
I thought that one definition of sushi is that it's made of fish?!
Kind regards,
Hannah.
Nils Goesche
Well, yes. But usually you also get a few pieces with only
cucumber or ginger or something. It still tastes somewhat like
sushi because of the specially prepared rice (cooked with Sake I
think).
Regards,
--
Nils Goesche
Ask not for whom the <CONTROL-G> tolls.
PGP key ID #xD26EF2A0
Hannah Schroeter
thelifter <thel...@gmx.net> wrote:
>Hmmm, maybe we should still all be using Fortran?
Perhaps I should quote something from a book named Artificial Intelligence
Techniques by Alan Bundy (ed.):
95 FORTRAN
FORTRAN is the programming language considered by many to be the
natural successor of Lisp and Prolog for AI research. Its advantages
include:
- it is very efficient for numerical computation (many AI programs
rely heavily on number-crunching techniques).
- AI problems tend to be very poorly structured, meaning that
control needs to move frequently from one part of a program to
another. FORTRAN provides a special mechanism for achieving this,
the so-called GOTO statement.
- FORTRAN provides a very efficient data structure, the array, which
is particularly useful if, for example, one wishes to process a
collection of English sentences each of which has the same length.
Coan, J.S., Basic FORTRAN, Hayden Book Co, Indianapolis, 1980.
Aloysius Hacker
SCNR,
Hannah.
David vGB
> Tim Bradshaw <t...@cley.com> wrote:
>>vegetarian sushi is really nice.
>
> What's that?!
>
> I thought that one definition of sushi is that it's made of fish?!
>
> Kind regards,
>
> Hannah.
>
The American Heritage® Dictionary of the English Language, Fourth Edition:
su·shi
n.
"Cold cooked rice dressed with vinegar that is shaped into bite-sized
pieces and topped with raw or cooked fish, or formed into a roll with fish,
egg, or vegetables and wrapped in seaweed"
The topping's not the defining factor - much like pizza is pizza pretty
much whatever you put on top.
Mind you I've got a pretty liberal definition - one of my local places has
sushi with turkey breast, asparagus, you name it. Hardly traditional but
_very_ nice.
--
(luvdave)
Nils Goesche
> Nils Goesche <car...@cartan.de> wrote:
> >[...]
>
> >Last thing I heard was that they give VISA cards even to 16 year olds
> >in Germany, nowadays.
>
> If you pay for it,
For a VISA? Parents give cell phones to their children
nowadays. Guess what's more expensive ;-)
> and probably with a not so high credit amount...
Maybe with none at all. You also have the option that they
withdraw the money from your account immediately after you spent
the money.
> >I can hardly imagine how anybody can survive
> >without a VISA card;
>
> In Germany? You can pay cash almost everywhere, and the rest can be
> done by bank money orders (Überweisungen) or deduction permits
> (Abbuchungsgenehmigung). I don't know any kind of domestic money
> transaction in Germany where you *need* credit cards for, in fact.
No, you don't /need/ one. You don't /need/ microwave ovens,
either. That's how we Germans are. I only have a microwave oven
because my Japanese wife insisted on buying one.
Once you get used to paying with credit cards (and I buy lots of
stuff in the US or UK over the internet) it's really nice,
just... convenient. I know the number by heart. You don't have
to check your wallet before entering an expensive restaurant or a
shop or anything, no matter in which country you are; no fiddling
with change and you never get to hear the larmoyant question
``Ham Se's nich n bißchen kleiner?'' again :-)
Erik Naggum
| vegetarian sushi is really nice.
* Hannah Schroeter
| What's that?!
|
| I thought that one definition of sushi is that it's made of fish?!
Given that vegetarians eat what is eaten by the animals killed for food that
real people eat, vegetarian sushi should be made up of the food that the
fish that will not be killed for food eat. Sea weeds, algae, accidentally
drowned Yakuza members, etc.
Henrik Motakef
> 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.
Just for the record: The annotation magic is not so much an Amaya
thing, but one of W3Cs "Annotea" server (see
http://www.w3.org/2001/Annotea/). Amaya is only one client for this,
there are plugins for IE and Mozilla mentioned at Annoteas website.
Erann Gat
> han...@schlund.de (Hannah Schroeter) writes:
>
> > Tim Bradshaw <t...@cley.com> wrote:
> > >* Dorai Sitaram wrote:
> > >> Now you're scaring off all the vegetarians who
> > >> might have liked Lisp.
> >
> > >vegetarian sushi is really nice.
> >
> > What's that?!
> >
> > I thought that one definition of sushi is that it's made of fish?!
>
> Well, yes.
Well, no. The defining characteristic of sushi is rice (strictly
speaking, a particular kind of rice) prepared so that the grains stick
together and seasoned with rice vinegar. Vegetarian sushi is still
sushi. (The defining characteristic of *sashimi*, on the other hand, is
raw fish. There is no such thing as vegetarian sashimi.)
What this has to do with Lisp eludes me.
E.
Nils Goesche
> In article <87lm6nh...@darkstar.cartan>, Nils Goesche <n...@cartan.de> wrote:
>
> > han...@schlund.de (Hannah Schroeter) writes:
> >
> > > Tim Bradshaw <t...@cley.com> wrote:
> > > >vegetarian sushi is really nice.
> > >
> > > What's that?!
> > >
> > > I thought that one definition of sushi is that it's made of fish?!
> >
> > Well, yes.
>
> Well, no. The defining characteristic of sushi is rice
> (strictly speaking, a particular kind of rice) prepared so that
> the grains stick together and seasoned with rice vinegar.
> Vegetarian sushi is still sushi.
I just asked my wife what the defining characteristic of sushi
is. For some reason, she didn't answer and laughed very hard at
me. But I guess you're right about this, although I don't know
why anybody would eat vegetarian sushi.
> (The defining characteristic of *sashimi*, on the other hand,
> is raw fish. There is no such thing as vegetarian sashimi.)
True.
> What this has to do with Lisp eludes me.
Me too.
Eduardo Muñoz
> Well, no. The defining characteristic of sushi is rice (strictly
> speaking, a particular kind of rice) prepared so that the grains stick
> together and seasoned with rice vinegar. Vegetarian sushi is still
> sushi. (The defining characteristic of *sashimi*, on the other hand, is
> raw fish. There is no such thing as vegetarian sashimi.)
>
> What this has to do with Lisp eludes me.
There is a strong link betwen hackerism (sp?) and
oriental culture, specially japanese. A noticeable
percentaje of computer scientist are married with
japanese women. And lisp is certainly a hacker's
language AFAIK :)
The reason for all this escapes me though.
--
Eduardo Muñoz
Eduardo Muñoz
> Given that vegetarians eat what is eaten by the animals killed for food that
> real people eat, vegetarian sushi should be made up of the food that the
> fish that will not be killed for food eat. Sea weeds, algae, accidentally
> drowned Yakuza members, etc.
I hope that they will get rid of the tatoos
first. Mostly for aesthetics :)
--
Eduardo Muñoz
Kurt B. Kaiser
A favorite of mine is avacado and cucumber surrounded by rice in a
nori wrapper. A little more interesting than kappa-maki.
KBK
Thien-Thi Nguyen
> I hope that they will get rid of the tatoos
> first. Mostly for aesthetics :)
where do you think soy sauce comes from?
thi
Gareth McCaughan
> > | Could you (or Erik or someone else) post a link where I can order it
> > | for 18 USD?
[Erik replied:]
> > http://webstore.ansi.org/ansidocstore/product.asp?sku=ISO%2FIEC+9899%3A1999
> > http://ftp2.ansi.org/download/free_download.asp?document=ISO%2FIEC+9899%2FCor1%3A2001
> >
> > It goes for USD 26 today. The corrigendum is free.
[Nicolas again:]
> Thanks for the links.
You can get the C99 standard for $18 from the ANSI store.
http://webstore.ansi.org/ansidocstore/product.asp?sku=INCITS%2FISO%2FIEC+9899%2D1999
I don't know the exact relationship between this version of it
and the $26 one. Probably just a matter of whether the document
says "ISO/IEC" on it or "INCITS/ISO/IEC".
--
Gareth McCaughan Gareth.M...@pobox.com
.sig under construc
Gareth McCaughan
> An for creating exceptional, breaking-through technology, you need
> 'virgin' brains (free and uninfluenced thinking paths) with exceptional
> analytic strength and creativity.
I think this is a myth. (The first part, not the second.)
Breakthroughs generally come from people who are very
familiar with the existing state of the art. As a rule:
Experts make revolutions; "virgin brains" make crackpottery.
Ng Pheng Siong
> But I guess you're right about this, although I don't know
> why anybody would eat vegetarian sushi.
When one's spouse loves sashimi and one can't stand any of the stuff. ;-)
--
Ng Pheng Siong <ng...@netmemetic.com> * http://www.netmemetic.com
Christopher Browne
Strictly speaking, "sushi" is the seasoned rice that the fish goes on
top of. So it is not a contradiction in terms to have "vegetarian
sushi." But this should doubtless be taken to alt.food.sushi...
--
(reverse (concatenate 'string "moc.enworbbc@" "sirhc"))
http://cbbrowne.com/info/linux.html
Rules of the Evil Overlord #172. "I will allow guards to operate under
a flexible work schedule. That way if one is feeling sleepy, he can
call for a replacement, punch out, take a nap, and come back refreshed
and alert to finish out his shift. <http://www.eviloverlord.com/>
Ingvar Mattsson
Almost. The definition is that it's made with sushi rice (rice with a
vinegar/water/salt/sugar/sake[1] mix) and it maty contain fish, raw or
uncooked. Raw fish is "sashimi".
//Ingvar
[1] If I remember correctly, I don't usually make sushi, I only eat it.
--
When C++ is your hammer, everything looks like a thumb
Latest seen from Steven M. Haflich, in c.l.l
ilias
> "ilias" wrote:
>
>
>>An for creating exceptional, breaking-through technology, you need
>>'virgin' brains (free and uninfluenced thinking paths) with exceptional
>>analytic strength and creativity.
>
>
> I think this is a myth. (The first part, not the second.)
> Breakthroughs generally come from people who are very
> familiar with the existing state of the art. As a rule:
> Experts make revolutions; "virgin brains" make crackpottery.
I think this is a myth.
And i think we talk both to general.
problem a can be solved by expert brains.
problem b can be solved by 'virgin' brains.
problem c can be solved by combination of expert / 'virgin' brains
Michael Sullivan
> g...@jpl.nasa.gov (Erann Gat) writes:
> > Well, no. The defining characteristic of sushi is rice
> > (strictly speaking, a particular kind of rice) prepared so that
> > the grains stick together and seasoned with rice vinegar.
> > Vegetarian sushi is still sushi.
>
> I just asked my wife what the defining characteristic of sushi
> is. For some reason, she didn't answer and laughed very hard at
> me. But I guess you're right about this, although I don't know
> why anybody would eat vegetarian sushi.
Because they are somewhere that knows how to make ume-shiso.
Michael
--
Michael Sullivan
Business Card Express of CT Thermographers to the Trade
Cheshire, CT mic...@bcect.com
Gareth McCaughan
I concur. (That's why I said "generally".) My claim is
that there are a lot more problems of type "a" than
of types "b" and "c", and that these include most
problems whose solutions lead to "exceptional,
breaking-through technology".
If you disagree -- which, from your original statement,
I assume you do -- then feel free to say why.
Jochen Schneider
Jochen
Tim Bradshaw <t...@cley.com> writes:
> Yes, and that's what amaya's annotations do by some magic, and what I
> was suggesting could probably also be done for ordinary browsers by
> something that interposed itself between the spec and the user.
ilias
> that there are a lot more problems of type "a" than
> of types "b" and "c", and that these include most
> problems whose solutions lead to "exceptional,
> breaking-through technology".
>
> If you disagree -- which, from your original statement,
> I assume you do -- then feel free to say why.
>
i don't know numbers.
but i estimate the rank:
a most
c second most
b third most
i think somewhere will be a statistic / overview available.
maybe someone knows.