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

[Devin Jeanpierre]

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.

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).

> 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.

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.

> 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?

-- Devin