Re: Scriptometer: measuring the ease of SOP (Script Oriented Programming) of programming languages

[Pixel <address@hidden>]

Daniel Weinreb <DLWeinreb@attbi.com> writes:

> Anton van Straaten wrote:
> > I see at least two reasons to prefer the "bug-prone" approach, for scripting
> > and prototyping purposes. First, as Pixel pointed out, there are many cases
> > in which the caller really doesn't care about the error that's been
> > signalled. Working with exceptions is like working with people who are prone
> > to panicking - every little mishap sends them running into your office
> > (usually while you're on the phone :) That makes it harder to miss a
> > potentially problematic event, but you get a lot of false alarms, and these
> > have a development cost.
>
> Could you give me some examples of what you consider to be false alarms? And
> why you have any confidence that ignoring such things constitutes correct
> behavior? Sure, "delete this file" may be able to ignore "file does not exist"
> in many (but not all!) cases, but perhaps you're in big trouble if it gets a
> "device is not mounted" (meaning that the file may very well exist out there
> and not be deleted). Just assuming that the exception can be ignored, without
> thinking about it, is a recipe for buggy programs.

Agreed

*but* buggy programs can be better than less buggy programs that
*fail* in production. Perl is able to go on in most cases. This is
quite bad when debugging/testing, *but* this is a strength in
production when bugs are not critical, when the program consist of
small independent tasks.

- good handling of errors is expansive (gui messages to signal errors
and propose to ignore them when possible, writing the error messages,
translation of those messages)

- some libraries can have *many* various ways of failing, and many
errors will never occur. Determining which errors are worth the
trouble, and in which practical occasion they occur is hard. It can be
done on demand: when an new pb occurs, you detect why it took place
and add handling for it.

- to detect the important problems, one can use some logs. The main
idea is to replace exceptions with debugging messages in some log
file. That way ignored problems can be looked at when needed.

This above would *not* be valid in C where problems cause the whole
program to go wild (ever heard of forking to enable segfault recovery! :)

--
Pixel
programming languages addict      http://merd.net/pixel/language-study/