<div dir="ltr"><div dir="ltr">Dennis,<div><br></div><div>I suspect there are a few tangentially related ideas that are getting clubbed together in your explanation, but the analogies are a nice way to go.<div><br></div><div>1. Why do we encapsulate (aka "abstract")? This is a matter of convenience, as humans - we have a need to group things together into categories and patterns so that we have fewer things we can hold in our minds. See <a href="http://psychclassics.yorku.ca/Miller/" target="_blank">http://psychclassics.yorku.ca/Miller/</a>.</div></div><div><br></div><div>2. How do we encapsulate? Like any problem, there are several different solutions that offer different degrees of correctness (with some tradeoffs). OO and functional are two kinds of solutions; they are not mutually exclusive in the real world (example, combinations of these, modules, packages, micro-services et cetera - we usually try take multiple approaches to solve this problem).</div><div><br></div><div>3. What are the 'degrees of correctness' mentioned above? What are the tradeoffs? The basic problem is that of leaky abstractions - we try to categorize complicated reality into categories or patterns, but often the details that we want to hide end up becoming important enough that they can't stay hidden in practice. OO and functional take different approaches to abstraction; OO relies on categorization based on 'what things are' (aka objects) whereas functional relies on categorization based on 'what actions can be done' (aka functions). Obviously, there is nothing inherently natural or unnatural about either, but objects do naturally encapsulate state (memory of past actions) and when coded inappropriately can lead to 'hidden mutable state'. When state is hidden and can change silently (think multi-threaded, multi-process, multiple micro-services), the behavior of the program depends very much on details that we want to have kept hidden. OO is closer to the 'real world'; the benefit is arguably a lower barrier to entry for being productive, and a greater opportunity for creating leaky abstractions. What makes functional different? Well, the programming idioms encourage not permitting hidden mutable state. In certain languages, this is enforced by the language compiler. The primary benefit of functional here is in limiting the programmer's ability to create leaky abstractions. The tradeoffs w.r.t. composition are probably worthy of a more thorough explanation by itself on how functions compose and locks don't etc.</div><div><br></div><div>4. What about coupling? Coupling is about how one component's program code varies with another. You could achieve a good tradeoff with the points above and still end up with tightly coupled code. What this means is that when you need to achieve some practical change relevant to the purpose of the software (ex: a new feature), you end up having to change many different parts of the software. The changes are not reasonably isolated such that you can minimize the cost of the change or the amount of the 'stuff' the person making the change needs to understand (or learn) in order to be successful. We reduce coupling by making the commonly required changes easy.</div><div><br></div><div>-- </div><div>RRI</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Mar 10, 2019 at 1:29 PM Dennis Raddle <<a href="mailto:dennis.raddle@gmail.com">dennis.raddle@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>I have a thought about OO vs. functional programming .<br></div><div><br></div><div>I'm moderately experienced with functional languages such as Haskell and Purescript and have used OO for many years at work (Python, C++).</div><div><br></div><div>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.<br></div><div><br></div><div>I've explained about "encapsulation": gathering related functions together and minimizing coupling to the rest of the program. <br></div><div><br></div><div>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. <br></div><div><br></div><div>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.</div><div><br></div><div>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). <br></div><div><br></div><div>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.</div><div><br></div><div>Then this thought occurred to me, which is nifty but maybe not the whole story.</div><div><br></div><div><br></div><div>"""<br></div><div>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.</div><div><br></div><div>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.<br></div><div>"""</div><div><br></div><div>D<br></div><div><br></div></div>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
Only members subscribed via the mailman list are allowed to post.</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Ramnath R Iyer</div></div></div>