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

[Nathan Rice]

On Thu, Mar 29, 2012 at 2:53 PM, Devin Jeanpierre
<jeanpierreda at gmail.com> wrote:
> Agreed with your entire first chunk 100%. Woohoo! High five. :)

Damn, then I'm not trolling hard enough ಠ_ಠ

> On Thu, Mar 29, 2012 at 1:48 PM, Nathan Rice
> <nathan.alexander.rice at gmail.com> wrote:
>> transformations on lists of data are natural in Lisp, but graph
>> transformations are not, making some things awkward.
>
> Eh, earlier you make some argument towards lisp being a universal
> metalanguage. If it can simulate prolog, it can certainly grow a graph
> manipulation form. You'd just need to code it up as a macro or
> function :p

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" :)

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.

>> Additionally,
>> because Lisp tries to nudge you towards programming in a functional
>> style, it can be un-intuitive to learn.
>
> I think you're thinking of Scheme here. Common Lisp isn't any more
> functional than Python, AFAIK (other than having syntactic heritage
> from the lambda calculus?)
>
> Common-Lisp does very much embrace state as you later describe, Scheme
> much less so (in that it makes mutating operations more obvious and
> more ugly. Many schemes even outlaw some entirely. And quoted lists
> default to immutable (aaaargh)).

I find it interesting that John McCarthy invented both Lisp and the
situation calculus.

As for set/setq, sure, you can play with state, but it is verbose, and
there is no inherent notion of temporal locality.  Your program's
execution order forms a nice lattice when run on hardware, that should
be explicit in software.  If I were to do something crazy like take
the union of two processes that can potentially interact, with an
equivalence relation between some time t1 in the first process and a
time t2 in the second (so that you can derive a single partial order),
the computer should be able to tell if I am going to shoot myself in
the foot, and ideally suggest the correct course of action.

> Well, what sort of language differences make for English vs Mandarin?
> Relational algebraic-style programming is useful, but definitely a
> large language barrier to people that don't know any SQL. I think this
> is reasonable. (It would not matter even if you gave SQL python-like
> syntax, the mode of thinking is different, and for a good reason.)

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.