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

Discussion in 'C++' started by Bart van Ingen Schenau, Mar 15, 2013.

  1. On Thu, 14 Mar 2013 11:19:25 +0000, Andy Champ wrote:

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


    Have you considered the possibility that the author of the job advert
    does not really know what he is talking about and that they are actually
    in the process of introducing OO in a procedural (C style) code base?

    I have no experience with functional languages, but from my
    understanding, the functional and OO paradigms are so far apart that
    there is no reasonable way to gradually convert a code-base from
    functional style to OO style.

    >
    > Andy


    Bart v Ingen Schenau
    Bart van Ingen Schenau, Mar 15, 2013
    #1
    1. Advertising

  2. Bart van Ingen Schenau

    Jorgen Grahn Guest

    On Fri, 2013-03-15, Bart van Ingen Schenau wrote:
    > On Thu, 14 Mar 2013 11:19:25 +0000, Andy Champ wrote:
    >
    >> 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.

    >
    > Have you considered the possibility that the author of the job advert
    > does not really know what he is talking about and that they are actually
    > in the process of introducing OO in a procedural (C style) code base?


    I bet that's it. People who don't know functional programming (as in
    LISP, Haskell, Erlang ...) exists often misuse the term, and mean
    procedural programming. Or at least they did 20 years ago ... perhaps
    the ad came in a time capsule?

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
    Jorgen Grahn, Mar 15, 2013
    #2
    1. Advertising

  3. Bart van Ingen Schenau

    Nobody Guest

    On Fri, 15 Mar 2013 21:37:35 +0000, Jorgen Grahn wrote:

    > People who don't know functional programming (as in
    > LISP, Haskell, Erlang ...) exists often misuse the term, and mean
    > procedural programming.


    It can't help that procedural languages frequently (mis)use the term
    "function" to mean a procedure. E.g. the first draft of the C standard I
    found contains 2791 occurrences of the word "function" but doesn't use the
    word "procedure" once.
    Nobody, Mar 16, 2013
    #3
  4. Bart van Ingen Schenau

    Stefan Ram Guest

    Nobody <> writes:
    >It can't help that procedural languages frequently (mis)use the term
    >"function" to mean a procedure. E.g. the first draft of the C standard I
    >found contains 2791 occurrences of the word "function" but doesn't use the
    >word "procedure" once.


    In C, a »function« is whatever n1570 defines a function to be.

    Even in mathematics they do not agree on the definition of
    »function«.

    The most widespread languages, C, C++, Java, C#, VBA do not
    have »procedures« (according to the language
    specifications). »Procedures« exist in Pascal (maybe in
    Modula, too, maybe in Algol, PL/1, or Ada).

    One is free to call some C functions »procedures«, but then not
    every C programmer might immediatly grasp that notion.

    C++ (n3290) is better than C (n1570) insofar as in n3290 the
    documentation of functions has an explicit section label
    »effect« to describe the effect of a function. So, one can
    immediately spot what the value and what the effect is.
    In n1570, there is no such section label.
    Stefan Ram, Mar 16, 2013
    #4
  5. On Mar 16, 1:40 am, -berlin.de (Stefan Ram) wrote:
    > Nobody <> writes:
    > >It can't help that procedural languages frequently (mis)use the term
    > >"function" to mean a procedure. E.g. the first draft of the C standard I
    > >found contains 2791 occurrences of the word "function" but doesn't use the
    > >word "procedure" once.

    >
    >   In C, a »function« is whatever n1570 defines a function to be.
    >
    >   Even in mathematics they do not agree on the definition of
    >   »function«.
    >
    >   The most widespread languages, C, C++, Java, C#, VBA do not
    >   have »procedures« (according to the language
    >   specifications). »Procedures« exist in Pascal (maybe in
    >   Modula, too, maybe in Algol, PL/1, or Ada).


    Alogol-60, yes. CORAL-66, yes.

    But most of them didn't enforce the function/procedure distinction.
    Richie was just being realistic.

    >   One is free to call some C functions »procedures«, but then not
    >   every C programmer might immediatly grasp that notion.
    >
    >   C++ (n3290) is better than C (n1570) insofar as in n3290 the
    >   documentation of functions has an explicit section label
    >   »effect« to describe the effect of a function. So, one can
    >   immediately spot what the value and what the effect is.
    >   In n1570, there is no such section label.
    Nick Keighley, Mar 16, 2013
    #5
  6. Bart van Ingen Schenau

    Stefan Ram Guest

    Stefan Ram, Mar 16, 2013
    #6
  7. Bart van Ingen Schenau

    Nobody Guest

    On Sat, 16 Mar 2013 01:40:54 +0000, Stefan Ram wrote:

    > Nobody <> writes:
    >>It can't help that procedural languages frequently (mis)use the term
    >>"function" to mean a procedure. E.g. the first draft of the C standard I
    >>found contains 2791 occurrences of the word "function" but doesn't use
    >>the word "procedure" once.

    >
    > In C, a »function« is whatever n1570 defines a function to be.
    >
    > Even in mathematics they do not agree on the definition of »function«.


    The term "function" has been around since the 17th century (usually
    attributed to Leibniz), and it's not by coincidence that the same term is
    used in programming, often with similar syntax as in mathematics.

    While the mathematical definition has some loose ends, I don't think that
    many mathematicians would consider "functions" as defined by any
    procedural language to be functions.

    > The most widespread languages, C, C++, Java, C#, VBA do not have
    > »procedures« (according to the language specifications).
    > »Procedures« exist in Pascal (maybe in Modula, too, maybe in Algol,
    > PL/1, or Ada).


    OTOH, there doesn't appear to be any genuine disagreement that all of the
    above are "procedural" languages regardless of which term(s) they use in
    their specification and/or grammar, while "functional" languages are those
    based around a concept of a "function" which is much closer to the
    mathematical concept of that name (even if they don't adhere to it
    rigidly; even ML and Haskell bend the rules to some degree).
    Nobody, Mar 16, 2013
    #7
  8. Bart van Ingen Schenau

    Stefan Ram Guest

    Nobody <> writes:
    >While the mathematical definition has some loose ends, I don't think that
    >many mathematicians would consider "functions" as defined by any
    >procedural language to be functions.


    Denotational semantics does this, as far as I understand it.

    A C function is a mathematical function insofar as it maps
    its argument values to a function that maps the state of the
    environment (prestate) to a state of the environment
    (poststate) and possibly a result value (a kind of a monad).

    >OTOH, there doesn't appear to be any genuine disagreement that all of the
    >above are "procedural" languages regardless of which term(s) they use in
    >their specification and/or grammar, while "functional" languages are those
    >based around a concept of a "function" which is much closer to the
    >mathematical concept of that name (even if they don't adhere to it
    >rigidly; even ML and Haskell bend the rules to some degree).


    Yes.
    Stefan Ram, Mar 16, 2013
    #8
  9. Bart van Ingen Schenau

    Nobody Guest

    On Sat, 16 Mar 2013 22:31:36 +0000, Stefan Ram wrote:

    >>While the mathematical definition has some loose ends, I don't think that
    >>many mathematicians would consider "functions" as defined by any
    >>procedural language to be functions.

    >
    > Denotational semantics does this, as far as I understand it.


    AIUI, denotational semantics typically represents "statements" as
    functions (denotations), whose parameters are the prior state and whose
    value (result) is the new state.

    Functions/procedures within the language aren't treated as functions, but
    e.g. a C expression-statement involving a function call would be. OTOH an
    expression-statement involving the same C function but with different
    arguments would be a different function (denotation).

    The key difference is that C treats its "functions" as functions, whose
    arguments and result are C "values", while denotational semantics treats
    the entire statement (function, arguments, assignment of return value to
    an lvalue, etc) as a function whose argument and value are states.

    You can just as easily (or, rather, more easily) construct a denotational
    semantics for machine code, where each instruction is a function. But
    machine instructions aren't normally described as "functions" or treated
    as such by assembly programmers.
    Nobody, Mar 18, 2013
    #9
  10. Bart van Ingen Schenau

    Stefan Ram Guest

    Nobody <> writes:
    >On Sat, 16 Mar 2013 22:31:36 +0000, Stefan Ram wrote:
    >>>While the mathematical definition has some loose ends, I don't think that
    >>>many mathematicians would consider "functions" as defined by any
    >>>procedural language to be functions.

    >>Denotational semantics does this, as far as I understand it.

    >AIUI, denotational semantics typically represents "statements" as
    >functions (denotations), whose parameters are the prior state and whose
    >value (result) is the new state.
    >Functions/procedures within the language aren't treated as functions,


    I don't know whether that is common teaching in denotational
    semantics (DN), but here comes in what I already wrote, but
    I might have to explain:

    f(1);

    is a statement, which can be interpreted as a function by DN
    as you wrote.

    f(2);

    is another statement, that is, another function.

    Therefore,

    f

    can be interpreted as a function (in the sense of mathematics)
    that maps integers (1, 2, ...) to functions (f(1);, f(2);, ...).

    Thus, I gave an interpretation of C functions as
    mathematical functions (I omitted some technical details
    such as the distinction between expressions and
    statements.). I do not know whether this interpretation
    is common in DN, this interpretation is possible however.
    AIUI it is the point of »monads« in programming.

    (I wrote more about monads on the following page, but this
    page is written in German and sometimes returns 403
    [in which case it might help to try another browser]:

    http://www.purl.org/stefan_ram/pub/monaden

    .)
    Stefan Ram, Mar 18, 2013
    #10
    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. 88888 Dihedral
    Replies:
    14
    Views:
    332
    Alain Ketterlin
    Mar 16, 2013
  2. Melzzzzz
    Replies:
    14
    Views:
    314
    Melzzzzz
    Mar 17, 2013
  3. Öö Tiib
    Replies:
    7
    Views:
    207
    Nick Keighley
    Mar 17, 2013
  4. Stefan Ram
    Replies:
    0
    Views:
    219
    Stefan Ram
    Mar 14, 2013
  5. Nick Keighley
    Replies:
    1
    Views:
    235
    Nobody
    Mar 16, 2013
Loading...

Share This Page