Message passing syntax for objects | OOPv2

[rusi]

On May 9, 7:35 am, Mark Janssen <dreamingforw... at gmail.com> wrote:
> On Fri, Apr 12, 2013 at 11:28 PM, Mark Janssen
>
> <dreamingforw... at gmail.com> wrote:
> >> Mark, this proposal is out of place on a Python list, because it proposes an
> >> object methodology radically different from any that is implemented in
> >> Python now, or is even remotely likely to be implemented in Python in the
> >> future.
>
> > Wow, you guys are a bunch of ninnies.  I'm going to find some
> > theoretical folks....
>
> Okay, to anyone who might be listening, I found the core of the problem.
>
> This issue is/was much deeper than OOP (which would be roughly a 20
> year refactoring) -- that was my mistake.  The issue goes right to the
> core to models of computation and the historical factions within
> theoretical CS itself (a 50+ year refactoring).
>
> The field needs re-invented and re-centered.  Mark my words.  There
> has been a half-century of confusion between two entirely separate
> domains and they've been using the same lexicon.  Long story short:
> the lambda calculus folks have to split from the Turing machine folks.
>  These models of computation should not use the same language.  Their
> computation models are too radically different.  Lisp will remain a
> pinnacle of the lambda calculus, but should be remanded to philosophy.
>  The logic of the binary/boolean arithmetic is simply not compatible,
> but forms the basis of any sensible computer science here in the West.
>
> Here pronouncith the.... whatever
>
> --
> MarkJ
> Tacoma, Washington

"Lisp will remain the pinnacle of lambda calculus" ???  : Surreal
feeling of falling into a 25-year time-warp

Read this http://www.cs.kent.ac.uk/people/staff/dat/miranda/wadler87.pdf

Just for historical context:
When this was written in the 80s:
- The FP languages of the time -- KRC, SASL, Miranda, Orwell -- were
elegant and academic
- Lisp was quasi-industrial-strength but as Wadler argues above, was
not doing good service to functional programming