[erlang-questions] Open Algorithmic Execution (OAE) next logical step after Open Source Software (OSS) ?

[Jay Nelson]

I have been very grateful for Open Source Software (OSS) and things
like github which have transformed the way code is distributed, coding
is learned and ideas in software are propagated. When I started it
required reading an armspan worth of vendor published documents
to write a program. Source code was proprietary and not available
for learning. Everyone muddled through and developed their own
style or a collective style of employee peers.

OSS has made the industry more accessible by exposing code to
any curious eyes. I have accomplished many things which would
have been impossible without reading the source code. But as ROK's
recent post indicates, after the vast survey that OSS allows, it becomes
apparent that the world is awash in a sea of code that does not have
visible characteristics of how it works. One must just "read the code"
in intricate detail to fully understand how it works.

The counter-argument that the traditional approach of private code
in a black box with well-defined interfaces no longer holds water
as the code is put to many different uses, with differing performance
requirements. It is not enough to know an API and that a black box
implementation is correct. The characteristics of the performance
under different environments or scenarios must be measured and
considered. The variety of solutions available through OSS makes
the choice more complicated, although I welcome the ability to
have any choice where previously there was none.

It seems that the next step is what I call Open
Algorithmic Execution (OAE). As ROK states, improvements in
the languages and expression of algorithms are needed because
it shouldn't be a requirement to compile or execute the code to
find out what it does, however, once you decide to run it, there
should be a transparency in execution that is equivalent to the
transparency that OSS provides.

I believe that OSS projects need to be more easily integrated
with other software, but that the algorithmic complexity and
performance should be graphically visible during execution
so that the user / integrator can see the effects of the
algorithm under different conditions and evaluate how that
might impact the whole system. This form of "openness" about
algorithms would enable a greater ability to choose the right
components when assembling a solution. It would also promote
better understanding of how the algorithms perform, and 
support the ability to communicate to non-engineers what
is happening in a system.

The real issue is that algorithm, code and execution should
share a model so that the mental mapping that occurs when
switching from one form to the other is reduced and made
more explicitly comparable.

jay