Loop
Josef Eschgfaeller
>> This means carefully reading the code, creating by yourself mentally
>> a sort of stack of dependencies which substitutes the indentation.
> But you don't *need* to do that, most of the time.
> intellectual progress is largely a matter of reducing the number of
> things about which we actually have to think.
Also in the beginning? I think, when after a thorough study and
admittedly sometimes arduous exercises your brain begins to automatise
those activities and reduces conscient thinking, this is different
from copying superficially a habit, without understanding.
> Itsperfectlypossibletoreadenglishwithoutspacescapitallettersorpunc
> tuationandtheresnoparticularreasonwhyonehastouseanyofthosecrutches
I did not propose to write Lisp in this way. But surely this example
shows that knowing well English grammar and words one can read it
rather well. English is not my mother language and I must read this
text with attention, for you these two lines are certainly immediately
understandable. Romans spoke Latin easily, because they knew the
elements of their language. Without these, two lines of Latin are
less comprehensible than your example, also if spaced. Romans wrote in
the other way, without spaces, you know. Arabs don't write (short)
vowels, this means precisely they do without indentation (I thought
about this when I wrote about crutches in language learning).
So, when I learn or teach Lisp, I want to know and transmit the
elements of the language. Thinking about the language, I noticed
that in contrast to C, every small Lisp function does something
significant, whereas a typical C program consists of a collection
of functions which by themselves are almost senseless, without life.
So in three of four lines of Lisp I can explain an algorithm,
sometimes of considerable complexity, and learning Lisp should, if
this is true, be useful also to people who later will use some other
language.
>> unusual notation can be. Writing X: f ---> f for a function instead
> What would you think of a mathematician who began a seminar by
> saying "In what follows, I'm going to write all my arrows the
> other way round
My intention was to say the same thing (?).
> if you insist on obfuscating your code
I don't insist. Perhaps I was surprised that people found it
obfuscating. I don't throw code to the list, as I find it. I edit
it in any case, in order to render it shorter and better understandable.
And at home I use always def instead of defun, so I have to change
that too.
In my opinion this thread is going already too long, but only to
show that there are sometimes subtle or special points: For myself
and my students I use Italian names for variables and newly defined
functions. Italian has a syntax which is very well suited for
programming, as opposed to German. Many German speaking programmers,
if I know well, prefer to program in English, because German has too
long words and an unwieldy imperative. It does not mix well with
English.
So the alternation between Italian and English words gives some
additional structure, which sometimes could substitute in part
indentation. This perhaps explains also why I wrote that one should
write a program like a letter (provoking ferocious contempt by the
list) - using Italian and English one can write really fluid and
understandable programs.
>> I like Emacs because it's so powerful, but if one prescribes
>> too much one looses some of that power.
> What power do you use by using Emacs in Lisp mode? I don't
> understand.
You mean in fundamental mode? Or perhaps you could not understand
because instead of loses I wrote looses, which perhaps here means
almost the contrary. Pronouncing the long [u:] while typing the oo
came out. For me the power is that Emacs is programmable, and with
those little functions in .emacs, which I can create or change at any
moment, I can manage all those thousands of files in which I write, much
better than in a database. Emacs was for me one of the first evidences
for the power of Lisp. I'm writing this reply on Emacs. Look at this
line:
(define-key global-map [f2] 'string-rectangle)
This is not even a function, but allows me to reproduce the > in replies
after selecting your text. I would however distinguish the discussion
about Lisp from that about Emacs. The indentation problem is a
communication problem and so we have to agree, the editor, operating
system or interface one uses depend on personal preferences or
resources. Someone could also ask "Why don't you use the power of
Windows?" I type almost automatically, so in a special mode I
effectively have to think more. Other people who are not so quick may
certainly appreciate the "full power of Emacs". Or these:
(defun change() (interactive)
(save-buffer) (other-window 1))
(defun change-yank-change() (interactive)
(change) (yank) (change))
(define-key global-map "\C-c\C-v" 'change)
(define-key global-map [prior] 'change-yank-change)
Seems nothing. But I use the first one constantly, and the second one
is terribly useful when composing indices out of items in another file.
Only to show that I'm accustomed by myself to optimize things and how
I use the possibilities of Emacs, which I like very much and I'm
using all day.
> A suggestion: don't bother trying to understand everything about LOOP
> for the moment. Learn to do easy things with it
Yes, clear. So turning to the technical questions, somebody adviced me
to use
(loop for x from a to b by d collect x)
instead of push + nreverse and wrote "should concentrate on using
a better algorithm and forget the micro-optimization." But when I time
these, I find that they are practically equivalent, before and also
after compilation. Therefore in what sense is loop a better algorithm?
Josef Eschgfaeller
Dipartimento Matematico
Universita' di Ferrara
e...@felix.unife.it e-mail
http://felix.unife.it/ home page
Tim Bradshaw
> > Itsperfectlypossibletoreadenglishwithoutspacescapitallettersorpunc
> > tuationandtheresnoparticularreasonwhyonehastouseanyofthosecrutches
>
> I did not propose to write Lisp in this way. But surely this example
> shows that knowing well English grammar and words one can read it
> rather well. English is not my mother language and I must read this
> text with attention, for you these two lines are certainly immediately
> understandable.
I'm a native English speaker and I find it *seriously* painful to read
that text. In fact it makes me feel physically uncomfortable looking
at it too closely, presumably due to some foulup in the lower levels
of my text-reading system. I think the problem is that I can see that
there are words in there and so I'm trying to do the normal
rapid-scanning thing that people who read a lot of stuff do, and that
is totally failing to pick out any sense, leaving me in a situation
where I have to go back and behave like a small child and puzzle out
each word. It's really unpleasant! I'd be interested in knowing if
other native speakers get the same feeling from that text.
I have much the same problem from really unformatted code -- it's not
as unpleasant because the fast-scanning of code is not as wired into
my mind as text, but it is quite uncomfortable. I rely really a lot
on the visual structure of code (specifically Lisp, but other
languages too) to help me scan it at speed. And scanning stuff at
speed is really important if you don't want to have to painfully
reread your code every time you have to make a change. Seeing the
patterns in code without having to actually read it is a huge win.
There is, I agree, a problem as to why you need all this visual layout
for code but not text. I think that that's code is so brittle, so
it's important to get it *exactly* right. Kent Pitman gave a good
example I thought of very legalistic text, where the structure is
*also* very important and very brittle, and sure enough, visual layout
helps there too. Things like outliners &c are another good example.
--tim
Fernando Mato Mira
Josef Eschgfaeller wrote:
> list) - using Italian and English one can write really fluid and
> understandable programs.
About foreigners programming in English:
Professionals:
1. In unmaleable programming languages with English keywords,
writing _everything_ in English keeps continuity.
2. If you can speak English well, are are a professional programmer,
languages with non-English keywords make you barf, even if
you also speak the other one well (eg: French expert system shell
with SI ALORS SINON instead of IF THEN ELSE
3. Supporting only 1 non-English syntax severely constrains your market,
if you're a language developer.
4. IF YOU WRITE IN ENGLISH, ALMOST ANYBODY CAN READ
YOUR CODE! Rule #1 for managers. And how would you like to get some
source code in Chinese,
Indian, Persian, even German? [If you're a paranoid, you could break
this rule just to make it harder on foreign pirates that somehow got your
source code]
Students
1. As you said, keep the keywords in your maleable language _standard_
(i.e.,
do not teach `italian Lisp').
2.Writing the rest in Italian might help a bit the non-fluent ones (while
brilliant bigots will think "loser environment", but that's OK). However, if
this are CS students, shouldn't they be looking at English
in ALL their courses? I would not hire anybody who can't _read_ English
effectively (it's a must to be up to date).
Mark K. Gardner
>Josef Eschgfaeller <e...@felix.unife.it> writes:
>
>> > Itsperfectlypossibletoreadenglishwithoutspacescapitallettersorpunc
>> > tuationandtheresnoparticularreasonwhyonehastouseanyofthosecrutches
>>
>> I did not propose to write Lisp in this way. But surely this example
>> shows that knowing well English grammar and words one can read it
>> rather well. English is not my mother language and I must read this
>> text with attention, for you these two lines are certainly immediately
>> understandable.
>
>that text. In fact it makes me feel physically uncomfortable looking
>at it too closely, presumably due to some foulup in the lower levels
>of my text-reading system. I think the problem is that I can see that
>there are words in there and so I'm trying to do the normal
>rapid-scanning thing that people who read a lot of stuff do, and that
>is totally failing to pick out any sense, leaving me in a situation
>where I have to go back and behave like a small child and puzzle out
>each word. It's really unpleasant! I'd be interested in knowing if
>other native speakers get the same feeling from that text.
I too find it unpleasant. I become impatient. Such a simple sentence
should not take so long to decypher so I dismiss it. There are plenty
of important, well formatted sentences for me to spend time on. Why
should I waste time on unformatted ones?
The crux of the indentation matter appears to me to be: redundency
increases fault tolerance (as KMP has said) and allows me to scan more
quickly than if redundency did not exist. The greatest difficulty I
had initially learning Lisp is not the simple syntax with lots of
parenthesis (which I admire for its elegance), but its the lack of
redundency which makes rapid scanning difficult. Indention adds
redundency and solves much of the scanning problem for me. (Good tools
and familiarity are solving the rest.)
I feel that the most important reason for conforming to indention
conventions is to communicate effectively. To become a member of the
Lisp community, I must "speak the language" that the community speaks.
That language includes indention idoms. If I refuse to speak the
language, I will forever remain on the outside.
Mark
--
Mark K. Gardner (mkga...@cs.uiuc.edu)
University of Illinois at Urbana-Champaign
Real-Time Systems Laboratory
--
Pierre R. Mai
> > > Itsperfectlypossibletoreadenglishwithoutspacescapitallettersorpunc
> > > tuationandtheresnoparticularreasonwhyonehastouseanyofthosecrutches
>
> I'm a native English speaker and I find it *seriously* painful to read
> that text. In fact it makes me feel physically uncomfortable looking
> at it too closely, presumably due to some foulup in the lower levels
> of my text-reading system. I think the problem is that I can see that
> there are words in there and so I'm trying to do the normal
> rapid-scanning thing that people who read a lot of stuff do, and that
> is totally failing to pick out any sense, leaving me in a situation
> where I have to go back and behave like a small child and puzzle out
> each word. It's really unpleasant! I'd be interested in knowing if
> other native speakers get the same feeling from that text.
Well, I'm not a native speaker, though I lived in London and
SHAPE/Belgium[1] for 3 years each, and learned English while I was
fairly young (because of computers, no less). Yet I seem to
experience the same kind of feeling, though possibly not as intense.
Regs, Pierre.
Footnotes:
[1] NATO Headquarters in Europe, which although it lies in the
french-speaking part of Belgium (near Mons), caused me to learn
more English than French for fairly obvious reasons...
--
Pierre Mai <pm...@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
Pierre R. Mai
> > list) - using Italian and English one can write really fluid and
> > understandable programs.
>
> About foreigners programming in English:
>
> Professionals:
>
> 1. In unmaleable programming languages with English keywords,
> writing _everything_ in English keeps continuity.
Yes, it keeps continuity, and I have to agree with previous comments,
that German is especially unsuitable for programming. OTOH there are
domains which use quite specialized vocabulary, which isn't easily
translated between languages without loosing a lot of the meaning (or
having to paraphrase a lot, which would lead to even uglier names).
In those cases it is IMHO preferable to stay with the local language
to name the domain-specific constructs/objects. This sadly breaks the
continuity, because you are now confronted with english keywords and
support functions, intermingled with german high-level names, which I
find breaks my flow of thought quite often.
> 2. If you can speak English well, are are a professional programmer,
> languages with non-English keywords make you barf, even if
> you also speak the other one well (eg: French expert system shell
> with SI ALORS SINON instead of IF THEN ELSE
True. I especially detest the tendency to translate keywords in
application macro languages, and fail to allow a german version of the
application to read a file which uses the english keywords (or
vice-versa for that matter). If it indeed has to be translated, at
least make it a matter of presentation only.
Regs, Pierre.
Gareth McCaughan
[I wrote:]
>> But you don't *need* to do that, most of the time.
...
>> intellectual progress is largely a matter of reducing the number of
>> things about which we actually have to think.
>
> Also in the beginning? I think, when after a thorough study and
> admittedly sometimes arduous exercises your brain begins to automatise
> those activities and reduces conscient thinking, this is different
> from copying superficially a habit, without understanding.
Who's suggesting "copying superficially a habit, without
understanding"? "Without having to recapitulate the long
exploratory process that showed the habit to be a good one",
perhaps; but we all do that when e.g. we learn to write
numbers using a place-value system rather than something
like Roman numerals. You might say that we don't *really*
understand why that's better because we haven't got there
by going through years of arduous arithmetic with Roman numerals
before deciding that there must be a better way. I don't think
that makes it any less right for us to use place-value notation.
Similarly, programmers generally learn the benefits of indentation
by being told about them by other more experienced programmers,
who in turn were told by others, and so on. (But this chain does
end; if you go back a bit you find programmers who discovered for
themselves that indentation helps to make programs much more
readable.)
If this is "copying superficially a habit", I'm all for it.
That's how I learned most of the things I know. Deeper understanding
comes later.
>> Itsperfectlypossibletoreadenglishwithoutspacescapitallettersorpunc
>> tuationandtheresnoparticularreasonwhyonehastouseanyofthosecrutches
>
> I did not propose to write Lisp in this way.
Sure. I was being a little unfair. (English without spaces is
probably more like Lisp with all parentheses replaced with spaces.)
My point is just that "it's possible to read this" and "it's easy
to read this" are very far from equivalent.
> But surely this example
> shows that knowing well English grammar and words one can read it
> rather well. English is not my mother language and I must read this
> text with attention, for you these two lines are certainly immediately
> understandable.
"Immediately"? I reckon I can read material formatted that way
at about the same speed that I can talk; maybe slightly faster.
But I read ordinary English much faster than that, and when
I'm skimming through a body of text looking for something in
particular, I go very much faster again. I can't skim-read
text with no spaces. *This* is very close to the situation
with Lisp indentation. It's much harder to make sense of without
reading everything, and that's something you need to be able to
do.
> Romans spoke Latin easily, because they knew the
> elements of their language. Without these, two lines of Latin are
> less comprehensible than your example, also if spaced. Romans wrote in
> the other way, without spaces, you know.
Yes. But nowadays, notice, all the languages descended from Latin
are written with spaces. Why? Because we've discovered it's easier
to read them that way. Just as nowadays almost all programmers
indent their code, because decades of experience showed that it's
easier to read indented code. So now we don't all have to go
through those decades before discovering the value of indentation.
> Arabs don't write (short)
> vowels, this means precisely they do without indentation (I thought
> about this when I wrote about crutches in language learning).
I don't know anything about Arabic. I do remember being told that
Hebrew is much slower to read (even for natives) than English,
largely because the vowels tend to get omitted.
> So, when I learn or teach Lisp, I want to know and transmit the
> elements of the language. Thinking about the language, I noticed
> that in contrast to C, every small Lisp function does something
> significant, whereas a typical C program consists of a collection
> of functions which by themselves are almost senseless, without life.
Well, C is a lower-level language than Lisp, so of course a typical
C program will have to contain functions that don't do very much.
But a good C program that does something interesting will also contain
functions that do entirely meaningful things.
I just did a little test of your assertion: I looked at a random
collection of functions from a large C program (a chess-playing
program called Crafty). Almost all of them were doing meaningful
things: test whether a piece is vulnerable to immediate capture,
assess a position on the basis of each side's passed pawns, decide
whether a position is an opening, middle-game or endgame position,
perform the alpha-beta search that drives the evaluation, etc.
I agree with you that Lisp is a much nicer language than C, and
that you can say a lot more in a short space in Lisp than in C.
But I don't like to see true statements supported by false ones.
>>> unusual notation can be. Writing X: f ---> f for a function instead
>> What would you think of a mathematician who began a seminar by
>> saying "In what follows, I'm going to write all my arrows the
>> other way round
>
> My intention was to say the same thing (?).
Well, your point seemed to be that a mathematician with annoying
notation wouldn't be a serious problem; whereas I think that
annoying notation can be a *very* serious problem. So I gave
a more extreme example than yours. :-)
> So the alternation between Italian and English words gives some
> additional structure, which sometimes could substitute in part
> indentation. This perhaps explains also why I wrote that one should
> write a program like a letter (provoking ferocious contempt by the
> list)
I didn't see furious contempt. I did see people saying "Why a
*letter*?", which you haven't really answered.
> - using Italian and English one can write really fluid and
> understandable programs.
Understandable to others who are bilingual in English and Italian,
or good at guessing meanings of words in languages they don't know,
perhaps.
>>> I like Emacs because it's so powerful, but if one prescribes
>>> too much one looses some of that power.
>
>> What power do you use by using Emacs in Lisp mode? I don't
>> understand.
>
> You mean in fundamental mode? Or perhaps you could not understand
> because instead of loses I wrote looses, which perhaps here means
> almost the contrary.
Oops. I meant "lose", not "use". (Nor "loose"!) In other words:
what couldn't you do in Lisp mode that you can in fundamental mode?
>> A suggestion: don't bother trying to understand everything about LOOP
>> for the moment. Learn to do easy things with it
>
> Yes, clear. So turning to the technical questions, somebody adviced me
> to use
>
> (loop for x from a to b by d collect x)
>
> instead of push + nreverse and wrote "should concentrate on using
> a better algorithm and forget the micro-optimization." But when I time
> these, I find that they are practically equivalent, before and also
> after compilation. Therefore in what sense is loop a better algorithm?
It's not a better algorithm. The point is that because it's
more concise you are less likely to get lost in details, and
therefore more likely to be able to spot algorithmic improvements.
If you write
(loop for x from a to b by d collect x)
rather than
(do ((j a (+ j d))
(result nil))
((>= j b) (nreverse result))
(push j result))
then
- it's about half as much code, and 1/4 as many lines with
most people's indentation conventions;
- it's therefore twice as fast to type
- it takes quite a lot less than half as long to *write*
(or at least it does for me; I found that I had to think
for the best part of a second at a couple of places while
writing the iterative version)
- it's quicker to read
but all these are minor points, compared to the one that actually
matters:
- when it's embedded in something more complicated, it doesn't
clutter up your screen and your mind with unimportant stuff;
you can see *instantly* and *unthinkingly* what it does.
Now, perhaps cleverer people than me (and, more to the point,
people who use DO more than me) can see *instantly* what that
DO-loop does. But I wonder. Its meaning would be considerably
changed if e.g. >= became > or <=, or if the NREVERSE were
omitted, but the result would still be a meaningful piece of
code. That suggests to me that it probably *isn't* possible to
read the DO-code as fast as the LOOP-code; and, more to the
point, it probably isn't possible to do so with as little
mental effort.
--
Gareth McCaughan Dept. of Pure Mathematics & Math. Statistics,
Gareth.M...@pobox.com Cambridge University, England.
Thomas A. Russ
> Yes, it keeps continuity, and I have to agree with previous comments,
> that German is especially unsuitable for programming.
I think this is an unfair characterization. There are several
advantages to using German for programming:
(1) No need to insert hyphens when typing compound name identifiers.
To borrow from Mark Twain, one wouldn't need to write
declarations-of-independence
instead one could just write
Unabhaengigkeitserklaerungen
(2) The language structure is well suited for stack-oriented, postfix
languages. Postscript should have been written with German
operators!
:) :0 =:o :) :0 =:o :) :0 =:o :) :0 =:o
--
Thomas A. Russ, USC/Information Sciences Institute t...@isi.edu
Fernando Mato Mira
"Thomas A. Russ" wrote:
> (2) The language structure is well suited for stack-oriented, postfix
> languages. Postscript should have been written with German
> operators!
Japanese rUl3Z! ;-)
Erik Naggum
| I too find it unpleasant. I become impatient. Such a simple sentence
| should not take so long to decypher so I dismiss it. There are plenty of
| important, well formatted sentences for me to spend time on. Why should I
| waste time on unformatted ones?
I gotta agree with this. I also skip poorly formatted USENET articles,
ignore people who can't spell, and get upset with people who _defend_
the ignorance and incompetence producing them.
in this particular case, however, I ran a small test on myself that
surprised me. it's easy to produce the "condensed" text style that
Gareth McCaughan used as an example, so I took a bunch of unknown texts
and tried to time my own reading speed. I consistently got differences
of a factor between 70 and 100, which I just couldn't believe, so I had
to try many times. if I worked really hard, I could get it down to a
factor of 50. that is, I normally read very fast, and having to piece
together word boundaries, rejoin lines mentally to find broken words,
figure out sentence ends, etc, had me bogged down. now, the surprising
part is that it didn't _feel_ like it was that big a difference, which
I'm sure is due to the same principle that led people to believe that a
compiler was fast if they got to watch a running line counter: activating
the sense of action. now, the counter-experiment was to read slowly, so
that the factor would become smaller. I found that I lost concentration
when I got down to a factor of 25, but when I tried to read the words one
by one and thinking about its role in the grammer, I managed to be only
10 times faster than the condensed text, but I couldn't remember what I
had read, but I _could_ explain the sentence structure very well.
to someone who reads and types atrociously slowly and whose mind doesn't
really work all that well to begin with (imagineน an autistic cripple who
types with his right big toe only and who uses his head to move a huge
magnifying glass that shows one letter at a time), I'm sure the pain and
suffering of typing spaces and formatting text or code nicely for others
to read is tremendously hard to deal with, and very different values of
"optimal" may consequently apply. e.g., add "blind" to the above, and
you probably have a person whose Braille printer or electronic voice
probably ignores (the then useless) whitespace, anyway.
| I feel that the most important reason for conforming to indention
| conventions is to communicate effectively. To become a member of the
| Lisp community, I must "speak the language" that the community speaks.
| That language includes indention idoms. If I refuse to speak the
| language, I will forever remain on the outside.
this is very important. however, many programmers are taught to program
in virtual isolation, and there is seldom an "oral tradition" that they
feel a desire to be part of. some of this is because most programming
languages have only been around for a decade at best, and there is not
all that much to form a community around to begin with. Lisp is very
different in this regard: it is the language _of_ a community.
#:Erik
-------
น or not, if you are offended by such images
--
@1999-07-22T00:37:33Z -- pi billion seconds since the turn of the century
Barry Margolin
>* mkga...@cs.uiuc.edu (Mark K. Gardner)
>| I too find it unpleasant. I become impatient. Such a simple sentence
>| should not take so long to decypher so I dismiss it. There are plenty of
>| important, well formatted sentences for me to spend time on. Why should I
>| waste time on unformatted ones?
>
> I gotta agree with this. I also skip poorly formatted USENET articles,
> ignore people who can't spell, and get upset with people who _defend_
> the ignorance and incompetence producing them.
What about people who use their own, ideosyncratic way of marking quotes in
followups? :-)
--
Barry Margolin, bar...@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, 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.
Rob Warnock
+---------------
| What about people who use their own, ideosyncratic way of marking
| quotes in followups? :-)
What about them? ;-}
-Rob
-----
Rob Warnock, 8L-855 rp...@sgi.com
Applied Networking http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
1600 Amphitheatre Pkwy. FAX: 650-933-0511
Mountain View, CA 94043 PP-ASEL-IA
Reini Urban
> I gotta agree with this. I also skip poorly formatted USENET articles,
^^^^^^^^^^^
this from someone who cannot start sentences uppercase (like myself) :)
"can spell" or "can not spell" is certainly community relative. if we
invented our own spelling rules (if consistent) we should certainly be
more tolerant about other parties spelling or formatting rules (if
consistent).
some write the term "I" uppercase (as taught in school), some lowercase
for consistency with the lowercase writing rules, starting only
"certain" names uppercase or "shouting".
i don't like (note the "wrong", or "can't spell", lowercase "i") the
exclusive attitude of a closed "community talk", the "i can correctly
spell a foreign language, but you not" attitude.
if some people are feeling this as "their home" we should take care to
be more tolerant. it certainly helps newbies or beginners to try out
asking stupid questions.
i also felt uncomfortable with josef's intendation rules, but i
wouldn't warn that i will skip over "wrongly formatted code". it's just
a lot harder to read.
btw: i like eric's attitude to defend his position with technical
arguments and samples. i certainly agree with the rest. but sometimes
he's a little bit too harsh.
--
Reini
Reini Urban
>4. IF YOU WRITE IN ENGLISH, ALMOST ANYBODY CAN READ YOUR CODE!
>Rule #1 for managers. And how would you like to get some
>source code in Chinese, Indian, Persian, even German?
>[If you're a paranoid, you could break
>this rule just to make it harder on foreign pirates that somehow got your
>source code]
how about reading the CLISP sources? the german comments?
though german is my native language i felt very uncomfortable reading
it.
it reminds me on various french sources, some schemes (older parts of
bigloo still have french documentation strings and comments) and I
really appreciate C.Jullien, C.Queinnec, M.Serrano, G. de Wailly and
others using english, even for obscure code.
BTW: most of not-english code is german and french (comments, names,
docs). strange, isn't it?
those universities really should accept english sources and docs.
recently it became better.
--
Reini