What is Expressiveness in a Computer Language

[Marshall]

Joe Marshall wrote:
> Marshall wrote:
> > Joe Marshall wrote:
> > >
> > > That's the important point:  I want to run broken code.
> >
> > I want to make sure I understand. I can think of several things
> > you might mean by this. It could be:
> > 1) I want to run my program, even though I know parts of it
> > are broken, because I think there are parts that are not broken
> > and I want to try them out.
>
> I think I mean a little of each of these.
>
> Nearly *every* program I have ever used is buggy, so this is actually a
> normal state of affairs even when I'm not debugging or developing.

That makes some sense to me.

It seems quite reasonable, as a language feature, to be
able to say to the computer: I know there are a few type
errors; just run this damn program as best you can.


> > 2) I want to run my program, even though it is broken, and I
> > want to run right up to a broken part and trap there, so I can
> > use the runtime facilities of the language to inspect what's
> > going on.
>
> I do this quite often.  Sometimes I'll develop `in the debugger'.  I'll
> change some piece of code and run the program until it traps.  Then,
> without exiting the debugger, I'll fix the immediate problem and
> restart the program at the point it trapped.  This technique takes a
> bit of practice, but if you are working on something that's complex and
> has a lot of state, it saves a lot of time because you don't have to
> reconstruct the state every time you make a change.

Wow, interesting.

(I say the following only to point out differing strategies of
development, not to say one or the other is right or bad or
whatever.)

I occasionally find myself doing the above, and when I do,
I take it as a sign that I've screwed up. I find that process
excruciating, and I do everything I can to avoid it. Over the
years, I've gotten more and more adept at trying to turn
as many bugs as possible into type errors, so I don't have
to run the debugger.

Now, there might be an argument to be made that if I had
been using a dynamic language, the process wouldn't be
so bad, and I woudn't dislike it so much. But mabe:

As a strawman: suppose there are two broad categories
of mental strategies for thinking about bugs, and people
fall naturally into one way or the other, the way there
are morning people and night people. One group is
drawn to the static analysis, one group hates it.
One group hates working in the debugger, one group
is able to use that tool very effectively and elegantly.

Anyway, it's a thought.


> > > I want to run
> > > as much of the working fragments as I can, and I want a `safety net' to
> > > prevent me from performing undefined operations, but I want the safety
> > > net to catch me at the *last* possible moment.
> >
> > This statement is interesting, because the conventional wisdom (at
> > least as I'm used to hearing it) is that it is best to catch bugs
> > at the *first* possible moment. But I think maybe we're talking
> > about different continua here. The last last last possible moment
> > is after the software has shipped to the customer, and I'm pretty
> > sure that's not what you mean. I think maybe you mean something
> > more like 2) above.
>
> It is often the case that the proximate cause of a bug is nowhere near
> where the fix needs to be applied.  This is especially true with the
> really hard bugs.  A static type system will tell me that there (may)
> exist a path through the code that results in an error, but the runtime
> check that fails will provide a witness.

Ah, the witness! I see the witness idea as supporting my thesis
that some people are using formal existential reasoning as a
tool for informal universal reasoning.

Very interesting. I want to again emphasize that I am not
interested in labelling one or the other of these approaches
as better or worse; rather, I want to understand both of
them, particularly to see if it is possible to have a single
language that incorporate both approaches.

This is not to say that I don't find one approach more appealing
than the other; rather it is to assert that I can tell the difference
between my personal preference and Truth. (Sometimes.)


Marshall