[Haskell-cafe] [OT] thoughts about OO vs. functional "philosophy"
raoknz at gmail.com
Mon Mar 11 02:23:05 UTC 2019
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
> Then this thought occurred to me, which is nifty but maybe not the whole
> 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.
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe