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.

  • 34
    $\begingroup$ 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. $\endgroup$
    – Tim
    Commented May 8, 2018 at 1:02
  • 71
    $\begingroup$ CS is the art of applying abstractions. You're not "lying", you're abstracting away the unnecessary details (for now, of course). $\endgroup$
    – tonysdg
    Commented May 8, 2018 at 1:09
  • 12
    $\begingroup$ Actually it was true until default methods were added. $\endgroup$ Commented May 8, 2018 at 5:05
  • 37
    $\begingroup$ 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". $\endgroup$ Commented May 8, 2018 at 5:05
  • 23
    $\begingroup$ @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++. $\endgroup$
    – Cubic
    Commented May 8, 2018 at 10:13

16 Answers 16


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.

  • 80
    $\begingroup$ 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." $\endgroup$
    – Mark
    Commented May 8, 2018 at 9:08
  • 13
    $\begingroup$ Some say public static void main(String[] args) is the most powerful spell of all. The results are only limited by your imagination! $\endgroup$
    – JollyJoker
    Commented May 8, 2018 at 9:22
  • 65
    $\begingroup$ public static void main(String[] args) is the entrypoint for a frictionless, perfectly spherical Java program $\endgroup$ Commented May 8, 2018 at 10:42
  • 38
    $\begingroup$ Assume a spherical cow.jar in a vacuum. $\endgroup$ Commented May 8, 2018 at 16:02
  • 13
    $\begingroup$ @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." $\endgroup$ Commented May 9, 2018 at 16:01

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.

  • 9
    $\begingroup$ Welcome to Computer Science Educators. Great suggestion. I hope we'll see more ideas from you on the site. $\endgroup$ Commented May 8, 2018 at 13:54
  • 5
    $\begingroup$ 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. $\endgroup$ Commented May 9, 2018 at 10:41
  • 2
    $\begingroup$ 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. $\endgroup$
    – the_lotus
    Commented May 9, 2018 at 17:34
  • 3
    $\begingroup$ 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. $\endgroup$
    – supercat
    Commented May 9, 2018 at 19:12
  • 1
    $\begingroup$ +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. $\endgroup$ Commented May 10, 2018 at 20:31

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.

  • 1
    $\begingroup$ 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. $\endgroup$
    – Ed Avis
    Commented May 10, 2018 at 6:34
  • $\begingroup$ My only concern is that 'for now' is invariably an invitation to some smart-alec to do it. $\endgroup$ Commented May 10, 2018 at 20:24
  • 15
    $\begingroup$ @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. $\endgroup$ Commented May 11, 2018 at 10:01

I am currently a student in a computer science bootcamp learning js, C# and asp.net mvc5.

For what its worth, I appreciate the honesty when my instructor uses crossed fingers.(He will pause to cross his right and middle finger and prominently display them in front of him before/while continuing with a "fuzzy truth") I will treat knowledge given to me in this manner as practical use advice and not grounded principle.

I feel that telling hidden un-truths for the sake of a smoother delivery sets a bad precedent and has potential to act as a crutch.

And isn't there always the chance a student "catches" the lie and becomes very confused?

  • 2
    $\begingroup$ Welcome to CSEducators. Say a bit more, please. Does the instructor actually give a visual signal to indicate "fuzzy truth"? That would be cool, I think. $\endgroup$
    – Buffy
    Commented May 8, 2018 at 0:55
  • $\begingroup$ Welcome to Computer Science Educators. It is always helpful to have the insightful feedback from students on questions, and answers, posted here. Often what the instructors "thinks" they are passing on is not the same as what the students "think" they mean. Knowing when it is not working is just as important as knowing when it does work. I hope we will see more of your words on the site. Glad you could join us. $\endgroup$ Commented May 8, 2018 at 1:16
  • 7
    $\begingroup$ I actually do sometimes visibly cross my fingers or use a crossed fingers icon on a slide. $\endgroup$ Commented May 8, 2018 at 1:22

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.

  • 2
    $\begingroup$ 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). $\endgroup$
    – Luaan
    Commented May 9, 2018 at 7:27
  • $\begingroup$ @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. $\endgroup$
    – Wildcard
    Commented May 12, 2018 at 2:55
  • 1
    $\begingroup$ @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. $\endgroup$
    – Luaan
    Commented May 12, 2018 at 8:16

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

  • 2
    $\begingroup$ 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". ;-) $\endgroup$ Commented May 8, 2018 at 20:49
  • $\begingroup$ @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 $\endgroup$ Commented May 10, 2018 at 0:53
  • 1
    $\begingroup$ For the purposes of this website... $\endgroup$
    – bdsl
    Commented May 12, 2018 at 17:06

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:

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.

  • $\begingroup$ "...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. $\endgroup$
    – Buffy
    Commented May 8, 2018 at 12:37
  • $\begingroup$ When my instructor crosses fingers I will keep an eye out and often find the exception to the rule during my work after the lecture. This leads to complete understanding(and excitement) on my part. When I know an instructor prefers to lie vs announce a half-truth I watch their speech and body language for signs that they are lying so I can keep it in mind for my studies later. I simply prefer to not have that extra strain on my attention during a lecture. (this is all my personal experience as a past and current student) $\endgroup$
    – user5052
    Commented May 8, 2018 at 20:51

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

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."


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 :–)

  • $\begingroup$ This doesn't quite answer the question. $\endgroup$
    – Wildcard
    Commented May 12, 2018 at 2:56
  • 3
    $\begingroup$ 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." $\endgroup$
    – JKreft
    Commented May 12, 2018 at 18:09
  • 1
    $\begingroup$ 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. $\endgroup$ Commented May 15, 2018 at 18:13
  • 1
    $\begingroup$ 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. $\endgroup$ Commented May 15, 2018 at 18:41
  • 2
    $\begingroup$ 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. $\endgroup$
    – JKreft
    Commented May 16, 2018 at 13:28

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.

  • $\begingroup$ @NOTCSEducator, fyi, the link "moved to chat" in your comment points to chat.stackexchange.com/rooms/71/the-h-bar , which seems to be something completely different... $\endgroup$
    – AnoE
    Commented Jul 6, 2022 at 12:46

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<T> {
    Iterator<T> iterator();

and iterators have next and hasNext

interface Iterator<T> {
   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.


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".


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.


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.

  • $\begingroup$ 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. $\endgroup$ Commented May 18, 2018 at 14:58
  • 2
    $\begingroup$ You are not in control of when your students take initiative to make use of what you teach them. $\endgroup$ Commented May 19, 2018 at 10:41

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.

  • 3
    $\begingroup$ 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.) $\endgroup$
    – Ben I.
    Commented Feb 27, 2019 at 1:37
  • $\begingroup$ 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. $\endgroup$
    – Ben I.
    Commented Feb 27, 2019 at 1:38
  • 2
    $\begingroup$ "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. $\endgroup$
    – Johnny
    Commented Mar 2, 2019 at 14:37
  • $\begingroup$ "and its syntax doesn't represent machine code instructions" that is rather the point of high level programming languages. $\endgroup$ Commented Jun 10, 2022 at 5:38

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.

  • 1
    $\begingroup$ 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. $\endgroup$ Commented Jun 10, 2022 at 5:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.