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

["Anton van Straaten" <address@hidden>]

> Actually I'm not really crazy about either of the examples below because
> they are both based on the bug-prone "programmer had better to remember to
> check the error code" style rather than using exceptions.  I don't see
> any reason why the usual pro-exeception-system arguments should not apply
> to scripts.

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.  Also, especially in
the scripting domain, it may create the temptation to simply trap and ignore
exceptions, which can be worse.

The second reason is that human reasoning about control flow can be a little
easier without exceptions.  With exceptions, every statement potentially
contains a kind of implicit if/goto, and control flow in a calling procedure
is decided by the called procedures, in a way that is usually not explicit
in the calling code.  Looking at a piece of code, it's not possible to tell
without outside knowledge (of the API etc.) which statements may or may not
trigger a control flow discontinuity.  Of course, with proper (and careful!)
exception handling design, this should not be a big problem, but that proper
& careful design is often counter to the goals of scripting.

(A side note is that in most languages with exceptions, they cause the loss
of control flow information when debugging, or even reporting a crash.  The
latter can be compensated for by good logging in the exception handlers, but
this turns what was (and should be!) an automatic operation by the language
into something that has to be explicitly programmed.)

Tying my two reasons together: when you're writing scripting or prototyping
code, and you're a decent programmer, you usually have a good intuition
about which statements are likely to fail in a way that you care about, and
you can insert logic to handle only those cases.  When you're done writing a
piece of code like this, you can read it and know exactly what the potential
control flow is *supposed* to be, without having to assume that every line
can potentially cause subsequent lines to be skipped.

I emphasized "supposed" because of course, this assumes you haven't made any
serious mistakes in your assumptions about which errors need to be handled.
In writing code this way, you're making a tradeoff between what's required
to handle every possible exception, vs. only the ones you care about, and
betting that you're going to save some development time by not handling them
all.

I think "the usual pro-exeception-system arguments" you mentioned apply
strongly in the case of business systems programming where something
"mission-critical" is being developed, usually by a team of varying skills,
and project managers are likely to want the language to be anal about
possible problems.  But the same requirements often don't exist in the
scripting space, even for some important applications - e.g. web-based
message boards and collaboration systems - where the consequences of an
error aren't nearly as severe as they can be in typical business systems.

The implied rant in the above is that I think the exception systems in
languages like Java and C++ are horribly primitive, and are only put up with
as a necessary evil.  They do address an important issue, but they do so in
the most minimal and invasive way possible.  Think of them as punishment for
your imperfections as a programmer.

I haven't worked enough with Python to know whether its system works any
better.  Certainly, not having the extra coercion of a static type system
checking exception signatures could make things a little less PITAish, but
that's not the only problem.

In fact, exception handling is an area where the scripting languages might
be able to do a better job, and come up with some useful innovations, with
their tendency to a stronger focus on how people use and want to use
languages.

Anton