Re: Securing type extensions

[Georg Bauhaus <rm-host.bauhaus@maps.futureapps.de>]

On 9/16/10 2:45 PM, Dmitry A. Kazakov wrote:

>> Party X made a library, L, of O-O types, abstract or not.
>> Party Y extends a type in L, say T
>>
>> I'm talking about how X and Y can trust each other before
>> X licenses the library and before Y writes an extension.
>
> They need not.

OK, each party to a legal contract may chose to not care
about the consequences of joining untrusted partners in software.
I trust they do care.  This is why there is software evaluation.

>> What technical factors of a language's type extension mechanism
>> will likely make X and Y be more confident that nothing will
>> go wrong?
>
> None, not needed, impossible anyway.

Why does public key cryptography create confidence when the
encryption might fail to protect in some time/case/whatever,
since it can impossibly be known to be secure, i.e. may go wrong?

Yet you enumerate reassuring language facilities of Ada,
noting that static analysis frees you from all concerns? Do I
understand correctly?
If one approaches program semantics from the world outside
the sacred halls of formal illusion, there is a lot between
"program's semantics cannot be known" and "program  will
basically function as intended".
This is where lawyers, sales people, engineers, support
staff, and customers spend a lot of their time.  They give
effective meaning to the sentences. This is where trust
is generated.


> If only signatures could make programs working...

The purpose of signatures put under a software contract
is to express something related to trust and mistrust.
Typically, there is a sentence like "we cannot be held
responsible for ... the usual stuff you have in software.
But otherwise, ...".

>> When you pay, or don't pay, this is easily measured.
>
> Measured what? Do you trust Microsoft?

Programmers trust Microsoft's Visual Studio to basically function
as they would expect, and to help them achieve their programming
goals. Less so the moment some IDE's reputation is ruined because
of poor quality, maybe.  The makers go out of business.


>> Psychology, politics, ambition and money are undoubtably parts of
>> SW engineering, steering the decisions. They are essential to
>> engineering in general.
>
> As a framework they are. That does not make them engineering.

Of course, if you define engineering to be tautologically not anything
but some idealized clean room acting by the book, a standard to strive for,
then whatever makes real engineers' hands move cannot have an influence on
their produce.  Do you mean the immaculate ideal of engineering, and not
the engineering we have, perhaps?

Georg