Number of languages known [was Re: Python is readable] - somewhat OT

[Nathan Rice]

On Thu, Mar 29, 2012 at 7:37 PM, Devin Jeanpierre
<jeanpierreda at gmail.com> wrote:
> On Thu, Mar 29, 2012 at 3:50 PM, Nathan Rice
> <nathan.alexander.rice at gmail.com> wrote:
>> Well, a lisp-like language.  I would also argue that if you are using
>> macros to do anything, the thing you are trying to do should classify
>> as "not natural in lisp" :)
>
> You would run into disagreement. Some people feel that the lisp
> philosophy is precisely that of extending the language to do anything
> you want, in the most natural way.

That is some people's lisp philosophy, though I wouldn't say that is a
universal.  Just like I might say my take on python's philosophy is
"keep it simple, stupid" but others could disagree.

> At least, I disagree, but my lisp thoughts are the result of
> indoctrination of the Racket crowd. I don't know how well they
> represent the larger lisp community. But you should definitely take
> what I say from the viewpoint of the sort of person that believes that
> the whole purpose of lisps is to embed new syntax and new DSLs via
> macros. Without macros, there's no point of having this despicable
> syntax (barring maybe pedagogy and other minor issues).

Heh, I think you can have a homoiconic language without nasty syntax,
but I won't get into that right now.

>> I'm really thinking here more in terms of a general graph reactive
>> system here, matching patterns in an input graph and modifying the
>> graph in response.  There are a lot of systems that can be modeled as
>> a graph that don't admit a nested list (tree) description.  By having
>> references to outside the nesting structure you've just admitted that
>> you need a graph rather than a list, so why not be honest about it and
>> work in that context from the get-go.
>
> I don't see any issue in defining a library for working with graphs.
> If it's useful enough, it could be added to the standard library.
> There's nothing all that weird about it.

Graphs are the more general and expressive data structure, I think if
anything you should special case the less general form.

> Also, most representations of graphs are precisely via a tree-like
> non-recursive structure. For example, as a matrix, or adjacency list,
> etc. We think of them as deep structures, but implement them as flat,
> shallow structures. Specialized syntax (e.g. from macros) can
> definitely bridge the gap and let you manipulate them in the obvious
> way, while admitting the usual implementation.

We do a lot of things because they are efficient.  That is why
gaussian distributions are everywhere in statistics, people
approximate nonlinear functions with sums of kernels, etc.  It
shouldn't be the end goal though, unless it really is the most
expressive way of dealing with things.  My personal opinion is that
graphs are more expressive, and I think it would be a good idea to
move towards modeling knowledge and systems with graphical structures.

>> I don't think they have to be.  You can view functions as names for
>> temporally ordered sequence of declarative implication statements.
>> Databases just leave out the logic (this is hyperbole, I know), so you
>> have to do it in client code.  I don't feel that a database
>> necessarily has to be a separate entity, that is just an artifact of
>> the localized, specialized view of computation.  As stronger
>> abstractions are developed and concurrent, distributed computation is
>> rigorously systematized, I think we'll go full circle.
>
> Maybe I'm too tired, but this went straight over my head, sorry.
> Perhaps you could be a bit more explicit about what you mean by the
> implications/logic?

Well,  the curry howard correspondance says that every function can be
seen as a named implication of outputs given inputs, with the code for
that function being a representation of its proof.  Since pretty much
every function is a composition of many smaller functions, this holds
down to the lowest level.  Even imperative statements can be viewed as
functions in this light, if you assume discrete time, and view every
function or statement as taking the state of the world at T as an
implicit input and  returning as an implicit output the state of the
world at T+1.  Thus, every function (and indeed pretty much all code)
can be viewed as a named collection of implication statements in a
particular context :)