<p>The problem with simplifying-by-lie is in the consequences it can have when your student faces practical, real world code development or maintenance situations as a beginner:</p>

<ul>
<li><p>When trying to find out the cause of a bug, they might discount the possibility of something that you said is impossible, and thus not check for it and thus not find the bug.</p></li>
<li><p>They might make a fool out of themselves by trying to defend what you told them as gospel against seasoned professionals, possibly with extreme accidental arrogance.</p></li>
</ul>

<p>So, it is always best to advertise the fact that you are simplifying.</p>

CC BY-SA 4.0
2018-05-18T14:58:56.543Z
True, but no student is going to go straight from CS 1 to a job interview or industry; nor would I expect them to do independent programming in which the oversimplification misled them, before taking a more advanced class or doing additional reading. In upper-division classes, I am much more rigorous.
Ellen Spertus
CC BY-SA 4.0
2018-05-19T10:41:52.927Z
You are not in control of when your students take initiative to make use of what you teach them.
rackandboneman
CC BY-SA 4.0
2018-05-13T02:38:32.343Z
2018-05-13T02:38:32.343Z
rackandboneman
<p>For starters, there is no such thing as an "Intro CS in Java" course, and the word Interface would never come up in such a course anyway.</p>

<p>"Computer Science" means using computers to solve problems.  Nevermind the fact that Java would never have made it out of the gate were it not for being named after a drink we are all addicted to.  Problem solving has nothing to do with Java, and a weighty language like Java has no place in an Intro class, unless your school is pandering to corporations, or Mao Tse Deng has designed your CS program to go from Freshman to Ph.D in three years.</p>

<p>Intro to CS students should be learning about assignment statements, conditional statements, writing small swap functions, learning about basic loops, memory allocation, and then recursion, fractals, string types, and then toward the end, some more interesting and complex functions and a little bigger programs.</p>

<p>Since Java is garbage collected, and its syntax doesn't represent machine code instructions, there is no place for it in an Intro to CS class, or any CS class really.  This is a science class, not a syntax class.  Use C.  If your students are asking about interfaces, then you are doing something very seriously wrong in your intro class.</p>

<p>Now, regarding lying, I don't know if you are a foreign teacher or not, but it's an extremely strange question in the West.  A teacher should NEVER LIE to a student to any degree and for ANY reason.  A student in a classroom is essentially in a hypnotic state of <em>a priori</em> belief in your authority as the true instruction.  Your students will take your lie, or stretching of the truth, at face value, and will cherish that belief FOREVER.  Most humans hold their beliefs not because they make sense, but because that was the first believe introduced to them on a subject.  Very few people every reach logical escape velocity.</p>

<p>By lying, you will destroy the credibility of your colleagues and any future teacher (who does NOT lie) who will teach that student correctly, and thus will contribute in a very dangerous way to the breakdown of the pillars of civil society itself, which rest on the first principal of integrity.</p>

CC BY-SA 4.0
2019-02-27T01:37:01.930Z
Of course there are intro to CS classes in Java, and many of them. It is the most commonly taught language in intro-level cs classes at universities (at least as of two years ago.)
Ben I.
CC BY-SA 4.0
2019-02-27T01:38:27.887Z
Also, much of the art of teaching is figuring out when to introduce wrinkles in order to allow students time to absorb complex ideas. When introducing the letter "j" to a 3 year old, we might say that "j" at the beginning of a word makes a "dʒ" sound. It would be utterly unfair (and counterproductive!) to mention at this moment that there is another language, French, in which it actually sounds like "ʒ". While the "dʒ" statement is a lie, it keeps information at a level at which it can be absorbed. The child can get to other languages later, and will learn about other sounds at that time.
Ben I.
CC BY-SA 4.0
2019-03-02T14:37:21.600Z
"Of course there are intro to CS classes in Java, and many of them. It is the most commonly taught language in intro-level cs classes at universities".  You are correct.  And yet you have completely missed the point.
Johnny
CC BY-SA 4.0
2022-06-10T05:38:37.170Z
"and its syntax doesn't represent machine code instructions" that is rather the point of high level programming languages.
Dikran Marsupial
CC BY-SA 4.0
2019-02-27T00:06:39.997Z
2019-03-02T18:40:43.207Z
2019-03-02T18:40:43.207Z
Johnny
<p>In my textbook, I say, &quot;In its most basic form, an interface is an offer to sign a contract.&quot;   It consists of a collection of method headers; classes sign the contract by implementing the interface.  I then proceed from there to discuss interfaces, polymorphism, and the Visibility and Delegation priciples.</p>
<p>This allows me to defer the development of static methods and data and default methods in interfaces.</p>

CC BY-SA 4.0
2022-06-10T05:35:58.903Z
Indeed, there is no need to say "interfaces cannot contain any code" in the first place, it isn't necessary to explain what interfaces are and how they are used.  The fact that the example interfaces used won't contain any code is sufficient to indicate that they don't *normally* include code.
Dikran Marsupial
CC BY-SA 4.0
2022-06-09T22:32:18.500Z
2022-06-09T22:32:18.500Z
ncmathsadist
<p>I would start sentences with "Generally speaking..." and I would appreciate if my professors did the same. It hints that there is more to know but doesn't waste time explaining anything further. If your students are curious enough they can raise their hand to inquire. If it takes too much time to explain during class and someone wants to know, you can offer more of your time during your office hours.</p>

<p>Nobody likes being lied to.</p>

<p>The phrase "generally speaking", does not imply that you are lying, it just points out that it is the most common case of something. You could also begin sentences with "Typically..."</p>

<p>In that particular example, you don't have to say "cannot", you could say they "typically don't".</p>

<p>"Generally speaking, interfaces do not contain any code." It shouldn't be more complicated than that.</p>

CC BY-SA 4.0
2018-05-08T13:54:53.767Z
Welcome to [cseducators.se]. Great suggestion. I hope we'll see more ideas from you on the site.
Gypsy Spellweaver
CC BY-SA 4.0
2018-05-09T10:41:43.800Z
Good suggestion, it gracefully deals with a huge problem in 2 words :)
"As a rule"/"As a general rule" could also be used in the same place.
Algy Taylor
CC BY-SA 4.0
2018-05-09T17:34:26.410Z
This is good. I was advanced for my course and when teacher "lied" I thought it was because they didn't know better. If they said "generally speaking" it peaked my curiosity to look at it further.
the_lotus
CC BY-SA 4.0
2018-05-09T19:12:25.857Z
The phrase "generally speaking" is great, because it invites a student to treat something applies in the cases that are going to follow, but discourages excessive inferences that might lead the student astray.
supercat
CC BY-SA 4.0
2018-05-10T20:31:43.360Z
+1 I'd suggest "should not" over "do not" - that way it begins to act as a red-flag to highlight a potentially bad programming practice.   There will be times it may be the right thing to do, but it then leads the students to check that code carefully and encourage them to justify their actions if/when they do so.
James Snell
CC BY-SA 4.0
2018-05-08T02:30:25.827Z
2019-08-06T16:43:36.630Z
2019-08-06T16:43:36.630Z
ADJenks
<p>Lying is good. But advertise it when you lie. Make sure students make a note of it that you are lying.</p>
<p>Pedantic is bad. If you try to explain <em>everything</em> you will wind up explaining <em>nothing</em>. Let me take a simpler example. In java we have a special incantation</p>
<pre class="lang-java prettyprint-override"><code>public static void main(String [] args)
</code></pre>
<p>We put it in every program. It distinguishes a program. But if you start your java course explaining every part of it you will (a) confuse the juices out of them and (b) never get to the point of writing a useful program. For the beginner, it is just an incantation like</p>
<pre class="lang-c prettyprint-override"><code>Riddikulus; // used in defence against a Boggart.
</code></pre>
<p>The Java code is just a &quot;charm&quot; for the beginner. All you need to say is that it is a &quot;hook&quot; for the OS to find its way into your program. Explain it later after you've taken up some of its elements for other purposes.</p>
<p>Beginners need a simple but coherent view of their language and system. When you simplify, work hard to keep it consistent. But it doesn't need to be complete and certainly not exhaustive.</p>
<p>When you are giving an &quot;overly&quot; simplified view, say that explicitly. Have the students mark their notes with an asterisk (or the above charm) so that they know it isn't complete. If you are explicitly asked for &quot;the rest of the story&quot; you have to decide whether it will help to include it (after the commercial break, of course) or to defer it or to enlighten the students out of the class context (email, say), or give a reference for those who &quot;will <em>not</em> be denied.&quot;</p>
<p>I used to start some discussions with &quot;I'm about to lie to you, but it will be helpful if you accept my lie for a bit&quot;. Of course I had to remember to come back an fill in the blanks  later, but it might not be for a while. Complex, inter-dependent topics are like that.</p>
<p>tl;dr: <strong>Lie, but honestly and truthfully.</strong></p>
<p>And, perhaps the most important caveat, <em>don't lie in such a way that the student later needs to <strong>unlearn</strong> something</em>. Lying is giving partial truths, or temporary world views, not sending students into mental blind alleys and backwaters. Withholding some facts may be necessary and valuable as is presenting an incomplete metaphor. UnLearning should never be part of learning.</p>
<p>I'll also note that infants learn to speak a native language without everything being explained to them before they begin. The deeper understanding comes to them only gradually and over time. We are actually conditioned by evolution to work this way.</p>
<hr />
<p>Added in June 2022. <a href="http://www.qwantz.com/index.php?comic=3907" rel="noreferrer">Today's Dinosaur Comics</a> gives a good illustration of this. Note that Ryan North, the creator of Dinosaur Comics has a masters in CS.</p>

CC BY-SA 4.0
2018-05-08T09:08:01.743Z
Note that it's not just CS where this applies.  Physics professors should prefix any discussion of friction with "This is the greatly simplified version of things.  If you want more detail, plan to get your doctorate in the subject."
Mark
CC BY-SA 4.0
2018-05-08T09:22:54.090Z
Some say `public static void main(String[] args)` is the most powerful spell of all. The results are only limited by your imagination!
JollyJoker
CC BY-SA 4.0
2018-05-08T10:42:05.177Z
`public static void main(String[] args)` is the entrypoint for a frictionless, perfectly spherical Java program
Lightness Races in Orbit
CC BY-SA 4.0
2018-05-08T16:02:11.653Z
Assume a spherical cow.jar in a vacuum.
Monica Apologists Get Out
CC BY-SA 4.0
2018-05-08T17:28:21.007Z
Related: [lie-to-children](https://en.wikipedia.org/wiki/Lie-to-children), "a simplified explanation of technical or complex subjects as a teaching method for children and laypeople".
Pablo H
CC BY-SA 4.0
2018-05-08T19:57:27.757Z
+1 for a great answer, and props for figuring out how to add a Harry Potter reference!
tonysdg
CC BY-SA 4.0
2018-05-08T23:43:44.407Z
@LightnessRacesinOrbit: Java programs are never frictionless, but in their natural state with mass approaching infinity, they do approach becoming perfectly spherical.
R.. GitHub STOP HELPING ICE
CC BY-SA 4.0
2018-05-09T00:17:33.387Z
@PabloH I much prefer the Discworld version :)  It includes "Lies to Wizards".  Being made by a computer. https://wiki.lspace.org/mediawiki/Lies-To-Children
ivanivan
CC BY-SA 4.0
2018-05-09T16:01:05.637Z
@Mark Mathematics, also. We definitely don't want to say things to first graders like, "In studying addition we are really looking at an Abelian group (which will later be extended to a field by adding a second operator). Some of you may be questioning whether it's truly a group and what the cardinality of the underlying set is, due to your current understanding of numbers. So we will answer those questions by expanding our discussion to countably infinite sets and additive inverses."
Todd Wilcox
CC BY-SA 4.0
2018-05-09T16:10:18.140Z
It may not be a bad idea to be pedantic *once*, as an explanation for why you aren't always going to go into detail. It also gives you a way to derail a student who wants to dig into the details at an inappropriate moment - they can check back during office hours (or whatever) if they want more detail.
RDFozz
CC BY-SA 4.0
2018-05-09T17:16:58.150Z
@PabloH has the correct idea.  My own preference is _abstraction_ in the CS sense, alternatively:  "A _Wittgenstein's ladder_ is a simplified explanation of a technical or complex subject that is used as a teaching tool, despite being technically wrong." (cf wikipedia)
Ti Strga
CC BY-SA 4.0
2018-05-10T03:27:48.790Z
@JollyJoker And your computer memory and processing speed.
jpmc26
CC BY-SA 4.0
2018-05-11T14:30:43.043Z
@ToddWilcox There is an algebraic structure called near-ring where addition does not need to be an Abelian group, https://en.wikipedia.org/wiki/Near-ring . Or was the idea that one lies to students that addition must be commutative?
user2219896
CC BY-SA 4.0
2018-05-16T09:24:08.970Z
"don't lie in such a way that the student later needs to unlearn something" -- Most important sentence in this answer, and often violated.
Raphael
CC BY-SA 4.0
2018-05-16T09:25:42.967Z
"I'll also note that infants learn to speak a native language without everything being explained to them before they begin" -- True. But: that takes years (decades, even) and regularly fails to produce speakers/writers with full command of their native tongue. Neither is really acceptable in (CS) education.
Raphael
CC BY-SA 4.0
2018-05-16T15:40:52.183Z
I broadly used the term "black magic" for parts of the boilerplate in a program people don't need to understand yet, but are asked to blindly copy for now.
Oleg Lobachev
CC BY-SA 4.0
2018-07-25T19:07:26.223Z
+1 My boggart is a professor that leaves out details and makes no mention of the omission.
koverman47
CC BY-SA 4.0
2019-04-08T07:28:52.783Z
@ToddWilcox if you know a first grade teacher who knows abstract algebra, I'd love to meet them.
setholopolus
CC BY-SA 4.0
2020-05-03T05:41:53.160Z
I wonder if an honest lie is a lie at all :D This is another topic, but I like the way you put it in catchy terms. I also like the overall attitude towards (learning) human beings which is evident in your text. +1! @Buffy
Antares
CC BY-SA 4.0
2022-06-10T05:06:15.820Z
It's funny, learning charms at Hogwarts is what I tell my students that programming is emphatically not, and that there is an underlying logic and structure to programming languages, which they should aim to learn....  But that they can't learn it all at once so they have accept some boilerplate at the start, but they shouldn't be comfortable with that in the long run.  I would say "never lie", you don't need to be pedantic to avoid lying, you just don't need to tell all the truth at once.
Dikran Marsupial
CC BY-SA 4.0
2018-05-07T22:50:33.837Z
2022-06-07T12:10:38.577Z
2022-06-07T12:10:38.577Z
Buffy
<p>I must say, I largely agree with the posters so far.  The principle of lying with your fingers crossed is a good one.  <em>However</em>, I have two caveats, and I believe that they are important.</p>

<p><strong>First, I have a small bone to pick with something <a href="https://cseducators.stackexchange.com/a/4720/27">/u/SlyFiye said</a>:</strong></p>

<blockquote>
  <p>For what its worth, I appreciate the honesty when my instructor uses crossed fingers .... I will treat knowledge given to me in this manner as <strong>practical use advice and not grounded principle.</strong></p>
</blockquote>

<p><sup>(emphasis mine)</sup></p>

<p>It seems to me that this is exactly backwards.  The reason to give an incomplete picture is to allow students to absorb important grounding principled before adding wrinkles and complexities.  This is what motivates the entire enterprise.</p>

<p><strong>Second, the principle is one for</strong> <strong><em>usually,</em></strong> <strong>and not for</strong> <strong><em>always.</em></strong>  </p>

<p>I've repeatedly observed in my own classroom that, if my students are already somewhat lost in a complex topic, even hinting that there might be more complexity beneath the surface causes them to completely lose the topic.  It has been consistent enough that I am utterly convinced that this effect is real, and we need to treat it with care.</p>

<p>I have two brain-based theories for why this might be.  I have not found any research to support (or detract) from these theories, but they could both well explain the phenomenon:</p>

<ol>
<li><p><strong>Simple de-motivation.</strong>  Upon hearing that this <em>very hard thing</em> that they are faced with is partially false, the student simply despairs and gives up.  Why do all of the hard work to understand something that isn't even true?</p></li>
<li><p><strong>Brain-scrambles.</strong> What happens in a student's brain when they hear that there is more to the story may not exactly be the blank <em>"okay, there will be more later"</em> that we might hope for. Instead, what might happen is a series of rapid mental transitions, in which the student mentally loops through the components of what they have learned and tries to guess at <em>which part</em> might not be true, exactly, and what that truth might be.  This involves a sort of miniature cognitive scramble at each pass.  <em>"Okay, so if</em> <strong><em>this</em></strong> <em>part isn't true, then maybe things don't quite connect the way I've just been shown."</em></p>

<p>The reason that this matters is that, if the connections in your student's brain are already quite tenuous, the process of scrambling can muck everything up.  </p>

<p>When faced with the revelation that the topic has even more to it, confused students <em>still go through that same mental process described above</em>, but what comes out of it is essentially spaghetti.  That tiny, inchoate thread that they were constructing about your topic will simply come apart.</p></li>
</ol>

<p>Regardless of the reason, if my students are already confused, I have found it better to hold off on even mentioning that the material is really more complex.  Give the students a chance to try to get a handle on the ideas you have placed before them before inviting them entertain any further complexity.</p>

<p>You can come back around and fix things later. Or not. I actually take a rather dim view of making sure that every statement is always fully accurate. Sometimes insisting on total accuracy can pull your students deep enough into the weeds that they simply get lost, and never fully notice the giant statue that you were trying to point them to.</p>

<p>I stand by what I said at the beginning; crossing your fingers is usually the best way to go.  But sometimes it can be more effective to choose your battles and let sleeping monsters lie.</p>

CC BY-SA 4.0
2018-05-08T12:37:31.213Z
"...choose your battles and let sleeping monsters lie". OTOH, if the road ahead is twisty and has obstacles it is good to put up a warning sign. If students think it is going to be easy, they may wind up blaming their own skills when it turns out harder than they expected. In fact, the topic at hand may be inherently difficult, even for the professionals.
Buffy
CC BY-SA 4.0
2018-05-08T03:35:01.363Z
2018-05-08T12:31:15.170Z
2018-05-08T12:31:15.170Z
Ben I.
<p>I would suggest saying "for the purposes of this class" or something along those lines to make it clear that while it may not be true, they can take it as truth, and that they don't need to learn the obscure case where it isn't as a hope for an surprise question or the like, similarly to how when teaching elementary physics you would typically ignore wind resistance and relativistic effects </p>

CC BY-SA 4.0
2018-05-08T20:49:49.493Z
I think this is a good answer but probably not one that should be applied to other contexts. For example, one shouldn't preface a lie to one's spouse with "for the purposes of our marriage". ;-)
Ellen Spertus
CC BY-SA 4.0
2018-05-10T00:53:23.987Z
@EllenSpertus I figured this being CS educators and not interpersonal or something along those lines, the context would limit the scope of the answer enough
user2813274
CC BY-SA 4.0
2018-05-12T17:06:07.927Z
For the purposes of this website...
bdsl
CC BY-SA 4.0
2018-05-08T01:48:52.313Z
2018-05-08T01:48:52.313Z
user2813274
<blockquote>
  <p>Tell all the truth but tell it slant —<br>
  Success in Circuit lies<br>
  Too bright for our infirm Delight<br>
  The Truth's superb surprise<br>
  As Lightning to the Children eased<br>
  With explanation kind<br>
  The Truth must dazzle gradually<br>
  Or every man be blind —  </p>
</blockquote>

<p><sup>Emily Dickinson, poem number 1129 in <em><a href="https://www.amazon.co.uk/Complete-Poems-Emily-Dickinson/dp/143957183X/ref=tmm_hrd_title_0?_encoding=UTF8&amp;qid=&amp;sr=" rel="noreferrer">Complete Poems</a></em></sup></p>

<p>Dijkstra often mentions the limited size of our skulls, so maybe you could make a remark at the start of your teaching that you cannot possibly convey all of the subtleties of every topic and you are going to have to abbreviate to begin teaching somewhere. This is the opposite of my favorite principle: <strong>The Sweater Effect</strong>: just start pulling anywhere, and sooner or later the entire thing will come unraveled.</p>

<p>I guess we could call your issue, <strong>The Enlightenment Effect</strong>. Sometimes it is referred to as "Lies to Children."</p>

CC BY-SA 4.0
2018-05-08T13:41:12.257Z
2018-05-08T14:02:03.907Z
2018-05-08T14:02:03.907Z
user5068
<p>As a current CS student, my lecturer use to solve this by simply using <strong>For now</strong>.</p>

<p>To come back to your interface example:</p>

<p>For now, interfaces cannot contain any code, unlike abstract classes.</p>

<p>This gives a clear message, there is more to the topic, but it isn't relevant at the moment. When students ask you can always elaborate a little bit, but for the most questions I think this will be sufficient.</p>

CC BY-SA 4.0
2018-05-10T06:34:31.683Z
You could also say up front that the course will be teaching Java 1.5 (or whatever fixed version).  Then extensions in newer versions can be covered in the last lecture.
Ed Avis
CC BY-SA 4.0
2018-05-10T20:24:17.443Z
My only concern is that 'for now' is invariably an invitation to some smart-alec to do it.
James Snell
CC BY-SA 4.0
2018-05-11T10:01:25.953Z
@JamesSnell Speaking as a lifelong smart-alec I can assure you that I need no invitation. Pretending no one is hiding behind the curtain will only result in me pulling on your drapes. However, a "don't worry about that for now" and a conspicuous wink will put a smile on my face and keep my butt in my seat.
candied_orange
CC BY-SA 4.0
2018-05-08T11:40:53.637Z
2018-05-08T11:40:53.637Z
Corba
<blockquote>
  <p>unlike abstract classes, interfaces generally do not contain any code</p>
</blockquote>

<p>This is not a lie.  In a large lecture hall, if they ask for "when do they contain code", say "that will be covered in another class" to avoid going off on a (possibly confusing) tangent.</p>

<p>This is <em>neither</em> lying, but it is glossing over details.  There are situations where lying is a good plan, but they are few and far between (for example, when you teach Newtonian physics, always qualifying every statement with "at velocities far below the speed of light" would get tedious quickly).</p>

<p>Telling a lie should be avoided for a few reasons.  First, your students may believe your lie and get confused later.  Second, they may catch you in a lie, and lose confidence in everything else you are saying or get confused because of the lie.</p>

<p>Finally, not-lies but glossing over (with words like "generally") leave places for students who are extra eager to look into it themselves.  If you lied they wouldn't know where to start looking, but by implicitly leaving a sign saying "there are more details here" you can recruit some student self-motivation to do your work (educating them) for you.</p>

CC BY-SA 4.0
2018-05-09T07:27:29.093Z
To be fair, students "losing confidence" can be a good thing - if it leads them to being critical of everything they learned, they can *do better*. It can also help them learn in the first place, by making things more interesting. But that's probably a minority (at least in modern school systems); most people will carry their misconceptions to the grave (or the next serious project where this lie actually matters :P).
Luaan
CC BY-SA 4.0
2018-05-12T02:55:00.093Z
@Luaan, your comment is a good example of false information (a lie).  No, it is *not* a good thing to make your students lose confidence.
Wildcard
CC BY-SA 4.0
2018-05-12T08:16:57.867Z
@Wildcard That's why the *if* is there - I'm not saying you should try it on purpose (or keep teachers that are horrible). It's more like a final consolation than a study plan :) But I guess it could be worded differently - it's a good thing if students don't take their teacher as an authority. That doesn't mean quite the same thing as "ignore that stupid old fart" - a teacher that isn't afraid to admit he doesn't understand or know something is a great bonus. Not assuming everything you say is right just because you're a teacher really leads to *more* confidence.
Luaan
CC BY-SA 4.0
2018-05-08T16:00:39.307Z
2018-05-08T16:00:39.307Z
Yakk
<p>I don't see why you restrict your choice to either lie or be pedantic, both of which are negatives.</p>

<p>It is pretty clear that almost all topics in CS are more complex than they seem at first; there always is a small visible surface, and a huge ice berg below. In fact, having a software developer who thinks he knows everything about a topic and has no open mind for further stuff is very hurtful in the real world, it can really wreak havoc in software projects.</p>

<p>Your solution could be as simple as "Today we are looking at the aspect of Java interfaces that makes it so they guarantee that classes implementing them define certain methods." (or whatever better formulation you can come up with). The important point is the "Today we are looking at <em>the aspect of</em> ...", the rest is just part of your irrelevant example.</p>

<p>Any student should pretty easily understand that if we look at one part of a puzzle, there are other parts.</p>

<p>Get them into the habit that you <em>never</em> give them the full picture (because, as the Hitchhiker tells us, that would be too humbling for our sanity...). If you, depending on the age of your audience, have to hammer it in, then preface your lecture by a picture of an iceberg (maybe together with the Titanic for some added humour...).</p>

<p>Also, you could find an exhaustive list of features of your interfaces, and give them a kind of "breadcrumb" somewhere in your presentation (if you are not writing by hand on a board), highlighting the topic of the current session. Even if you lose no word about the other topics, they will be aware that there <em>are</em> other topics. Like "Interfaces: multiple inheritance; <em>abstract method definitions</em>; default code...", if todays session is just about the fact that classes implementing the interfaces have to implement the methods, and that the caller can use the interface as a type if he does not need more information about the concrete classes.</p>

CC BY-SA 4.0
2022-07-06T12:46:12.797Z
@NOTCSEducator, fyi, the link "moved to chat" in your comment points to https://chat.stackexchange.com/rooms/71/the-h-bar , which seems to be something completely different...
AnoE
CC BY-SA 4.0
2018-05-08T08:57:59.790Z
2018-05-08T08:57:59.790Z
AnoE
<p>Just tell them you are trying to explain an important aspect of things, and you have to simplify a bit.</p>
<p>I'm preparing a lecture about iterators in Java, so I use that example.  I tell student that iterable objects <em>must have</em> an iterator method in order to implement the <code>Iterable</code> generic interface</p>
<pre><code>interface Iterable&lt;T&gt; {
    Iterator&lt;T&gt; iterator();
    ...
}
</code></pre>
<p>and iterators have <code>next</code> and <code>hasNext</code></p>
<pre><code>interface Iterator&lt;T&gt; {
   boolean hasNext();
   T       next();
   ...
}
</code></pre>
<p>That's all I want to explain. I don't oversimplify, but I don't want to say a word about <code>forEach</code> and <code>remove</code> and blood-thirsty spliterators from Jurassic Park at this point.  If some students read the documentation and ask questions, I point them to the ellipsis.</p>
<p>But I make clear there are other things, not to be discussed now.</p>
<p>About interfaces, what about telling they were <strong>mostly intended</strong> to list methods to be implemented by concrete classes? It doesn't exclude the presence of other things in the interface.</p>
<hr />
<p>At some point, but much later, it can be interesting to explain why default methods were introduced in Java, whereas it seems a contradiction with their initial intent.</p>
<p>To put it simply, lots of existing code uses the same standard interfaces as, for example, the collections. New features were added to collections interface, like forEach.  But it was not reasonable to ask customers provide implementations of forEach for all their existing classes. So language designers went by that tradeoff.</p>

CC BY-SA 4.0
2018-05-08T07:08:04.843Z
2020-09-28T21:10:50.077Z
2020-09-28T21:10:50.077Z
Michel Billaud
<blockquote>
  <p>unlike abstract classes, interfaces cannot contain any code.</p>
</blockquote>

<p>I don't like the word "lie".</p>

<p>Let's change subjects so you can see what I mean:</p>

<p>It isn't lying to teach children that the atom is the smallest unit, that atoms form molecules and molecules form everything else.</p>

<p>Later, in chemistry class, you can tell them that an atom has a nucleus which is surrounded by electron clouds and that the nucleus is made of protons and neutrons.</p>

<p>Later, in physics class, you can tell them about quarks, gluons, spin, color, etc.</p>

<p>Did you lie in the first statement because you said, <code>smallest unit</code>?<br>
Even though you knew full well that the atom is in fact the <code>smallest constituent unit of matter that has the properties of a chemical element</code>?  </p>

<p>I'd say <code>No</code>.<br>
<em>You are not leaving out stuff to mislead</em>, <strong>you are simplifying to teach the subject clearly</strong>.</p>

<p>However, when a politician does that, I call it a lie :–)</p>

CC BY-SA 4.0
2018-05-12T02:56:01.780Z
This doesn't *quite* answer the question.
Wildcard
CC BY-SA 4.0
2018-05-12T18:09:16.223Z
This is also what the asker is trying to ask about, whether this is ok. And frankly, I disagree with you. We should *not* be teaching children that atoms are the smallest unit; the only reason we do is because that was the state of the art a long time ago. It's not  anymore, and we should stop saying it. Physics in particular is rife with this problem. Students get taught Newtonian gravity as a "Law of Gravity" then hear "Newton was Wrong, Einstein said so" and this decreases trust in science. We should be saying "This was the Newtonian Approximation, it's good enough in most cases."
JKreft
CC BY-SA 4.0
2018-05-15T18:13:32.973Z
This *is* a direct answer to her question.  My belief is that "simplifying a subject to make it easier to learn" is not a lie. So don't feel guilty about it.
J. Chris Compton
CC BY-SA 4.0
2018-05-15T18:40:19.633Z
@JKreft Yes, "Newtonian Approximation", fine - that probably *is* better.
J. Chris Compton
CC BY-SA 4.0
2018-05-15T18:41:34.637Z
Y'all do what you want, but if someone (especially someone that doesn't know calculus) learns "Law of Gravity" and wants to talk to me about it I'm happy to talk. At no point in that conversation will I feel a need to tell them that they are wrong because Einstein. Computer Science is hard enough for most people - don't erect barriers to these students learning, getting a good grade, then *wanting* to learn more.
J. Chris Compton
CC BY-SA 4.0
2018-05-16T13:28:39.327Z
It's not that they want to talk to you about it. It's that they go out of class and say "I was just taught today that everything I thought I knew about gravity was wrong and my middle school teacher lied to me/didn't know better." It turns them off of learning more. As I said, Physics is *especially bad* about being taught as if the last hundred years of advances didn't exist and then re-teaching them "Oh, all that stuff is out of date". It inhibits learning.
JKreft
CC BY-SA 4.0
2019-07-05T02:29:29.130Z
+1 to Lying To Children.  These are college students, though, so don't say "I'm lying to you".  Say, "This is the first approximation needed for Comp Sci 101.  You'll learn more next year."
RonJohn
CC BY-SA 4.0
2018-05-08T17:02:43.300Z
2018-05-08T17:02:43.300Z
J. Chris Compton
<p>I had a similar issue in a class about video coding. There is a set of design decisions, that are quite abstract, and then there are actual codecs. The codecs went on relaxing <em>many</em> constraints of initial theoretical design decisions, because then it works better and yields better compression rate. But it does not make it easier to understand for a beginner.</p>

<p>So, what I caught myself constantly saying was more or less this. I am trying to highlight the key phases.</p>

<blockquote>
  <p>The <strong>generic idea</strong> is that you have an I frame at the beginning of the GOP.
  When you think about a P frame now, <strong>just for understanding</strong>, think that it can reference only a preceding I or P frame. <strong>In practice</strong> it is possible to reference a frame <em>after</em> the P frame. Actually, there are I-, P-, and B-blocks and frames are built out of them. And, like, with H.264 the criteria of a GOP are also relaxed. <strong>This will be discussed in a detail later</strong>, when we get there. But for <strong>a theoretical overview</strong>, that is also <strong>relevant for an exam</strong>, use the generic, theoretical view above. If a question does not specify a concrete codec, you need to use this generic idea of a video codec without exceptions used in concrete implementations.</p>
</blockquote>

<p>And then I also had an exam question of "which frame would reference which" in this "generic ideal video codec".</p>

CC BY-SA 4.0
2018-05-16T14:42:32.190Z
2018-05-16T14:42:32.190Z
Oleg Lobachev
<p>Are you teaching computer science using Java as an exemplar, or are you teaching Java programming skills?</p>

<p>Because when you use a word like "interface", in the one case you will want to discuss the general CS meaning of the concept independent of programming language (let along programming language versions), while in the latter case, students will need at some stage to be aware of the details.</p>

<p>Discussion of the gory detail of Java versions here could detract from your ability to convey the importance of interface definitions in software engineering by isolating components from each other's implementation detail: which I would think is the important thing to be teaching.</p>

CC BY-SA 4.0
2018-05-11T15:37:43.140Z
2018-05-11T15:37:43.140Z
Michael Kay
<p>When teaching Intro CS in Java, I sometimes tell students things that are not entirely true, such as that, unlike abstract classes, interfaces cannot contain any code. (For those of you unfamiliar with Java, that was true until functional interfaces were added with Java 1.8 in 2014.) </p>

<p>I realize I could put an asterisk on the slide, or visibly cross my fingers, and let students know I'm not telling the full story, but, when I witness other instructors allude to irrelevant advanced material, I view them as pedantic and fear that students find the additional information distracting or confusing.</p>

<p>I don't mean to open a debate on the importance of functional interfaces in Java -- they're just an example. What I'd like to know is if it's considered better to gloss over details in an introductory class or to always speak the whole truth.</p>

CC BY-SA 4.0
2018-05-08T01:02:57.290Z
I just learnt that interfaces can contain code - looks like my lecturer went with the lie route! I’m doing the 1st year of a degree.
Tim
CC BY-SA 4.0
2018-05-08T01:09:39.410Z
CS is the art of applying abstractions. You're not "lying", you're *abstracting* away the unnecessary details (for now, of course).
tonysdg
CC BY-SA 4.0
2018-05-08T05:05:36.547Z
Actually it was true until *default methods* were added.
Criticize SE actions means ban
CC BY-SA 4.0
2018-05-08T05:05:57.343Z
And it's not "not entirely true", it's just plain untrue. Instead of saying something so obviously untrue, I would consider "except for default methods, which we'll get into later, interfaces can't contain any code" or "interfaces can't contain any code, with one exception that we'll cover later".
Criticize SE actions means ban
CC BY-SA 4.0
2018-05-08T06:31:18.497Z
If you want to be *really* pedantic, interfaces could contain code way back when (Java 1.1, I think) by means of putting it in a static inner class.
Peter Taylor
CC BY-SA 4.0
2018-05-08T06:58:11.983Z
Everything you have learnt anywhere is somekind of "lie to children"
joojaa
CC BY-SA 4.0
2018-05-08T09:12:15.423Z
@PeterTaylor Given that we're being *really* pedantic: that would be a 'static nested class'. If it's static, it's not an inner class.
Max Barraclough
CC BY-SA 4.0
2018-05-08T10:13:42.717Z
@Tim Honestly, it's very likely that that wasn't deliberate. Many educators don't quite keep up with technology. I still see many treat C++11 as some new fangled thing that'll never catch on, same with anything that was added to Java after 6. And from what I can tell at least in India, many students are _still_ taught with Borland C++.
Cubic
CC BY-SA 4.0
2018-05-08T10:41:20.120Z
@Cubic: Yep, Turbo C++ from the 80s using a DOS emulator! Good times.
Lightness Races in Orbit
CC BY-SA 4.0
2018-05-08T11:46:57.300Z
Maybe you can mention in the beginning that not all things that you explain are exactly such but you simplify them for easy understanding.
i486
CC BY-SA 4.0
2018-05-08T19:38:38.260Z
Perhaps instead of explaining the what, explain the why? Something along the lines of "Interfaces are used to define common behaviors between all of their implementors, but because the details can greatly differ they usually do not contain code" Then you could show an example how default methods can be used to do something like "add if not present" but the add method and contains method must be defined by the implementor.
Captain Man
CC BY-SA 4.0
2018-05-09T00:14:46.553Z
I tend to couch things in terms of "mostly" and "sometimes" and "depending on exactly what version of...", especially in areas of flux (ie, teaching Linux admin and referencing Debian 8, Ubuntu 16.04, Debian 9, and Ubuntu 18.04 and initialization, the use of `ip` vs `ifconfig` and `route`, etc.)  I think the Science Of Discword explained it - this Discworld wiki gives a nice summary of "Lies to Children", which this is qualifying as... https://wiki.lspace.org/mediawiki/Lies-To-Children
ivanivan
CC BY-SA 4.0
2018-05-09T13:08:19.950Z
"unlike abstract classes, interfaces cannot contain any code" - My CS1 professor said the same. Problem is, I had my OCJP when I took his class. I told him about `default` in Java 8, which he did not know about. He later added an asterisk and a small footnote explaining the Java 8 update and adding "generally..." to his statement. I thought it was a good solution.
Strikegently
CC BY-SA 4.0
2018-05-09T16:37:16.517Z
I suggest the formulation "For now, please assume that..."
Aaron Brick
CC BY-SA 4.0
2018-05-09T18:06:02.657Z
Do definitions and signatures not count as code?
Kyle Delaney
CC BY-SA 4.0
2018-05-09T20:37:06.637Z
@KyleDelaney In a sense they are, but in many contexts such as this one or when counting lines of code they are not (typically).
Shelby115
CC BY-SA 4.0
2018-05-10T00:56:34.200Z
You can *omit* whatever you want (# @title rant). But never lie to anyone about anything if your goal is the exchange of knowledge.
Mazura
CC BY-SA 4.0
2018-05-10T04:09:01.427Z
Why not say, "Interfaces cannot contain **state**" or "interfaces cannot contain fields?" That's the real difference between them and abstract classes. Maybe also say, "They usually don't contain code."
Brian McCutchon
CC BY-SA 4.0
2018-05-10T13:49:08.513Z
This is an example of: https://en.wikipedia.org/wiki/Lie-to-children
borjab
CC BY-SA 4.0
2018-05-10T19:10:57.293Z
>Macleod and Ross wrote: "Playing devil's advocate is in itself a challenging notion for many learners, who may, especially in their early years of higher education, be conditioned by what Stewart and Cohen call 'lies to children' to expect simple and unambiguous questions and equally simple answers."< ... *Only you can prevent millennials.*
Mazura
CC BY-SA 4.0
2018-05-10T19:43:41.473Z
Dangit, I meant declarations, not definitions. Common mistake.
Kyle Delaney
CC BY-SA 4.0
2018-05-10T21:38:07.137Z
The Lie-to-Children paradigm is pervasive in education. In elementary school you learn that the sky is blue. In high school you learn that the sky appears blue because the atmosphere is blue. At university, you learn that the atmosphere filters out non-blue light to a greater extent than blue light. In grad school, you are led to wonder what the defintion of "blue" was anyway, the historical context of defining the sky as blue, and what the likely social, economic, and political ramifications of a non-blue sky would be. During your PhD, you claim that the sky is mauve and defend your model.
Robert Columbia
CC BY-SA 4.0
2018-05-10T21:57:15.270Z
Start the year with a disclaimer.  'Coding is a living art.  I will tell you some things cannot be done - then someone will come along and DO them!  And that's great.  Every impossibility is a challenge!  Just bear with me, let me teach you stuff that definitely CAN be done for now.'
Laurence
CC BY-SA 4.0
2018-05-11T19:24:49.460Z
Do you forbid code using topics not yet covered in class? Plenty of my programming classes wouldn't allow functions until covered for example... "You CAN do that... but you're not allowed to in submitted code until/unless it's covered in class"
WernerCD
CC BY-SA 4.0
2018-05-11T19:38:23.167Z
Don't "lie" to your students: they are little bit older than 5. Either put a disclaimer that "technically you can do this but we would not cover that right now" or update your course (Yes CS stuff changes really fast). I don't know how your students but we were checking everything our professors told us and if we would find out that she/he doesn't know his stuff... Well.. the fact that "he doesn't know anything" passed from year to year was the least of the problems. Some students were complaining to university management about such "professors" and university took an action on one of such.
AlexanderM
CC BY-SA 4.0
2018-05-12T05:45:34.407Z
Why do you want to stick with "cannot" instead of saying something like "should not"?  Is it to stick with a textbook or other teaching materials that aren't up to date?  It seems like a bad practice to me.  If a student later comes across this and remember what you said it will make them wonder what else you told them isn't "entirely true" either.
Jason Goemaat
CC BY-SA 4.0
2018-05-12T12:03:03.587Z
Some lies are okay, some other lies aren't. For example, professors I know have taught students that reading the value of an uninitialized local variable in C and C++ will evaluate to "whatever garbage was in that place in memory". That's a *disastrous* lie if you are teaching these languages seriously. Regarding the Java interfaces thing, I'd say the lie is generally harmless.
Theodoros Chatzigiannakis
CC BY-SA 4.0
2018-05-12T12:05:47.943Z
Whenever you're lying, however, remember that your students *look up to you.* I've seen a lot of students who live by the words of their teachers for many years after graduation, and they may even dismiss new information that contradicts what their teacher said (until someone with *much higher authority* tells them otherwise). That's my strongest reservation when it comes to lying.
Theodoros Chatzigiannakis
CC BY-SA 4.0
2018-05-13T05:01:30.120Z
*"Is it better to lie to students or to be pedantic when teaching Intro CS?"* Porque no los dos? :-)
user541686
CC BY-SA 4.0
2018-05-13T09:14:09.380Z
An insignificant inaccuracy can save a lengthy explanation.
dotancohen
CC BY-SA 4.0
2018-05-13T23:14:15.207Z
It's better to lie - and don't make a note of it - at the time. This is true of all teaching. As you go deeper into it, you can revisit, and expose, those lies.
Strawberry
CC BY-SA 4.0
2018-05-15T06:43:12.833Z
Related: [CppCon 2015: Kate Gregory “Stop Teaching C"](https://www.youtube.com/watch?v=YnWhqhNdYyk)
moooeeeep
CC BY-SA 4.0
2018-05-18T14:53:59.113Z
@AlexanderM The issue isn't being willing to update my course. It's not wanting to confuse students by introducing more information than is needed. Intro CS classes tend to have high drop-out/failure rates, so I don't want to front load content that stronger students can get in later courses.
Ellen Spertus
CC BY-SA 4.0
2019-03-02T16:50:04.617Z
_functional interfaces were added with Java 1.8_ — **Corollary:** Java's "functional interfaces" are not interfaces. (This looks like an example of the [red herring principle](https://ncatlab.org/nlab/show/red+herring+principle).)
JeffE
CC BY-SA 4.0
2020-09-28T07:35:52.830Z
I love this question! Have you seen https://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EWD480.html ? Particularly the para starting : "This disastrous blending"...  I'm also sad to see from [meta](https://cseducators.meta.stackexchange.com/questions/481/users-shouldnt-be-told-theyre-asking-the-wrong-question) that you're considering dropping out of here. I wish — if only because this is a very dear-to-me question! — that you'll stay to discuss this (though yes, it's true for serious important questions SE is particularly badly misfitted)
Rushi
CC BY-SA 4.0
2021-08-19T19:08:28.360Z
my God this is a genius question that needs to be asked for the teaching of maths, physics, chemistry, biology etc. there are so many lie vs pedantic cases there
BCLC
CC BY-SA 4.0
2022-06-10T05:11:36.347Z
"such as that, unlike abstract classes, interfaces cannot contain any code." but why would you need to say that?
Dikran Marsupial
<best-practice>
Is it better to lie to students or to be pedantic when teaching Intro CS?
# Is it better to lie to students or to be pedantic when teaching Intro CS?

(Asked by: username_0 on 2018-05-07)

When teaching Intro CS in Java, I sometimes tell students things that are not entirely true, such as that, unlike abstract classes, interfaces cannot contain any code. (For those of you unfamiliar with Java, that was true until functional interfaces were added with Java 1.8 in 2014.)

I realize I could put an asterisk on the slide, or visibly cross my fingers, and let students know I'm not telling the full story, but, when I witness other instructors allude to irrelevant advanced material, I view them as pedantic and fear that students find the additional information distracting or confusing.

I don't mean to open a debate on the importance of functional interfaces in Java -- they're just an example. What I'd like to know is if it's considered better to gloss over details in an introductory class or to always speak the whole truth.

**Tags:** best-practice

> **Comments:**
> **username_1**: I just learnt that interfaces can contain code - looks like my lecturer went with the lie route! I’m doing the 1st year of a degree.  
> **username_2**: CS is the art of applying abstractions. You're not "lying", you're *abstracting* away the unnecessary details (for now, of course).  
> **username_3**: Actually it was true until *default methods* were added.  
> **username_3**: And it's not "not entirely true", it's just plain untrue. Instead of saying something so obviously untrue, I would consider "except for default methods, which we'll get into later, interfaces can't contain any code" or "interfaces can't contain any code, with one exception that we'll cover later".  
> **username_4**: If you want to be *really* pedantic, interfaces could contain code way back when (Java 1.1, I think) by means of putting it in a static inner class.  
> **username_5**: Everything you have learnt anywhere is somekind of "lie to children"  
> **username_6**: @PeterTaylor Given that we're being *really* pedantic: that would be a 'static nested class'. If it's static, it's not an inner class.  
> **username_7**: @username_1 Honestly, it's very likely that that wasn't deliberate. Many educators don't quite keep up with technology. I still see many treat C++11 as some new fangled thing that'll never catch on, same with anything that was added to Java after 6. And from what I can tell at least in India, many students are _still_ taught with Borland C++.  
> **username_8**: @username_7: Yep, Turbo C++ from the 80s using a DOS emulator! Good times.  
> **username_9**: Maybe you can mention in the beginning that not all things that you explain are exactly such but you simplify them for easy understanding.  
> **username_10**: Perhaps instead of explaining the what, explain the why? Something along the lines of "Interfaces are used to define common behaviors between all of their implementors, but because the details can greatly differ they usually do not contain code" Then you could show an example how default methods can be used to do something like "add if not present" but the add method and contains method must be defined by the implementor.  
> **username_11**: I tend to couch things in terms of "mostly" and "sometimes" and "depending on exactly what version of...", especially in areas of flux (ie, teaching Linux admin and referencing Debian 8, Ubuntu 16.04, Debian 9, and Ubuntu 18.04 and initialization, the use of `ip` vs `ifconfig` and `route`, etc.)  I think the Science Of Discword explained it - this Discworld wiki gives a nice summary of "Lies to Children", which this is qualifying as... https://wiki.lspace.org/mediawiki/Lies-To-Children  
> **username_12**: "unlike abstract classes, interfaces cannot contain any code" - My CS1 professor said the same. Problem is, I had my OCJP when I took his class. I told him about `default` in Java 8, which he did not know about. He later added an asterisk and a small footnote explaining the Java 8 update and adding "generally..." to his statement. I thought it was a good solution.  
> **username_13**: I suggest the formulation "For now, please assume that..."  
> **username_14**: Do definitions and signatures not count as code?  
> **username_15**: @KyleDelaney In a sense they are, but in many contexts such as this one or when counting lines of code they are not (typically).  
> **username_16**: You can *omit* whatever you want (# @title rant). But never lie to anyone about anything if your goal is the exchange of knowledge.  
> **username_17**: Why not say, "Interfaces cannot contain **state**" or "interfaces cannot contain fields?" That's the real difference between them and abstract classes. Maybe also say, "They usually don't contain code."  
> **username_18**: This is an example of: https://en.wikipedia.org/wiki/Lie-to-children  
> **username_16**: >Macleod and Ross wrote: "Playing devil's advocate is in itself a challenging notion for many learners, who may, especially in their early years of higher education, be conditioned by what Stewart and Cohen call 'lies to children' to expect simple and unambiguous questions and equally simple answers."< ... *Only you can prevent millennials.*  
> **username_14**: Dangit, I meant declarations, not definitions. Common mistake.  
> **username_19**: The Lie-to-Children paradigm is pervasive in education. In elementary school you learn that the sky is blue. In high school you learn that the sky appears blue because the atmosphere is blue. At university, you learn that the atmosphere filters out non-blue light to a greater extent than blue light. In grad school, you are led to wonder what the defintion of "blue" was anyway, the historical context of defining the sky as blue, and what the likely social, economic, and political ramifications of a non-blue sky would be. During your PhD, you claim that the sky is mauve and defend your model.  
> **username_20**: Start the year with a disclaimer.  'Coding is a living art.  I will tell you some things cannot be done - then someone will come along and DO them!  And that's great.  Every impossibility is a challenge!  Just bear with me, let me teach you stuff that definitely CAN be done for now.'  
> **username_21**: Do you forbid code using topics not yet covered in class? Plenty of my programming classes wouldn't allow functions until covered for example... "You CAN do that... but you're not allowed to in submitted code until/unless it's covered in class"  
> **username_22**: Don't "lie" to your students: they are little bit older than 5. Either put a disclaimer that "technically you can do this but we would not cover that right now" or update your course (Yes CS stuff changes really fast). I don't know how your students but we were checking everything our professors told us and if we would find out that she/he doesn't know his stuff... Well.. the fact that "he doesn't know anything" passed from year to year was the least of the problems. Some students were complaining to university management about such "professors" and university took an action on one of such.  
> **username_23**: Why do you want to stick with "cannot" instead of saying something like "should not"?  Is it to stick with a textbook or other teaching materials that aren't up to date?  It seems like a bad practice to me.  If a student later comes across this and remember what you said it will make them wonder what else you told them isn't "entirely true" either.  
> **username_24**: Some lies are okay, some other lies aren't. For example, professors I know have taught students that reading the value of an uninitialized local variable in C and C++ will evaluate to "whatever garbage was in that place in memory". That's a *disastrous* lie if you are teaching these languages seriously. Regarding the Java interfaces thing, I'd say the lie is generally harmless.  
> **username_24**: Whenever you're lying, however, remember that your students *look up to you.* I've seen a lot of students who live by the words of their teachers for many years after graduation, and they may even dismiss new information that contradicts what their teacher said (until someone with *much higher authority* tells them otherwise). That's my strongest reservation when it comes to lying.  
> **username_25**: *"Is it better to lie to students or to be pedantic when teaching Intro CS?"* Porque no los dos? :-)  
> **username_26**: An insignificant inaccuracy can save a lengthy explanation.  
> **username_27**: It's better to lie - and don't make a note of it - at the time. This is true of all teaching. As you go deeper into it, you can revisit, and expose, those lies.  
> **username_28**: Related: [CppCon 2015: Kate Gregory “Stop Teaching C"](https://www.youtube.com/watch?v=YnWhqhNdYyk)  
> **username_0**: @username_22 The issue isn't being willing to update my course. It's not wanting to confuse students by introducing more information than is needed. Intro CS classes tend to have high drop-out/failure rates, so I don't want to front load content that stronger students can get in later courses.  
> **username_29**: _functional interfaces were added with Java 1.8_ — **Corollary:** Java's "functional interfaces" are not interfaces. (This looks like an example of the [red herring principle](https://ncatlab.org/nlab/show/red+herring+principle).)  
> **username_30**: I love this question! Have you seen https://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EWD480.html ? Particularly the para starting : "This disastrous blending"...  I'm also sad to see from [meta](https://cseducators.meta.stackexchange.com/questions/481/users-shouldnt-be-told-theyre-asking-the-wrong-question) that you're considering dropping out of here. I wish — if only because this is a very dear-to-me question! — that you'll stay to discuss this (though yes, it's true for serious important questions SE is particularly badly misfitted)  
> **username_31**: my God this is a genius question that needs to be asked for the teaching of maths, physics, chemistry, biology etc. there are so many lie vs pedantic cases there  
> **username_32**: "such as that, unlike abstract classes, interfaces cannot contain any code." but why would you need to say that?  

---

## 15 answers

### Answer by username_43 on 2018-05-07. Score: 184 | Accepted answer

Lying is good. But advertise it when you lie. Make sure students make a note of it that you are lying.
Pedantic is bad. If you try to explain everything you will wind up explaining nothing. Let me take a simpler example. In java we have a special incantation
public static void main(String [] args)

We put it in every program. It distinguishes a program. But if you start your java course explaining every part of it you will (a) confuse the juices out of them and (b) never get to the point of writing a useful program. For the beginner, it is just an incantation like
Riddikulus; // used in defence against a Boggart.

The Java code is just a "charm" for the beginner. All you need to say is that it is a "hook" for the OS to find its way into your program. Explain it later after you've taken up some of its elements for other purposes.
Beginners need a simple but coherent view of their language and system. When you simplify, work hard to keep it consistent. But it doesn't need to be complete and certainly not exhaustive.
When you are giving an "overly" simplified view, say that explicitly. Have the students mark their notes with an asterisk (or the above charm) so that they know it isn't complete. If you are explicitly asked for "the rest of the story" you have to decide whether it will help to include it (after the commercial break, of course) or to defer it or to enlighten the students out of the class context (email, say), or give a reference for those who "will not be denied."
I used to start some discussions with "I'm about to lie to you, but it will be helpful if you accept my lie for a bit". Of course I had to remember to come back an fill in the blanks  later, but it might not be for a while. Complex, inter-dependent topics are like that.
tl;dr: Lie, but honestly and truthfully.
And, perhaps the most important caveat, don't lie in such a way that the student later needs to unlearn something. Lying is giving partial truths, or temporary world views, not sending students into mental blind alleys and backwaters. Withholding some facts may be necessary and valuable as is presenting an incomplete metaphor. UnLearning should never be part of learning.
I'll also note that infants learn to speak a native language without everything being explained to them before they begin. The deeper understanding comes to them only gradually and over time. We are actually conditioned by evolution to work this way.

Added in June 2022. Today's Dinosaur Comics gives a good illustration of this. Note that Ryan North, the creator of Dinosaur Comics has a masters in CS.

> **Comments:**
> **username_44**: Note that it's not just CS where this applies.  Physics professors should prefix any discussion of friction with "This is the greatly simplified version of things.  If you want more detail, plan to get your doctorate in the subject."  
> **username_45**: Some say `public static void main(String[] args)` is the most powerful spell of all. The results are only limited by your imagination!  
> **username_8**: `public static void main(String[] args)` is the entrypoint for a frictionless, perfectly spherical Java program  
> **username_46**: Assume a spherical cow.jar in a vacuum.  
> **username_47**: Related: [lie-to-children](https://en.wikipedia.org/wiki/Lie-to-children), "a simplified explanation of technical or complex subjects as a teaching method for children and laypeople".  
> **username_2**: +1 for a great answer, and props for figuring out how to add a Harry Potter reference!  
> **username_48**: @LightnessRacesinOrbit: Java programs are never frictionless, but in their natural state with mass approaching infinity, they do approach becoming perfectly spherical.  
> **username_11**: @PabloH I much prefer the Discworld version :)  It includes "Lies to Wizards".  Being made by a computer. https://wiki.lspace.org/mediawiki/Lies-To-Children  
> **username_49**: @username_44 Mathematics, also. We definitely don't want to say things to first graders like, "In studying addition we are really looking at an Abelian group (which will later be extended to a field by adding a second operator). Some of you may be questioning whether it's truly a group and what the cardinality of the underlying set is, due to your current understanding of numbers. So we will answer those questions by expanding our discussion to countably infinite sets and additive inverses."  
> **username_50**: It may not be a bad idea to be pedantic *once*, as an explanation for why you aren't always going to go into detail. It also gives you a way to derail a student who wants to dig into the details at an inappropriate moment - they can check back during office hours (or whatever) if they want more detail.  
> **username_51**: @PabloH has the correct idea.  My own preference is _abstraction_ in the CS sense, alternatively:  "A _Wittgenstein's ladder_ is a simplified explanation of a technical or complex subject that is used as a teaching tool, despite being technically wrong." (cf wikipedia)  
> **username_52**: @username_45 And your computer memory and processing speed.  
> **username_53**: @ToddWilcox There is an algebraic structure called near-ring where addition does not need to be an Abelian group, https://en.wikipedia.org/wiki/Near-ring . Or was the idea that one lies to students that addition must be commutative?  
> **username_54**: "don't lie in such a way that the student later needs to unlearn something" -- Most important sentence in this answer, and often violated.  
> **username_54**: "I'll also note that infants learn to speak a native language without everything being explained to them before they begin" -- True. But: that takes years (decades, even) and regularly fails to produce speakers/writers with full command of their native tongue. Neither is really acceptable in (CS) education.  
> **username_55**: I broadly used the term "black magic" for parts of the boilerplate in a program people don't need to understand yet, but are asked to blindly copy for now.  
> **username_56**: +1 My boggart is a professor that leaves out details and makes no mention of the omission.  
> **username_57**: @ToddWilcox if you know a first grade teacher who knows abstract algebra, I'd love to meet them.  
> **username_58**: I wonder if an honest lie is a lie at all :D This is another topic, but I like the way you put it in catchy terms. I also like the overall attitude towards (learning) human beings which is evident in your text. +1! @username_43  
> **username_32**: It's funny, learning charms at Hogwarts is what I tell my students that programming is emphatically not, and that there is an underlying logic and structure to programming languages, which they should aim to learn....  But that they can't learn it all at once so they have accept some boilerplate at the start, but they shouldn't be comfortable with that in the long run.  I would say "never lie", you don't need to be pedantic to avoid lying, you just don't need to tell all the truth at once.  

---

### Answer by username_37 on 2018-05-08. Score: 95

I would start sentences with "Generally speaking..." and I would appreciate if my professors did the same. It hints that there is more to know but doesn't waste time explaining anything further. If your students are curious enough they can raise their hand to inquire. If it takes too much time to explain during class and someone wants to know, you can offer more of your time during your office hours.

Nobody likes being lied to.

The phrase "generally speaking", does not imply that you are lying, it just points out that it is the most common case of something. You could also begin sentences with "Typically..."

In that particular example, you don't have to say "cannot", you could say they "typically don't".

"Generally speaking, interfaces do not contain any code." It shouldn't be more complicated than that.

> **Comments:**
> **username_38**: Welcome to [cseducators.se]. Great suggestion. I hope we'll see more ideas from you on the site.  
> **username_39**: Good suggestion, it gracefully deals with a huge problem in 2 words :) "As a rule"/"As a general rule" could also be used in the same place.  
> **username_40**: This is good. I was advanced for my course and when teacher "lied" I thought it was because they didn't know better. If they said "generally speaking" it peaked my curiosity to look at it further.  
> **username_41**: The phrase "generally speaking" is great, because it invites a student to treat something applies in the cases that are going to follow, but discourages excessive inferences that might lead the student astray.  
> **username_42**: +1 I'd suggest "should not" over "do not" - that way it begins to act as a red-flag to highlight a potentially bad programming practice.   There will be times it may be the right thing to do, but it then leads the students to check that code carefully and encourage them to justify their actions if/when they do so.  

---

### Answer by username_62 on 2018-05-08. Score: 39

As a current CS student, my lecturer use to solve this by simply using **For now**.

To come back to your interface example:

For now, interfaces cannot contain any code, unlike abstract classes.

This gives a clear message, there is more to the topic, but it isn't relevant at the moment. When students ask you can always elaborate a little bit, but for the most questions I think this will be sufficient.

> **Comments:**
> **username_63**: You could also say up front that the course will be teaching Java 1.5 (or whatever fixed version).  Then extensions in newer versions can be covered in the last lecture.  
> **username_42**: My only concern is that 'for now' is invariably an invitation to some smart-alec to do it.  
> **username_64**: @JamesSnell Speaking as a lifelong smart-alec I can assure you that I need no invitation. Pretending no one is hiding behind the curtain will only result in me pulling on your drapes. However, a "don't worry about that for now" and a conspicuous wink will put a smile on my face and keep my butt in my seat.  

---

### Answer by username_65 on 2018-05-08. Score: 17

> unlike abstract classes, interfaces generally do not contain any code

This is not a lie. In a large lecture hall, if they ask for "when do they contain code", say "that will be covered in another class" to avoid going off on a (possibly confusing) tangent.

This is *neither* lying, but it is glossing over details. There are situations where lying is a good plan, but they are few and far between (for example, when you teach Newtonian physics, always qualifying every statement with "at velocities far below the speed of light" would get tedious quickly).

Telling a lie should be avoided for a few reasons. First, your students may believe your lie and get confused later. Second, they may catch you in a lie, and lose confidence in everything else you are saying or get confused because of the lie.

Finally, not-lies but glossing over (with words like "generally") leave places for students who are extra eager to look into it themselves. If you lied they wouldn't know where to start looking, but by implicitly leaving a sign saying "there are more details here" you can recruit some student self-motivation to do your work (educating them) for you.

> **Comments:**
> **username_66**: To be fair, students "losing confidence" can be a good thing - if it leads them to being critical of everything they learned, they can *do better*. It can also help them learn in the first place, by making things more interesting. But that's probably a minority (at least in modern school systems); most people will carry their misconceptions to the grave (or the next serious project where this lie actually matters :P).  
> **username_67**: @username_66, your comment is a good example of false information (a lie).  No, it is *not* a good thing to make your students lose confidence.  
> **username_66**: @username_67 That's why the *if* is there - I'm not saying you should try it on purpose (or keep teachers that are horrible). It's more like a final consolation than a study plan :) But I guess it could be worded differently - it's a good thing if students don't take their teacher as an authority. That doesn't mean quite the same thing as "ignore that stupid old fart" - a teacher that isn't afraid to admit he doesn't understand or know something is a great bonus. Not assuming everything you say is right just because you're a teacher really leads to *more* confidence.  

---

### Answer by username_35 on 2018-05-08. Score: 11

I must say, I largely agree with the posters so far. The principle of lying with your fingers crossed is a good one. *However*, I have two caveats, and I believe that they are important.

**First, I have a small bone to pick with something [/u/SlyFiye said](https://cseducators.stackexchange.com/a/4720/27):**

> For what its worth, I appreciate the honesty when my instructor uses crossed fingers .... I will treat knowledge given to me in this manner as **practical use advice and not grounded principle.**

(emphasis mine)

It seems to me that this is exactly backwards. The reason to give an incomplete picture is to allow students to absorb important grounding principled before adding wrinkles and complexities. This is what motivates the entire enterprise.

**Second, the principle is one for** ***usually,*** **and not for** ***always.***

I've repeatedly observed in my own classroom that, if my students are already somewhat lost in a complex topic, even hinting that there might be more complexity beneath the surface causes them to completely lose the topic. It has been consistent enough that I am utterly convinced that this effect is real, and we need to treat it with care.

I have two brain-based theories for why this might be. I have not found any research to support (or detract) from these theories, but they could both well explain the phenomenon:

1. **Simple de-motivation.** Upon hearing that this *very hard thing* that they are faced with is partially false, the student simply despairs and gives up. Why do all of the hard work to understand something that isn't even true?
2. **Brain-scrambles.** What happens in a student's brain when they hear that there is more to the story may not exactly be the blank *"okay, there will be more later"* that we might hope for. Instead, what might happen is a series of rapid mental transitions, in which the student mentally loops through the components of what they have learned and tries to guess at *which part* might not be true, exactly, and what that truth might be. This involves a sort of miniature cognitive scramble at each pass. *"Okay, so if* ***this*** *part isn't true, then maybe things don't quite connect the way I've just been shown."*

   The reason that this matters is that, if the connections in your student's brain are already quite tenuous, the process of scrambling can muck everything up.

   When faced with the revelation that the topic has even more to it, confused students *still go through that same mental process described above*, but what comes out of it is essentially spaghetti. That tiny, inchoate thread that they were constructing about your topic will simply come apart.

Regardless of the reason, if my students are already confused, I have found it better to hold off on even mentioning that the material is really more complex. Give the students a chance to try to get a handle on the ideas you have placed before them before inviting them entertain any further complexity.

You can come back around and fix things later. Or not. I actually take a rather dim view of making sure that every statement is always fully accurate. Sometimes insisting on total accuracy can pull your students deep enough into the weeds that they simply get lost, and never fully notice the giant statue that you were trying to point them to.

I stand by what I said at the beginning; crossing your fingers is usually the best way to go. But sometimes it can be more effective to choose your battles and let sleeping monsters lie.

> **Comments:**
> **username_43**: "...choose your battles and let sleeping monsters lie". OTOH, if the road ahead is twisty and has obstacles it is good to put up a warning sign. If students think it is going to be easy, they may wind up blaming their own skills when it turns out harder than they expected. In fact, the topic at hand may be inherently difficult, even for the professionals.  

---

### Answer by username_59 on 2018-05-08. Score: 11

I would suggest saying "for the purposes of this class" or something along those lines to make it clear that while it may not be true, they can take it as truth, and that they don't need to learn the obscure case where it isn't as a hope for an surprise question or the like, similarly to how when teaching elementary physics you would typically ignore wind resistance and relativistic effects

> **Comments:**
> **username_0**: I think this is a good answer but probably not one that should be applied to other contexts. For example, one shouldn't preface a lie to one's spouse with "for the purposes of our marriage". ;-)  
> **username_59**: @EllenSpertus I figured this being CS educators and not interpersonal or something along those lines, the context would limit the scope of the answer enough  
> **username_60**: For the purposes of this website...  

---

### Answer by username_61 on 2018-05-08. Score: 9

> Tell all the truth but tell it slant —  
> Success in Circuit lies  
> Too bright for our infirm Delight  
> The Truth's superb surprise  
> As Lightning to the Children eased  
> With explanation kind  
> The Truth must dazzle gradually  
> Or every man be blind —

Emily Dickinson, poem number 1129 in *[Complete Poems](https://www.amazon.co.uk/Complete-Poems-Emily-Dickinson/dp/143957183X/ref=tmm_hrd_title_0?_encoding=UTF8&qid=&sr=)*

Dijkstra often mentions the limited size of our skulls, so maybe you could make a remark at the start of your teaching that you cannot possibly convey all of the subtleties of every topic and you are going to have to abbreviate to begin teaching somewhere. This is the opposite of my favorite principle: **The Sweater Effect**: just start pulling anywhere, and sooner or later the entire thing will come unraveled.

I guess we could call your issue, **The Enlightenment Effect**. Sometimes it is referred to as "Lies to Children."


---

### Answer by username_70 on 2018-05-08. Score: 8

> unlike abstract classes, interfaces cannot contain any code.

I don't like the word "lie".

Let's change subjects so you can see what I mean:

It isn't lying to teach children that the atom is the smallest unit, that atoms form molecules and molecules form everything else.

Later, in chemistry class, you can tell them that an atom has a nucleus which is surrounded by electron clouds and that the nucleus is made of protons and neutrons.

Later, in physics class, you can tell them about quarks, gluons, spin, color, etc.

Did you lie in the first statement because you said, `smallest unit`?  
Even though you knew full well that the atom is in fact the `smallest constituent unit of matter that has the properties of a chemical element`?

I'd say `No`.  
*You are not leaving out stuff to mislead*, **you are simplifying to teach the subject clearly**.

However, when a politician does that, I call it a lie :–)

> **Comments:**
> **username_67**: This doesn't *quite* answer the question.  
> **username_71**: This is also what the asker is trying to ask about, whether this is ok. And frankly, I disagree with you. We should *not* be teaching children that atoms are the smallest unit; the only reason we do is because that was the state of the art a long time ago. It's not  anymore, and we should stop saying it. Physics in particular is rife with this problem. Students get taught Newtonian gravity as a "Law of Gravity" then hear "Newton was Wrong, Einstein said so" and this decreases trust in science. We should be saying "This was the Newtonian Approximation, it's good enough in most cases."  
> **username_70**: This *is* a direct answer to her question.  My belief is that "simplifying a subject to make it easier to learn" is not a lie. So don't feel guilty about it.  
> **username_70**: @username_71 Yes, "Newtonian Approximation", fine - that probably *is* better.  
> **username_70**: Y'all do what you want, but if someone (especially someone that doesn't know calculus) learns "Law of Gravity" and wants to talk to me about it I'm happy to talk. At no point in that conversation will I feel a need to tell them that they are wrong because Einstein. Computer Science is hard enough for most people - don't erect barriers to these students learning, getting a good grade, then *wanting* to learn more.  
> **username_71**: It's not that they want to talk to you about it. It's that they go out of class and say "I was just taught today that everything I thought I knew about gravity was wrong and my middle school teacher lied to me/didn't know better." It turns them off of learning more. As I said, Physics is *especially bad* about being taught as if the last hundred years of advances didn't exist and then re-teaching them "Oh, all that stuff is out of date". It inhibits learning.  
> **username_72**: +1 to Lying To Children.  These are college students, though, so don't say "I'm lying to you".  Say, "This is the first approximation needed for Comp Sci 101.  You'll learn more next year."  

---

### Answer by username_68 on 2018-05-08. Score: 6

I don't see why you restrict your choice to either lie or be pedantic, both of which are negatives.

It is pretty clear that almost all topics in CS are more complex than they seem at first; there always is a small visible surface, and a huge ice berg below. In fact, having a software developer who thinks he knows everything about a topic and has no open mind for further stuff is very hurtful in the real world, it can really wreak havoc in software projects.

Your solution could be as simple as "Today we are looking at the aspect of Java interfaces that makes it so they guarantee that classes implementing them define certain methods." (or whatever better formulation you can come up with). The important point is the "Today we are looking at *the aspect of* ...", the rest is just part of your irrelevant example.

Any student should pretty easily understand that if we look at one part of a puzzle, there are other parts.

Get them into the habit that you *never* give them the full picture (because, as the Hitchhiker tells us, that would be too humbling for our sanity...). If you, depending on the age of your audience, have to hammer it in, then preface your lecture by a picture of an iceberg (maybe together with the Titanic for some added humour...).

Also, you could find an exhaustive list of features of your interfaces, and give them a kind of "breadcrumb" somewhere in your presentation (if you are not writing by hand on a board), highlighting the topic of the current session. Even if you lose no word about the other topics, they will be aware that there *are* other topics. Like "Interfaces: multiple inheritance; *abstract method definitions*; default code...", if todays session is just about the fact that classes implementing the interfaces have to implement the methods, and that the caller can use the interface as a type if he does not need more information about the concrete classes.

> **Comments:**
> **username_68**: @NOTCSEducator, fyi, the link "moved to chat" in your comment points to https://chat.stackexchange.com/rooms/71/the-h-bar , which seems to be something completely different...  

---

### Answer by username_69 on 2018-05-08. Score: 5

Just tell them you are trying to explain an important aspect of things, and you have to simplify a bit.
I'm preparing a lecture about iterators in Java, so I use that example.  I tell student that iterable objects must have an iterator method in order to implement the Iterable generic interface
interface Iterable {
    Iterator iterator();
    ...
}

and iterators have next and hasNext
interface Iterator {
   boolean hasNext();
   T       next();
   ...
}

That's all I want to explain. I don't oversimplify, but I don't want to say a word about forEach and remove and blood-thirsty spliterators from Jurassic Park at this point.  If some students read the documentation and ask questions, I point them to the ellipsis.
But I make clear there are other things, not to be discussed now.
About interfaces, what about telling they were mostly intended to list methods to be implemented by concrete classes? It doesn't exclude the presence of other things in the interface.

At some point, but much later, it can be interesting to explain why default methods were introduced in Java, whereas it seems a contradiction with their initial intent.
To put it simply, lots of existing code uses the same standard interfaces as, for example, the collections. New features were added to collections interface, like forEach.  But it was not reasonable to ask customers provide implementations of forEach for all their existing classes. So language designers went by that tradeoff.


---

### Answer by username_55 on 2018-05-16. Score: 3

I had a similar issue in a class about video coding. There is a set of design decisions, that are quite abstract, and then there are actual codecs. The codecs went on relaxing *many* constraints of initial theoretical design decisions, because then it works better and yields better compression rate. But it does not make it easier to understand for a beginner.

So, what I caught myself constantly saying was more or less this. I am trying to highlight the key phases.

> The **generic idea** is that you have an I frame at the beginning of the GOP.
> When you think about a P frame now, **just for understanding**, think that it can reference only a preceding I or P frame. **In practice** it is possible to reference a frame *after* the P frame. Actually, there are I-, P-, and B-blocks and frames are built out of them. And, like, with H.264 the criteria of a GOP are also relaxed. **This will be discussed in a detail later**, when we get there. But for **a theoretical overview**, that is also **relevant for an exam**, use the generic, theoretical view above. If a question does not specify a concrete codec, you need to use this generic idea of a video codec without exceptions used in concrete implementations.

And then I also had an exam question of "which frame would reference which" in this "generic ideal video codec".


---

### Answer by username_73 on 2018-05-11. Score: 2

Are you teaching computer science using Java as an exemplar, or are you teaching Java programming skills?

Because when you use a word like "interface", in the one case you will want to discuss the general CS meaning of the concept independent of programming language (let along programming language versions), while in the latter case, students will need at some stage to be aware of the details.

Discussion of the gory detail of Java versions here could detract from your ability to convey the importance of interface definitions in software engineering by isolating components from each other's implementation detail: which I would think is the important thing to be teaching.


---

### Answer by username_33 on 2018-05-13. Score: 1

The problem with simplifying-by-lie is in the consequences it can have when your student faces practical, real world code development or maintenance situations as a beginner:

* When trying to find out the cause of a bug, they might discount the possibility of something that you said is impossible, and thus not check for it and thus not find the bug.
* They might make a fool out of themselves by trying to defend what you told them as gospel against seasoned professionals, possibly with extreme accidental arrogance.

So, it is always best to advertise the fact that you are simplifying.

> **Comments:**
> **username_0**: True, but no student is going to go straight from CS 1 to a job interview or industry; nor would I expect them to do independent programming in which the oversimplification misled them, before taking a more advanced class or doing additional reading. In upper-division classes, I am much more rigorous.  
> **username_33**: You are not in control of when your students take initiative to make use of what you teach them.  

---

### Answer by username_34 on 2019-02-27. Score: 1

For starters, there is no such thing as an "Intro CS in Java" course, and the word Interface would never come up in such a course anyway.

"Computer Science" means using computers to solve problems. Nevermind the fact that Java would never have made it out of the gate were it not for being named after a drink we are all addicted to. Problem solving has nothing to do with Java, and a weighty language like Java has no place in an Intro class, unless your school is pandering to corporations, or Mao Tse Deng has designed your CS program to go from Freshman to Ph.D in three years.

Intro to CS students should be learning about assignment statements, conditional statements, writing small swap functions, learning about basic loops, memory allocation, and then recursion, fractals, string types, and then toward the end, some more interesting and complex functions and a little bigger programs.

Since Java is garbage collected, and its syntax doesn't represent machine code instructions, there is no place for it in an Intro to CS class, or any CS class really. This is a science class, not a syntax class. Use C. If your students are asking about interfaces, then you are doing something very seriously wrong in your intro class.

Now, regarding lying, I don't know if you are a foreign teacher or not, but it's an extremely strange question in the West. A teacher should NEVER LIE to a student to any degree and for ANY reason. A student in a classroom is essentially in a hypnotic state of *a priori* belief in your authority as the true instruction. Your students will take your lie, or stretching of the truth, at face value, and will cherish that belief FOREVER. Most humans hold their beliefs not because they make sense, but because that was the first believe introduced to them on a subject. Very few people every reach logical escape velocity.

By lying, you will destroy the credibility of your colleagues and any future teacher (who does NOT lie) who will teach that student correctly, and thus will contribute in a very dangerous way to the breakdown of the pillars of civil society itself, which rest on the first principal of integrity.

> **Comments:**
> **username_35**: Of course there are intro to CS classes in Java, and many of them. It is the most commonly taught language in intro-level cs classes at universities (at least as of two years ago.)  
> **username_35**: Also, much of the art of teaching is figuring out when to introduce wrinkles in order to allow students time to absorb complex ideas. When introducing the letter "j" to a 3 year old, we might say that "j" at the beginning of a word makes a "dʒ" sound. It would be utterly unfair (and counterproductive!) to mention at this moment that there is another language, French, in which it actually sounds like "ʒ". While the "dʒ" statement is a lie, it keeps information at a level at which it can be absorbed. The child can get to other languages later, and will learn about other sounds at that time.  
> **username_34**: "Of course there are intro to CS classes in Java, and many of them. It is the most commonly taught language in intro-level cs classes at universities".  You are correct.  And yet you have completely missed the point.  
> **username_32**: "and its syntax doesn't represent machine code instructions" that is rather the point of high level programming languages.  

---

### Answer by username_36 on 2022-06-09. Score: 1

In my textbook, I say, "In its most basic form, an interface is an offer to sign a contract." It consists of a collection of method headers; classes sign the contract by implementing the interface. I then proceed from there to discuss interfaces, polymorphism, and the Visibility and Delegation priciples.

This allows me to defer the development of static methods and data and default methods in interfaces.

> **Comments:**
> **username_32**: Indeed, there is no need to say "interfaces cannot contain any code" in the first place, it isn't necessary to explain what interfaces are and how they are used.  The fact that the example interfaces used won't contain any code is sufficient to indicate that they don't *normally* include code.  

---

