another frustrating learner question, CLOS
in [Lisp]
|
Prev: Anybody mind to translate this Felleisen quote from German to English
Next: Macros and anonymous functions
From: Nicolas Neuss on 28 Feb 2010 11:09 Giovanni Gigante <giov(a)cidoc.iuav.it> writes: > Btw, I am curious what the volume "lisp style and design" contains. Never > been able to see a copy. You can even obtain it online: http://www.cs.umd.edu/~nau/cmsc421/norvig-lisp-style.pdf But CL is so diverse that (beyond this tutorial) there are many good styles. Ideally, good CL programmers may even write a DSL first for expressing their problem and solution in a suitable way. Nicolas
From: Nicolas Neuss on 28 Feb 2010 11:21 Tim Bradshaw <tfb(a)tfeb.org> writes: > On 2010-02-28 01:01:37 +0000, Zach Beane said: > >> The usual way to do exception handling in Perl is to combine die() (or >> similar) and eval { ... }. There are modules that make the syntax look >> like other languages. > > And of course, this is why Perl is in fact Lisp: there are modules which > make the syntax convenient, for almot arbitrary values of "convenient". Interesting. Which modules are that? Could one easily switch the Perl syntax to S-expressions without writing an own interpreter? Nicolas
From: Ron Garret on 28 Feb 2010 11:31 In article <hmdmv4$tl8$1(a)news.eternal-september.org>, Tim Bradshaw <tfb(a)tfeb.org> wrote: > On 2010-02-28 02:10:26 +0000, Ron Garret said: > > > There was some reason why that wouldn't work. I think it might have had > > something to do with there being ways to have errors in perl that did > > not have the semantics of calling die(). But I don't remember the > > details. If you really want to know I could probably contact one of > > them and ask. > > To me this sounds like some terrible design flaw in the application > which people (not you!) are busily blaming on the implementation > language rather than trying to put right. This doesn't mean I think > they were lying to you - I don't - rather that, as is quite common, > they either did not understand the problem, or were in a state of > denial about it. > > This kind of thing is quite common - I've had discussions with people > who blamed catastrophically bad performance of a tool on slow > performance of the implementation language (and, I think, honestly > believed that) when I knew, because I'd measured it, that it was due to > changing a single line in a ~20M file by rewriting the whole file, and > doing this tens of thousands of times, resulting in hundreds of GB of > I/O. > > Don't misunderstand me - Perl's error handling is deficient, Well, there you go. > but I'm > not sure I'd be willing to say that it makes it impossible to handle > errors. It made it de facto impossible in this case. I didn't (and still don't) know Perl, and all the people who did said it was impossible. Hence it was impossible. Of course this is just one data point. YMMV. rg
From: Giovanni Gigante on 28 Feb 2010 11:52 Nicolas Neuss wrote: > Giovanni Gigante <giov(a)cidoc.iuav.it> writes: > >> Btw, I am curious what the volume "lisp style and design" contains. Never >> been able to see a copy. > > You can even obtain it online: > http://www.cs.umd.edu/~nau/cmsc421/norvig-lisp-style.pdf That's a different thing. The one I am referring to is an old paper book: http://portal.acm.org/citation.cfm?id=78980 > But CL is so diverse that (beyond this tutorial) there are many good > styles. Ideally, good CL programmers may even write a DSL first for > expressing their problem and solution in a suitable way. I am not advocating a single style, and I understand the possible flaws of the idea of "patterns", but if there are bad ways to write lisp code (and there are, as any beginner knows, myself included), it follows that good ways exist too. I would really like to read about lisp best practices, if anything like that exists (examples in PCL points to that direction, but I would like more). g
From: Tim Bradshaw on 28 Feb 2010 11:59
On 2010-02-28 16:31:55 +0000, Ron Garret said: >> Don't misunderstand me - Perl's error handling is deficient, > > Well, there you go. C's error handling is deficient as well, yet people write what are empirically highly reliable systems in C - systems so reliable that one of the significant problems I have at work is making sure they get restarted every so often so we know they still *can* be restarted, in case changes have crept in which will break the boot process. > It made it de facto impossible in this case. I didn't (and still don't) > know Perl, and all the people who did said it was impossible. Hence it > was impossible. Of course this is just one data point. YMMV. Well, it was impossible, but this may not have been because of Perl, which is the relevant point here. I think that before we accuse Perl's lack of exceptions from causing the problem, we would need to know exactly *how* they caused it, because, for instance, C's lack of exceptions still seems to allow Unix to be empirically very reliable indeed. |