to RG - Lisp lunacy and Perl psychosis
in [Lisp]
|
Prev: The correct choice for implementation (was: A simple web clientlibrary)
Next: Solved Re: Emacs speedbar doesn't show .lisp and .asd files
From: RG on 15 Mar 2010 19:23 In article <slrnhpt9hi.is.hjp-usenet2(a)hrunkner.hjp.at>, "Peter J. Holzer" <hjp-usenet2(a)hjp.at> wrote: > On 2010-03-12 05:04, Ron Garret <rNOSPAMon(a)flownet.com> wrote: > > In article <slrnhpisqf.i4n.hjp-usenet2(a)hrunkner.hjp.at>, > > "Peter J. Holzer" <hjp-usenet2(a)hjp.at> wrote: > > > >> In any case I very much doubt that it is much easier to find the bug in > >> a lisp program which "suddenly started failing silently and > >> intermittently" than in a Perl program which does the same. > > > > I assure you, you are quite mistaken. I have a first-hand data point on > > that as well: > > > > http://ti.arc.nasa.gov/m/pub/archive/2000-0176.pdf > > Interesting paper. > > But I don't think it proves your point. > > 1) Perl isn't mentioned at all So? I was responding to a claim you made about Lisp. > so you cannot draw any conclusions about > Perl from the paper (neither negative nor positive). Not from that paper in isolation. But I cited that paper within a conversational context. Do I need to review it for you? > 2) The verification tool mentioned doesn't work on Lisp input, but uses > a specialized modelling language called PROMELA. That is completely beside the point. The relevant part of the paper is section 2.3. It has nothing to do with Promela. > 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. 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
From: Peter J. Holzer on 15 Mar 2010 19:06 On 2010-03-15 23:23, RG <rNOSPAMon(a)flownet.com> wrote: > In article <slrnhpt9hi.is.hjp-usenet2(a)hrunkner.hjp.at>, > "Peter J. Holzer" <hjp-usenet2(a)hjp.at> wrote: >> On 2010-03-12 05:04, Ron Garret <rNOSPAMon(a)flownet.com> wrote: >> > In article <slrnhpisqf.i4n.hjp-usenet2(a)hrunkner.hjp.at>, >> > "Peter J. Holzer" <hjp-usenet2(a)hjp.at> wrote: >> >> In any case I very much doubt that it is much easier to find the bug in >> >> a lisp program which "suddenly started failing silently and >> >> intermittently" than in a Perl program which does the same. >> > >> > I assure you, you are quite mistaken. I have a first-hand data point on >> > that as well: >> > >> > http://ti.arc.nasa.gov/m/pub/archive/2000-0176.pdf >> >> Interesting paper. >> >> But I don't think it proves your point. >> >> 1) Perl isn't mentioned at all > > So? I was responding to a claim you made about Lisp. I made a claim about the relative merits of Lisp *and* Perl. >> so you cannot draw any conclusions about >> Perl from the paper (neither negative nor positive). > > Not from that paper in isolation. But I cited that paper within a > conversational context. Do I need to review it for you? I could use the same condescending tone you use, but I won't. >> 2) The verification tool mentioned doesn't work on Lisp input, but uses >> a specialized modelling language called PROMELA. > > That is completely beside the point. The relevant part of the paper is > section 2.3. It has nothing to do with Promela. 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: >> 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). [...] >> 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. > > I didn't say it was conclusive, I said it was a data point. 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)). > 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. 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. > 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. 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".
From: RG on 15 Mar 2010 21:55 In article <slrnhptfbt.je0.hjp-usenet2(a)hrunkner.hjp.at>, "Peter J. Holzer" <hjp-usenet2(a)hjp.at> wrote: > I could use the same condescending tone you use, but I won't. But then of course you do: > 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. 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[1] doesn't help you much finding race conditions or bugs that cause > the program to "start failing silently and intermittently". 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
From: Tim Bradshaw on 16 Mar 2010 06:16 On 2010-03-16 01:55:59 +0000, RG said: > A REPL can be very useful in debugging such problems. Having a REPL > aboard DS1 was invaluable in finding and fixing the RAX bug. You need to beware of digging yourself into a pit. I'm sure no one is claiming that REPLs are not useful. Are you arguing that Perl can not have a REPL? Or that peope deploying Perl in environments where remote debugging might be important would somehow be too stupid to provide one? These seem like weird claims to me: I can only asume you're making them from a deep ignorance of Perl, as I assume you're not trying to mislead people (this is not an ironic remark). But if you are so ignorant of Perl why are you arguing against it so virulently?
From: Nick Keighley on 16 Mar 2010 08:05
On 12 Mar, 06:02, Ron Garret <rNOSPA...(a)flownet.com> wrote: > In article <hnbvsd$5b...(a)news.eternal-september.org>, > Tim Bradshaw <t...(a)tfeb.org> wrote: > > On 2010-03-11 18:24:32 +0000, Ron Garret said: > > > C++ is clearly > > > harder to learn than, say, Scheme, and yet I'm pretty sure that more > > > people know C++ than know Scheme. > > > On what basis is it then harder to learn? > > You're kidding, right? Are you seriously questioning the claim that C++ > is harder to learn than Scheme? I'll stick my experience in as a data point. I've tried to learn both of them. C++ I'm still scared of templates. I can use the STL and write simple ones of my own. (And learning scheme may get me to do C+ +'s functional stuff...). I'm wading through Alexandrescu's book. Jolly Clever chap I'd say. Scheme, I'm *almost* there with call/cc. Hmm. macros. It's be kind of unfair to lambast C++ templates and sing the praises of scheme's macros. How many are there? define-macro, define-syntax, syntax-rules, syntax-case. Yes I know those things aren't all at the same level. Then there's all the slightly away from the main stream stuff quasisyntax and sweet macros. A lack of easy to find teaching material. Is that a standard way to expand a macro? So no, scheme ain't easy to learn. Hygenic macros are Jolly Clever, but... > > I think you may be confusing "has a small definition" with "is easy to learn". > > No, though being small certainly doesn't hurt, all else being equal. > (But of course, being small can be taken too far. Unlambda is smaller > than Scheme, but it's much harder to learn to program in Unlambda than > it is to program in Scheme.) > > > That would make, > > say, general relativity, something that is very easy to learn (much > > easier than being able to cook competently, say), but I don't think > > that is true. > > That's hardly a fair comparison. You're taking one narrow topic (GR) > and comparing it to an entire field of study (cooking). A better > comparison would be GR versus how to make a souffle, or learning how to > cook versus learning physics. > > The reason C++ is hard to learn is not that it's big per se. Common > Lisp is big too, but it's vastly easier to learn that C++. The reason > C++ is hard to learn is that it burdens the programmer with remembering > endless minutiae, all of which are essential to producing working code. I have a checklist - should DTOR be virtual - should CTOR be explicit - do you want the Big Three - do you want operator== - should this member func be const and there's probably a longer internal checklist. What should be virtual or abstract? What should be public or private (or protected)? What should be static? Static member values have to be defined somewhere. Which smart pointer should I use here? "Is it (exception) Safe" Marathon Coder > Google for "C++ coding standards" and compare the result to "Scheme > coding standards." There's an entire industry devoted to reminding > people of the myriad things they must keep in mind while coding in C++. Where is "More Effective Scheme"? -- Nick Keighley |