[Haskell-cafe] [OT] thoughts about OO vs. functional "philosophy"

[Ramnath R Iyer]

To give credit where due, I finally recalled where I had come across that
particular reference to encapsulation. Chapter 1.3,
https://github.com/hmemcpy/milewski-ctfp-pdf.

On Sun, Mar 10, 2019 at 19:40 Dennis Raddle <dennis.raddle at gmail.com> wrote:

> Indeed, Python does not enforce encapsulation. It has weakly enforced
> types as well (duck typing for most objects). But it's still an opportunity
> to follow an "encapsulation" convention and explain the purpose, while
> telling my student he won't see the full OO implementation until he gets
> into Java or C++.
>
> I want to comment on Ramnath's point that encapsulation helps us hold
> fewer things in our minds. I would agree that's part of it, but in a
> general sense programming always involves more than we can hold in our
> minds and never requires us to hold all of it at once.
>
> Consider a mathematical proof that runs to 300 pages. We don't need to
> hold the whole thing in our minds to create and understand it--but it's
> still worth finding a way to simplify it so it takes fewer pages or less
> advanced math.
>
> Although we rarely prove a program's correctness in a strict sense, we
> probably give some thought to a rough justification of the correctness of
> our design choices, even if such a justification requires more thoughts
> than we can hold at once. There is a benefit in encapsulating so that the
> justification requires fewer thoughts -- say 20 thoughts instead of 200
> thoughts.
>
> Now, I'm not sure this is any closer to the heart of the matter. Maybe
> Ramnath is more essentially correct. Comments welcome.
>
> D
>
>
>
> On Sun, Mar 10, 2019 at 7:23 PM Richard O'Keefe <raoknz at gmail.com> wrote:
>
>> Serious question: does Python _have_ encapsulation?
>> I know about the single-underscore convention and
>> the double-underscore convention, but even double-
>> underscore attributes and methods can be accessed
>> freely from the outside if you use the class-name
>> prefix.  That is, it makes it difficult to breach
>> encapsulation by accident, but it doesn't take the
>> Lock-Picking Lawyer from YouTube to breach
>> encapsulation on purpose without breaking stride.
>>
>> On Mon, 11 Mar 2019 at 09:29, Dennis Raddle <dennis.raddle at gmail.com>
>> wrote:
>>
>>> I have a thought about OO vs. functional programming .
>>>
>>> I'm moderately experienced with functional languages such as Haskell and
>>> Purescript and have used OO for many years at work (Python, C++).
>>>
>>> I'm giving tutoring lessons in Python to a professional who wants to use
>>> programming as part of his work. (He's an entrepreneur.) He is eager to
>>> understand functional and OO styles within Python--he keeps asking about
>>> the real benefit of each, not content with a superficial approach.
>>>
>>> I've explained about "encapsulation": gathering related functions
>>> together and minimizing coupling to the rest of the program.
>>>
>>> He asks "why do we encapsulate?" I've explained that one reason is to
>>> help we, the programmers, be confident that our code is correct.
>>>
>>> For example, in a class we try to isolate the implementation details
>>> from the rest of the program, and the compiler helps enforce that.So when
>>> we're writing our code and confirming to ourselves it's correct, we can
>>> make simplifying assumptions. We know the rest of the program won't modify
>>> our private variables and won't access us in any way other than the
>>> interface we've presented to the world.
>>>
>>> I explained that a large program is like a corporation, and pieces of
>>> the program are like individual employees. When we write a class or
>>> function, in a sense we "become" that employee and "forget about" a lot of
>>> the details of other employees. (i.e., encapsulation).
>>>
>>> Then has asked why functional programming is helpful. I explained about
>>> referential transparency. Say we're a function: then other "employees"
>>> (other functions) can trust us with simplifying assumptions, like no
>>> side-effects.
>>>
>>> Then this thought occurred to me, which is nifty but maybe not the whole
>>> story.
>>>
>>>
>>> """
>>> Say we're a class. Then the simplifying assumptions of OO allow *us* to
>>> trust the *rest of the program* won't mess with us.
>>>
>>> Say we're a function. Then the simplifying assumptions of functional
>>> style help the *rest of the program* trust that *we* won't mess with it.
>>> """
>>>
>>> D
>>>
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> To (un)subscribe, modify options or view archives go to:
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>> Only members subscribed via the mailman list are allowed to post.
>>
>> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.

-- 
Ramnath R Iyer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20190311/326f3966/attachment.html>