Evolutionary Programming!

[Idan Arye via Digitalmars-d]

On Tuesday, 5 January 2016 at 16:10:21 UTC, Jason Jeffory wrote:
> 1. Grammar independence - People speak different languages and 
> perceive logic through different symbols. It is the nature of 
> life and knowledge.

I want to focus on that. If multiple developers need to work on 
the same project, having different grammars is not a very good 
idea. Consistency is important - we promote coding standards to 
cover the parts not enforced by the grammar - so mixing the 
different grammars in the same project is a huge no-no. Promoting 
multiple grammars will be a disservice to programmers then, since 
each project will have it's chosen grammar, and number of 
projects each developer is comfortable working on will be 
drastically reduced.

Of course, as already suggested in this thread, AST editors could 
do that translation, and having me use a different grammar than 
you will become as simple as my text editor highlighting keywords 
in different colors than yours. Then again - if this will be the 
case, using different grammars will also be about as meaningful 
as having different color schemes...


However, using different grammars can have a different goal - 
reducing the boundaries between libraries. If everyone use 
different grammars of the same language, you won't have to give 
up on or struggle with a cool library just because it's written 
in a different language than the one you use.

This problem is currently addressed by platforms like Java and 
.NET. Languages on these platforms are compiled into bytecode, 
with an expressive enough format that allows any language on the 
platform to use libraries written in other languages - without 
the need to translate the library's interface to the client 
language.

The main hurdle with these - which I believe your dream language 
will have to face as well when it tries to support multiple 
grammars - is supporting the many language-backed idioms that 
modern languages use to make our code cleaner and safer.

Let's consider, for the Dispose 
Pattern(https://en.wikipedia.org/wiki/Dispose_pattern). The 
syntax in Java and in Python looks quite similar:

     try (BufferedReader reader = new BufferedReader(new 
FileReader(filename))) {
         return reader.readLine();
     }

     with open(filename) as reader:
         print(reader.readline())

So, since Python has a JVM version - Jython - you would expect to 
be able to do this:

     with BufferedReader(FileReader("chapter-tracker.sh")) as 
reader:
         print(reader.readline())

But no - you get an error:

     AttributeError: 'java.io.BufferedReader' object has no 
attribute '__exit__'

So, what happened? While the idioms look similar in Java and 
Python, the semantics behind them are quite different. In Java, 
`try (Foo foo = new Foo())` will simply call `foo.close()` when 
the block is exited. In python, `with Foo() as foo:` will call 
`__enter__()` on `Foo()`'s result, assign it's result to `foo`, 
and when the block exists it call `__exit__(...)` on `Foo()`'s 
result from back than(not on `foo`!)


To solve this, you'd have to define such idioms as part of the 
platform, and thus all the languages(/grammars) could follow 
them. But this comes with it's own price:

  - The list of idioms you'd want to make official can become 
quite large - making the interface between the platform and the 
languages/grammars more complex, and therefore the implementation 
of such languages more complex. This is something 
platform/language designers usually try to avoid.

  - Language/grammar designers will want to add new idioms to 
their languages/grammars, but the process of adding a new idiom 
to the platform will be quite long. This will give 
language/grammar designers to just add their new idiom into their 
own creation, without caring about consistency in the platform's 
ecosystem.

So, like everything else in our profession - this is a matter of 
tradeoffs.