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: J�rgen Exner on 12 Mar 2010 12:22 bugbear <bugbear(a)trim_papermule.co.uk_trim> wrote: >These days, it's quite common to see 'C' categorised >as a portable assembly language. Absolutely. I have worked on compilers, which generated C-code as the target output. And C is working very nicely for that purpose. jue
From: D Herring on 12 Mar 2010 21:10 On 03/12/2010 09:45 AM, Tim Bradshaw wrote: > On 2010-03-12 05:44:14 +0000, Ron Garret said: >> The world is slowly -- oh so slowly -- beginning to >> come to its senses about this and realizing that the right way to solve >> this problem is not to make it easier to generate parsers but to >> standardize the representation so that you don't have to spend your >> whole life writing parsers. If you standardize the representation you >> can just write ONE parser and then go spend your time on more productive >> pursuits. > > This may be true in some domains, but I think the amount of unstructured > data that is being generated is so spectacular that the structured stuff > will always be trivial. (Think video and audio). Yes and no. With data descriptions such as HDF5 and XDR, we are slowly getting abstract structured approaches to describing binary data. Yes, pattern matching of the contents will always be a bigger task; but the data representation should eventually formalize. - Daniel
From: Vassil Nikolov on 12 Mar 2010 23:37 On Fri, 12 Mar 2010 15:47:08 +0000, bugbear <bugbear(a)trim_papermule.co.uk_trim> said: > ... > These days, it's quite common to see 'C' categorised > as a portable assembly language. It has been categorized like that for at least two decades (and that must be an underestimate). (I agree with the sentiment.) ---Vassil. P.S. Not cross-posted. -- No flies need shaving.
From: Peter J. Holzer on 15 Mar 2010 15:44 On 2010-03-12 02:14, John Bokma <john(a)castleamber.com> wrote: > "Peter J. Holzer" <hjp-usenet2(a)hjp.at> writes: >> On 2010-03-10 20:54, John Bokma <john(a)castleamber.com> wrote: >>> I do agree, however, that it would've been nice if C had references like >>> Perl, and (harder to get to) pointers as they are now. >> >> Actually, C pointers are quite ok in theory (for example, you can't make >> a pointer into an array point outside of the array (except "just after" >> it). > > How does C prevent this? Or I don't understand what a pointer into an > array is. > 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
From: Peter J. Holzer on 15 Mar 2010 17:27
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 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 |