[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Daniel Weinreb wrote:
> Thank you very much for this whole conversation. This is going to be
> great raw material for that paper that I'm hoping to write someday.

Thank you too.  As long as you don't write your paper as a Platonic dialog
with me cast as the misguided character who is eventually swayed by your
infallible logic!!

> Even though LL2 is imminent, we're still enjoying the benefits of LL1.
> Isn't that cool?

Yup!

> The bottom line here is that we are agreeing, just saying the same thing
> in a glass-half-empty and glass-half-full mode.

I agree, to an extent. :)

>>In that kind of code, many kinds of error can legitimately, and
implicitly,
>>be ignored.  There are pros and cons to that.
>>
>I am not sure what you are referring to here.  And I am not sure whether
>your use of the word "error" rather than "exception" was deliberate or not.

Sorry, I did mean "exception" (and I *do* know the difference :)  This also
ties into what I mean by "mandatory exception handling".  Because of the way
static typing integrates with exceptions in languages like Java and C++
(probably Ada & Eiffel too?), when a method declares that it throws an
exception, every one of its callers has to take more or less explicit steps
to handle that.  Yes, you can just declare methods as "throws Exception" and
ignore all that, but I'm talking about systems that do try to do the right
thing, which most systems that reach production have to do.

This mandatory exception handling has wide implications for programs - try
adding a minor exception to a widely-used low-level library routine for a
demonstration of this.  While this has good points in a traditional fascist
language kind of way, it cries out (to me) for some more sophisticated
support for exception handling to be made available to the callers of
methods.

I don't consider that an exception architecture like that of current
Java/C++ is suitable for a "lightweight language".  However, simply removing
the static typechecking of exceptions can make an enormous difference,
because it suddenly means you're once again free to implicitly ignore
exceptions if you so choose.  I imagine that's the case in Python - that a
method that can raise an exception can be called, without the caller having
to explicitly handle or declare that exception.  Various 4GL-style languages
have had exception handling like this for a long time - it probably derives
from BASIC - and I've found that approach to be quite reasonable.

You might shudder at the idea of all those potential exceptions not being
explicitly handled, but I think it's important to have that ability, for
prototyping, scripting, etc.  Still, even I see that something big has been
lost in the dynamically-checked case.  But I'm saying that having the
end-programmer bear the entire cost of the static checking is
unsatisfactory.  If the compiler is going to be complaining at me every time
I call a method and don't handle even just one of its exceptions, then I
want that language to give me some good tools to help deal with this in
practice.

That summarizes my biggest problem with Java/C++-style exceptions.  I don't
have a problem with statically-typed languages in general - even with its
various flaws, typical imperative language static type-checking can have big
benefits that can certainly be worth the tradeoff.  I think the case for
static exception handling enforcement as it currently stands is much iffier.

The issue I mentioned of caller control flow is more minor, but I think it's
part of the same broader issue.  To give an example, imagine a try block
with a number of statements in it, and one of them raises an exception that
I believe I can safely ignore, under the circumstances, while other
statements in the same block raise exceptions that are handled in a catch
block.  Or, one statement in the block raises a FoobarException which I want
to handle, and another raises the same type of exception which I want to
pass on up the call chain.  OK, it's certainly possible to handle these
cases, but the handling tends to become pretty convoluted. You can wrap
individual statements in try/catch blocks; have tests in the catch blocks to
take selective action; etc.  The practical result of this, though, is that
programmers often take the line of least resistance, and actually don't
handle the exceptions as well as they could, given better tools.

Also, one of the original points of the try/catch block was to clean up
control flow in the caller - to get rid of all those nested if statements
checking error codes, for example.  If that's replaced by nested try/catch
blocks and/or if/then tests in the catch blocks, little has been gained.  I
also think one tends to lose sight of the forest because of the trees:
important exception handling gets drowned out by all the noise created by
the trivial ones.

> I am not in the habit of calling library entrypoints when I don't
> know what they do.

Yes, but I'm talking about reading, debugging, and maintaining code,
including other people's code, as well as writing it.

> I just think that languages are clearer for the reader and the writer
> when they judiciously and tastfully use an exception mechanism of the
> try/handle variety rather than depending on error-code-parameters
> or global "errno" variables.

I can almost completely agree with that, but I think that in practice, it's
difficult to use exceptions judiciously and tastefully in the
mandatory-exception-handling languages, currently.  Being able to use them
judiciously is what I want, and what the compilers won't let me do.

Anton