Does it really matter?
This is the sort of thing that I would expect to come up in some pedants interview question - it has very little with being able to use the features effectively.
It doesn't matter if no one cares. It matters if 2 devs are talking and only one distinguished between these terms. In that case he has a chance of getting really confused qickly ;)
Speaking of pedants, recent interview one guy (their 'senior scientist') spent the whole hour tossing pedantic nits at me. What about RESTful interfaces? Are they an API or not? Ha! They're not 'procedural'! Guess what this tiny recursive algorithm's parameters are for? I don't know, whatever you use them for. I would never use a recursive algorithm in embedded work (suicide). Ha! Ha! Its the identity value over the virtual function! Ooookay. Good for you. I'd convert it to tail recursion, then a simple iteration, and never need that value.
I feel your pain man. They're a lot of insecure posers out there who would like to show you that they know more than you do. And often fail miserably at proving their point.
I bet nobody gets keys and values mixed up, even though it's basically exactly that distinction. Far from pedantic, in my view! If you don't know the difference I do think you'll have difficulty using the features effectively.
And if you do know the difference, which most will, it's worth knowing the standard terms. There's only two of them, and it won't take long to commit them to memory.
Try to write an interpreter or compiler (for a language with functions of at least one argument). If you don't get the difference there, you will be in deep trouble.
I don't see how you could do any high-level programming without understanding the difference between defining a function and calling it.
I think you misunderstood collyw's original comment (or maybe I did?) - it's not pedantic to understand the conceptual difference, it's pedantic to worry about the terminology. (Except if you're writing a compiler, I guess, which most programmers are not.)
No, you misunderstand me (and the fault could be mine): my point is that since it's pedantic to worry about the terminology, you might as well use the standard terms. Leave it to others to waste their time worrying about what things are called.
Using the terms in a consistent manner can avoid confusion. I tell beginning programming students that a Parameter is like a "Placeholder," and the Argument is the "Actual" value that fills it in, emphasizing the first letters of each.
Could someone offer a good explanation as to why it matters in this specific case? I can't think of any way in which a lack of knowledge of the "correct" term could lead to something being done incorrectly.
> When someone writes about a function argument I immediately know that code gets executed, but when someone talks about a parameter I know that he’s looking at some declaration or definition!
It might not lead to something being done incorrectly, but I do think it can make communication easier. My initial opinion was that the author was being pedantic, but the above example changed my mind. I've actually had conversations where this distinction would've made everything simpler.
It always matters. The difference between argument and parameter is the difference between concrete and abstract, or the difference between contents and container. Would you ask whether those are relevant distinctions?
Most things rarely matter always. The purpose of words is generally to convey an idea to someone else. Humans are very effective at filling gaps or patching over mistakes in the communications they receive. There are certain key aspects that determine the meaning of a sentence, and one can get pretty far by getting those parts close enough.
I would param that the distinction between "argument vs parameter" is hardly ever a key aspect in a specific communication. The terms you mentioned are more important, so I don't the analogy quite holds up.
If the speaker used argument or parameter incorrectly, the context would make the intention very clear. Most listeners would make the correct mental association without even thinking about it.
One easy way to remember which is which: Recall the term "command line arguments." That will remind you that arguments are what's passed to the function. So, parameters are what's declared/defined in the function.
The words are definitely not interchangeable, but you can probably say "parameter" most of the time, and people will figure out from context whether you mean a parameter or an argument. I'm a lot less certain this applies to "argument".
(You could also say something like "parameter value"... VC++ calls parameters "formal parameters" and arguments "actual parameters", for example.)
"The general consensus seems to be that it's OK to use these terms interchangeably in a team environment. Except perhaps when you're defining the precise terminology; then you can also use 'formal argument/parameter' and 'actual argument/parameter' to disambiguate."
For a field that has so many elements of an exact science, I find it quite astonishing that so many people have such a lax attitude towards fundamental terms. But maybe that's just me.
Perhaps they're lax because distinguishing between parameters and arguments is hardly ever necessary? I can't even imagine a situation where I'd be confused by someone saying "argument" to refer to a "parameter", nor vice-versa.
In general, it's because different languages have sufficiently different semantics that you can not in general use a term from one language on another.
You might think to yourself "Surely this parameter/argument thing is such a fundamental bit of terminology that it would apply to all languages?", to which I'd point out that there's an entire paradigm to which this distinction doesn't, strictly speaking, apply: Concatenative languages. Further, in Perl 5, functions and methods don't really have "parameters" at all. (Prototypes permit some optional, complicated, and generally not used stuff.) Also, in a language that permits equational reasoning it's not clear to me that the distinction has the same meaning, though I'll concede that's a more subtle point.
I'm not aware of very many terms that can be strictly applied across all languages. Even something as innocuous as "int" has significantly different semantics in different languages (does it roll over or transparently upgrade to a BigInt?). You could call it a "machine int", perhaps, but that terminology isn't necessarily what I'd call "common use" even if most people will know what you mean.
That would only be true for distinctions that make a technical difference.
There are also distinctions that only exist for someone to flout[1] their superior knowledge of the technical terms. That is a social status issue, not a matter of precision.
Best example of that case would be collective nouns: "oh gosh, you're supposed to say a "crash" of rhinos; you can't just say a "herd" or "bunch"! ~adjusts monocle~
Best example of "precision matters and can cause confusion" would be "literally" or "biweekly". It causes confusion when people can't rely on X-weekly meaning "X per week" or "every X weeks". You would be majestically justified in prodding people to stick to the same convention to avoid confusion.
But there any scenarios where "signature vs invocation" actually matters to the point that you would do the wrong thing as a result of someone ignorantly flipping the terms? The only thing I can think of would be if someone said, with no other context, "change the parameters to fix the bug".
[1] I know, it's "flaunt", not "flout". That's the point: they don't compete for the same semantic use cases, so they don't cause confusion.
Those parameters hold information about the arguments that were passed in. They don't hold information about what parameters were declared. To programmatically get information about the parameters you would use reflection or something like that.
I think so. Mathematicians talk about “arguments”, but I've never seen “parameter” used. There are more differences in that specific area: Mathematicians apply functions to their arguments. Only a programmer would attempt to “call” a function. That's actually a remnant from “calling a subroutine”, what we did in assembler, even before functions were a thing in programming.
That's accurately named, though. It's values are the arguments that were passed to the function. A hypothetical parameters object would presumably tell you what parameters the function was declared with, e.g.
One also finds the terms "formal parameter" (for what is called a "parameter" in the article) and "actual parameter" (for what is called the "argument" in the article).
I like to phrase it like this: “A parameter is a local variable that's initialized by passing an argument”. That works for functions and C++ templates. It also works in languages like ML, where you can initialize multiple parameters from a single argument (via pattern matching).
Consequently, speaking of “passing a parameter” is dead wrong most of the time, except maybe when you're writing a function that “defines” other functions, where a parameter of the function to be defined is an argument of the definer function. But I will stop here before it gets complicated.
This, like basically all terminology/jargon distinctions, will be community-specific. This particular distinction is idiomatic primarily in the C family (C, C++, Java, ad n.), primarily inheriting from the declaration/definition distinction in the ancestral language. But jargon has dialects---some people will have seen declaration/definition above and now be itching to correct me with 'prototype/implementation'. In other development communities (say, lispers), the terms may be different, the distinction may not exist or a different one might take priority (like, say, car/cdr). As others have said, what matters is clarity of communication, and part of that is always learning the idiom and norms of your community. Note: in many cases there might be a published standard (eg. K&R C, or Academie Francais French), which can inform usage, but not necessarily prescribe it.
Then there's Common Lisp, where a variable is assigned only the first time it's defined, while a parameter is assigned every time its definition form is evaluated: http://clhs.lisp.se/Body/m_defpar.htm.
The meaning of parameters and arguments in the context of functions, which is what this post is about, are defined as usual[1]:
> argument n. 1. (of a function) an object which is offered as data to the function when it is called.
> parameter n. 1. (of a function) a variable in the definition of a function which takes on the value of a corresponding argument (or of a list of corresponding arguments) to that function when it is called, or which in some cases is given a default value because there is no corresponding argument.
What you describe are the two possible ways of defining special variables, which are more like program parameters.
It's nice to know this distinction when you're working with other people who expect this distinction to be followed.
Personally, I prefer the softer explanation in Wikipedia that begins, "The terms parameter and argument are sometimes used interchangeably, and the context is used to distinguish the meaning."
I’ve also seen and used terms like “option” for command-line values, or “bare argument” for values that are not tied to anything in particular. And in code, if the documentation uses hooks like "@param" then people will naturally think of those as parameters. You can also refer to individual fields of a data structure as “parameters” even if they are passed to a function as one value (and I have never seen people refer to fields as “arguments” in that situation).
In the end, I don’t think any term is used consistently enough. People will use whichever words they want, and you have to treat them all as potentially referring to the same thing.
47 comments
[ 144 ms ] story [ 338 ms ] threadNeedless to say I didn't connect.
And if you do know the difference, which most will, it's worth knowing the standard terms. There's only two of them, and it won't take long to commit them to memory.
I think you misunderstood collyw's original comment (or maybe I did?) - it's not pedantic to understand the conceptual difference, it's pedantic to worry about the terminology. (Except if you're writing a compiler, I guess, which most programmers are not.)
It might not lead to something being done incorrectly, but I do think it can make communication easier. My initial opinion was that the author was being pedantic, but the above example changed my mind. I've actually had conversations where this distinction would've made everything simpler.
If the speaker used argument or parameter incorrectly, the context would make the intention very clear. Most listeners would make the correct mental association without even thinking about it.
(You could also say something like "parameter value"... VC++ calls parameters "formal parameters" and arguments "actual parameters", for example.)
http://stackoverflow.com/questions/156767/whats-the-differen...
"Summary"
"The general consensus seems to be that it's OK to use these terms interchangeably in a team environment. Except perhaps when you're defining the precise terminology; then you can also use 'formal argument/parameter' and 'actual argument/parameter' to disambiguate."
You might think to yourself "Surely this parameter/argument thing is such a fundamental bit of terminology that it would apply to all languages?", to which I'd point out that there's an entire paradigm to which this distinction doesn't, strictly speaking, apply: Concatenative languages. Further, in Perl 5, functions and methods don't really have "parameters" at all. (Prototypes permit some optional, complicated, and generally not used stuff.) Also, in a language that permits equational reasoning it's not clear to me that the distinction has the same meaning, though I'll concede that's a more subtle point.
I'm not aware of very many terms that can be strictly applied across all languages. Even something as innocuous as "int" has significantly different semantics in different languages (does it roll over or transparently upgrade to a BigInt?). You could call it a "machine int", perhaps, but that terminology isn't necessarily what I'd call "common use" even if most people will know what you mean.
There are also distinctions that only exist for someone to flout[1] their superior knowledge of the technical terms. That is a social status issue, not a matter of precision.
Best example of that case would be collective nouns: "oh gosh, you're supposed to say a "crash" of rhinos; you can't just say a "herd" or "bunch"! ~adjusts monocle~
Best example of "precision matters and can cause confusion" would be "literally" or "biweekly". It causes confusion when people can't rely on X-weekly meaning "X per week" or "every X weeks". You would be majestically justified in prodding people to stick to the same convention to avoid confusion.
But there any scenarios where "signature vs invocation" actually matters to the point that you would do the wrong thing as a result of someone ignorantly flipping the terms? The only thing I can think of would be if someone said, with no other context, "change the parameters to fix the bug".
[1] I know, it's "flaunt", not "flout". That's the point: they don't compete for the same semantic use cases, so they don't cause confusion.
int main (int argc, char argv)
public static void main(String[] args)
static void Main(string[] args)
sys.argv
Wait a minute...
Let's say: "Here we define a function f(x,y) of two arguments x and y.."
https://en.wikipedia.org/wiki/Parameter_(computer_programmin...
Consequently, speaking of “passing a parameter” is dead wrong most of the time, except maybe when you're writing a function that “defines” other functions, where a parameter of the function to be defined is an argument of the definer function. But I will stop here before it gets complicated.
> argument n. 1. (of a function) an object which is offered as data to the function when it is called.
> parameter n. 1. (of a function) a variable in the definition of a function which takes on the value of a corresponding argument (or of a list of corresponding arguments) to that function when it is called, or which in some cases is given a default value because there is no corresponding argument.
What you describe are the two possible ways of defining special variables, which are more like program parameters.
[1] http://www.lispworks.com/documentation/HyperSpec/Body/26_glo..., http://www.lispworks.com/documentation/HyperSpec/Body/26_glo...
Personally, I prefer the softer explanation in Wikipedia that begins, "The terms parameter and argument are sometimes used interchangeably, and the context is used to distinguish the meaning."
https://en.m.wikipedia.org/wiki/Parameter_(computer_programm...
In the end, I don’t think any term is used consistently enough. People will use whichever words they want, and you have to treat them all as potentially referring to the same thing.