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: Pascal J. Bourguignon on 28 Feb 2010 12:24 Tim Bradshaw <tfb(a)tfeb.org> writes: > 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. After 40 years of hard work by a lot of programmers, eventually a unix kernel written in C can work without panicing too often. Ok. But isn't the cost excessive? -- __Pascal Bourguignon__
From: Tim Bradshaw on 28 Feb 2010 13:21 On 2010-02-28 17:24:34 +0000, Pascal J. Bourguignon said: > After 40 years of hard work by a lot of programmers, eventually a unix > kernel written in C can work without panicing too often. It also has a vast number of features which were not in the original kernel of course: I imagine the effort required to make a kernel which only supported the features of the first Unix C kernel reliable would have been very significantly less. > > Ok. But isn't the cost excessive? I don't know. Absent any realistic comparison it's very hard to tell. Again, I'm not arguing that lack of exception handling is a good thing (any more than that I'm arguing that unrestricted pointers such as C's are a good thing), just that they are not necessarily crippling. I think I have probably said as much as I usefully have to say now.
From: Ron Garret on 28 Feb 2010 13:47 In article <hme7d0$3ta$1(a)news.eternal-september.org>, Tim Bradshaw <tfb(a)tfeb.org> wrote: > 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. Reliable code can be written in any language given enough time and resources. The issue is not so much *whether* the code fails but *how* it fails when (not if) it fails. When Lisp or Python code fails it almost invariably does so in a way that preserves the state of the computational process at the point of failure. So you can do things like get a stack backtrace. Or run some kind of recovery or logging code. In some cases you might even be able to resume the computation from the point of failure. By way of stark contrast, when C code fails it generally dumps core. Figuring out what went wrong in that case is much harder. Fixing the problem and resuming are flat-out impossible. I have no idea what generally happens when Perl code fails, but whatever it is, its behavior and utility seem to be much closer to that of C than of Lisp or Python. Note that the code in my anecdote was not unreliable. It had been in production for a long time and generally worked well. The problem was that when it suddenly began to fail, no one -- not even the people who wrote it -- knew how to figure out what the problem was. rg
From: Frank GOENNINGER on 28 Feb 2010 15:25 ccc31807 <cartercc(a)gmail.com> writes: > That's because it was a non-sensical, irrational rant. It's kind of > hard to derive meaning from the meaningless. > > CC. No, it's hard to derive any clue from Erik's message by the clueless. I strongly recommend to read that message again, and again, and again - until you see the light. Frank
From: ccc31807 on 1 Mar 2010 09:53
On Feb 27, 3:08 pm, Ron Garret <rNOSPA...(a)flownet.com> wrote: > It boggles my mind that the same people who > complain about the aesthetics (or lack thereof) of parens in > S-expressions will accept something like this: > > (?:[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*|"(?:[\ > x01-\x08\x0b\x0c\x0e-\x1f\x21\x23-\x5b\x5d-\x7f]|\\[\x01-\x09\x0b\x0c\x0e > -\x7f])*")@(?:(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]* > [a-z0-9])?|\[(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]| > 2[0-4][0-9]|[01]?[0-9][0-9]?|[a-z0-9-]*[a-z0-9]:(?:[\x01-\x08\x0b\x0c\x0e > -\x1f\x21-\x5a\x53-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])+)\]) I'd like to offer some perspective to this, without insulting or casting aspersions. FIRST, regular expressions is a small, separate language. We all run into small separate languages, SQL, XML, HTML, and in Lisp, (format) and (loop). Even configuration files, such as the one for Apache, can be considered small, separate languages. As developers, we pick up these kinds of small languages without missing a stride. Why object to regular expressions? SECOND, regular expressions is a very dense language. You have to read it literally character by character, and one character in a RE can be equivalent to an expression, a function call, or even a function definition in a more verbose language. However, density in and of itself is no reason to object to a language, any more than verbosity. Besides, if you want white space, in Perl you can use the x modifier and comment the RE to your heart's content. THIRD, regular expressions is not peculiar to Perl, being found in Python, Java, awk, in shell commands such as grep, and in applications such as vi and emacs. I use vi a lot, and even though I use REs in Perl, I use REs a lot more in vi, particularly to do heavy duty text editing (e.g., taking a list of words and turning them into variable declarations, variable assignments, and formatted print statements with just a few key strokes.) FOURTH, speaking of Perl, Perl provides alternatives. Indeed, I came to REs late, and having learned Perl from a C background I used substr() and index() a lot and even now turn to these first rather than a regular expression. Perl isn't synonymous with regular expressions, and regular expressions aren't synonymous with Perl. FIFTH, regular expressions in actual use aren't nearly as complicated as the illustration above. They are typically used to strip unwanted characters, such as white space or quotes, to substitute strings, or to extract various parts of a string. I personally don't recall having ever written a RE longer than one line (in Perl), and I have seen very, very few multiple line REs in Perl code. Usually, they are quite simple, and typically are used serially rather than a bunch of functionality packed into one horrendous RE. SIXTH, regular expressions is a specially elegant language for strings. As with most other things, beauty is in the eye of the beholder, but I have seen REs that are breath-takingly beautiful and elegant in their simplicity and creativity. I read through the RE example above, and it would take a bit of time to figure out exactly what it did, at a glance it seems to use look ahead and look behind assertions to pull out certain characters including hex characters. Yes, it looks forbidding at first, and it uses techniques that I don't use every day, but it can easily be broken into component expressions even if we don't fully understand the purpose of each individual component without consulting a reference. In any case, it's certainly not beyond comprehension, and with a little experience not even a WORO expression. CC. |