Can anyone write this recursion for simple regexp more beautifullyand clearly than the braggarts

[Phil Carmody]

Pity that nobody in industry is using Lisp... Why, if it is SOOOOO....
GOOD?...

I'd say in our office 50% of the softies use vi (vim, probably), and
50% of the softies use emacs. So 50% of them are using (a dialect of)
Lisp.

You didn't say 'developing in Lisp'.

Phil

 

[Richard Tobin]

Really, I didn't see much in there at all about C. In the few places
it was referenced, he seemed to be talking about lousy C code, which
certainly exists but by no means has a monopoly. Is there no such
thing as lousy (louthy?) Lisp code?

[/QUOTE]

No. That's the point of that article.

You just cannot write Object* a; in Lisp.
You just cannot write a**b+++c in Lisp.
[...]

I believe it was another famous Lisp hacker, David Moon, who said that
no language can prevent a bad programmer from writing bad code. The
most we can say is that some languages provide more ways for you
easily write bad code. C is, in some respects, such a language, but
in return it provides various advantages to the careful programmer.

It's not for nothing that many Lisp implementations are written at
least partly in C.

-- Richard

 

[Pascal J. Bourguignon]

No. That's the point of that article.

You just cannot write Object* a; in Lisp.
You just cannot write a**b+++c in Lisp.
[...]

I believe it was another famous Lisp hacker, David Moon, who said that
no language can prevent a bad programmer from writing bad code. [/QUOTE]

It's really harder for a lisp programmer to make a lisp program that
crashes. The only way AFAIK is to benefit from a bug in the
implementation (and I consider implementations that take the excuse of
(safety 0) to remove bound checks to be buggy).

Of course, in any language you can write a program that doesn't
implement the specifications. But this is another question, not
addressed in this paper.

The most we can say is that some languages provide more ways for you
easily write bad code. C is, in some respects, such a language, but
in return it provides various advantages to the careful programmer.

It's not for nothing that many Lisp implementations are written at
least partly in C.

The reason why is explained in the cited paper.
Notice that the best implementations are NOT written in C.

In general only a _small_ stub to hook the lisp implementation into a
unix (or posix) environment is written in C. The only Common Lisp
implementation coming to mind being written in "C" being the one that
includes 'C' in its name, namely Clisp.

 

[Alessio Stalla]

Really, I didn't see much in there at all about C. In the few places
it was referenced, he seemed to be talking about lousy C code, which
certainly exists but by no means has a monopoly. Is there no such
thing as lousy (louthy?) Lisp code?
No.  That's the point of that article.
You just cannot write Object* a; in Lisp.
You just cannot write a**b+++c in Lisp.
[...]

I believe it was another famous Lisp hacker, David Moon, who said that
no language can prevent a bad programmer from writing bad code.  

There's profound wisdom in those words.

It's really harder for a lisp programmer to make a lisp program that
crashes.   The only way AFAIK is to benefit from a bug in the
implementation (and I consider implementations that take the excuse of
(safety 0) to remove bound checks to be buggy).

This is not a property of "lisp" in general but of Common Lisp in
particular (and other dialects as well, like Scheme for example). CL
is standardized in a way that doesn't address low-level implementation
details, but a Lisp able to directly manipulate memory or directly
call OS system functions (Movitz, the Lisp 'kernel' used to implement
many CL implementations, Lisp machine dialects, ...) can crash hard,
too.

Of course, in any language you can write a program that doesn't
implement the specifications.  But this is another question, not
addressed in this paper.
Agreed.



The reason why is explained in the cited paper.
Notice that the best implementations are NOT written in C.

Not entirely in C, but almost all implementations do have at least
"[snip] a _small_ stub to hook the lisp implementation into a unix (or
posix) environment [snip]". However I fully agree to the fact that C
makes it much easier than _Common_ Lisp and Scheme to screw things up
disastrously, and is much less expressive than CL or any other modern
Lisp.

The only Common Lisp implementation coming to mind being written in "C" being the one that
includes 'C' in its name, namely Clisp.

And ECL, and probably GCL too. However, this does not really prove
anything. The first Lisp interpreters were written in machine
language, does that mean that machine language is better? (BTW, I
don't remember any CL implementation that does *not* have 'C' in its
name: _C_lisp, SB_C_L, _C_C_L, _C_MU_C_L, E_C_L, AB_C_L, G_C_L,
A_C_L... ok there's one, LispWorks).

Bye,
Alessio

 

[Nick Keighley]

On Aug 29, 10:38 pm, bolega <[email protected]> wrote:

Do you think C syntax is brain damaged ? [...]

nope. And the artical (see below) actually mentions Ada in passing
as being "better" than C. Is Ada's syntax broken?

In advance to the comment I give below I'd like to point out that C is
not my Favourite Language.


You call that article "excellent"? I've got curious and read it. Wow.
It's one of the lousiest articles I've been pointed to for quite some
time.

It didn't seem that bad to me. Parts of it were quite interesting.

After the first pages I thought the author must love that language
(lisp) so much[*]

oh, he does love Lisp. As a current learner of a Lisp-like language
(scheme) I feel like commenting on some of his views.

"[with C] numerous PDP idioms that show through"

these are?

that he got carried away, and just because of that
enthusiasm he's lacking to be precise or sophisticated in his comparisons,
deductions, and conclusions. But then the comparisons got partly even so
ridiculous that I thought this is certainly a joke, a fun paper, to subtly
promote C instead of lisp. In the end there's a note that the author was
a founder of a lisp systems vendor; while that might at least explain why
the paper is written as it is, it's nonetheless something I'd not expected
from an MIT emeritus professor in computer science, who should be, as all
scientists, obliged to to argue conclusively and fair. YMMV, of course.

yeah, such thinks as confusing precedence and getting the brackets
wrong
do happen with inexperienced C programmers but are much less likely as
you gain
experience. On the other hand a C programmer may beg to differ that

(define x1 (/ (+ (- b) (sqrt (- (* b b) (* 4 a c)))) (* 2 a)))

is better or clearer than

x1 = (-b + sqrt (b * b - 4 * a * c)) / 2 * a;

(and no, I'm not sure I got both expressions right)

He's just plain wrong on L9 (this is a list from an analysis of the
causes of
errors in a large C program) "L9. Ensure logical OR and AND tests are
correct."
he assumes this is a confusion between & and && whilst I think the
study
is talking about errors in logic- confusing && and ||.

He says = and == are a source of many errors- again this improves
with
experience. There are planty of similar pitfalls in Lisp-like
languages
for the newbie (what *is* the difference between eq? eqv? and
equal??).

I'm also dubious that a telecommunications switch (which is what the
study
was about) would be inherently better in Lisp than C. "you can run a
real-time
garbage collector every 10ms if necessary". As Tannenbaum puts it
"what you hear
as a click is the death of a thousand bits". And yes, I've heard or
Erlang.

<snip>

 

[Pascal J. Bourguignon]

Is there no such thing as lousy (louthy?) Lisp code?

No. That's the point of that article.

You just cannot write Object* a; in Lisp.
You just cannot write a**b+++c in Lisp.
[...]

I believe it was another famous Lisp hacker, David Moon, who said
that no language can prevent a bad programmer from writing bad
code.

It's really harder for a lisp programmer to make a lisp program that
crashes.

Oh, is *that* all? I can easily design and implement a programming
language in which it is impossible for programs written in it to
cause a crash. That doesn't imply that such a language is wonderful,
however - or even terribly useful.

It is not all, but it is all a thread about Fateman's paper should be
concerned with.

For the other good features of Lisp, have a look at the other threads
in cll.

 

[Alessio Stalla]

On the other hand a C programmer may beg to differ that

(define x1 (/ (+ (- b) (sqrt (- (* b b) (* 4 a c)))) (* 2 a)))

is better or clearer than

x1 = (-b + sqrt (b * b - 4 * a * c)) / 2 * a;

(and no, I'm not sure I got both expressions right)

You made a point against C in this case the C expression is
incorrect, since it does (<first part> / 2) * a, contrary to what hand-
written mathematical notation suggests:

<first part>
----------------
2 * a

You should have written <first part> / (2 * a). The Lisp version is
more verbose and harder to read as it requires more parentheses, but
avoids this kind of ambiguity entirely, as operator precedence is
syntactically apparent. With more complicated expressions, and more
meaningful variable names, Lisp's disadvantages are less evident.

 

[Pascal J. Bourguignon]

I'm also dubious that a telecommunications switch (which is what the
study was about) would be inherently better in Lisp than C.

I would totally agree with you that C and C++ are perfectly good,
possibly optimum programming languages to implement a unix kernel or a
telecommunication switch. After all, they were invented by smart
people working for AT&T.

Where I differ, is when people use C or C++ for anything else. These
are specialized languages to write a unix kernel or a telecommuniation
switch, and are not adapted to write other kinds of programs.

 

[Pascal J. Bourguignon]

You made a point against C in this case the C expression is
incorrect, since it does (<first part> / 2) * a, contrary to what hand-
written mathematical notation suggests:

<first part>
----------------
2 * a

You should have written <first part> / (2 * a). The Lisp version is
more verbose and harder to read as it requires more parentheses, but
avoids this kind of ambiguity entirely, as operator precedence is
syntactically apparent. With more complicated expressions, and more
meaningful variable names, Lisp's disadvantages are less evident.

I'm not sure. If you don't know whether a/b*c is evaluated as (a/b)*c
or a/(b*c), perhaps it would be better to write in C:

x1=(((-b)+(sqrt((b*b)-(4*a*c))))/(2*a));

and then:

% sed -e 's/[^()]//g' <<EOF
x1=(((-b)+(sqrt((b*b)-(4*a*c))))/(2*a));
(/ (+ (- b) (sqrt (- (* b b) (* 4 a c)))) (* 2 a))
EOF
((()((()())))())
((()((()())))())

 

[Nick Keighley]

On Sep 11, 12:44 pm, Nick Keighley <[email protected]>
wrote:





You made a point against C in this case the C expression is
incorrect, since it does (<first part> / 2) * a, contrary to what hand-
written mathematical notation suggests:

<first part>
----------------
    2 * a

You should have written <first part> / (2 * a). The Lisp version is
more verbose and harder to read as it requires more parentheses, but
avoids this kind of ambiguity entirely, as operator precedence is
syntactically apparent. With more complicated expressions, and more
meaningful variable names, Lisp's disadvantages are less evident.

I was less confident of the Lisp version so i checked it more
carefully...

 

[Nick Keighley]

I would totally agree with you that C and C++ are perfectly good,
possibly optimum programming languages to implement a unix kernel or a
telecommunication switch.  After all, they were invented by smart
people working for AT&T.

Where I differ, is when people use C or C++ for anything else.  These
are specialized languages to write a unix kernel or a telecommuniation
switch, and are not adapted to write other kinds of programs.

the example being discussed *was* a telecommunications switch.
I've used C and I've worked on such things and I'm not sure C is
any more optimised for them than anything else. C is "jolly fast"
and I think most people with anything appraoching a hard real-time
requirement would be a bit nervous of a garbage collector (this may
be just programmers' collective unconcious remembering mark-and-sweep
on DEC-10 or something). ericson program some (all?) of their
switches
in a functional language called erlang- apparently it parallelises
well.
But that's all I know about erlang.

I also wonder when something stops "being like a telecommunications
switch".
When the bit banging and real time goes?

 

[Pillsy]

On Sep 11, 5:11 am, (e-mail address removed) (Richard Tobin) wrote:
[...]

C is, in some respects, such a language, but in return it provides
various advantages to the careful programmer.

Compared to Lisp, C is tricky in two distinct ways. One is that it's a
lower-level language, requiring, among other things, much more
explicit (and often error-prone) work in terms of handling memory and
allowing various unsafe uses of pointers. In some circumstances, this
is actively beneficial, and in quite a few others it's not
particularly burdensome.

The other way it's tricky is in its syntax, with many levels of
precedence, different associativities, and operators that go from
being unary to binary depending on the context, and which mean
completely different things in those different contexts.

The two are unrelated. It's not at all hard to imagine a language with
C-like semantics and Lisp-like syntax.

Cheers,
Pillsy

 

[Richard Fateman]

Richard Heathfield wrote:
Is there no such

thing as lousy (louthy?) Lisp code?

Ahem.

It may help some people to look at the inspiration for my article,
namely
Weider D. Yu. “A Software Fault Prevention Approach in Coding and Root
Cause Analysis,” Bell Labs Technical Journal, vol. 3 no. 2 April-June
1998, 3–21.

which may be hard to get online free. The Lucent link in my
bibliography is broken now, but the paper is online at
http://www3.interscience.wiley.com/journal/97518972/abstract?CRETRY=1&SRETRY=0
which my library offers to me free (I suspect it is not be free in general)

Anyway, Prof. Yu explains common mistakes made -- by experienced coders
of C, and largely overlooked in debugging by other experienced coders --
in an important system with very high reliability requirements at
Lucent. (Bell System).

He comes up with a set of cautions about how to code (in C).
Most of the pitfalls he mentions can only be committed in C.
...............

To quote from my own abstract,

"a change of language can eliminate whole classes of errors".

In response to an item in this thread...
As to whether the C language was influenced by the PDP-11, Dennis
Ritchie points out http://cm.bell-labs.com/cm/cs/who/dmr/chist.html
that C (or its predecessor B) existed before the PDP-11, so
C was not designed to match the PDP-11 instruction set. My statement,
that C displays "numerous PDP idioms" ...like the use of autoincrement
and such, as well as a byte orientation (compare this to the GE635,
a word oriented machine and also at Bell Labs in the early UNIX days),
.... is not apparently a result of importing these idioms from the
hardware, as is commonly assumed.

Maybe the PDP-11 was influenced by the B or C languages?

I think that a better example of a language influenced by hardware, and
as a C rival for system building (it was used on the DEC VAX-11/780) is
BLISS, which has various versions over the years. So compared to BLISS,
C was relatively machine independent.

The belief that "software engineering" or "writing reliable programs"
is almost equivalent to "how to debug C programs" is common. See
http://www.amazon.com/Writing-Solid-Code-Microsofts-Programming/dp/1556155514

The (unfortunately unstated) point of Yu's article and (explicitly
stated) point of mine is that one should consider language choice if
reliability is important. I show that (as one possibility) it would be
rather hard to commit many of those errors in Lisp.

RJF

 

[Pascal J. Bourguignon]

Richard Heathfield wrote:
Is there no such
Ahem.

It may help some people to look at the inspiration for my article,
namely
Weider D. Yu. “A Software Fault Prevention Approach in Coding and Root
Cause Analysis,†Bell Labs Technical Journal, vol. 3 no. 2 April-June
1998, 3–21.

which may be hard to get online free. The Lucent link in my
bibliography is broken now, but the paper is online at
http://www3.interscience.wiley.com/journal/97518972/abstract?CRETRY=1&SRETRY=0
which my library offers to me free (I suspect it is not be free in general)

Seems to be accessible, after free registration with Wiley's web site.

Thanks for the link.

 

[Harald Hanche-Olsen]

which may be hard to get online free. The Lucent link in my
bibliography is broken now, but the paper is online at
http://www3.interscience.wiley.com/journal/97518972/abstract?CRETRY=1&SRETRY=0
which my library offers to me free (I suspect it is not be free in general)

Probably not. Anyway, the link as given did not work for me: I got a
complaint about cookies. Dropping the parameters and accessing it as

http://www3.interscience.wiley.com/journal/97518972/abstract

worked for me, however.

 

[Keith Thompson]

A.L. escreveu:

Because the few using Lisp have got a lot of free time in their hands
while most of the industry drags around fixing and duct-taping C-based
infrastructure holes?

Oh goody, a cross-posted language war! Those are always so
interesting and constructive.

 

[Richard Fateman]

Richard Heathfield wrote:
....

And although I am no Lisp expert

(in fact, I'm currently a "hello world" kind of guy), it seems from
my (minimal) research on the subject that it is quite difficult to
squeeze enough out of Lisp to get it anywhere near C in performance
terms.

what should one do with trolls who switch themes in mid-stream?
stop answering riddles and refuse to cross their bridges?

 

[Beej Jorgensen]

Oh goody, a cross-posted language war! Those are always so interesting
and constructive.

I'm of the opinion that both LISP and C are pretty rockin', and we all
should just go out for pints. Amen.

-Beej

 

[Thomas A. Russ]

I'm of the opinion that both LISP and C are pretty rockin', and we all
should just go out for pints. Amen.

Hmmm. Maybe we could morph this into a Beer vs. Ale discussion?

 

[James Dow Allen]

And now you've got me curious, so I've read it. It's an interesting
article, but it could be made a lot shorter.

I hereby present the full text of the proposed Second Edition:
  WHY C IS NOT MY FAVOURITE PROGRAMMING LANGUAGE
  Because I prefer Lisp.

I was also curious, came to a conclusion similar to
Mr. Heathfield's, but less succinctly....

The claim that a language like Common Lisp is, a priori,
more productive than C seems *very plausible* to me
(though I'd prefer C anyway for reasons not germane to
this discussion), and I eagerly read two of the references
cited in this thread hoping one would be articulate enough
to explain *why* Common Lisp is better.

Boy, was I disappointed. The Hudak-Jones paper, where
one of the tested languages was 'awk', seemed silly
to me. "Prototyping"? Isn't that where you write
code that pretends to do something but doesn't?
And maybe I'm embarrassingly out-of-touch, but I always
thought the set of applications where 'awk' is appropriate
and the set of applications so complex that an academic
study of productivity would be pertinent were *disjoint*
sets!

I found Fateman's paper almost as peculiar as Hudak-Jones.
That Lisp doesn't have or need pointers may be a vital difference
and it would be interesting to understand why. I'm sure
automatic garbage-collection is a big part of the answer
(and probably a big part of why Lisp is a more productive
language), but Fateman's emphasis is that Lisp programmers
cannot "incorrectly" increment or deference pointers because
there are no pointers. Is confusion between "(*n)++" and "*n++"
or between "**p" and "*p" really a major source of C's alleged
productivity problem?? If so, perhaps he just needs to hire
better C programmers. Fateman is proud that "NIL" is the
only Boolean false in Lisp. Isn't "0" the only Boolean false
in C? If Fateman posted this kind of nonsense here he'd be
accused of sophomoric trolling.

From Fateman we learn that
(equal foo bar)
is less error-prone than
foo == bar
and that
(+ (* a b) c)
"is arguably clearer" than
a*b + c

Oops, I'm misquoting Fateman. He didn't write
"a*b + c"; he wrote "a*b+c". (Given his straw-man
approach, one is almost surprised he didn't write
"a * b+c" !) In another example, he seems to
think C programmers should know what "b+++c" does,
but don't and that this is an argument against C.
(I'm not too shy to admit *I* wasn't sure what "b+++c"
does. FWIW, gcc behaves as expected when faced with
either "b+ ++c" or "b++ +c" and treats "b+++c" as the
latter. But I can't imagine the "+++" form except in a
trolling question or in an Obfuscation Contest entry.)

(BTW, gcc accepts both "a+ + + +b" and "a+ ++ +b"
without complaint but generates *different* results
for them! Is *this* compliant?)

In other words, many of Fateman's objections would
disappear on a C compiler modified to enforce
complete parenthesization. If Fateman fans want to
argue that this is insignificant trivia, then why did
Fateman ask me to waste so much time reading it?

But let's address Fateman's question. Is
(+ (* a b) c)
actually clearer than the alternative?
a*b + c
Perhaps these examples are too simple to quibble one
way or the other, but all other things being equal,
the version with less ink will be understood more
quickly!

By this measure, Fateman might win the debate with
(dolist (x Foo)
(Guzzle x))
compared with C's slightly less terse
for (x = Foo_head; x; x = x->next)
Guzzle(x);
but a C programmer might #define dolist
if tersity is all that matters.

Frankly, I'd much rather type out the for-loop
than remember what 'dolist' does, especially since
Fateman implies there's a host of such keywords
I'll need to memorize. He seems proud of a
'remove-duplicates' keyword, but *don't* tell him
you could write a remove_duplicates() function if
needed: he stipulates at the top of Page 7 that any C
function will be hard to decode and "possibly erroneous"!

I prefer fewer keywords rather than more.

It may seem that I've singled out the silliest claims
in Fateman's paper. Not really; had that been my goal I
would mention his concern that C comments "can't be nested"
or ridicule his peculiar belief that any claimed virtue
of C need not be refuted if the virtue is dropped in any
language, e.g. Java, that has C-like syntax! (see Pages 7 & 9)

As I implied above, I suspect Common Lisp actually *is*
a more productive language, and furthermore suspect that I,
knowing almost nothing about Lisp, can offer a single
clause more cogent than Fateman's entire paper!:
" ... because it's easier to blithely make copies of
data, leaving them on the floor with the peanut shells,
since Mrs. G.C. stops by to sweep up every afternoon."
I've no idea if the performance cost of the blithely-made
copies is important, but Fateman seems to think so, going
so far as to "counterattack" with a C "inefficiency":
"implementations of C typically waste some number of bits
in each 32-bit pointer for machines that have an actual
address space less than 4 gigabytes"
Wow! Great moments in Computer science. Not!

James Dow Allen