Can anyone write this recursion for simple regexp more beautifully and clearly than the braggarts
bolega
visit it twice to be explained. I am puting the excerpt from pp2-4 of
this book and the C code. The C code will become indented and syntax
highlighted once you paste in emacs etc. It is my belief and
observation on a lot of problems by these so called "demi gods" that
they are actually all average and no more intelligent. Its all that
they got some opportunities to study some things at opportune time and
facilities and also spent a lot of time in a productive environment
and team.
I know that lisp eval is written more clear than this recursion below
because I am able to read it easily. and that code is almost self
explanatory. C is more quirky. When you really mean recursively call
another function, you are using return so you can have tail
recursion ???? .
Anyway, its your chance to show how clear C/C++/lisp/Scheme code you
can write that is clearer. Also, i dont exclude pseudocode but it
should be clear enough to be instantly translatable to a programming
language. The real goal is to learn how to write or DERIVE recursion,
how to enumerate cases, order them, and build recursion. You may even
put some introductory tuturial and dont have to reply here in ascii
but can upload a pdf at some link in rapidshare etc. Look how he put
the code after problem statement and then has the need to explain it.
Ideally, the discussion should be such that the student or reader
himself jumps to the solution. That is why I give these unix school of
pike/thomson/kernighan low grade in almost all their expositions
except that they wrote earliest books to make millions of dollars in
royalties and since now they are nobody due to linux, they are poorly
regurgitating old material.
Enjoy .............
============================
The Practice of Programming
In 1998, Rob Pike and I were writing The Practice of Programming
(Addison-Wesley). The
last chapter of the book, “Notation,” collected a number of examples
where good notation
led to better programs and better programming. This included the use
of simple data specifications
(printf, for instance), and the generation of code from tables.
Because of our Unix backgrounds and nearly 30 years of experience with
tools based on
regular expression notation, we naturally wanted to include a
discussion of regular
expressions, and it seemed mandatory to include an implementation as
well. Given our
emphasis on tools, it also seemed best to focus on the class of
regular expressions found in
grep—rather than, say, those from shell wildcards—since we could also
then talk about the
design of grep itself.
The problem was that any existing regular expression package was far
too big. The local
grep was over 500 lines long (about 10 book pages) and encrusted with
barnacles. Open
source regular expression packages tended to be huge—roughly the size
of the entire
book—because they were engineered for generality, flexibility, and
speed; none were
remotely suitable for pedagogy.
I suggested to Rob that we find the smallest regular expression
package that would illustrate
the basic ideas while still recognizing a useful and nontrivial class
of patterns. Ideally,
the code would fit on a single page.
Rob disappeared into his office. As I remember it now, he emerged in
no more than an
hour or two with the 30 lines of C code that subsequently appeared in
Chapter 9 of The
Practice of Programming. That code implements a regular expression
matcher that handles
the following constructs.
Character Meaning
c Matches any literal character c.
. (period) Matches any single character.
^ Matches the beginning of the input string.
$ Matches the end of the input string.
* Matches zero or more occurrences of the previous character.
This is quite a useful class; in my own experience of using regular
expressions on a day-today
basis, it easily accounts for 95 percent of all instances. In many
situations, solving the
right problem is a big step toward creating a beautiful program. Rob
deserves great credit
for choosing a very small yet important, well-defined, and extensible
set of features from
among a wide set of options.
Rob’s implementation itself is a superb example of beautiful code:
compact, elegant,
efficient, and useful. It’s one of the best examples of recursion that
I have ever seen, and it
shows the power of C pointers. Although at the time we were most
interested in conveying
the important role of good notation in making a program easier to use
(and perhaps
easier to write as well), the regular expression code has also been an
excellent way to
illustrate algorithms, data structures, testing, performance
enhancement, and other
important topics.
Implementation
In The Practice of Programming, the regular expression matcher is part
of a standalone program
that mimics grep, but the regular expression code is completely
separable from its
surroundings. The main program is not interesting here; like many Unix
tools, it reads
either its standard input or a sequence of files, and prints those
lines that contain a match
of the regular expression.
This is the matching code:
/* match: search for regexp anywhere in text */
int match(char *regexp, char *text)
{
if (regexp[0] == '^')
return matchhere(regexp+1, text);
do { /* must look even if string is empty */
if (matchhere(regexp, text))
return 1;
} while (*text++ != '\0');
return 0;
}
/* matchhere: search for regexp at beginning of text */
int matchhere(char *regexp, char *text)
{
if (regexp[0] == '\0')
return 1;
if (regexp[1] == '*')
return matchstar(regexp[0], regexp+2, text);
Character Meaning
c Matches any literal character c.
. (period) Matches any single character.
^ Matches the beginning of the input string.
$ Matches the end of the input string.
* Matches zero or more occurrences of the previous character.
4 C H A P T E R O N E
if (regexp[0] == '$' && regexp[1] == '\0')
return *text == '\0';
if (*text!='\0' && (regexp[0]=='.' || regexp[0]==*text))
return matchhere(regexp+1, text+1);
return 0;
}
/* matchstar: search for c*regexp at beginning of text */
int matchstar(int c, char *regexp, char *text)
{
do { /* a * matches zero or more instances */
if (matchhere(regexp, text))
return 1;
} while (*text != '\0' && (*text++ == c || c == '.'));
return 0;
}
bolega
inserted in the middle although it was just one block of text.
This is the matching code:
/* match: search for regexp anywhere in text */
int match(char *regexp, char *text)
{
if (regexp[0] == '^')
return matchhere(regexp+1, text);
do { /* must look even if string is empty */
if (matchhere(regexp, text))
return 1;
} while (*text++ != '\0');
return 0;
}
/* matchhere: search for regexp at beginning of text */
int matchhere(char *regexp, char *text)
{
if (regexp[0] == '\0')
return 1;
if (regexp[1] == '*')
return matchstar(regexp[0], regexp+2, text);
if (regexp[0] == '$' && regexp[1] == '\0')
return *text == '\0';
if (*text!='\0' && (regexp[0]=='.' || regexp[0]==*text))
return matchhere(regexp+1, text+1);
return 0;
}
/* matchstar: search for c*regexp at beginning of text */
int matchstar(int c, char *regexp, char *text)
{
do { /* a * matches zero or more instances */
if (matchhere(regexp, text))
return 1;
} while (*text != '\0' && (*text++ == c || c == '.'));
return 0;
}
By the way did you note the spicy style of narration by which they
promote each other ? and can you abstract the technique of narration
for image building ? Another scum in electronic, Bob Pease of national
semiconductor writes in the same style. I know all their basic ideas
in that field, which are trivial. The only art is the art of writing
and propaganda.
The one man I have real respect for and is humble is McCarthy. He
really put some original ideas together but still did not give any
clue how he constructed them. However, in lisp recursion is lucidly
clear. You test if a thing is nil. Else you check if it is an atom and
act appropriately to call a handler and otherwise recursion.
spinoza1111
>
> - Show quoted text -
Many people seem to have been upset with this article in Beautiful
Code. I emailed Kernighan about it and received a reply (I'd met the
guy), but no real answer to the basic problem, which is that C cannot
express programming ideas clearly.
The first problem is that by being so "simple" it fails to implement a
recognizable "regular expression" processor.
I thought a second problem was that it used a value parameter as a
work area, which isn't something I would do in my languages of choice
(C Sharp and VB in recent years), but I found myself doing this in C
when I returned to the language mostly to kick the shit out it.
A third problem is praising a programmer for fast work. There's enough
slipshod work in our industry, and enough programmer overwork as it
is.
I think Brian Kernighan would be the first to admit that Lisp as
opposed to C made a more far-reaching contribution to computer science.
JustBoo
> This braggart admits that he had to put this code in TWO books and
> visit it twice to be explained. I am puting the excerpt from pp2-4
> of this book and the C code.
Well, witness yet another way, boy and girls, to market a book. We'll
be seeing a lot of it from now on I'm sure. Meh. Enjoy.
Richard Heathfield
If you mean "The Practice of Programming" (Kernighan and Pike), (a)
it's been in print for a great many years, and we've already seen a
lot of it; and (b) neither Brian Kernighan, nor Rob Pike, nor
Prentice Hall is infra dig enough to stoop to such tactics.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within
bolega
> Many people seem to have been upset with this article in Beautiful
> Code. I emailed Kernighan about it and received a reply (I'd met the
> guy), but no real answer to the basic problem, which is that C cannot
> express programming ideas clearly.
I admire the fact that someone brought all this in the public
discussion because a lot of sleazy people (not referring in particular
to this troika) have been able to propagate crap and kept it immune to
academic critique just due to people afraid of criticizing it which
leads to a lot of newbie sheeple.
Do you think C syntax is brain damaged ? Can you explain your second
point in more detail and clearly as I could not understand any of it.
> The first problem is that by being so "simple" it fails to implement a
> recognizable "regular expression" processor.
>
> I thought a second problem was that it used a value parameter as a
> work area, which isn't something I would do in my languages of choice
> (C Sharp and VB in recent years), but I found myself doing this in C
> when I returned to the language mostly to kick the shit out it.
>
> A third problem is praising a programmer for fast work. There's enough
> slipshod work in our industry, and enough programmer overwork as it
> is.
>
> I think Brian Kernighan would be the first to admit that Lisp as
> opposed to C made a more far-reaching contribution to computer science.- Hide quoted text -
Actually, in C all they did was to borrow parens and braces from math
to delimit blocks - BUT lisp already had the idea in the prefix
notation. The other contribution is the for loop with all the loop
elements at the top in the interface. The declaration syntax of
pointers is poor and ugly. switch-case has fall thru. break and
continue is new unless PL1 or BCPL had it.
BUT YOU HAVE NOT SHOWN how to structure the recursion. Does it need
NFA ? I need a tutorial because C is to stay and I can avoid some of
its ugliness by using C++ as pretty C.
> - Show quoted text -
I admire the fact that you
Thomas Munro
> ...
> Anyway, its your chance to show how clear C/C++/lisp/Scheme code you
> can write that is clearer. Also, i dont exclude pseudocode but it
> should be clear enough to be instantly translatable to a programming
> language. The real goal is to learn how to write or DERIVE recursion,
I'll ignore the discussion about Pike et al, and start out by saying
that I quite like the C code and enjoyed it in the Beautiful Code
book. It's an interesting exercise for a learner and I'm feeling
reckless today, so here go my first two attempts at expressing it in
Lisp. It seems to me that the C code is short and sweet because of the
following characteristics of the language:
1. You can pass pointers into the middle of strings.
2. Strings are null terminated.
3. Variables can be post-incremented while appearing in an
expression.
Most Lisps can achieve at least [1] and [2] if they use lists of
characters rather than a string type. First, I translated the
algorithm into Scheme, using lists of characters (hopefully without
introducing any bugs, but I'm not sure yet, it seems to work):
=== Begin program #1 ===
;;; Check if the pattern REGEX matches the front of TEXT.
(define (matches-here? regex text)
(cond ((null? regex) #t)
((and (not (null? (cdr regex)))
(char=? (cadr regex) #\*))
(matches-star? (car regex) (cddr regex) text))
((and (char=? (car regex) #\$)
(null? (cdr regex)))
(null? text))
((and (not (null? text))
(or (char=? (car regex) #\.)
(char=? (car regex) (car text))))
(matches-here? (cdr regex) (cdr text)))
(else #f)))
;;; Check if TEXT starts with 0 or more of CHARACTER followed by
REGEX.
(define (matches-star? character regex text)
(or (matches-here? regex text)
(and (not (null? text))
(or (char=? character (car text))
(char=? character #\.))
(matches-star? character regex (cdr text)))))
;;; Check if the pattern REGEX matches the character list TEXT.
(define (matches-list? regex text)
(cond ((null? regex) #t)
((char=? (car regex) #\^)
(matches-here? (cdr regex) text))
(else
(let loop ((text-tail text))
(if (null? text-tail)
#f
(or (matches-here? regex text-tail)
(loop (cdr text-tail))))))))
;;; Check if the pattern in the string REGEX matches the string TEXT.
(define (matches? regex text)
(matches-list? (string->list regex)
(string->list text)))
=== End program #1 ===
Converting strings into lists every time doesn't seem like a great
idea though. (Maybe Clojure can offer an iterator/list type view of a
string without converting it to a list?) To implement this algorithm
using real string types in the Lisp dialects that I know, you'd have
to use an offset (index). To avoid having to pass around the string
AND the offset for both strings, I guess the best approach is to use
internal definitions that can see the strings, so only the indexes
need to be passed around. This time I used Emacs Lisp (it's probably
also valid Common Lisp if you change the character literal syntax and
character comparison functions).
=== Begin program #2 ===
(require 'cl) ;; for LOOP and LABELS
(defun regex-matches-p (regex text)
"Check if the pattern in string REGEX matches the string TEXT."
(let ((regex-length (length regex))
(text-length (length text)))
(labels ((matches-here-p (regex-index text-index)
(cond ((= regex-index regex-length) t)
((and (< regex-index (- regex-length 1))
(= (elt regex (+ regex-index 1)) ?*))
(matches-star-p (elt regex regex-index)
(+ regex-index 2)
text-index))
((and (= (elt regex regex-index) ?$)
(= regex-index (- regex-length 1)))
(= text-index text-length))
((and (< text-index text-length)
(or (= (elt regex regex-index) ?.)
(= (elt regex regex-index)
(elt text text-index))))
(matches-here-p (+ regex-index 1) (+ text-index
1)))
(t nil)))
(matches-star-p (character regex-index text-index)
(or (matches-here-p regex-index text-index)
(and (< text-index text-length)
(or (= character (elt text text-index))
(= character ?.))
(matches-star-p character
regex-index
(+ 1 text-index))))))
(if (and (> (length regex) 0) (= (elt regex 0) ?^))
(matches-here-p 1 0)
(loop for text-index from 0 to text-length
thereis (matches-here-p 0 text-index))))))
=== End program #2 ===
I'm looking forward to seeing some expert implementations. Mine
probably have bugs and are not as pretty as I hoped when I started out
with a cup of coffee and a blank screen this morning. (Removed cross-
posting to C/C++/Unix related groups in which context this post seemed
like trolling.)
Thomas
Ed Morton
> This braggart admits that he had to put this code in TWO books and
> visit it twice to be explained. I am puting the excerpt from pp2-4 of
> this book and the C code.
You should post this to comp.lang.c.
Ed.
Pascal J. Bourguignon
> Converting strings into lists every time doesn't seem like a great
> idea though. (Maybe Clojure can offer an iterator/list type view of a
> string without converting it to a list?) To implement this algorithm
> using real string types in the Lisp dialects that I know, you'd have
> to use an offset (index). To avoid having to pass around the string
> AND the offset for both strings, I guess the best approach is to use
> internal definitions that can see the strings, so only the indexes
> need to be passed around.
Indeed, closures can help. You can make pointers with them:
(defun send (o m &rest args) (apply o m args))
(defun make-character-pointer (string &optional (offset 0))
(if (or (< offset 0) (<= (length string) offset))
(error "Out of bound")
(lambda (m &optional c)
(ecase m
((ref) (aref string offset))
((set) (setf (aref string offset) c))
((inc) (if (< offset (length string))
(incf offset)
(error "Out of bound")))
((dec) (if (< 0 offset)
(decf offset)
(error "Out of bound")))
((str) string)
((off) offset)
((eq) (and (eq (send c 'str) string) (= offset (send c 'off))))
((lt) (and (eq (send c 'str) string) (< offset (send c 'off))))
((dif) (if (eq (send c 'str) string)
(- offset (send c 'off))
(error "Non congruent pointers")))))))
(defun setmem (start end char) ; void setmem(char* start,char* end,char chr){
;; Look Ma! No string, no index!
(loop while (send start 'lt end) ; while(start<end){
do (send start 'set char) ; (*start)=chr;
(send start 'inc))) ; start++; }}
(let ((str (make-string 20 :initial-element #\-)))
(setmem (make-character-pointer str 5) ; &(str[5])
(make-character-pointer str 15) ; &(str[15])
#\+)
str)
--> "-----++++++++++-----"
--
__Pascal Bourguignon__
A.L.
Very good way to market a book. Something criticized on c.l.l. must be
really good.
Ordered from Amazon 5 minutes ago.
A.L.
bolega
please dont derail my thread, BUT, you ordered the wrong book. The one
you SHOULD have ordered is this one:
Book Review
--------------------------------------------------------------------------------
Advanced C Struct Programming by John W.L. Ogilvie
Highly Recommended
ISBN: 0-471-51943-X Publisher: Wiley Pages: 405pp
Price: £22.95
Categories: advanced c data structures
Reviewed by Francis Glassborow in C Vu 3-2 (Jan 1991)
This is the kind of book that I might easily miss on a casual visit
to
my local bookshop. In all honesty my first impression when I opened
it
was not that good. It is aimed at people who wish to take programming
seriously yet it first seemed more like the kind of text that I am
used to finding on the hobbyists shelves. It is much better than
that.
When you have mastered the foothills of programming in C, have a good
runtime library reference on your shelf and, perhaps, have invested
in
a book on data structures and another on programming algorithms or
techniques what do you get to help you develop good medium size
programs (all right large ones if you must)?
If you had asked my advice a month ago, I would have hummed and hawed
and come up with a couple of titles and then suggested that what you
really wanted was a book on program/data design rather than one on C.
Advanced C Struct Programming tackles this need. The author's
declared
intent is to present a practical method for designing and
implementing
complex (complicated) data structures in C. In doing so he leads you
through experience (sometimes of false trails) in tackling a number
of
different programming problems.
The book does not include complete applications or libraries of
source
code. It is a book to be worked through. By the time you have
finished
it you should be a much better programmer. Let me warn you that it is
not a book to dip into in that odd spare moment. If that is all you
have time for then go and do something else.
On the other hand it is not like some of the books above that will
take you years to fully grasp (if ever). Buy this book, set aside a
regular time to work at it, stick to your routine and find yourself
becoming far more professional in your programming.
Yes, I like it and it is not machine dependant. For once I am glad
that the supporting discs are relatively expensive ($39.95 in IBM and
Apple Mac formats) as I think that you will only get the full benefit
by grafting at the keyboard yourself.
--------------------------------------------------------------------------------
Last Update - 13 May 2001.
To link to this review, please use the URL:
http://www.accu.org/bookreviews/public/reviews/a/a000142.htm
Copyright © The Association of C & C++ Users 1998-2000. All rights
reserved.
Mirrored from http://www.accu.org/
A.L.
wrote:
>On Aug 29, 8:53�am, A.L. <alewa...@aol.com> wrote:
>> On Sat, 29 Aug 2009 07:10:59 -0700, JustBoo <B...@boowho.com> wrote:
>> >bolega wrote:
>> >> This braggart admits that he had to put this code in TWO books and
>> >> visit it twice to be explained. I am puting the excerpt from pp2-4
>> >> of this book and the C code.
>> >[...]
>>
>> >Well, witness yet another way, boy and girls, to market a book. We'll
>> >be seeing a lot of it from now on I'm sure. Meh. Enjoy.
>>
>> Very good way to market a book. Something criticized on c.l.l. must be
>> really good.
>>
>> Ordered from Amazon 5 minutes ago.
>>
>> A.L.
>
>please dont derail my thread, BUT, you ordered the wrong book. The one
>you SHOULD have ordered is this one:
>
>Book Review
>---------------------------------------------------------------------------�-----
>Advanced C Struct Programming by John W.L. Ogilvie
>Highly Recommended
>ISBN: 0-471-51943-X Publisher: Wiley Pages: 405pp
>Price: �22.95
I have this book already.
Regarding this one that I ordered - Amazon has 30 days return
policy...
A.L.
Chris McDonald
Richard Heathfield
By the walks-like,swims-like,quacks-like theorem, I do see why you
think so, but I think we should be slow to make such accusations,
since they are so often wrong. I have never actually been accused of
being a sock puppet as far as I am aware, but I have certainly been
accused of running them (which I have never done, but of course those
who accuse me don't believe that).
People can and often do use similar styles, especially when responding
to people with whom they're perhaps not the best of friends. The
other day, an irregular poster, a guy - who'd been away for a while
and is unlikely to have become familiar with my occasional habit of
marking nilgewater with "nonsense snipped - nothing left" - made
precisely the same response. It would be easy to accuse /him/ of
being a sock puppet... and yet his name has been well-known in
another group for many years and he knows far more about that group's
subject than I do, and I vaguely recall having a few extended
disagreements with him in the past. He also posts from a different
continent, by the way.
Sock puppets undoubtedly happen, but they don't really matter because
what counts is not who says what, but what they say (and, to a
certain extent, how they say it). We might pay a lot of attention to
a name we recognise (e.g. if Donald Knuth started posting, we'd sit
up and take notice) - but *only* after it became obvious that it
wasn't some spotty teenager mucking about. And we judge that by
content. "By their fruits you shall know them" and all that.
In the current case, bolega (unknown name, to me at least) is slagging
off Brian Kernighan and Rob Pike (both names known to me) and their
book (which I've read). He starts with the word "braggart", and the
rest is similar ranting. It's just perfectly normal bilgewater of the
sort you often find on the Internet, but I don't see why we need to
accuse it of being nilgewater as well.
w_a_x_man
> the code after problem statement and then has the need to explain it.
> Ideally, the discussion should be such that the student or reader
> himself jumps to the solution. That is why I give these unix school of
> pike/thomson/kernighan low grade in almost all their expositions
> except that they wrote earliest books to make millions of dollars in
> royalties and since now they are nobody due to linux, they are poorly
> regurgitating old material.
Kernighan fails to correct the bugs in his programs.
Download his awk here:
http://cm.bell-labs.com/cm/cs/who/bwk/awk95.exe
Test it with this program:
BEGIN {
# Specify the field-separator.
FS = "!"
text = "foo!bar"
$0 = text
# Should print "foo".
print $1
printf "Press <ENTER>: "
getline junk
$0 = text
print $1
}
pk
That program triggers several undefined behaviors, so I'd not say bwk's awk
is buggy based only on the outcomes of that code.
A.L.
<thomas...@gmail.com> wrote:
>=== Begin program #1 ===
>
>;;; Check if the pattern REGEX matches the front of TEXT.
>(define (matches-here? regex text)
> (cond ((null? regex) #t)
>;;; Check if the pattern REGEX matches the character list TEXT.
>(define (matches-list? regex text)
> (cond ((null? regex) #t)
> ((char=? (car regex) #\^)
> (matches-here? (cdr regex) text))
> (else
> (let loop ((text-tail text))
> (if (null? text-tail)
> #f
> (or (matches-here? regex text-tail)
> (loop (cdr text-tail))))))))
>
>;;; Check if the pattern in the string REGEX matches the string TEXT.
>(define (matches? regex text)
> (matches-list? (string->list regex)
> (string->list text)))
>
>
>probably have bugs and are not as pretty as I hoped when I started out
>with a cup of coffee and a blank screen this morning. (Removed cross-
>posting to C/C++/Unix related groups in which context this post seemed
>like trolling.)
No. They will be happy. An their response will be: "Can you imagine
100K lines of TRASH LIKE THIS?"
A.L.
Richard Harter
<r...@see.sig.invalid> wrote:
>In <h7cc1a$e6g$1...@enyo.uwa.edu.au>, Chris McDonald wrote:
<snip>
>In the current case, bolega (unknown name, to me at least) is slagging
>off Brian Kernighan and Rob Pike (both names known to me) and their
>book (which I've read). He starts with the word "braggart", and the
>rest is similar ranting. It's just perfectly normal bilgewater of the
>sort you often find on the Internet, but I don't see why we need to
>accuse it of being nilgewater as well.
Just so. The two styles are quite distinct. Generally speaking
those who use the internet for ranting have quite individual and
distinct styles. Thus Nilges is clearly well educated and well
read, using many post modern and progressive tropes along with
pop psychology. On the other hand Bolega (I thought it might be
a sausage but apparently it is a brand of socks) is less well
read and less literate.
Incidentally, in my opinion the term "troll" isn't appropriate
for such persons. Trolls are like malicious little children who
stir up trouble for the pleasure of seeing people get all
excited. These ranters have a different agenda.
Richard Harter, c...@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
No one asks if a tree falls in the forest
if there is no one there to see it fall.
Beej Jorgensen
>Kernighan fails to correct the bugs in his programs.
Somewhat contrary to this, Kernighan's awk source comes with a 1000-line
file describing 20 years-worth of awk bugfixes. (I don't doubt there
are still bugs in awk, however.)
-Beej
mjc
Works fine with gawk, which is what most of us use anyway.
Chris Dollin
(re: the Beautiful Code RE matcher)
> The first problem is that by being so "simple" it fails to implement a
> recognizable "regular expression" processor.
False. It implements a /useful subset/ of REs and provides a framework
for adding more features -- it's an educational tool, not a library
component.
--
"I have travelled far and wide upon this journey." - The Reasoning,
/A Musing Dream/
Hewlett-Packard Limited registered office: Cain Road, Bracknell,
registered no: 690597 England Berks RG12 1HN
spinoza1111
> On Aug 29, 2:51 am,spinoza1111<spinoza1...@yahoo.com> wrote:
>
> > Many people seem to have been upset with this article in Beautiful
> > Code. I emailed Kernighan about it and received a reply (I'd met the
> > guy), but no real answer to the basic problem, which is that C cannot
> > express programming ideas clearly.
>
> I admire the fact that someone brought all this in the public
> discussion because a lot of sleazy people (not referring in particular
> to this troika) have been able to propagate crap and kept it immune to
> academic critique just due to people afraid of criticizing it which
> leads to a lot of newbie sheeple.
>
> Do you think C syntax is brain damaged ? Can you explain your second
> point in more detail and clearly as I could not understand any of it.
Read this excellent article: Software Fault Prevention by Language
Choice: Why C is Not My Favorite Language, Richard Fateman. Fateman is
on the faculty of the rather C-centric Univ of California at Berkeley.
http://www.eecs.berkeley.edu/~fateman/papers/software.pdf.
My current language C Sharp addresses some but not all of Fateman's
points.
>
> > The first problem is that by being so "simple" it fails to implement a
> > recognizable "regular expression" processor.
>
> > I thought a second problem was that it used a value parameter as a
> > work area, which isn't something I would do in my languages of choice
> > (C Sharp and VB in recent years), but I found myself doing this in C
> > when I returned to the language mostly to kick the shit out it.
>
> > A third problem is praising a programmer for fast work. There's enough
> > slipshod work in our industry, and enough programmer overwork as it
> > is.
>
> > I think Brian Kernighan would be the first to admit that Lisp as
> > opposed to C made a more far-reaching contribution to computer science.- Hide quoted text -
>
> Actually, in C all they did was to borrow parens and braces from math
> to delimit blocks - BUT lisp already had the idea in the prefix
> notation. The other contribution is the for loop with all the loop
> elements at the top in the interface. The declaration syntax of
> pointers is poor and ugly. switch-case has fall thru. break and
> continue is new unless PL1 or BCPL had it.
>
> BUT YOU HAVE NOT SHOWN how to structure the recursion. Does it need
> NFA ? I need a tutorial because C is to stay and I can avoid some of
> its ugliness by using C++ as pretty C.
Is C here to stay?
No way.
In 2038, lemme tellya straight,
C's inability to get a date
Right will cause the thousand years of darkness.
Ever wonder why spam sorts high, and makes you cry?
You're looking at the answer, my oh my.
spinoza1111
> On Sun, 30 Aug 2009 06:30:45 +0000, Richard Heathfield
>
> <r...@see.sig.invalid> wrote:
>
> <snip>
>
> >In the current case, bolega (unknown name, to me at least) is slagging
> >off Brian Kernighan and Rob Pike (both names known to me) and their
> >book (which I've read). He starts with the word "braggart", and the
> >rest is similar ranting. It's just perfectly normal bilgewater of the
> >sort you often find on the Internet, but I don't see why we need to
> >accuse it of being nilgewater as well.
>
> Just so. The two styles are quite distinct. Generally speaking
> those who use the internet for ranting have quite individual and
> distinct styles. Thus Nilges is clearly well educated and well
> read, using many post modern and progressive tropes along with
> pop psychology. On the other hand Bolega (I thought it might be
> a sausage but apparently it is a brand of socks) is less well
> read and less literate.
I'd ask you to lay off personalities. You people have taken entirely
too long to figure out that I'm a class act, and Bolega may very well
be a class act. I wouldn't myself start off by calling Kernighan a
braggart, but I did have problems with O'Reilly's selecting some
fairly humdrum examples of "Beautiful Code" in the book containing
Kernighan's code. I was offended by Kernighan's praising programmer
for taking an hour.
>
> Incidentally, in my opinion the term "troll" isn't appropriate
> for such persons. Trolls are like malicious little children who
> stir up trouble for the pleasure of seeing people get all
> excited. These ranters have a different agenda.
Thank you for clearing that up at long last. I really appreciate it.
Trolls don't admit they are wrong to their worst enemies, but
Heathfield, who knows C if little else that I can discern, did prove
to me (along with my own experiments) that all parameters in C are
really and truly call be value, period, and as soon as I realized it,
I admitted it. I still have a problem with the fact that I had to beat
the answer out of him as well as mess with C.
>
> Richard Harter, c...@tiac.nethttp://home.tiac.net/~cri,http://www.varinoma.com
spinoza1111
> On Aug 28, 11:35 pm, bolega <gnuist...@gmail.com> wrote:
>
> > Look how he put
> > the code after problem statement and then has the need to explain it.
> > Ideally, the discussion should be such that the student or reader
> > himself jumps to the solution. That is why I give these unix school of
> > pike/thomson/kernighan low grade in almost all their expositions
> > except that they wrote earliest books to make millions of dollars in
> > royalties and since now they are nobody due to linux, they are poorly
> > regurgitating old material.
>
> Kernighan fails to correct the bugs in his programs.
We all have bugs in significant programs.
>
> Download his awk here:http://cm.bell-labs.com/cm/cs/who/bwk/awk95.exe
>
> Test it with this program:
>
> BEGIN {
> # Specify the field-separator.
> FS = "!"
> text = "foo!bar"
> $0 = text
> # Should print "foo".
> print $1
> printf "Press <ENTER>: "
> getline junk
> $0 = text
> print $1
>
>
>
> }- Hide quoted text -
>
spinoza1111
> In <h7cc1a$e6...@enyo.uwa.edu.au>, Chris McDonald wrote:
>
> > Ed Morton <mortons...@gmail.com> writes:
>
> >>On Aug 28, 11:35=A0pm, bolega <gnuist...@gmail.com> wrote:
> >>> This braggart admits that he had to put this code in TWO books and
> >>> visit it twice to be explained. I am puting the excerpt from pp2-4
> >>> of this book and the C code.
>
> >>You should post this to comp.lang.c.
>
> >> Ed.
>
> > He did, and I smelt a Bilges sock puppet.
Don't make mock of my patronym, punk.
>
> By the walks-like,swims-like,quacks-like theorem, I do see why you
> think so, but I think we should be slow to make such accusations,
> since they are so often wrong. I have never actually been accused of
> being a sock puppet as far as I am aware, but I have certainly been
> accused of running them (which I have never done, but of course those
> who accuse me don't believe that).
Wise words, for wisdom crieth in the streets. The only time I have
used a sock puppet was once on wikipedia.
>
> People can and often do use similar styles, especially when responding
> to people with whom they're perhaps not the best of friends. The
> other day, an irregular poster, a guy - who'd been away for a while
> and is unlikely to have become familiar with my occasional habit of
> marking nilgewater with "nonsense snipped - nothing left" - made
Don't make mock of my patronym or I will make mock of you as I have in
the past. You fuck with me I fight back, you dig? My relatives are war
heroes and professionals and they don't deserve this shit.
> precisely the same response. It would be easy to accuse /him/ of
> being a sock puppet... and yet his name has been well-known in
> another group for many years and he knows far more about that group's
> subject than I do, and I vaguely recall having a few extended
> disagreements with him in the past. He also posts from a different
> continent, by the way.
>
> Sock puppets undoubtedly happen, but they don't really matter because
> what counts is not who says what, but what they say (and, to a
> certain extent, how they say it). We might pay a lot of attention to
> a name we recognise (e.g. if Donald Knuth started posting, we'd sit
> up and take notice) - but *only* after it became obvious that it
> wasn't some spotty teenager mucking about. And we judge that by
> content. "By their fruits you shall know them" and all that.
>
> In the current case, bolega (unknown name, to me at least) is slagging
> off Brian Kernighan and Rob Pike (both names known to me) and their
> book (which I've read). He starts with the word "braggart", and the
> rest is similar ranting. It's just perfectly normal bilgewater of the
Don't make mock of my patronym, since it's an insult not so much to me
as to my relatives. If you must make mock, my first name is Edward and
my handle is spinoza1111.
My uncle, Edward Joseph NILGES, was killed in Italy in March 1945
leading Japanese American Nisei against the Germans. Don't mock him.
My father, Richard G Nilges, fought unethical practises in medicine.
Don't mock him.
Mock my first name or posting handle. Lay off "Nilges".
spinoza1111
If by NFA you mean an NDFA (non-deterministic finite automaton), no.
If you go down that road, you need to convert the regex first to an
NDFA and then to a deterministic DFA by treating groups of possible
symbols to single "symbols". A problem I have with the article is that
it doesn't confront this need.
Aho Sethi et al.'s COMPILERS (Dragon book) addresses how to do this.
But for individual regexes it's straightforward to code them directly.
Richard Heathfield
spinoza1111 wrote:
> On Aug 30, 2:30 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
<snip>
>>
>> In the current case, bolega (unknown name, to me at least) is
>> slagging off Brian Kernighan and Rob Pike (both names known to me)
>> and their book (which I've read). He starts with the word
>> "braggart", and the rest is similar ranting. It's just perfectly
>> normal bilgewater of the
>
> Don't make mock of my patronym
From Chambers: "*bilge* noun 1a the broadest part of a ship's bottom;
b (usually bilges) the lowermost parts on the inside of a ship's
hull, below the floorboards. 2 (also bilge-water) the dirty water
that collects in a ship's bilge. 3 /rather dated colloq/ rubbish,
nonsense, drivel."
I can see why you might object to the use of the neologism
"nilgewater", but I see no sensible reason for objecting to the
perfectly normal word "bilgewater". One might reasonably object to a
particular application thereof in a given context, but the word
itself is surely unobjectionable.
<snip>
Kenny McCormack
spinoza1111 <spino...@yahoo.com> wrote:
...
>Trolls don't admit they are wrong to their worst enemies, but
>Heathfield, who knows C if little else that I can discern, did prove
>to me (along with my own experiments) that all parameters in C are
>really and truly call be value, period, and as soon as I realized it,
>I admitted it. I still have a problem with the fact that I had to beat
>the answer out of him as well as mess with C.
A few comments:
1) That they totally mis-use the word "troll" is, of course, legion. It
wouldn't be such a big deal if it weren't for how obsessively anal they
are about words here. I.e., the hypocrisy is self-evident.
1a) It has certainly become common usage over the past decade or so to
use the word "troll" as a synonym for "people we don't like" (where
"we" is interpreted to mean "the Establishment"). This makes it no
less wrong, of course, but people would be more inclined to let it
pass if it weren't for the "clc personality type" (described above).
2) I have to admit also that Dicky was right about C's parameter passing
being exclusively call by value. I will further say that this fact
always impressed me - that everything is "by value". That is, in the
context of the minimalist/portable-assembler kind of language that C is.
2a) Nonetheless, that fact is that, in all but the most obscuirely
CLC-sense, it is true that C implements call-by-reference via pointers.
To argue otherwise, is just being a jerk, and I think we all
recognize that. It is the CLC disease to be technically right, but
so obviously wrong, at the same time.
rjf
in lisp that implements regular expressions, in part, I recommend this
article by Henry Baker, http://home.pipeline.com/~hbaker1/Prag-Parse.html
which displays in its entirety a lisp program remarkable (in my
opinion)
for its brevity and generality.
Somehow I think this thread is not about lisp or regular expressions,
but I can't figure out what it IS about, so apologies in advance if my
response is off topic. I'm just sort of going by the subject line.
RJF
George Neuner
<r...@see.sig.invalid> wrote:
>In <04b443ab-b17b-4ec9...@i8g2000pro.googlegroups.com>,
>spinoza1111 wrote:
>
>> On Aug 30, 2:30 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
><snip>
>>>
>>> In the current case, bolega (unknown name, to me at least) is
>>> slagging off Brian Kernighan and Rob Pike (both names known to me)
>>> and their book (which I've read). He starts with the word
>>> "braggart", and the rest is similar ranting. It's just perfectly
>>> normal bilgewater of the
>>
>> Don't make mock of my patronym
>
>From Chambers: "*bilge* noun 1a the broadest part of a ship's bottom;
>b (usually bilges) the lowermost parts on the inside of a ship's
>hull, below the floorboards. 2 (also bilge-water) the dirty water
>that collects in a ship's bilge. 3 /rather dated colloq/ rubbish,
>nonsense, drivel."
>
>I can see why you might object to the use of the neologism
>"nilgewater", but I see no sensible reason for objecting to the
>perfectly normal word "bilgewater". One might reasonably object to a
>particular application thereof in a given context, but the word
>itself is surely unobjectionable.
>
><snip>
Can we, at least, object to the making of a single word noun from a
two word "adjective noun" combination?
English already has more than 1.2 million perfectly good words. Let's
all try using them before inventing new ones.
George
Jerry Coffin
@g1g2000vbr.googlegroups.com>, gnui...@gmail.com says...
Even though I'm quite sure the original post really was some close
relative of trolling, let's dissect the code itself, and see if it
really can be improved a great deal:
int match(char *regexp, char *text)
{
if (regexp[0] == '^')
return matchhere(regexp+1, text);
If an RE starts with '^', it has to match at the beginning of the
text, so we check only for a match of the remainder of the RE,
starting from the beginning of the text.
do { /* must look even if string is empty */
if (matchhere(regexp, text))
return 1;
} while (*text++ != '\0');
Otherwise, we step through each possible position in the text, and
check for a match at that position.
/* matchhere: search for regexp at beginning of text */
int matchhere(char *regexp, char *text)
{
if (regexp[0] == '\0')
return 1;
If we've reached the end of the RE, return 1, indicating we found a
match.
if (regexp[1] == '*')
return matchstar(regexp[0], regexp+2, text);
If we find a '*', use 'matchstar' to check for a match.
if (regexp[0] == '$' && regexp[1] == '\0')
return *text == '\0';
If the RE ends in '$', we have a match only if we've reached the end
of the text.
if (*text!='\0' && (regexp[0]=='.' || regexp[0]==*text))
return matchhere(regexp+1, text+1);
If we're at the end of the text, but there's more to the RE, we don't
have a match. Otherwise, if the current character of the RE is '.',
OR it's any other (non-meta-) character that matches the current
character in the text, we have a match iff the remainder of the RE
matches the remainder of the text.
return 0;
Otherwise (e.g. we were at the end of the text, but not the end of
the RE) we do not have a match.
So far, it's simple and straightforward -- we've simply enumerated
the possibilities, and handled each in a fairly straightforward
manner.
/* matchstar: search for c*regexp at beginning of text */
int matchstar(int c, char *regexp, char *text)
{
do { /* a * matches zero or more instances */
if (matchhere(regexp, text))
return 1;
} while (*text != '\0' && (*text++ == c || c == '.'));
Here's where things get a little bit tricky. Recall that matchstar()
is called when matchhere() encountered an RE something like 'x*E'. It
calls matchstar(), passing the 'x' as the first parameter, "E" as the
second, and the text as the third (where 'x' is some single
character, and "E" is an arbitrary RE).
matchstar() then says that such an RE matches if 1) 'x' matches some
number of characters in text, followed by E matching the remainder of
the text.
return 0;
If we fall out of the loop, we either reached the end of the text
without finding a match for the remainder of the RE, or else because
we found a mismatch between 'x' and the current character in the RE
before finding a match between the remainder of the RE and the
remainder of the text.
As to the original implication that the code is particularly
difficult to read or understand, I'd have to say no, not really. In
fact, much like most well written recursive code, it's structured
very much like an inductive proof: establish an invariant for what's
currently being considered, then show that the invariant remains true
for the remainder.
In this case, it does that by (mostly in matchhere) checking whether
the current item in the RE matches the current character in the text,
and if it does recursing to establish whether the remainder of the RE
matches the remainder of the text.
It's also rather similar to rather a large amount of Lisp code. The
primary difference is that in Lisp, the primary data structure is
typically a list, whereas here it's a string (or at least C's rather
limited version of a string). Nonetheless the similarity in usage is
striking. In essence, the code works primarily in terms of a CAR and
a CDR. The code examines the CAR directly, and assuming that's
successful, examines the CDR via a recursive call.
For most practical purposes, this _is_ Lisp code that happens to use
a rather strange syntax.
--
Later,
Jerry.
spinoza1111
> In <04b443ab-b17b-4ec9-9269-8a873d740...@i8g2000pro.googlegroups.com>,
>
>
>
> spinoza1111wrote:
> > On Aug 30, 2:30 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
> <snip>
>
> >> In the current case, bolega (unknown name, to me at least) is
> >> slagging off Brian Kernighan and Rob Pike (both names known to me)
> >> and their book (which I've read). He starts with the word
> >> "braggart", and the rest is similar ranting. It's just perfectly
> >> normal bilgewater of the
>
> > Don't make mock of my patronym
>
> From Chambers: "*bilge* noun 1a the broadest part of a ship's bottom;
> b (usually bilges) the lowermost parts on the inside of a ship's
> hull, below the floorboards. 2 (also bilge-water) the dirty water
> that collects in a ship's bilge. 3 /rather dated colloq/ rubbish,
> nonsense, drivel."
>
> I can see why you might object to the use of the neologism
> "nilgewater", but I see no sensible reason for objecting to the
> perfectly normal word "bilgewater". One might reasonably object to a
> particular application thereof in a given context, but the word
> itself is surely unobjectionable.
Well, Dickon,
What think'st thou Norfolke.
Nor. A good direction warlike Soueraigne,
This found I on my Tent this Morning.
Iockey of Norfolke, be not so bold,
For Dickon thy maister is bought and sold.
I still object to "bilge", etc., because you are like a child making
fun of my patronym.
You are a dull Fellowe
With a streak of bright Yellowe
Who when he loses an argument
Says 'tis not what I meant,
And who makes a child's game
Out of a person's father's name
Because unlike myself
Thou hast no Pelf
In the wealthe that lieth in words
Your posties they are for the birds.
A Yank can yank your chaine
And cause you paine, knowing he
More than you about your paternitie,
The English language you have lost.
Jockey of Heathfield, be not so bold
We're tired of you, and you're gettin' old.
Richard Heathfield
<33b68711-9b51-4162...@upsg2000gro.googlegroups.com>,
spinoza1111 wrote:
<snip>
> I still object to "bilge", etc., because you are like a child making
> fun of my patronym.
I thought your patronym was Nilges, not Bilges. Was that a mistake?
gavino
> let me paste the code separately since it has some garbage that
> inserted in the middle although it was just one block of text.
>
> This is the matching code:
> /* match: search for regexp anywhere in text */
> int match(char *regexp, char *text)
> {
> if (regexp[0] == '^')
> return matchhere(regexp+1, text);
> if (matchhere(regexp, text))
> return 1;} while (*text++ != '\0');
> }
>
> /* matchhere: search for regexp at beginning of text */
> int matchhere(char *regexp, char *text)
> {
> if (regexp[0] == '\0')
> return 1;
> return matchstar(regexp[0], regexp+2, text);
> return *text == '\0';
> return matchhere(regexp+1, text+1);
>
> /* matchstar: search for c*regexp at beginning of text */
> int matchstar(int c, char *regexp, char *text)
> {
> do { /* a * matches zero or more instances */
> if (matchhere(regexp, text))
> return 1;
>
> } while (*text != '\0' && (*text++ == c || c == '.'));
> }
>
> By the way did you note the spicy style of narration by which they
> promote each other ? and can you abstract the technique of narration
> for image building ? Another scum in electronic, Bob Pease of national
> semiconductor writes in the same style. I know all their basic ideas
> in that field, which are trivial. The only art is the art of writing
> and propaganda.
>
> The one man I have real respect for and is humble is McCarthy. He
> really put some original ideas together but still did not give any
> clue how he constructed them. However, in lisp recursion is lucidly
> clear. You test if a thing is nil. Else you check if it is an atom and
> act appropriately to call a handler and otherwise recursion.
I am curious, so you are saying that one should not be impressed by c
and K+R and plan9 and all the rest? That they kind of suck and the
mccarthy really is much better and his lisp can do things much more
simply in fewer line of code?
gavino
gavino
> In <h7cc1a$e6...@enyo.uwa.edu.au>, Chris McDonald wrote:
reality: show me the apps!! apps I am using now: windows7[c?],
firefox3[c], pidgin char[gtk+c?], opera browser[c?], and vlc media
player[c] seem all to be made in c, so where are the lisp replacements
and I shall happily use them, esp if they are more felxible and fast
enuf.
gavino
so where are the 100s of lines of good working lisp?
I wish many utilities for running a web business were redone in lisp
with less lines of code and lisp power: DNS, NFS[or something nicer],
openssh, webserver, web broswer I can use to check email, monitoring
server, clustering... etc etc
gavino
> On Aug 29, 10:38 pm, bolega <gnuist...@gmail.com> wrote:
>
> > On Aug 29, 2:51 am,spinoza1111<spinoza1...@yahoo.com> wrote:
>
> > > Many people seem to have been upset with this article in Beautiful
> > > Code. I emailed Kernighan about it and received a reply (I'd met the
> > > guy), but no real answer to the basic problem, which is that C cannot
> > > express programming ideas clearly.
>
> > I admire the fact that someone brought all this in the public
> > discussion because a lot of sleazy people (not referring in particular
> > to this troika) have been able to propagate crap and kept it immune to
> > academic critique just due to people afraid of criticizing it which
> > leads to a lot of newbie sheeple.
>
> > Do you think C syntax is brain damaged ? Can you explain your second
> > point in more detail and clearly as I could not understand any of it.
>
> Read this excellent article: Software Fault Prevention by Language
> Choice: Why C is Not My Favorite Language, Richard Fateman. Fateman is
forth for the win!
gavino
inyego montoya, you killed my father! you are about to die!
gavino
> In <04b443ab-b17b-4ec9-9269-8a873d740...@i8g2000pro.googlegroups.com>,
everyone knows this
gavino
> On Tue, 01 Sep 2009 15:25:41 +0000, Richard Heathfield
>
>
>
> <r...@see.sig.invalid> wrote:
just as in forth one should learn the base word list before making a
word to do something from lots fo base words that does the same as a
low level word
gavino
> In article <f9e3a68d-2eac-4f97-a005-bf933662c568
are you talking about using a perl compat regex package in lisp? or
doing regex natively in lisp somehow?
gavino
wow you brits crack me, no wonder been at war for 300 years
Michael Foukarakis
> This braggart admits that he had to put this code in TWO books and
> visit it twice to be explained. I am puting the excerpt from pp2-4 of
> highlighted once you paste in emacs etc. It is my belief and
> observation on a lot of problems by these so called "demi gods" that
> they are actually all average and no more intelligent. Its all that
> they got some opportunities to study some things at opportune time and
> facilities and also spent a lot of time in a productive environment
> and team.
>
> I know that lisp eval is written more clear than this recursion below
> because I am able to read it easily. and that code is almost self
> explanatory. C is more quirky. When you really mean recursively call
> another function, you are using return so you can have tail
> recursion ???? .
>
> Anyway, its your chance to show how clear C/C++/lisp/Scheme code you
> can write that is clearer. Also, i dont exclude pseudocode but it
> should be clear enough to be instantly translatable to a programming
> language. The real goal is to learn how to write or DERIVE recursion,
> how to enumerate cases, order them, and build recursion. You may even
> put some introductory tuturial and dont have to reply here in ascii
> but can upload a pdf at some link in rapidshare etc. Look how he put
> the code after problem statement and then has the need to explain it.
> Ideally, the discussion should be such that the student or reader
> himself jumps to the solution. That is why I give these unix school of
> pike/thomson/kernighan low grade in almost all their expositions
> except that they wrote earliest books to make millions of dollars in
> royalties and since now they are nobody due to linux, they are poorly
> regurgitating old material.
"He" has the need to explain it because its goal is to provide advice
and guidance, ie. be educational.
Now go fetch Lisp device drivers.
James Kuyper
> In
> <33b68711-9b51-4162...@upsg2000gro.googlegroups.com>,
> spinoza1111 wrote:
>
> <snip>
>
>> I still object to "bilge", etc., because you are like a child making
>> fun of my patronym.
>
> I thought your patronym was Nilges, not Bilges. Was that a mistake?
Surely you're not denying that "bilgewater" is being used because of the
similarity of Nilges and Bilge?
However, he's mistaken in thinking that you're making fun of his
patronym; it's the comparison between the qualities of his writing the
qualities of bilgewater that provides the humor, and the (well deserved)
insult. There's nothing particularly humorous, in itself, about the
similarity between Nilges and bilge.
spinoza1111
Hey, Reading Rainbow, I'm a Yank, and it says so in the post. I am
carrying the battle to the enemy as did John Paul Jones when he
invaded Britain during the Revolutionary war.
Richard Heathfield
<snip>
> There's nothing particularly humorous, in itself,
> about the similarity between Nilges and bilge.
No, it isn't even remotely amusing.
Aleksej Saushev
> On Sep 1, 4:58О©╫am, spinoza1111 <spinoza1...@yahoo.com> wrote:
>>
>> Read this excellent article: Software Fault Prevention by Language
>> Choice: Why C is Not My Favorite Language, Richard Fateman. Fateman is
>> on the faculty of the rather C-centric Univ of California at Berkeley.
>> http://www.eecs.berkeley.edu/~fateman/papers/software.pdf.
>
> forth for the win!
The world still waits for you to write any program longer than 8 lines,
in any language, be it Forth, Lisp or Scheme.
--
CE3OH...
luserXtrog
The dude from Zeppelin?!
--
appendix
spinoza1111
Oh never mind...eye roll...deep, deep sigh...crotch grab...
>
> --
> appendix- Hide quoted text -
spinoza1111
> gavino <gavcom...@gmail.com> writes:
> > On Sep 1, 4:58šam,spinoza1111<spinoza1...@yahoo.com> wrote:
>
> >> Read this excellent article: Software Fault Prevention by Language
> >> Choice: Why C is Not My Favorite Language, Richard Fateman. Fateman is
> >> on the faculty of the rather C-centric Univ of California at Berkeley.
> >>http://www.eecs.berkeley.edu/~fateman/papers/software.pdf.
>
> > forth for the win!
>
> The world still waits for you to write any program longer than 8 lines,
> in any language, be it Forth, Lisp or Scheme.
How about 26000 lines in Visual Basic? 50000 in Cobol? 75000 in
assembler? 25000 in PL/I? 20000 in C sharp? 10000 in C? 1000 in TI-79
machine language, a compiler and run time in 1K for Mouse, a Forth
knockoff?
>
> --
> CE3OH...
spinoza1111
> In <h7lg4v$sh...@news.eternal-september.org>, James Kuyper wrote:
>
> <snip>
>
> > There's nothing particularly humorous, in itself,
> > about the similarity between Nilges and bilge.
>
> No, it isn't even remotely amusing.
So why do you make a joke of it? Is it perhaps because you're a feeb
and this is the only reply you can make to my verse?
Richard Heathfield
<fd5edcf0-86d1-4f52...@f18g2000prf.googlegroups.com>,
spinoza1111 wrote:
> On Sep 2, 6:11 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
>> In <h7lg4v$sh...@news.eternal-september.org>, James Kuyper wrote:
>>
>> <snip>
>>
>> > There's nothing particularly humorous, in itself,
>> > about the similarity between Nilges and bilge.
>>
>> No, it isn't even remotely amusing.
>
> So why do you make a joke of it?
My use of the word "bilgewater" (or, more properly, "bilge-water",
according to Chambers) was not intended to be a joke.
> Is it perhaps because you're a feeb
> and this is the only reply you can make to my verse?
I wouldn't call that "verse". It wouldn't even qualify as doggerel.
spinoza1111
> In
>
> spinoza1111wrote:
> > On Sep 2, 6:11 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
> >> In <h7lg4v$sh...@news.eternal-september.org>, James Kuyper wrote:
>
> >> <snip>
>
> >> > There's nothing particularly humorous, in itself,
> >> > about the similarity between Nilges and bilge.
>
> >> No, it isn't even remotely amusing.
>
> > So why do you make a joke of it?
>
> My use of the word "bilgewater" (or, more properly, "bilge-water",
> according to Chambers) was not intended to be a joke.
Of course not. You grind on without levity and at best create
confusion. We have to beat answers out of you since you insist on
being literally "right" at all times.
>
> > Is it perhaps because you're a feeb
> > and this is the only reply you can make to my verse?
>
> I wouldn't call that "verse". It wouldn't even qualify as doggerel.
Sorry, but of verse you are no judge
Any more than any packer of fudge. Stick with C:
You have no poetry.
Richard Heathfield
<d176241c-d7f9-46e0...@f20g2000prn.googlegroups.com>,
spinoza1111 wrote:
> On Sep 2, 10:44 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
>> In
>>
<fd5edcf0-86d1-4f52-b8f5-6fb182b1a...@f18g2000prf.googlegroups.com>,
>>
>> spinoza1111wrote:
>> > On Sep 2, 6:11 pm, Richard Heathfield <r...@see.sig.invalid>
>> > wrote:
>> >> In <h7lg4v$sh...@news.eternal-september.org>, James Kuyper
>> >> wrote:
>>
>> >> <snip>
>>
>> >> > There's nothing particularly humorous, in itself,
>> >> > about the similarity between Nilges and bilge.
>>
>> >> No, it isn't even remotely amusing.
>>
>> > So why do you make a joke of it?
>>
>> My use of the word "bilgewater" (or, more properly, "bilge-water",
>> according to Chambers) was not intended to be a joke.
>
> Of course not. You grind on without levity and at best create
> confusion.
So first you accuse me of trying to be funny, and then you accuse me
of trying *not* to be funny. It becomes evident, therefore, that you
are only really interested in criticising me, no matter what I do.
There is obviously no point, therefore, in paying any attention to
any of your criticisms.
> We have to beat answers out of you
On the contrary, I'm generally happy to provide answers, when I know
them. I don't know /all/ the answers, however.
> since you insist on
> being literally "right" at all times.
It is very clear that you have not succumbed to the same temptation.
<nonsense snipped>
Nick Keighley
> [...] It is my belief and
> observation on a lot of problems by these so called "demi gods" that
> they are actually all average and no more intelligent. Its all that
> they got some opportunities to study some things at opportune time and
> facilities and also spent a lot of time in a productive environment
> and team.
it's a *bad* thing that they spent time in a productive team?
> I know that lisp eval is written more clear than this recursion below
> because I am able to read it easily. and that code is almost self
> explanatory. C is more quirky. When you really mean recursively call
> another function, you are using return so you can have tail
> recursion ???? .
ah, what? In what sense is C's recursion any more difficult that
any other language's recursion?
<snip>
Janis Papanagnou
In advance to the comment I give below I'd like to point out that C is
not my Favourite Language.
> Read this excellent article: Software Fault Prevention by Language
> Choice: Why C is Not My Favorite Language, Richard Fateman. Fateman is
> on the faculty of the rather C-centric Univ of California at Berkeley.
> http://www.eecs.berkeley.edu/~fateman/papers/software.pdf.
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. After the first pages I thought the author must love that language
(lisp) so much[*] 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.
Epilog: I've stumbled across the above quoted comment due to the posting
having been crossposted to a lot of groups, and I probably won't see your
replies.[**] Though, I don't care about discussions of *that* paper anyway,
because of it's extremely low quality, and it would thus require a huge
amount of effort if someone would really like to seriously argue about it;
I think the paper is not worth that effort. My intention was to warn folks
about so called "excellent articles" from (probably) sacrosanct authors.
Have fun with your favourite language(s) of choice, be it Lisp, or C, or
whatever else you enjoy to struggle with.
Janis
[*] Confirmed by the author at the end of his article.
[**] I haven't subscribed the two groups to which I reduced the x-posting
list. (But feel free to drop me an email if you like.)
Richard Heathfield
> spinoza1111 wrote:
>> On Aug 29, 10:38 pm, bolega <gnuist...@gmail.com> wrote:
>>>
>>> Do you think C syntax is brain damaged ? [...]
>
> In advance to the comment I give below I'd like to point out that C
> is not my Favourite Language.
>
>> Read this excellent article: Software Fault Prevention by Language
>> Choice: Why C is Not My Favorite Language, Richard Fateman. Fateman
>> is on the faculty of the rather C-centric Univ of California at
>> Berkeley.
>> http://www.eecs.berkeley.edu/~fateman/papers/software.pdf.
>
> You call that article "excellent"? I've got curious and read it.
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.
++++++++++++++++++++++++++++++++++++++++++++++++++
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?
Pascal J. Bourguignon
> In <h8bvbd$ajb$1...@svr7.m-online.net>, Janis Papanagnou wrote:
>
>> spinoza1111 wrote:
>>> On Aug 29, 10:38 pm, bolega <gnuist...@gmail.com> wrote:
>>>>
>>>> Do you think C syntax is brain damaged ? [...]
>>
>> In advance to the comment I give below I'd like to point out that C
>> is not my Favourite Language.
>>
>>> Read this excellent article: Software Fault Prevention by Language
>>> Choice: Why C is Not My Favorite Language, Richard Fateman. Fateman
>>> is on the faculty of the rather C-centric Univ of California at
>>> Berkeley.
>>> http://www.eecs.berkeley.edu/~fateman/papers/software.pdf.
>>
>> You call that article "excellent"? I've got curious and read it.
>
> 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.
Yes, you've made me too read again that excellent article. Not all
articles written by academic guys need to be full of formula,
statistics and graphs. If you want that kind of article comparing
languages, they exist too. And for precise enumeration of C pitfalls,
a single article is not enough, whole libraries are written about
that!
> I hereby present the full text of the proposed Second Edition:
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++
>
> WHY C IS NOT MY FAVOURITE PROGRAMMING LANGUAGE
>
> Because I prefer Lisp.
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++
>
> 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.
You just cannot write 4["abc"] in Lisp.
You just cannot write int a=100000;short b=a; in Lisp.
You just cannot write if(b=100000); in Lisp.
You just cannot write int* a=(int*)42; in Lisp.
You're right that there are also some pitfalls in Lisp, but instead of
being pitfalls that any programmers including newbies encounter
everyday, and overlook everyday, thus leaving numerous bugs in C
programs, pitfalls in Lisp are a few sophisticated technicalities
that are generally not encountered by programmers. The set of bug
producing pitfalls in Lisp is infinitesimal compared to C.
--
__Pascal Bourguignon__
Richard Heathfield
> Richard Heathfield <r...@see.sig.invalid> writes:
<snip>
>> Is there no such thing as lousy (louthy?) Lisp code?
>
> No. That's the point of that article.
Hmmm. Okay, I'll bite - or try to. I guess you're not normally a
comp.lang.c kind of guy, and I'm certainly not a comp.lang.lisp kind
of guy, so perhaps we can take this up in c.p when I've had a chance
to install Lisp on my box?
Pascal J. Bourguignon
> In <87pr9yl...@galatea.local>, Pascal J. Bourguignon wrote:
>
>> Richard Heathfield <r...@see.sig.invalid> writes:
>
> <snip>
>
>>> Is there no such thing as lousy (louthy?) Lisp code?
>>
>> No. That's the point of that article.
>
> Hmmm. Okay, I'll bite - or try to. I guess you're not normally a
> comp.lang.c kind of guy, and I'm certainly not a comp.lang.lisp kind
> of guy, so perhaps we can take this up in c.p when I've had a chance
> to install Lisp on my box?
Sure.
In the meantime have a look at the articles referenced on
http://www.cliki.net/Performance
comparing programmer productivity in various languages.
(And mind the http://www.cliki.net/Education links for lisp beginners).
--
__Pascal Bourguignon__
A.L.
Bourguignon) wrote:
>Richard Heathfield <r...@see.sig.invalid> writes:
>
>> In <87pr9yl...@galatea.local>, Pascal J. Bourguignon wrote:
>>
>>> Richard Heathfield <r...@see.sig.invalid> writes:
>>
>> <snip>
>>
>>>> Is there no such thing as lousy (louthy?) Lisp code?
>>>
>>> No. That's the point of that article.
>>
>> Hmmm. Okay, I'll bite - or try to. I guess you're not normally a
>> comp.lang.c kind of guy, and I'm certainly not a comp.lang.lisp kind
>> of guy, so perhaps we can take this up in c.p when I've had a chance
>> to install Lisp on my box?
>
>Sure.
>
>In the meantime have a look at the articles referenced on
>http://www.cliki.net/Performance
>comparing programmer productivity in various languages.
>
>(And mind the http://www.cliki.net/Education links for lisp beginners).
Pity that nobody in industry is using Lisp... Why, if it is SOOOOO....
GOOD?...
A.L.
Phil Carmody
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
--
Any true emperor never needs to wear clothes. -- Devany on r.a.s.f1
Richard Tobin
Pascal J. Bourguignon <p...@informatimago.com> wrote:
>> 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. 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
--
Please remember to mention me / in tapes you leave behind.
Pascal J. Bourguignon
> In article <87pr9yl...@galatea.local>,
> Pascal J. Bourguignon <p...@informatimago.com> wrote:
>
>>> 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.
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.
--
__Pascal Bourguignon__
Richard Heathfield
> ric...@cogsci.ed.ac.uk (Richard Tobin) writes:
>> In article <87pr9yl...@galatea.local>,
>> Pascal J. Bourguignon <p...@informatimago.com> wrote:
>>>> 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.
<snip>
Alessio Stalla
wrote:
> rich...@cogsci.ed.ac.uk (Richard Tobin) writes:
> > In article <87pr9yl1ig....@galatea.local>,
> > Pascal J. Bourguignon <p...@informatimago.com> wrote:
>
> >>> 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 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.
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
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.
<shrug>
> > Read this excellent article: Software Fault Prevention by Language
> > Choice: Why C is Not My Favorite Language, Richard Fateman. Fateman is
> > on the faculty of the rather C-centric Univ of California at Berkeley.
> >http://www.eecs.berkeley.edu/~fateman/papers/software.pdf.
>
> 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>
--
Physics, as we know it, will be over in six months.
Max Born (1928)
Pascal J. Bourguignon
> In <7czl91o...@anevia.com>, Pascal J. Bourguignon wrote:
>> ric...@cogsci.ed.ac.uk (Richard Tobin) writes:
>>> In article <87pr9yl...@galatea.local>,
>>> Pascal J. Bourguignon <p...@informatimago.com> wrote:
>>>> Richard Heathfield wrote:
>>>>> 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.
--
__Pascal Bourguignon__
Alessio Stalla
wrote:
> 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 Bourguignon__
Pascal J. Bourguignon
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
((()((()())))())
((()((()())))())
--
__Pascal Bourguignon__
Nick Keighley
I was less confident of the Lisp version so i checked it more
carefully...
Nick Keighley
wrote:
> Nick Keighley <nick_keighley_nos...@hotmail.com> writes:
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
[...]
> 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
Eric Sosman
> [...]
> 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?
Sure. The O(N*N*logN) sort I mentioned a few days ago was done
in Lisp. It seems likely that the reason the comparator took O(N)
time was that the brevity of an innocent-looking Lisp construct caused
the programmer to overlook its time complexity.
No language has a monopoly on lousy code. If there's a language
that is immune to lousy code and lousy coders, I've yet to see or hear
of it.
Richard Fateman
Is there no such
> thing as lousy (louthy?) Lisp code?
>
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
>> 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)
Seems to be accessible, after free registration with Wiley's web site.
Thanks for the link.
--
__Pascal Bourguignon__
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.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
when there is no ground whatsoever for supposing it is true.
-- Bertrand Russell
namekuseijin
> Pity that nobody in industry is using Lisp... Why, if it is SOOOOO....
> GOOD?...
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?
--
a game sig: http://tinyurl.com/d3rxz9
namekuseijin
> 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.
The only such advantages I see are a readily-available C-centric IT
world and plenty of programmers used to its syntax -- but not to its
primitive, low-level semantics, since most of these people are actually
programming either in C++, Java, Javascript or C#...
Keith Thompson
> A.L. escreveu:
>> Pity that nobody in industry is using Lisp... Why, if it is SOOOOO....
>> GOOD?...
>
> 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.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Richard Heathfield
> Richard Heathfield wrote:
> Is there no such thing as lousy (louthy?) Lisp code?
>>
> Ahem.
Hmmm?
> 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)
It doesn't appear to be accessible, no.
> 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).
Everybody makes mistakes. I suspect, however, that vanishingly few, if
any, of these bugs would survive a comp.lang.c review. (I refer here
to bugs that are violations of good language practice; matching the
program spec can be done too, but I suspect that even the most
good-natured clcer would want paying for that.)
> 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.
Hmmm. It has rightly been said that you can stop people doing stupid
things only by taking away their ability to do clever things.
<snip>
> 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>
Not a bad book, but far from perfect.
> 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.
Reliability *is* very important. So are robustness, correctness,
maintainability, and performance. (In my personal opinion, in
descending order of importance the first three are maintainability,
correctness, and robustness, in that order, and I know that some
people will say "huh?" to that. But placing correctness second does
not mean I think it's unimportant, and I certainly rate it higher
than performance.)
But performance is clearly one factor. (Not the only factor, as
Richard Gabriel rightly points out.) 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.
Richard Fateman
...
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
Richard Heathfield
I don't know where you got the idea that I'm trolling. Are you aware
that this thread is cross-posted between clc and cll? I'm reading it
in clc, where all the Lisp stuff is fundamentally off-topic and could
be considered trolling, but given the fact of the crosspost I'm
trying to give you the benefit of the doubt. Probably it would be
better if we just drop this whole thing, yes?
Thomas A. Russ
Hmmm. Maybe we could morph this into a Beer vs. Ale discussion?
--
Thomas A. Russ, USC/Information Sciences Institute
James Dow Allen
> >> On Aug 29, 10:38 pm, bolega <gnuist...@gmail.com> wrote:
> >> Read this excellent article: Software Fault Prevention by Language
> >> Choice: Why C is Not My Favorite Language, Richard Fateman. Fateman
> >> is on the faculty of the rather C-centric Univ of California at
> >> Berkeley.
> >>http://www.eecs.berkeley.edu/~fateman/papers/software.pdf.
>
> 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
Vassil Nikolov
On Sat, 12 Sep 2009 00:30:15 -0700 (PDT), James Dow Allen <jdall...@yahoo.com> said:
> ...
> 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.)
The meaning of
b+++c
in the C programming language cannot be asserted by what a compiler
does with it, but by the syntactic rule (which I thought was very
well known) that, essentially, tokenization is greedy (there is no
`+++' token in the grammar, and `++' is longer than `+', therefore
the tokenization of the above is `b' `++' `+' `c').
> (BTW, gcc accepts both "a+ + + +b" and "a+ ++ +b"
> without complaint but generates *different* results
> for them! Is *this* compliant?)
These are two different expressions, of course, but is
+b
an lvalue?
> ...
> 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.
What would that definition look like? (The body of DOLIST may
contain an arbitrary number of forms.)
---Vassil.
--
"Even when the muse is posting on Usenet, Alexander Sergeevich?"
vippstar
<snip>
> 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.
preprocessor, and was unable to find a difference between the two
macros. It's likely most of common lisp can be macro'ed that way into
C, so the jokes on CL bragging about its macros!
> 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"!
Of course in the real world, with all the incompetent programmers, he
is quite right: anything with such flexibility quite likely has a bug-
infested implementation. He's not talking about a small circle of
people (c.l.c. inhabitats for instance), which might achieve better
results on average, he's talking about the average of C programmers -
and I think we'd agree there's more average programmers than experts.
But it is shown on a daily basis at c.l.c., that most code hides a bug
or two that only the regulars know (plus those who know C but are not
regulars). Of course, in that case he's also making a point about
incompetent lisp programmers but in any case, he's correct saying
that.
<snip>
> 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!
We'd have releases of software for computers with 1GB memory, 2GB
memory, etc, and incompability problems when upgrading memory (in
reality, the optimization scheme can't work at all).
Richard Heathfield
James Dow Allen wrote:
<snip>
> 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.
Well, it's not difficult. The expression yields the result of adding
the value of b (that is, the value it had at the previous sequence
point) to the value of c. As a side-effect, it increments b.
> (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.)
C tokenisation uses the "maximum munch" principle, grabbing the
biggest legal token even if this results in a syntax error that a
smaller munch would not cause. Thus, b+++++c is illegal even though
the tokeniser /could/ tokenise it as b ++ + ++ c, because the rules
of C require this instead: b ++ ++ + c
Quoth the Standard: "If the input stream has been parsed into
preprocessing tokens up to a given character, the next preprocessing
token is the longest sequence of characters that could constitute a
preprocessing token."
> (BTW, gcc accepts both "a+ + + +b" and "a+ ++ +b"
> without complaint but generates *different* results
> for them! Is *this* compliant?)
The first one is fine - unary +. Since +b is the same as b (unary +,
remember), and + +b is likewise the same as +b, and + + +b is
likewise the same as + +b, the a+ at the beginning just means "add a
to" - throwing in a binary + curveball for you.
The second one looks wrong to me because unary + is still an operator,
so it yields a value, and you can only ++ an object, not a value. If
that's legal (which I doubt), it's only because of a weird exception
for unary +. Does the Standard grant such licence? I doubt it very
much indeed.
<snip>
> 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.
If source terseness is all that is required:
int doit(int, char**);int main(int a,char**b){return doit(a,b);}
is the longest C program you'll ever need to show anyone. "What's
doit()?", says you. "Oh, don't worry about it - it's just a library
call", says I - with tongue firmly in cheek.
Incidentally, I've just been trying to teach myself Lisp. It's a very
frustrating process - clisp's error messages are even more
incomprehensible to a newbie than those of a C compiler!
Willem
) Of course in the real world, with all the incompetent programmers, he
) is quite right: anything with such flexibility quite likely has a bug-
) infested implementation. He's not talking about a small circle of
) people (c.l.c. inhabitats for instance), which might achieve better
) results on average, he's talking about the average of C programmers -
) and I think we'd agree there's more average programmers than experts.
Perhaps there are a lot more average programmers doing C than there are
doing Lisp ? Who knows, perhaps those that learn Lisp are inherently those
that are better at programming in general.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
Keith Thompson
> In <c52cfc1f-7f29-4008...@i4g2000prm.googlegroups.com>,
> James Dow Allen wrote:
>> (BTW, gcc accepts both "a+ + + +b" and "a+ ++ +b"
>> without complaint but generates *different* results
>> for them! Is *this* compliant?)
>
> The first one is fine - unary +. Since +b is the same as b (unary +,
> remember), and + +b is likewise the same as +b, and + + +b is
> likewise the same as + +b, the a+ at the beginning just means "add a
> to" - throwing in a binary + curveball for you.
>
> The second one looks wrong to me because unary + is still an operator,
> so it yields a value, and you can only ++ an object, not a value. If
> that's legal (which I doubt), it's only because of a weird exception
> for unary +. Does the Standard grant such licence? I doubt it very
> much indeed.
The second one certainly looks like a bug in gcc. +b is not an
lvalue, so you can't legally apply ++ to it. (The standard doesn't
say so explicitly, but it seems clear enough. For one thing, the
integer promotions are applied to the operand; if b is of type short,
then +b is of type int, and it doesn't make sense for it to be an
value of type int with no int object in sight.)
I wouldn't be surprised if gcc allowed this as an extension, but it
won't complain about it even with options that tell it to attempt to
behave as a conforming compiler.
Sun's compiler complains:
"c.c", line 6: operand must be modifiable lvalue: op "++"
James Dow Allen
> On Sat, 12 Sep 2009 00:30:15 -0700 (PDT), James Dow Allen <jdallen2...@yahoo.com> said:
> The meaning of
> b+++c
> in the C programming language cannot be asserted by what a compiler
Yep. Sorry if my post implied otherwise. :-)
I sometimes report gcc's behavior in lieu of quoting
The Standard(tm) (which I've never read) since, if there's
a difference, it would be interesting to know!
> ... the syntactic rule (which I thought was very
> well known) that, essentially, tokenization is greedy ...
I'm sure it's well known to C language experts, but count me
out there! In 30 years of C programming (which never included
a C parser, obviously) I've *never* needed to remember this
fact! Perhaps my C coding is just too tame, but
I don't think it's been overly unsuccessful. For me, C
is about interesting algorithms like some of the code or puzzles
at my website, but I know for some of you it's more important
to see who can parse "a+ + ++ + +b" first. :-)
> > (BTW, gcc accepts both "a+ + + +b" and "a+ ++ +b"
> > without complaint but generates *different* results
> > for them! Is *this* compliant?)
>
> These are two different expressions, of course, but is
> +b
> an lvalue?
I sure don't think so! This gcc behavior is mysterious to me;
I stumbled on it only because I'd already typed in the
unremembered "+++" case and added some more "+"s just for
fun. :-)
> > ...
> > 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.
>
> What would that definition look like? (The body of DOLIST may
> contain an arbitrary number of forms.)
As I imply, I don't advocate it (except for special purposes)
but simplest might be
#define dolist(x,h) for (x = h; x; x = x->next)
Now the Lisp fragment above "translates" to
dolist(x, Foo) {
Guzzle(x);
}
Very similar -- except for trivia like a prefix "("
becoming an infix "{".
James
Flash Gordon
> 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.
<snip>
> 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.
A number of us over on comp.lang.c don't consider C to be the best
language for everything, and indeed many of us use several languages.
Some of your article is a bit out of date now. For example...
A number of good compilers and analysis tools will detect the use of
uninitialised variables, so to catch the logic error of using an
uninitialised variable just read what the tools tell you!
You comment that Lisp code is properly indented in the normal
development environment. The same applies to C if you are using a decent
development environment, including many free editors which are
independent of specific C compilers. This correct indentation (and free
tools and editors will reindent) make it clear what you are breaking out
of or continuing.
Your comments about interface flaws are now irrelevant in "properly"
written C. Function prototypes have been available for a long time which
provide parameter type checking (your suggestion of a function expecting
a pointer but the call disagreeing would be required to generate a
diagnostic given a function prototype). C99 has added a requirement that
there is always a declaration in scope (although not a full prototype),
and for a long time compilers have been able to warn when a function is
called without a prototype in scope.
Your tradition of functions in lisp returning a condition if there is
nothing else to return is also a tradition in C. You can also return
multiple values in C by wrapping them in a struct, although this is
fiddly and not generally done.
Your section 4.3 I consider irrelevant since a modern editor will show
you if the extra statement for an if is not part of the "then" clause
since it will indent it in a way which makes this clear!
There are times when your hard real-time constraints mean that even a
1ms delay for GC would be problematic, so for such code I would still
not use a language with GC. I would happily consider other languages,
however, and would not insist on C. I also would not rule out Lisp for
other tasks just because it might not be suitable for this one.
I've done a lot of work on systems with less than 64K of memory, where
again the overhead of Lisp would not be acceptable. Adding more memory
would up production costs, power requirements and heat dissipation which
are all things which need to be kept down (under hard limits) for some
systems.
In short, use the right language for the job, which may not be Lisp or
C, and bare in mind all of the points. I won't spend a wek learning a
new language to write a 50 line program, but I might for a far larger
program. I've sometimes spent an hour learning a language to write 1
line of code, because I knew it was the right tool for the job!
--
Flash Gordon
James Kuyper
> On Sep 11, 6:02�am, Richard Heathfield <r...@see.sig.invalid> wrote:
> ... Is confusion between "(*n)++" and "*n++"
> or between "**p" and "*p" really a major source of C's alleged
It's been decades since I stopped making mistakes that simple, but it's
not uncommon in newbies.
> ... Isn't "0" the only Boolean false
> in C? ...
If you mean a value of boolean type no. The constant 0 has int type. C90
doesn't have any boolean type as such; in C99 you could use (_Bool)0 or,
if you #include <stdbool.h>, you could also use (bool)0.
If you mean a value that is treated as false when it appears as a
condition in if(), while(), or for() statements, or in ?: expressions,
the answer is still "No". Any C expression with a value of 0 is treated
as false in those contexts. The value 0 can be represented in any
integer, floating point (including complex and _Imaginary), or character
type. As a special rule, a null pointer of any type compares equal to 0,
even though 0 is an integer, not a value of pointer type: the 0 gets
implicitly converted to a null pointer of the corresponding type, for
purposes of the comparison.
As a result, there are LOTS of ways to write a constant with a value
that counts as false in C. Here's just a few of them:
0, 0X0, 0U, 0L, 0LL, 0.0, 0.0E10, 0.0F, 0.0L, 0.0P-5, '\0', L'\0', '\x0'
And of course, (T*)0, where T represents any arbitrary type.
If you #include <stdbool.h>, you can also use the macro named "false",
which expands to a 0. I would have thought it slight more appropriate to
have it expand to (_Bool)0, but given the way C's integer promotions
work, that wouldn't make much difference.
I think it would be a good idea for conditions to require an expression
of boolean type, with all comparison operators returning values of that
type, and with no conversions allowed to and from boolean type. The
equivalent of such conversions could be achieved by
(nonbool == 0)
and
(boolvalue ? 1 : 0)
Such rules would be a minor inconvenience when writing code, but would
make the code clearer and more maintainable. However, the need for
backwards compatibility means that such a change could never be made to C.
...
> (BTW, gcc accepts both "a+ + + +b" and "a+ ++ +b"
> without complaint but generates *different* results
> for them! Is *this* compliant?)
I don't think so. I believe that the first form is equivalent to
a + (+(+(+b)))
or in other words, a + b. The second form is equivalent to
a + (++(+b))
Which is a constraint violation because the result of the unary +
operator is not an lvalue, and the ++ operator requires an operand that
is an lvalue.
Curt
>
> 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.
> ..............
I hope I'm not being rude, but I don't think you can "commit" a pitfall.
It seems to me that sensible people try to avoid them. Maybe in C
they're difficult to avoid because of their proximity to well-traveled
paths or their sheer numerosity.
;-)
Nicolas Neuss
> But performance is clearly one factor. (Not the only factor, as
> Richard Gabriel rightly points out.) 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.
If one uses a good Common Lisp implementation (especially one which
compiles to native code, as e.g. CMUCL/SBCL, Allegro CL, or Lispworks),
fI would expect that for most code the results for equivalent code are
not worse than C by a factor of 2 or maybe 3. The reason is that one
can write Common Lisp code also very C-like, with type and optimization
declarations, so there is no language reason why compiled code should be
slower. (The observable difference is due to slightly less elaborate
compiler backends and possibly also garbage collection.)
Nicolas
Michael Weber
> But performance is clearly one factor. (Not the only factor, as
> Richard Gabriel rightly points out.) 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.
Most things we do the first time are "quite difficult". With some
practice and a profiler which tells you where the hot spots are, it's
actually not hard at all to optimize Lisp code; certainly not harder
than optimizing C++ code, IME.
In fact, this is something that I like about CL in comparison to other
dynamic languages: I don't have to drop down to C to make it fast. I
can eliminate performance bottlenecks while staying within the
language, and keep all the flexibility and comfort of a dynamic
language where performance does not matter.
Some pointers:
* ICFP 2006 VM in CL, run-time within 20% of C implementations (but
quite a bit shorter) by adding a few declarations:
http://www.foldr.org/~michaelw/log/programming/lisp/icfp-contest-2006-vm
* B. Svingen, "When Lisp is faster than C",
http://www.cs.bham.ac.uk/~wbl/biblio/gecco2006/docs/p957.pdf
* D. Verna, "Beating C in Scientific Computing Applications",
http://www.lrde.epita.fr/~didier/research/verna.06.ecoop.pdf
Richard Fateman
implausible mistakes in the C programming language:
I once again recommend that you look at Weider Yu's article, where he
itemizes these pitfalls as frequent causes of erroneous behavior that
were found in production code, in a Bell System ESS switching system.
These items were presumably written by programmers who were paid (some
would call them "professional programmers").
I didn't make them up.
My point was, Yu didn't consider the obvious solution to avoiding these
pitfalls: Choose a programming language that did not have them. Is this
point weakened by the availability of tools that can catch some of these
errors automatically (if they are used)? Maybe somewhat. Is there a good
argument that C is now the right language to use if your priority is
reliable code? Maybe the argument would be that academics are working
on proving the correctness of programs written in C? Maybe the argument
is that there are so many more C programmers that you should just have
multiple teams writing the code, and run the programs at the same time
and have them "vote"? (Especially after recent layoffs, you should be
able to hire lots of them.)
>>
>> 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.
>
By the way, when I wrote the article, I just posted it on my web page. I
did not try to publish it anywhere. The editor of that publication
found it on my web page and asked if he could publish it. I allowed it.
RJF
PS. While I wrote the article, and I still pretty much agree with what
it says, I did not start this thread :)