Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #44991 > unrolled thread

Re: Message passing syntax for objects | OOPv2

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Message passing syntax for objects | OOPv2 Mark Janssen <dreamingforward@gmail.com> - 2013-05-08 19:35 -0700
    Re: Message passing syntax for objects | OOPv2 rusi <rustompmody@gmail.com> - 2013-05-08 20:26 -0700
      Re: Message passing syntax for objects | OOPv2 Mark Janssen <dreamingforward@gmail.com> - 2013-05-08 20:53 -0700
    Re: Message passing syntax for objects | OOPv2 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-05-09 05:39 +0000
      Alternate computational models can be harmonious (was Message passing syntax for objects | OOPv2) rusi <rustompmody@gmail.com> - 2013-05-09 04:56 -0700
      Re: Message passing syntax for objects | OOPv2 Mark Janssen <dreamingforward@gmail.com> - 2013-05-09 14:41 -0700

#44991 — Re: Message passing syntax for objects | OOPv2

On Fri, Apr 12, 2013 at 11:28 PM, Mark Janssen
<dreamingforward@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

[toc] | [next] | [standalone]

#44998

On May 9, 7:35 am, Mark Janssen <dreamingforw...@gmail.com> wrote:
> On Fri, Apr 12, 2013 at 11:28 PM, Mark Janssen
>
> <dreamingforw...@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

[toc] | [prev] | [next] | [standalone]

#44999

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

Fascinating.
-- 
MarkJ
Tacoma, Washington

[toc] | [prev] | [next] | [standalone]

#45004

On Wed, 08 May 2013 19:35:58 -0700, Mark Janssen wrote:

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

Their computation models are exactly equivalent.

This is like saying that Cartesian coordinates and polar coordinates are 
so radically different that they cannot possibly both describe the same 
space.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#45029 — Alternate computational models can be harmonious (was Message passing syntax for objects | OOPv2)

On May 9, 10:39 am, Steven D'Aprano <steve
+comp.lang.pyt...@pearwood.info> wrote:
> On Wed, 08 May 2013 19:35:58 -0700, Mark Janssen wrote:
> > 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.
>
> Their computation models are exactly equivalent.
>
> This is like saying that Cartesian coordinates and polar coordinates are
> so radically different that they cannot possibly both describe the same
> space.

Spot on Steven -- thanks.

And further we do know that from a pragmatic POV the two can be quite
different.
For example cartesian are easier for add/subtract, whereas polar are
easier for multiply/divide.
And so on occasion the best way of doing an operation is to -- if
necessary -- convert to the more appropriate format.

I feel that the case of alternate computation models is analogous --
for some purposes one model works well and sometimes another.

Python embeds the functional model almost as natively as it does the
imperative/OO model.  This is an aspect of python that is powerful but
can also make it hard for some people. In short, python's multi-
paradigm possibilities could do with some good publicity.

My own attempts at bringing functional thinking to classical
imperative languages and Python in particular, will be up at:
https://moocfellowship.org/submissions/the-dance-of-functional-programming-languaging-with-haskell-and-python

It is also an attempt at bringing the lightness and freedom of Python
to the Haskell community and answer divisive judgements of
computational models/paradigms such as the OP's.

More details at http://blog.languager.org/2013/05/dance-of-functional-programming.html

[toc] | [prev] | [next] | [standalone]

#45056

>>  These models of computation should not use the same language.  Their
>> computation models are too radically different.
>
> Their computation models are exactly equivalent.

No they are not.  While one can find levels of indirection to
translate between one and the other, that doesn't mean they're
equivalent.  It's like saying that because I can make an equivalence
between the complex plane and the real, that they should be treated as
equivalent.  But they shouldn't -- else you run into a domain error.

-- 
MarkJ
Tacoma, Washington

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web