Ask Kent M. Pitman About Lisp, Scheme And More 353
Kent M. Pitman has been programming in Scheme and Lisp, and contributing to the design of those languages, for a long time -- 24 years. He was a technical contributor and an international representative for the ANSI subcommittee that standardized Common Lisp, and in that capacity directed the design of Lisp's error system. Scheme may be better known as a teaching language, but both Scheme and Lisp have applications (as any Emacs user knows) that go far beyond this. Now's your chance to ask him about the pros and cons of those two languages, circa 2001 A.D. Kent also has an interesting, ambivalent take on Free software that's worth noting in an atmosphere where complex issues are often oversimplified and radicalized. Since he's someone who's helped develop standards, this is perhaps a timely issue on which to probe his opinion. It's also a good time to get acquainted with things he's written, which might interest you just as much as his programming. (Soap opera parodies, anyone?) So suggest questions for Kent below (please, one per post) -- we'll pass along the highest-rated ones for him to answer, and Kent will get back soon with his answers.
Scheme in CS (Score:5, Insightful)
Re:command on the left (Score:2, Insightful)
If I'm not mistaken, you mean
defun( . .
as opposed to
(defun . .
In scheme, the first item in a list can itself be a list. The distinct possibility here is that when the first item is evaluated, the return value may be a procedure, which then operates on the rest of the list.
This would not be possible if the operator were on the outside of the parenthesis. For example,
((operator-maker var1 var2) x y z)
will allow you to construct an operator, and then apply it to x y and z.
Lisp doesn't have this allowance, because variable name space and the function name space are separate, so to call a resultant name as a function, you need to use "funcall"
Advice to Aspirants (Score:5, Insightful)
I am one of the lucky ones who programs professionaly in Common Lisp. I certainly appreciate your hard work and the hard work of everyone else who helped to bring us the ANSI standard - which serves to reify much of the esoteric knowledge the Lisp community has developed in the many years since the language was born.
While I do not need to be sold on Lisp, I know many people who do not fully appreciate the power of the language. To a large degree, this is due to misconceptions about the language. Specifically, there seem to be a number of what I would call 'cultural misconceptions'. Because many people have never worked in a tightly interactive development environment with incremental compilation, language-level introspection, and real code/data equivalence (not to mention the differences between CLOS and what the rest of the world seems to have come to believe is the God-given definition of 'object-oriented' programming) - they don't really 'get' what makes Lisp so special and so powerful. More to the point, because the logistics of developing and deploying applications in Lisp is different than what the typical c/c++/perl/java developer knows, the hurdle to even investigating or considering Lisp as a real possibility seems unnecessarily high.
Could you talk a bit about how those who have a feeling that Lisp might help them with their hard problems could go about bootstrapping their way into finding out? How would you suggest getting started? What is a reasonable set of tools for experimentation, and where should a beginner start with the language? (The standard is a big document!) Also, could you give an example of the type of problem space and style of application delivery that demonstrates that Lisp is more practical than many seem to believe?
Re:Scheme in CS (Score:5, Insightful)
OOP is not C++-specific. Believe it or not, you can use other programming paradigms in scheme than just functional programming. You can write procedural code, if you wish, or even OO code. The point of using Scheme in introductory CS classes is two-fold.
Even though it's unlikely scheme is going to directly affect your job marketability, there are good reasons for using it in education. Foremost of the reasons is that a four-year Computer Science degree is aimed at doing more than just developing currently-marketable talents. You're learning how to think and problem-solve, and how to learn, so that in five years when Java is no more, or when C++ finally goes by the way-side, or when whatever marketable skill you have is no longer applicable (and that will eventually be the case), you are capable of quickly grasping the new technologies because you have learned how to learn. If you don't want to learn this, don't bother with a university degree. A two-year tech college, or even a couple of well-chosen certifications (guh, don't even get me started on the uselessness of those) will be much better for you, and save you money in the short run. (In the long-run, you're going to continue to pay out the rear to keep your "education" up-to-date by taking more classes or certifications.)
Re:Scheme in CS (Score:5, Insightful)
Yup. And the problem is, those students are right. Curiosity really does kill the cat. That is, if students really do construe their years in college as training for industrial jobs, then those future employers will require them to have had (N+1) years of experience in experience using a language that was only invented N years ago. Somehow, they'll get by; the clever cat will get the chance to kill some mice. Then M years from now, they'll be let go for not having M+1 years of experience in the language invented this year. They are the old cats who can no longer (it is thought) learn new tricks. And there's always a new litter of kittens... There is nothing new here. Of course, if these students view college as just a credential to enter this kind of rat race (or a race to eat rats), then they risk missing out completely on the world of ideas. In the end, an initial failure of curiosity leads exactly where lack of curiosity has always led: a dead end.
I honestly don't know how anybody can stand to learn to live without curiosity, but that is what I see around me every day. And, really, you don't need very much to get started. Suppose you're a CS major, and you've heard you need to learn Java to get a "real job". All it takes is the single spark to ask "Why Java?" Regardless of whether Java is the One True Answer or not, the mere action of trying to understand why it is even an answer will take you much deeper than most undergraduates I know ever get. It's addictive; it's fun; it's never boring. Yet real curiosity is so very rare.
The failures brought about by an essential lack of curiosity are all around us. I wish I understood how people could really be happy that way. Not because I want to become one of them, but so I would no longer find them so completely frightening, so alien, so unlikely to care about anything beyond their own comfort.
SRFIs and FFIs (Score:2, Insightful)
Are you in touch with the current participants in the SRFI process? Do you know if any work is being done towards standardizing bidirectional FFIs between Scheme and other languages/runtimes (especially C and Java, but also CORBA, SOAP, and COM)?
FFIs are, of course, crucial for being able to use new libraries which are not designed specifically for your language. I'm convinced that the primary reason why C is so popular to this day is because it standardized its FFI very early on. I'm also of the opinion that this is why adoption of Scheme and Lisp lags so far behind single-implementation languages like Tcl, Perl, and Python, which have a "standardized" FFI by default.
(For the newcomers: SRFI = Scheme Request For Implementations, the current, informal "standards" process for adding features to Scheme; FFI = Foreign Function Interface.)
Re:Scheme in CS (Score:4, Insightful)
Actually, a single lecture is enough to get them started on the study of recursion. You can postpone coverage of the bells and whistles (such as there are) until later in the semester.
Add:
1b. Scheme is different enough from the languages that the students already know that it will rock the boat for any nascent notions that there is only one way to do things (and that "their" language does it "right", which, alas, seems to be a dearly held belief for many Slashdaughters).
3. The simplicity of Scheme lets you expose students to simple correctness proofs during their first semester in CS. (You essentially treat Scheme code as a funny kind of algebraic syntax, and "solve" the code directly.)
4. It exposes students to functional programming (which otherwise they will only see for a couple of weeks during their programming languages class).
CS is not (usually) taught as a trade program. One of the major goals of a college education is to expand your mental horizons. Scheme does that.
Re:Scheme in CS [recursion] (Score:2, Insightful)
Recursion is a critical concept and is much harder to master than iteration.
I once taught Computer Science in a University where the introductory courses were all taught in procedural programming languages. I had to teach theory and some other advanced topics to people who'd never mastered recursion and it was unspeakably painful. Like teaching physics to students who hadn't mastered algebra.
Re:Scheme in CS (Score:2, Insightful)
I think you misunderstood the point I was trying to make (which is as much my fault as yours, as I only mentioned it once, in passing). That major point was that scheme/lisp makes for a very good introductory language. You know, your first one or two CS classes, where you start learning the core concepts, but before you could even dream about being able to apply your new-found knowledge to real world tasks. It's extremely important in those early stages to be able to level the playing field. It's great if a student comes into the curriculum already knowing C++, Java, or whatever else (as long as s/he hasn't formed any bad habits, anyway, which is unlikely). However, there are always going to be neophytes that are interested in computer science but have never had the time or opportunity to learn a language on their own. Choosing a language such as scheme (for example. You could pick any easy-to-learn-but-obscure language, if you really want) makes it so that those with prior language knowledge aren't at too much of an advantage, and those that have no prior knowledge are not at too much of a disadvantage. There's always the oddball that comes into such a class already konwing scheme, but that's much rarer than if said class were taught in Java (for example). Also, as a vehicle for teaching early CS concepts (the major types of paradigms, for example), scheme excels. With C++, you can't write functional code ("functional" meaning "functions are first-class objects, a la scheme, lisp, sml, etc" not "working"). With Java, it's hard to write anything but OO code. With scheme, you can introduce all through concepts within the bounds of a single language. This is perfect for presenting the concepts without relying overly much on syntax.
Just to fill in a little bit of my own background, I graduated from the University of Illinois - Urbana/Champaign [uiuc.edu] a little over a year and a half ago. When I began my education there, the initial CS course for CS majors was taught in scheme, so perhaps I'm a little biased. However, roughly two years into my education, the school began moving classes over to java, beginning with that class. Having younger friends who took this class in java, I saw a noticeable deficiency of various core concepts that they should've been taught in that class. I'm not blaming java 100% for that, but it surely owns some of the guilt. As far as later classes go, I have no problem with them using whatever language is appropriate (typically prolog and lisp for AI work, C++ or java for data structures, and so on), but to teach an introductory course in an infelxible language is doing a disservice to the students.