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

[Richard O'Keefe]

PS: surely one of the main claims for both OO and FP is
reuse and composition.  OO tends to do composition by either
object-level application (Smalltalk, Ruby, Javascript, Java)
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>
> 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/a79e266f/attachment-0001.html>