Code Requires Rigid Context

In the works of the Viewpoints Research Institute is mentioned an interesting idea: call by meaning.
http://www.vpri.org/pdf/tr2014003_callbymeaning.pdf

The idea behind that name is code being dropped into an environment, which it can then probe to find
its dependencies; the basic example given is code to draw a clock dynamically finding a time source.
The paper imagines a program pulling messages from the Internet, with incompatible and ever-changing
representations, and all of this automatically resolved by some system rather than a programmer; the
first examples use a fake human language system; then examples employ Cyc for a true working system.

I'm torn between criticizing the paper and criticizing the idea.  The idea, although interesting, is
one which I believe to be fundamentally unrealizable and further still undesirable.  Firstly, all of
these components need annotation of some sort, part of some language or not; names, according to the
paper, ``don't scale'' because people can't globally agree on names, but supposedly people can agree
globally on concepts and ways to express those concepts, and how laughable.  Secondly, the idea that
all the world should form such a coherent global system is perhaps misguided; the atomic unit of the
Internet is a packet largely without inherent meaning, and so I see not in the Internet a prior art.

Constantly, the paper criticizes techniques that ``don't scale'' and yet perhaps programming needn't
scale globally.  Alan Kay belongs to that set of people who believe children with no training should
be able to program, and I agree, but only to a certain extent.  They seem not to have considered how
a provably correct program could ever be written using the call by meaning idea, borne by ignorance.

It's certainly possible to have a function finder that can examine parameter types and return values
or even use examples to locate compatible functions, but that's leagues away from a full behavioural
search with validation and the like.  Still, regarding correct code, none of this will ever suffice.

I've a different idea on how programs could be built from components, and it requires training.  For
a program to be dropped into a largely unfamiliar environment and yet work, that only solution I see
is for it to carry its dependencies; if it carried a specification of how these dependencies behave,
that's often no better than carrying them wholesale, for anything complex.  Deduplication is one way
an environment can deny this approach its main problem, and dependencies can be totally or partially
compared for equivalency, made easier by explicit domain so that a superset can imitate a subset.  I
regularly write programs which take advantage of the total specifications of functions, and no other
way exists to be certain of two programs meaning the same thing, other than such exhaustive testing.

I imagine a guild with a big set of data structures and, to a far lesser extent algorithms, which it
offers to its members, so that they may avoid wasteful work.  I see no means to have this other than
a list of some sort which may be organized and searched in many ways, but must be known nonetheless.
One method of organization could be to allow for search based on time and space characteristics, and
in this way the programmer could ignore plenty of details, but if I were to want a data structure to
map arrays of some data to some other data, and with linear space and constant time characteristics,
would I see a trie or a hash table; there would need to be clearly search for best, average, and the
worst case characteristics.  Further, whether that stored data would have a known or indefinite size
is another important consideration.  I'm not confident a single good solution exists to the problem,
but I'm confident one solution to incredibly large systems is making them smaller through less code.
If every decent interface be packaged for such reuse, perhaps most programs can then avoid the need.

Rather than making programs which can be maximally ignorant and unspecified, I'm interested with the
idea of making programs more like clocks; I'm no master clockmaker, but I wouldn't expect to be able
to take pieces from a grandfather clock to use inside of a wristwatch, or a building clock.  None of
these physical such considerations affect programs, but I see not why even a small amount of knowhow
oughtn't be needed for making a complex system.  The same people who believe children should be able
to program with little or no knowhow wince at considering letting a child burn himself to know fire.
A clockmaker is expected to know the parts he'll use, but perhaps not every such variant everywhere.

My conclusion is that correct code must know or carry around its definitions and anything else won't
work; deduplication of shared definitions is perhaps as good as it gets; anything else is foolhardy.
.