Ask Kent M. Pitman About Lisp, Scheme And More

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.

Lisp becoming more used

[zairius]

As we move closer to having infinite memory and infinite processor speed do you see Lisp being used more in the mainstream?

John Casey

I had to say it

[smileyy]

We're no closer to having infinite memory and infinite processor speed than we were 40 years ago.

mmmm...a set of bits of cardinality aleph-null...

Re:Lisp becoming more used

[sharkey]

Too bad "Infinite Justice" is likely to make it illegal to use all that memory and speed.

Re:Lisp becoming more used

[sv0f]

As we move closer to having infinite memory and infinite processor speed do you see Lisp being used more in the mainstream?

Common Lisp applications of nontrivial size (i.e., NOT "hello world") are no larger than, and typically smaller than equivalents written in more mainstream languages (e.g., C++ and Java). This is sometimes obscured by the fact that programs in more mainstream languages have small disk footprints but large memory footprints due to large, dynamically-linked libraries. Common Lisp applications typically 'carry' all of this in the application image itself.

Round about the time average computers started sporting 8 megs of RAM, the memory demands of Common Lisp and more mainstream languages reached equilibrium. At this point, the last hangers-on ditched their workstations and joined other developers on PCs.

Educational Languages?

[FortKnox]

Lisp and Scheme have long been viewed as just "Educational Languages". Do you see any future with the two languages in commercial software?

Re:Educational Languages?

[Junks Jerzey]

Lisp and Scheme have long been viewed as just "Educational Languages". Do you see any future with the two languages in commercial software?

You're confusing the two. Scheme has always been an educational language, because that's what it was designed as. But Lisp has been hardcore for a long time now: AutoCAD, Emacs, Mirai (high end 3D modelling/texturing/animation system), Yahoo Store, scripting for the Crash Bandicoot series and the upcoming Jax & Dexter for the PlayStation 2, it's used by companies such as British Telecom and Boeing, and so on.

University Students

[akula1]

It seems that more and more universities are focusing only on C++/Java, even to the point of discouraging learning other languages. Do you see this as continuing trend? If so, how do you think this will shape the next generation of computer scientists?

Scheme in CS

[Anonymous Coward]

It seems many of the more popular CS programs in the world use Scheme as a teaching language. A lot of times, students complain about this, saying they'd prefer to learn about C or another language that is considered "apt for industry." I used to be like this too, but have now discovered the error of my thinking. How have you convinced others that while the latest programs might not be written in Scheme, that it is worth a student's time to learn Scheme. Many seem stuck to the point that if they won't use it outside of school, they shouldn't learn it. How can we convince them otherwise, to become scholarly citizens instead of drones?

Re:Scheme in CS

[Mark_pdx]

Many EDA (electronic design CAD) tools use LISP variants. Cadence's SKILL, Avanti uses Scheme. It's 10X faster to write code than procedural languages, and the code is rock-solid (if you know what you're doing) because you can easily test the pieces as you build up your code. I spend 10X less time debugging LISP than procedural languages.

Even if you don't use it, any programmer should at least code enough lisp to understand how elegant programming can be. Become one with the stack. Witness the power of (mapcar It's a completely different kind of mindset than the procedural languages.

Re:Scheme in CS

[Jon Howard]

Aside from the scholastic value of lisp (or scheme) as a system of abstract logic, there is a thriving commercial industry - it's not huge, but it does include some big names - Yahoo, Orbitz.. the list goes on..

• Companies making it big with lisp [franz.com]
• Lisp career listings [franz.com]

Re:Scheme in CS

[King Babar]

It seems many of the more popular CS programs in the world use Scheme as a teaching language. A lot of times, students complain about this, saying they'd prefer to learn about C or another language that is considered "apt for industry."

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.

CS != learning a programming language.

[morzel]

I have to disagree with you: CS isn't about learning programming languages, it isn't about mastering a specific technique or language that is "apt for industry".

It's all about learning the basic fundamentals of programming, algorithms, data structures, different ways of solving things, lot's of theory - it's called "computer SCIENCE", remember.

Scheme is a good teaching language for a lot of reasons:

Most CS students nowadays have experience with computer "programming": VB, Delphi, C, C++, Java, Javascript,... nearly everybody has some experience with some programming language. The problem is that a lot of this experience isn't always built on the proper fundamentals, they're mostly about solving a particular problem without knowing why they should use data structure X or algorithm Y. The usage of Scheme as a teaching language has the advantage that most (if not all) students are forced to learn a new language, which probably isn't at all similar to what they're used to - enabling the teachers to start from scratch. That way, there aren't differences in the level of knowledge of the students, also a plus.

The language structure of scheme is very flexible: most (if not all) fundamental bits can be dealt with properly in Scheme: procedural programming, heaps of different data structures, OOP, ...

I do agree that other languages (be it C, C++, Java, Pascal, Fortran, O'Caml, Eiffel, ...) should be taught as well. But only on a later stage in the education: the most important thing is that the fundaments of your knowledge are strong, well-taught. Scheme is a good language to do just that: laying those fundaments.

With the boom of IT and internet the last 5 years, there are so many programmers out there that lack those proper fundaments. I'm not saying that they aren't any good, but there are a lot of people that don't have a grip on what lies beneath - which is a pity.

Don Knuth showed us that computer programming is an art, not based on a specific programming language, and I tend to agree with him :).

Re:Scheme in CS [recursion]

[rpg25]

This isn't a way to convince people to learn Scheme, but one of the reasons I think it's critical to use a language like Scheme in CS education is that it helps learn the critical concept of recursion. While you may never use recursive programming again (or you might use it all the time, like me), it is an absolutely critical concept for computer science and for other fields like mathematics, linguistics, etc.

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

[Osty]

Why not learn C++, and OOD instead of scheme? Its in the industry, and it teaches them the theory they need to know.

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.

1. It levels the playing field. Students coming into the class already knowing C++ or Java or even Basic no longer have as much of an advantage over students that come into the class knowing little or nothing about programming. (and while you might argue that the latter people shouldn't be learning CS anyway, that's a very narrow-minded and short-sighted view, and one that's not even worth acknowledging)
2. It allows the teacher to focus on concepts rather than language idiosyncracies. Scheme can be taught to the students within the first two weeks of class. After that, they'll have all the tools necessary to learn about different programming paradigms and other CS concepts. This is much better than Java, for instance, which more or less forces you into OO design.

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

[Black Parrot]

> Scheme can be taught to the students within the first two weeks of class.

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

[mandolin]

It levels the playing field. Students coming into the class already knowing C++ or Java or even Basic no longer have as much of an advantage over students that come into the class knowing little or nothing about programming.

Of course those who learned Scheme in high school will have that advantage.. (no, I didn't. I'm from the Pascal era.)

This is much better than Java, for instance, which more or less forces you into OO design.

Since my skills in Scheme are, shall we say, not up to snuff, I will put this next bit in the form of a question:

How does Scheme, as a lisp (successor? derivative? argh) not force you to design more recursively and/or functionally (ie, functional programming)? Certainly straight-up procedural programming is not encouraged except as a speed "hack"?

Re:Scheme in CS

[Osty]

I take serious offense at this notion that advanced conceptual computer science can only be taught in a commercially-backwater language like Scheme or LISP. It is the same ivory tower elitism at work here as that which so often causes types like Harvard anthropology majors or Berkeley political science majors to view the rest of modern, industrialized society with disdain.

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.

I went to MIT over ten years ago and I was taught Scheme by Hal Abelson and Gerald Sussman. I also worked in Common LISP on Symbolics LISP machines and Texas Instruments Explorers. These things I learned were supposedly the pinacle of computer science education of the day. I mention this not to brag, but rather due to the specific topical relevance of my past experience. In short, I feel qualified to say that -- in my experience -- Scheme and LISP offered nothing that I could not have also learned through the use of a more commercially-relevant language. In fact, in my personal opinion, I would almost go so far as to say that some of the vaunted abstract concepts that they go through pains to indoctrinate their students with verge on being counter-productive in the real world.

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.

Re:Scheme in CS

[mvw]

More importantly, the concept of code generation and evaluation as part of the language semantics is NOT possible in C or C++.

Which is bull, because all these languages, even assembler, are computationally equivalent (Turing complete).
It is just more work and uglier to achieve.

Re:Scheme in CS

[mvw]

The 'rewrite' part is possible but ugly as hell in C (dump the source, exec the compiler, dl_open... you get the idea?).

That's why I used 'ugly' in the first place, if you cared to read.

On the other hand this is a somewhat artificial uglyness, because compilation is usually delegated to external programs (the compiler) and not integral part of the run time system, which makes it harder to use and to get perceived more artificial than the built in byte code compilation of those interpreted functional languages. This has nothing to do with the language, why not have C++ running on a VM and with an easy integrated compilation function? (Will something like this not be part of .NOT?)

(and no, #defines are not Turing complete, nor they can parse their arguments).

I didn't claim that. But templates (which are one of the means Stroustrup tried to get rid of the preprocessor) offer such computation power at run time: This link to template metaprogramming [t-online.de] should give an example.

Regards, Marc

Re:Scheme in CS

[mvw]

Your use of "interpreted functional languages" indicates an ignorance of current Lisp practice.

I apologize for that statement. What I wanted to approach was that when talking about languages, one often includes the development/execution environment of the typical language implementation.

In case of Lisp these are the integrated systems like the ones you describe.

In case of C++ the environment is split into compilers, linkers, assemblers with very loose coupling. And thus lead to this big recompile in that case you describe.

But I see no reason (which doesn't mean that there is one :-) that one builds a C++ system that has many of those Lisp features. I guess it would have to modify or get rid of the present object and library file models.

How do the Lisp implementations solve the problem of linking libraries from different vendors?

Re:Scheme for OOD

[mvw]

C++ isn't a fully object-oriented language. It's a set of object-oriented extensions grafted onto a non-OO substructure. One particular place where you can see this is the way the object-oriented extensions combine with operator overloading and type coercion to create something that's deeply confusing.

This is not true. C++ has full support for OOP (and lots of other paradigms as well by the way). In that aspect it is more complete than Java which misses multiple inheritence due to concessions to its VM interpretation. Operator overloading is a blessing or a curse depending on how you use it.

Too bad that many beginning C++ programmers expose the same habit like new wordprocessor users who try out every font and style to create ugly documents, but that's not the fault of C++.

Also, since C++ is aimed at building very efficient systems programs, it skirts things that seem difficult, like multiple inheritance. C++ has no garbage-collection.

Again I disagree. Java has shown how helpful a modern, large, portable, well documented set of libraries is. The libraries are the real part, where C++ could need additional work.

LISP on Windows

[Multiple Sanchez]

Does the relative absence of a good, free LISP interpreter for Windows ever give you pause?

Re:LISP on Windows

[sv0f]

Does the relative absence of a good, free LISP interpreter for Windows ever give you pause?

People stopped using Lisp interpreters decades ago. Everything's compiled now, and has been for a while. In fact, Common Lisp implementations led the way in the arena of incremental compilation, e.g., Macintosh Common Lisp has had this capability for over a decade, even on hardware of trivial power compared to what we have now.

Franz and Xanalysis have free trial versions of their Windows environments. CLISP works under Windows. For an amazingly cheap native Windows Common Lisp, check out Corman Common Lisp.

Re:LISP on Windows

[Lemmy Caution]

I like LISP, but I have to agree with the above poster (and in the interests of having his question posed to Kent Pitman, advocate that he get modded up.)

The free implementations of LISP on Windows are usually crippled or limited, with limits in stack sizes or ability to save images, etc. And vital libraries are often missing from the free versions. CLISP is a nice try, but it's far from a fully useable implementation. GCL doesn't work with (any reasonable recent versions of) cygwin. The trial versions of Franz look promising, but it's hard to justify paying the prices for the Windows implementation when such good implentations are Free in *nix.

I think that this is a fixable lack, but it should be pointed out as a lack.

Re:LISP on Windows

[hding]

The right link for XAnalys is actually here [xanalys.com] (no 'i').

Where has Lisp been?

[mikewelter]

I've suggested to my employer that we use Lisp to generate some source code as a product of pattern matching. His response was "where has Lisp been for the last seven years?" He's right. No new books. No press. No interest. Do you see Lisp falling off the end of the earth?

Re:Where has Lisp been?

[Junks Jerzey]

No new books. No press. No interest.

Some Lisp and Scheme books published in the last ten years:

Paradigms of Aritificial Intelligence Programming (Norvig)
ANSI Common Lisp (Graham)
The Little Schemer (Friedman & Felleisen)
On Lisp: Advanced Techniques for Common Lisp (Graham)
Lisp in Small Pieces (Queinnec & Callaway)

Re:Where has Lisp been?

[Anonymous Coward]

Oh dim one, YHBT, by your employer. If Microsoft started selling Lisp tomorrow, your Boss would embrace it like the $1.50 whore he is.

"Good" applications for Lisp

[HyperbolicParabaloid]

I'm a professional programmer, mostly Java, primarily in the financial services industry. I've recently become interested in Lisp (UPS delivered Graham's book yesterday).
It seems to me that Lisp would be useful in areas such as derivatives ananlysis, where people come up with a new exotic type of option every day. I'm still learning about Lisp, but it seems that it might provide more flexibility to handle this constant evolution.
Is that analysis accurate? What general types of problems is lisp best suited for?

Lisp used in finance

[hding]

I use Lisp for something similar in finance. So, yes, it does work for that.

Re:"Good" applications for Lisp

[sv0f]

It seems to me that Lisp would be useful in areas such as derivatives ananlysis, where people come up with a new exotic type of option every day. I'm still learning about Lisp, but it seems that it might provide more flexibility to handle this constant evolution.

Here are two reasons to use Common Lisp:

(1) It's numeric facilities are among the best thought-out of all programming languages, certainly better than those in more mainstream languages. For example, for decades Common Lisp programmers have not worried about integer overflows. Machine-sized integers are extended automatically to 'big integers' and contracted back as needed. Thus, one can compute efficiently and safely with integers in Common Lisp as a mathematical abstraction, regardless of their size. Contrast this with the bifurcated integer types of Java.

(2) Many of the major mathematical programming languages (e.g., MACSYMA) are Lisp-based. Emerging statistics packages such as R derive their semantics from the Scheme variant of the Lisp family. Lisp has proven capable of scaling up for the most demanding mathematical applications. This bodes well for its application in your area.

Re:"Good" applications for Lisp

[SuperKendall]

From my expereience programming in both Scheme and C++, I find Java actually closer to Scheme than C++. At least the same though processes I used for Scheme seem to map over well.

One complaint I've seen C++ programmers have is that Java is more like Lisp than C++!

Educational vs. production languages

[thinmac]

Lisp and scheme are both used in educational setting pretty commonly, but I don't know of any production projects (which isn't to say they don't exist) that use either language. Could you discuss the difference between what makes a good educational language and a good working language, specifically as to why it might be useful to learn in a language that you are unlikely to ever use in a work environment.

Lisp as a Macro Language

[wiredog]

Are there any programs other than Autocad and Emacs that use lisp as the macro language?

Re:Lisp as a Macro Language

[rgmoore]

I can think of at least one other program that does: the Sawfish [sourceforge.net] window manager that's now the default WM for GNOME.

Re:Lisp as a Macro Language

[sv0f]

MACSYMA, the mathematical programming language. A lot of languages are based on Lisp's semantic model, so that understanding Lisp allows you to understand them. This is true of the rapidly-emerging R statistical language, the Curl language that was discussed on Slashdot recently, etc. I think that the internal representation of GCC is Lisp-based. Some have said that XML is basically a subset of the representational capabilities of Lisp. A development tool for Ninetendo games (Nichimen?) is Lisp based. I think that one of Adobe's web-creation programs is Lisp-based or was in its first version (i.e., because of Lisp's rapid prototyping capabilities). One of Autocad's competitors is, I believe, also written in Lisp. Many expert system authoring tools. Etc etc. (Any errors in the above unintentional.)

Lisp tends to lurk behind the scenes, the competitive advantage that company's don't want you to know they're using to run circles around you. Paul Graham talks about this on his website.

List in Mathematics Programming

[Anonymous Coward]

Gregory Chaitin has a book called "the limits of mathematics." In it he claims that mathematicians should love Lisp because Lisp is basically set theory, and all mathematicians love set theory. I wholeheartedly agree with this, one only needs to look at Chaitin's Lisp programs to realize how quickly and succinctly one can arrive at astonishing incompleteness results in mathematics. So we know Lisp is great for stuff like this, really researhing a mathematical subject. Do you see Lisp continuing in this direction, showing and discovering theorems, or will it move into industry? Or has it moved into industry, and we just don't know it? Do the likes of NASA and JPL use Lisp and Scheme religiously? I would bet so.

Re:List in Mathematics Programming

[sv0f]

Note also that Douglas Hoftstadter is/was a Lisp fan. He devoted three columns to it, which can be found in his "Metamagical Themas". (Note that this is an old dialect.)

Re:List in Mathematics Programming

[Black Parrot]

> In it he claims that mathematicians should love Lisp because Lisp is basically set theory, and all mathematicians love set theory.

To say nothing of recursive functions (in the mathematical sense). Lisp is, at its core, and implementation of Church's lambda calculus.

Too damn hard

[HyperbolicParabaloid]

There don't appear to be a lot of Lisp programming jobs out there right now. I suspect that is because there aren't many commercial Lisp projects, perhaps because there aren't many Lisp programmers....
If Lisp is so great, why is that so? Or, more positively, how do we overcome this bias against Lisp?

Re:Too damn hard

[sv0f]

There don't appear to be a lot of Lisp programming jobs out there right now.

When I've searched for Lisp jobs in the past, I've always found tens of hits on Monster. It is possible to get Lisp jobs in University towns and big cities across the country, and particularly easy on the coasts. What's cool is that people use Lisp to do cutting-edge stuff. These jobs are almost always challenging and your coworkers smart and intellectually-diverse cookies. You're not just surrounded by Perl monkeys.

Future of Scheme?

[Larne]

The IEEE spec has expired, I can't find any information about efforts towards r6rs, and not much seems to be happening on the SRFI front. On the other hand, there's an active Scheme community and dozens of implementions, and it seems more show up daily.

How do you reconcile these apparent contradictions, and where do you see Scheme going?

Re:Future of Scheme?

[Waffle Iron]

> The IEEE spec has expired
This seems to be true. When I tried to run my Scheme interpreter today,
this is what it output:
(but (are (sorry we))
(has (expired (IEEE-specification Scheme))))
(for (interest your (in Scheme)) thankyou)
(provide (to you) (are (hard (working we)))
(replacement (a technology)))
(may (meantime (the in))
(suggest we (try you (other (fine languages)))
(such-as (Python Ruby Haskell C# Java Forth))))
(for (are (sorry we))
(caused (any (inconvenience you))))

The prerequisite FP question

[Larne]

What are your thoughts about Haskell, OCaml, and teh state of functional programming in general?

Lisp - Scheme - ML

[Tom7]

I know a lot of big academic (erstwhile) lisp shops, such as CMU, have transitioned away from lisp to ML [standardml.org] and relatives [inria.fr]. Some of the reasons we might give are:

- Sophisticated type systems, catching most bugs before your program is run, ensuring safety, etc.
- Much more efficient (http://www.bagley.org/~doug/shootout/craps.shtml) , partly due to compilation strategies using types
- Increased modularity and abstraction
- Pattern matching, (subjectively) more natural syntax

In fact, I'm one of those people. I've been scoffed at by lisp fans, but most had never used ML. But I have an open mind, so, in the face of more "modern" languages, what advantages do lisp and scheme offer? Do you think that these advantages are fundamentally impossible to achieve in a typed setting?

Re:Lisp - Scheme - ML

[Junks Jerzey]

There are two schools of thought:

1. We need to determine everything at compile time, so we can prove properties of our programs.
2. We should make everything as dynamic as possible, so we're not prematurely locked into a solution.

You could argue either way, but it's a split decision. Some schools lean one way, some the other.

Re:Lisp - Scheme - ML

[Black Parrot]

> I've been scoffed at by lisp fans, but most had never used ML.

I'm one of those who've never used ML (along with a dozen other languages I wish I had time to try), so this is not intended as a scoff. However:

> Sophisticated type systems, catching most bugs before your program is run, ensuring safety, etc.

I'm a fan of that too, which is why I almost always program in Ada. However, I also see the value of dynamic typing as used by the Lisp family of languages. It makes some stuff really easy, at the cost of having to be careful with the coding. (Horrors, that we should ever feel a need to be careful with our coding!) It's not really so hard, when you start thinking functionally: every function is a filter that accepts data of some particular type(s) and returns a result of some particular type(s). You need to enforce a discipline of ensuring that every function is called with an appropriate type or else of ensuring that every function checks the types of its arguments, but that's very doable.

> Increased modularity and abstraction

<noscoff>That's an interesting claim, since I always thought you could make Lisp as modular and abstract as you cared to.</noscoff>

> Pattern matching

Seen that in 1st-semester CS classes that use Scheme.

> (subjectively) more natural syntax

You may be on to something more than subjective, there.

Re:Lisp - Scheme - ML

[jacobm]

Actually, the PLT Scheme distribution [neu.edu] comes with a tool called MrSpidey that does implicit static type analysis on your Scheme programs. It allows recursive types and all that fun stuff. The only problem is it doesn't work well when you use some of PLT Scheme's more advanced features, such as its class system.

relative benefits of using Scheme and LISP?

[Anonymous Coward]

Given that LISP and Scheme have traditionally been portrayed as research languages most suitable for AI work, and have not been accepted as widely as more traditionally structured languages such as C:

-What arguments would you give to convince programmers looking for easier ways to accomplish traditional computing tasks to use LISP or Scheme, mindful of the overhead required to learn LISP and Scheme and the lack of programmers who are intimately familiar with them?

For example, I start to develop an OpenSource text editor at SourceForge, and I choose Scheme. What advantages would I have over someone using a language such as Java or C++ that would outweigh the fact that I might not be able to find another developer who is familiar with Scheme?

-Do you feel that any work is being done at present to bring the two languages further into mainstream?

Thanks, I genuinely like both languages, and would like to seem them gain greater adoption by programmers et al.

Why learn lisp -- deeper reasons needed

[billr]

I've read some interesting articles about lisp, and I'm interested in learning to some extent.

One problem though is that most people stop at saying that feature X (which no other language can do) is really great, and stop there. Never having used feature X, I don't have enough context to say, yes that will help me solve problems more easily.

For example, somebody claims that LISP is better because a lisp program can write code as it goes, or something like that. Having never had that as an option I can't see circumstances where I'd want to do that.

Could you please describe in some detail the top features of lisp and why they are GOOD THINGS?

Also, I promise to not make fun of parenthesis if you don't state that infix notation is one of the reasons that lisp is good. ;)

Re:Why learn lisp -- deeper reasons needed

[chompz]

you can change the syntax to anything you want

Isn't that a strength?

Overlooked practical aspects of Lisp

[hding]

Why do you think that people so often overlook many of the wonderful things in Common Lisp such as unwind-protect, the whole condition system (which you are of course closely associated with), and so on - things that make it very useful for day-to-day programming, and are there any such things that you'd particularly highlight, or conversely that you wish had become part of the standard but did not.

Incidentally, thank you for all of the insight so generously and regularly poured forth in comp.lang.lisp.

Good texts for learning Scheme?

[drenehtsral]

I have recently been working on learning Scheme in my spare time, with the eventual goal of writing a scheme based scripting system to run the guts of a massive adventure game/graphical mud sort of system, everything from environment simulation (predator/prey cycles, etc...) to 3d models (i.e. models will be geometry glued together by scripts so you could have trees that by a random seed and a growth level variable have grown over time and are unique to provide interresting landscape features). Scheme is appealing because it's simple, powerful, and adapts well to the idea of a threaded interpreter.
To further my goal of learning Scheme inside and out, i've been reading "The Little Schemer", as well as "Structure and Interpretation of Computer Programs". Do you have any other recommendations for good Scheme programming texts?

Re:Good texts for learning Scheme?

[HongPong]

In my freshman CS class we are using the Scheme book "Concrete Abstractions," which is more oriented around theory than "The Little Schemer." A fine paradoxical title for a book. The author's name escapes me though.

Who needs a text?

[fm6]

I'm not Scheme expert. But I really wonder if you need any text at all to learn it. What little work I've done with Scheme has been in my occasional attempts to work through S&I. That book is interesting because it (a) assumes no prior knowledge of Scheme (b) spends very little time explaining the language as such. And yet the whole book is about Scheme programming! It would seem that Scheme programmers spend less of their time thinking about language issues than other programmers.

New programming language ideas in Lisp?

[cardhead]

What I'm most intereseted in is not Lisp as a mainstream language, but rather Lisp as a research language. When people talk about the new things in programming languages these days, they talk about lazy evaluation, polymorphicly typed functional languages (e.g. Haskell). Since the ANSI spec, it seems as if Lisp has stagnated. CLOS gave us objects, but very little new has come down the pike since then. At one time, much of the new work in programing languages was done with Lisp. Now Lisp seems to be in the position of C: an excellent language that has aged out of the cutting edge. I guess my question is, is this a correct assessment, if so, should something be done about it and what should that be?

cheers,
ric

Lisp vs the world.

[hjs]

What do you see as the unique strengths and weaknesses of Lisp?

What strengths does it specifically have over other functional languages (such as ML), over structured languages (such as C, Algol, etc), over object oriented languages (such as C++, smalltalk, simula, etc), and over scripting languages (such as TCL, perl, etc)? Can these other languages or classes of languages be enhanced to include these strengths? If so, how, and if not, why?

What about weaknesses? What do you see as the weaknesses of Lisp, both in general and in comparison to the above classes of languages? Can these weaknesses be eliminated? If so, how and if not, why?

I mean strengths and weaknesses not only in the formal sense of the language itself, but also in terms of its usability in today's world. For example, difficulty in delivering binaries or lack of accessibility of system libraries from within common implementations of a language would be considered weaknesses.

First nontrivial program

[quigonn]

When you first learn a language, you often do toy programs for some time, until you know the most important features of the language. Then you should be able to try your skills out in a bigger application. Now I would like to know what program that was when you learned Lisp.

Scheme as an XML Translation Language

[Evangelion]

I've become fairly interested lately in using Scheme (probably mzscheme [rice.edu]) and the SXML [okmij.org] package as a way to do arbitrary XML translations in my free time (if I had any).

From the looks of it, the ability to create a reflexive mapping between an arbitrary XML document and an interpretable programming language is too powerful to be ignored.

Do you think that in the future one of the primary roles of Scheme/Lisp is going to be in manipulation of XML documents, or is this going to be relegated as an academic curiostiy while the world struggles through parsing XML in Java?

Re:Scheme as an XML Translation Language

[Black Parrot]

> From the looks of it, the ability to create a reflexive mapping between an arbitrary XML document and an interpretable programming language is too powerful to be ignored.

I looked at XML and thought it was too much syntax for a relatively simple problem, so I already ditched it in favor of Scheme as a data representation language.

Other people are taking the same route, e.g., Xconq uses a Scheme-like language for its scenario data.

Notice that your "stylesheet" can just be a program that does arbitrary transformations on your data, and also that you can include executable code in either the data, the stylesheet, or both. (Sandbox those applications, though!)

FWIW, when I was first learning Scheme I spent an evening writing a program that would accept an ad hoc "SBML" (Scheme-Based Markup Language) as input, and spit out an HTML output.

There's an old claim that "those who don't know Lisp are doomed to reinvent it, badly". IMO that claim was a prophecy of the coming of XML.

Re:Scheme as an XML Translation Language

[BitwizeGHC]

For XML applications I find that the easiest thing to do is write a translator that parses XML and converts it to a Scheme data structure that represents the various elements and character data, and perform any further operations on that. The code to do this is both small and fast, and really isn't too different from using a DOM (although it may be a bit more flexible).

That is, when I need to use XML. Ususally I just format data in a Scheme-type syntax for my own applications, when no boss is breathing down my neck. My comic site was constructed in this way.

Basis set for programming languages?

[PseudonymousCoward]

As a Scheme and Common Lisp programmer, I got excited when I heard that the Java Virtual Machine would have automatic memory allocation and garbage collection. I thought it would be possible to build Lispish languages to run on the JVM. The rate at which Kawa has been developed, to implement a near-Scheme on the JVM has been frustrating to me. I attribute this at least in part to the absence in the JVM of a construct equivalent to Scheme's continuations. Do you think it is feasible to establish a "basis set" of programming language concepts on which all programming languages could be built, so that the distinctions between C, Scheme, etc would be "merely" syntactic? If yes, please enumerate your candidate set.

Re:Basis set for programming languages?

[chompz]

to say it again, you can change the syntax in lisp to be anything you want, you can even make a C intrepreter in lisp. It wouldn't be very fast, but it would work. You can define a strongly typed language in lisp, and make it do anything you can think of. lisp is the original VM, designed to allow the programmer to code the same way that they think. Very usefull programming language from that standpoint.

Questions I've Come Across Learning Lisp

[Jon Howard]

I was recently (April) hired-on as webmaster at Franz [franz.com], a commercial lisp company (we make Allegro Common Lisp [franz.com]) which has introduced me to lisp in a very loud way. Since joining these guys (and gals), I've been thoroughly indoctrinated - with my full consent - because of my belief that as computing hardware progresses programming in more abstract languages will allow for more creative and effective use of the platform. Sure, coding assembler on a new super-duper petaflop chip will still be possible and less wasteful, but who would want to code a million lines of asm to save a few (or even a few thousand) operations out of a few billion, or trillion when it will only net a difference of nanoseconds in the end? I'm less interested in making super-fast programs than I am in making artistic and super-functional programs.

I'm not expressing the views of Franz, every member of the company has their own beliefs on what makes for great programming - which is one of the major reasons I find this place so fulfilling, everyone has complex reasons for their design considerations, and everyone communicates them (something I've grown to appreciate from working in too many places where this was definitely not the case), and consequently I've been exposed to quite a few different techniques of Lisp coding since my introduction half a year ago. I'm constantly amazed that so many different styles of programming can be expressed in the same language, it's capable of accomodating any logical thought process that can be converted to code - and I doubt many of you often use recursion in a logical way on a daily basis, but even that can be done efficiently in lisp.

I'm still very new to lisp, and I was never a serious programmer in the past, but I've always been accustomed to asking questions, and here are a few that I'd like some input on:

• If you learned any other programming language, did you initially find the formalities of its structure to be a significant stumbling block to understanding the language as a whole? Was the same true of learning lisp?
• How much time do you spend debugging non-lisp code? How much on lisp?
• What language took you the most time to learn - was it your first?
• What feature do you consider to be the most important for an abstract language to support efficiently - and which features have you found to be most poorly implemented in lisp distributions?

I'd love to hear about what people think sucks about lisp and needs improvement - or can't be improved, so far I haven't found anything that I could complain about, the most difficult thing for me has been managing all the documentation on a half-century old language in the process of learning it. I've begun to love working in lisp, but I suppose being surrounded by a group so full of passion for it has helped contribute to my bias - if I'm wrong, help snap me out of it with a good argument against using lisp. ;)

Lisp projects and success stories?

[DeathBunny]

Lisp doesn't seem to get the "mind share" and media attention that some programming languages (C, Java, Perl) do. You don't see a lot of books and articles about Lisp and, with the obvious exceptions of Emacs and Sawfish, most people would have trouble naming major applications written in Lisp.

Why do you think Lisp doesn't get mentioned more in the computer press?

Similarly, can you tell us about any major applications written in Lisp, or any great Lisp success stories?

Re:Lisp projects and success stories?

[DeathBunny]

Most cool! Thanks for the links.

What will it take to make Lisp fashionable again?

[kfogel]

For myself and a number of friends, Lisp/Scheme programming has for too long been a kind of mystical Eden, fading in our memories, from which we have been mostly banished in our professional lives. But we can still recall how it felt to work in a language able to shape itself to any pattern our minds might ask: coding was more interesting and more expressive, and the rate of increasing returns over time was tremendous, because fine-grained -- almost continuous -- abstraction was in the nature of the language. Life was just more fun, frankly.

Alas! In our jobs and even in our personal projects, we are often forced to use C, C++, Java, Perl, or Python -- not because we prefer to write in those languages, but for two much less satisfying reasons: first, everyone else knows those languages, so we'll get more developers with them. And second, you can't count on users and testers having the right environment to run programs written in Lisp/Scheme, so right away you take a portability hit if you choose to develop in them.

Do you think there is a chance of Lisp/Scheme becoming "mainstream" again? That is, when someone contemplates starting a project, it would be as realistic for them to consider Lisp or Scheme as, say, Perl, without worrying about losing developers or initial testers? What will it take?

Re:Serious reply: What will it take to make Lisp f

[SuperKendall]

The things of it is, if (1) through (3) were really factors then I don't think Java would have taken off the way it has - Java has had those problems, though is getting over them.

I think (4) is a factor for Enterprise adoption - though I loved using Scheme in school but I'm not sure how well it would work for large projects with a lot of people.

In general though, Lisp has seemed to lack a big champion to promote Scheme and help move it into new spaces. I grew interested in Java initially because I really liked Sun, the company, and thought they might have some good ideas - in the following years Sun has done a tremendous promotoing job, but in helping make it easy for developers to choose Java and to push Java into every space, like small devices or distributed systems.

I think what also helped Java is that there is Java, the platform AND language vs. Lisp, the language. With Java you gain quite a bit more than just another nice programming language, you also get the features of the platform (like security and a wide set of standard API's) to build on.

Re:Serious reply: What will it take to make Lisp f

[Black Parrot]

> LISP needs a powerful IDE like MSCV++ with syntax-sensitive indenting, keyword auto-completion, and chroma-coding (perhaps they already do?)

Never seen MSCV++, but mere lowly Emacs does at least part of this, and could be programmed to do the rest.

> One thing that makes me shy away from using LISP for commercial product is the long pauses of the garbage collector that kicks in at unpredictable times. I would like to have a guaranteed maximum pause time.

There are lots of garbage collection strategies around, addressed to different tradeoffs, so maybe there is a Lisp implementation that uses one that will suit you.

However, in the limit, the garbage collector has to find memory as fast as your program consumes it. You could have a gc that only spent, say, 1ms whenever it butted in to do its business, but if your program is grabbing memory too fast you'd just get lots of 1ms interruptions without too much substantial computation between them. At some point your gc has to be in equilibrium with your program, regardless of what strategy it uses.

Re:Serious reply: What will it take to make Lisp f

[big.ears]

As a frequent LISP user, I think you are right about 1 & 4-- 2 & 3 would be nice, but GC doesn't bug me so much since I turned off the debugging feedback that told me every time it was collecting, and I almost never have to use non-tail recursion, and even then I find myself re-writing most recursive calls with mapcars and lambda functions.

I think the best IDE I've used is for MCL. The editor, FRED (Fred Resembles EMACS Deliberately), is probably better than the ilisp modes I currently use in EMACS (the paren highlighting keeps breaking, for instance.) Allegro's Windows IDE was pretty fancy, but was very difficult to work with. An IDE that allowed for better large-scale organization, as well as better GUI interface, could go a long ways toward reviving LISP. Something like Delphi/C++ Builder, but in LISP. But don't ask me how it would work.

LISP was commercial twice in 1980s

[peter303]

(1) The first scientific workstations were LISP-based. Symbolics and Texas Instruments sold graphics workstations in the early to mid 1980s. My recollection is that in the late 1970s Mead & Conway developed elegant software for circuit design that made it easier for programmer types to design their own computer chips. Prof. Sussman of the MIT A.I. Lab and others used this to develop a LISP-accelerating CPU (mainly typed memory and instructions). T.I. got some commercial rights and Symbolics spun off of M.I.T.

A few years later commodity chip UNIX workstations from Sun and DEC took over the workstation market. Custom LISP processors could not evolve new generations as fast as commodity chips. Furthermore, clever LISP interpreters learned to emulate LISP hardware in coventional machine languages almost as fast as the custom hardware.

(I have worked on some oil-industry software with LISP at its core because it was first developed in the 1980s when LISP machines were the only viable workstations.)

(2) The second pulse was the "Expert System" frenzy of late 1980s. Applied A.I. was going to take over the world. Japan was going leap-frog the USA in doing this first. The expert system stock bubble and bust resembled the internet stock bubble on a smaller scale. There are a couple of survivors doing interesting things such as the CYC (enCYClopedia) project in Austin TX.

The first language of the expert system frenzy was LISP. Then a language specifically designed for logic inference called Prolog was used. And finally very fast implemntations in conventional languages such as C.

What would you do differently?

[scruffy]

For a variety of reasons, Lisp and Scheme remain, in my opinion, marginal languages for computer programming. If you had the chance to redesign Lisp and/or Scheme, what would you change so that they would have become as popular as say C/C++/Java?

Language feature trickle-down

[WillWare]

I was a big Scheme/Lisp fan five or six years ago, but now I see most of my favorite Lisp-like language features available in Python, which is getting a huge amount of high-quality development mindshare these days. Some of the Lisp-ish features in Python that spring right to mind are functions as objects, closures, garbage collection, and dynamic-yet-strong typing, and convenient rapid-app development.

One needn't look far to find arguments that there is still something unique to Lisp that differentiates it even from very recent languages which have had ample opportunity to borrow from Lisp. But one rarely finds a really clear articulation of that uniqueness. Do you think concur with the view that Lisp is still unique, and if so, do you think that Lisp's putative advantage really is ineffable?

If there is an advantage but it's ineffable and therefore opaque to managers with purchasing power, that would explain why Franz, Harlequin, et al have had such a rocky road. Does the Lisp/Scheme community regard this as a worrisome issue? (Some folks on c.l.lisp clearly don't think so, but I don't know if they are just a noisy minority.)

McCarthy and Foderaro said it best

[alispguru]

John McCarthy said this [stanford.edu] in 1980:

LISP has survived for 21 years because it is an approximate local optimum in the space of programming languages.

More recently, John Foderaro said [paulgraham.com]:

Lisp is a programmable programming language.

For my money, these two together cover Lisp's enduring advantages over newcomers.

Yes, you can get many advantages with strongly typed functional programming languages. But, you can get most of their abstraction power with Lisp's first-class functions and macros, without the pain and suffering of adhering to formality. Most Lisp hackers acknowledge the utility and power of functional programming, but use Lisp anyway because it doesn't force them to do everything functionally

Yes, Java, Python and Ruby have many of Lisp's features without Lisp's syntax. But, they don't have Lisp macros, so the abstraction power of designing your own language is not available to them. I use Lisp because it allows me to take

FileInputStream infile = null;
try {
infile = new FileInputStream("foo")
// Do stuff with infile
} catch (Exception e) {
// Report error munging infile
} finally {
infile.close();
}

and replace it with:

(with-open-file
(infile "foo" :direction :input)
;; Do stuff with infile
)

and get the same level of safety, with a lot less repetitious code.

VLIW-optimized LISP

[puz]

Several years ago I wrote a term paper on my idea of a LISP machine in which CONS cells were verctorized in the CDR direction. For example, 8 cells will be stored in consecutive memory locations and the chunk will be handled by the processor as a single data unit. The hardware would be a VLIW architecture where operations will be performed simultaneously on all 8 cells. The simulation of such hypothetical machine exhibited an 8-fold speedup for list operations such as REVERSE and APPEND which encoded data in the CDR direction. There was no functional difference with conventional LISP at the user level except that REPLCD was disallowed. Also memory efficiency was somewhat sacrificed. Another conclusion from my study was that the width of the VLIW did not have to exactly match the width of the chunk in order to reap the benefit of this architecture. For example, a 4-wide VLIW could be used to process chunks consisting of 16 CONS cells with a performance comparable to this implemented with a 16-wide VLIW.

What do you think of my idea?

Lisp OS questions.

[Berkana]

I have been planning on writting a Lisp based OS, but I like Scheme's conventions, and some of it's design features. Unfortunately, there's no complier for Scheme that's fit for the task out there. Do you have any recommendations? is CL fit for the task?

What do you have to say about Lisp OSes? What do you think of the past efforts? I hear that the old Lisp machines (genera, etc.) can do cool things that even modern machines can't do, but I've never heard anything specific. Do you know what these are?

(My OS, HomunculOS (tm), will hopefully have it's own dialect of Lisp (If I can get around to doing this) that is hybridized with the best of Scheme. Modular, capability based, orthogonally persistent, only as much low level coding as necessary, for portability. Scheme shell text interface. )

Re:Lisp OS questions.

[NonSequor]

I wish you luck. An OS written entirely in Lisp is exactly what I want.

Scheme and JIT compiling

[relinquish]

I've written a few rudimentary scheme interpreters and have ideas for a new one.

I'm suprised I've never seen scheme and JIT compiling mentionned together.

First, it seems JIT compiling would elegantly solve the problems linked to eval and macros (and their specific environments). When you program a simple scheme interpreter, eval and macros actually are no problem as long as you're not aiming for speed. But they do become a problem once you start compiling code. Thus the ability of compiling a macro or an eval at execution time seems to me like an elegant solution.

Secondly, scheme's structure allows for easy code analysis that could render a JIT compiler extremely efficient.

In my opinion this could be a killer combination in provoking LISP's regained acceptance.

So what do you think - are scheme and JIT compiling a perfect match?

Lisp in a hardcore science/engineering environment

[sean-mccorkle]

I had an all-too-brief love affair with Lisp back in college in the 70s, but I never used it in my subsequent career in various scientific environments, thinking of it as an interpreter (somewhat slow) for doing symbolic processing rather than number crunching. However, a report from JPL [nasa.gov] recently came to my attention, which suggests that Lisp (using new compilers/interpreters) is competitive with Java or C++ in terms of programming time and execution speed & memory. While the authors themselves admit the study is not very conclusive or scientific, it did re-kindle my old love with the language.

Do you think its worthwhile pursuing Lisp solutions to everyday-type problems in scientific/engineering enviroment, which are numerically intensive or data-intensive? (for example, a particle physics monte-carlo simulation, or searching gigabytes of DNA sequence for patterns)

Sean McCorkle
Genome Group, Brookhaven National Laboratory

A question for Kent

[MarkusQ]

Do you have a maclisp manual I could borrow?

-- MarkusQ

Advice to Aspirants

[Anonymous Coward]

Kent,

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?

The standard process

[VP]

As participant in the standardization process for Lisp, what are your thoughts on standards for programming languages? What would you like to see different in this process? And speaking of standards, what do you think about the RAND licensing issue and the W3C?

What's in a name?

[xFoz]

I'm wondering if LISP might have been more popular if it had a name that didn't invoke a joke coming to mind every time the name comes up:

Interviewer: Do you program in LISP.
Candidate: Yeth.

Has this been a problem over the years or is it largely overlooked? Maybe there's an old story or two you could tell in this vain.

Practical Lisp

[jstoner]

I've been hearing lots lately about Lisp being used in mainstream software shops, and how it provides a powerful competitive advantage to good developers. Where would you recommend a curious, serious software engineer with real-world problems to solve start to study Lisp? Are there any good practical references (not necesarily for the Lisp novice, I can get that elsewhere) that focus on high-leverage software engineering techniques possible in Lisp? Things you just can't do in other kinds of languages?

Interactively programmable applications

[divbyzero]

One of the primary reasons why Scheme and Lisp interest me is that they are well suited for making applications interactively programmable at runtime (Scheme especially, due to its small size). This is far more flexible and useful than applications which are only extensible through heavyweight, precompiled plugins. Since the Slashdot readership tends to be made up of people who are comfortable with programatic interfaces (unlike the general computer-using public), why do we not see more such applications?

SRFIs and FFIs

[divbyzero]

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

Why LISP is doomed

[Gorobei]

In theory, everyone should be using LISP: it's fast, interactive, elegant, extensible, and reflective. Many modern languages lack its power: e.g. most "design patterns" are solutions to the problem that you aren't using LISP.

As time goes on, I get to program in LISP less and less, largely because it is being used less. I've wondered about this for some time, and here's my theory:

In the old days, when computers cost $200,000 a piece, the scarcity of hardware made the competition for the chance at a CS degree very high. Graduating required at least the ability to write a compiler, a toy OS, know how to use all the standard data structures, know algorithmic complexity, Turing machines, computability, etc. A DEC-20 supported so few users that a Uni could only graduate 40 CS majors per year: the bar was raised to the point that those making it intuitively understood that LISP expressed computation well.

When desktop machines arrived, there became a demand for programmers (people that could turn ideas in programs.) The schools could turn out more programmers because resources where cheaper for them too. CS (or IT) became as common a major as English Lit, and the bell-curve of talent was no longer chopped off at +3 sigma.

10 years ago, many new CS graduates couldn't explain what a Continuation was. Now, many can't explain how a hashtable is implemented. Moore's Law has obsoleted deep CS knowledge (and thus LISP,) as brutally as the industrial revolution killed weaving skills.

There will always pockets of LISP (the skilled craftmen working on human-scale projects,) but the vast bulk of computer programming is now carried out by people with neither the time, inclination, nor mental capacity to understand what was once Computer Science.

I wish I were wrong, but I fear programming is becoming like food: yes, there will always be some great chefs, but most people in the industry will never be able to progress beyond their fast food outlet's Fryolator.

Is Java the successor to LISP?

[Animats]

Although the syntax is very different, Java has a run-time environment that's LISP-like, with dynamic loading, run-time safety, and garbage collection. Java is now the first language taught at Stanford. Is Java now being used where LISP once was?

Re:Summary?

[bliss]

he's a man who is influential in the programming language called lisp.

Re:Linux -- Not an executable?

[raz16]

IMHO you have downloaded something for Linux, just another OS.

Re:command on the left

[Jackster]

The reason it in inside is it is then part of the list that is denoted by the parentheses, and can be more easily manipulated by a another scheme procedure reflectively. Reflection is the property that code can examine and change code at its same level of abstraction and run it. I saw an example where you could pass an expression like
(+ 2 (* x (/ x 3))) into a "derivative" method, which would examine that expression, MODIFY it, and return a completely valid new scheme method that was the actual mathematical derivative.

Very cool. The reason it could easily do this recursively is that the operators were bould with the arguments inside the same list.

Re:command on the left

[dirtyhippie]

I'd be very surprised if it modified the original, but instead returned a new one. I suppose you didn't mean that though.

Re:command on the left

[Mark_pdx]

Cadence did exactly this in SKILL (a proprietary version of LISP used in chip design CAD) and
it's absolutely awful. Your code and stack traces become completely unreadable. LISP only makes
sense like it is, with the operator inside the paren. You just need to program LISP long enough
until your brain "gets it", then you will be writing code very quickly....

Re:command on the left

[Berkana]

having the command on the left of the parenthesis is possible with lisp, but would defeat one of the great features of Scheme.

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"

Re:Which language?!

[alienmole]

My advice, based on my personal experience, is to learn Scheme and ML (try SML/NJ). Haskell is interesting, but in some ways too pure (no side effects, completely lazy). Scheme and ML cover two important parts of the functional language space, i.e. dynamically typed vs. statically typed. Scheme is a fairly easy language to get into, and makes a good bridging language to purer functional programming.

Given familiarity with Scheme and ML, most other functional languages are simply variations on these themes. Depending on what you want to do, for real-world work you might try using something like oCaml (although I find its syntax messy).

I don't think there is necessarily a *best* functional language. They have pros and cons, and I think which features are really important are still being hashed out. The existence of statically typed languages doesn't eliminate the need for languages like Scheme, for example - they excel at different things.

The best features of functional languages ultimately make their way into mainstream languages like Java etc. Automatic garbage collection, for example, has its roots in LISP. In future, you can expect mainstream languages to support things like closures and continuations (Stackless Python already does).

Re:Which language?!

[King Babar]

My advice, based on my personal experience, is to learn Scheme and ML (try SML/NJ). Haskell is interesting, but in some ways too pure (no side effects, completely lazy)

Not to prevent anybody from learning Scheme or ML, but your comments about Haskell are a bit puzzling. One of the greatest advantages of a pure functional language is precisely referential transparency, which does imply no side-effects, at least as we would think of them conventionally. Laziness has some very nice properties too (and fits nicely with transparency); moreover, if you really want more strictness for some reason, that can be gotten, too.

A really great text/introduction to Haskell is Paul Hudak's The Haskell School of Expression: Learning Functional Programming through Multimedia. Yes, that's right; Hudak's book aims to teach functional programming from the surprising angle of animation, music, graphics, and all the cool-looking stuff you'd expect to see in the latest "Java in 15 days" book.

Try it; you may well like it.

Re:Which language?!

[alienmole]

I've written real systems in Haskell, including one which does some fairly sophisticated financial analysis. Haskell is a beautiful, expressive, and concise language. But my experience has been that a completely side-effect free language can be a real PITA and hamper development in various ways. Monads and the like are an interesting theoretical construct, and I'm very interested in the theoretical aspects of mutation in programming languages, particularly the way in which it relates to capturing the concept of time.

However, for real-world development, being able to "cheat" when it's convenient, and mutate a value here and there, can be a real development timesaver. I find languages which don't let you do that to be less practical. Also, for those new to functional programming, starting out with a language that's a little less pure may make things a little easier, and avoid frustration.

The "surprising angle" of the book you referenced is not all that surprising, except possibly to a total newbie. Graphical programs are a perfect application space for pure functional programming. The raytracing competition winning entry written in oCaml a year or so ago is a classic example of this.

Re:Which language?!

[King Babar]

However, for real-world development, being able to "cheat" when it's convenient, and mutate a value here and there, can be a real development timesaver. I find languages which don't let you do that to be less practical. Also, for those new to functional programming, starting out with a language that's a little less pure may make things a little easier, and avoid frustration.

So, do you have any thoughts on O'Haskell? [chalmers.se] When I first saw this, I thought it would take over the world. But, being an academic project, it's development has progressed at a leisurely, academic pace. Which is very unfortunate. oCaml may yet rule the space, as you suggest.

The "surprising angle" of the book you referenced is not all that surprising, except possibly to a total newbie.

Yes, but it was the newbies I was addressing, albeit obliquely. :-)

OK, so the joke wasn't that funny. In any case:

Graphical programs are a perfect application space for pure functional programming.

Absolutely, but the usual imperative style for this is for-loops galore and more assignment statements than you can shake a stick at.

Re:Recursion

[Kupek]

Because sometimes, recursion is more natural and easier than an iterative solution. For a very good example of this, write an implementation of a binary tree that uses no iteration.

Because continuations are hard to implement

[phr1]

in languages like Java. (Don't say do it with
threads. Performance will be abysmal. Remember
that it's supposed to be legitimate Scheme style
to use continuations anywhere other languages
would use gotos, loops, or even ordinary function
calls, not just fancy constructs like coroutines.