From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lucio De Re To: 9fans@cse.psu.edu Subject: Re: [9fans] ... in the Kingdom of Sources Message-ID: <20030911190427.A2507@cackle.proxima.alt.za> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: ; from rob pike, esq. on Thu, Sep 11, 2003 at 08:48:43AM -0700 Date: Thu, 11 Sep 2003 19:04:27 +0200 Topicbox-Message-UUID: 31036f64-eacc-11e9-9e20-41e7f4b1d025 On Thu, Sep 11, 2003 at 08:48:43AM -0700, rob pike, esq. wrote: > > precisely. the approach taken by the C standard implies you're > supposed to error check the conversion and presumably yell about it, > maybe exit. but the great majority of text processing code is > interactive - editors, browsers, terminal programs - and must soldier > on. the `error rune' solution not only solves the problem of > soldiering on, it provides a way to yell and takes no code at all in > the application. (if you really want to stop processing on errors, > it's still a simple check; it's just that you almost never have to > bother to check and i can't think of a single program that does.) > I'm willing to concede rob's point. In an interactive environment error checking is counterproductive if a user response would be preferable. But you can't design a standard around "the great majority of text processing code" without sacrificing the ability to deal with the exceptions. I've done a good deal of programming using Don Libes' Expect and it's quite a lesson in the cost of relying in real intelligence to deal with contingencies. MS Windows programming really brings the point home: there aren't many operations I would feel comfortable automating unsupervised. Whereas forgetting the "close" function in a pop-up error message isn't too serious, being unable to detect an out-of-memeory or out-of-disk-space condition in a background task can be catastrophic. I had a print spool completion pop-up appearing at the same time as the screen saver Ctl-Alt-Del prompt pop-up: I didn't have to identify myself before acknowledging the print completion, for example. Is something like that worth worrying about? Not really, but is not perhaps symptomatic of a programming style where all contingencies are passed on to the user except when the user isn't available, in which case they are merely glossed over until disaster strikes, at which point the RESET button comes to the rescue? Whereas in Plan 9 (and Unix) it is easy to distinguish between interactive tools and command line utilities, in Windows the distinction is very thoroughly and almost certainly intentionally blurred. In my experience very few Windows programmers actually code with unattended, unsupervised operation in mind. I think Doug's concerns, like mine, are in laying down rules that make it possible to deal with the unexpected programmatically. The ANSI-C committee, like the ITU-T, seemingly strive to remove all possible ambiguity instead of relying on the human brain to make a choice. It is a sane approach to dealing with computers, even though the compromises made in this quest may be atrocious and, I'm sure, occasionally mistaken. As compromises have to be, when trying to address conflicting requirements. What may help considerably is the acknowledgement that different needs can be addressed by different solutions. For example, Perl is a prime example of a language designed to concoct one-off solutions. Some of us have to do this on a regular basis (I know of one instance where data conversions from continually changing formats is a daily occurrence) whereas others can indulge in monumental works to be used for decades. Writing monumental works in Perl should be discouraged, I'm sure, while Limbo may be quite unsuitable as an instrument to write short sysadmin scripts. Another point worth raising (I think it was Geoff Collyer who first pointed it out) is that graphic programming is still at the level of assembly code. A lot of the decision making in interactive programming is similarly at a very low level and therefore seems extremely cumbersome. Somewhere, somehow - I'd expect rob to be the likely genius to come up with something - somebody will have the flash of inspiration that leads to second and third generation graphic languages. Until then, I think we have to accept that we don't have sufficient grounds on which to construct "standards" that address the real problem, we can only base our recommendations on traditional principles that are undoubtedly obsolete. ++L