[Haskell-cafe] [OT] thoughts about OO vs. functional "philosophy"
raoknz at gmail.com
Mon Mar 11 02:28:29 UTC 2019
PS: surely one of the main claims for both OO and FP is
reuse and composition. OO tends to do composition by either
or type-level application (Eiffel, Swift, Java, C++).
not exhaustive lists.
On Mon, 11 Mar 2019 at 15:23, 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>
>> 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