to cap or not to cap

[Ivan Godard]

I recently spoke to Peter Neumann of SRI, who has been working on caps
with a group at Cambridge in the UK led by Robert Watson. Lots of info
here: http://www.cl.cam.ac.uk/research/security/ctsrd/ The short of it
is that they have a soft MIPS machine running on an FPGA that they have
extended with a hybrid caps system as a research project.Norm: I'm sure
you know Neumann - do you know any of the Cambridge guys?

Their caps (as of the most recent material on the site, which may be out
of date by now) are 257 bits. I'm following up.

[nm...@cam.ac.uk]

In article <klhl1n$s6n$1...@dont-email.me>,

Ivan Godard <iv...@ootbcomp.com> wrote:
>I recently spoke to Peter Neumann of SRI, who has been working on caps
>with a group at Cambridge in the UK led by Robert Watson. Lots of info
>here: http://www.cl.cam.ac.uk/research/security/ctsrd/ The short of it
>is that they have a soft MIPS machine running on an FPGA that they have
>extended with a hybrid caps system as a research project.Norm: I'm sure
>you know Neumann - do you know any of the Cambridge guys?

I know Ross Anderson and Simon Moore fairly well. This was new
to me - I must ask them about it!

I find it sad that the only people who can get support to work on
development environments designed to ensure correctness, assuming
fallible programmers, are the security people - and I know that a
lot of those people agree with me :-(


Regards,
Nick Maclaren.

[Paul A. Clayton]

On Apr 28, 5:46 am, n...@cam.ac.uk wrote:
[snip]

> I find it sad that the only people who can get support to work on
> development environments designed to ensure correctness, assuming
> fallible programmers, are the security people - and I know that a
> lot of those people agree with me :-(

Hmm. It seems that _some_ aspects of "development
environments designed to" *promote* "correctness"
would improve productivity even if 'seems to work' is
considered good enough. Any help to clear thinking
would seem to help in reaching 'seems to work', any
help to clear expression would reduce the programmer's
memory burden (and the communication issues with any
software where more than one programmer is involved
and possibly help in user/specifier-developer
communication), and automated checks would tend to
accelerate turn around time (though such somewhat
hinders reaching 'seems to work', even with that
target automated checks might be helpful).

*Ensuring* correctness might reduce 'productivity',
and available buggy software might be more valuable
than 'too late' correct software (better a leaky
bucket available to fight a fire than hoses and a
pump a month after the fire?)--though such also has
extrinsic costs such as moral corruption (loss of
motivation for excellence/goodness) and intellectual
corruption (loss of ability to think well). (The
accumulation of 'technical debt' is also an issue,
though technological and socio-economic changes [the
relative cost and value of a design can change] can
make desirable the refactoring of even an ideal for
the time design.)

With cheap processing and accumulated knowledge, it
probably is quite sad that software development is
as primitive as it seems to be.

(In hindsight the above seems to add little if
anything new, but I lack the virtue to discard
the writing rather than post it. Maybe there is
some even less programming-literate lurker who
might learn something [that will not have to be
unlearned to avoid error]. :-)

[Ivan Godard]

You, sir, are an optimist.

Every writer of compilers is familiar with the bug report that begins:
"My program used to work fine on compiler version X-1, but now on
version X it's giving me an error message. Didn't you test version X
before you released it? Now I have to roll back the installation until
you fix this bug."

You might not know that early versions of C, favored by such users, gave
fast compilation by assuming that the source code inputs were correct
and doing no diagnosis at all. This approach persists to this day, in C
programmers if no longer in C compilers.

Of course, it is possible to go too far in the other direction. Like
many compilers, the Univac 1108 Fortran compiler would count diagnostics
and break off after some number (assuming that it was irrecoverably
lost) and put out a final diagnostic "Not all errors were reported". We
had a program for which the *only* diagnostic was "Not all errors were
reported".

Ivan

[Paul A. Clayton]

On Apr 28, 5:36 pm, Ivan Godard <i...@ootbcomp.com> wrote:
> On 4/28/2013 2:04 PM, Paul A. Clayton wrote:

[snip]

>> Hmm.  It seems that _some_ aspects of "development
>> environments designed to" *promote* "correctness"
>> would improve productivity even if 'seems to work' is
>> considered good enough.

[snip]

> You, sir, are an optimist.

Perhaps an optimist with respect to what is _possible_;
I am more pessimistic (i.e., more realistic--sigh)
about what is likely to happen (even in that sense I am
optimistic in estimating the improbability of a good
result, but with respect to actions the difference
between 5% or 0.5% and 0.000_005% is that a niche [in
time and/or application] use is perhaps likely in the
former probability and so the change might be worth
pursuing).

> Every writer of compilers is familiar with the bug report that begins:
> "My program used to work fine on compiler version X-1, but now on
> version X it's giving me an error message. Didn't you test version X
> before you released it? Now I have to roll back the installation until
> you fix this bug."

My claim (such as it was) was that productivity (even
with the "seems to work" target) could be improved--not
that the programmers who accept "seems to work" would
eager or even willing to embrace such a change. Those
that did embrace the change would (I am guessing) find
that development (which includes maintenance and
enhancement) is less frustrating and faster.

It is quite possible that conversion tools could be
made to translate source code (similar to "software
rejuvenation" except that a mode might be provided to
allow guesses as to the original intent of the code so
that ambiguous cases could be handled automatically,
which those targeting "seems to work" might prefer).

The cost of "upgrading" *programmers* would be
substantial, but even with that cost (including lost
opportunity costs) I suspect a net gain in
"productivity" would be possible. ("Unfortunately",
at least some of these "upgraded" programmers would be
infected with clearer thinking and a desire for
excellence, and so would rebel against the "seems to
work" target

> You might not know that early versions of C, favored by such users, gave
> fast compilation by assuming that the source code inputs were correct
> and doing no diagnosis at all. This approach persists to this day, in C
> programmers if no longer in C compilers.

Compile-time errors are annoying (and presumably less
development-friendly than edit-time error checking).
Edit-time error checking could highlight the error
when the programmer is presumably closer to the context
of the error (Yes, some "errors" would be more like
enhancement requests--some of which errors might be
downgraded by producing a dummy function or so the code
becomes valid [requiring warnings/errors for such
dummy functions just as some languages have warnings/
errors for using "obsolete"/"deprecated" interfaces].).
Such error reporting might be through highlighting so
that bursts of coding could be accommodated, and many
errors could be automatically corrected or provide a
quick "Did you mean X?" (or "X, Y, Z, or something
else?").

(With a well-designed language, it should be possible
to do much better than the spell-checking and grammar
checking of existing word processors do for English
not only in discovering errors but in correctly
recognizing the intended/correct expression.)

(It does seem, however, that even the English
spelling/grammar checking could be much better both in
sophistication of analysis and in the interface [e.g.,
autocorrecting based on probability--"micorarchitecture"
is almost certainly meant to be "microarchitecture" but
"arche tecture" _might_ have a significant possibility
of meaning "arch texture" though personal and document
context could usually refine the probabilities--,
providing a faster means of examining and applying
alternative text, and providing quick and simple access
to short--but easily expandable--definitions and usage
information.)

This seems to be consistent with the agile programming
philosophy of fail fast.

With relatively abundant memory and processing power,
providing a sophisticated development environment
should be more practical in 2013 than it was in the
1970s or 1980s (or even the late 1990s).

> Of course, it is possible to go too far in the other direction. Like
> many compilers, the Univac 1108 Fortran compiler would count diagnostics
> and break off after some number (assuming that it was irrecoverably
> lost) and put out a final diagnostic "Not all errors were reported". We
> had a program for which the *only* diagnostic was "Not all errors were
> reported".

"Compiler stopped from running in circles waving its
arms and screaming." might have been a "better"
message than the sole diagnostic of "Not all errors
were reported" (though such a humorous message might
make some programmers feel laughed at rather than
laughed/cried with).

[nm...@cam.ac.uk]

In article <b3a4f007-0745-469a...@q9g2000yqd.googlegroups.com>,

Paul A. Clayton <paaron...@gmail.com> wrote:
>On Apr 28, 5:36 pm, Ivan Godard <i...@ootbcomp.com> wrote:
>>
>>> Hmm. It seems that _some_ aspects of "development
>>> environments designed to" *promote* "correctness"
>>> would improve productivity even if 'seems to work' is
>>> considered good enough.
>

>> You, sir, are an optimist.
>
>Perhaps an optimist with respect to what is _possible_;
>I am more pessimistic (i.e., more realistic--sigh)

>about what is likely to happen ...

You are perfectly correct on the first grounds, and I agree
on the second.

I teach in one of my courses that better software engineering (at
the workshop procedure level) will often slow down development
to first complete build, but speed up the time to the first even
plausibly correct run.


Regards,
Nick Maclaren.

[Tom Gardner]

Paul A. Clayton wrote:
> This seems to be consistent with the agile programming
> philosophy of fail fast.

One of the real problems with the agile movement is that
the developers and management tend to believe that if
the code passes the unit tests then the code works. The
more clueful realise that's incorrect, but suppress their
misgivings because everybody else is happy, and rocking
the boat is a career-limiting move.

As for the quality and completeness of the tests? Don't
ask! I've seen code coverage tests without a pass/fail
condition, i.e. the code was executed but nobody cared
what it did! Guess what metrics were applied to the
project.

Amazing, but I've seen it several times.

[MitchAlsup]

On Monday, April 29, 2013 9:55:18 AM UTC-5, Paul A. Clayton wrote:
> Edit-time error checking could highlight the error
> when the programmer is presumably closer to the context
> of the error

How are you going to get edit time error detection into vi? or
perhaps vim?

Mitch

[Paul A. Clayton]

Doesn't vim already have _syntax_ awareness support for
some languages? Adding higher level grammar and vocabulary
support might not be unthinkably difficult (I am guessing).

Edit-time error checking would require a more "bloated"
development environment, but "Eight[y] Megs" would no
longer be "And Constantly Swapping". (By the way, to the
extent that I have used text editors, I have preferred vim
over emacs. I also have a philosophical disagreement with
the concept of IDEs locking the programmer into a
specific editor/interface.)

Such would also be an additional burden for the language
tool development team.

Using a more sophisticated editor might not be much more
unreasonable an expectation than using a more sophisticated
source control system than manually creating and populating
directories.

I am just a technophile, but it _seems_ reasonable to _me_
to trade off complexity in the construction of development
tools for catching programming errors (just as spell checking
is now universal in word processors and limited grammar
checking is often available).

[nm...@cam.ac.uk]

In article <ddccd8c9-b38c-4ead...@j4g2000yqc.googlegroups.com>,

Paul A. Clayton <paaron...@gmail.com> wrote:

>On Apr 29, 12:36=A0pm, MitchAlsup <MitchAl...@aol.com> wrote:
>> On Monday, April 29, 2013 9:55:18 AM UTC-5, Paul A. Clayton wrote:
>> >
>> > Edit-time error checking could highlight the error
>> > when the programmer is presumably closer to the context
>> > of the error
>>
>> How are you going to get edit time error detection into vi? or
>> perhaps vim?
>

>Doesn't vim already have _syntax_ awareness support for
>some languages? Adding higher level grammar and vocabulary
>support might not be unthinkably difficult (I am guessing).

For a civilised language like Fortran, no. For C++, or even the
C preprocessor, don't even think of it - the compilers that do
that get it wrong.

In any case, it's useless. Who spends most of their time on
syntax errors (even in C++?) Beginners on their first course,
and execusuits pretending to be technically competent, that's who.
A classic error mode is someone matching brackets or similar in
such an editor, and producing complete nonsense that looks right;
you want compiler assistance to work against flaws of human
nature, not enhance them.


Regards,
Nick Maclaren.

[Dr. Bandwidth]

On Sunday, April 28, 2013 4:04:24 PM UTC-5, Paul A. Clayton wrote:
> Hmm. It seems that _some_ aspects of "development
> environments designed to" *promote* "correctness"
> would improve productivity even if 'seems to work' is
> considered good enough.

Perhaps slightly sideways from the topic, but one of the boldest approaches to correctness was taken by John Holt in the development of the Turing programming language. A primary design criterion was that there would be no cases for which the language definition would declare the behavior to be undefined. Either the code is valid, producing a result consistent with the language definition, or the code is invalid, in which case either the compiler or run-time system were required to identify the errant code.

Obviously this does not help the computer magically understand what I want it to do, but I suspect I am not alone in having paid a high cost in "productivity" due to being allowed to compile and run code with undetected constructs having "undefined behavior".

[Ivan Godard]

You wouldn't be Canadian, would you?

[Stephen Fuld]

While I am not Canadian (the group that developed Turing are), I too
appreciate the language and its design principles. Besides the
"air-tight" syntax, a goal was to make the basics simple enough to be a
first language taught, replacing what was then BASIC, and to adhere to
the principle of least surprise.

I have several times stated here in the past that Turnig would be among
my first choices for a language to replace C. It is easy to learn, fun
to use, and in its Turing+ extensions mode capable enough to write a
full OS in (the group did that). Even where things like type cheats are
required, they are allowed, but with a syntax that essentially says "I
am cheating here. Be Careful!). Overall a well done system.

Unfortunately, Turing is no longer being used as the intro programming
language, and is no longer being supported, but the last version is
available for free.


http://compsci.ca/holtsoft/

Also, the book on the development of the language gives a good idea of
their goals and the process of development and the changes as they went
along. While it is long out of print, it is a good read.



--
- Stephen Fuld
(e-mail address disguised to prevent spam)

[MitchAlsup]

On Monday, April 29, 2013 12:44:38 PM UTC-5, nm...@cam.ac.uk wrote:
> In any case, it's useless. Who spends most of their time on
> syntax errors (even in C++?) Beginners on their first course,
> and execusuits pretending to be technically competent, that's who.

There are also some of us who have not made more than 1 pointer error
per year over the last decade, either. Yet, there is endless debate on
how much freedom to allow a programmer using pointers through the
language(s).

Mitch

[nm...@cam.ac.uk]

In article <f2922964-2624-42b3...@googlegroups.com>,

MitchAlsup <Mitch...@aol.com> wrote:
>
>> In any case, it's useless. Who spends most of their time on
>> syntax errors (even in C++?) Beginners on their first course,
>> and execusuits pretending to be technically competent, that's who.
>
>There are also some of us who have not made more than 1 pointer error
>per year over the last decade, either. Yet, there is endless debate on
>how much freedom to allow a programmer using pointers through the
>language(s).

Many people don't use them or use them only in simple ways, or
VERY occasionally write almost error-free code. But there are
lots of experienced users (including me) who make quite a few
pointer errors when writing code that uses them extensively in
non-trivial ways.

What I was saying is that NO experienced and competent user spends
much time removing syntax errors, not even in C++.


Regards,
Nick Maclaren.

[Terje Mathisen]

nm...@cam.ac.uk wrote:
> In article <f2922964-2624-42b3...@googlegroups.com>,
> MitchAlsup <Mitch...@aol.com> wrote:
>>
>>> In any case, it's useless. Who spends most of their time on
>>> syntax errors (even in C++?) Beginners on their first course,
>>> and execusuits pretending to be technically competent, that's who.
>>
>> There are also some of us who have not made more than 1 pointer error
>> per year over the last decade, either. Yet, there is endless debate on
>> how much freedom to allow a programmer using pointers through the
>> language(s).

I can't remember the last time I made a classic pointer error
...
Yes I can: I got a race condition when rewriting a single-thread program
to be multi-threaded and tried to access an object that had been freed.

I don't know if this is a typical pointer error though?

>
> Many people don't use them or use them only in simple ways, or
> VERY occasionally write almost error-free code. But there are
> lots of experienced users (including me) who make quite a few
> pointer errors when writing code that uses them extensively in
> non-trivial ways.
>
> What I was saying is that NO experienced and competent user spends
> much time removing syntax errors, not even in C++.

I agree.

Syntax errors are quite rare and go away after the first compilation
attempt. As long as the compiler warn me about "if (x = 1) ..." I'm
quite happy. :-)

Subtle bugs otoh are more or less forever...

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

[nm...@cam.ac.uk]

In article <3bp45a-...@ntp-sure.tmsw.no>,

Terje Mathisen <"terje.mathisen at tmsw.no"> wrote:
>
>I can't remember the last time I made a classic pointer error
>...
>Yes I can: I got a race condition when rewriting a single-thread program
>to be multi-threaded and tried to access an object that had been freed.
>
>I don't know if this is a typical pointer error though?

Yes, it is one of the all-time greats, of the subclass that gets
through most simple testing and is picked up because of occasional
failures in use.

>> What I was saying is that NO experienced and competent user spends
>> much time removing syntax errors, not even in C++.
>
>I agree.
>
>Syntax errors are quite rare and go away after the first compilation
>attempt. As long as the compiler warn me about "if (x = 1) ..." I'm
>quite happy. :-)
>
>Subtle bugs otoh are more or less forever...

Yes. Architectures and languages could help with a lot more than they
do, but could not eliminate them while leaving the language Turing-
complete.


Regards,
Nick Maclaren.