Python is readable

Nathan Rice nathan.alexander.rice at gmail.com
Thu Mar 22 14:26:51 EDT 2012


>> 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.
>
> (1) Optimum in what sense?

Oh, I don't know, the information theoretic one?  Of course, if you're
part of the department of redundancy department, that might seem to
appear to look like a poor, weak, sub-optimal criterion for the
purposes of evaluation of optimality, goodness and positive quality.

If you're getting hung up on the fact that there are deep ties to data
compression in this language, let me help you out.  Imagine that
instead of having a simple Boolean algebra of two values, the possible
values ranged over a set of elementary concepts.  You are then trying
to come up with a set of compound concepts and a permutation of those
concepts that can describe

> (2) What does this have to do with designing programming languages?

A program is a representation of knowledge (i.e. a model) which a
machine has the ability to interpret.  Let me know if you can't
understand this, I'll break it down further for you.

> This discussion sounds to me like the apocryphal story about the
> spherical cow.
>
> http://en.wikipedia.org/wiki/Spherical_cow

When you take the baton, you're supposed to keep running along the
path in the same direction as the person who handed it to you.

>> 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.
>
> Some people, when confronted with a problem, think "I know, I'll use a
> DSL." Now they have two problems.

Sure.  When confronted with the problem of finding the area under a
curve, using integral calculus is going to make things worse...  I
should just manually sum the infantesimals, from now until the end of
time.

> And some people think "I know, I'll use a meta-language with an infinite
> number of infinitely variable DSLs." Now they have an infinite number of
> problems.

I'll agree with you, if we change that statement to say "an infinite
number of possible problems, all isomorphic to each other."

>> A language designed in such a way would also prevent issues
>> like the Python 2 -> 3 fiasco,
>
> What fiasco?

The extremely slow uptake?  I don't really care one way or another but
a lot of the devs have lamented the issue.

> You've just lost an awful lot of credibility with me.

I didn't lose anything, technically you lost some of your belief in my
credibility.

So, tautologically, you are the one that lost in this situation.

> I'm just surprised you didn't manage to fit quantum mechanics and "the
> interconnectedness of all things" into it :)

Math/Logic are encompassing.  I could draw analogies to quantum theory
if you really wanted (category theory is great for this sort of
thing).  As for the interconnectedness of all things, that is quack
language, I do science.

>> 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.
>
> No offence Nathan, but I think you need to come back down to earth for
> air before you black out:
>
> http://www.joelonsoftware.com/articles/fog0000000018.html

I read that article a long time ago, it was bullshit then, it is
bullshit now.  The only thing he gets right is that the Shannon
information of a uniquely specified program is proportional to the
code that would be required to generate it.  Never mind that if a
program meets a specification, you shouldn't care about any of the
values used for unspecified parts of the program.  If you care about
the values, they should be specified.  So, if Joel had said that the
program was uniquely specified, or that none of the things that
weren't specified require values in the programming language, he might
have been kinda, sorta right.  Of course, nobody cares enough to
specify every last bit of minutiae in a program, and specifications
change, so it is pretty much impossible to imagine either case ever
actually occurring.

> Or at least before *I* black out. Even if somebody manages to write your
> meta-language, you're going to run into the problem of who is going to be
> able to use it. The typical developer knows three, maybe four languages
> moderately well, if you include SQL and regexes as languages, and might
> have a nodding acquaintance with one or two more.

Please don't black out Steven.  I'm trying to encourage thought in
interesting directions; you can't think when you're unconscious.

Lets draw the analogy to mathematicians.  If a mathematician wants to
solve a problem, he can cruise along at a pretty good clip as long as
he understands the theories of the problem domain.  If he runs into a
portion of the problem domain that requires theories he isn't familiar
with, he must trot off to the library for a book, or read some journal
articles.  Once he's absorbed the theory, he can continue to work on
solving the problem, and if he encounters other problems that require
the theory, he is set.

I can give you another analogy that is even clearer... What happens if
there are several words in a paragraph you don't know?  You go to the
dictionary to look them up, you now know the words, they are part of
your vocabulary, and life is good.

Finally, what about when you want to use a library in a programming
language you already know?  That is a domain specific language that
just so happens to have the syntax and semantics of the base language
as a subset of its own syntax and semantics.

Part of the problem here, I think, is that you imagine each DSL to
have radically different syntax and semantics.  That is unnecessary,
and actually contrary to what I am proposing.

> With the radical changes you're suggesting, developers would need to be
> able to deal with some arbitrary number of different DSLs, and whatever
> meta-language is used to glue them together.

They already do that (replace DSL with library here, again).  The
problem is that the meta-language lacks expressiveness and flexibility
because it is modeling the permutation rather than the permutation
generator.

> There are a huge number of incompatible programming languages because
> language designers have different requirements, preferences, and styles;
> and because the state of the art of language design is very different in
> 2012 than it was in 1962.

Every language goes to 1s and 0s in the end.  Clearly 1s and 0s are
capable of closing the space of requirements, preferences and styles.
This is the case because programs are information (i.e. encoded
knowledge).  All I'm proposing is an intermediate representation
language that describes the higher order structure and dynamics of
knowledge in a clean, human readable format.  Mathematicians realized
this was a good idea and started down this path something like 140
years ago (minus the human readable ;).   They aren't done yet, so
clearly any meta language someone develops would similarly be a work
in progress, but the nice thing is that backwards compatibility would
never be broken; as deeper theorems are exposed, previous results can
be recast as specific cases of them.



More information about the Python-list mailing list