Path: csiph.com!usenet.pasdenom.info!goblin2!goblin.stu.neva.ru!newsfeed.xs4all.nl!newsfeed5.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <CABicbJ+A5MPV=GyJC__SBtjHkDsTZUYm3Csi=KC6_2CJ49=ncg@mail.gmail.com>
References: <CAPTjJmoEuHcUs5vkTNywfC6ZAwsKdVvs+8os40EJ4Oa1GPaBVw@mail.gmail.com> <B58DAE84-AA61-477A-B835-A62DA2224D8A@gmail.com> <CAPTjJmr3ybJUZFPyTWLysOE3YgWUjFZ8Bx6cjVjvNYVakXzM1Q@mail.gmail.com> <CAOFbRmLFrE_YiNu39xShCHnicoKVFYg8raZAGfHY9pC3HmOxVg@mail.gmail.com> <CAPTjJmqRBB+J=BwBCkSK--BtcNMQHteXwb7qguc6fD=O+-oKNw@mail.gmail.com> <CAOFbRmLuvC0YAn3+zwJL9XM9mVhWMqxnoMVFi9KQSraBTmMDjw@mail.gmail.com> <CABicbJ+A5MPV=GyJC__SBtjHkDsTZUYm3Csi=KC6_2CJ49=ncg@mail.gmail.com>
Date: Thu, 29 Mar 2012 15:50:37 -0400
Subject: Re: Number of languages known [was Re: Python is readable] - somewhat OT
From: Nathan Rice <nathan.alexander.rice@gmail.com>
To: Devin Jeanpierre <jeanpierreda@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: python-list@python.org
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.1133.1333050641.3037.python-list@python.org>
Lines: 68
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:22358

On Thu, Mar 29, 2012 at 2:53 PM, Devin Jeanpierre
<jeanpierreda@gmail.com> wrote:
> Agreed with your entire first chunk 100%. Woohoo! High five. :)

Damn, then I'm not trolling hard enough =E0=B2=A0_=E0=B2=A0

> On Thu, Mar 29, 2012 at 1:48 PM, Nathan Rice
> <nathan.alexander.rice@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.