[OT] thoughts about OO vs. functional "philosophy"

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

[OT] thoughts about OO vs. functional "philosophy"

Dennis Raddle
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.
Reply | Threaded
Open this post in threaded view
|

Re: [OT] thoughts about OO vs. functional "philosophy"

Jack Kelly
Dennis Raddle <[hidden email]> writes:

> I have a thought about OO vs. functional programming -snip-
>
> """
> 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.
> """

Interesting. Perhaps this is why it feels like OO scales for a little
bit, but seems to hit diminishing returns? You get _some_ encapsulation,
but "the rest of the program" grows faster than "us/we", and pure FP
gives us guarantees about "the rest of the program", which is a larger
set?

-- Jack
_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: [OT] thoughts about OO vs. functional "philosophy"

Ian Denhardt
Quoting Jack Kelly (2019-03-10 17:20:04)

> > 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.

Worth noting that modules do this for us in Haskell. Encapsulation of
implementation details is something that languages of all stripes give
you in one way or another.
_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: [OT] thoughts about OO vs. functional "philosophy"

Ramnath R Iyer-2
In reply to this post by Dennis Raddle
Dennis,

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.

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 http://psychclassics.yorku.ca/Miller/.

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).

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.

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.

-- 
RRI

On Sun, Mar 10, 2019 at 1:29 PM Dennis Raddle <[hidden email]> 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.


--
Ramnath R Iyer

_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: [OT] thoughts about OO vs. functional "philosophy"

Richard O'Keefe
In reply to this post by Dennis Raddle
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 <[hidden email]> 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.

_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: [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 <[hidden email]> 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 <[hidden email]> 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.

_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: [OT] thoughts about OO vs. functional "philosophy"

Dennis Raddle
In reply to this post by Richard O'Keefe
Indeed, Python does not enforce encapsulation. It has weakly enforced types as well (duck typing for most objects). But it's still an opportunity to follow an "encapsulation" convention and explain the purpose, while telling my student he won't see the full OO implementation until he gets into Java or C++.

I want to comment on Ramnath's point that encapsulation helps us hold fewer things in our minds. I would agree that's part of it, but in a general sense programming always involves more than we can hold in our minds and never requires us to hold all of it at once.

Consider a mathematical proof that runs to 300 pages. We don't need to hold the whole thing in our minds to create and understand it--but it's still worth finding a way to simplify it so it takes fewer pages or less advanced math.

Although we rarely prove a program's correctness in a strict sense, we probably give some thought to a rough justification of the correctness of our design choices, even if such a justification requires more thoughts than we can hold at once. There is a benefit in encapsulating so that the justification requires fewer thoughts -- say 20 thoughts instead of 200 thoughts.

Now, I'm not sure this is any closer to the heart of the matter. Maybe Ramnath is more essentially correct. Comments welcome.
D



On Sun, Mar 10, 2019 at 7:23 PM Richard O'Keefe <[hidden email]> 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 <[hidden email]> 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.

_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: [OT] thoughts about OO vs. functional "philosophy"

Viktor Dukhovni
In reply to this post by Dennis Raddle
On Sun, Mar 10, 2019 at 01:28:18PM -0700, Dennis Raddle wrote:

> 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.
> """

I am curious what readers of this thread make of:

    "Object-Oriented Programming is Bad":

       https://www.youtube.com/watch?v=QM1iUe6IofM

The main thesis appears to be that OO encapsultion makes code harder
to read, and fails to deliver on the benefits of encapsulation of
state when objects interact with other objects.

--
        Viktor.
_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: [OT] thoughts about OO vs. functional "philosophy"

Paul
In reply to this post by Ramnath R Iyer-2
10.03.2019 23:50, Ramnath R Iyer wrote:
> whereas functional relies on categorization based on 'what actions can
> be done' (aka functions)
that's what interfaces are for.

_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: [OT] thoughts about OO vs. functional "philosophy"

Damien Mattei-2
I think functional programming really help simplifying the things: you need to do a complex thing, so you build it with more simple functions that you compose, you make a simple function and reuse it in a more complex one... for each function you have arguments in input and get an object (list, array, int ,string....) in output.

OO programming seems at first glance to provide a way to do this by calling methods of a class that are encapsulated in it, but when using  a method of a class you always have to instantiate an object, you have to set some things before doing the work. For any simple things your minds tends to create virtual or real classes that you will perhaps have the needs,example you needs a square object, nothing else, but you will tends to create first edges, as class of square, and put square in a super class named polygons which will also be in a class of.... you understand the problem? ;-)
so after another people reading your code will say,  "hey what's all this mess?" , and you're code will be hard to read , and even for you when making big program you will have tons of classes, inheritance and will move in a maze of classes!!! a nightmare.... sometimes, i experienced it! at the opposite functional programming is so easy, so clear for your mind.

If you had strong typing which almost always the case in OO programming, non immutable object like in C++, copy constructor, object requiring canonical normal form of Copine,
OO programming can become really stressing to develop with in my opinion.
Damien

On Mon, Mar 11, 2019 at 8:18 AM PY <[hidden email]> wrote:
10.03.2019 23:50, Ramnath R Iyer wrote:
> whereas functional relies on categorization based on 'what actions can
> be done' (aka functions)
that's what interfaces are for.

_______________________________________________
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.

_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: [OT] thoughts about OO vs. functional "philosophy"

Paul
11.03.2019 09:51, Damien Mattei wrote:
 > a method of a class you always have to instantiate an object...

not always, static methods do not need this.

 > so after another people reading your code will say,  "hey what's all
this mess?" , and you're code will be hard to read , and even for you
when making big program you will have tons of classes, inheritance and
will move in a maze of classes!!! a nightmare.... sometimes, i
experienced it! at the opposite functional programming is so easy, so
clear for your mind.

Absolutely no matter what you slice the code: functions in modules or
methods in classes. In Haskell we also have a lot of functions, modules,
types, etc. But the cause of the complexity is not linked directly to
the number of entities (and in most cases it's not): programming in
Smalltalk/Java/VB/Python/etc is simple and fast and increasing of the
number of used classes and methods does not need more specific knowledge
of the language and can be done by newbie who already knows the syntax,
as you said it before - it's enough to instantiate the object and to
call some its method! By the way, Smalltalk, as I know, even has not DI
- I suppose due to image :)

And this is false for Haskell: it's not enough to know language syntax
(it's relatively simple): each library can involve own level of
abstraction, own eDSLs, etc. And if somebody built his library on
arrows, pipes, free monads, etc - it's not enough to know language's
syntax only. Imagine a big house built with simple and same bricks. And
some Baroque theater where anything is complex and unique.

So, languages like Haskell are more complex and need more time to learn
and create valuable applications.
_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: [OT] thoughts about OO vs. functional "philosophy"

Damien Mattei-2
when i was talking about functional programming, i was thinking to Scheme not Haskell, when you use scheme there is no strong typing, no typing at all in almost cases... when you use map it's map, no need to ask yourself if it is mapM or Prelude.map or anything else.... there is no gothic cathedral only old strong roman church style ;-)

On Mon, Mar 11, 2019 at 11:55 AM PY <[hidden email]> wrote:
11.03.2019 09:51, Damien Mattei wrote:
 > a method of a class you always have to instantiate an object...

not always, static methods do not need this.

 > so after another people reading your code will say,  "hey what's all
this mess?" , and you're code will be hard to read , and even for you
when making big program you will have tons of classes, inheritance and
will move in a maze of classes!!! a nightmare.... sometimes, i
experienced it! at the opposite functional programming is so easy, so
clear for your mind.

Absolutely no matter what you slice the code: functions in modules or
methods in classes. In Haskell we also have a lot of functions, modules,
types, etc. But the cause of the complexity is not linked directly to
the number of entities (and in most cases it's not): programming in
Smalltalk/Java/VB/Python/etc is simple and fast and increasing of the
number of used classes and methods does not need more specific knowledge
of the language and can be done by newbie who already knows the syntax,
as you said it before - it's enough to instantiate the object and to
call some its method! By the way, Smalltalk, as I know, even has not DI
- I suppose due to image :)

And this is false for Haskell: it's not enough to know language syntax
(it's relatively simple): each library can involve own level of
abstraction, own eDSLs, etc. And if somebody built his library on
arrows, pipes, free monads, etc - it's not enough to know language's
syntax only. Imagine a big house built with simple and same bricks. And
some Baroque theater where anything is complex and unique.

So, languages like Haskell are more complex and need more time to learn
and create valuable applications.

_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: [OT] thoughts about OO vs. functional "philosophy"

Tarik ÖZKANLI
When you get a deep run-time type incompatibility with a difficult to debug case, the Gothic Church that you talked about may change it's direction and function and chase after you at a very inappropriate midnight. :)

On Mon, 11 Mar 2019 at 15:43, Damien Mattei <[hidden email]> wrote:
when i was talking about functional programming, i was thinking to Scheme not Haskell, when you use scheme there is no strong typing, no typing at all in almost cases... when you use map it's map, no need to ask yourself if it is mapM or Prelude.map or anything else.... there is no gothic cathedral only old strong roman church style ;-)

On Mon, Mar 11, 2019 at 11:55 AM PY <[hidden email]> wrote:
11.03.2019 09:51, Damien Mattei wrote:
 > a method of a class you always have to instantiate an object...

not always, static methods do not need this.

 > so after another people reading your code will say,  "hey what's all
this mess?" , and you're code will be hard to read , and even for you
when making big program you will have tons of classes, inheritance and
will move in a maze of classes!!! a nightmare.... sometimes, i
experienced it! at the opposite functional programming is so easy, so
clear for your mind.

Absolutely no matter what you slice the code: functions in modules or
methods in classes. In Haskell we also have a lot of functions, modules,
types, etc. But the cause of the complexity is not linked directly to
the number of entities (and in most cases it's not): programming in
Smalltalk/Java/VB/Python/etc is simple and fast and increasing of the
number of used classes and methods does not need more specific knowledge
of the language and can be done by newbie who already knows the syntax,
as you said it before - it's enough to instantiate the object and to
call some its method! By the way, Smalltalk, as I know, even has not DI
- I suppose due to image :)

And this is false for Haskell: it's not enough to know language syntax
(it's relatively simple): each library can involve own level of
abstraction, own eDSLs, etc. And if somebody built his library on
arrows, pipes, free monads, etc - it's not enough to know language's
syntax only. Imagine a big house built with simple and same bricks. And
some Baroque theater where anything is complex and unique.

So, languages like Haskell are more complex and need more time to learn
and create valuable applications.
_______________________________________________
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.

_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: [OT] thoughts about OO vs. functional "philosophy"

Brandon Allbery
In reply to this post by Paul
On Mon, Mar 11, 2019 at 6:55 AM PY <[hidden email]> wrote:
And this is false for Haskell: it's not enough to know language syntax
(it's relatively simple): each library can involve own level of
abstraction, own eDSLs, etc. And if somebody built his library on
arrows, pipes, free monads, etc - it's not enough to know language's
syntax only. Imagine a big house built with simple and same bricks. And
some Baroque theater where anything is complex and unique.

So, languages like Haskell are more complex and need more time to learn
and create valuable applications.

OO has its own version of this… more insidiously. You're prone to see a class hierarchy and think you understand it up front because it's all familiar things, but every application in effect has its own distinct notion of what a given class means, exposed as either custom methods or custom implementations thereof implementing the app's specific logic. Haskell's FP style makes you expose this directly. (But it's the same amount of complexity underneath, so ultimately not really different; it just taxes the programmer in different ways.)

--
brandon s allbery kf8nh

_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: [OT] thoughts about OO vs. functional "philosophy"

Ramnath R Iyer-2
In reply to this post by Dennis Raddle
To give credit where due, I finally recalled where I had come across that particular reference to encapsulation. Chapter 1.3, 

On Sun, Mar 10, 2019 at 19:40 Dennis Raddle <[hidden email]> wrote:
Indeed, Python does not enforce encapsulation. It has weakly enforced types as well (duck typing for most objects). But it's still an opportunity to follow an "encapsulation" convention and explain the purpose, while telling my student he won't see the full OO implementation until he gets into Java or C++.

I want to comment on Ramnath's point that encapsulation helps us hold fewer things in our minds. I would agree that's part of it, but in a general sense programming always involves more than we can hold in our minds and never requires us to hold all of it at once.

Consider a mathematical proof that runs to 300 pages. We don't need to hold the whole thing in our minds to create and understand it--but it's still worth finding a way to simplify it so it takes fewer pages or less advanced math.

Although we rarely prove a program's correctness in a strict sense, we probably give some thought to a rough justification of the correctness of our design choices, even if such a justification requires more thoughts than we can hold at once. There is a benefit in encapsulating so that the justification requires fewer thoughts -- say 20 thoughts instead of 200 thoughts.

Now, I'm not sure this is any closer to the heart of the matter. Maybe Ramnath is more essentially correct. Comments welcome.

D



On Sun, Mar 10, 2019 at 7:23 PM Richard O'Keefe <[hidden email]> 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 <[hidden email]> 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.
_______________________________________________
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.
--
Ramnath R Iyer

_______________________________________________
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.