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

[Daniel Weinreb <address@hidden>]

Anton van Straaten 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.  Even though 
LL2 is
imminent, we're still enjoying the benefits of LL1.  Isn't that cool?

>Daniel Weinreb wrote:
>
>
>The difference is that in all other respects, the contract does not involve
>screwing with the caller's control flow.  It simply involves values provided
>and received - an encapsulated communication.
>
Yeah, that's the difference all right.  That's what we're trying to 
achieve here.

>It's like phoning your friend from your living room and finding that he's
>somehow moved you to the bathroom... :)
>
It's like calling your friend to say "Hey, I missed school today, can 
you tell me what homework
question number 1 was?" and your friend says "I gotta hang up the phone, 
a bug-eyed
monster just came to the door!".  No value is returned by the 
get-homework-question
function.  You get to say how a "gotta-hang-up" is handled.

Using your method, the program just ignores the gotta-hang-up, and 
proceeds as if it
now knows all about homeowrk question one, which it then proceeds to try 
to deal
with, and probably makes a complete mish-mosh of it.

>
>
>Something that could help this in Java, given its static typing, would be if
>IDEs highlighted lines that throw exceptions.  Perhaps you've memorized
>every API in J2EE - I have to confess I'm not there yet, nor would I ever
>want to be.
>
No, I haven't memorized every API in J2EE.  But when I call an API, I do 
have to know what it
is.  I am not in the habit of calling library entrypoints when I don't 
know what they do.  Sure,
good handy API documentation is a great thing.  But the part of the API 
that talks about
the exceptions is just another part of the API.  There's nothing so 
magic about it.  The
description of the API talks about many things: the meanings of the 
inputs, what the outputs
are as a function of the inputs and various global state, the effect 
that the entryupoint has
on various aspects of global state, the global resources that the 
entrypoint consumes,
the exceptoins that it might throw, the datatype of the returned value, 
and so on.  All this
is part of the API.  The idea that you should be able to ignore ONE part 
of the API
description (the exception part) and still use the entrypoint strikes me 
as arbitrary and
unmotivated.  If you want to call an API, you gotta know the contract. 
 Sorry, there's no
way out of that.

>
>
>I want to be clear about something: I'm not saying the whole notion of
>exceptions and the try/catch structure is bad, only that currently it's
>rather primitive and unsophisticated, and that it creates problems as well
>as solving some.
>
I agree that there is room for improvement!

>>
>
>I wasn't actually suggesting coding without the exception system, in the
>kinds of applications for which Java is used.  But I do think the exception
>system could be improved, and you agree:
>
Yes, I do, and I'm sorry if I implied otherwise.

>Yes, many of the flaws I'm talking about can be addressed by coding
>standards.  They could be addressed even better by improvements in the
>language itself, as you suggest:
>
Yes, I agree that often when you see a coding standard, what you're 
seeing is a workaround
for a place where the language isn't as good as it could be.  In our 
particular case, there are
some places where I can see what language feature would be great and 
obviate the need
for our coding standards, and others where I have not yet figured out 
how to do that, but
very likely that's my own deficiency...

>
>
>>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.
>>
>
>This kind of thing is exactly where my characterization of exception support
>as "minimal" comes from.  It's amazing it's taken so long for something as
>simple as this to get into the JDK. 
>
Ah, well, then you get into the whole question of how Sun evolves Java 
and why the evolution is
so slow.  That's a really big topic that I'd rather not try to take on 
just at the moment.

> Let's discuss this again in 10 years
>time - looking back on exception handling today, we'll wonder how people
>managed to get anything done.  Current exception systems are not going to be
>the solution to the allegedly dismal state of software today.  They might be
>an improvement in some senses, but if you're happy with them as they stand,
>your standards may be too low.
>
The bottom line here is that we are agreeing, just saying the same thing 
in a glass-half-empty
and glass-half-full mode.

>
>
>>Do you divide the world into two classes, "mission critical" and "it
>>make no difference whether there are gobs of bugs"?
>>
>
>It's possible to write reliable code without explicit Java-like exceptions.
>
Certainly,and it's possible to write in assembly language, and...

>
>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.  The two concepts 
are quite distinct.  My
usual nutshell explanation of the difference:
(1) if you call square-root on 16 and get back 3, that's an error but no 
exception
(2) if you call divide on 3 and 0, and it throws zero-divide, that's an 
exception but no error,
since divide did precisely what its contract says it should do.

>
>
>I also think it's possible to go overboard in one's insistence on perfect
>systems.  Worse is better, yada yada.  There's a strong economic incentive
>to develop things that are only barely good enough, and that's more of a
>driver of the state of software than anything technical.
>
Well, once one gets down to bedrock values it's hard to go any further...

>
>
>It sounds to me as though your bad experiences with other people's scripts
>
(And it's not just scripts; C programs in 1981 Unix are my favorite 
example, actually...)

>
>have led you to believe that the imposition of mandatory exception handling
>would be the solution. 
>
I don't know what you mean by "mandatory exception handling".  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.

> That would make more sense to me if better exception
>handling systems existed.  As usual in these discussions, we're discussing
>opposite extremes: the Java situation where all possible exceptions have to
>be explicitly managed or passed on by the caller, vs. the error-code
>situation where checking exceptions is completely optional.
>
I'm confused by your mandatory/optional distinction.

In classic Unix, you have the option to ignore checking "errno", and 
programmers tend to do
so, with the result that by default catastrophic errors do not cause the 
program to halt, fail-fastness is
lost, and problems multiply on themselves and are hard to understand and 
debug.  In Java,
you have the option to not bother to put in an explicit catch, and 
progammers tend to do
so, with the result that by default catastrphic errors halt the program, 
but so do exceptional
circumstances that might not be catastrphoic errors, and might not even 
be errors at all.
But how many examples of the "not errors at all" come up in practice? 
 It's pretty rare in  my
experience.

>
>
>Richer systems are certainly possible, e.g. systems with more centralized,
>declarative exception handling strategies, so that I can identify sets of
>exceptions that I don't care about in certain situations, for example, and
>then in those situations, simply identify the exception handling strategy I
>want.  Some of this might be hacked in Java using inner classes and some
>kind of exception profile class, perhaps.  But that still proves my point:
>current systems leave a lot to be desired - and in addition, I don't see a
>lot of attention being paid to it.
>
I've just begun to learn about the aspect-oriented programming stuff and 
from the very little
I know, it sounds as if it might be a good vehicle for achieving some of 
these results.  I hope
to read a lot more of their papers and learn more about it.

>
>
>If you really care about the current state of software, you should join my
>side!  Better exception systems for all!!  ;)
>
I think we may really be on the same side after all.