On Thu, Mar 22, 2012 at 9:17 AM, Chris Angelico <ros...@gmail.com> wrote: > On Thu, Mar 22, 2012 at 11:47 PM, Nathan Rice > <nathan.alexander.r...@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 -- http://mail.python.org/mailman/listinfo/python-list
