Python is readable

[Nathan Rice]

On Thu, Mar 22, 2012 at 9:17 AM, Chris Angelico <rosuav at gmail.com> wrote:
> On Thu, Mar 22, 2012 at 11:47 PM, Nathan Rice
> <nathan.alexander.rice at gmail.com> wrote:
>> Having one core language with
>> many DSLs that can interoperate is infinitely better than having many
>> languages that cannot.  A language designed in such a way would also
>> prevent issues like the Python 2 -> 3 fiasco, because two versions of
>> a DSL can be separate, and code can reference them independently while
>> being able to interoperate.
>
> This is either utterly impossible, or already available, depending on
> your point of view.

Of course it is already available.  It is called the laws of physics.
Everything we know of inter-operates in the context of physical
reality perfectly.

> To have an infinitely-configurable program, you must make its
> configuration equivalent to writing code. There is already an
> infinitely-configurable program in Unix: "gcc config.c; ./a.out" takes
> a simple-format text file called "config.c" and processes it.

It is true that infinite configuration requires that the configuration
be specified in the language of the program.  What's the problem?

> You want infinite DSLs? Behold!
>
> $ ./module1 | ./module2 | ./module3 | ./module4
>
> Each one has a shebang that tells you what they are (Python 2, Python
> 3, something else entirely). There's a very strict interoperability
> protocol between the modules - they pass information around through
> stdout and stdin. You can write any module in any language, and you
> can rewrite module1 for Python 3 without affecting any other or the
> invocation sequence.

It has always been possible to get from one point in space to another
point in space in finite time.  Was the invention of the automobile
was redundant and unimportant?  Obviously not, the characteristics of
the process matter.

For example, your ability to reason about the behavior of the system
you posited as a whole is limited.  Are there parts of the different
modules that can execute concurrently?  Is the output of module1
guaranteed to be acceptable as the input for module2?  Is part of
module3 redundant (and thus avoidable) given some conditions in
module1?  If you make a change in module2 what effect does that have
on module3 and module4?  What if you need to go back and forth between
module2 and module3 until some criterion is met before you transition
to module4?  What if you sometimes want to run module2b instead of
module2?

> Problems always come when you want to share data between dissimilar
> modules. There's no single perfect data-transfer protocol that works
> across all languages. What does it mean to "call a function"? If you
> truly want this level of flexibility, the best thing to do is to
> separate sections cleanly. In fact, the pipe system I show above could
> be used that way, although it's stupidly ugly. Everything going on
> stdout/stdin has a two-word dispatch envelope with a from and a to,
> and each module reads a line, and if it's not addressed to it, passes
> it on to stdout. Responses get sent out with their from and to
> reversed. All you need is for the last module's stdout to be linked
> back into the first module's stdin (not sure if you can do that or not
> - it has the feeling of plugging a power strip into itself), and it'll
> work perfectly. Add a bit of boilerplate so that the application
> developers don't see what's happening underneath, and you could
> pretend that dissimilar languages are able to call into each other.
> Doesn't mean it's efficient though!

What is a function?  You could say that it is a sequence of logical
statements that relates some assertion with another.  You can make a
big deal about call by name versus call by value, but it only really
matters on a conceptual level when dealing with infinite objects that
do not have an analytic closure.  You can make a big deal about data
format, but scientists have been communicating using different unit
systems for hundreds of years, I don't see assertions of relationship
between structures as different from unit conversions from imperial to
metric; it's all data.  There are of course a few snags such as
cardinality of the set represented by the integer data type in one
case versus another, but that is a low level detail that would be a
problem if DSLs were embedded in an expressive modelling language.
Data structures ultimately boil down to assertions, assertions about
those assertions and relations between assertions.

> TLDR version: Infinite flexibility means you're doing nothing.

I could address that from a number of ways.  First off, anything that
is Turing complete is basically "infinitely flexible" but the
difference in expressiveness (as measured by the combined length of
the program and its input required to generate some output) varies
over orders of magnitudes.  So, we're actually discussing "infinitely
expressive" though in fact we don't need to appeal to infinity here,
so that is a strawman.  The reason for that is the system in which
concepts are generated (physical reality) is finite on some levels.
Much like a fractal, though there is infinite "detail", it is the
result of the recursive application and composition of a small set of
motifs.  This is why I keep harping on the importance of a meta-model.
 Given a description of the fractal system and starting state, I can
predict the structure of any portion of the fractal at any time with
complete accuracy (assuming it is not a stochastic system, in which
case I can only predict the distribution of states).  If you try to
model a fractal system at a particular point by describing its
geometry you will be busy for a VERY long time, and if I asked you
anything about the state of the fractal at a different time you would
be at a loss. All I'm trying to advocate is that people stop modelling
the geometry of the system at time t and start modelling the dynamics
of the system.  Seems pretty reasonable to me.

TL;DR there are a huge number of incompatible programming languages
because people are modeling a permutation rather than the input to a
permutation generating function.


Nathan