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

[Daniel Weinreb <address@hidden>]

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.

> Also, especially in
>the scripting domain, it may create the temptation to simply trap and ignore
>exceptions, which can be worse.
>
But in any half-decent exception system, it's easy to say that you want 
to ignore a specific class of
exception, rather than ignore exceptions as a whole.  Using Java 
terminology, you just set up a try/catch
with one empty catch clause naming the class.

>
>
>The second reason is that human reasoning about control flow can be a little
>easier without exceptions. 
>
Wow, what a statement.  The whole point of exception systems is 
precisely to make the control
flow easier to understand.  If you're having the opposite effect, I 
respectfully suggest that you
are misusing 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. 
>
So what you're telling me is that if you are reading a program, and the 
program calls entrypoint X,
and you don't know the API (the contract) for X, then you might have 
trouble understanding
the program.  Well, gee, that would be true even if there were no 
exceptions at all!  Of course
you have to understand the contract of the entrypoint you call!

> 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.
>
Well, if improper and uncareful design is your goal, then I guess you 
and I are not very
interested in doing the same things as each other...

>
>
>(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.)
>
OK, I completely concede that you have to use exceptions carefully and 
in the right way in order
to avoid this problem.  At eXcelon on the BPM project, Mike Rowley and I 
wrote up a set of
coding standards for using exceptions, which effectively solved this 
problem.  It did, as you suggest,
include a logging facility.  Without such a coding standard, it's very 
easy to screw up and cause
bad effects.  So my previous remarks should have been made contingent on 
this.

I'd really like to publish the coding standard, but (1) eXcelon owns it 
and I don't work there,
and (2) it's not quite totally perfect (I know, bad excuse).  I have a 
dream that someday I'll
write a really great paper explaining all my feelings about exceptions, 
and I have a place in
my office where I'm piling up raw material on which to base this paper 
someday.

>
>
>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. 
>
That has not been my experience.  I have spent endless time with scripts 
that are careless about
handling exceptional circumstances.  Generally they ignore exceptions, 
often by failing to check
error codes, and so they keep executing even after things have failed, 
leading to more complex
and profound mistakes and errors, eventually resulting in a car-crash 
that's very hard to understand
and fix.

> 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.
>
That's fine if programmers always, always, always check the "exception 
return" code and put
in explicit branches or "exit" statements, except in cases where you 
GENUINELY don't
care about the code.  I have found this to be rare in practice.  It's 
not only scripting languages,
by the way.  Unix circa 1981 was really, really sucky in this way. 
 Applications routinely
didn't check "errno" and when things went wrong, it ended up being very 
hard to debug
problems since the programs were not fail-fast (i.e. they kept running 
even though their
assumptions had been violated).  It was not a pretty sight.

>
>
>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.
>
Do you divide the world into two classes, "mission critical" and "it 
make no difference whether there
are gobs of bugs"?  My own personal values say that message boards and 
collaboration systems
should work properly.  The current state of the software world is just 
miserable.  I'm almost embarrassed
to tell people that I am a software engineer.  It is amazing that the 
world puts up with software
as it currently exists.  We, as a profession, have to really get our act 
together about demanding
correctness, not only in avionics and medical instrument software, but 
even in message boards.
In my humble opinion.

>
>
>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.
>
Needless to say I totally disagree.  If I had to program in Java without 
the exception system, life
would be far worse than with the exception system.  Life would be better 
if the Java exception
system embodied more of the stuff that's in the coding standards that 
Rowley and I created.
In fact they have made one step in that direction in Java 1.4, adding 
the "cause" (or whatever
it's called) instance variable, which we were doing as part of our 
conventions.  Maybe I ought
to write that paper and then see if I can come up with any good JSR 
proposals along its
lines.  In my copious spare time.