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

[Richard O'Keefe]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20190311/aa8b2685/attachment.html>