I think the thing to explain to a student is that the world is ever changing and that one cannot put ones eggs all in one basket. Furthermore, modern environments are often quite heterogeneous, with different languages and systems being used together cooperatively. Especially for a CS student, who often has the luxury of time that a person in the job world does not, I think it's worth taking time to learn as many different languages as possible. This not only exposes the students to alternate ways of thinking, but it also prepares the student to quickly change modes of thought or languages of expression later. Once on the job, one often can't afford the ramp-up time to learn a new language at the point it becomes necessary to use. Better to already know it and just have to "brush up".
One is much more likely to consider alternative approaches if one has a sense of what is involved in them; it's very easy to fear the unknown, even when the unknown might be of great help. So get to know as many things as you can while you can. Common Lisp and Scheme, which I regard as two very different languages, by the way, should definitely be among the things every student studies. But they should not be the only things the person studies. Like it or not, there is a lot the professional programmer needs to know to be really successful not just tomorrow, but for a lifetime.
As Oliver Wendell Holmes is often quoted as saying, "A mind stretched to a new idea never returns to its original dimensions." In order to stretch a student's mind, I recommend they make a list of "kinds of languages" and then learn as many different kinds as they can. Here are some that come to mind, though I'm sure others with different experience than me might reasonably contribute still others.
I'm confident that if people make a sincere effort to learn each of these kinds of languages on their own terms, the Lisp community will get its share of converts. But further, I would hope that the people who come to the Lisp community bring with them the ideas of other communities so that we can incorporate, rather than hide from, the good ideas that we need in order to continually be moving forward.
I originally called Kent "the father of LISP". I think I was quoting the Slashdot article at the time, but now that I go back there, I can't find the phrase. Perhaps it was just my imagination! Here is a message Kent sent me to clarify his involvement:
I guess it's flattering that you've labeled me Father of Lisp, but I personally think it's probably overblowing my role, so I figured I'd mention it. After that, you can adjust it however you like or not at all. It's up to others, not me, to peg my relevance/importance to the language.
(On the other hand, I've learned in my career that people rarely cite one for what they have done, so perhaps one should just sit tight and let them cite one for what they haven't, hoping that some odd kind of balance is achieved.)
John McCarthy of Stanford is the person who conceived Lisp and I think most people would call him the father of Lisp in some literal sense. It was born of him and would not be if he were not its father. He continues to use Lisp and to have some influence on it, but many big strides have been made since his initial design.
Guy Steele is widely credited for Common Lisp, since he held the pen for the committee, but it (the text of Common Lisp: The Language, popularly abbreviated CLTL) was a committee design.
ANSI Common Lisp, for which I was in a like role as Project Editor, was likewise a committee project. I was (as was Steele for CLTL) also a technical contributor, but in that role my part was to introduce ideas, to lobby for their inclusion, and to vote.
I haven't talked to Steele on this point specifically, but I suspect knowing his sense of humor that he would agree with me that in many way the role of Project Editor is more akin to midwife than to father. To the extent that the parenting metaphor is appropriate, the parents of Common Lisp were many, not just two, including both language dialects and people, each contributing pieces of the DNA that became the language. To see my role in better context, you might see http://www.lispworks.com/reference/HyperSpec/Body/00_.htm
Of course, the Common Lisp HyperSpec as an HTML document is entirely my baby. ANSI Common Lisp was begun by Guy Steele for CLTL, and later by Kathy Chapman (the original ANSI Common Lisp editor that preceeded me) in TeX. While doing this work, I would often talk about cross-references in the document as "hyperlinks" but HTML had not yet shown its face to me, so I was thinking of proprietary hypertext formats. When HTML and the web appeared, I conceived of the HyperSpec as a standalone product and sold the idea to what was then Harlequin (whose Lisp assets were later bought by Xanalys). The HyperSpec was created a year and a half prior to its release to the public. Harlequin sat on the idea, not understanding its importance. I just about died when CLTL2 later appeared webbed, appearing to make my year-old never-released work a mere afterthought, but managed to turn this into leverage for the eventual release of the HyperSpec to the public. I wrote the TeX->HTML translator program that created CLHS myself (in Lisp, of course).
Sometimes, too, I have carried on the role of Common Lisp's "cheerleader", its "historian", a teacher of it, and its informal and quite unelected "representative" (in the informal sense that we are all representatives of the cultures from which we come and what we do reflects on our associates generally). The Slashdot article you quote is done in these roles.
So it's fine if you overblow my importance now that you're "informed" as to the truth of things, and it's due to your choice and not just some misunderstanding. It's somewhat more reasonable to credit me for CL's condition system (which I led the design of, but again which again was based on others ideas--see http://www.nhplace.com/kent/CL/Revision-18.txt) or to credit me with CLHS. Or you can just call me a key technical contributor.
Hope you find this information useful in putting me and my contributions into the proper perspective. (It's fine with me if you want to quote some or all of this message in any correction you make.)
--Kent