Answers.Body: <p>It is a CS class isn't it? You cannot refuse to use the language of the trade simply because it may have a different meaning for beginners. By all means use the jargon. That may help reinforce the concept in the students' minds. </p>
  
  <p>You just may need to put the extra effort to disambiguate frequently by adding say: I mean your program method. We do this every where. Forexample, a Physics teacher may tell students the field near the GSM tower is strong &amp; then add something like: I mean the electromagnetic field. </p>
  
  <p>Use the jargon bro: they are the more precise scientific terms. Any euphemism or "by-pass" may end up beclouding the concept and befuddling the students.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-10-25T00:50:51.367Z
Answers.Text: You understood the opposite of what I meant: I refuse to use the language of normal people, for fear that when I use the language of the trade, my words will not be recognized.
Answers.UserDisplayName: JohnnyApplesauce
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-10-25T06:25:17.167Z
Answers.Text: OK I get you now. Yes, keeping non technical usage of jargon out can help. E.g. instead of use this method, one could say: use this style for the common meaning.
Answers.UserDisplayName: Mallam Awal
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-10-25T00:06:01.220Z
Answers.LastActivityDate: 2019-10-25T00:26:13.640Z
Answers.LastEditDate: 2019-10-25T00:26:13.640Z
Answers.UserDisplayName: Mallam Awal
Answers.Body: <p>Actually, a <em>static</em> method of a class is the same as a function. The context that is available in the body includes the parameters and the containing (non local) variables. But an ordinary (non static method) is different. It also has as its context the actual object that was sent the <em>message</em> that invoked the method. So, the concepts are different and if you don't get that part the whole meaning of OO programming can be lost. </p>
  
  <p>You "call" a function (static method), but you send a message to an object, via some reference variable that refers to an object of some class. The actual class may not be obvious (or even knowable) from the text of the program without executing it. The class of the object actually determines how the message is handled (which method is invoked). It isn't the text of the program, but the dynamic behavior of it that matters. </p>
  
  <p>For example, consider a list that contains objects of some class along with objects of its subclasses. It is heterogeneous in a certain well defined way. You insert into that list in some way and later, at a different part of the program you want to process all of the objects in that list. So you get an object and you send it a message. If the message is defined in the superclass then the objects of subclasses will understand it, but each might have the message implemented with a different method. When you extract the object from the (heterogeneous) list you don't actually know what class it has other than that it conforms in some way to the protocol of some superclass. </p>
  
  <p>If you can follow the above, you may start to see how important the language actually is and how misleading it can be to use simpler, but inaccurate, language. Dynamic dispatch is the essence of OO programming and what really distinguishes it from other paradigms. </p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-01-14T15:28:55.100Z
Answers.Text: This Answer helped me because it prompted me to think a little more about *Static* and the occasional times I used it. I do still wonder if we couldn't have simpler, but accurate programming languages. Or, fewer of them. But that was a different Question...
Answers.UserDisplayName: Scott Rowe
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-10-25T00:02:12.667Z
Answers.LastActivityDate: 2019-10-25T00:02:12.667Z
Answers.UserDisplayName: Buffy
Answers.Body: <p>In direct answer to your question: not much.  I keep my approach here very simple.  I do as I would for any other time that a word could have two meanings.  If the word use feels ambiguous, I clarify which version I mean.  If it doesn't, I let it stand.</p>
  
  <p>It sounds like you're trying to put a lot of careful discipline into your speech patterns.  There's nothing wrong with that; it's admirable!  It may even help to stem a bit of confusion, but I honestly haven't found that being more relaxed (and clarifying as needed) has caused many roadblocks for my students, so I don't worry about it too much.</p>
  
  <p>I do occasionally discuss trap words when first introducing them, just to make clear to my students that there are now two meanings in play.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-10-25T12:32:11.710Z
Answers.LastActivityDate: 2019-10-25T12:32:11.710Z
Answers.UserDisplayName: Ben I.
Body: <p>For example, words like "method," "puts," and "object" do not have as much linguistic markedness as "comparator," "eff-gets," and even "function" (because context alone at the very least conjures up the math term). So, for example, how do you make clear when explaining classes that when you say "your method doesn't work," that you mean the class's function doesn't work rather than the manner in which a student is carrying out the task at hand doesn't work? My current method(!) is to never use the word with its mundane meaning in a tutoring context: "In the last <em>session</em>, the professor went over <em>ways</em> for writing <strong>methods</strong> for a <strong>class</strong>."</p>
  
  <p>(It may be the case that this isn't a problem for some, but in my first year, I didn't realize that "for-loop" wasn't jargon on the first exposure.)</p>
  
  <p>EDIT: People have missed the point of the question. The <em>names</em> of certain CS concepts have more markedness (“standing-out-ness”) than the names of other concepts. Which particular concepts do not matter: “variable” sounds more like a jargon word, more like a reason to have the ears perk up and know to start taking notes, than “assignment.” When speaking out loud, how do you non-stiltedly mark jargon whose meaning may be overshadowed by a more common meaning in a non-jargon context?</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2022-01-14T12:29:24.677Z
Comments.Text: @ctrl-alt-delor Anything with `getNext()` or similar both returns information and changes internal state.  Stack or queue `pop()` methods are similarly messy. There are undoubtedly more such examples, which is why the rule remains soft in most languages.
Comments.UserDisplayName: Ben I.
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2022-01-14T15:42:25.087Z
Comments.Text: I have never heard the word 'jargon' used in a positive / normative sense, I thought it was purely derogatory. But the primary meaning is just: "the language of the trade". Interesting, ya learn something new every day. But I do tend to abandon any words that become 'tainted' by negative associations, so perhaps I was just trigger happy. (Wait, could that be an unintentional pun? Language is getting very thick these days.)
Comments.UserDisplayName: Scott Rowe
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2022-01-15T19:48:49.120Z
Comments.Text: @BenI.Yes. some people make a mash up of the two (function and procedure), but this is usually an anti-pattern. However It seems unavoidable unless using OO (OO language not needed, you can do OO in C). Just encapsulation is needed: objects with methods (functions and procedures), and data.
Comments.UserDisplayName: ctrl-alt-delor
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-10-24T18:18:59.853Z
Comments.Text: Yes I can see that as a problem. But on a side note: a method can be a function or a procedure (some people make a mash up of the two, but this is usually an anti-pattern, and I can't remember the case where it is not).
Comments.UserDisplayName: ctrl-alt-delor
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-10-25T07:15:52.217Z
Comments.Text: *Session* also has jargon meanings.
Comments.UserDisplayName: Peter Taylor
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-10-25T12:40:49.650Z
Comments.Text: Are you asking about why it is _important_ to use jargon correctly or how we can _avoid_ jargon and use generic terms? I can actually say a lot more about the difference between math and CS in the use of terms _variable_ and _function_. The concepts are very different in the two fields.
Comments.UserDisplayName: Buffy
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-10-25T12:51:06.710Z
Comments.Text: Suggest a _non-jargon_ context in which this might be important. Not a class lecture, I assume.
Comments.UserDisplayName: Buffy
Tags: <best-practice><undergraduate><computational-thinking>
Title: How do you distinguish jargon from normal language in explaining a concept?
ThreadText: # How do you distinguish jargon from normal language in explaining a concept?
  
  (Asked by: username_0 on 2019-10-24)
  
  For example, words like "method," "puts," and "object" do not have as much linguistic markedness as "comparator," "eff-gets," and even "function" (because context alone at the very least conjures up the math term). So, for example, how do you make clear when explaining classes that when you say "your method doesn't work," that you mean the class's function doesn't work rather than the manner in which a student is carrying out the task at hand doesn't work? My current method(!) is to never use the word with its mundane meaning in a tutoring context: "In the last *session*, the professor went over *ways* for writing **methods** for a **class**."
  
  (It may be the case that this isn't a problem for some, but in my first year, I didn't realize that "for-loop" wasn't jargon on the first exposure.)
  
  EDIT: People have missed the point of the question. The *names* of certain CS concepts have more markedness (“standing-out-ness”) than the names of other concepts. Which particular concepts do not matter: “variable” sounds more like a jargon word, more like a reason to have the ears perk up and know to start taking notes, than “assignment.” When speaking out loud, how do you non-stiltedly mark jargon whose meaning may be overshadowed by a more common meaning in a non-jargon context?
  
  **Tags:** best-practice, undergraduate, computational-thinking
  
  > **Comments:**
  > **username_3**: Yes I can see that as a problem. But on a side note: a method can be a function or a procedure (some people make a mash up of the two, but this is usually an anti-pattern, and I can't remember the case where it is not).  
  > **username_4**: *Session* also has jargon meanings.  
  > **username_5**: Are you asking about why it is _important_ to use jargon correctly or how we can _avoid_ jargon and use generic terms? I can actually say a lot more about the difference between math and CS in the use of terms _variable_ and _function_. The concepts are very different in the two fields.  
  > **username_5**: Suggest a _non-jargon_ context in which this might be important. Not a class lecture, I assume.  
  > **username_1**: @username_3 Anything with `getNext()` or similar both returns information and changes internal state.  Stack or queue `pop()` methods are similarly messy. There are undoubtedly more such examples, which is why the rule remains soft in most languages.  
  > **username_2**: I have never heard the word 'jargon' used in a positive / normative sense, I thought it was purely derogatory. But the primary meaning is just: "the language of the trade". Interesting, ya learn something new every day. But I do tend to abandon any words that become 'tainted' by negative associations, so perhaps I was just trigger happy. (Wait, could that be an unintentional pun? Language is getting very thick these days.)  
  > **username_3**: @username_1Yes. some people make a mash up of the two (function and procedure), but this is usually an anti-pattern. However It seems unavoidable unless using OO (OO language not needed, you can do OO in C). Just encapsulation is needed: objects with methods (functions and procedures), and data.  
  
  ---
  
  ## 3 answers
  
  ### Answer by username_1 on 2019-10-25. Score: 3 | Accepted answer
  
  In direct answer to your question: not much. I keep my approach here very simple. I do as I would for any other time that a word could have two meanings. If the word use feels ambiguous, I clarify which version I mean. If it doesn't, I let it stand.
  
  It sounds like you're trying to put a lot of careful discipline into your speech patterns. There's nothing wrong with that; it's admirable! It may even help to stem a bit of confusion, but I honestly haven't found that being more relaxed (and clarifying as needed) has caused many roadblocks for my students, so I don't worry about it too much.
  
  I do occasionally discuss trap words when first introducing them, just to make clear to my students that there are now two meanings in play.
  
  
  ---
  
  ### Answer by username_6 on 2019-10-25. Score: 2
  
  It is a CS class isn't it? You cannot refuse to use the language of the trade simply because it may have a different meaning for beginners. By all means use the jargon. That may help reinforce the concept in the students' minds.
  
  You just may need to put the extra effort to disambiguate frequently by adding say: I mean your program method. We do this every where. Forexample, a Physics teacher may tell students the field near the GSM tower is strong & then add something like: I mean the electromagnetic field.
  
  Use the jargon bro: they are the more precise scientific terms. Any euphemism or "by-pass" may end up beclouding the concept and befuddling the students.
  
  > **Comments:**
  > **username_0**: You understood the opposite of what I meant: I refuse to use the language of normal people, for fear that when I use the language of the trade, my words will not be recognized.  
  > **username_6**: OK I get you now. Yes, keeping non technical usage of jargon out can help. E.g. instead of use this method, one could say: use this style for the common meaning.  
  
  ---
  
  ### Answer by username_5 on 2019-10-25. Score: 2
  
  Actually, a *static* method of a class is the same as a function. The context that is available in the body includes the parameters and the containing (non local) variables. But an ordinary (non static method) is different. It also has as its context the actual object that was sent the *message* that invoked the method. So, the concepts are different and if you don't get that part the whole meaning of OO programming can be lost.
  
  You "call" a function (static method), but you send a message to an object, via some reference variable that refers to an object of some class. The actual class may not be obvious (or even knowable) from the text of the program without executing it. The class of the object actually determines how the message is handled (which method is invoked). It isn't the text of the program, but the dynamic behavior of it that matters.
  
  For example, consider a list that contains objects of some class along with objects of its subclasses. It is heterogeneous in a certain well defined way. You insert into that list in some way and later, at a different part of the program you want to process all of the objects in that list. So you get an object and you send it a message. If the message is defined in the superclass then the objects of subclasses will understand it, but each might have the message implemented with a different method. When you extract the object from the (heterogeneous) list you don't actually know what class it has other than that it conforms in some way to the protocol of some superclass.
  
  If you can follow the above, you may start to see how important the language actually is and how misleading it can be to use simpler, but inaccurate, language. Dynamic dispatch is the essence of OO programming and what really distinguishes it from other paradigms.
  
  > **Comments:**
  > **username_2**: This Answer helped me because it prompted me to think a little more about *Static* and the occasional times I used it. I do still wonder if we couldn't have simpler, but accurate programming languages. Or, fewer of them. But that was a different Question...  
  
  ---
  
  