I've gotten into numerous conversations with people about the proper terms to use for members of executable body of code, and the results are surprisingly opinionated.
Almost everyone agrees that a function (the noun), following the mathematical definition thereof, is a thing which accepts an input or multiple inputs, and returns a consistent, repeatable result, directly related to that input. But... say 'method' and/or 'procedure' in front of the wrong people, and you will be taken to task on the semantic meaning of such words, and what is proper and correct within a variety of technical fields.
Similarly, what is meant by "functional" (the adjective) is also up for debate. Some people, when they hear the word "functional" think you're speaking in terms of "functionality" perhaps in the context of user acceptance testing, and the proving of a minimum viable product. Others will think you're referring to the "pure functional" programming paradigm, like as in the sense of Haskell.
Still others will think you are simply referring directly to a specific Java method, or a specific JavaScript function, and correct you accordingly, and not consider whether the terms have any deeper meaning or context at all. (like: "no, this is Java, so it's a method..." or "no, JavaScript only has functions, not methods...")
That being said, I've always felt that these terms have such broad, generalizable definitions, since they've sort of been borrowed from layman's English, and repurposed within a specific context.
Is there REALLY a difference between a "method," a "procedure," and a "function" proper?
> Is there REALLY a difference between a "method," a "procedure," and a "function" proper?
The context you are speaking in entirely determines the answer to this question.
Your context reminds me of "is there REALLY a difference between a 'list', an 'array', a 'tuple' and a 'vector'?", as different languages overload these terms with different (sometimes the same!) properties.
The OP seems to be taking a perspective embedded in operational semantics, where a non-halting, unspecified or incorrect "named callable" should not be properly called a procedure.
Personally, I find both kinds of hair-splitting semantic arguments a waste of time when they're isolated from the underlying question, which should be:
> what sort of conversation do we want to be having about these things? What notation or terminology is going to make that easier?
>> Is there REALLY a difference between a "method," a "procedure," and a "function" proper?
Yes. These words closely follow the evolution of programming paradigms.
Early in computing, code was organized loosely as "blocks of named code", or procedures. These often used ad hoc methods to receive inputs and produce outputs, e.g. by directly writing to various globals, registers, and memory regions. You can imagine that this would result in complex programs, since each procedure may have many intertwined dependencies.
To better organize code, a stricter procedure was developed -- the function. These blocks of named code declare their inputs, using them to produce an output. Although this was the ideal, in practice there still tended to be many undeclared dependencies via globals. Again, this led to hard-to-read, obfuscated code.
So, object-oriented programming introduced methods. These are procedures or functions that belong to a class. Meaning, in addition to their inputs, they can only read and modify particular methods and attributes. Hence, the dependencies of the function beyond its inputs are much more precisely understood and organized. In theory at least.
A function is just a set of ordered pairs. It implies nothing about computation or even decidability. Procedures and methods are just different names for the same general idea: a sequence of steps for a computer to follow. Commonly, the term method also implies the concept of an implicit argument (usually referred to as `self`).
6 comments
[ 3.2 ms ] story [ 30.4 ms ] threadAlmost everyone agrees that a function (the noun), following the mathematical definition thereof, is a thing which accepts an input or multiple inputs, and returns a consistent, repeatable result, directly related to that input. But... say 'method' and/or 'procedure' in front of the wrong people, and you will be taken to task on the semantic meaning of such words, and what is proper and correct within a variety of technical fields.
Similarly, what is meant by "functional" (the adjective) is also up for debate. Some people, when they hear the word "functional" think you're speaking in terms of "functionality" perhaps in the context of user acceptance testing, and the proving of a minimum viable product. Others will think you're referring to the "pure functional" programming paradigm, like as in the sense of Haskell.
Still others will think you are simply referring directly to a specific Java method, or a specific JavaScript function, and correct you accordingly, and not consider whether the terms have any deeper meaning or context at all. (like: "no, this is Java, so it's a method..." or "no, JavaScript only has functions, not methods...")
That being said, I've always felt that these terms have such broad, generalizable definitions, since they've sort of been borrowed from layman's English, and repurposed within a specific context.
Is there REALLY a difference between a "method," a "procedure," and a "function" proper?
The context you are speaking in entirely determines the answer to this question.
Your context reminds me of "is there REALLY a difference between a 'list', an 'array', a 'tuple' and a 'vector'?", as different languages overload these terms with different (sometimes the same!) properties.
The OP seems to be taking a perspective embedded in operational semantics, where a non-halting, unspecified or incorrect "named callable" should not be properly called a procedure.
Personally, I find both kinds of hair-splitting semantic arguments a waste of time when they're isolated from the underlying question, which should be:
> what sort of conversation do we want to be having about these things? What notation or terminology is going to make that easier?
As you pointed out you will get different answers from different people. There is no correct answer.
Yes. These words closely follow the evolution of programming paradigms.
Early in computing, code was organized loosely as "blocks of named code", or procedures. These often used ad hoc methods to receive inputs and produce outputs, e.g. by directly writing to various globals, registers, and memory regions. You can imagine that this would result in complex programs, since each procedure may have many intertwined dependencies.
To better organize code, a stricter procedure was developed -- the function. These blocks of named code declare their inputs, using them to produce an output. Although this was the ideal, in practice there still tended to be many undeclared dependencies via globals. Again, this led to hard-to-read, obfuscated code.
So, object-oriented programming introduced methods. These are procedures or functions that belong to a class. Meaning, in addition to their inputs, they can only read and modify particular methods and attributes. Hence, the dependencies of the function beyond its inputs are much more precisely understood and organized. In theory at least.
That's it, really.