Python is readable

[Nathan Rice]

>> If I'm reading you correctly, you're expressing frustration with the
>> state of language syntax unification in 2012.  You mention language in a
>> broad sense (not just programming languages, but also English, math,
>> logic, etc.), but even in the narrow context of programming languages,
>> the current state of the world is pretty chaotic.
>
> And this is a good thing. Programming languages are chaotic because the
> universe of programming problems is chaotic, and the strategies available
> to solve those problems are many and varied.
>
> Different programming languages are good for different things because
> they have been designed to work in different problem/solution spaces.
> Although I dislike C with a passion, I do recognise that it is good for
> when the programmer needs fine control over the smallest details. It is,
> after all, a high-level assembler. Likewise for Forth, which lets you
> modify the compiler and language as you go.

There is a concept in statistical/mathematical modeling called minimum
message length (a close analog is minimum description length), which
asserts that the optimum model for some set of information is the one
that minimizes the sum of the length of the model and the length of
the set described by that model.  Clearly no model is going to be
optimal for every set of information.  What I was alluding to in the
post that Steve Howell replied to was that we need to have a
programming language that is a model of models, then include a second
order model as part of the program.  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.

> Some languages are optimized for the compiler, some for the writer, and
> some for the reader. So are optimized for numeric work, others for
> database access. Some are Jack-Of-All-Trades. Each language encourages
> its own idioms and ways of thinking about programming.

The difference between compiler optimized and writer optimized
languages is how many assertions they require about the thing being
modeled to be a "valid" program, given its deductive rules.  Ideally,
the number of assertions should be flexible, and the
interpreter/compiler should try and figure out the best way to
implement it given the information it has.

> When it comes to programming, I say, let a thousand voices shout out.
> Instead of imagining a single language so wonderful that every other
> language is overshadowed and forgotten, imagine that the single language
> is the next Java, or C, or even for that matter Python, but whatever it
> is, it's not ideal for the problems you care about, or the way you think
> about them. Not so attractive now, is it?

I agree about letting a thousand voices shout out, in the context of
an embedding language that guarantees code interoperability.
Additionally, the size of optimal DSLs for different areas is actually
quite small, yet having separate languages for each DSL requires the
user to re-learn common patterns such as collection manipulation, IO,
etc.  Pretty horrible all around.

>> The optimistic view is that there will be some kind of inflection point
>> around 2020 or so.  I could imagine a perfect storm of good things
>> happening, like convergence on a single browser platform,
>
> You call that a perfect storm of good things. I call that sort of
> intellectual and software monoculture a nightmare.

The cores of English and math are pretty much singularly represented.
At more nuanced or abstract levels, there is divergence in order to
simplify the process of describing complicated things.  How would you
like it if linear algebra or algebraic geometry re-invented addition,
multiplication, etc with completely different syntax and semantics
(I'm ignoring non-commutativity of vector space multiplication)

> I want a dozen browsers, not one of which is so common that web designers
> can design for it and ignore the rest, not one browser so common that
> nobody dares try anything new.

How about one browser that is infinitely configurable?  That way if
someone tries something new, you can try it as well without precluding
anything else you already do.

The CLI/JVM provide some flexibility, but they are not the correct
path.  They model the executable machine representations of language,
rather than modeling the meta structure of language.  This means that
you still lack flexibility and dynamism.  At least things are moving
in the right direction.