in reply to Re: How do I go from functional to object oriented programming?
in thread How do I go from procedural to object oriented programming?

Jenda, many many moons ago, I was talking with someone, I can not remember who, in the chatterbox; and he, I remember the person being male, called my subroutines "functions". Since then I have thought of my subroutines as "functions". It appears I have been wrong in my thinking. I do tend to have a lot of faith in the people I talk with in the chatterbox so I do not fact check them when they tell me something (unless it sounds so absurd I have to verify). This is an easy shift in my thinking unlike going from procedural programming to object oriented programming.

You are invited to change the name of your reply node to reflect the correction (functional to procedural) as are all of the other respondents. I have made the change in the title of this node.

Thank you for stopping by and correcting this minor(?) error.

Special note: This is my 300th node.

No matter how hysterical I get, my problems are not time sensitive. So, relax, have a cookie, and a very nice day!
Lady Aleena
  • Comment on Re^2: How do I go from procedural to object oriented programming?

Replies are listed 'Best First'.
Re^3: How do I go from procedural to object oriented programming?
by salva (Canon) on Apr 21, 2015 at 07:49 UTC
    You can keep calling your subroutines functions even if they are procedures. Everybody calls them functions inside the context of imperative programming.

    Functional programming was a obscure thing until a few* years ago. If I recall correctly, the popular meaning for functional programming back them was "programming using functions as first class objects". For instance, Lisp was considered a functional programming language because it was able to build, pass and call functions and closures at runtime, in opposition to other lower level languages as C which didn't support closures and couldn't build functions dynamically.

    Then, the *real* functional programming wave toke over, there was an explosion of new functional languages and functional programming became synonymous to using functions without side effects as in the mathematical sense.

    Nowadays, the name "function" is still used to designate procedures. Any programmer using an imperative language as C/C++, Python, Perl or even old-school functional languages as Lisp will use the term "function" to designate both functions and procedures. Very few would take the time to consider the difference and state it explicitly. AFAIK, the only imperative language making a difference between functions and procedures is Eiffel and then it uses a completely different nomenclature.

    In summary, you can call your subs functions even if you don't do functional programming. And say that you do procedural programming, or more commonly, imperative programming (that subsumes both the procedural and object oriented paradigms).

    *) I would say until around the turn of the millennium... but it is quite subjective.

[reply]

      There are other languages that distinguish between functions and procedures with function meaning "a subroutine that does return a value" and procedure meaning "a subroutine that doesn't return anything". For example Pascal or any procedural extension to SQL I've ever seen. (Microsoft's TSQL, Oracles PL/SQL, ...)

      I think it's actually a little unlucky that C books speak about "void functions" rather than "procedures".

      Jenda
      Enoch was right!
      Enjoy the last years of Rome.

[reply]
        Ah, Pascal differentiates between procedures and functions, but not in the procedural vs functional way. Pascal functions may have side effects, there is nothing in the language forbidding that.

        Regarding the SQL extensions, well, the distinction between functions and procedures is not so clear. The main difference seems to be as in the Pascal case: if there is a return value or not. But then, function calls are allowed embedded inside SQL statements and that opens the door to lots of other considerations, more related to database implementation and internal matters than to anything else.

        I think it's actually a little unlucky that C books speak about "void functions" rather than "procedures".

        Just returning a value doesn't make a function a function in the functional programming sense (deterministic, no side effects). In C (at least) that is exacerbated by the fact that return values are commonly used to report errors.

        So, it's true that C functions returning void are procedures, but then, most C functions returning values are also procedures. The distinction doesn't lie there.

[reply]

In Section Seekers of Perl Wisdom