R
Ron Garret
Martijn Lievaart said:
I'm sure there were. But it's not that I'm holding out on you, it's
that I never fully understood the details even at the time.
rg
I'm sure there were. But it's not that I'm holding out on you, it's
that I never fully understood the details even at the time.
rg
N
Nick Keighley
now there's a challenge. Who are the other competitors?
- FORTRAN computed goto
- FORTRAN fixed layout
- Algol-60 free layout
- Algol-60 call by name
- Pascal with
- C declaration syntax
- C++ template syntax
- C++ exception specification
- PL/I
M
Mario S. Mommer
Nick Keighley said:
I miss
- FORTRAN common blocks
from that list. And with respect to C++ templates - well, the syntax
isn't really the worst part.
Mario.
F
Frank Seitz
Nick said:
The classical Perl FILEHANDLE
Frank
--
Dipl.-Inform. Frank Seitz
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel
Blog: http://www.fseitz.de/blog
XING-Profil: http://www.xing.com/profile/Frank_Seitz2
J
John Bokma
Nick Keighley said:
PHP
XHTML
F
Frank Seitz
John said:
What is wrong with XHTML?
Frank
--
Dipl.-Inform. Frank Seitz
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel
Blog: http://www.fseitz.de/blog
XING-Profil: http://www.xing.com/profile/Frank_Seitz2
J
John Bokma
Frank Seitz said:
People seem to have a hard time to get it right. Thankfully, browsers
are forgiving: they work around not-well-formed XHTML, which is contrary
to what XML stands for.
Maybe XML should've been on that list as well. It has enough warts which
is funny for such a simple language.
P
Pascal J. Bourguignon
John Bokma said:
Well, since C is weakly-to-not typed, you cannot enforce it at the
variable site, however, it is specified indeed that it is invalid or
undefined to derefer a pointer that doesn't point to allocated memory,
and to compare pointers that don't point to elements of the same array
or one beyond. This can be enforced by heavy pointers and run-time
checks. Of course, since they prefer to have their results fast than
correct, this is rarely enforced.
One way is to define pointers as:
typedef struct {
address arrayBase;
int elementSize;
int elementCount;
int index;
} Pointer;
Pointer NULL={0,0,0,0};
void Pointer_incr(Pointer* p){
if(p.index<p.elementCount){
p.index++;
}else{
error("Trying to increment a pointer out of bounds"); }}
void Pointer_decr(Pointer* p){
if(0<p.index){
p.index--;
}else{
error("Trying to decrement a pointer out of bounds"); }}
int Pointer_minus(Pointer p,Pointer q){
if(p.arrayBase!=q.arrayBase){
error("Incompatible pointers");
}else{
return(p.index-q.index); }}
bool Pointer_equalp(Pointer p,Pointer q){ return(Pointer_minus(p,q)==0); }
bool Pointer_lessp (Pointer p,Pointer q){ return(Pointer_minus(p,q)<0); }
T Pointer_deref(Type T,Pointer p){
if(p.index<p.elementCount){
return(deref(T,p.arrayBase+p.index));
}else{
error("Trying to dereference out of bound pointer."); }}
char a;
char b;
int c[10];
int d[10];
char* p1=&a; /* <=> p1.arraybase=address_of(a);
p1.elementSize=1;
p1.elementCount=1;
p1.index=0; */
char* p2=&b; /* <=> p2.arraybase=address_of(b);
p2.elementSize=1;
p2.elementCount=1;
p2.index=0; */
int* p3=&c; /* <=> p3.arraybase=address_of(c);
p3.elementSize=sizeof(int);
p3.elementCount=10;
p3.index=0; */
int* p4=&(d[9]); /* <=> p4.arraybase=address_of(d);
p4.elementSize=sizeof(int);
p4.elementCount=10;
p4.index=9; */
int* p5=&d; /* <=> p5.arraybase=address_of(d);
p5.elementSize=sizeof(int);
p5.elementCount=10;
p5.index=9; */
char* n=NULL;
p2++; /* <=> Pointer_incr(&p2); */
p3++; /* <=> Pointer_incr(&p3); */
p1==p2; /* <=> Pointer_equalp(p1,p2); <=> error */
p3<p4; /* <=> Pointer_lessp(p3,p4); <=> error */
p4<p5; /* <=> Pointer_lessp(p5,p4); returns false. */
*p4=*p5; /* <=> copies the int from d[0] to d[9]. */
*n=0; /* <=> error (dereferencing NULL) */
P
Paul Wallich
Mario said:
But pointers, common blocks and computed goto (don't know the others
well enough) aren't really computer science, are they? They pretty much
predate any principled study of how languages should be put together,
back in a time when getting any compiler at all to run was a big deal.
Complaining about them is sort of like complaining about the irregular
edges of stone tools.
paul
P
Philip Potter
C *doesn't* prevent it. If you have a pointer to a member of an array,
which you keep iterating with p++ until it goes well beyond the end, the
behaviour is undefined. That means that *no matter what* the compiler
and resulting program does, it's a valid implementation of the C
Standard. It is certainly not required that a C compiler checks that you
don't do something stupid like this.
http://catb.org/jargon/html/N/nasal-demons.html
Phil
P
Philip Potter
COME FROM.
J
Jürgen Exner
bugbear said:
Absolutely. I have worked on compilers, which generated C-code as the
target output. And C is working very nicely for that purpose.
jue
M
Martijn Lievaart
- All of COBOL and especially COBOL74 and earlier.
- Command.com batch language (and to a lesser degree cmd.exe batch
language)
- Java's resource managing techniques (or rather, lack of).
- C++'s automagical creation of copy constructors and assignment operators
Do we have to restrict it to programming languages? Otherwise I know a
few others:
- DOS drive letters
- Unix access control
- ActiveX as used originally, download and execute from any site when
requested.
- Original Mac autorun feature
- Borland technical support
OK, maybe not computer science. Certainly not rocket science
M4
P
Pascal J. Bourguignon
#include <iostream>
template <int N> struct Factorial {
enum { value = N*Factorial<N-1>::value };
};
template <> struct Factorial<1> {
enum { value = 1 };
};
int main()
const int f15=Factorial<15>::value;
std::cout << f15 << std::endl;
return 0;
}
I lose track of the count of syntactic irregularities...
But you're right, it's not the worst part:
-*- mode: compilation; default-directory: "/tmp/" -*-
Compilation started at Fri Mar 12 20:19:03
SRC="/tmp/f.c++" ; EXE="f" ; g++ -I. -L. -g3 -ggdb3 -o ${EXE} ${SRC} && ./${EXE} && echo status = $?
/tmp/f.c++: In instantiation of 'Factorial<13>':
/tmp/f.c++:4: instantiated from 'Factorial<14>'
/tmp/f.c++:4: instantiated from 'Factorial<15>'
/tmp/f.c++:12: instantiated from here
/tmp/f.c++:4: warning: integer overflow in expression
/tmp/f.c++: In instantiation of 'Factorial<14>':
/tmp/f.c++:4: instantiated from 'Factorial<15>'
/tmp/f.c++:12: instantiated from here
/tmp/f.c++:4: warning: integer overflow in expression
/tmp/f.c++: In instantiation of 'Factorial<15>':
/tmp/f.c++:12: instantiated from here
/tmp/f.c++:4: warning: integer overflow in expression
2004310016
status = 0
Compilation finished at Fri Mar 12 20:19:04
vs.
(defun fact (n) (if (= 1 n) 1 (* n (fact (- n 1)))))
(defmacro factorial (n) (fact n))
(defun main ()
(let ((f15 (factorial 15)))
(print f15)
0))
(main)
1307674368000
0
P
Peter J. Holzer
You removed the next sentence where I wrote that it doesn't. It just
says "that's forbidden", but leaves to compiler complete freedom how to
deal (or not deal) with the situation. Most compilers (for the sake of
efficiency and compatibility with existing ABIs) assume that the
programmer never makes a mistake and produce code which will happily
scribble over neighbour variables. A very few however will produce code
which catches the error and raises an exception.
hp
P
Peter J. Holzer
Interesting paper.
But I don't think it proves your point.
1) Perl isn't mentioned at all, so you cannot draw any conclusions about
Perl from the paper (neither negative nor positive).
2) The verification tool mentioned doesn't work on Lisp input, but uses
a specialized modelling language called PROMELA. The authors state:
The modeling effort, i.e. obtaining a PROMELA model from the LISP
program, took about 12 man weeks during 6 calendar weeks, while the
verification effort took about one week. The modeling effort
consisted conceptually of an abstraction activity combined with a
translation activity. Abstraction was needed to cut down the program
to one with a reasonably small finite state space, making model
checking tractable. Translation, from LISP to PROMELA, was needed to
obtain a PROMELA model that the SPIN model checker could analyze.
[...]
The translation phase was non-trivial and time consuming due to the
relative expressive power of LISP when compared with PROMELA.
Spending 12 man-weeks hand-translating Lisp to PROMELA doesn't
exactly sound like it's easy - in fact the authors explicitely called
the task "non-trivial".
3) Then the authors built an automated translation tool, but again it
doesn't translate Lisp to PROMELA, it translates (a subset of) Java
to PROMELA. So, again, they had to hand-translate Lisp to Java, which
could then be automatically processed. At least translating Lisp to
Java was very quick (two hours!) but that may be because
Some of us spotted the potential error situation because it
resembled the similar error we had found using SPIN in 1997[...]
and the subsequent
focus on the particular code fragment
The error is a text-book example of a race-condition, btw. It is
discussed in almost identical form in any systems programming class,
and they could have spotted it because of that and not just because
the encountered it before.
4) The RAX team found the error within 24 hours, the JPF team within
48 hours (but they also had identified the code fragment as
suspicious within 12 hours).
In conclusion, there is nothing in the paper which suggests that Lisp in
particularly easy to model. If anything, they seem to suggest that Java
is easy to model, although I suspect that "shrinking down" real world
Java programs to a manageable complexity is still non-trivial, even with
the help of their abstraction tool.
That two independent teams each found the race condition within less
than two days is impressive. That may be a hint that Lisp makes it
relatively easy to spot that kind of error. But without more knowledge
about the specific case and a direct comparison to other programming
languages it isn't conclusive.
hp
P
Peter J. Holzer
I made a claim about the relative merits of Lisp *and* Perl.
I could use the same condescending tone you use, but I won't.
You didn't say what the relevant part of the paper was. You should
expect that when you cite a paper as support of your claims that one
assumes that the topic of the paper has something to do with your claim.
However, I noticed section 2.3:
But without knowing more about the case and a comparison to other
languages you really can't say whether finding the bug within a day was
fast or slow. I've found similar bugs in C programs within 5 minutes, so
I could claim that C is much easier to debug than Lisp (omitting the
important facts that the C programs where rather short (a few hundred
lines) and were written by students in a systems programming course
(so I expected race conditions and was specifically looking for them)).
A REPL[1] doesn't help you much finding race conditions or bugs that cause
the program to "start failing silently and intermittently". So it is
moot for the two cases you mentioned. It can be very helpful in other
cases, though.
I didn't say that Perl is easier to debug than Perl. I said I doubt that
Lisp is much easier to debug than Perl. There is a slight difference
which you should be able to spot.
hp
[1] The Perl module Devel::REPL is on the first page of Google results
when you search for "REPL".
R
RG
Peter J. Holzer said:
So? I was responding to a claim you made about Lisp.
Not from that paper in isolation. But I cited that paper within a
conversational context. Do I need to review it for you?
That is completely beside the point. The relevant part of the paper is
section 2.3. It has nothing to do with Promela.
I didn't say it was conclusive, I said it was a data point.
But FWIW, there are sound theoretical reasons to believe that Lisp
programs are easier to debug than Perl programs, mainly because Lisp has
a REPL and Perl (normally) does not.
But I really don't feel like arguing about this. If you think it's
easier to debug Perl than Lisp then go for it.
rg
R
RG
Peter J. Holzer said:
But then of course you do:
Frustration can drive even the best among us to snarkiness.
Look, I understand what you were saying the first time you said it. But
I disagree with you: I think Lisp is easier to debug than Perl. I have
two data points and one theoretical argument to support my position, but
no hard proof. I might be wrong. But all the evidence I have at my
disposal indicates to me that I am not.
BTW, I disagree with this too:
A REPL can be very useful in debugging such problems. Having a REPL
aboard DS1 was invaluable in finding and fixing the RAX bug. And
there's another data point in the NASA lore to support this point of
view: there was a similar problem with the Pathfinder Rover that was
found and fixed using a virtually identical process. In this case the
software was written in C, but there was nonetheless a REPL because the
C code was running under vxWorks, which provides a shell that, while not
a full REPL, provides much of the same functionality.
If you have some actual evidence or theoretical arguments to support
your position let's hear them. All I've heard from you so far is
unsupported assertions and arguments of the form, "You haven't proven X,
therefore X is not true." If that's all you've got we'll just have to
agree to disagree.
rg
N
Nick Keighley
why would the presence of a REPL theoretically make debugging
something easier? Whose theory? Ive debugged small Perl and Scheme
programs.