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: Raffael Cavallaro on 12 Mar 2010 00:01 On 2010-03-11 19:01:39 -0500, Tim Bradshaw said: > I think this is close to the core of this argument. It seems to me > that for people who don't come from a Unix background, then various > things about Perl might just seem impossibly weird. But for people who > do come from that background, many of Perl's constructs - such as the > way double-quoted strings work - seem like naturual rationalisations of > the way these things work in other tools, specifically the shells and > awk / sed. OK, so then perl is just the unix cancer metastasized. ;^) -- Raffael Cavallaro
From: Ron Garret on 12 Mar 2010 00:04 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 rg
From: Alain Picard on 12 Mar 2010 00:11 Tim Bradshaw <tfb(a)tfeb.org> writes: > On 2010-03-11 02:58:54 +0000, Ron Garret said: > >> And how am I supposed to know that if I don't know Perl? > > This whole "Perl is really hard to learn" thing you have going on is > kind of intersting. I mean, one would think you could test this sort > of hypothesis by looking at the number of people who learn it. Oh, > damn. Well, as a data point, I offer myself as anectodal evidence of perl being "hard to learn". I've written quite a bit of perl, over many years. (Heck, I've got a first printing camel book on my shelf; back when O'Reilly's bindings were shoddy glue. The whole thing is falling apart). Yet I find that whenever I have to revisit some perl, even (especially?) when it's my code, I have to pore over manuals to find out how things work again. Everything I learn just seems to slowly dribble out of my brain as fast as it can; it's almost as if my brain is actively trying _not_ to remember this stuff. I think it's rebelling against the sheer _arbitrariness_ of the language. I've never experience this with any other computer language. I can't be the only person with this experience, can I? I think programmers, good ones, anyhow, naturally develop some sort of esthetic which they use to make design and coding decisions everyday. The way a good chess player no longer sees individual pieces, or how each one moves, but patterns, lines of attack, etc. In Perl, it seems I can never get beyond the "how does this particular piece move again?" stage. YMMV. --alain -- Please read about why Top Posting is evil at: http://en.wikipedia.org/wiki/Top-posting and http://www.dickalba.demon.co.uk/usenet/guide/faq_topp.html Please read about why HTML in email is evil at: http://www.birdhouse.org/etc/evilmail.html
From: Ron Garret on 12 Mar 2010 00:44 In article <hnc093$7ve$1(a)news.eternal-september.org>, Tim Bradshaw <tfb(a)tfeb.org> wrote: > On 2010-03-11 22:28:40 +0000, Peter J. Holzer said: > > > [Ron wrote] > >> It violates universally accepted conventions > >> about what, for example, double quotes mean. For example, this: > >> > >> print "The widget costs $12.75."; > >> > >> The actual behavior of that code snippet is not justifiable under any > >> sane language semantics. > > > > "Universally accepted" is rather strong given that most shells, most > > templating languages and many scripting languages use a similar > > expansion mechanism. > > I think this is close to the core of this argument. It seems to me > that for people who don't come from a Unix background, then various > things about Perl might just seem impossibly weird. But for people who > do come from that background, many of Perl's constructs - such as the > way double-quoted strings work - seem like naturual rationalisations of > the way these things work in other tools, specifically the shells and > awk / sed. May be Ron has never used these tools, I'm not sure. I have never used awk or sed. I have written the odd shell script, but only for really trivial things. The reason I have never used awk or sed is that I learned Lisp very early in my career, long before I ever encountered unix, and so I have always regarded the unix model as deeply and fundamentally broken: the fundamental unit of data exchange is a stream of bytes, but there is no standard for serializing higher level abstractions. As a result there is a horrific mishmash of representations, and a programming culture where people spend a significant fraction of their lives doing nothing but writing parsers for one little mini-language or another. This culture is even reflected in the nomenclature: YACC stands for Yet Another Compiler Compiler, implying that there are other compiler compilers. But of course YACC is not a compiler compiler, it is merely a parser compiler. But when you live in a world where there is no standard representation of higher level abstractions, making it easier to generate parsers has value. Buggy whips were useful once too. Someone in another branch of this thread mentioned that I've spent too much time harshing on Perl's excessive use of punctuation, and they're right. The punctuation isn't the problem. The punctuation is merely a symptom of the real problem. It's not that Perl is bad at solving the problem it was designed to solve, it's that the problem Perl -- and sed and awk and sh and YACC -- were designed to solve is the wrong problem. The problem all these systems are trying to solve is the problem of parsing data formatted according to the ad hoc rules of the zillion little mini-languages that are flitting about through unix sockets around the planet. 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. But of course Greenspun's tenth applies, and so instead of just adopting S-expressions we have SGML and XML and JSON and god only knows what the standard serialization flavor of the month is. And all of them are, of course, isomorphic to S-expressions, or at least a subset thereof. I'm going back to my padded room now. rg
From: Ron Garret on 12 Mar 2010 00:45
In article <732o67-cj6.ln1(a)news.rtij.nl>, Martijn Lievaart <m(a)rtij.nl.invlalid> wrote: > On Wed, 10 Mar 2010 16:41:27 -0800, Ron Garret wrote: > > > Why must those be the only possibilities? It was because the Perl code, > > which had been working fine for months, suddenly started failing > > silently and intermittently, and I was told there was no way to do the > > equivalent of wrapping the whole script in the equivalent of a > > TRY...EXCEPT form in order to catch the error. Whether this was in fact > > true or whether the entire engineering team was incompetent I do not > > know. But they seemed pretty bright and capable otherwise, so it would > > be pretty odd for them all to be mistaken about this. > > If they didn't know about eval { original code here };, they were > incompetent. But there were probably other factors at work you didn't > tell about. 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 |