Re: OO vs functional programming: what's a suitable newsgroup?

Discussion in 'C++' started by 88888 Dihedral, Mar 14, 2013.

  1. Andy Champæ–¼ 2013å¹´3月14日星期四UTC+8下åˆ7時19分25秒寫é“:
    > I came across this in a job advert: "Experience of both functional and
    >
    > Object Oriented design and engineering is essential as the product is
    >
    > evolving from following a functional to an OO design discipline". I was
    >
    > a bit surprised at this - I know little of functional programming (in
    >
    > the Erlang/Haskell etc sense, which I assume is what they mean) but I'd
    >
    > thought it was a newer paradigm.
    >
    >
    >
    > This as a discussion doesn't really belong here - can anyone suggest a
    >
    > suitable newsgroup? I did look at comp.programming, but it doesn't look
    >
    > healthy.
    >
    >
    >
    > Andy


    The V-table part is functional in the run time to be dynamically determined
    in C++ of the virtual method of an object.

    Check how compiler's works then you can induce the relations of the two.
    88888 Dihedral, Mar 14, 2013
    #1
    1. Advertising

  2. 88888 Dihedral

    Melzzzzz Guest

    On Thu, 14 Mar 2013 04:25:51 -0700, 88888 Dihedral wrote:

    > Andy Champæ–¼ 2013å¹´3月14日星期四UTC+8下åˆ7時19分25秒寫é“:
    >> I came across this in a job advert: "Experience of both functional and
    >>
    >> Object Oriented design and engineering is essential as the product is
    >>
    >> evolving from following a functional to an OO design discipline". I was
    >>
    >> a bit surprised at this - I know little of functional programming (in
    >>
    >> the Erlang/Haskell etc sense, which I assume is what they mean) but I'd
    >>
    >> thought it was a newer paradigm.
    >>
    >>
    >>
    >> This as a discussion doesn't really belong here - can anyone suggest a
    >>
    >> suitable newsgroup? I did look at comp.programming, but it doesn't
    >> look
    >>
    >> healthy.
    >>
    >>
    >>
    >> Andy

    >
    > The V-table part is functional in the run time to be dynamically
    > determined in C++ of the virtual method of an object.
    >
    > Check how compiler's works then you can induce the relations of the two.


    Functional programming is opposite to OO programming. Haskell, for example
    does not have dynamic dispatch and inheritance (can be emulated, though)
    but supports parametric polymorhism similar like C++ templates.
    Also, there are no variables in functional programming.
    Melzzzzz, Mar 14, 2013
    #2
    1. Advertising

  3. Melzzzzz <> writes:

    [...]
    > Functional programming is opposite to OO programming. Haskell, for
    > example does not have dynamic dispatch and inheritance (can be
    > emulated, though)


    I completely disagree with this: functional languages have pattern
    matching, including matching on type constructors. This is as powerful
    as dynamic binding; it is actually even more powerful than what most OO
    languages can express, since it covers multiple dispatch.

    > but supports parametric polymorhism similar like C++ templates. Also,
    > there are no variables in functional programming.


    -- Alain.
    Alain Ketterlin, Mar 14, 2013
    #3
  4. 88888 Dihedral

    osmium Guest

    "Juha Nieminen" wrote:

    > Melzzzzz <> wrote:
    >> On Thu, 14 Mar 2013 04:25:51 -0700, 88888 Dihedral wrote:
    >>> The V-table part is functional in the run time to be dynamically
    >>> determined in C++ of the virtual method of an object.
    >>>
    >>> Check how compiler's works then you can induce the relations of the two.

    >>
    >> Functional programming is opposite to OO programming. Haskell, for
    >> example
    >> does not have dynamic dispatch and inheritance (can be emulated, though)
    >> but supports parametric polymorhism similar like C++ templates.
    >> Also, there are no variables in functional programming.

    >
    > Disregard what 88888 says. He's a strange person who has for a very
    > long time made completely random and incoherent posts that do not say
    > anything.


    At the moment, I can't recall ever seeing a single post from Dihedral that
    was coherent and made sense, much less was helpful.
    osmium, Mar 14, 2013
    #4
  5. 88888 Dihedral

    Melzzzzz Guest

    On Thu, 14 Mar 2013 13:40:46 +0100, Alain Ketterlin wrote:

    > Melzzzzz <> writes:
    >
    > [...]
    >> Functional programming is opposite to OO programming. Haskell, for
    >> example does not have dynamic dispatch and inheritance (can be
    >> emulated, though)

    >
    > I completely disagree with this: functional languages have pattern
    > matching, including matching on type constructors. This is as powerful
    > as dynamic binding; it is actually even more powerful than what most OO
    > languages can express, since it covers multiple dispatch.
    >


    You disagree that Haskell does not have dynamic dispatch or
    you think that pattern matching is same as dynamic dispatch?
    Type constructors are not same as types.
    While one can dispatch on type constructors, they all must be part of
    same type.
    You can't make heterogenous list in Haskell and map with virtual function.
    Though, you can emulate it as explained here:
    http://www.haskell.org/haskellwiki/
    Existential_type#Dynamic_dispatch_mechanism_of_OOP
    Melzzzzz, Mar 14, 2013
    #5
  6. Melzzzzz <> writes:

    > On Thu, 14 Mar 2013 13:40:46 +0100, Alain Ketterlin wrote:
    >
    >> Melzzzzz <> writes:
    >>
    >> [...]
    >>> Functional programming is opposite to OO programming. Haskell, for
    >>> example does not have dynamic dispatch and inheritance (can be
    >>> emulated, though)

    >>
    >> I completely disagree with this: functional languages have pattern
    >> matching, including matching on type constructors. This is as powerful
    >> as dynamic binding; it is actually even more powerful than what most OO
    >> languages can express, since it covers multiple dispatch.
    >>

    >
    > You disagree that Haskell does not have dynamic dispatch or
    > you think that pattern matching is same as dynamic dispatch?


    Pattern matching is the same as dynamic dispatch.

    > Type constructors are not same as types.
    > While one can dispatch on type constructors, they all must be part of
    > same type.


    The same way as a virtual function must be declared in a single base
    class.

    > You can't make heterogenous list in Haskell and map with virtual
    > function.


    Again the same holds for OOP: you still need to have a base class to
    hold your virtual function.

    > Though, you can emulate it as explained here:
    > http://www.haskell.org/haskellwiki/
    > Existential_type#Dynamic_dispatch_mechanism_of_OOP


    -- Alain.
    Alain Ketterlin, Mar 14, 2013
    #6
  7. osmiumæ–¼ 2013å¹´3月14日星期四UTC+8下åˆ8時45分11秒寫é“:
    > "Juha Nieminen" wrote:
    >
    >
    >
    > > Melzzzzz <> wrote:

    >
    > >> On Thu, 14 Mar 2013 04:25:51 -0700, 88888 Dihedral wrote:

    >
    > >>> The V-table part is functional in the run time to be dynamically

    >
    > >>> determined in C++ of the virtual method of an object.

    >
    > >>>

    >
    > >>> Check how compiler's works then you can induce the relations of the two.

    >
    > >>

    >
    > >> Functional programming is opposite to OO programming. Haskell, for

    >
    > >> example

    >
    > >> does not have dynamic dispatch and inheritance (can be emulated, though)

    >
    > >> but supports parametric polymorhism similar like C++ templates.

    >
    > >> Also, there are no variables in functional programming.

    >
    > >

    >
    > > Disregard what 88888 says. He's a strange person who has for a very

    >
    > > long time made completely random and incoherent posts that do not say

    >
    > > anything.

    >
    >
    >
    > At the moment, I can't recall ever seeing a single post from Dihedral that
    >
    > was coherent and made sense, much less was helpful.


    Don't you think about how and when programs are designed, compiled
    and executed in the two?

    Functional programming is more abstract.

    OOP is more focused in the application world.
    88888 Dihedral, Mar 14, 2013
    #7
  8. 88888 Dihedral

    osmium Guest

    "88888 Dihedral" wrote:

    osmium? 2013?3?14????UTC+8??8?45?11???:
    > "Juha Nieminen" wrote:
    >
    >
    >
    > > Melzzzzz <> wrote:

    >
    > >> On Thu, 14 Mar 2013 04:25:51 -0700, 88888 Dihedral wrote:

    >
    > >>> The V-table part is functional in the run time to be dynamically

    >
    > >>> determined in C++ of the virtual method of an object.

    >
    > >>>

    >
    > >>> Check how compiler's works then you can induce the relations of the
    > >>> two.

    >
    > >>

    >
    > >> Functional programming is opposite to OO programming. Haskell, for

    >
    > >> example

    >
    > >> does not have dynamic dispatch and inheritance (can be emulated,
    > >> though)

    >
    > >> but supports parametric polymorhism similar like C++ templates.

    >
    > >> Also, there are no variables in functional programming.

    >
    > >

    >
    > > Disregard what 88888 says. He's a strange person who has for a very

    >
    > > long time made completely random and incoherent posts that do not say

    >
    > > anything.

    >
    >
    >
    > At the moment, I can't recall ever seeing a single post from Dihedral that
    >
    > was coherent and made sense, much less was helpful.


    Don't you think about how and when programs are designed, compiled
    and executed in the two?

    Functional programming is more abstract.

    OOP is more focused in the application world.

    QED!!!

    Bonus. Attribution mangling due to Google.
    osmium, Mar 14, 2013
    #8
  9. 88888 Dihedral

    Stefan Ram Guest

    88888 Dihedral <> writes:
    >Functional programming is more abstract.
    >OOP is more focused in the application world.


    C++ class instances have two features:
    - they constitute a unit of dynamic memory allocation
    - they provide a common scope and lifetime for
    functions and fields

    In LISP, the same is possible, but it historically
    predates OOP. For example, in Common Lisp notation:

    ( defun make-counter ()
    ( let(( n 0 ))
    ( values #'( lambda () ( incf n ))
    #'( lambda () ( setq n 0 )))))

    returns a »new counter object« with a field n and
    two methods (which are anonymous yet) to increment
    and to reset this counter. I believe something like
    this to be possible even with older LISP dialects.
    It surely was not possible with FORTRAN or COBOL!

    However, functional programming usually is no fun
    without a garbage collector. So, to some extend it
    is possible more in Java than in C++. (I wrote a
    purely functional parser in Java, but cannot write
    one in C++.)

    A purely functional program only uses names for values,
    but never changes a state (such as that of a variable).
    Evaluations only have a value, never an effect. There
    is no such thing as a block, where statements are
    executed in sequence, there only are expressions.
    Stefan Ram, Mar 14, 2013
    #9
  10. 88888 Dihedral

    Melzzzzz Guest

    On Thu, 14 Mar 2013 16:23:30 +0100, Alain Ketterlin wrote:

    > Melzzzzz <> writes:
    >
    >> On Thu, 14 Mar 2013 13:40:46 +0100, Alain Ketterlin wrote:
    >>
    >>> Melzzzzz <> writes:
    >>>
    >>> [...]
    >>>> Functional programming is opposite to OO programming. Haskell, for
    >>>> example does not have dynamic dispatch and inheritance (can be
    >>>> emulated, though)
    >>>
    >>> I completely disagree with this: functional languages have pattern
    >>> matching, including matching on type constructors. This is as powerful
    >>> as dynamic binding; it is actually even more powerful than what most
    >>> OO languages can express, since it covers multiple dispatch.
    >>>
    >>>

    >> You disagree that Haskell does not have dynamic dispatch or you think
    >> that pattern matching is same as dynamic dispatch?

    >
    > Pattern matching is the same as dynamic dispatch.
    >
    >> Type constructors are not same as types.
    >> While one can dispatch on type constructors, they all must be part of
    >> same type.

    >
    > The same way as a virtual function must be declared in a single base
    > class.
    >


    Heh, I never thought about it in that way:)
    What you actually say is this ?

    data Shape = Circle Double | Rectangle Double Double | Square Double
    deriving (Show)

    perimeter (Circle r) = 2*r*pi
    perimeter (Rectangle x y) = 2*(x+y)
    perimeter (Square x) = 4*x

    shapes = [Circle 2.4, Rectangle 3.1 4.4, Square 2.1]

    main = do
    putStrLn $ show $ map perimeter shapes
    putStrLn $ show shapes

    Actually , yes it looks like perimeter is virtual function ;)
    Melzzzzz, Mar 15, 2013
    #10
  11. 88888 Dihedral

    Melzzzzz Guest

    On Fri, 15 Mar 2013 10:26:17 +0000, Melzzzzz wrote:

    Bah copy pasting messed my formatting ;(

    >
    > data Shape = Circle Double | Rectangle Double Double | Square Double
    > deriving (Show)
    >
    > perimeter (Circle r) = 2*r*pi

    perimeter (Rectangle x y) = 2*(x+y)
    > perimeter (Square x) = 4*x
    >
    > shapes = [Circle 2.4, Rectangle 3.1 4.4, Square 2.1]
    >
    > main = do
    > putStrLn $ show $ map perimeter shapes

    putStrLn $ show shapes
    >
    Melzzzzz, Mar 15, 2013
    #11
  12. Melzzzzz <> writes:

    > On Thu, 14 Mar 2013 16:23:30 +0100, Alain Ketterlin wrote:

    [...]
    >> Pattern matching is the same as dynamic dispatch.

    [...]
    > Heh, I never thought about it in that way:)
    > What you actually say is this ?
    >
    > data Shape = Circle Double | Rectangle Double Double | Square Double
    > deriving (Show)
    >
    > perimeter (Circle r) = 2*r*pi
    > perimeter (Rectangle x y) = 2*(x+y)
    > perimeter (Square x) = 4*x
    >
    > shapes = [Circle 2.4, Rectangle 3.1 4.4, Square 2.1]
    >
    > main = do
    > putStrLn $ show $ map perimeter shapes
    > putStrLn $ show shapes
    >
    > Actually , yes it looks like perimeter is virtual function ;)


    Yes, I think the difference is really a matter of focus: OO focuses on
    data (i.e., classes), whereas FP focuses on functions.

    OO makes it easy to add a new type of data (a new subclass), but makes
    it harder to add a new virtual function (you'll have to modify all
    classes).

    FP makes it easy to add a new function, but makes it harder to add a new
    type of data (you'll have to modify all functions).

    -- Alain.
    Alain Ketterlin, Mar 15, 2013
    #12
  13. Alain Ketterlinæ–¼ 2013å¹´3月15日星期五UTC+8下åˆ7時23分25秒寫é“:
    > Melzzzzz <> writes:
    >
    >
    >
    > > On Thu, 14 Mar 2013 16:23:30 +0100, Alain Ketterlin wrote:

    >
    > [...]
    >
    > >> Pattern matching is the same as dynamic dispatch.

    >
    > [...]
    >
    > > Heh, I never thought about it in that way:)

    >
    > > What you actually say is this ?

    >
    > >

    >
    > > data Shape = Circle Double | Rectangle Double Double | Square Double

    >
    > > deriving (Show)

    >
    > >

    >
    > > perimeter (Circle r) = 2*r*pi

    >
    > > perimeter (Rectangle x y) = 2*(x+y)

    >
    > > perimeter (Square x) = 4*x

    >
    > >

    >
    > > shapes = [Circle 2.4, Rectangle 3.1 4.4, Square 2.1]

    >
    > >

    >
    > > main = do

    >
    > > putStrLn $ show $ map perimeter shapes

    >
    > > putStrLn $ show shapes

    >
    > >

    >
    > > Actually , yes it looks like perimeter is virtual function ;)

    >
    >
    >
    > Yes, I think the difference is really a matter of focus: OO focuses on
    >
    > data (i.e., classes), whereas FP focuses on functions.
    >
    >
    >
    > OO makes it easy to add a new type of data (a new subclass), but makes
    >
    > it harder to add a new virtual function (you'll have to modify all
    >
    > classes).
    >


    I think you are referring languages focused on the static compilation
    approach for optimized objective parts linked statically to be executed
    in the run time.


    >
    >
    > FP makes it easy to add a new function, but makes it harder to add a new
    >
    > type of data (you'll have to modify all functions).
    >
    >
    >
    > -- Alain.


    I can't agree with you in this point. The FP part can't do in-line
    optimizations for speed in the compilation phase easily.
    88888 Dihedral, Mar 15, 2013
    #13
  14. 88888 Dihedral

    Stefan Ram Guest

    Alain Ketterlin <-strasbg.fr> writes:
    >OO makes it easy to add a new type of data (a new subclass), but makes
    >it harder to add a new virtual function (you'll have to modify all
    >classes).


    One can »add« a new function to a base class not by modifying
    the base class, but by adding a new derived class which adds
    that function. And the same holds for all the subclasses.
    (open-closed principle)

    >FP makes it easy to add a new function, but makes it harder to add a new
    >type of data (you'll have to modify all functions).


    In Haskell, it might suffice to add just a new pattern on the
    left side of the definition for the new type for those functions
    that are really needed to operate on the new type. (But I don't
    know Haskell that well.)
    Stefan Ram, Mar 15, 2013
    #14
  15. -berlin.de (Stefan Ram) writes:

    > Alain Ketterlin <-strasbg.fr> writes:
    >>OO makes it easy to add a new type of data (a new subclass), but makes
    >>it harder to add a new virtual function (you'll have to modify all
    >>classes).

    >
    > One can »add« a new function to a base class not by modifying
    > the base class, but by adding a new derived class which adds
    > that function. And the same holds for all the subclasses.
    > (open-closed principle)


    Yes, but what I meant is the situation where you need to add a new
    function for all existing classes, like, e.g., when you have a very nice
    hierarchy of shapes and realize that you need to compute the bounding
    box of all possible shapes.

    >>FP makes it easy to add a new function, but makes it harder to add a new
    >>type of data (you'll have to modify all functions).

    >
    > In Haskell, it might suffice to add just a new pattern on the
    > left side of the definition for the new type for those functions
    > that are really needed to operate on the new type. (But I don't
    > know Haskell that well.)


    Yes again. My remark was more about the arrangement of syntactic
    structures: OO is centered around classes, FP around functions.

    -- Alain.
    Alain Ketterlin, Mar 16, 2013
    #15
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Melzzzzz
    Replies:
    14
    Views:
    303
    Melzzzzz
    Mar 17, 2013
  2. Öö Tiib
    Replies:
    7
    Views:
    205
    Nick Keighley
    Mar 17, 2013
  3. Stefan Ram
    Replies:
    0
    Views:
    214
    Stefan Ram
    Mar 14, 2013
  4. Bart van Ingen Schenau
    Replies:
    9
    Views:
    216
    Stefan Ram
    Mar 18, 2013
  5. Nick Keighley
    Replies:
    1
    Views:
    226
    Nobody
    Mar 16, 2013
Loading...

Share This Page