In my Lisp studies I now learned most of the concepts of this great
language. Soon I will start to surf through the hyperspec and trying out
several functions which ansi Lisp offers me (I think its around 850+
functions that ship with Lisp).
What do you guess, how many of these functions do you know off by heart?
Is it more like 30? 100? Or even 540?
"Knowing" these functions means in this context that you know what they
do (and how they get evaluated if the form is a macro). It is not
necessary to know how they are implemented or how efficient they are...
Andr�
--
Andr� Thieme wrote:
> In my Lisp studies I now learned most of the concepts of this great
> language. Soon I will start to surf through the hyperspec and trying out
> several functions which ansi Lisp offers me (I think its around 850+
> functions that ship with Lisp).
>
> What do you guess, how many of these functions do you know off by heart?
> Is it more like 30? 100? Or even 540?
By heart?! Two: apropos, and that my ide offers the argument list
expected after I type a space after the function name.
How'm I doing?
Oh, hang on, two more: ^. is symbol completion, F1 (in AllegroCL) takes
me to the hyperspec on the current symbol. Also the compiler or Lisp
itself will slap me upside the head if I screw up.
Can I put "Lisp expert" on the resume?
kt
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
From: Thien-Thi Nguyen
Subject: Re: How many functions do you know?
Date:
Message-ID: <7gad1q4t7n.fsf@gnufans.net>
Andr� Thieme <······································@justmail.de> writes:
> What do you guess, how many of these functions do you know
> off by heart?
any function's heart is known
if simply, as seed starts, is sown.
tamp environ, water often,
spray for in-sets whose logic softens.
prune the wild growth if need arises
but do so gently, for seed reprises.
avoid drain bamage (monsantos woe);
support i/o-diversity (both fast and slow).
where there was none, now the funcs flower
under the sun's innumerable power!
and what do i know? i know i know not.
regardless, it's a beautiful garden that i got.
Andr� Thieme wrote:
> What do you guess, how many of these functions do you know off by heart?
> Is it more like 30? 100? Or even 540?
You mean everyone hasn't memorized CLtS? :)
Paul
On Mon, 05 Apr 2004 03:05:00 +0200, Andr� Thieme <······································@justmail.de> wrote:
> In my Lisp studies I now learned most of the concepts of this great
> language. Soon I will start to surf through the hyperspec and trying
> out several functions which ansi Lisp offers me (I think its around
> 850+ functions that ship with Lisp).
>
> What do you guess, how many of these functions do you know off by
> heart? Is it more like 30? 100? Or even 540?
>
> "Knowing" these functions means in this context that you know what
> they do (and how they get evaluated if the form is a macro). It is
> not necessary to know how they are implemented or how efficient they
> are...
Dunno. But I also haven't ever counted how many German and English
words I know - probably more than 850. Or do you know how much of the
J2EE API you have internalized?
I think the bottom line is that after you've gained some experience
you start feeling fluent although you may not know the whole
vocabulary - this is true for natural languages as well as for
computer languages. I can more or less write English emails and if I'm
missing a word I'm looking it up. Same in CL.
The point is pratice: You have to /use/ the language. (I'm pretty sure
I knew enough French to feel fluent in that language when I was
20. I've almost never used it since so I've lost it more or less
completely. Same with, say, Fortran.)
Edi.
From: André Thieme
Subject: Re: How many functions do you know?
Date:
Message-ID: <c4stsd$2t6$1@ulric.tng.de>
Edi Weitz wrote:
> On Mon, 05 Apr 2004 03:05:00 +0200, Andr� Thieme <······································@justmail.de> wrote:
>
>
>>In my Lisp studies I now learned most of the concepts of this great
>>language. Soon I will start to surf through the hyperspec and trying
>>out several functions which ansi Lisp offers me (I think its around
>>850+ functions that ship with Lisp).
>>
>>What do you guess, how many of these functions do you know off by
>>heart? Is it more like 30? 100? Or even 540?
>>
>>"Knowing" these functions means in this context that you know what
>>they do (and how they get evaluated if the form is a macro). It is
>>not necessary to know how they are implemented or how efficient they
>>are...
>
>
> Dunno. But I also haven't ever counted how many German and English
> words I know - probably more than 850.
My request was to guess it. Of course I know that no one knows the exact
answer to this question.
I am just interested about the order of magnitude.
> Or do you know how much of the J2EE API you have internalized?
Yes, I know it exactly: 0%.
And do I miss something important now? :)
> The point is pratice: You have to /use/ the language.
Of course this is correct (and no one stated something else).
Andr�
--
Andr� Thieme <······································@justmail.de> writes:
> Edi Weitz wrote:
> > On Mon, 05 Apr 2004 03:05:00 +0200, Andr� Thieme <······································@justmail.de> wrote:
> > The point is pratice: You have to /use/ the language.
>
> Of course this is correct (and no one stated something else).
I've been thinking about Knuth's idea that programming is like writing
litereature. I think he is really on to something with that idea. I
am fairly fluent in English but I don't think I will ever write a Hugo
award winning science fiction novel.
--
It would not be too unfair to any language to refer to Java as a
stripped down Lisp or Smalltalk with a C syntax.
--- Ken Anderson
http://openmap.bbn.com/~kanderso/performance/java/index.html
David Steuber wrote:
> Andr� Thieme <······································@justmail.de> writes:
>
>
> I've been thinking about Knuth's idea that programming is like writing
> litereature. I think he is really on to something with that idea. I
> am fairly fluent in English but I don't think I will ever write a Hugo
> award winning science fiction novel.
>
Knuth meant that people understand English, not programs. So code, with
or without comments is a terrible medium to communicate ideas. So if you
want to write a well documented program first try to explain it in
English in a literate style, and fill in the code as a side-effect of
your explanation.
Kumar
Kumar Balachandran <·············@earthlink.net> writes:
> David Steuber wrote:
>
> > Andr� Thieme <······································@justmail.de> writes:
> > I've been thinking about Knuth's idea that programming is like
> > writing
> > litereature. I think he is really on to something with that idea. I
> > am fairly fluent in English but I don't think I will ever write a Hugo
> > award winning science fiction novel.
> >
> Knuth meant that people understand English, not programs. So code,
> with or without comments is a terrible medium to communicate ideas. So
> if you want to write a well documented program first try to explain it
> in English in a literate style, and fill in the code as a side-effect
> of your explanation.
I have misunderstood then.
I've found in practice that it is very difficult to keep comments in
sync with code. It is much easier if the programmer only comments
are sparse. I go for the verbish long function names and noun object
names. I try to make my code as self documenting as possible with the
expectation that a human is able to read the language.
During the design stage, I also find English to do a poor job. I may
get by with some form of English like psuedocode. However, I consider
that to be a work around for a deficiency in the programming language.
I haven't really captured my thinking when designing code. One thing
I do know is that I think about what do I know and what do I want to
do. I generally create a direct translation in my mind between the
algorithm as represented in my head to the algorithm as represented in
the language I am using. The language itself is thus very influential
in my thinking.
I still run into pitfalls of course. While I have gotten much better
at reading my own code later, when I've had time to forget it, I do
run into problems with other people's code. Mind you, I sometimes
have the same problems reading other people's English prose. I'm
getting pretty good at recognizing people who's first language is
German with only limited mastery of English.
BTW, just as an aside, I am rather jealous of people who know how to
communicate in more than one natural language.
Anyway, I do my best to write code in a way that does not require
comments for a human reader. The comments I do occasionally put in
are more like annotations and just not important. However, I don't
throw away efficiency for the sake of humans. If I had to write a
sort algorithm, it wouldn't be a bubble sort. The end result is that
what I write should be comprehensible to people, but the information
may be far denser than if I wrote a lengthy description in English.
I'm not saying documentation is a bad thing. I just happen to find
progamming challenging enough without having to write documentation as
well. I mean English documentation of course.
--
I wouldn't mind the rat race so much if it wasn't for all the damn cats.
From: Joe Marshall
Subject: Re: How many functions do you know?
Date:
Message-ID: <brlu27tc.fsf@comcast.net>
Kumar Balachandran <·············@earthlink.net> writes:
> Knuth meant that people understand English, not programs. So code,
> with or without comments is a terrible medium to communicate ideas.
Sussman and Abelson disagree completely. They believe that code is an
outstanding way to communicate ideas *precisely*.
--
~jrm
Am Wed, 14 Apr 2004 10:05:36 GMT schrieb Joe Marshall
<·············@comcast.net>:
>> Knuth meant that people understand English, not programs. So code,
>> with or without comments is a terrible medium to communicate ideas.
>
> Sussman and Abelson disagree completely. They believe that code is an
> outstanding way to communicate ideas *precisely*.
IMO literal-programming is only useful if you have very complicated
concepts that need to be proved or introduced first. Also if you, e.g.,
want to know what a programming library does, you will hardly want to look
directly into the code as long as you need real details.
So comments are mainly useful for communicating the concepts. But rarely
for exact description. Especially if the code is still changing a lot it's
everything but useful to have a lot of comments.
ts
--
Sombody a few messages ago said (clip more carefully!):
> >> Knuth meant that people understand English, not programs. So code,
> >> with or without comments is a terrible medium to communicate ideas.
I sincerely doubt that Knuth intended this interpretation. In his
books and papers, he makes quite an effort to use code and pseudo-code
to communicate things best communicated that way.
Joe Marshall <·············@comcast.net> writes:
> > Sussman and Abelson disagree completely. They believe that code is an
> > outstanding way to communicate ideas *precisely*.
They *also* use a combination of English and code.
Code can't answer the question "why?" but it's very good at "what?".
Thomas Schilling <······@yahoo.de> writes:
> IMO literal-programming is only useful if you have very complicated
> concepts that need to be proved or introduced first. Also if you, e.g.,
> want to know what a programming library does, you will hardly want to look
> directly into the code as long as you need real details.
There's more to literate programming than just commentary. Being able
to organize your code according to how you explain it, is the main
idea. Lisp is flexible enough that it doesn't come up much, but I
still sometimes find myself wishing I had an LP system at hand.
Especially for security concerns -- having a chapter on authentication
and authorization that explains the system's approach, and includes
all the auth code in the system, would be really helpful for my peace
of mind that someone later won't come in and screw it up.
> So comments are mainly useful for communicating the concepts. But rarely
> for exact description. Especially if the code is still changing a lot it's
> everything but useful to have a lot of comments.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Thomas Burdick wrote:
> There's more to literate programming than just commentary. Being able
> to organize your code according to how you explain it, is the main
> idea. Lisp is flexible enough that it doesn't come up much, but I
> still sometimes find myself wishing I had an LP system at hand.
> Especially for security concerns -- having a chapter on authentication
> and authorization that explains the system's approach, and includes
> all the auth code in the system, would be really helpful for my peace
> of mind that someone later won't come in and screw it up.
More: Knuth claims that writing literate programs is a win
even when no one other than the author is ever going to read
them, because the mental discipline it imposes encourages you
to write good code. For instance, it makes "programming by
coincidence" harder to get away with.
--
Gareth McCaughan
.sig under construc
Gareth McCaughan <················@pobox.com> writes:
> Thomas Burdick wrote:
>
> > There's more to literate programming than just commentary. Being able
> > to organize your code according to how you explain it, is the main
> > idea. Lisp is flexible enough that it doesn't come up much, but I
> > still sometimes find myself wishing I had an LP system at hand.
> > Especially for security concerns -- having a chapter on authentication
> > and authorization that explains the system's approach, and includes
> > all the auth code in the system, would be really helpful for my peace
> > of mind that someone later won't come in and screw it up.
>
> More: Knuth claims that writing literate programs is a win
> even when no one other than the author is ever going to read
> them, because the mental discipline it imposes encourages you
> to write good code. For instance, it makes "programming by
> coincidence" harder to get away with.
Yep, that would be the case where "someone later" is "me" :-)
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Am 14 Apr 2004 23:15:16 +0100 schrieb Gareth McCaughan
<················@pobox.com>:
> Thomas Burdick wrote:
>
>> There's more to literate programming than just commentary. Being able
>> to organize your code according to how you explain it, is the main
>> idea. Lisp is flexible enough that it doesn't come up much, but I
>> still sometimes find myself wishing I had an LP system at hand.
>> Especially for security concerns -- having a chapter on authentication
>> and authorization that explains the system's approach, and includes
>> all the auth code in the system, would be really helpful for my peace
>> of mind that someone later won't come in and screw it up.
>
> More: Knuth claims that writing literate programs is a win
> even when no one other than the author is ever going to read
> them, because the mental discipline it imposes encourages you
> to write good code. For instance, it makes "programming by
> coincidence" harder to get away with.
But doesn't that slow you down even more? Because when you write a whole
bunch of text around your code you have to change even more when you
eventually find out that you have to reconstruct your algorithm. In my
experience this happens quite often - AFAIK this is the main reason why
the first-plan-then-code-approach fails that often.
Ok, I agree that documenting which design decisions/changes had to be made
is a valuable information but a sensible comment at the right place will
do the same IMHO. Nevertheless I really appreciate a kind of /concept
description/, possibly even at the beginning of each file or in a separate
document. This greatly helps getting the big concept without commenting
every precise detail - which would in fact double the code.
Where you do need a precise (textual desciption) and where change is
unlikely to happen very often are complex mathematical algorithms. There,
I think, you need a really detailed and comprehensive description. Often
things are proved correct beforehand so there's not much to be modified
later (without deeper thought). As an example it would be very hard to get
the idea of bresenham's line-drawing-algorithms only from code, but it
also will hardly be changed later. So a thorough description would be very
useful.
ts
--
"But I don't expect to convince anyone (over 25) to go out and learn
Lisp." - Paul Graham
Thomas Schilling wrote:
[I said:]
>> More: Knuth claims that writing literate programs is a win
>> even when no one other than the author is ever going to read
>> them, because the mental discipline it imposes encourages you
>> to write good code. For instance, it makes "programming by
>> coincidence" harder to get away with.
>
> But doesn't that slow you down even more? Because when you write a
> whole bunch of text around your code you have to change even more when
> you eventually find out that you have to reconstruct your
> algorithm. In my experience this happens quite often - AFAIK this is
> the main reason why the first-plan-then-code-approach fails that often.
Well, literate programming does predate the "agile" movement by several
years! On the other hand, the documentation that LP makes you write a
lot of is "close to the code" conceptually as well as physically, and
that means that you don't have the same danger as with typical
big-design-up-front methodologies, of spending a lot of time writing
big design documents that you find need changing as soon as you actually
start writing the code.
But I wouldn't advise trying to combine literate programming with,
say, eXtreme Programming. (That benefit I mentioned -- that LP
stops you getting away with programming by coincidence and makes
you articulate what you're doing and thereby forces it to make
some sort of sense -- is also a benefit of pair programming.
Interesting.)
> Ok, I agree that documenting which design decisions/changes had to be
> made is a valuable information but a sensible comment at the right
> place will do the same IMHO. Nevertheless I really appreciate a kind
> of /concept description/, possibly even at the beginning of each file
> or in a separate document. This greatly helps getting the big concept
> without commenting every precise detail - which would in fact double
> the code.
LP isn't particularly about commenting every precise detail.
The documentation in, say, "TeX: the program" is mostly
conceptual, even though there's a lot of it. But it *does*
more than double the volume of the code. Is that a bad thing?
Well, maybe. It may mean it takes longer to write (though
I'm not sure it really does, for several reasons), but if
it also means it takes less time to debug and maintain then
that may not matter. The best-known software produced by
literate programming, Knuth's TeX, is exceptionally solid
and bug-free (and also very efficient in space and time),
but it's hard to tell whether that's because it was written
by Knuth or because it was written using LP. Or because
Knuth was able to devote so much time to it; it's not all
that big a program, and he was at it for years.
> Where you do need a precise (textual desciption) and where change is
> unlikely to happen very often are complex mathematical
> algorithms. There, I think, you need a really detailed and
> comprehensive description. Often things are proved correct beforehand
> so there's not much to be modified later (without deeper thought). As
> an example it would be very hard to get the idea of bresenham's
> line-drawing-algorithms only from code, but it also will hardly be
> changed later. So a thorough description would be very useful.
Yes. I'd omit the word "mathematical", though; detailed
descriptions of what's going on would be valuable in, say,
an OS's virtual memory subsystem.
--
Gareth McCaughan
.sig under construc
I think there is a big difference between writing code that will endure
for a long time and the kind of coding that is done by the "blue-collar"
work-force for a modern corporation.
A program such as emacs or TeX naturally benefits from practices such as
literate programming because these are products that will last. The core
software does not change much because the thought processes that went
into them were systematic and detailed. Also, they do not suffer from
the pressure of the marketplace -- the same pressure that creates a
Walmart where you could have managed with your corner store. Literate
programming will never work in an atmosphere where deadlines have to be
met and the next product release is a waypoint into the plans for the
next quarterly report.
Agile methods may work in a highly disciplined environment, but they are
meant for the mass market, where everything is made of plastic and the
mould gets thrown away in time. In reality, agile techniques or XP are
practised in less disciplined circumstances -- sometimes code is also
deliberately obfuscated so programmers create a false aura of
indispensibility around them. Let's face it -- programmers have achived
the status of a guild, and methods such as XP are a form of
protectionism. Of course, real computer scientists never do such things :-)
There are interesting contrasts between the world of hardware design and
software design. Hardware design needs to be literate at one level --
even in those cases where the design involves VHDL code, you will find
that special care is given to proper design technique and documentation.
Software, on the other hand, has no cost associated with failure --
there is the principle that software problems can be fixed, which has
been papered over to mean software is too complex and impossible to make
fault-free. The truth is that careful design and proper communication of
design documents across an organisation minimises the degree to which
software is faulty. When I read a piece of code, it is nice to know what
the author was thinking when they commited their design to screen. It
will also make identification of problems a lot easier.
Today's software engineer expects a GUI and does not understand the
command line. If something does not work they need a tool manufacturer
to call -- sort of like the carpenter who does not fix furniture in his
own home. They need pictures as crutches, and cannot visualise anything
in their mind. They can blindly translate a requirement into code, but
design methodology involves sitting in front of an IDE and typing out
code. In general they spend so much time making their machines do things
that they have forgotten that people do not communicate in the C
language, and that spoken languages have metaphors and other figures of
speech unique to cultures that greatly increase the translation of an
idea to concepts that others can grasp -- I mean the muzzy headed people
that some poster was talking about. Why would a programmer write
documentation if they never learnt to write?
I think software work ethic is very different for Signal Processing code
though. DSP programmers are very secure and confident of their abilities
that their code tends to be documented well. Perhaps that is unique of
my experience -- but my conclusion is that their jobs have not been
commoditised yet.
As you may have guessed, I am not a software engineer myself -- I use
and write software occasionally as a means to an end. I have intimate
knowledge of what goes on in this milieu though, from a particular and
perhaps skewed angle, no doubt. I have seen too many cases of abuse of
the system under the guise of "XP" to the extent of tuning out when it
gets mentioned.
I'm sure I've managed to confuse the issue completely, and probably
contradicted myself several times above, but maybe there is some sense
to be made of all this, eh?:-)
In case people complain this is off topic, please note I mentioned emacs
above -- that should allow me to squeak in. Also, lest anybody in this
newsgroup feel offended, I'm sure you are all computer scientists. Of
course, I wouldn't dream of calling you mere programmers :-D Seriously,
it takes significant penance to be proficient at LISP. I think having
learnt C has made me a bad LISP programmer, but knowing a bit of LISP
has definitely made me a better C programmer.
Kumar
Kumar Balachandran <·············@earthlink.net> writes:
> In case people complain this is off topic, please note I mentioned
> emacs above -- that should allow me to squeak in. Also, lest anybody
> in this newsgroup feel offended, I'm sure you are all computer
> scientists. Of course, I wouldn't dream of calling you mere
> programmers :-D Seriously, it takes significant penance to be
> proficient at LISP. I think having learnt C has made me a bad LISP
> programmer, but knowing a bit of LISP has definitely made me a better
> C programmer.
My Phd is in scatology. I have to use a special filter to remove the
BS from my posts before they get sent out.
If real programming ever becomes like genuine factory work, I will
probably want to do something else. I wonder why former Levis
employees don't feel relieved when their jobs are off shored. Ok, I
don't. I've never felt like a guild worker though. If the jobs I
have done could have been automated, I would have automated them. I
am not a bolt turner. I like to think that there is some creativity
involved.
--
I wouldn't mind the rat race so much if it wasn't for all the damn cats.
Am Wed, 14 Apr 2004 16:22:39 +0200 schrieb Thomas Schilling
<······@yahoo.de>:
> look directly into the code as long as you need real details.
s/(you )(need)/$1don't $2/
Joe Marshall wrote:
>
> Kumar Balachandran <·············@earthlink.net> writes:
>
> > Knuth meant that people understand English, not programs. So code,
> > with or without comments is a terrible medium to communicate ideas.
>
> Sussman and Abelson disagree completely. They believe that code is an
> outstanding way to communicate ideas *precisely*.
>
They are right, but to understand that level of precision and detail
requires disciplined thought.
Since most people are unwilling or unable to invest the effort,
programmers can only communicate with such people using no more
precision and detail than those people are willing and able
to comprehend.
Thus, we have to describe these processes twice; once precisely and
completely, in code, and once in language that allows muzzy-headed
people *some* level of understanding of what's going on.
Bohr's law of communication states that you should never express
yourself more clearly than you think. This will allow more effective
communication by helping you avoid promoting false beliefs about that
which you do not fully understand.
But it's not as widely recognized that try as you may, you *can't*
express yourself more clearly than your intended audience thinks.
Anything beyond that point will only lead them to false beliefs,
thus undermining your effort to communicate the truth as surely
as if you'd said them.
More to the point; if a middle manager untrained in code tries to
puzzle out what a program does by looking at the source, he will
develop many wrong ideas. No matter how complete and precise a
description of the process that source may be, you're not going to
be able to use it to express, *TO HIM*, the correct idea of what
it does.
Bear
"Ray Dillinger" <····@sonic.net> wrote in message
······················@sonic.net...
> Since most people are unwilling or unable to invest the effort,
> programmers can only communicate with such people using no more
> precision and detail than those people are willing and able
> to comprehend.
>
> Thus, we have to describe these processes twice; once precisely and
> completely, in code, and once in language that allows muzzy-headed
> people *some* level of understanding of what's going on.
Geez, I hate that kind of attitude. Someone else mentioned and I would like
to re-enforce that code may indeed perfectly describes "what", but when you
modify it you need to know "why." Code is for the compiler that cares not a
whit for the "why" but good programmers understand that "why" is in fact
everything and they document it.
--
Coby Beck
(remove #\Space "coby 101 @ big pond . com")
Coby Beck wrote:
>
> "Ray Dillinger" <····@sonic.net> wrote in message
> ······················@sonic.net...
> > Since most people are unwilling or unable to invest the effort,
> > programmers can only communicate with such people using no more
> > precision and detail than those people are willing and able
> > to comprehend.
> >
> > Thus, we have to describe these processes twice; once precisely and
> > completely, in code, and once in language that allows muzzy-headed
> > people *some* level of understanding of what's going on.
>
> Geez, I hate that kind of attitude. Someone else mentioned and I would like
> to re-enforce that code may indeed perfectly describes "what", but when you
> modify it you need to know "why." Code is for the compiler that cares not a
> whit for the "why" but good programmers understand that "why" is in fact
> everything and they document it.
>
Of course we do. Judging by a few random samples, my code is about half
programming language for doing stuff, about a quarter comments explaining why
that's what it's doing, and about a quarter comments explaining general
theory and relationship to other parts of the code.
But there is no way on earth I'm going to be able to point an ad exec at
that; It's far too complete and it's too complex to be useful to him. He
doesn't have time to read all of the comments, will get lost in the details
anyway and fail to synthesize a whole out of all the explanations, and
doesn't have the skill to read the programming-language part of the code
itself. If he tries, he'll probably wind up believing something false
about what the code is and does.
He wants a one-page description of what a 10K line program is doing and
why; that's far far above the resolution of the code that is useful to
or normally written by a programmer. I cannot express myself (to him)
more clearly than he thinks.
People who have to write end-user documentation *need* a lot of those
details, and usually are capable of understanding them; But not all in
one chunk. When I'm working with someone who's writing detailed
documentation, I still need to sit with them, and start by directing
their attention to the roots and lower branches of the code tree, and
walking them through examples of the expected behavior and theory, so
they first understand a lower-resolution picture of what's happening.
If they don't read programming language, then I have to add to the code
a lot of documentation explaining what's happening in various sections,
even though that information is strictly redundant when it appears next
to the programming-language part of the code that does it.
The information about relationships to other parts of the code is
usually lost on them, but they do wind up usually using at least a
quarter of the internal documentation from the code. But the rest
of it is lost on them. It's in their way, semantic clutter; it's
an obstacle to them, because it's more detail and complexity than their
job allows them to deal with. They can't communicate the purpose and
workings of the code (to the users) more clearly than the users think.
But the users think about it a *lot* more clearly than the ad guy,
because they are actually using it daily and have time to think about
more than one aspect of it.
The only person who actually needs the level of detail, of both how and
why, that's found in the code, is another programmer.
Bear
In my English studies I now learned most of the concepts of this great
language. Soon I will start to surf through the dictionary and trying
out several words which oxford English offers me (I think its around
250.000+ words that ship with English).
What do you guess, how many of these words do you know off by heart? Is
it more like 30? 1000? Or even 50.000?
"Knowing" these words means in this context that you know what they mean
(and how they get understood if the form is a compound). It is not
necessary to know what their origin is or how stilted they sound...
Pascal
Andr� Thieme wrote:
> In my Lisp studies I now learned most of the concepts of this great
> language. Soon I will start to surf through the hyperspec and trying out
> several functions which ansi Lisp offers me (I think its around 850+
> functions that ship with Lisp).
>
> What do you guess, how many of these functions do you know off by heart?
> Is it more like 30? 100? Or even 540?
>
> "Knowing" these functions means in this context that you know what they
> do (and how they get evaluated if the form is a macro). It is not
> necessary to know how they are implemented or how efficient they are...
>
>
> Andr�
P.S.: You don't learn a language by trying to memorize as much as
possible. You learn a language by using it.
--
1st European Lisp and Scheme Workshop
June 13 - Oslo, Norway - co-located with ECOOP 2004
http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/
From: André Thieme
Subject: Re: How many functions do you know?
Date:
Message-ID: <c4su7i$355$1@ulric.tng.de>
Pascal Costanza wrote:
> In my English studies I now learned most of the concepts of this great
> language. Soon I will start to surf through the dictionary and trying
> out several words which oxford English offers me (I think its around
> 250.000+ words that ship with English).
Sounds like a good idea. Every pupil is doing something similar in
school. The teachers do tests where they ask for vocabulary.
Take an english book like Joyces "Ulysses" and have fun with it when you
are not a native speaker. If you really want to understand it I guess
you would have to look up at least one word per page in the dictionary.
If you follow this method on every page you soon will put the book away
or get the german version of it.
Please understand my question correctly:
I don't intend to read the hyperspec and learn every function of Lisp
and I don't suggest this to anyone.
> What do you guess, how many of these words do you know off by heart? Is
> it more like 30? 1000? Or even 50.000?
In english I guess it is around 20000, as an order of magnitude.
Andr�
--
André Thieme wrote:
>
> Pascal Costanza wrote:
>
> > What do you guess, how many of these words do you know off by heart? Is
> > it more like 30? 1000? Or even 50.000?
>
> In english I guess it is around 20000, as an order of magnitude.
>
It also depends on how you count words. A lot of the "words" we know
have a dozen or more different forms depending on tense, case, and person.
English is better about this than some languages; at least we don't
further split up our graphemes by gender, familiarity, etc. But it's
worse about it than a lot of other languages, because the rules by which
these alternative forms are created vary depending on which language
English originally stole the word from and how long English has had it
that particular word in its posession.
Dictionaries are spotty about this; some include past tenses, plurals,
perfects and participles, and some don't. Some develop rules about which
such forms they will include and which words they'll include them for (if
the word is irregular, for example).
Grady Ward's "moby word list", which lists, as nearly as I can tell, every
form of nearly every word in english, has 354984 entries. Based on six
random one-page samples of the list, I think I (a native speaker) recognize
about half these entries. But most of them I recognize only through
construction rules, or recognize from their greek/latin/german/whatever
roots, and would never have used in a sentence myself.
So, I'd guess recognized vocabulary at about 200K words, and working
vocabulary at about 20-40K words.
Bear
---
As a friend of mine once said,
"verbogeny is one of the pleasurettes of the creatific."
Andr� Thieme wrote:
> Please understand my question correctly:
> I don't intend to read the hyperspec and learn every function of Lisp
> and I don't suggest this to anyone.
I guess a better version of your original question would be: Which one
of the fields covered by the ANSI CL standard do you think you know well
by now?
Whenever I go to a conference I make the experience that I have a pretty
good time discussing CS things during the conference - so my coverage of
English seems to be relatively good in this area. However, as soon as we
leave for dinner, I can't even order a complete menu because I seem to
miss some fundamental vocabulary. (And this isn't because I can also
only talk about CS in German - I have double-checked this. ;)
For example, in your case, think about the Java API and ask yourself
which question is more meaningful: How many methods do you know well?
How many classes do you know well? Or how many packages do you know
well? (This is probably one of the few areas in which CL isn't optimal:
It has everything in one package when it would probably have been better
to define a core package and then add other stuff in dedicated packages.
This would have stopped some of the repeated discussions about good ways
how to extend the standard in the future because it would have looked
more natural just to add more packages. Anyway, I am digressing...)
The chapter structure of the HyperSpec isn't necessarily the best way to
group the functionality found in ANSI CL. The "Selected Highlights"
gives a somewhat better feel what things belong together. I actually
prefer the structuring in CLtL2. Yes, I think the best version of your
question would be: What functionality provided by CL, according to the
chapter structure in CLtL2, do you know well?
Does this make sense to you?
Pascal
--
1st European Lisp and Scheme Workshop
June 13 - Oslo, Norway - co-located with ECOOP 2004
http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/
Pascal Costanza <········@web.de> writes:
> The chapter structure of the HyperSpec isn't necessarily the best way
> to group the functionality found in ANSI CL. The "Selected Highlights"
> gives a somewhat better feel what things belong together. I actually
> prefer the structuring in CLtL2. Yes, I think the best version of your
> question would be: What functionality provided by CL, according to the
> chapter structure in CLtL2, do you know well?
I hope CLtL2 is still relevent because I am reading it now.
For purposes of vocabulary, I'm kind of glad that a number of the
words in CL are synonyms like car, first, cdr, rest, cadr, second, and
so on. That helps a bit.
I don't mind large chunks of the language being lumped together. In
Java, I always found it a pain to have to import the math package just
for some simple transcendental functions. Doing a #include in C is
almost as bad. Then some implimentations screw you by requiring that
you link in the math library. So I don't think a big core package is
so bad. The human brain can sort out classes of functionality. And
I've seen it with Perl.
I'm sure the useful subset of CL is fairly small. More is better as
you can express ideas more concisely. Ultimately, I don't think it is
the size of the language that gets in the way. If something isn't in
the language, you either get it from a library or write it yourself.
The challenge is knowing what you want to say. When you know that,
you will find a way (even if it is not the best) to express it.
--
It would not be too unfair to any language to refer to Java as a
stripped down Lisp or Smalltalk with a C syntax.
--- Ken Anderson
http://openmap.bbn.com/~kanderso/performance/java/index.html
David Steuber wrote:
> Pascal Costanza <········@web.de> writes:
>
>>The chapter structure of the HyperSpec isn't necessarily the best way
>>to group the functionality found in ANSI CL. The "Selected Highlights"
>>gives a somewhat better feel what things belong together. I actually
>>prefer the structuring in CLtL2. Yes, I think the best version of your
>>question would be: What functionality provided by CL, according to the
>>chapter structure in CLtL2, do you know well?
>
> I hope CLtL2 is still relevent because I am reading it now.
Yep, mostly. The appendixes (series, generators and gatherers) haven't
made it into the standard, and then there are a few changes. Check out
http://home.comcast.net/%7ebc19191/cltl2-ansi.htm for a list of differences.
Summary: You're definitely not wasting your time. ;)
Pascal
--
1st European Lisp and Scheme Workshop
June 13 - Oslo, Norway - co-located with ECOOP 2004
http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/
Andr� Thieme <······································@justmail.de> wrote in message news:<············@ulric.tng.de>...
> What do you guess, how many of these functions do you know off by heart?
> Is it more like 30? 100? Or even 540?
I know a few of the basic words. I haven't mastered CLOS or macros yet.
Then there is the entirely different mindset behind Lisp than there is behind C.
Andr� Thieme <······································@justmail.de> writes:
> "Knowing" these functions means in this context that you know what they
> do (and how they get evaluated if the form is a macro). It is not
> necessary to know how they are implemented or how efficient they are...
Several hundred I guess.
But even for those that I use every day, I sometimes have to check the
argument list (arglist checking in the editor is a must-have!), I never
seem to learn the difference between the GETF and GETHASH arglists :-/
--
(espen)