On Thu, Mar 29, 2012 at 2:53 PM, Devin Jeanpierre <jeanpierr...@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.r...@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. -- http://mail.python.org/mailman/listinfo/python-list
