Kent M. Pitman Answers On Lisp And Much More

A few weeks ago, you asked Kent M. Pitman about Lisp, Scheme, standards, and other things -- He's answered your questions below, at length. At such length, in fact, that only the first eleven of his answers are shown below -- expect more shortly! Thanks, Kent.

1) (just one thing (I) want to (know))?
by An Anonymous Coward

((
What (
(is) with (all)
) of (the) ()s?
)
Hmmm?
)

Kent M. Pitman: This question actually got scored down to -1 and marked as a troll question, but I fished it out of the barrel and restored it because everyone asks and I might as well confront the issue head-on.

Ironically it's non-Lisp languages that allow and encourage you to put ()'s in any place you want, as if there were no meaning to the introduction of gratuitous paren groups.

3+(2*5)+7 means the same thing in an algebraic language as does 3+2*5+7. In Lisp, we write:

(+ 3 (* 2 5) 7)

This shows you the structure and means you never have to learn obscure precedence rules that make expressions like -3! confusing in algebraic languages, where you must learn whether it means (-3)! or -(3!). In Lisp, the parens would show you immediately that (factorial -3) or (- (factorial 3)) was intended.

The thing I personally like about (+ (* 2 y) x) rather than 2*y+x is that it simplifies my editing. I'm a touch-typist and I use the emacs commands to go forward and backward over expressions, to swap expressions, and to delete expressions very heavily. And I don't have to reach for the mouse to manipulate large, complex expressions because they are paren-bounded. If I put the cursor at the head of 2*y+x and say "go forward an expression", ought this go forward over 2, 2*y, or 2*y+x? Having different editor commands to move across a sum, a product, etc. would be unwieldy. Yet without that, I don't see how the editor would know. In Lisp, there can't be any ambiguity because every sub-expression has its own start character, so a single notion of "the expression in front of the cursor" or "the expression after the cursor" suffices.

This, by the way, also answers the question of why we don't write foo(x) and instead write (foo x). In Lisp notation, foo is an expression. In the expression (foo x), it's a subexpression, so it's enclosed within it. Were it outside, a text editor would not be sure if foo(x) were one expression (a function call) or two expressions (the symbol foo followed by the list (x)). That would make going forward over 'one expression' ambiguous when at the start of foo(x). Should the cursor end up after the foo or after the (x)? In other words, The natural purpose of parentheses is to enclose things, so that's what Lisp uses them for. Avoiding ambiguity is critical to the writing of correct "keyboard macros" in Emacs, where I might interactively write a program to do a lot of code transformations quickly. In an algebraic language, such keyboard macros can be much harder to write robustly.

2) It's not just me is it?
by demo9orgon

After trying to "self-learn" lisp in the 80's I get this physical reaction to the word "lambda"...a cold sweat combined with the involuntary retraction of my testicles to a protected location in my abdomen (damn unpleasant shit)...I usually avoid that second one by mentally going through the mechanics of "hello world" in C, or any half-a-dozen other programming languages.

Lisp is one of those meta-languages you either learn or avoid. I write practical stuff all the time, daily in fact, and I've never had something that required the arcane stuff in LISP.

KMP: Actually, "hello world" in Lisp looks like this:

(defun hello-world ()
(write-line "Hello, World!"))

I don't know about you, but I find that pretty soothing.

And as to LAMBDA, one only needs use it when they find it useful. For example, after a while, one sometimes gets tired of writing a separate function where that function will only be used once, as in:

(defun sort-by-name (list)
(sort list #'name<))

(defun name<(name1 name2)
(or(string<(last-name name1) (last-name name2))
&nbsp(and (string= (last-name name1) (last-name name2))
(string< (first-name name1) (first-name name2)))))

so Lisp allows one to instead say:

(defun sort-by-name (list)
(sort list #'(lambda (name1 name2)
(or (string< (last-name name1) (last-name name2))
(and (string= (last-name name1) (last-name name2))
(string< (first-name name1) (first-name name2)))))))

Whether one actually does this is purely a personal preference. Some people like having separate named functions, some don't. Sometimes the separately named function might have a nonsensical name, though, and it's nicer not to have to invent a stupid name for a one-shot use.

Now, as to why it's called LAMBDA and not FUNCTION, that's just a piece of history. You get used to it. Toward that end, I'll offer a story that will perhaps help you put it in perspective:

Early in my not-yet career as a computer scientist, which is to say, while I was in high school, I lived in the Panama Canal Zone. Computers were not at all common there at the time. In fact, the place being entirely run by the US Government, there was some weird edict that said no one was allowed to own one so that they would all be centralized in the Comptroller's Office and not wasted in individual offices around the Zone. Our school had to bend the rules in order to get us a computer to study. So one thing I did while trying to learn about computers was to go downtown (out of the Canal Zone into Panama City, in the Republic of Panama) and visit a company there who did computer work. Of course, people there spoke Spanish, but fortunately I did, too. They showed me some of their code, and I was immediately struck by the fact that all the language keywords were in English.

"Doesn't that bother you?" I asked. But the person I was talking to was quite a thoughtful person and he immediately responded this way: "Do you know how to read music?" "A little," I said. "Have you seen the notations on music like forte, sotto voce, and so on?" I nodded. "Does it bother you that they are in Italian?" "No," I had to admit. His point was to make me see that it could be viewed as part of the charm and history of the notation. He was, perhaps, unusually forgiving. But this was in the late 1970s, when everyone who had access to computers was far too excited about just plain having them to care about subtle issues of whose culture got too much say in the design of a world-wide phenomenon.

So when today I look at the very few mysterious-looking terms like LAMBDA, CAR, and CDR that still linger untouched in modern Lisp's design, I think of them as I do those musical notations, conceptual links to a little piece of history that I'm just as happy not to see crushed by an overeager rush to regularize and homogenize the world--something the computer culture has done altogether too much of.

3) Interactively programmable applications
by divbyzero (divbyzero@hotmail.com)

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?

KMP: I think it's just an issue of education, formal and otherwise. Without being explicitly guided, some people will try out all kinds of ways to do things, or invent them where they're not present. But many others will simply do what they have been taught to do without exploring the alternatives.

In the past, everything was about speed. Every instruction was precious. The focus was entirely on "micro" efficiency. People would examine the cost of being able to redefine something (which sometimes involves as much as following pointer indirection), and if there was a cycle lost, the game was over. Today, hardware cache and prefetch architectures can often hide such costs anyway, but even if they couldn't, processors run so fast that one has time to worry not only about micro efficiency but also macro efficiency--that is, "running smart", not just "running fast", as a way of assuring total efficiency.

A lot of people identify Lisp as a language that is "just good for Artificial Intelligence (AI)". Certainly Lisp is good for AI. But saying it is just good for AI misses the point. Lisp doesn't do AI. Lisp is a programming language. AI researchers program AI, and often their language of choice has been and continues to be Lisp. But the important thing is that AI researchers have been banging on the door of Lisp implementors for years, demanding the introduction and tuning of the features and constructs they need in order to get their work done. Lisp hasn't become a mere AI toolbox as a result of that. Rather, it has become a robust tool for addressing the world's most complex and vexing problems. The Lisp community has a long experience with supporting "intelligent programming", and with doing so efficiently.

Lisp's biggest problem in the past is probably that it hit its commercial peak too early, in the mid 1980s, before most computational problems the world was confronting were big enough to need the power Lisp had to offer. Those were the days of MacWrite and MacPaint and Lotus 1-2-3, and it just didn't make any difference whether one used Lisp or C for those. But for better or worse, the world has grown up around us, and the important problems of the day are a lot more complex. I think Lisp has a lot more to offer to the world of today than it ever did in the past.

4) The standard process
by 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?

KMP: I think standards have served their time to provide a stable base for people to build on, but for the modern environment, they move way too slowly to keep pace with the speed of change in business. It took a long time to put the Common Lisp standard together. We began in 1986, finished work in 1994, and got the actual document to press just before the end of 1995. Getting community consensus on something that big really does take that long, and I think it was an exercise worth doing to create the stable base that we created, but for future evolution of the language, I think there needs to be another way with far less overhead.

I see standards as having two components: The first is to simply cast a name into concrete so that reference to that name will always have a clear meaning. The definition of ANSI Common Lisp, at least for 1994, is now permanently registered. Anyone who wants to can now conform to that definition and others will know exactly what they mean by that. The second component is to assert an informal consensus in the community that there is a single right way of doing things. This latter component may be useful for the foundation (to define the initial market space), but I'm not sure it's appropriate for the library level of the language.

For the base language, if 60% of the community wanted to do things one way and 40% another way, the 60% got to roll over the 40%, and 100% of the community was expected to do things in the way that won. But at the library level, if 60% want one library and 40% want another, I'd rather 100% of the community get what they want by having some people just do it one way and the rest of the people do it the other way. The Lisp community has not traditionally done things that way; they've sought consensus. The Scheme community has been even more conservative about this than the Common Lisp community, and as a result has even fewer standardized facilities than the Common Lisp community.

The Scheme community has moved to a more loose-knit approach to break the design deadlock brought on by the core language committee's consensus process through its Scheme Requests for Implementation (SRFI) process. The Common Lisp community hasn't got anything quite so organized yet, but I suspect will eventually evolve something similar.

As to the question of the W3C, I'm not a huge fan at the moment. At a prior employer, we had the opportunity to join, but the contract we'd have had to sign made it clear that votes among members were advisory only, and W3C itself could decide to override what people voted on. This, to me, is not a consensus body. Furthermore, although I think standards bodies like ANSI move in near glacial time, I don't think you can fix things by just shortening the times. True national and global consensus just takes time, and shortening timelines doesn't just make things move faster, it also disenfranchises people. While I use the existing HTML, CSS, XML, XSL, and other W3C guidelines, I don't feel they were created in a manner that I respect as proper consensus process. I think the process was insular and rushed.

Neither am I happy with the notion of processes involving Reasonable and Non-Discriminatory (RAND) fees being part of a standard; I think consensus standards should only involve royalty-free (RF) technologies. I think adherence to standards should not induce a baseline cost beyond the cost of creating the code so that the cost of compliance with standards can closely approach zero. If there is a profit to be made on the implementation of a standard, it should go to the implementor, not to a patent holder. Then again, while I'm a strong proponent of software copyright, I'm not at all a fan of software patents. Rather than seeing independent creation as infringement, I think independent creation should be contributory proof that an idea was more obvious than perhaps the patent office thought. I don't mind copyright because there are ways that one can demonstrate that one did not merely copy another's work, and independent creation is a defense.

5) Advice to Aspirants
by An Anonymous Coward

Kent, I am one of the lucky ones who programs professionally 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?

KMP: Well, one thing to note is that there's very little overhead to just downloading an implementation and diving in. Not only do the major commercial vendors like Xanalys and Franz offer high quality, no-cost trial versions of their proprietary software, but there are quite a number of free (non-proprietary) versions of Lisp as well. Information about these, as well as much other useful information about Lisp, can be found at the Association of Lisp Users (ALU) web site. I've also recently purchased common-lisp.info, which I plan to maintain as a repository for information about Common Lisp; the site doesn't have a large base of information yet, but it does have a list of the problem spaces in which you might consider using Lisp.

The ANSI Common Lisp standard, effectively available in webbed form as the Common Lisp HyperSpec, is indeed a big document (about 16MB and having about 108 kilohyperlinks downloadable). I think it's fairly readable as standards go. But you're right that it takes some work to get through and it wasn't really intended as a tutorial.

The ALU web site will also have pointers to books and online tutorials about Lisp. Books by Paul Graham and Peter Norvig on the subject are very highly regarded. I think there is always room for more, and I'm working on several, at least one of which I hope to complete in the not too distant future; feedback from you and others is useful to me in understanding what areas most urgently require treatment.

One resource that some people might find useful is an article I wrote called Accelerating Hindsight: Lisp as a Vehicle for Rapid Prototyping. This article is intended primarily for a Lisp programmer audience, to help them articulate some of the ideas you've asked about to others. It was not intended to be read by the audience you'd like to convince mainly because it appeals periodically to Lispy notation that might not be familiar to them, but it may still be of interest to the adventurous non-Lisp reader.

As your project becomes more sophisticated, and evolves from a personal toy to a real commercial product, it also doesn't hurt to ask an expert for help. My company offers consulting services that include helping companies manage the transition into Lisp. One of my major clients, The Software Smith approached me on just such a basis and the result has been very exciting both for me (getting to help them improve their system) and, I think, for them (getting to see more of how Lisp is supposed to be used). I don't want to turn this interview into a huge advertisement, but people can contact me for more information. If I'm either not competent to help you or am too busy to help you, there's a very good chance I can refer you to someone else who can help you.

6) Language feature trickle-down
by 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.)

KMP: I guess I think Lisp is unique, but whether it is or not doesn't affect its usefulness as a tool. I'll enumerate some things I like about Lisp, but Slashdot readers shouldn't assume that I'm asserting for each of these features that Lisp has a lock on these. Various other languages surely have some of these. But I am often heard to say: languages are ecologies. Language features are not a priori good or bad. Rather, language features are good or bad in context, based on how well they interact with other language features. Some of what makes Lisp what it is has to do with the features it offers, but some of what makes Lisp what it is has to do with how the features work together to make a coherent whole. Lifting some of these features out of context might sometimes work, but in other cases, it might not. To get a real feel for Lisp, or any language, I think you have to really use it.

Also, in my 1994 article Lambda, the Ultimate Political Party, I advance the hypothesis that languages are defined as much by their community as by their semantics. That is, languages are forever in flux, and the semantics you read about in a language spec is a point in a multi-dimensional space telling you the current location, but it does not tell you the velocity vector in that space. For that, you must look to the community. Even if two languages happened to occupy precisely the same point in design space, that is, if they had the same semantics, would they continue to over time? I think not.

For what it's worth, here are just some of the things I personally like about ANSI Common Lisp:

• Lisp is dynamic. The world is ever changing and it's useful to allow programs to change dynamically with it. I can load new or changed functions, classes, and method definitions into a running image that I'm debugging, or even in a deployed production application. When I do, the code that was running will immediately start using the new definitions. Classes can be redefined even if the new class has different slots, and, if I care to, I can control how the update is done from old to new slot arrangements for already-created instances. This kind of thing supports programs that must be continually running yet must be responsive to changes or even just bug fixes.

• Lisp is introspective. Not only can functions, packages, classes, methods be dynamically added, redefined, or removed, but programs can also inquire about whether aspects of the programming environment (functions, packages, classes, and so on) are defined, can manipulate those objects as data, can save them away, can transform or encapsulate them, etc. Also, the Lisp compiler is a standard part of the language and can be invoked even at runtime by applications that need to augment themselves. New programs can be created on the fly, then compiled and loaded and executed in the same running image as they were created, without ever exiting (and even without doing file I/O). This facilitates automatic programming and the development of layered languages.

• Lisp's syntax is malleable. There's nothing worse than being stuck in a syntax that you don't like in a language you're going to use for a long time. Lisp allows programmers to reconfigure the syntax rules for parsing characters into data and programs, as well as allowing macro technology that transforms one parsed program expression into another. And it allows control of how data is displayed during program execution and debugging. Moreover, this can generally be done in such a way that one programmer's customizations don't adversely impact another's. This makes interactions with Lisp more pleasant and debugging sessions more productive.

• Lisp doesn't force users to use variable type declarations in order to just get a program to run. The initial focus in Lisp is on getting programs working. You can add type declarations when you're done if you want to, in order to enable additional compiler optimizations. This facilitates rapid prototyping by first getting an application running quickly with low overhead, and then allowing an application to be tuned as a second pass operation.

• Lisp has a powerful class system, and a flexible meta-class system. The class system allows powerful slot and method definition, method combination, and a great many other detailed features. The meta-class system allows users to treat the object system as data that can be programmed, creating new kinds of classes.

• Lisp gives the user powerful tools for both signaling and handling errors. This means that when an error occurs, there are often a variety of ways to continue programs other than simply aborting or dumping core. Moreover, object-oriented error handling allows programs to represent errant situations, evaluate the options for how to proceed, and select an appropriate option under program control.

• Lisp uses automatic memory management. This means that when a programmer is done with an object, they just let go of it and the garbage collector reliably frees its storage. This means Lisp programs do not suffer from the memory leaks that commonly plague programmers in many other languages.

7) What will it take to make Lisp fashionable again?
by 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?

KMP: First, let me say that I really appreciate the poetic description you offer in the first paragraph above. I very much think that captures how I and others think about the experience of using Lisp.

And as to the future of Lisp, I think the situation for Lisp is looking pretty upbeat these days. Enough so that my own infant business is building its tools in Lisp, both for sale and for our own internal use on products we produce.

There are a lot of implementations, both commercially maintained and "free", with a wide range of delivery options, from conventional executables to "remote" solutions: Some implementations support CORBA and/or COM interfaces, for example. Also, most implement some kind of sockets interface, and there are several Lisp-based web servers available that build on this. Lisp programs can dynamically load DLLs, or can be delivered as DLLs themselves. They can do "foreign function call" to functions in other languages. It can also communicate with databases, and so with other programs via databases.

As the world moves increasingly to high-bandwidth global connectivity, I think the issue of the delivery environment will become less important. People have been waiting for an e-Service based society to take off, and it hasn't quite done that yet, but I think it's coming. I can't see how it won't. The overall savings in quality assurance and support of not having to re-deploy an application in a hostile customer-premise environment will be a lot, just as your question implies. One will just bring an application up on the right kind of hardware, connect it to the net, and then forget about where the program is actually being used. That may be an oversimplification today, but I wouldn't waste my money betting against it for tomorrow.

8) Questions I've Come Across Learning Lisp
by 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 accommodating 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. ;)

KMP: I knew FORTRAN and Basic before I learned Lisp. And I've dealt with numerous languages of all kinds since learning Lisp. With most, the syntax itself is generally not a burden. Some languages have more pleasant syntaxes than others, but the human brain has an amazing ability to cope. Of all the many languages and syntaxes I've seen, about the only thing I've never been able to cope with is the "*" used to notate indirection in C. I understand thoroughly the notion of pointer indirection, and the difference between "pointer to array" and "array of pointers", but I find it forever hard to read and write that particular awful notation for some reason. Give me Teco or Perl any day.

Mostly, though, I think the issue of how hard a syntax makes it to learn a language is overblown. Humans have brains that are adapted to processing myriad special cases and can mostly cope with obscure syntaxes. The real issue is how hard it is for humans to pass on their knowledge to programs. People are good at judgment, and programs are good at repetition. Over time, though, judgment tasks become repetitive and it's time for programs to take them over. I like to write macros to package up things I do a lot, and the key to that is having a reliable mapping between program syntax and program structure. The last thing one wants is a macro language based on character syntax, since such syntax is too unpredictable. Lisp offers macros based on program structure, and that greatly reduces the number of programmer errors one makes in macro writing.

As to debugging, I try to use non-lisp code as little as possible because of how hard it is to debug. Most other languages don't have good visual representations of their data, so when I get in the debugger, the manner in which I am presented with errant data is usually low-level and hard to read. A great deal of my valuable time is spent painstakingly piecing structure back together. But in Lisp data objects have familiar visual representations and I find it's usually easier to see what has gone wrong.

What language took me the most time to learn? Probably Teco. There was a lot of trivia to learn there. What language took the least time? Probably FORTRAN, BASIC, Lisp, HyperTalk, and MOO. Fortran just because it was small. The others because they are highly interactive, which is a huge boon to learning.

Actually, I learned PostScript very fast, too. There are some excellent cookbooks on this. But I never learned to debug PostScript. When my programs erred, I mostly just wrote them anew and hoped they'd work then because debugging was too painful.

What do I consider it most important for an abstract language to support efficiently? My time. Time is the only true, non-renewable commodity. I eschew languages like C because they often waste enormous amounts of my time trying to develop and debug programs, and justify it on the basis of micro-differences in speed that have just never ended up mattering to me. I regard C as appropriate for use as an assembly language, but it doesn't provide enough high-level services for me. When I'm old and grey and look back on my life, I want to have done a lot of interesting things, not just have done a few interesting things but "boy were they fast".

I think it's important to pick a language not on the basis of how fast its implementations are today, but on the basis of how much they do what you want. Lisp has an undeserved reputation for being slow, which I think results from deciding to make it do things that there are not always known optimizations for at the outset. Like garbage collection. But as Lisp is used, people complain about the things that are slow, and fixes get found. So Lisp moves ahead. If Lisp had started instead only with the things it knew how to implement efficiently, it would be holding things back. I want my ideas to lead my technology and my tools, not to have my technology and tools leading my ideas.

9) Basis set for programming languages?
by 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.

KMP: Well, continuations are just functions. What's really lacking to make this easier is good tail call support so that continuations can be called correctly without pushing stack.

I don't really have personal experience with using the JVM directly, but my experience with the MOO programming language led me to believe that there might be a problem with integrating tail calling and security, since sometimes security is implemented by asking "who called me?" and tail calls can mean that the apparent caller is not the real caller. So I asked my spies at Sun about this.

I'm told that the original security model for Java worked the way I expected (by examining the call chain), and that concern over consequent security matters contributed to the absence of tail calling support in early releases. But apparently it was conceded a long time ago that such support should be added some day, and that day simply hasn't come yet. So perhaps there is hope.

Even so, I'm not so sure no matter how hard you try that you can just paper over the many differences between languages and say that the only remaining issues are ones of syntax. I do think you can probably get to a point where all languages can compile to this machine, but that may not always mean that programs in one language are as efficient as those in another, or that data structures in one language are as naturally represented as those in another. For example, both Lisp and Scheme assume that small integers (that would fit in a machine number) are still integers; they don't have the int/Integer disjointness that Java has. A Lisp-to-JVM compiler could presumably hide this distinction, but it would be wrong to say that the only difference between Java and Lisp was syntax--there are really some material philosophical disagreements between the two languages.

10) Scheme as an XML Translation Language
by Evangelion

I've become fairly interested lately in using Scheme (probably mzscheme) and the SXML 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 curiosity while the world struggles through parsing XML in Java?

KMP: Are those my only two choices? The second one sounds awfully bleak. I'd better choose the former.

I don't know whether you'll see XML as a formal part of either Lisp or Scheme any time in the near future, but a lot of that is because the standards bodies administering these are not extraordinarily active at this time. That doesn't mean the languages are dead, just stable. Ongoing work is mostly happening at the level of libraries, and such libraries can generally be written by anyone using existing primitives, without modifications to the core language.

Lisp manipulation of XML and HTML is something people have been working on for a long time. For example, the Document Style Semantics and Specification Language (DSSSL) was a purely functional, side-effect free variant of Scheme. Even XSL, the apparent replacement to DSSSL, offers the same kind of functionality. It just uses a more CSS-like page model and XML syntax. But, conceptually, it's Scheme inside.

In my recent professional life, I have personally written several XML parsers, all in Lisp, for various employers and most recently for myself and my fledgling company. My company's implementation is not available on the market yet, but when it is, I'm quite sure the chief competition will not be around the availability of mere "availability". Already there are a variety of libraries related to XML, XSL, and SAX floating around. And I'm quite sure there will be more to come. Competition will be over things like efficiency, robustness, representation, and optional additional features.

11) Lisp vs. the world
by 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.

KMP: There are so many things I like about Lisp, but most of them come under the heading of "doing things in the right order."

For example, type declarations in many languages are required but in Lisp they're optional. I prefer to first get my program working, and only then to tune it to be more efficient by adding type declarations. What's the point of doing a lot of make-work declarations if you're not even sure you're going to keep the result? I do a lot of exploratory programming just to answer "what if" questions. I also write lots of little throwaway programs just to compute a simple result. I don't need such programs to run in 5 microseconds instead of 10.

I also view the process of programming as a series of "times" at which decisions can be made: "coding time," "parsing time" (Lisp calls this "read time"), "macro expansion time," "compilation time," "load time," and "execution time." Lisp gives me a great deal more control for each piece of code as to when it runs, so that it can run at the appropriate time when the data it depends on is known. Other languages, especially statically typed ones, often make me specify information too soon, before it is really known, which usually means "making up" answers instead of really knowing the answers. Sometimes that makes programs run faster. Sometimes it just makes them run wrong.

And I like Lisp's willingness to represent itself. People often explain this as its ability to represent itself, but I think that's wrong. Most languages are capable of representing themselves, but they simply don't have the will to. Lisp programs are represented by lists and programmers are aware of that. It wouldn't matter if it had been arrays. It does matter that it's program structure that is represented, and not character syntax, but beyond that the choice is pretty arbitrary. It's not important that the representation be the Right® choice. It's just important that it be a common, agreed-upon choice so that there can be a rich community of program-manipulating programs that "do trade" in this common representation.

I write a lot of macros because there are a lot of interesting things one can do with macros in Lisp. In other languages, macro-writing is a process of manipulating strings containing input syntax. That feels very unreliable and I've never liked that. Lisp's willingness to represent its code in known data structures makes macro writing feel a lot more reliable. And the presence of macros in Lisp generally means that the boring parts of coding get removed, because repetitive patterns usually get captured by a macro and hidden away, keeping the developer's attention on the "interesting parts", and making the activity of programming itself both more fun and more efficient.

Could other languages borrow some of Lisp's strengths? Sure. And they do. Java, Dylan, and I suspect even C++ have all borrowed ideas from Lisp. But that's ok. We'll make more. And anyway, it's not a zero sum game. Everyone benefits when there's this kind of cross-pollination, whether it's Lisp influencing other languages or vice versa.

Weaknesses of the language? Well, that's harder to say. I think the basic design is quite strong. Sometimes you see an implementation that has put more energy into some parts of the language than others, but usually that has created a market opportunity for another, so overall we have our bases covered.

For example, you might find some implementations that have big "hello world" footprint sizes compared to "hello world" in other languages. Some in the Lisp community, don't think this matters much, because disk and RAM are getting ever cheaper. "Real" applications (i.e., not "hello world," but something meaty) of 5-10 megabytes are pretty commonplace these days. Years ago, Lisp used to be seen as large, but due to such criticism, Lisp has held its size constant in the last decade while other languages and systems have bloated rapidly. So nowadays, Lisp is comparatively quite small. And even still, if you don't like the size you get from one vendor, it seems there's always another trying to squeeze into the niche of addressing your need. Corman Common Lisp (an up-and-coming commercial implementation) and CLISP (a GPL-style "free" implementation) have given special attention to this issue. So there's a vendor for everyone on the size issue. And, though I deal more often in Common Lisp in my day-to-day work these days, I would be remiss if I didn't mention that image size is also a key concern of the Scheme language community, so that's yet another way the size issue is addressed for those who see it as critical.

Some might have heard that Lisp, being dynamic, doesn't make use of static type information. This isn't quite right. In fact, the language doesn't require static type analysis, it merely permits it. This gives a lot of leeway to each implementation to address the specific needs of its own customer base. The CMU Common Lisp implementation has, for example, addressed the issue of type analysis in great detail and offered a clear demonstration that there are many exciting things that implementations of Common Lisp can do with type declarations if they choose to.

Why don't all implementations optimize all of these aspects--footprint size, static type analysis, etc.? The Common Lisp language is admittedly conceptually large and correct, efficient compilation requires considerable time and cleverness to implement. "Why not make the language smaller so it requires less work to implement?" is a query you hear a lot from the outside, and even from members of the Scheme community. The answer from the Common Lisp community amounts to this: Programs are written all the time, but implementations are written much more rarely. What the implementation does not do is left for the user. The more hard work the language does, the less hard work programs do. In effect, the thesis of Common Lisp is that bigger languages make for smaller sentences in the language. (To see that there is at least some intuitive basis for this, think about how long a novel like Gone With the Wind is in English, then try to imagine whether the same novel re-expressed in Esperanto would be longer or shorter.)

If a language offers only what a programmer could implement overnight, it gives its programmers not much of a leg up on their final application. Many members of the Scheme community boast that they have written a Scheme implementation, while many Common Lisp programmers have not. Common Lisp is surely harder to implement, but the Common Lisp community does not see as its primary purpose to put out legions of implementors, each with their own easily-created implementation. The Common Lisp community has chosen to be about commercial applications, and its designers have provided a "meaty chunk" of useful power for programmers to use, with the promise that if programmers write their programs to that standard, not only will those programs work well today, but as implementations get better, those same programs will work even better tomorrow.

[to be continued...]

Comments

Good to see Lisp is still around.

[Anton Anatopopov]

As long as these languages are kept alive by their dedicated users, there is always the chance that the suits will see the light, and go for the productivity gains offered by high level languages.

I have never recovered from learning Smalltalk as a postgraduate, and then being forced to take a job programming in C++ because corporations are so far behind the times.

I look forward to the day when programmers in large corporations are able to use high level languages such as lisp, scheme and smalltalk instead of the current crop of low level languages like C++ Java and Perl.

Re:Good to see Lisp is still around.

[Anonymous Coward]

It's not just the language. Smalltalk was extensively adopted by JP Morgan in the early '90s. APL was used by Morgan Stanley. UBS even attempted to create their own language, 'K'.

But despite all of these efforts, Wall Street continues to use C/C++, VB and Java. Why?

Re:Good to see Lisp is still around.

[Anonymous Coward]

Programmer demand, maybr?
Speaking of Wall Street, look at the most effective programming shops. Are they using Smalltalk, APL, UBS? No, their using C/C++, VB, and Java. Surprised?

Re:Good to see Lisp is still around.

[kin_korn_karn]

C++, Java, and Perl are low-level like my dog is a cat. C is low-level (or with better libraries, mid-level). Anything that supports objects or runs in a virtual machine cannot by definition be low-level because there's too much abstraction of system functionality between the source and object code. Just because C++ still lets you twiddle with bits, doesn't mean you HAVE to.

Productivity is also a huge judgement call. One judges productivity by familiarity; I don't think there's a programmer at my office that knows Lisp (too old), Smalltalk (most are self-taught or consultants), or any of these other obscure languages. Businesses don't choose languages for the 'fun factor'.

Re:Good to see Lisp is still around.

[connorbd]

APL? Ugh... You want some real fun, though, take a look at BANCstar, which is very possibly the nastiest thing I've ever seen in a commercial setting. /Brian

Re:Good to see Lisp is still around.

[omigod!kenny]

"One judges productivity by familiarity" If for the sake of argument an unfamiliar language once mastered makes one much more productive, then one should overcome the unfamiliarity, not carry on with inferior tools. So the question reverts to how powerful is Lisp, not how many batch COBOL programmers are out there.

Re:Good to see Lisp is still around.

[Unknown Lamer]

C++, Java, and Perl are low-level like my dog is a cat. C is low-level (or with better libraries, mid-level). Anything that supports objects or runs in a virtual machine cannot by definition be low-level because there's too much abstraction of system functionality between the source and object code. Just because C++ still lets you twiddle with bits, doesn't mean you HAVE to.

What! For one, C++ is almost 100% compatible with C89 (just some type stuff, C99 also has some other stuff like restrict and _Imaginary and stuff). C++ is horribly low level, when compared to LISP. I tried to implement an "abstract" plugin model for a media player (shut up! Everyone thinks the world needs a 10,001st console media player) in C++. I failed. Why? The details. The damn little details. To achieve the abstractness that C++ programs are supposed to have, I had to bend over backwards. Now, after learning Scheme (and GOOPS) and some clisp, I relized how easily the same thing could be done with GOOPS or CLOS. Sure, I would have to write some wrappers (oh wait, SWIG can do this for me) to access available libraries, but the time that would be saved in the long run would offset that. Now, if only I could find something that wouldn't piss people off when I released it (not even I need another media player!). Now, Java and perl might be a bit higher level, but in C++ you almost always have to deal with low level things. Now, there are some libraries (i.e. the STL or Qt) that can save you from some of the low level stuff, but I doubt that you will go through an entire program without dealing with something like, say, memory managment (which you can ignore in most LISP dialects).

Re:Good to see Lisp is still around.

[Macrobat]

C++, Java, and Perl are low-level like my dog is a cat.

I gotta say it, C++ is the catdog. If C is low-level, then C++ can be.

Just because C++ still lets you twiddle with bits, doesn't mean you HAVE to.

This could be paraphrased as, "Just because you don't HAVE to twiddle with bits, doesn't mean you CAN'T."

Remember, C++ doesn't force you to use its OOP features, so you can work efficiently and at a low level pretty handily.

Re:Good to see Lisp is still around.

[kin_korn_karn]

I'm sure Lisp is very powerful. The problem is that Lisp advocates sell the concepts and not the applications. Java took off because Sun said, "here's our language, this is what you can do with it." Not "here's our language, and it's better than yours." There's a confrontational style to the advocacy of Lisp, and other high-concept languages, and that doesn't sit well with CIO types. They want to know what it does for them that the old tool didn't, not why you, in particular, like it.

Re:Good to see Lisp is still around.

[kin_korn_karn]

All good points... the fact that you can write a low-level program in a language doesn't make it a low-level language, though. low vs. high level is a function of the distance from machine code, and this:

cout "Hello World";

is much further from machine language than this:

printf ("Hello World");

How? Well, the concept of redirecting a string into a stream object that's attached to STDOUT is a lot more abstract than "print this formatted string to STDOUT", even though the end result is the same; characters get copied into video RAM or sent over *getty to *term.

*shrug* it's one of those unwinnable arguments.

More Lisp

[JustJoking]

I wish that lisp was focussed on more in CS curriculum. It has far more potential in the future for doing useful things, as opposed to just doing things fast (java).

Re:More Lisp

[spellcheckur]

Beautifully, MIT's "intro" freshman CS class, Structure and Interpretation of Computer Programs is taught in Scheme.

There as been a significant amount of pressure (from both non-CS administration and some CS-because-it-pays-well,-not-because-I-want-to-lea rn students) to change to Java or some other "real world" language, but thankfully, the instructors haven't given in.

The differentiation between good programmers and bad, isn't in the number of languages they "know." Programming is a methodology, and Lisp/Scheme is a great tool to teach it.

Re:More Lisp

[Pengo]

Hehe,

My friend who graduated from Harvard said that he wished he learned Java instead of Lisp so he could of learned something he would use in the world.

I know that you learn and take more than details of a language, but his point was not unfounded. Depends on what you go to school to learn and do. Maybe you should choose your school based on your goals in education. His happened to be one that didn't see a lot of value in learning lisp.

Oh well.

Re:More Lisp

[the_2nd_coming]

that is the thing I wish Unis would learn. the point of being in school is to learn the fundamentals and the theories, what you do out side school is apply those things you learned to the real world. people should be able to pick up a language, after learning to program, quite easy. If they got a job that requires them to know C++ then they have a good motivation to learn C++.

Re:More Lisp

[sv0f]

My friend who graduated from Harvard said that he wished he learned Java instead of Lisp so he could of learned something he would use in the world.

Learning Common Lisp as an undergraduate at CMU in the late 1980s changed my life for the better. I guess to each his own.

Then again, isn't one of the goals of a CS degree to expose you to a variety of computational paradigms? Lisp is quite unlike C, C++, Objective C, and the like. Certainly worth a semester or two of exposure.

Perhaps it is your friend that has the problem if all he could handle in college was one freakin' language.

Re:More Lisp

[NetSettler]

I address this issue in the second part of the interview, to appear in a day or two. In brief, though (for once): I agree, learning more languages (and more kinds of languages) is better than learning fewer. Don't decide between them. Learn both.

Re:More Lisp

[egomaniac]

Lisp also has amazingly limited real-world capabilities compared to Java.

I'd like to see, for instance, a word processor written in Lisp. Seriously -- something compatible with Microsoft Word. An action game with sophisticated graphics, including transparency and particle effects? How about an MPEG decoder, or an MP3 player? What about 3D shooters? I'm certainly not saying they aren't possible, and for all I know they might even exist, but I know I can find all of those for Java inside of two minutes.

Lisp doesn't have a toolkit equivalent to Java 2D + Swing, and I seriously doubt it has anything equivalent to Java 3D, the Java Advanced Imaging API, or the Java Media Framework.

I'm not insulting Lisp the language, but the fact is that its libraries are woefully inadequate compared to Java's. Lisp programmers have had twenty-odd years to come up with decent libraries -- so where are they?

Re:More Lisp

[sv0f]

I'd like to see, for instance, a word processor written in Lisp. Seriously -- something compatible with Microsoft Word. An action game with sophisticated graphics, including transparency and particle effects?

If you seek in-principle proofs, all of this and more existed for Lisp Machines of the 1980s. they still exist, in fact. Nichimen sells a graphics/game engine for Ninetendo written in Lisp. There's a commercial game for PC available right now that is partially written in Lisp. I don't have the time, but I'm sure a quick Google search would reveal positive answers to your questions if you care to look.

You do bring up a good point. While this stuff is possible in Lisp and has been done, it's not done now. Bad PR associated with AI Winter has left Lisp reeling in this (i.e., graphics and GUIs) regard.

(I really gotta go!) Have a look at CLIM for a cross-platform graphics library for Common Lisp -- Windows, Unices, the Mac. But it's probably fair to say that Lisp is for other parts of your application at the moment, just as a game is part assembly, part C, and part other languages. Write the parts that can be elegantly written in Lisp in Lisp.

Re:More Lisp

[Anonymous Coward]

Java's libraries are indeed rich, perhaps the richest set of standard libraries available for any language. But the reason for this is Java's specific VM model -- Sun had to provide all of the facilities usually found in the operating system, as well as more "standard" standard libary tools such as file IO and complex data structures. Java goes beyond this and provides networking, a GUI windowing system, database access, et cetera... things provided by the OS in "normal" UNIX and Windows system programming.

Lisp is a great tool for folks who want to program without actually interfacing with the computer. In that respect, it is comparable to Visual Basic and Delphi. But the "real" work will continue to be done in C (because nothing else provides the same combination of speed and portability) and C++ (because nothing else provides the same combination of speed, portability, and modern programming methodology). Note that all "real" applications -- from word processors (Microsoft) to games (id) to databases (Oracle) are written in C and C++.

Java is interesting. It is so heavily based on C++ that C++ programmers can't help but feel comfortable using it, but at the same time it adopts such "loser" features as garbage collection, and eschews direct memory access.

(Just like Lisp.)

I don't think that niche languages such as Lisp should be taught in undergrad CS. I wasn't a CS major, because, just by being a geek, I learned more about computing than most BSCS folks know. The fact is that nothing "interesting" is taught until the grad level. Undergrad CS should focus on "real world" tools that students will use to get jobs once they graduate, and save the fancy theoretical stuff for grad school.

Of course, I disagree with the concept of CS as a major to begin with. It manages to take the most basic parts of engineering and analytical mathematics and combine them in a fashion that makes CS students ill-suited for both real-world and scientific work.

Re:More Lisp

[NetSettler]

Re: Lisp doesn't have a toolkit equivalent to Java 2D + Swing, and I seriously doubt it has anything equivalent to Java 3D, the Java Advanced Imaging API, or the Java Media Framework.

Long before Java was born, Lisp actually led the industry in high-quality 3d graphics long ago. Around the time of the gulf war, CNN and other major TV systems were doing their graphics rendering in Lisp. There was some bad business management that led to the demise of the company with that tool, but the technical tools had nothing wrong with them. (sigh)

Re: I'd like to see, for instance, a word processor written in Lisp.

MIT Lisp Machines were the first to run an Emacs-style editor based on Lisp, I think. Then MIT Multics, where it was conventional to use PL/1, deviated to prefer Lisp as its implementation language. Then Stallman rewrote Teco-based Emacs in Lisp. It's different than MS/Word out of preference and tradition, not becuase something in Lisp keeps it from doing what Word does. But it is a word processor.

Also, Lisps can call out to other programs by native function call, by RPC, by CORBA, by COM, by sockets, and probably (though I haven't recently checked because I don't do Java) by RMI. So we're not lacking for ways to integrate others' tools if we need them.

Re: I'm not insulting Lisp the language, but the fact is that its libraries are woefully inadequate compared to Java's.

The Lisp community was in a boom at the time AI became unpopular. Many siezed upon the opportunity to blame Lisp for AI not meeting everyone's expectations (as if had the work been done in C++, AI would be blossoming today). It's easy for something to become a scapegoat, just as the word "dot com" has become a scapegoat for many companies doing bad financial planning recently. Since that time, Lisp has labored under a bad reputation that I think was unfairly attached as part of a convenient blame game. Yet even though many have tried to kill Lisp, it won't go away mostly because it still has ideas to contribute and commercial problems it can solve that other languages can't. It is gradually building back up to the image it had before, I think, by embracing rather than fighting other technologies. I dare say that if we had as much money to throw around in our community as Sun had to throw around getting Java advertised and populated with libraries, our image would be as good. We're just working on less budget, and so the process of rebuilding trust can't happen overnight by sheer force of dollars.

Re:More Lisp

[jaoswald]

Sure, you can find a Java implementation of a word processor, but will it last as long as Emacs? Is it as flexible? Is it as customizable? Is it as powerful? An Emacs based on Common Lisp (instead of its own crippled Lisp) would be even more of an improvement.

Any Java "word processor" is going to have a hard time beating MS Word at its own game. Emacs, however, thrives by playing another game, the "text editor" game. And it wins.

Lisp has toolkits like Common Lisp Interface Manager (CLIM) which are much more than simple layers to create windows with widgets. I can't even come up with a concise description of how different the Lisp idea is. (Some of this is my lack of practical experience with CLIM. I don't program GUI applications.)

Java is fine for relatively simple, solved problems (like GUI word processors). Lisp is for horrendously complex, hard-to-solve problems like managing logistics for airlines. Or bioinformatics

Or managing information in complex investigations and audits.

You'll notice that all of these are created to solve real-world problems, where it might not be obvious how a computer could help you. Word processing and 3D-shooters are all very securely "inside the box" of what computers are known to do, and have been done many times. Lisp is for taking on the world, forging into new territory, and kicking the world's ass. If you want to stay safe and do "yet another" of the same old thing, maybe Java is all you need.

Re:More Lisp

[psavo]

At least Abuse had LISP scripting abilities. There's also some tools for 3d in scheme, but I can't seem to find it right now. And sawfish has backend of scheme. Emacs is written in emacs lisp. etc etc..

Re:More Lisp

[UberLame]

As far as I know, there aren't any word processors compatible with Word written in Lisp. I think that it has been quite some time since a word processor was written in word, which doesn't help.

As to games, I don't know of any games written front to back in Lisp. I do know that several games have used Lisp for the intelligence. Abuse was one example of this. Crash Bandicoot was another.

Not a game, but the software used for the modelling and animation of games like Mario 64, Zelda 64, FF7 at least (possibly 8 and 9, don't know when the moved to Maya), were done in a program name N-World (now Mirai), which is written in Lisp.

Now, could you write an MPEG decoder or MP3 player in Lisp? Definately. Would they be real time? I don't know. However, if you write something in lisp and it isn't fast enough, if you are sure you are using the most efficient algorithms, then it is quite acceptable to take the piece of code and rewrite it in assembly. This is in effect what happens when MPEG and MP3 decoders are optimized for things like MMX, Altivec, SSE, 3dnow, etc.

Lisp doesn't presume to force everything down your throat. Things like graphics toolkits are meant to be supplied seperately. So, numerous lisp and scheme implementations have bindings for things like X11, GTK, MFC, and probably soon Aqua. There are also bindings to OpenGL, and scene graph tools written in Lisp. And some of the most pioneering imaging software was originally written in Lisp. Just look at the amazing work done on the Symbolics machines (which ran lisp natively).

For commercial uses of Lisp, check out http://www.franz.com/success/index.lhtml. And also try searching google sometime for other places it pops up.

Re:More Lisp

[Anonymous Coward]

Java...fast...Java...fast

Nope, doesn't scan. Whichever meaning your choose for "fast."

Re:More Lisp

[egomaniac]

First, text editors and word processors are hardly the same thing. The two sorts of applications don't have a whole lot in common, any more than a rowboat is a Boeing 747 because they're both vehicles. Word processors are graphical applications which need sophisticated font support, tables, images, pagination, headers, footers, print previews, and a whole bunch of other things Emacs doesn't handle. A text editor is a relative piece o' cake to write, even one as powerful as Emacs.

Second, I am aware that Lisp has some graphical toolkits available. However, nothing that I have seen comes remotely close to Swing's power and expressiveness.

Third, anyone who calls a word processor a "relatively simple, solved problem" has clearly never written one. There's a reason why there are only a few competitive ones, and that's because they're unbelievably nasty programs to write -- far more so than they look on first blush.

Further, you'll have to do better than that to convince me that Lisp is somehow the uberlanguage. The fact that Lisp has been used to, for instance, handle airline logistics does not in any way imply that it was the best choice for that problem. Note that I'm not saying it isn't -- I'm just saying that the fact it was used in, say, a bioinformatics program doesn't say crap about whether e.g. Java couldn't have solved the problem equally easily. Assembly language was used to solve some tough problems which hadn't been solved before, too -- and that doesn't mean a damned thing as to whether or not it was a good choice.

I hardly consider airplane logistics "forging into new territory and kicking the world's ass", by the way. Yes, it's a terribly involved problem, but it's also a boring one, and I seriously doubt that it would be significantly tougher in Java.
"I kicked the world's ass today, Mom!"
"Oh, what did you do?"
"I wrote an *AIRPLANE LOGISTICS PROGRAM*!!! WHOOOOO!! I ROCK!!!"
See? Maybe I'm just getting cynical in my old age, but that just doesn't sound like bragging rights to me.

(Please keep in mind that I'm not insulting Lisp. I haven't used Lisp enough to have a real opinion either way. But the fact does remain that Java's libraries are much more powerful, and it is much more popular. I'm reasonably certain that those two facts are related.)

Re:More Lisp

[Anonymous Coward]

You lucky bastard. Now CMU has bowed down to the industry and teaches Java. Some higher-level courses still use SML, at least. What a downfall, from the school where CMUCL was once developed.

Re:More Lisp

[Anonymous Coward]

• Most word processors suck. This includes MS Word. Just use something decent, like LaTeX, and then try and go back. The output from MS Word hurts my eyes, it's so badly typeset.
• There is more to Lisp than libraries. Common Lisp compilers are heavily dynamic systems which allow interactive, and incremental compilation, and vast introspective capabilities (wow, lots of i's). Being able to examine your system and update it incrementally is an enormous boon when developing.
• If you consider airplane logistics boring perhaps you'd better go back to designing yet another word processor in Java (that can be crappier than StarOffice, yuk)
• Oh, and did I mention how much I hate using interfaces designed with Swing? They never behave quite right; I think the developers of that library still have a little ways to go.
• "I wrote an *AIRPLANE LOGISTICS PROGRAM*!!! WHOOOOO!! I ROCK!!!" Cynical in your old age? Of what? 12?
• The reason why Lisp is a better language for hard problems than Java is that Java forces you to fight against the language to get anything done. I recently came across an amusing example of what someone thought OO programming meant: a.minus(b.plus(c)), and that is quite clearly an example of Java's clumsiness in matters such as that. Instead in Lisp you have (- a (+ b c)) which makes an incredible amount of sense more. (methods that specialize on multiple parameters! genius!)
• If Lisp had as much money thrown at it as Java does by Sun, you would probably see a lot more libraries out there. As it is, there are only so many Lisp programmers and many of them are quite busy doing work as Lisp programmers for their jobs.

Just a few thoughts...

Re:More Lisp

[jaoswald]

Look. Airlines save millions of dollars in real money by using these kinds of programs, and they're not going to quibble if it is implemented in Java. They pay *real* money for these kinds of programs, and getting serious companies to pay large amounts for solving these kinds of real-world problems is enough to say "I rock" even if one isn't living with Mom anymore. Point me to a documented case where Java handles these kinds of intense logistics problems, and I'll begin to give you some credibility.

Right around the time when you show me the Mona Lisa done in fingerpaint.

Considering your preferred example was a 3D-shooter game, I'm relatively skeptical about your opinion on world-class application development.

If you think anything in Java touches what CLIM has achieved, you obviously haven't even followed the link I gave and read what is there. You also ignored all the positive qualities of Emacs (ever try to program Word?) that I cited. I fully conceded at the outset that Emacs and MS Word are competing in different arenas. Lisp has a history of serious publishing tools (also not word processing). These solved, for example, the serious problems involved in generating large sets of documentation using hypertext. in 1985.

Again, I concede that MS probably didn't use Lisp to develop Word. The fact that there isn't a Lisp-based competitor probably is due to the fact that smart people don't try to compete in the same niche as MS, and Lisp is used by smart people.

Re:More Lisp

[Ryan Amos]

I currently attend the University of Texas, and the honors section of the introductory CS course is taught in Scheme. The non-honors sections used to be taught in Haskell and Scheme until last year, when they moved to Java. The upper level classes are now moving to Java as well. This disturbs and upsets me. Not because I hate Java (though I do) but because IMO it's a bad thing to concentrate on learning just one language. It's a good idea to learn one language very well (though I'd prefer C++) and to have a good knowledge of several others. Scheme is a good language to know because it's so radically different from Java/C. If you ever have a chance to take a course in Scheme, I highly reccomend it.

Re:More Lisp

[egomaniac]

The fact that airlines save millions of dollars a year using these programs is certainly important; I'll never say otherwise. I'm just saying that "kick the world's ass" is a bit strong for an application like this.

"Point me to a documented case where Java handles these kinds of intense logistics problems, and I'll begin to give you some credibility."

So a language is only interesting if it's used for "intense logistics problems"? I guess word processing, hospital record keeping, or web page design aren't good enough. Well, I have absolutely no idea about Java logistics programs, because I am not involved in logistics. Doesn't mean it isn't used, doesn't mean it is.

"Considering your preferred example was a 3D-shooter game, I'm relatively skeptical about your opinion on world-class application development."

I listed a 3D shooter as one example out of many, and nowhere did I say it was a "world-class" application. Please stop implying I've said things that I didn't say.

"Ever try to program Word?"

Yes, actually. Not the most fun I've ever had, but Visual Basic for Applications isn't all that bad for a macro language.

"smart people don't try to compete in the same niche as MS, and Lisp is used by smart people"

So Linux, which is a direct competitor to Windows NT, is written by a bunch of idiots?

One's choice of language has nothing to do with one's intelligence. Lisp does indeed seem to have more than its fair share of elitists, however.

Re:More Lisp

[Lord Ender]

Of course you are overlooking something.

It's pretty hard to get a job that requires you know C++ when all you know is 'theory' and not any actual C++.

There should be a happy medium in CS ciriculum. Many schools, I think, do this (such as Ohio State).

Re:More Lisp

[NetSettler]

Re: One's choice of language has nothing to do with one's intelligence.

Neither does one programmers's choice of application area have anything to do with a language's suitability for other things. Go to Franz's success stories page for a list of Lisp success stories. But please don't assume this is an exhaustive list, and please don't assume Lisp is only useful for Animation and Graphics, AI, Bioinformatics, B2B and Ecommerce, Data Mining, EDA/Semiconductor applications, Expert Systems, Finance, Intelligent Agents, Knowledge Management, Mechanical CAD, Modeling and Simulation, Natural Language, Optimization, Research, Risk Analysis, Scheduling, Telecom, and Web Authoring just because these are the only things they happened to list. Common Lisp really is a general language capable of a lot more than these few incidental application areas, even if this web page doesn't totally bring that out.

Re: Lisp does indeed seem to have more than its fair share of elitists, however.

Your use of the word "seem" of course makes this a statement about you and your ability to perceive, not a factual statement about the world. If you had made this a factual statement about the world, I'd ask to know your source of statistics and the nature of your accounting techniques to make sure you were not applying any kind fo selective bias or personal opinion. But fortunately, that won't be necessary.

I'm also not really sure why elitism of individual users is an issue. Languages are not elitist, people are. And I think that's just a sometimes side-effect of passion (unless you're making a claim that something in the language semantics forces this, a claim that would require more documentation than you've given). Are there languages that don't attract passionate people? I'd be more afraid of a language that didn't inspire passion than one that did.

Re:More Lisp

[NeonSquare]

Second, I am aware that Lisp has some graphical toolkits available. However, nothing that I have seen comes remotely close to Swing's power and expressiveness.

You then should definitely have a look at CLIM - it is _very_ different to more conservative toolkits like Swing, but it is a very powerful tool. (I would always take a complete CLIM over Swing+Java2d)

I hardly consider airplane logistics "forging into new territory and kicking the world's ass", by the way. Yes, it's a terribly involved problem, but it's also a boring one, and I seriously doubt that it would be significantly tougher in Java. "I kicked the world's ass today, Mom!" "Oh, what did you do?" "I wrote an *AIRPLANE LOGISTICS PROGRAM*!!! WHOOOOO!! I ROCK!!!" See? Maybe I'm just getting cynical in my old age, but that just doesn't sound like bragging rights to me.

I worked a while for a vendor of airplane logistics software. I can ensure you that this topis is so complicated that there are not many vendors for that tools. Fact is that only a few vendors was able to develop good enough algorithms to scale up to big airports. One of the newer vendors explicitely used Common Lisp even if it would have been easier to find Java Programmers than Common Lisp programmers.

Re:More Lisp

[egomaniac]

Neither does one programmers's choice of application area have anything to do with a language's suitability for other things.

Of course not. I've been saying that all along. Not once have I said that Lisp is a lousy language, or even a subpar one, nor have I said one single thing regarding Lisp's suitability or unsuitability towards any particular application.

All I have been saying is that Java's libraries are much more powerful, and that quite likely has a lot to do with the fact that Java is in much broader use. Let's face it, we're discussing a language in which simple things like sockets and multithreading aren't "core" behaviors. Yes, they exist, but in the form of third-party addons which (please correct me if I'm wrong) differ significantly from vendor to vendor, and are still in such limited use that lots of people will tell you they don't exist.

Your use of the word "seem" of course makes this a statement about you and your ability to perceive, not a factual statement about the world.

The word "seem" was chosen intentionally to indicate that that was nothing more than my opinion. I don't see how this is an interesting issue.

I'm also not really sure why elitism of individual users is an issue.

Quite simply because the person I was talking to was being an elitist, and it irritated me. I've heard the "only idiots don't program Lisp" bit a number of times, and it's wearing a bit thin.

I program Java for one and only one reason -- the class library. Nothing, in any other language I have ever heard of, approaches the breadth and power of Java's core APIs. Lisp doesn't even rate on the radar, as you would have to download hundreds of third-party modules to even come close. Therefore, I program Java. It's not because I don't like Lisp, or because I do like Java -- it's because Java meshes more closely with what I'm trying to accomplish. That doesn't make Lisp users smarter than me, despite how many of them snicker at all the idiots who don't seem to "get it".

Re:More Lisp

[NetSettler]

Re: I program Java for one and only one reason -- the class library.

I absolutely agree this is a strong concern and can't blame you. I regard Java as more of an assembly language establishing a virtual machine. I wish they'd come out with hardware Java so it would be fast enough that people could seriously embed languages atop it without losing still even more speed than Java already loses.

I like Java's wealth of libraries (even if I quibble with this or that particular one) but I hate the Java surface language. I'm not a static typing person, and I need macros. Java makes me feel unproductive, even after taking time off to do about a year of intensive programming in it. If you can cope with it, more power to you. :-)

Re:More Lisp

[Bobo the Space Chimp]

> Learning Common Lisp as an undergraduate at CMU in
> the late 1980s changed my life for the better. I
> guess to each his own.

I agree. It's like taking courses in the development of Western thought, or living in Europe (or the USA) for awhile. You get exposure you otherwise wouldn't, and can subsequently grasp a lot more.

I have programmed professionally in Lisp for about 4 years (actual AI work out in the real world, no U attachment.) I have also programmed C, and now C++ for about 8 years.

I can't count the number of months worth of debugging I've done in C and C++ doing things that would not have been any problem whatsoever in Lisp.

The ungodly ease of development when you can effortlessly encode processing a list of objects and single objects is worth it just for that alone. Pass in the arg, test if it's a list or not, recurse or run thru the list.

How much time does C++ programming require to change parameters, values, etc.? A ton. In Lisp, just pass in extra quoted values as additional parameters, with associated quoted symbol identifier (don't even hafta bother with :) and you're done. It's (for those who know) the blackboard system applied to functions. Gather up a bunch of data you do know, even if some is extra or irrelevant, and pass it in and let the function pull out what it needs. If it doesn't find what it needs, it can return without doing anything.

Quick, fast, don't worry about crashing, rapid development, far more robust. I was rather sad that Lisp didn't take off as the language of the web -- it's been 10 years since a desktop PC had to worry about speed in executed script code for anything other than a number crunching program.

Yes, you can suffer from the same logic bugs as any other language, but everything else is a ton easier.

Re:More Lisp

[theNeophile]

Sure, you can find a Java implementation of a word processor, but will it last as long as Emacs? Is it as flexible? Is it as customizable? Is it as powerful? An Emacs based on Common Lisp (instead of its own crippled Lisp) would be even more of an improvement.

I think he means a text editor written is lisp. Emacs is written in C.

You'll notice that all of these are created to solve real-world problems, where it might not be obvious how a computer could help you. Word processing and 3D-shooters are all very securely "inside the box" of what computers are known to do, and have been done many times. Lisp is for taking on the world, forging into new territory, and kicking the world's ass. If you want to stay safe and do "yet another" of the same old thing, maybe Java is all you need.

So... lisp can't do it, but thats ok because... it's easy to do.

Re:More Lisp

[yugami]

I think he means a text editor written is lisp. Emacs is written in C.

uhm, emacs is a lisp parser written in C, everything emacs does in terms of editing text is done through lisp

Re:More Lisp

[Anonymous Coward]

Rice University's Intro to CS is also taught in Scheme

kilohyperlinks

[wiredog]

Whoa. I don't think I've ever seen that before. Or a document where the number of links could be described in that fashion. "Megahyperlinks" sounds cool, though. I wonder if there are any of those around.

Re:kilohyperlinks

[sv0f]

Whoa. I don't think I've ever seen that before. Or a document where the number of links could be described in that fashion.

You should check out Kent's HyperSpec. It's an amazing (and amazingly useful) document. Just project the obvious thoughtfulness of his replies over a huge document and imagine the result.

My god....

[Cesaro]

I think I may have just found most verbose man ever. I'm awed by the miniscule size of my scrollbar, and there are hardly any comments! This is ridiculously incredible.

Re:My god....

[sv0f]

I think I may have just found most verbose man ever. I'm awed by the miniscule size of my scrollbar, and there are hardly any comments!

You prefer the sarcastic barbs of linguist/banana republic dictator Lary Wall?!? (Incidentally, Kent's undergraduate degree is in linguistics.)

Or the detached arrogance of Bjarne Stoustroup (sp)?

Assume the position and be Wayne and Garth to Kent's Steven Tyler.

Re:My god....

[Tiny Elvis]

I'm awed by the miniscule size of my scrollbar

I must admit I've never heard 'it' referred to as a scrollbar before..

Re:My god....

[Anonymous Coward]

I'm awed by the miniscule size of my scrollbar,

Yeah, that's what your girlfriend implied, but with a slightly more accurate variation on the meaning of 'awe'.

Re:My god....

[Anonymous Coward]

MTV got your brain?

Ah, LISP fanaticism

[Animats]

It's been a long time since I've encountered a LISP fanatic. I thought they were extinct.

I've written about 10,000 lines of LISP myself, know John McCarthy (who finally retired last week) and even used a Symbolics refrigerator at one point, but realistically, LISP is an idea whose time has passed.

Representing programs as S-expressions, incidentally, has one terrible cost - it's hostile to comments. Because there's no place to hang the comments, LISP code tends to be uncommented within the text of the code.

He has a good point, though, that while LISP used to be considered a big language, the other languages have bloated so much in the last decade that LISP now looks small.

Re:Ah, LISP fanaticism

[Brian Kendig]

I used to be a Lisp fanatic, and I still have a soft spot in my heart for the language. :-)

To me, Lisp is wonderful for three reasons:

(1) It's highly abstract. It makes working with fuzzy concepts (such as natural language) so much easier; you very rarely (if ever) have to get into the nitty-gritty of worrying about how your code actually interfaces with the hardware it's running on. Lisp is one of the highest-level languages I've ever used. Compared to Lisp, C++ is just horribly ugly.

(2) Lisp code can be self-modifying -- it's easy to write a program which puts together a new function and adds it to itself. This makes it great for artificial intelligence, in which self-modifying programs are good things. Compared with this, Perl's 'eval' function is woefully inadequate.

(3) One of the most important things to learn about Lisp is that good code flows from the fingertips, while bad code snarls up and is hard to write. If you're having a hard time getting a piece of Lisp code to work, then you're probably going about solving a problem the wrong way. When thoughts and code are in harmony, it's a very Zen form of beauty.

Lisp code is just *fun* to write. :-) Even more so than Perl code!

Re:Ah, LISP fanaticism

[Anonymous Coward]

Representing programs as S-expressions, incidentally, has one terrible cost - it's hostile to comments. Because there's no place to hang the comments, LISP code tends to be uncommented within the text of the code.

Really? It's not the S-expressions fault, for example, in Common Lisp you have ; for comments that reach to the end of the line, #| and |# for block comments (and they nest too) and (this is a bit of a hack) #+ignored for commenting one sexp. Doesn't look like hostile to comments to me ;)

The chief reason the code is often uncommented is the fact that Lisp names tend to be more descriptive and the functions shorter, so you see what's happening without any comments.

Re:Ah, LISP fanaticism

[andrew cooke]

That's it? Lisp is no good because you can't fit comments into S-expressions?

A Lisp comment comes after a semi-colon and it's trivial to put one at the end of a line. Also, it's traditonal to write programs as collections of fairly short functions (if you're used to Java or C, for example, the OO part of Lisp breaks the code up into the equivalent of methods rather than classes), so comments above code are also usually visible.

But more than that, why on earth is this rated as 4? Sure, Lisp's time may have passed - but if so, there must be a better argument than that!

Re:Ah, LISP fanaticism

[yellowstone]

Representing programs as S-expressions, incidentally, has one terrible cost - it's hostile to comments. Because there's no place to hang the comments, LISP code tends to be uncommented within the text of the code.

I don't mean this as flamebait or a troll, but what are you talking about? All my LISP code is in text files. It's just as easy (or hard, depending on your habits) to comment LISP as it is to comment Java, C/C++, or any other language with text-based source code.

Re:Ah, LISP fanaticism

[Anonymous Coward]

Representing programs as S-expressions, incidentally, has one terrible cost - it's hostile to comments. Because there's no place to hang the comments, LISP code tends to be uncommented within the text of the code.

Actually, I believe that LISP provides greater commentability than other languages, since LISP encourages code reuse through small, atomic procedures that can be passed as variables. Need to sort a list based on a metric? Create a generic sort procedure and have it take the metric as an argument. This way, each metric can be documented on its own and the sort routine can be documented separately. At the topmost level, good LISP code becomes very compact and readable as a result of the modularity inherent in the language.

(at lael (dot mit edu))

Re:Ah, LISP fanaticism

[sv0f]

Representing programs as S-expressions, incidentally, has one terrible cost - it's hostile to comments. Because there's no place to hang the comments, LISP code tends to be uncommented within the text of the code.

Actually, quite the opposite. Because Lisp programs have a nested tree structure and there are universal indentation conventions, any single expression in a Lisp program can be isolated on its own line in a way that's natural to the reader, and then commented. Plus, Common Lisp (like all decent languages) permits inline comments: #| comment |#.

Poorly written code in ANY language displays the qualities you attribute uniquely to Lisp.

Re:Ah, LISP fanaticism

[Anonymous Coward]

hahahaha!

very nice troll, i'm sure it'll go far

Re:Ah, LISP fanaticism

[Anonymous Coward]

And by the way, inline (or block) #| comments |# can be nested (unlike /* C comments */), so that you can comment out a large portion of a file without having to worry about already-present comments.

Just think...

[PW2]

He's answered your questions below, at length

I'm imagining Katz hard at work trying to top this one...

C takes too long to write?

[windex]

I don't know what planet he's from but, in general, C does not take long to write. C has this wonderful capibility called functions, and if you do a lot of repetitive work, you can write a function to do that repetitive work. Or, for example, in C++ you can pass a class of C++ functions and data as an argument, making it so that modular applications can pass the same code and data to all available functions for immediate use..

IMHO, he's just biased to Lisp, and I'm just biased to C. But, outright saying that C programmers are a bunch of speed-freak-holier-than-thou losers, was going a little far..

Re:C takes too long to write?

[mikeee]

Obviously, "C" is quicker than "Lisp" to write, especially if you already have capslock on. It's shorter.

I predict the new language I am designing, ^H, will be very sucessful.

Re:C takes too long to write?

[kill -9 $$]

In reading his answers, I have to agree that he is extremely biased towards LISP. I personally was not that impressed with the language at all. However, for writing some AI projects it made for much easier work handling dynamic lists of items which was the only benefit I saw of it.

As I mention in another post in this discussion, I've often wondered if Perl could be used just as easily gaining the benefit and familiarity of writing in a C-like language along with using things like splice/push/pop and other array based notation to handle the lists aspect that LISP does so well.

Re:C takes too long to write?

[mdalgarno]

> IMHO, he's just biased to Lisp, and I'm just biased to C.

The difference is that he backs up such 'bias' with an argument - you don't.

Re:C takes too long to write?

[Frizzle Fry]

C takes far longer to write in for large applications than Lisp due to the debugging time. Tracking down memory leaks, pointer bugs, etc. is a pretty tedious process that lisp programmers don't worry about.

Re:C takes too long to write?

[ingvar]

One thing I do often when writing C is to have
something *very* similar to this:
[line broken for slightly more readability]
#define EXTEND(BUF, LEN, BUFLEN, TEMP, END) do { while (((LEN)+1)>(BUFLEN)) {
TEMP=realloc(BUF, 2*(BUFLEN));
if (TEMP) {
END=TEMP+(END-BUF);
BUF=TEMP;BUFLEN=2*(BUFLEN);
} else {
write_error(this,
"Malloc fail in support function");
return;}}}
while (0)

I guess I *could* have written a function doing
similar stuff, but I guess it is similar things
that KMP refers to.

Now, I would really like a switch that does
case-sensitive string comparisons, but I don't
fancy writing a CPP macro that can do it for
me. :/

Re:C takes too long to write?

[mparker762]

But writing such switch statement (that handles strings) is trivial in lisp. It would be useless, since lisp already does this, but it would still be trivial.

I recently wrote a macro for use in a VM I was playing with, that is used for defining opcodes,
and is used something like this:

(definstruction 32 addi ((n1 integer) (n2 integer) -- (result integer))
(setq result (+ n1 n2)))

(definstruction 10 swap (a b -- b a)
)

The definstruction macro takes the opcode number, opcode name, a stack picture, and the body of the function. It then expands into code for a function that implements the opcode. In the case of addi, this function verifies that there are at least two items on the stack, and that they are both integers, throwing appropriate exceptions for each error case. It then generates code to pop these items off the stack into local variables and also declares the output variable, making sure not to double-declare if some of the same variables are used on both the input and output. It then generates the body of the function wrapped up in an exception handler that restores the stack to its initial state before calling the exception hook if it's a restartable exception, or just calls the exception hook directly if it's a resumable exception (yes, Lisp has resumable exceptions so you can clean up and keep going). The macro then generates code to push the result back on the stack, checking for overflow if needed, and (optionally, for debugging purposes) verifying that the result was indeed of the correct type.

Finally, it generates code to add the opcode to the jump-table that the vm interpreter uses, and also to the tables that the disassembler uses.

For something like addi maybe 30 lines of code are generated. For something like swap, it only generates about 4, because the macro is intelligent enough to realize that with no body and no typechecking it doesn't need the exception handlers etc.
This one macro is under 100 lines of lisp code, and will save 5000 to 10000 lines boring, repetitious, bug-prone code!

Re:C takes too long to write?

[Kaz Kylheku]

Firstly, I'm a much more experienced C programmer than a Lisp programmer. Yet, the limitations of C compared to Lisp are painfully obvious to me.

Yes, C supports the fundamental unit of program abstraction known as the function. But that does not make up for the various other drawbacks.

Why C takes longer to write is because the programmer must deal with every detail of the computation---other than some machine-specific details such as allocating values to machine registers, explicitly managing the passing of parameters, or manually scaling pointer displacements based on types.

Firstly, there is the memory management. Every significantly large C program which uses dynamic memory, unless it is correctly written by a miraculous fluke, will suffer from failures due to premature deallocation of memory and memory leaks. It's not possible to create a significant data abstraction of C without encumbering it with memory management burden. A typical abstract datatype (ADT) module will have create and destroy functions which call malloc and free. The user of these functions inherits all of the responsibility that comes with malloc and free: the avoidance of premature deallocations and concerns about leaks. There are many things you can't do effectively without a garbage collector: the entire technique of functional programming is made impractically difficult. When you don't have to worry about memory allocation, you gain productivity.

Secondly, there is the strict, static type system. Static type systems get in the way of certain types of programming. Here is an example. It's not unusual for parsers written in C to use a union type to represent the items stored in a parse tree, and to use integer tags to identify what is present. What is that, if not an emulation of dynamic typing?

This brings us to my last point. Compiler writing is incorporated into the Lisp programming style, and the dynamic typing supports it directly. In Lisp, in addition to the use of functions as an abstraction mechanism, you have macros. These are not like C macros which work with tokens of the program text; they are operators that work on data structures; data structures which typically represent some programming construct and are translated into some other data structure, which represents Lisp code that will be substituted for the macro and evaluated in its place.

The techniques for abstraction provided by Lisp macros are squarely out of reach of the programmer working in C, who is stuck with a fixed set of langauge features, and a lame preprocessor that can perform some very simplistic emulations of new language features.

What if you want to embed a whole new language in C? You have to write an external processor that works with the raw text of your source code. This is exemplified by ``embedded SQL''.

Re:C takes too long to write?

[jaoswald]

C'mon. Every C function needs you to declare the type of every argument to the function (except in varargs, which are done infinitely better in Common Lisp) in machine-level detail before it will even compile, much less work.

Have you spent any time at all thinking whether a numeric argument should be "int" or "long" or "float" or "double"??? You're falling behind Lisp. Did you remember to worry about integer overflow? (Lisp integers only overflow when you run out of memory. C programmers think that wrap-around is a problem that won't happen soon enough to care (2038 A.D.?)) Yet more time wasted, or bugs introduced.

Did you need to define a data structure? In Lisp, you can just use lists for quick-and-dirty. If you want to be cleaner, use structures. You don't have to define the type of every slot, unless you want to.

Did you need serious, robust string handling? Watch out for buffer overflow exploits, extraneous NULL characters, and so on. Did you do any memory allocation? Be sure to think very carefully about "who owns what" or you've introduced memory leaks. Well, even very careful probably wasn't enough, so you still have memory leaks, but you can just restart every so often, right?

You did remember to check the return values of all your system calls to make sure they worked, right? Lisp file I/O throws exceptions, so you can handle errors in structured ways.

Lisp has arrays that can automatically expand as you add data to them (retrieval is fast, storage is fast until the size needs to bump up, when it is still very fast, no arbitrary array bounds to cause buffer overflows later).

Sure, you can write C programs fast. If you have time to put in extraneous detail. And can ignore all the pitfalls in the resulting code. Something like doing surgery fast with a chainsaw. Sure, it might be fast, but do you really like the results?

Re:C takes too long to write?

[Anonymous Coward]

Now, I would really like a switch that does
case-sensitive string comparisons, but I don't
fancy writing a CPP macro that can do it for me.


Standard Common Lisp doesn't have a CASE statement
that does string comparisons, but it would be rather simple to write a Lisp macro to do that.

This is because of three features of Lisp:

1) the uniform, parentheses-delimited syntax -- which means that you don't need to do any hairy parsing of the input syntax of the macro

2) the use of lists to represent program structure -- so that first of all everyone who programs in lisp is already intimately familiar with the form of the "parse-tree" for the macro, and can furthermore manipulate the parse tree using familiar functions

3) macros can execute code -- this allows more powerful transformations than simple text substitution macros. For something like a switch statement, being able to loop over all of the clauses is a real advantage in such a macro. It also allows one to factor out functionality into functions.

Example:

(defun expand-custom-case (comparison-function test-variable clauses)
(loop for clause in clauses
when (member (first clause) '(T OTHERWISE))
collect `(T ,@(rest clause))
else collect `((,comparison-function ,test-variable ,(first clause)) ,@(rest clause))))

(defmacro case-sensitive-case (test-form &body clauses)
`(cond ,@(expand-custom-case 'string= test-form clauses)))

(defmacro case-insensitive-case (test-form &body clauses)
`(cond ,@(expand-custom-case 'string-equal test-form clauses)))

(defmacro sounds-like-case (test-form &body clauses)
`(cond ,@(expand-custom-case 'soundex-compare test-form clauses)))


In this example, I was able to define three new, related case macros for string comparison using built-in functionality (except for soundex-compare, which is a name I invented). This is close to what production code would look like.

Disclosure: Real production code would take care to make sure the test-form was only evaluated once, and the expansion function would need to be expanded to allow for lists of matching strings instead of just single elements. Those would be rather easy extensions, so I omitted them from this example.

This would then allow one to write code using the macros like the following:


(case-insensitive-case last-name
("Smith" (print "common"))
("Einstein" (print "famous"))
(otherwise (print "beat's me")))

Re:C takes too long to write?

[jacobm]

C's ability to declare functions is a good tool for abstraction, but doesn't come close to the power of abstraction you can get in Scheme/Lisp.

For example, there is a standard library function in Scheme (and every other halfway-functional language in existence) called map. map takes a function and any number of lists, and returns a new list such that element X of the returned list is the result of applying the given function to element X of each of the input lists. So, for instance,

(map + (list 1 2 3) (list 4 5 6))
is
(list 5 7 9)

In Scheme, the function map is extremely easy to write -- it's certainly appropriate for a student in a beginning programming course taught in Scheme after about five or so weeks. In C, even if you substitute arrays for lists, map as described would be a real pain to implement -- I challenge you, in fact, to write a version that's as general as the Scheme version. And, if you're really up for a challenge, find someone who's had as much experience in Scheme as you have in C, and race. :)

Of course, nobody misses map in C (well, nobody who isn't indoctrinated in functional programming, anyway). C programmers just idiomatically write for or while loops instead. And, surprise surprise, C programmers are always making silly little mistakes that cost time -- "Oops! I got that termination condition wrong!" "Oops! I incremented the wrong counter!" "Oops! I forgot to initialize that variable to zero!" "Oops! I forgot to allocate memory for the return array!" Sure, they're mistakes that C programmers learn to catch quickly because they happen so frequently. But my 5-week-educated Scheme programmer will never have any of those bugs, and won't ever have to spend any time finding or fixing them.

Re:C takes too long to write?

[Anonymous Coward]

I don't agree. I find static typing very helpful. There are lot of runtime errors that can be triggered in dynamic typing languages, like "object foo does not have a bar member".

I found this slashdot interview interesting because i am myself interested in functional programming. I would have loved a comparison of lisp with ocaml or haskell. lisp and scheme are great for teaching tools because of their simple syntax.

I usually use haskell for academic purposes, no real life application done yet. It has a very cool type system that can infer the type of your functions without declarations. Polymorphism is supported as well as parametric types. You can code incrementally using a shell (hugs, ghci) and when you are done you can use an optimizing compiler (ghc).

It's infix syntax is very powerful because you can change the precedence rules as you wish and define operators from new characters. For example:
infixl <**> 5
a <**> b = some_function a b
This way you can define a kind of embedded language inside haskell, look for example HaXML, a library to manipulate XML and Utrecht Parser combinators..

I would be very pleased if Ken could make some comparisons of lisp with modern functional programming languages.

Re:C takes too long to write?

[Cartan]

I don't think Common Lisp's type system is less expressive than Haskell's. Can you define a Haskell type ``integer between 5 and 217''? In Lisp you can. The main difference is between static vs dynamic typing. To avoid runtime type errors and/or gain efficiency, you _can_ declare types, and smart compilers as CMUCL will do as much type inference as they can based on the information you give them. In my experience, when you get used to Common Lisp and it's type system, you don't get many runtime type errors anymore, or maybe none at all. Just as a Haskell newbie doesn't get any programs to compile at first because of all those type errors, but an experienced Haskell or ML programmer knows how to avoid those errors in the first place (just as in Lisp).

And no: Infix syntax is NOT ``very powerful''. Fine, you can change the precedence of infix operators in some languages, but you don't have to in Common Lisp because there is no precedence problem in the first place! If you want embedded languages, Common Lisp's macros are a very strong and unique tool. Why do you think OCaml has such a complicated and VERY hard to use tool as Camlp4? Only to emulate a small subset of what you can do with Common Lisp macros much easier. Common Lisp books sometimes warn about macros being ``complicated'', but they are laughably trivial to use and yet more powerful when compared to a monster like Camlp4.

When programming in ML or Haskell, I find myself most of the time thinking about how to outsmart the type checker again by defining more and more complicated union types; this is fun, actually, but only as long as you are playing around with it. When you want to get something done, the static type checker quickly becomes your main enemy, who keeps you from getting work done. Just look at the discussions about ``phantom types'' on the OCaml mailing list, or just try to define an Y-combinator in an ML like language. This is so hard (because of the type checker), that many ML programmers even think it can't be done! Writing the damn thing down in Common Lisp is trivial.

Just my 0.02$.

Re:C takes too long to write?

[NetSettler]

Actually, back in the 70's sometime, Vaughan Pratt (then at MIT, I think since moved on to Stanford or some such) invented this thing called CGOL, which was an infix syntax for Lisp. (It didn't require special magic to do; Lisp's syntax is redefinable, to it just takes a normal user program and a little imagination to do this.) He also wrote some much-ignored but very interesting papers on how its parser worked that I don't have pointers to but that I remember learning a lot from.

The Pratt parser used a modified parse precedence thing where any operator could take back control of parsing if wanted to. It was very flexible and reprogrammable and I swear by that model of parsing even today, much preferring it to simple bnfs and that kind of thing. But as to reprogrammability, I pointed out to him once, decades back now, that I thought the ability to dynamically rearrange parse precedences wasn't the win it seemed like it should be, because it made people uncertain as to what would associativities would occur. He seemed to sadly agree with me and said, at least then (he may have changed his mind since), that he thought it was probably better for defining a language than for offering a redefined language--that probably a language should just have a fixed set of such operators and then be done because indeed it turned quickly to a tower of babel if you rearranged parse precedences programmatically like the language technically allowed.

The traditional Lisp notation avoids this tower of babel by just making every expression syntax-neutral. No system-defined function or macro gets special "operator" parsing status, so no user-defined function or macro complains "hey, how do I do that?". The result, as most Lisp users remark at one point or another in their life, is a much more egalitarian environment, where system macros and user macros blend naturally without one having more apparent status than the other.

Re:C takes too long to write?

[jejones]

I wouldn't call C typing strict. While C does require declarations for variables, there are sufficiently common tricks for subverting the type system that I would say that C is "sleazily typed."

Learning Lisp/Scheme?

[FortKnox]

Anyone have any good docs/books they used to learn lisp/scheme quickly and easily (more than just an amazon/google search)?

Doesn't Lisp have a foundation in AI? Or is that Prolog? Doesn't Lisp somehow have a relationship to prolog?

Re:Learning Lisp/Scheme?

[Pretender]

The Little Schemer is very good, and somebody can start with that without even having a background in programming.

Re:Learning Lisp/Scheme?

[Pretender]

Sorry to reply to my own post, but I forgot one of the best ways to be introduced to Lisp: Emacs. It probably came with your OS or has been ported to your OS at some point, it is based on Lisp (albeit one not as powerful as Common Lisp), and you can get both an introduction to Emacs Lisp and a reference manual direct from GNU's web site.

Re:Learning Lisp/Scheme?

[big.ears]

Lisp is commonly used by AI researchers, more in the 80s than it is today. Prolog is as well, and was the basis for 'Expert' systems that were in vogue a dozen years ago. Aside from the facts that it is fairly easy to implement prolog in lisp, and they are both used by people who are consider AI researchers, they are very different.

From a naive perspective, lisp is just a programming language that you can tell what to do and it does it. Prolog doesn't seem to actually do anything--You just tell it information and it somehow knows the answer.

Re:Learning Lisp/Scheme?

[Anonymous Coward]

There is only one book you need to get:

Structure and Interpretation of Computer Programs - also known as "SICP".

Have fun. It is very cool stuff.

Re:Learning Lisp/Scheme?

[Anonymous Coward]

The Little Schemer is a good introduction to Scheme. There is even a sequel: The Seasoned Schemer.

I'd also recommend Structure and Interpretation of Computer Programs. It's an excellent book and will teach you more than you ever wanted to know.

Re:Learning Lisp/Scheme?

[kill -9 $$]

Books, I can't really help you. I learned Lisp out of some book that I'm sure is now out of print , but was titled something like Common Lisp: Programmers Guide or something. It was good, but ancient in computer book years now. (then again I don't think LISP has changed all that much). As for your other questions...

Lisp is used for AI because it makes easy work of slashing through lists of items, etc. (I can't go further since its been a while since I've done AI and LISP) It can also be used for all sorts of other programming tasks, etc. I've often wondered after learning Perl soon after, if Perl could actually accomplish all the great stuff LISP is used for just as easily. Anybody know the answer?

As for Prolog its also used for AI, but I'm pretty sure its a AI specific language (I'm sure it can be twisted to do other things though).

One of the main differences between the two, if memory serves correct, is that LISP is ones a forward chaining language whereas the other is backward chaining (or vice-versa). Again if memory serves me correctly these have to do with deduction and learning. So as far as I know, no they aren't that related.

Re:Learning Lisp/Scheme?

[brsett]

I've got one just called Common Lisp, 3rd Ed. Not great, but not bad. The Paul Graham one is really, really good. Maybe one of the best books on a programming language I've seen. I think the name is simply ANSI Common Lisp. Highly recommended (check the reviews at Amazon I guess to make sure I'm not off my rocker).

Re:Learning Lisp/Scheme?

[FortKnox]

Not to start a flame war (this is just my opinion), but in the war of vi vs. emacs, I'm all for emacs. I used emacs while learning C++, and have a great respect for it (although I'm more of an xemacs user).

I remember toying with the idea of learning lisp just to edit emacs to make just a "code editor" and kill all the calender/email/other stuff it has in it (I'm still waiting for the "emacs linux distro", where you login, and are brought to an emacs window that has its own os running. After all it is the only way to increase emacs' bloat ;-) )

Now the next question is, which to learn: Scheme or Lisp? Isn't scheme a newer language? Is it better?

Re:Learning Lisp/Scheme?

[lars_stefan_axelsson]

Well I don't know about "quickly and easily", but the book for Scheme (or rather for programming, but based on Scheme) is: The Structure and interpretation of computer languages", by Abelson and Sussman, MIT Press. It's even online.

While I would certainly recommend some programming background, and perhaps The little Schemer. (Many more tips on www.schemers.org even a few worthwhile tutorials online such as "Teach yourself Scheme in fixnum days"). SICP as it's affectionately known is one of the best books on programming, period. It may not be in the "teach yourself xx in n days" category, and rather heavy going at times, but the rewards are worth it.

This is IMHO the book that makes Scheme worthwhile.

Re:Learning Lisp/Scheme?

[sv0f]

Anyone have any good docs/books they used to learn lisp/scheme quickly and easily (more than just an amazon/google search)?
Check out the Association of Lisp Users web site for references. I believe Dave Touretzky has made his very good introductory book available online and Dave Lamkins has also written a long web-based tutorial.

Also, the introductory course at MIT uses the fabled 'Structure and Interpretation of Computer Programs' which I believe is also available online. It covers Scheme, not Common Lisp, though.

Re:Learning Lisp/Scheme?

[sv0f]

one of the best ways to be introduced to Lisp: Emacs.

Emacs lisp is an old dialect. It differs fundamentally from Common Lisp and Scheme in lacking lexical variable bindings. Avoid it in favor of free versions of the newer dialects if your purpose is to understand Lisp as it has been for the past twenty years. Especially explore Common Lisp, which includes so much cool functionality as part of the standard. For example: I believe that Common Lisp was the first object-oriented programming language to become an ANSI standard.

Re:Learning Lisp/Scheme?

[sv0f]

Also:

(1) Peter Norvig's "Artificial Intelligence Programming: Case Studies in Common Lisp"

(2) Sonya Keene's "Object-Oriented Programming in Common Losp: A Programmer's Guide to CLOS"

(3) Paul Graham's "ANSI Common Lisp"

(4) Paul Graham's "On Lisp: Advanced Techniques for Common Lisp"

(5) Friedman, Wand, and Haynes's "Essentials of Programming Languages"

Re:Learning Lisp/Scheme?

[RhymeAndReason]

I believe Dave Touretzky has made his very good introductory book available online
Here, have a link:

Touretzky, D.S. Common Lisp: A Gentle Introduction to Symbolic Computation, Benjamin/Cummins, 1990. ISBN 0-8053-0492-4. (For Lisp novices.)

Re:Learning Lisp/Scheme?

[connorbd]

My call: split the difference. For your own work go with Scheme. Tutorials are easy to find, and LispMe (the GPLed Lisp Machine on a PalmPilot) is actually a Scheme interpreter, so you've got portable prototyping capability; it's also the scripting language for the GIMP. However, if you're going to do Lisp at all it probably pays to know both dialects, since Common Lisp seems to be the Lisp that gets used in the Real World.

/Brian

Re:Learning Lisp/Scheme?

[Anonymous Coward]

Actually your knowledge of Lisp seems to be dated back to the 1960's. It has changed quite a bit, as a quick peruse through the Hyperspec will show.

But it's quite easy to answer whether Perl can do what Lisp does. The answer is no; and anyone who has written a macro in Lisp will tell you the same.

Re:Learning Lisp/Scheme?

[Anonymous Coward]

Scheme is more beautiful, but Lisp is probably more useful in the real world. Poke around at schemers.org for a tutorial or something. If you find that you like Scheme, you'll be able to transfer a lot of your understanding to Lisp.

developers need to see the light, not suits

[Frothy Walrus]

As long as these languages are kept alive by their dedicated users, there is always the chance that the suits will see the light, and go for the productivity gains offered by high level languages.

currently high-level languages like Lisp are good for early prototyping and development stages, but lack the library hooks and other trappings needed for real, industrial strength application development. what i'd like to see Lisp and Smalltalk and Eiffel develop is a good compiler and a good interface to the system and GUI code.
(no, Java does not cut it.)

when i can write an app in Lisp and still use GTK, Athena widgets, etc, then we might see corps moving from C/C++ to languages where memory allocation, etc become fond memories and real high-level thinking may take place.

Re:developers need to see the light, not suits

[Anonymous Coward]

what the hell is industrial strength?
Software that is strong like bull and smart like street car?
I've yet to see well written business from a software shop.
Home grown programs are even worse.
The world is awash with terrible software written in every language.

Re:developers need to see the light, not suits

[the_2nd_coming]

lack the library hooks and other trappings needed for real, industrial strength application development

have you looked at python?

Re:developers need to see the light, not suits

[rmstar]

currently high-level languages like Lisp are good for early prototyping and development stages, but lack the library hooks and other trappings needed for real, industrial strength application development. what i'd like to see Lisp and Smalltalk and Eiffel develop is a good compiler and a good interface to the system and GUI code.

Too damn right. And try parallel programing with lisp. There simply isn't such a thing. Sad, sad.

No, hey: I mean it, ok? It is really sad. Tell you more another day.

rmstar.

Re:developers need to see the light, not suits

[sv0f]

currently high-level languages like Lisp are good for early prototyping and development stages, but lack the library hooks and other trappings needed for real, industrial strength application development.

Like what? Common Lisp is as capable of writing 'industrial strength' applications as any other languages. And its dynamic properties mean that you can debug them on-line, without taking systems down for massive recompiles.

what i'd like to see Lisp and Smalltalk and Eiffel develop is a good compiler and a good interface to the system and GUI code.
(no, Java does not cut it.)

Commercial Common Lisp compilers are good enough. What do they lack their C/C++, Java, and other counterparts? (Specific technical features please.)

As far as GUI coding goes, ALL languages but Java seem in the same leaky boat when it comes to developing cross-platform applications. (Java is in its own boat, one with different problems than the rest.)

Re:developers need to see the light, not suits

[sv0f]

And try parallel programing with lisp. There simply isn't such a thing. Sad, sad.

When you grow tired of sticking your head in the sand, have a look at ITA's website. They make the software that powers Orbitz's web site. If this is not an impressive testament to Common Lisp's ability to do industrial strength parallel programming, I'm not sure what would satisfy you.

You are correct that Common Lisp lacks a standard definition of parallel programming constructs, and thus parallel programs must use vendor-specific extensions. (There are some efforts to abstract over the differences.) In this regard, Common Lisp seems in the same boat as most other languages.

Re:developers need to see the light, not suits

[Gabe Garza]

This just isn't true. All major Common Lisp environments, Commercial and Free, offer a painless way to call C functions. No recompilation of any kind needed, you just declare the C function, load the library, and call it.

As for GUI's, there's something called CLIM, the Common Lisp interface manager. It's a standardized Common Lisp GUI. There are at least 4 major implementations. Using it, you can write a GUI application that is Source-code compatible across anything Commons Lisp/CLIM runs on, which includes pretty much any PC operating system as well as a plethora of Unix workstations

In fact, Lisp is ideal for ``Industrial Strength''; application development. It's portable. It's (nearly always) compiled to native code. It offers superb exception handling. It has a package system. You can update running, deployed programs without stopping them. There are many other good reasons.

As for GTK specifically, there are no fewer then 2 Common Lisp GTK bindings out there.

Re:developers need to see the light, not suits

[Gabe Garza]

Too damn right. And try parallel programing with lisp. There simply isn't such a thing. Sad, sad.

There is such a thing. All the major commercial implementations (Franz's Allegro Common Lisp, www.franz.com, Xanalys's LispWorks, www.xanalys.com, Macintosh Common Lisp, www.digitool.com) as well as one of the major free (Free as in honestly free: public domain) Common Lisps support multithreading using largely the same interface.

Re:developers need to see the light, not suits

[Anonymous Coward]

Too damn right. And try parallel programing with lisp. There simply isn't such a thing. Sad, sad.

What?!

Actually, Scheme and Lisp have properties that make them highly ammenable to parallel processing. If you can restrict yourself to what is mostly a purely functional style of coding, a good compiler could make your program run in parallel with very little work on your part.

The idea of a purely functional language is that once a value is bound to a variable, that value never changes. (You can effectively change it through a recursive call where a new value is bound to it.) Essentially, there are no assignment statements. Admittedly, the idea is rather foreign if your coming from a procedural or OO language and takes some getting used to, but it really is a very powerful idea.

Sticking closely to this allows for a lot of neat possibilities. For one, it makes it feasible to mathematically analyze a program and prove its correctness.

More importantly in this case, because the bindings won't be changed, calculations can be run in parallel without worry of interfering with each other - it eliminates a lot of the headaches of semaphores. And, at least it Scheme (which I'll use here since I know it better), the report purposely doesn't define an order in which variables get evaluated and bound, except in specific cases. For example, the normal let statement is allowed to evaluate and bind its variables in any order.

So suppose you had a function to sum the values in a binary tree. You might write something like:

(define sum
(lambda (tree)
(if (list? tree)
(let ((a (sum (car tree)))
(b (sum (cdr tree))))
(+ a b))
tree)))

In Scheme the branches of the let statement may be evaluated and bound in any order. A Scheme compiler that supported parallel programming might actually have a parallel let statement that could compile this so as to execute both branches simultaneously. This function would then execute in a time proportional to the depth of the tree, given sufficient processors. No need to bother with explicit thread code, starting and stoping, locking, semaphores etc. The compiler could manage that for you and allow you to easily parallelize a program.

As far as a GUI system goes, there are at least several implementations of Scheme and Lisp with GTK bindings and Smalltalk had one of the first GUI systems.

Re:developers need to see the light, not suits

[dup_account]

I imagine what the comment was saying is that it isn't "C". This means that all of the libraries created in "C" aren't automatically bound to the language. Perl, Ada, Java, and Lisp all have this "problem". The usual response is 1) there is a "painless" way to call C functions, or 2) the library that was mentioned has a binding (ie GTK binding).

Personally, this is a major reason why I don't use Ada. Sure you could add in C functions, sure there were bindings... But! it was a real pain to do. Calling C functions was annoying and the bindings I was forced to use (the only binding that existed) were broken. So things are easy to call via C functions calc_some_value(x,y) is easy, but when you start getting into callbacks, it becomes more difficult. I avoid Perl GUI programming for the same reasons.

Sure Lisp is industrial strength, but if I have to do lots of extra work to rapid develop something, I feel like I am losing the rapid development. (This seemed to be one of the benefits of Lisp, rapid development).

We really need some sort of library system (and don't say activeX or COM) that languages can automatically support... Just load the library, and call into it with the languages native invocations methods...

Re:developers need to see the light, not suits

[Anonymous Coward]

GUIs are obsolete, and only used by computer novices. Drop the legacy technology and switch to the command line!

Re:developers need to see the light, not suits

[NetSettler]

Re: GUIs are obsolete, and only used by computer novices. Drop the legacy technology and switch to the command line!

Or the web. I've been just writing programs that talk straight to the web and using something like Emacs or Microsoft FrontPage HTML support as a GUI designer (depending on whether you like writing raw HTML or doing it WYSIWYG style).

Re:developers need to see the light, not suits

[RevAaron]

Take a look at Smalltalk/MT or Dolphin. Examples of what well-integrated Smalltalks can be like. For Windows only, but that's where the money is. And the market. Great Win32 System and GUI integreation.

Re:developers need to see the light, not suits

[rmstar]

In Scheme the branches of the let statement may be evaluated and bound in any order. A Scheme compiler that supported parallel programming might actually have a parallel let statement that could compile this so as to execute both branches simultaneously. This function would then execute in a time proportional to the depth of the tree, given sufficient processors. No need to bother with explicit thread code, starting and stoping, locking, semaphores etc. The compiler could manage that for you and allow you to easily parallelize a program.

Ok! That sounds actually great, and I really dig it. But where is something like that? Where are at least working MPI bindings so I can try to write a let like that myself?

NIL

As far as a GUI system goes, there are at least several implementations of Scheme and Lisp with GTK bindings and Smalltalk had one of the first GUI systems.

'nother woan that sound kinda cool. Now, WHERE ON EARTH ARE THEY? I would not be doing the crap I'm doing if I knew where they are.

N I know how to google, sire.

Lisp commenting.

[Kaz Kylheku]

Comments are easily placed in Lisp code. And also, there is a way to embed documentation into functions and some other objects via the documentation string feature. This allows information about a function to be dynamically retrieved. The following illustrates how comments are written in the predominant Lisp code formatting style:

;;;
;;; This function computes the factorial of its
;;; argument x. The argument must be a
;;; non-negative integer. If the argument is 0
;;; or 1, the result is 1. Otherwise the result
;;; is the product (x)(x-1)(x-2) ... 2.
;;;

(defun fact (x) "Computes the factorial function"
(case x

;; if n is zero or 1, return 1
((0 1) 1)

;; otherwise compute factorial recursively
(otherwise (* x (fact (1- x))))))

The comp.lang.lisp FAQ has a few pointers on style, including use of whitespace, comment placement, how many semicolons to use for what comments and the like.

Re:Lisp commenting.

[NetSettler]

I think the original poster meant that READ does not preserve comments. This is a true remark, though the idea that it's "terrible" may be a little exaggerated. Most source-to-source transformations don't result in new source files, but are done as part of compilation. No language I know of uses comments (well, ok, PostScript and Teco maybe a little, but by abuse only) to help them compile code, so that's probably a reasonable optimization.

There is a technique one can use for modifying the reader to find comments and attach them to the parent object using hash tables, repatriating them later. I've seen this done for some source-to-source translation facilites such as one provided with the Symbolics system for upgrading user code between releases. It is more work, but given how often the issue comes up, the extra cost is probably reasonable in exchange for how much easier it is to transform code without worrying that comments are intervening.

The alternative is to do like Interlisp did and make comments be structures, but then you can only put comments in certain places. It's plainly more flexible to put them anywhere you want and we pay the cost for that in the READ function.

Re:Lisp commenting.

[ftobin]

While not trying to put down lisp, it seems like what is desired here is something analogous to Python's docstrings:

class Square(Shape):
"""An abstract representation of a box"""

def size():
"""Return the size of the box"""
return self.x * self.y

The docstrings are queriable (object.__doc__), and there exist excellent tools to give a module/class/method's documention: pydoc. pydoc is such a nice wonder.

IIRC, Python 2.2. has docstrings applicable to object attributes, too.

Re:Lisp commenting.

[ftobin]

Heh, whoops; I forgot that my 'size' method's signature should've been "def size(self):".

Re:Lisp commenting.

[Phil Gregory]

I think the original poster meant that READ does not preserve comments. This is a true remark, though the idea that it's "terrible" may be a little exaggerated.

That's not entirely true. While, strictly, comments are diregarded by the interpreter, many Lisp dialects have the conecpt of docstrings, where the first element of a function or structure is a string describing the object's purpose. For an example, let me steal some elisp code from ILISP:

;;;
(defun bridge-call-handler (handler proc string)
"Funcall HANDLER on PROC, STRING carefully. Error is caught if happens,
and user is signaled. State is put in bridge-last-failure. Returns t if
handler executed without error."
(let ((inhibit-quit nil)
(failed nil))
(condition-case err
(funcall handler proc string)
(error
(ding)
(setq failed t)
(message "bridge-handler \"%s\" failed %s (see bridge-last-failure)"
handler err)
(setq bridge-last-failure
(` ((funcall '(, handler) '(, proc) (, string))
"Caused: "
(, err))))))
(not failed)))


--Phil (Gee, I wish Slashdot would let me close the <TT> tag!)

Re:Lisp commenting.

[Phil Gregory]

Gee, I wish Slashdot would let me close the <TT> tag!

Erm, oops. So I had two <tt> tags at the top of my post and only one at the bottom. Preview was showing the monospaced font extending past my </tt>, galeon wasn't showing my the page source properly (it reloads the page to see the source--bad when on dynamically-generated pages), and </tt> isn't in the list of allowed HTML at the bottom. I jumped to a conclusion.

--Phil (Appropriately chagrined.)

Re:Lisp commenting.

[hding]

Lisp has the same facility. You can attach strings as documentation to functions, generic functions, and classes at the very least (possibly to more things, I can't remember offhand) and query them using documentation. E.g.

(defun square (x)
"Return the square of x"
(* x x))

(defclass square (shape)
((side-length :initarg :side-length))
(:documentation "A representation of a box"))

Then

(documentation 'square 'function)
returns "Return the square of x"

(documentation 'square 'type)
returns "A representation of a box"

Re:Lisp commenting.

[Gabe Garza]

While not trying to put down lisp, it seems like what is desired here is something analogous to Python's docstrings

While not trying to put down Python, Lisp has had docstrings since long before Python had them. Where do you think it got the idea from?:)

Re:Lisp commenting.

[sv0f]

While not trying to put down lisp, it seems like what is desired here is something analogous to Python's docstrings:

Common Lisp as had this capability for 15 years. The following is from Macintosh Common Lisp:

? (setq *SAVE-DOC-STRINGS* t)
T
? (defun hello-world ()
"Print 'hello world' to the terminal."
(write-line "hello world"))
HELLO-WORLD
? (documentation 'hello-world 'function)
"Print 'hello world' to the terminal."
? (defclass no-slots () ()
(:documentation "This class has no slots."))
#{STANDARD-CLASS NO-SLOTS}
? (documentation (find-class 'no-slots))
"This class has no slots."
T
?

AHH!!!!!

[the_2nd_coming]

I have never seen LISP before, now that I have, I have a very strong respect for those that can actual think in the the LISP way........

how can you write a math formula like that!!!!
my brain hurts......

Re:AHH!!!!!

[andrew cooke]

You get used to it ;-)

Seriously, it becomes natural. Just like using RPN HP calculators (which is kind of similar)

Re:AHH!!!!!

[sv0f]

how can you write a math formula like that!!!

You should see how Lisp folks wretch when they seem the horrors the **ML crowd has foisted on the world.

Aren't you tired of serving Lord infix and the dark side, Darth? ;-)

Re:AHH!!!!!

[grazzy]

im currently reading lisp in school.

and this infix notation is great, because if you think in the way of binary trees. and every node as a operation and the leafes as values you can very easily translate that notation into a binary tree and then calculate it.

for example.

Re:AHH!!!!!

[Anonymous Coward]

If you're referring to (+ 3 (* 2 5) 7), I think it's easier to read than the equivalent infix expression, provided you know how to read it:

"Sum together 3, the product of 2 and 5, and 7."

If you consider that the infix version (3+2*5+7) translates roughly as "take 3, add the result of the product of 2 and 5 to it, then add 7 to it" (without even taking into account precedence problems), it seems to me that "thinking the Lisp way" could cure some of your brain aches ;)

Re:AHH!!!!!

[jejones]

Your brain only hurts because it hurt a lot as a child when you had "My Dear Aunt Sally" and infix notation drilled into it, so much so that alternatives seem unnatural. With prefix (or postfix; FORTH chooses that alternative) notation, there's none of this operator precedence stuff to worry about; it's all simple and straightforward. Give it a chance.

Re:AHH!!!!!

[dakoda]

for years, I've been a die-hard C fan. code for speed, speed, size, and then speed again. I've made a few feeble attempts to learn Lisp, but they never really went anywhere. However, after reading the examples he provides, the lisp notation (pre/postfix?) seems very logical. Much more clever than the whole PEMDAS nonsense. I am guessing that, much like linux/windows, c/lisp each have their strengths and weaknesses.

just my 2 cents

Re:AHH!!!!!

[modulo]

Actually the programming language for the HP-48, RPL, is supposed to stand for "Reverse Polish Lisp", although it actually is a lot more like FORTH. (Has a couple list processing commands like HEAD and TAIL, but it's very stack focused)

your point, deflated

[Frothy Walrus]

(define (f n)
; calculates factorial of n
(if (= n 1)
n
(* n (f (- n 1)))))

there's plenty of room to hang comments...

Lisp Not Hard

[Putz19]

I learned CLISP during my last semester of College in my AI class(to ('01 Jan) ('01 May)) [Jan '01 to May '01]. I did not think it was all bad, the worst was making sure you have the right amount of ()'s matching.. This was solved with the ALMIGHTY VIM!! This handy editor color coded my code and made working in files a snap, also with the % command to see matching ()'s.

Just My CS 2 cents.

Re:Lisp Not Hard

[Evangelion]

If you think that vim is nice for lisp editing, try emacs.

Being able to send the current expression to the lisp interpreter with a keystroke to see if it evaluates correctly is awesome once gotten used to ;)

Re:Lisp Not Hard

[Dom2]

Well, it's easy to get paren-matching emacs as well. I think it's turned on by default. But one more useful hint is to make the % key behave the same as in vi. This bit of elisp code does the trick.

(defun match-paren (arg)
"Go to the matching parenthesis if on parenthesis otherwise insert %."
(interactive "p")
(cond ((looking-at "\\s\(") (forward-list 1) (backward-char 1))
((looking-at "\\s\)") (forward-char 1) (backward-list 1))
(t (self-insert-command (or arg 1)))))
(global-set-key "%" 'match-paren)

Re:Lisp Not Hard

[divbyzero]

This is Lisp, after all. Shouldn't you have made it a lambda function passed to global-set-key? :-)

Re:Lisp Not Hard

[tamills]

In my last year of college (1985) I coop-ed with DoD in Baltimore (I'm sure some recognize the euphemism) and learned LISP on the job, with only a set of manuals and a Symbolics workstation.

I can honestly say I was writing productive code in less time with LISP than I have with any language since, including C, C++, Basic, Perl, Java, and Prolog. The language supports things being done easily. The dynamic nature of the language cannot be overstated as its main benefit.

Also, the funky notation is not truly odd. When you have only one structural rule, it is learned quite quickly even if it is quite different from usual language (like English: we say "three PLUS five" but not "PLUS three five"; sigh...)

Once you get past that point, LISP flows from the mind like water from a pitcher. God, I wish I could do some real LISP development, and not just play with Emacs code!

MOO!

[scrytch]

If I'd known you programmed in MOO, I'd have asked: what's your character name on LambdaMOO?

Anyway, implementing tail calling in MOO isn't as bad as it sounds, and for a trivial case of it, I implemented it. You do lose most of callers(), and thus have less meaningful tracebacks, but I just keep the last frame for caller and caller_perms(). The only thing that permanently breaks is callers() based security like @gag and @refuse, but I implemented a "taint" mechanism (in-db, could easily have been done in-server) that just held the set of perms used. gag_p was then a simple matter of $set_utils:intersection(this.gaglist, permset)

Sometimes wish I still had my old MOO code, but I gave up on MOO long ago after seeing that it just wasn't going to get anywhere. Shame I don't see any real languages anymore with integrated security like MOO had.

SICP is what you want

[Frothy Walrus]

Structure and Interpretation of Computer Programs is probably the best computer science text ever written (with the possible exception of Knuth's Art of Computer Programming), and uses Scheme. it's such a small language (14 basic reserved words, i think?) with such clear syntax that little time is spent teaching the language, and more time is spent teaching programming.

after reading SICP, it will take you perhaps a week to learn any computer language. highly recommended.

Re:SICP is what you want

[brsett]

after reading SICP, it will take you perhaps a week to learn any computer language. highly recommended.

Now, now, a little hyperbole is fine, but this is silly. Many, many (,many!?!) languages develop their expressiveness via keywords and complex idioms, rather than functional constructs and take much longer than a week to learn (I consider someone who has learned a language to be able to write any program they normally could in that language). This is not a bad thing, its just different. Languages such as C++ and especially Ada use keywords to denote many things about the program that languages such as lisp do not bother to enforce, or use convention instead (as far as it goes C is a quite simple language syntax wise, but many of its most powerful idioms could not be learned in a week).

Re:SICP is what you want

[NetSettler]

If you like keywords rather than pure functional programming, you should be checking out Common Lisp, not Scheme. This is a major political difference between these two very different Lisp-family languages.

This issue is discussed in more detail in part 2 of the interview, expected out in a day or two.

Re:SICP is what you want

[brsett]

I do like Common Lisp (and more recently I thought Dylan was a nice extension to Common Lisp), my only real complaint is about the lack of finalization semantics, particularly C++ destructors which I think are far and away the best object lifetime management system going. LISP, just like all the languages that have copied its gc system, neglects to understand that there are many other resources I need to manage other than memory (db handles, shared memory regions, mutexes, files, etc.). Macros and closures allow me to emulate this in a single lexical enclosure, but if I wish to do the resource management in different lexical blocks (perhaps using producer/consumer idioms), no way other than manual resource management is offered. I cannot setup a consistent, automatic system. Oh well, I guess I am just one of the unwashed masses who thinks GC causes more headaches than it really solves.

Great interview, probably the best I've seen on Slashdot (or at least that I remember in the last few years)

Re:SICP is what you want

[mrdlinux]

* (describe 'unwind-protect)

UNWIND-PROTECT is an external symbol in the COMMON-LISP package.
Special form documentation:
Unwind-Protect Protected Cleanup*
Evaluate the form Protected, returning its values. The cleanup forms are
evaluated whenever the dynamic scope of the Protected form is exited (either
due to normal completion or a non-local exit such as THROW).

More information can be obtained from the Hyperspec

Re:SICP is what you want

[Anonymous Coward]

These keywords and idioms you speak of are rather trivial seeming after SICP. Basically, everything becomes rather obvious, so all you need to do is see something, and you can use it, often even at near-full effectiveness. People who think it's more complicated than that, generally just don't realize where the useful lines of complexity are at. In a sense, it's the difference between learning to program in a language and learning how a language lets you program.

I'll reinforce the previous poster: Given a decent reference, a week is plenty to get up to speed--and that's not a week of heavy study either, just a week. Of course, there's also libraries/APIs to learn and those can pretty much take arbitrary amounts of time just to review Still, it's just memorization, and a very good reference can almost completely replace memorizatiom. Admittedly, those are getting pretty rare now as everyone likes to write big thick "knowledge dump" tomes that generally elevate every little detail to equal importance.

(Although, I suppose you could say SICP weeds out people who aren't going to "get" programming at that level, but I think that's being unduely pessimistic and cynical.)

Re:SICP is what you want

[Bobo the Space Chimp]

I love that form. I laughed at the clunky try throw catch crap in C++ when it came around.

Comparison with ML/OCaml

[Random Man]

I would love to hear Kent Pittman compare Lisp with the growing interest in quasi-functional languages such as ML and especially OCaml.

These languages give up the s-expression syntax, and thus the powerful Lisp macro facility which people like Paul Graham believe to be critical to high-end Lisp programming.

What they offer in return is static type checking, which has saved me countless hours of bug hunting, and some wonderful mechanisms for abstraction and code clarification: sum types, modules, functors, and exceptions.

I used to do all my work in Lisp/Scheme. And occasionally I miss the simple clarity of the s-expression syntax and the macros. But these days I do everything in OCaml and have been amazed at the ease with which conceptual structures become code.

Re:Comparison with ML/OCaml

[NetSettler]

I think there are some remarks on this in the second half of the interview. Maybe re-ask this question in response to that?

Sorry the interview got split. There was apparently a length limit, perhaps caused by a pre-allocated fix-length buffer due to failing to use a language with dynamic memory allocation. ;-)

Re:Comparison with ML/OCaml

[chromatic]

Close... it's a database field size limit. (Perl has dynamic memory allocation, but you knew that. :)

Re:Comparison with ML/OCaml

[sigue]

A quibble with your "and thus"...

There is no inherent link between s-expressions
and the powerful Lisp macro facility. It is
certainly easier to implement with s-expression
syntax, but can (and has) been done in languages
with infix syntax. See Dylan for example, and Java Syntax Extensions. While neither of these implementations allows using the full power of the language to generate code (i.e., procedural macros), there's no reason that couldn't also be done in an infix language.

python v lisp

[Anonymous Coward]

I used to love lisp (well, scheme more so) but then I got into Python and I havent looked back. Hello world in python, at it's easiest, is

print "hello, world"

I think thats the first thing that won me over, the 2nd was that it was all infix, which in my heart, i love better than prefix, and 3rd would have to do the lack of syntax structrures... not a ton of parents or other things around, but rather indenting... pretty nice.

Re:python v lisp

[Anonymous Coward]

Even easier..

echo "hello world"

No language involved. Plus it is portable to 99.9% of computers out there.

Re:python v lisp

[sv0f]

Hello world in python, at it's easiest, is print "hello, world"

How about (write-line "hello, world")?

Lispers feel the same way about about have Lots of InSpired Parentheses, if this makes any sense.

Re:python v lisp

[Per Bothner]

In Lisp it's even easier:

"hello, world"

This is because a string is a self-evaluating expression.

No place to hang the comments?!

[alispguru]

@ Representing programs as S-expressions, incidentally, has one terrible cost - it's hostile to comments. Because there's no place to hang the comments, LISP code tends to be uncommented within the text of the code. Just curious - when did you stop writing Lisp? If you actually used a Symbolics, how could you have missed the standard semi-colon commenting conventions, which Lisp-aware editors grok quite nicely:

; - inside code (at end of line)
;; - inside code (beginning of line, indented)
;;; - function header comments (column 1)
;;;; - Big block comments

Or have you never heard of the ANSI standard generic function (documentation place &optional type) that lets you access comment strings, which can be hung just about anywhere? I even have a little package I picked up in 1997 that trolls Lisp source code, extracts the documentation strings, and emits javadoc-like documents, in HTML or TeX or RTF.

"no place to hang the comments", indeed.

You might, just possibly, be thinking of Interlisp, which did have a comment form that could be placed inside your function code and was edited with the structure editor like everything else. In ancient times you had to be a little careful as to where you put comments, but that problem went away with Xerox Common Lisp, around 1986 or so.

Help me start learning

[Anonymous Coward]

I've been trying to follow the online tutorial found at lisp.org, but I get stuck at the hello world example (Pretty discouraging). When I try:
(write-line "Hello, world.")
I get: "Symbol's function definition is void: write-line"
Is there a library I need to load into emacs (how do I do that)? Any help will be appreciated.

Re:Help me start learning

[reflective recursion]

For one thing, Emacs uses elisp. Elisp is not the same as Common Lisp (or Scheme). Common Lisp has "write-line" and Scheme has "display". As for Emacs, well I don't think there is such a thing because it is integrated with a text editor (and has no terminal, or standard output).

I suggest getting CMU Common Lisp (CMUCL) or CLISP. Check out www.lisp.org.

Re:Help me start learning

[vsync64]

Emacs uses a quirky dialect of a rather ancient Lisp. If you want to learn Common Lisp, you will need to get a Lisp environment. I recommend CLISP, due to its extreme portability, simple installation procedure (./configure; make; su; make install), and relatively friendly CLI when not used via an editor interface (tab completion mainly).

I recommend using ILISP with Emacs. It integrates with most of the Lisp environments out there and provides some neat features such as sending the new version of your defun to Lisp, and a slightly buggy buffer-package-matching thingy. Here's the Common Lisp devel stuff in my ~/.emacs:

Well, I would have put it here, except that even with all the text below, the Slashdot lameness filter cens0rizes me. Email me if you're curious and I'll send you a copy.

Lameness filter encountered. Post aborted! Reason: Please use fewer 'junk' characters.

[Sorry about this, but it looks as if I'll have to change the character ratios a bit...] Four score and seven years ago our fathers brought forth on this continent a new nation, conceived in liberty and dedicated to the proposition that all men are created equal. Now we are engaged in a great civil war, testing whether that nation or any nation so conceived and so dedicated can long endure. We are met on a great battlefield of that war. We have come to dedicate a portion of that field as a final resting-place for those who here gave their lives that that nation might live. It is altogether fitting and proper that we should do this. But in a larger sense, we cannot dedicate, we cannot consecrate, we cannot hallow this ground. The brave men, living and dead who struggled here have consecrated it far above our poor power to add or detract. The world will little note nor long remember what we say here, but it can never forget what they did here. It is for us the living rather to be dedicated here to the unfinished work which they who fought here have thus far so nobly advanced. It is rather for us to be here dedicated to the great task remaining before us--that from these honored dead we take increased devotion to that cause for which they gave the last full measure of devotion--that we here highly resolve that these dead shall not have died in vain, that this nation under God shall have a new birth of freedom, and that government of the people, by the people, for the people shall not perish from the earth.

CHAPTER 1

It was a bright cold day in April, and the clocks were striking thirteen. Winston Smith, his chin nuzzled into his breast in an effort to escape the vile wind, slipped quickly through the glass doors of Victory Mansions, though not quickly enough to prevent a swirl of gritty dust from entering along with him.

The hallway smelt of boiled cabbage and old rag mats. At one end of it a coloured poster, too large for indoor display, had been tacked to the wall. It depicted simply an enormous face, more than a metre wide: the face of a man of about forty-five, with a heavy black moustache and ruggedly handsome features. Winston made for the stairs. It was no use trying the lift. Even at the best of times it was seldom working, and at present the electric current was cut off during daylight hours. It was part of the economy drive in preparation for Hate Week. The flat was seven flights up, and Winston, who was thirty-nine and had a varicose ulcer above his right ankle, went slowly, resting several times on the way. On each landing, opposite the lift-shaft, the poster with the enormous face gazed from the wall. It was one of those pictures which are so contrived that the eyes follow you about when you move. BIG BROTHER IS WATCHING YOU, the caption beneath it ran.

Inside the flat a fruity voice was reading out a list of figures which had something to do with the production of pig-iron. The voice came from an oblong metal plaque like a dulled mirror which formed part of the surface of the right-hand wall. Winston turned a switch and the voice sank somewhat, though the words were still distinguishable. The instrument (the telescreen, it was called) could be dimmed, but there was no way of shutting it off completely. He moved over to the window: a smallish, frail figure, the meagreness of his body merely emphasized by the blue overalls which were the uniform of the party. His hair was very fair, his face naturally sanguine, his skin roughened by coarse soap and blunt razor blades and the cold of the winter that had just ended.

Outside, even through the shut window-pane, the world looked cold. Down in the street little eddies of wind were whirling dust and torn paper into spirals, and though the sun was shining and the sky a harsh blue, there seemed to be no colour in anything, except the posters that were plastered everywhere. The blackmoustachio'd face gazed down from every commanding corner. There was one on the house-front immediately opposite. BIG BROTHER IS WATCHING YOU, the caption said, while the dark eyes looked deep into Winston's own. Down at streetlevel another poster, torn at one corner, flapped fitfully in the wind, alternately covering and uncovering the single word INGSOC. In the far distance a helicopter skimmed down between the roofs, hovered for an instant like a bluebottle, and darted away again with a curving flight. It was the police patrol, snooping into people's windows. The patrols did not matter, however. Only the Thought Police mattered.

Behind Winston's back the voice from the telescreen was still babbling away about pig-iron and the overfulfilment of the Ninth Three-Year Plan. The telescreen received and transmitted simultaneously. Any sound that Winston made, above the level of a very low whisper, would be picked up by it, moreover, so long as he remained within the field of vision which the metal plaque commanded, he could be seen as well as heard. There was of course no way of knowing whether you were being watched at any given moment. How often, or on what system, the Thought Police plugged in on any individual wire was guesswork. It was even conceivable that they watched everybody all the time. But at any rate they could plug in your wire whenever they wanted to. You had to live -- did live, from habit that became instinct -- in the assumption that every sound you made was overheard, and, except in darkness, every movement scrutinized.

Winston kept his back turned to the telescreen. It was safer, though, as he well knew, even a back can be revealing. A kilometre away the Ministry of Truth, his place of work, towered vast and white above the grimy landscape. This, he thought with a sort of vague distaste -- this was London, chief city of Airstrip One, itself the third most populous of the provinces of Oceania. He tried to squeeze out some childhood memory that should tell him whether London had always been quite like this. Were there always these vistas of rotting nineteenth-century houses, their sides shored up with baulks of timber, their windows patched with cardboard and their roofs with corrugated iron, their crazy garden walls sagging in all directions? And the bombed sites where the plaster dust swirled in the air and the willow-herb straggled over the heaps of rubble; and the places where the bombs had cleared a larger patch and there had sprung up sordid colonies of wooden dwellings like chicken-houses? But it was no use, he could not remember: nothing remained of his childhood except a series of bright-lit tableaux occurring against no background and mostly unintelligible.

The Ministry of Truth -- Minitrue, in Newspeak* -- was startlingly different from any other object in sight. It was an enormous pyramidal structure of glittering white concrete, soaring up, terrace after terrace, 300 metres into the air. From where Winston stood it was just possible to read, picked out on its white face in elegant lettering, the three slogans of the Party:

WAR IS PEACE
FREEDOM IS SLAVERY
IGNORANCE IS STRENGTH

Scheme isn't dead? Then it should.

[DaaZ]

I say scheme because it's what I'm learning right but it could easily be extended to LISP in general.

The language has it's potential and I guess part of the reason why I hate it is because my scheme teacher is a complete moron who's exams are about verifying our ability to be a scheme interpreter.

But anyway I think it's an archaic language (it was invented in the 50's if I recall) and like anything invented nearly 50 years ago in the computer world, something better has evolved from it or was either created from scratch in a better way.

I hate the gazillions of parenthenses and especially the poor interface given to me by DrScheme (of course again there might be something better but it's our teacher's restriction).

I also don't think the language would have survived if it was not supported by universities morons who just don't want it to die. Leave it be! It's time is over!

Anyway... speaking about speed. We had a small project of doing fractals and compared it to a c++ program and the scheme program took nearly 20 times than the c++ to do the same recursion level.

So don't talk about nanoseconds here, we're more talking about days and months faster with a c++ program. (Btw the c++ prog took me 5 minutes to write while the scheme took me nearly 2 hours. Of course I'm advanced in c++ and was beginning in scheme but still, there's too much fighting with the language itself).

So in final words. Carry on. Nostalgia and the computer don't mix too well, once something is too old (and scheme was too old maybe 20 years ago...) drop it and go on to something else.

Re:Scheme isn't dead? Then it should.

[Gabe Garza]

But anyway I think it's an archaic language (it was invented in the 50's if I recall) and like anything invented nearly 50 years ago in the computer world, something better has evolved from it or was either created from scratch in a better way.

Lisp has evolved. ANSI Common Lisp is a very different language then what was used in the 50's. It has been continously evolving for nearly half a century.

I hate the gazillions of parenthenses and especially the poor interface given to me by DrScheme (of course again there might be something better but it's our teacher's restriction).

Nearly all serious Lisp development is done in an Emacs-like editor that has built-in support for writing Lisp programs. This support includes facilities that make keeping paranthesis balanced trivial.

I also don't think the language would have survived if it was not supported by universities morons who just don't want it to die. Leave it be! It's time is over!

I'd highly recommend you go to www.lisp.org and look at the hundreds of huge commercial applications that have been written in Common Lisp. It is not an obscure research language: If Common Lisp was only used by ``universities morons,'' would 2 major vendors (www.franz.com, www.xanalys.com) be able to make money off it? Incidently, both the preceeding sites--especially www.franz.com--list commercial customers who have been satisfied with developing software in Common Lisp.

Anyway... speaking about speed. We had a small project of doing fractals and compared it to a c++ program and the scheme program took nearly 20 times than the c++ to do the same recursion level.

It's very important to note that Scheme is not Common Lisp. Scheme is a very different language: Scheme is about having an elegant tool to solve problems; Lisp is about having a tool to elegantly solve problems. In particular Common Lisp is typically compiled to native code and allows the programmer to include type declarations. These two features alone can improve speed by a couple orders of magnitude. To be fair, some Schemes support these features but, AFAIK, it's not standardized.

Re:Scheme isn't dead? Then it should.

[geekoid]

Nearly all serious Lisp development is done in an Emacs-like editor that has built-in support for writing Lisp programs. This support includes facilities that make keeping paranthesis balanced trivial.
great, a language that needs a special editor to maintain parens.

Re:Scheme isn't dead? Then it should.

[Evangelion]

oh please, have you ever tried to write C++ in notepad?

if you're doing any programming in any language, you should have an editor suited to that task.

Re:Scheme isn't dead? Then it should.

[jacobm]

Maybe your teacher really is a moron, but you're sounding just like one of the many many people (myself included, once upon a time) who get upset with Scheme because it actually forces them to understand programming at a deep level as opposed to just banging out code that they only understand poorly. Ask yourself, if you can't hand-evaluate a program, how can you claim you know what it does? Maybe (probably) you're "fighting with the language" exactly because you don't understand this area as well as you cood. Particularly in Scheme, learning the semantics in detail is an extremely worthwhile exercise, as Scheme's semantics are very simple [thanks in part to those parentheses you hate so much]. Vague understandings of the semantics of any language lead to programs that you only vaguely understand, and that only work sorta-kinda. If you aspire to be that kind of programmer, quit now and do something else. And about your fractal program, I suspect that your Scheme algorithm was a worse algorithm than the C++ version. Newcomers to Scheme frequently do things like accidentally computing recursions more frequently than necessary, and if you're seeing that big a speed difference it's very likely that's what's going on. Also, DrScheme imposes a pretty big (constant factor) speed penalty itself due to all of the debugging support it provides. If you ran your program directly in MzScheme you'd gain significant speed savings, but nothing compared to optimizing the algorithm to remove inefficiencies.

Re:Scheme isn't dead? Then it should.

[Jon Howard]

"...especially www.franz.com--list commercial customers who have been satisfied with developing software in Common Lisp."

Here's a link to the "Success Stories" section of www.franz.com - I believe that many people will find these to be particularly surprising, but that's a prejudice I'll attempt to debunk through action rather than words.

Re:Scheme isn't dead? Then it should.

[Anonymous Coward]

Maybe your teacher really is a moron, but you're sounding just like one...

Re:Scheme isn't dead? Then it should.

[page fault]

Anyway... speaking about speed.

DrScheme is a Scheme interpreter. You're comparing a Scheme interpreter to a C++ compiler. This is meaningless.

It's not clear whether you wrote both programs or whether you wrote a simple fractal program in Scheme and then compared it to a C++ program downloaded from somewhere. There are a number of clever algorithmic optimizations often implemented in fractal programs you're likely to download. These optimizations can have a dramatic effect on the runtime of the program. Chances are you didn't implement these in your Scheme code. Unless you're comparing the same algorithm, the same language implementation mechanism (compiler/interpreter), on the same hardware, etc., the results are meaningless.

P.S. I seem to recall that the DrScheme guys have a compiler available for MzScheme (could they possible have chosen more unfortunate names?). I don't know how it stacks up against other Scheme compilers. I suspect Stalin generates faster code.

I'm a happy IT drone

[Anonymous Coward]

Perl had sucked. His wife hadn't.

God, he was beat at every turn. Frustrated at every corner. No good thoughts or beautiful visions before the moment of truth. Only blackness, a life of dull, planned movements as consistent and boring as a bran-concious geriatrics bowel movement. For a moment he thought he might cry.

Lisp/Scheme implementation

[mystik]

Here @ NEU, some professors are part of 'TeachScheme', which is an effort to push Scheme into CS curricula. They have actually put togeather a scheme implementation, DrScheme, which provides an excellent interactive environment for writing and learning scheme http://www.cs.rice.edu/CS/PLT/packages/drscheme/ Oh, and it's GPL too. runs on Mac/Windows/linux.

syntax nothing to be proud of

[ezekeze]

The thing I personally like about (+ (* 2 y) x) rather than 2*y+x is that it simplifies my editing.

Abd then bragging about how easy it is to write editor macros to manipulate expressions? some of the examples ended in lines like:

(string &lt (first-name name1) (first-name name2)))))))


Crapping closing parens like that makes the language difficult to read without a text editor for matching. And it hurts my eyes ;-).

Re:syntax nothing to be proud of

[Gabe Garza]

Crapping closing parens like that makes the language difficult to read without a text editor for matching. And it hurts my eyes ;-).

In practice, Lisp programmers always use an editor that supports parenthesis matching. Something I've found after learning Lisp is that I don't notice the parenthesis at all; they're a non issue: I let emacs deal with them. Instead, I read code by how it's indented. Paranthesis are for the compiler, and indentation is for the programmer :)

Re:syntax nothing to be proud of

[sv0f]

Crapping closing parens like that makes the language difficult to read without a text editor for matching. And it hurts my eyes ;-).

Just think of it as trading all of your semicolons, colons, parentheses, braces, brackets and weirdo digraphs and trigraphs (e.g., ->) -- all that line noise -- for two characters, opening and closing parentheses. Once you do, you stop seeing them.

(Trust me. If you don't, note that I made a similar comment in the past and a C++ type did some actual comparisons that backed me up.)

The gains are metalinguistic: Your programs are now infinitely malleable by other programs, you can customize the lexical and syntactic structure of the language, you can effortlessly write new languages on top of Lisp (ever check out the internal representations of GCC?), etc.

Re:syntax nothing to be proud of

[ezekeze]

Or, if you program in python, indentation is for both the compiler and the programmer!

I can buy the argument that the parens become a practical non-issue using decend text editors, and proper indentation. I just find it aesthetically unpleasant, and not a language feature on the plus side (at best at 0, and for newbies a negative).

Though I used lisp for some coursework and found that once I got my head thinking in the correct way I could be productive, I never achieved the affection for the language some people have (and I blame the syntax!) Surely there are functional languages that have the zen-like qualities lisper's seem to adore, but don't make me upchuck when I see the code written on a page?

Re:syntax nothing to be proud of

[SangoDaze]

Don't forget, you don't need to sit there counting parentheses in order to follow Lisp code -- emacs (and other Lisp/Scheme editors) indent the code as you type it. While the whitespace is not important to the function of the program (unlike Python for example), it is critical to readability.

On a related note, I can't imagine using an editor (such as emacs) that does not indent code automatically regardless of the language. The Lisp way is 'anti-bugging,' finding errors as they occur. Having an editor that enforces indentation helps enormously in finding all sorts of typos (missing quotes, etc.) before you run your code.

Re:syntax nothing to be proud of

[marcoxa]

Assuming the presence in C/C++ (or similar
languages) of the approriate functions, your example would look

C/C++ 1

strcmp(first_name(name1), first_name(name2))

C/C++ 2

strcmp(name1.first_name, name2.first_name)

C/C++ 3

strcmp(name1->first_name, name2->first_name)

They all are similar in "typing complexity" to
the proper Lisp form

(string

It is really just the "position" of the parenthesis that is different.

Cheers

Re:syntax nothing to be proud of

[Anonymous Coward]

Where do you pull "not a language feature" from? Did you ever bother to use macros? Did you ever stop to think that the power of Lisp macros would not be feasible if you did not structure your code in some fashion?

As for Python, the indentation dependency must be a big pain in the ass when there is no corresponding structure to assure that the indentation is proper. Even the nastiest Lisp code can be easily reformatted into nice output, as a result. Try that with Python.

Re:syntax nothing to be proud of

[Anonymous Coward]

> Or, if you rogram in python, indentation is both for the compiler and the programmer

When I started using python, i really liked this feature ... until i was cooperating with somebody who was so used to his non python aware editor that he wrote his python code in that. also, at some point i had to do some cut-and paste editing

the parentheses (or, in other languages, keywords) let the compiler verify that all constructs are properly closed. or you can use a formatter and check whether the indentation really corresponds what you had in mind

Re:syntax nothing to be proud of

[gorilla]

Just think of it as trading all of your semicolons, colons, parentheses, braces, brackets and weirdo digraphs and trigraphs (e.g., ->) -- all that line noise -- for two characters, opening and closing parentheses. Once you do, you stop seeing them.

However having differing characters for different syntax elements means that we can read them more easily. If I see a } in a C like language, I know that that } belongs to a block. If I see a ) in lisp, I cannot tell if it's a block, or a function argument or other syntax element. english also has similar redundancy. we could write without uppercase letters and everyone, including kent m. pitman, would understand us. however by using uppercase letters we impart more information.

Re:syntax nothing to be proud of

[ezekeze]

No, never used macros. What I mostly remeber from lisp is car cdr cdr cdr ... and leaning over my barf bag.

I don't deny the languages power. But I take issue with its usability. Prefer compact languages with readable syntax. Remind me, how large is the Common Lisp langage reference?

What I do admire about lisp (&Scheme) is the incredible performance implementers have achieved, comparable to traditional compiled languages like C. I didn't think that was possible with the dynamic nature of Lisp. That performance beats the hell out of python.

And no, the python indentation isn't a pain in the ass, its simply bliss. To each his own and all that.

Re:syntax nothing to be proud of

[jaoswald]

Lisp's redundancy is more English-like, in that more is done with words (in Lisp terminology, "symbols") than with punctuation. Also, indentation is often used to clarify the grouping relations (just as in C).

In fact, as a Lisp programmer, your choices of interpretation for ")", that is "block", "function argument" or "other syntax element" seem strange to me. ")" doesn't denote any of those things. From your examples, I can't even tell what you mean by "syntax element."

"block" as in a block of execution in Lisp is denoted by symbols like "progn", "let", "defun", "tagbody", or by a number of macros and special forms. All of them group using ( and ), but you tell them apart by reading the first element. You see the grouping not by counting parentheses, but by the indentation under the first term. Poorly indented Lisp code is as hard to read as poorly-indented C code.

"function argument" is no different in Lisp from any other expression. "4" might be a function argument, so might (+ 3 5) and so might (if (>= x 0) x (- x)) [otherwise known as (abs x)].

Note, particularly, that the result of a if-then expression can be used as a value to be passed to a function. C can only express this using "? :" expression, which many C programmers don't even know about. This is *extremely* useful, and I miss it all the time in C.

"+" or "map" or "let" or "defun" look pretty different to me. When you see a parenthesis in C, how do you know whether it is a function call or a cast or a expression grouping? When you see a comma, is it separating function arguments, or is it a sequence operator? Those are actually more difficult problems than understanding ")" in Lisp.

Re:syntax nothing to be proud of

[jaoswald]

car and cdr are certainly important operators in Lisp, but if that is all you remember, you probably weren't shown much. Did you even use arrays? Hash tables? Structures? Objects? Common Lisp has all of those and more.

It sounds like you, along with many other students, were introduced to Lisp as a way to learn to express and manipulate recursive data structures. While Lisp is an excellent language for expressing those concepts, modern Lisp implementations (all the commercial ones of which compile to native machine code) have a much larger amount of functionality than car and cdr.

As an aside, you don't even have to use "car" and "cdr." You can also use "first" and "rest" if you find those more readable.

The Common Lisp language reference includes large sections on things that a typical C language reference, for instance, leaves out. Like a flexible way to express and manipulate pathnames in a OS- and file-system- independent fashion. A flexible and powerful condition (exception handling) system. A very powerful I/O formatting language (like printf on steroids). A powerful macro system. There is lots to discuss!

The book you are probably referring to, "Common Lisp: the language" also contains extensive discussions on a number of issues, large examples, and much material that is explanatory (like plots of all the transcendental functions over the complex plane, and the Lisp code that automatically generated the plots in PostScript). It is one of the best-written language references that exist for any language.

If you wish, you can summarize Common Lisp in about 50 pages, such as in the appendix to Paul Graham's "ANSI Common Lisp" book. That is useful enough for my day-to-day work. Or, for more detailed issues, I use Kent Pitman's (you know, the guy whose interview this was) web version of the ANSI standard, the Hyperspec.

Re:syntax nothing to be proud of

[gorilla]

In fact, as a Lisp programmer, your choices of interpretation for ")", that is "block", "function argument" or "other syntax element" seem strange to me. ")" doesn't denote any of those things. From your examples, I can't even tell what you mean by "syntax element."

But that's the exact point. I cannot tell exactly what a ")" means. I have to go back to the corresponding "(" and see what it's being used for. This means that reading lisp code, even properly formatted is slower for me than reading C code. Now this may well be due to my relative experiences in lisp & C, but I think that it's systematic. I agree that C overloads "()" & "," to mean multiple meanings, however I consider this a bug, not a feature. Having unique characters for each unique element of the syntax would be ideal, though not accomplisable with existing keyboards, character encodings and systems.

Re:syntax nothing to be proud of

[NetSettler]

Macros are a central part of the Common Lisp experience, and if you had a class or book that didn't teach them, it did you (and our community) a disservice by giving you a false sense of what normal programming is like in CL.

As to the size of the language spec, you should probably read my article Don't Judge a Spec by Its Cover which I wrote while the standard was just a draft and lots of people asked questions like these. There are 978 symbols (defined names) in Common Lisp. The ANSI CL spec, whose online incarnation is most easily accessed as the Common Lisp HyperSpec, is about 1195 printed pages. That's an average of about one page per defined name, a lot of which is examples of how to use them. That doesn't seem unreasonable to me on a per-function basis. Perhaps you'd be happier with fewer functions or fewer examples. Or we could have left out the helpful glossary of Lisp terms that provide a normative effect on the community's terminology. That would make the spec smaller.

I personally don't recommend reading the full spec cover to cover. I never have. I recommend reading the opening few chapters on syntax and evaluation, and then thinking of other chapters as libraries that you can read about as you need them. Then again, the spec is not intended to be a tutorial, people just get confused about that because it is (I'm told) more readable than most language specs. If I'd made it more unreadable, most people would never have approached it (as is the case for most other programming languages), and people would judge the language by tutorial texts. Lisp has a great many tutorial textbooks that are much smaller than the spec; the spec's first responsibility was to be a clear and accurate record of the language definition. The prior definition, Steele's Common Lisp: The Language was more brief, but left some things vague that led to portability problems and required more exposition to get right.

Re:syntax nothing to be proud of

[NetSettler]

Re: Having unique characters for each unique element of the syntax would be ideal, though not accomplisable with existing keyboards, character encodings and systems.

I believe you meant to say "finite" rather than "existing" keyboards. Whethere existing or possible to build, there's always a problem: Lisp intends users to add more syntax, and after a while you run out out of cute little operator markers, even in Unicode.

Lisp does, however, allow you to redefine the syntax as you like, so you're welcome (and enabled) to pursue your dream there, even without invading others' programs since you can do it in a private readtable (the guide the lisp reader uses for parsing). That's better syntax support than most other languages give you when you're dissatisfied.

Re:syntax nothing to be proud of

[jaoswald]

You miss my point. Why are you looking at the ")" in the first place? There's nothing to see there.

When you read Lisp, you look at the "(". Then there is a symbol that tells you what the S-expression is. If your text-editor cursor is on the ")" for some reason, use the appropriate navigation key to jump to the beginning of the s-expression, so you can tell what it is. Emacs does it with a single key (C-M-a, I'm guessing)

The ")" per se has no meaning. It takes no effort to understand.

If Lisp is so great, why isn't it more popular

[scruffy]

Long ago and far away, I programmed on an Xerox Lisp Machine (Dandelion) for several years and immensely enjoyed it, so my comments are intended to be friendly rather than hostile.

While weak typing and dynamic scoping are great for some things, it really trips up a lot of beginner programmers. An alternative Lisp that requires declarations might be very helpful for beginners. For strongly typed languages, compilers are a major help in debugging.

I would agree that other languages have become huge, I think the problem is that Lisp is a big and idiosyncratic language. Some things are in Lisp because of tradition. Some more things are in Lisp because they were grafted on top of the tradition. Then you have exceptions such as macros that violate the usual rules. It is true that Java is also huge, but each object in the API follows a very restricted syntax.

CLOS has all sorts of interesting things in it such as multiple inheritance and methods for combinations of objects. These are very nice once you have learned to use them, but there are lots of pitfalls, too.

I guess this means Lisp is a power tool for those who have learned how to use it. But it is difficult to learn, and unfortunately, a widely-used and widely-understood (more or less) language needs to appeal more to the lowest common denominator rather than only to those that get it.

Re:If Lisp is so great, why isn't it more popular

[Anonymous Coward]

Common Lisp is a strongly-typed, dynamicly-typed language, do not confuse that with weak-typing (C is weakly typed). Common Lisp closures are lexically-scoped, not dynamically-scoped either. Nor do I see how macros violate the usual rules. Remember, what you used on the LispM was not Common Lisp, it was most likely a variant of MacLisp. A lot of things have changed since then.

As for the lowest common-denominator, a language such as Java caters exclusively to them. And yos lose tons of power in the process. Better to have a language that gives you the tools to change itself, if necessary, to cater to the lowest common-denominator than to be stuck there.

Re:If Lisp is so great, why isn't it more popular

[emarsden]

While weak typing and dynamic scoping are great for some things, it really trips up a lot of beginner programmers.

It's more accurate to speak of dynamic or latent typing than weak typing. Languages in the lisp family are strongly typed (in the sense that type errors are always trapped, unless you've told the compiler that you care more about execution speed than safety); they differ from statically typed programming languages (such as Java and ML) in that type errors are trapped at runtime rather than compile time. However, you may get a warning at compile time if your compiler notices that you're trying to do something like add a fixnum to a character.

As for the dynamic scoping: most modern Lisps use lexical scoping (though dynamic scoping is also available with Common Lisp's special variables). The most notable exception nowadays is Emacs Lisp (a fairly crufty dialect), and it may be changed in the future.

I guess this means Lisp is a power tool for those who have learned how to use it. But it is difficult to learn, and unfortunately, a widely-used and widely-understood (more or less) language needs to appeal more to the lowest common denominator rather than only to those that get it.

if everyone followed this reasoning, their only form of locomotion would be crawling, because learning to walk (let alone to drive) would be a huge effort. Luckily, I think there still is a use for programmers who are willing to invest time to learn a language that can greatly improve their efficiency, and the pleasure they gain from their work.

Besides, historical baggage and huge complexity don't seem to prevent widespread use of C++ :-)

Re:If Lisp is so great, why isn't it more popular

[Anonymous Coward]

So, to reverse your analogy, if McDonald's is very popular, the food must be great!

Right?

No. It's because people are more familiar with McDonald's, because it has the best exposure (there's one on every corner).

If Lisp had the same exposure that C++ and Java get these days, it's very likely that it would be just as popular.

Too many people with CS degrees would look at you and say "Huh?" if you mentioned Lisp. This is sad, not only because education is neglecting one of the most significant developments *EVER* in the history of computer languages, but also because it shows the lack of broad coverage in today's CS education.

The typical CS degree today equates to: "Push em out the door, sell em to Microsoft." Very few educators care about more abstract facets of computer languages, and the ones that do are precisely the ones that get ignored by administration.

Re:If Lisp is so great, why isn't it more popular

[Don Geddis]

Did you read Kent's comments about (Common) Lisp vs. Scheme? Scheme is a much smaller language that is easier for beginners to learn all of.

Common Lisp was designed for real-world programmers to solve real-world problems. It was not optimized to be easy to learn; it was optimized to be productive for fluent speakers.

Any serious programmer will have more than enough time with their implementation language to become fluent. The real point is that fluent Lisp programmers are MUCH more productive than fluent programmers in most other languages.

Re:If Lisp is so great, why isn't it more popular

[Anonymous Coward]

Ohh, nice line of argumentation! Let me try:

I guess this means Linux is a power tool for those who have learned how to use it. But it is difficult to learn, and unfortunately, a widely-used and widely-understood (more or less) OS needs to appeal more to the lowest common denominator rather than only to those that get it.

Cute, huh? Although, really, you lost all your credibility when you failed to understand that Lisp is neither weakly typed nor dynamically scoped (in recent memory, anyway). I suggest you to shut up your face-hole before you start sounding even more stupid.

Re:If Lisp is so great, why isn't it more popular

[SecretAsianMan]

I guess this means Lisp is a power tool for those who have learned how to use it. But it is difficult to learn, and unfortunately, a widely-used and widely-understood (more or less) language needs to appeal more to the lowest common denominator rather than only to those that get it.

Well, one thing's for sure: you're either a Windows user or a hypocrite.

Re:If Lisp is so great, why isn't it more popular

[scruffy]

Instead of dynamic scoping, I should have said unrestricted global variables. Don't know what I was thinking.

Unless you go out of your way to declare a variable, a variable can be assigned any type of value. Variables are weakly typed. Values are strongly typed, but not variables (without additional effort). Also, lists do not have subtypes as far as I know, it could be a list of numbers, list of strings, or a mixture of types.

How do macros violate the rules? Well, the syntax in the macro does not need to be prefix notation, so all a beginner needs to learn is how to parse the individual syntax of each macro.

No, I am not a Windows user, but Linux is harder to learn and use.

And if you think my reasons are lame, you should at least try to come up with better ones. The conspiracy theories are not very good.

operator*() velocity vector

[epine]

The author's comment about the use of the * syntax in C to mean indirection immediately recalled his comments about different communities having different velocity vectors for the same constructs.

C++ manages to distinguish itself by having multiple velocity vectors for a single construct. The technical term for this is multiparadigm. It means: a furball of vectors all pointing in different directions.

In the generic phase space, operator*() no longer means indirection. It roughly means "evaluate iterator in default expression context".

vector<pair<int,double> > V;
for (vecpairiter a = V.begin(); a != V.end(); ++a) {
if (a->first == 42) {
meaning += a->second;
*a = pair<int,double>(0, 0.0);
}
}

Here operator->() is used to perform a non-default evaluation.

typedef vector<Object> Vobj;
typedef Vecobj::iterator Vobjiter;
typedef vector<Vecobjiter> VVobj;
typedef VVobj::iterator VVobjiter;
for (Vobjiter a = V.begin(); a != V.end(); ++a) {
for (VVobjiter b = a->begin(); b != a->end(); ++b) {
cout << *b << '\n';
}
}

Care to re-evaluate whether the human mind is really all that good at coping with ugly syntax?

The point of this example is that iterators themselves are first class objects. You assign, compare, modify these just like any other object. An iterator does not stand in for the object(s) it is capable of accessing.

If you did make it stand in for the object (bottom of indirection chain) you would still need a notation for dereferencing N levels from the top (regardless of the depth of the composition), otherwise iterator composition won't work.

I guess it would look like this:
a // value of fully dereferenced chain
^a // iterator at top of chain
*^a // one level dereference from top
**^a // two levels dereference from top

That cracks me up. STL programmers spend more time manipulating iterators than they do manipulating the base objects.

The only syntax I've never been able to swallow is Pascal's use of ^ to get me back to the thing I was really thinking about: getting the iteration correct.

the first time I saw lisp I said...

[geekoid]

...aAAAAAAAah MY EYES, THEY BURN!!!!
I get from this article the following:
1)you should use lisp because its emacs friendly.
2)we use notation thats different then what mathmaticians use, but is better
3)Lisp programmer feel that speed is un-important because there is enough processor speed. (that little comment made me want to put my fist through my monitor) clearly not made by an engineer.
4)bracket intense sphagetti code is a good thing.
5)old guys can be even more fanatical about an obscure language then 'lee7 w4rez d00dz'
6)its bad that the most powerfully, rich, and technological nation on the planet had a cultural influence on the computer industry.
7)LAMBDA is just a way to maintain lisp leetness

Re:the first time I saw lisp I said...

[Anonymous Coward]

1)you should use lisp because its emacs friendly.

I actually use and love lpe.

2)we use notation thats different then what mathmaticians use, but is better

*Shrug* sqrt(x) isn't exactly mathematical notation either.

3)Lisp programmer feel that speed is un-important because there is enough processor speed.

And it is the mistake of a C/C++ programmer to assume that speed and efficiency is only related to how fast a certain algorithm can be made to run. Lisp can be efficient and fast in development time. Lisp breaks a very distinct and important efficiency barrier that I never noticed (or had) in C: compile-time computations (i.e. _real_ macros).

4)bracket intense sphagetti code is a good thing.

It is only spaghetti code because it looks different to you. Get used to it and _every_ C/C++ program will look spaghetti.

5)old guys can be even more fanatical about an obscure language then 'lee7 w4rez d00dz'

I'm not an "old guy" or "lee7 w4rez d00d" but I certainly know that the principles in Lisp are generations ahead of most mainstream languages.

6)its bad that the most powerfully, rich, and technological nation on the planet had a cultural influence on the computer industry.

Were you reading the same article I was? His little story was not about American cultural influence, but why lambda and various others like car, cdr are still in the Lisp language even though the original machines are long past. You took it completely out of context.

7)LAMBDA is just a way to maintain lisp leetness

I don't think anyone is holding C or other languages from creating a lambda-like function, are they?

Re:the first time I saw lisp I said...

[Anonymous Coward]

> 1)you should use lisp because its emacs friendly

That was ONE of his points. But I think what he's really saying is that "Emacs is really good when hacking Lisp". Big deal, nothing to be so upset about.

> 2)we use notation thats different then what mathmaticians use, but is better

Mathematicians do use it. They just don't write it out. At least not most of the mathematicians. Although, there are some though; The Lambda Calculi people...

>3)Lisp programmer feel that speed is un-important because there is enough processor speed. (that little comment made me want to put my fist through my monitor) clearly not made by an engineer

What bothers you most with this expression:
x = y op z
1) That referencing x, y and z is done in 1 ms rather than 0.5 ms? ... or ...
2) That the "op" operation takes 2 seconds?
What he says is that ITS THE OVERALL DESIGN that you should worry about. It doesn't matter if your memory fetches and stores are really super fast, if your algorithms suck, it's still going to be slow.

> 4)bracket intense sphagetti code is a good thing

I'm not going to comment that one since you obviously haven't seen "spaghetti code" before.

> 5)old guys can be even more fanatical about an obscure language then 'lee7 w4rez d00dz'

Aren't you comparing apples and pears? Everybody knows that 99% of all "lee7 w4rez d00dz" can't program and are not very intelligent (how hard is it to push one file from one FTP server to another??). The remaining 1% are "lee7 w4rez d00dz" wannabes. For what reason, I don't know.

> 6)its bad that the most powerfully, rich, and technological nation on the planet had a cultural influence on the computer industry

I don't have a problem with that, and from what I read he didn't either. Forte!

> 7)LAMBDA is just a way to maintain lisp leetness

You don't get the point I'm afraid. Lambda is a concept rather than a Lisp construct. It allows you to look at functions as if they were any kind of language object (int, char, float, struct, or whatever). A (defun ..) (function declaration in Lisp) is merely a way to bind a name to a function object. This is most visible in Scheme where a (define (func arg1 arg2 ...) ...) is the same as (setf func (lambda (arg1 arg2 ...)...).

This means that you can refer to a function object with different names.. just like function pointers in C. The major difference is that you can create functions dynamically and statically without giving it a name.

Smalltalk does a similar thing which they call "Thunks". Thunks are basically objects (in the sense of OO) that can be called upon.

Personally I like Lisp for its lambda construct. It allows me to do similar things that C++ people do with STL and functors, but I don't have to bind a name to it - which is a feature most STL/C++ experienced programmers would like to have :)

Re:the first time I saw lisp I said...

[gregfortune]

3)Lisp programmer feel that speed is un-important because there is enough processor speed. (that little comment made me want to put my fist through my monitor) clearly not made by an engineer.

What the heck? I remember making exactly that comment when choosing Python to implement a Point of Sale system for a local business. The machines are powerful enough to run an interpreted language quickly, and it's a heck of a lot faster to develop under Python than under C++ or Java. If anything, that mentality *increases* my interest in the language...

Perhaps you are a hardware engineer or perhaps you work exclusivly on embedded systems. Either way, get a clue and recognize the usefulness of such a claim...

Re:the first time I saw lisp I said...

[jaoswald]

1) The thing that makes Lisp friendly to Emacs is its uniform programmatic structure. The real benefit of this structure is that it is trivial to write programs that write Lisp programs.

2) see answer to (1). Uniform notation means programs can understand (and manipulate) programs.

3) Lisp lets you add declarations to speed up a program that you have written, without changing the behavior. But only if you want to. Premature optimization is the root of all evil. Lisp lets you paint with a broad brush, so you can cover a large area fast. When you need to get the little tiny details painted, (the routines that run many times, and must be made faster) you switch to a smaller brush. Instead of having to paint the whole damn wall with the small brush. Lisp applications have been compiled which run at speeds competitive with Fortran applications.

4) brackets are the glue that holds the uniform notation together. With auto-parent matching and auto-indenting in your editor, you learn to see past the parens. See answer to (1) again.

5) What are you fanatical about? C? Obviously something is making you fanatically opposed to Lisp.

6) Huh?

7) lambda means that functions are just as much data in Lisp as numbers are in Fortran. When you write programs that crunch functions in the same way that Fortran crunches numbers, you can kick some serious ass.

Re:the first time I saw lisp I said...

[Anonymous Coward]

sorry about the bold. Yet again, Slashcode previews different than in publishes. ( apparently matches in the preview, not in the final result)

And I meant "paren" matching not "parent" matching.

Re:the first time I saw lisp I said...

[jacobm]

1) you should use lisp because its emacs friendly.

Among other, much more important things.

2)we use notation thats different then what mathmaticians use, but is better

Better for a programming language, yes. If you're really in love with having to know what's left versus right associative, try ML. Not that you'd like it, judging from your comments.

3)Lisp programmer feel that speed is un-important because there is enough processor speed. (that little comment made me want to put my fist through my monitor) clearly not made by an engineer.

Of course not. That would be stupid. Lisp programmers (or more likely Lisp implementors) feel that adding a constant slowdown is acceptable when it leads to markedly sped-up program development. All engineers do this: you don't design your CPU chips by thinking about NMOS and PMOS, and you generally don't even think about NAND and NOR gates either (one level of abstraction up). You could probably make a faster chip if you hand-optimized all that logic, but it would take 10 years to make the damn thing and you'd never be sure there wasn't some crazy obscure bug lurking in it.

4)bracket intense sphagetti code is a good thing.

Of course not. Lisp programs have a beautiful organization when programmed in the proper style. You're just not familiar with it.

5)old guys can be even more fanatical about an obscure language then 'lee7 w4rez d00dz'

No argument there. But fanatical in a good way.

6)its bad that the most powerfully, rich, and technological nation on the planet had a cultural influence on the computer industry.

Reading comprehension was never your strong suit in high school, was it?

7)LAMBDA is just a way to maintain lisp leetness

Or, there's no good reason to change it, so why break all the existing code and bother all the existing programmers? Besides, if you really care about it, FUNCTION instead of LAMBDA is a macro-definition away.

Try spending more of your effort trying to figure out what it is about Lisp and Scheme that make people like it rather than wasting it on knee-jerk vitriol.

Re:the first time I saw lisp I said...

[jmb_no]

I just want to take issue with one of your points which sounds like a misunderstanding (the rest sound mostly like flamebait to me):

3)Lisp programmer feel that speed is un-important because there is enough processor speed. (that little comment made me want to put my fist through my monitor) clearly not made by an engineer.

One of the things I love about Lisp is that you don't start by optimizing your solution before you know it. You start by solving the problem (correctly!), then you start optimizing the solution. This can either be done by recoding (considering the first code as a prototype) or evolving the code (typically choosing more optimal constructs and adding type annotations).

I have personally gotten a Lisp implementation to perform within 10-15 percent of C code on computationally intensive code. I could perhaps have gotten even closer if it had been important to me. Or I could have chosen to use C functions for the "inner loops" (which is in fact simpler than doing the same from Python). I sometimes do the latter when I need to squeeze the last few bits out (or when I already have optimized C solutions for known algorithms available).

The whole point is not to spend time on optimizing something which is already fast enough. When you do need to optimize the code, you profile it and start optimizing the bits that eat up your time instead of optimizing parts which are not contributing much to your run time.

Re:the first time I saw lisp I said...

[noc]

Perhaps this is part of the reason no one renames LAMBDA as FUNCTION:

(in-package :my-package)
(defmacro function (&rest stuff)
(cons 'cl:lambda stuff))
;;; Aw, crap, now what do I call function?
(defmacro sharp-quote (&rest stuff) ; maybe?
(cons 'cl:function stuff))

:-)

Re:the first time I saw lisp I said...

[noc]

I have personally gotten a Lisp implementation to perform within 10-15 percent of C code on computationally intensive code. I could perhaps have gotten even closer if it had been important to me. Or I could have chosen to use C functions for the "inner loops" (which is in fact simpler than doing the same from Python). I sometimes do the latter when I need to squeeze the last few bits out (or when I already have optimized C solutions for known algorithms available).

When you already have optimized C solutions, then using C for the inner loops is a good idea (obviously). However, when you're trying to squeeze every last cycle out of the machine, C is as lousy a choice as Lisp. You can give the compiler a bunch of hints, but you can probably hand-optimize its assembler output to be yet faster. In which case you want to write in as high-level a language as you can, giving the compiler all the hints you can, and hand-transform the result.

I almost never have a need to do this in Lisp or C.

Re:the first time I saw lisp I said...

[jmb_no]

...but you can probably hand-optimize its assembler output to be yet faster. ...

That is true (at least for some cases). Actually, some of the more modern[1] Lisp systems allow you to program Assembly directly from the Lisp system. You never need to leave the Lisp system for that last bit of assembly squeezing. The nice thing about this is that you can dynamically write and add/change assembly-implemented functions, so you can even make Lisp-functions which modify and recompile your hand-optimized "template functions" based on the particular input-data on this run of the system (adding the benefit of dynamic/run-time optimization to the static optimization you do with handcrafted assembly). Of course, you can also do this using standard compiled lisp functions.

I mostly use Assembly for kernel-level things that are hard to do from a C compiler though.

1. I assume this was the case for some of the older ones as well

Re:the first time I saw lisp I said...

[Bobo the Space Chimp]

>> 2)we use notation thats different then what
>> mathmaticians use, but is better
>
> *Shrug* sqrt(x) isn't exactly mathematical
> notation either.

Let's not forget the woody these C++ loving engineers get with their RPN (postfix) TI calcs.

Our calc uses postfix notation, Lisp uses prefix notation, which isn't what mathematicians use, but is better.

Re:the first time I saw lisp I said...

[dvdeug]

> 2)we use notation thats different then what mathmaticians use, but is better

Ken Iverson did a study of precendence among mathematicians. He found beyond the very basics, mathematicians couldn't agree on precendence. That's why APL has no precendence. GCC has an option to warn you when you're using precendence (outside the obvious) because too many C programmers don't remember the relative precedences of, say, the comparison operators and bit operators.

Also, when's the last time you saw a programming language that actually used mathematical notion? Most I've seen have a limited set of operators out of ASCII, and toss in several (e.g. the bit operators) that no mathematians's ever seen before. If they used matematical notion or arithmatic, that'd be different.

Closing parenthesis placement vs. readability.

[Kaz Kylheku]

The truth of the matter is that the closing parentheses don't matter one bit. What programmers read is the indentation. This is true across programming languages. Whether you are working in Lisp, Python or C, you use whitespace clues to determine program structure (in the case of Python, the language sees it the same way).

If a C program is properly formatted using one of the popular styles, then you can remove all of the braces and its meaning is still obvious; you can put the braces back automatically, or nearly so.

I've experimented with a C formatting style in which closing braces are stacked like in Lisp, and it didn't make one bit of difference to the readability of the code.

In a way, the closing brackets, braces or parentheses are for the compiler, not for the reader; the programmer simply has to ensure that they balance.

In some implementations of Lisp long ago, there was feature known as superbrace. If you wrote a right square bracket, it would close all outstanding open parentheses. I think there was one additional rule; the superbrace closing would stop upon encountering a matching open right bracket.

So you could write something like:

(defun hello() [let (foo bar) (a (b] ((c d(e)]

The first ] will properly close the outstanding parentheses all the way back to the [let. The second one will balance back to the (defun.

The superbrace did not catch on; it's not part of modern Lisp. That's could be because programmers simply didn't perceive enough of a benefit from the feature.

GUI bindings for Lisp

[Anonymous Coward]

I wish I could have gotten this in earlier, but I might as well bring it up now. Nowadays, almost any lanuguage you name has bindings to a graphical toolkit. Lisp, as near as I can tell, has nothing beyond low level X bindings and Garnet. Is it possible to create bindings for something such as WxWindows, which might make it possible for many people on many platforms to convince the powers that be that lisp is something they can and should use?

Re:GUI bindings for Lisp

[cstacy]

The commercial Lisp implementations from Xanalys and Franz, at least, have bindings to proprietary GUI toolkits that are programmed at fairly high levels. The Xanalys toolkit is called CAPI, and is portable across Windows and Unix. There is also CLIM, which is a standardized, cross-platform, very high-level GUI system; this is available for Windows, Unix, and Mac. There is currently an effort to create a free implementation of this. There are others, but I haven't used them.

Re:GUI bindings for Lisp

[NeonSquare]

There are several opportunities for Common Lisp. The commercial Lisps tend to come with decent GUI support. - Xanalys LispWorks comes with "CAPI" which is a portable (between OSes) Toolkit that uses the WinAPI on Windows and Motif on UNIX/Linux. - Franz Inc. AllegroCL comes with "Common Graphics" which is a Toolkit written for Windows - Digitools MCL comes with decent MacOS GUI support - Xanalys _and_ Franz _and_ Digitool offer implementations of "CLIM" (Common Lisp Interface Manager) a GUI Framework portable between OSes and Lispsystems Free GUI Toolkits (probably incomplete) - CLX is an implementation of the X Protocol in pure (!) Common Lisp (no binding to the C libs!). Therefore it runs on nearly every Lispsystem available. You need a X-Server to use Programs written with it, and the Toolkit is rather low-level. - CLM is a binding to Motif available for CMUCL and AFAIK some other systems. - Garnet is a rather extensive (but unfortunately not further developing) GUI Toolkit for several Systems - CLG and CL-GTK are Bindings to GTK for at least CMUCL - McCLIM is an effort to build a free implementation of CLIM (see above) which is developing rather quickly and looks very promising. Rationale: It is possible to use Toolkits like GTK or QT with Lisp, but there are several Problems with those: - Both GTK _and_ QT make sometimes stretch the image of what can be counted as easy portable C Interfaces (with QT offering until recently only a C++ interface) - GTK Does not look native on Windows, QT does but cannot be used commercially without paying license fees on Windows. - Simply writing bindings is not enough it will look like coding C in Lisp if there is no good layer above the low-level stuff. Therefore IMHO the right way for Common Lisp is to count on McCLIM getting _the_ OS and Lisp-System independent GUI Toolkit it deserves to be (with the possibility of having GTK, Motif, QT, WinAPI... as Backends)

Re:GUI bindings for Lisp

[NeonSquare]

Sorry for the bad formatting - but after dozens of tries to preview the article which only resulted in network timeouts I hit the submit button and to my astonishment seemed to work... I formatted the text appropriately in the text-field but do not know why it got so crippled (*grr*)

Re:GUI bindings for Lisp

[rpg25]

I'm a pretty fanatic CL programmer and I agree that the lack of good GUI bindings is a real handicap.

IMHO, CLIM manages to be the worst of all worlds. It's crude, yet somehow bloated, too. And on top of all that, it's insanely expensive.

A good, bulletproof, free interface to Tk would get my vote.... Honestly, I wouldn't want CLIM even if it were free.

I've used Garnet and think it's slick as anything, but it's orphanware with no one carrying it on. Further, it requires mastering an entirely new, and different (and cool, I admit) object system. A significantly added cost on top of the already difficult sell of CL. Oh yeah, and Garnet out of the box is really, really, ugly. I had to sit down with a UI specialist for a long time to make my own version with OK-looking colors, roundtangles for buttons, etc., etc. Then it was way slick.

Re:GUI bindings for Lisp

[Bobo the Space Chimp]

Probably posted as html, in which case &lt br&gt's are required. The good thing is they actually no longer require you to post with html selected for the html tags to work.

Solution: you can write a little infix translator!

[Kaz Kylheku]

If prefix notations for arithmetic really bother you, you can write a Lisp macro which translates infix to postfix, something like:

(infix x / sqrt ( x * x + y * y))

whose expansion might be

(/ x (sqrt (+ (* x x) (* y y))))

Really, if some way of programming bothers you, you can write a little compiler which translates from a notation that you find more suitable.

That's a fundamental concept in Lisp; that it's easy for programmers to write little compilers for new language features; compilers which are incorporated right into programs, and whose target language is Lisp.

()'s

[Anonymous Coward]

C does have a very good support for the programming style that lisp/scheme uses. But guess C made the syntax too easy to write that
people consider it bad code when someone actually does use it!

Consider the difference between:
int r; if (a) { r=b; } else { r=c; }
compared to
int r = a ? b : c;
A program should be _a single expression_ instead of a sequence of "commands".

Once you understand this, learning lisp and scheme becomes much simpler.

Anyway, as shown above, C/C++ has a very
convinient construct to do this -- obviously
when C was designed, the idea of program
as a single expression was around and considered useful enough to make a convinient
construct to the C language.

C/C++ #define macros and functions becomes easier to understand, if you consider the
whole program as a single expression!
Instead of a sequence like
a; b; c; d;

you can always write (the execution order is the same):
d(c(b(a)))

or in more convinient notation
(d (c (b (a))))

Or if you want to restore it to the good
old sequence

def fa=(a)
def fb=(b fa)
def fc=(c fb)
def fd=(d fc).
The same sequence except you can macro-expand
the whole thing always to
(d (c (b (a))))

Re:()'s

[jejones]

Um, the strict stack nature of C keeps it from allowing a functional programming style in the same manner as Lisp. Just to prove it to yourself, you might try writing a function that takes one argument and returns a function of one argument that returns the product of its argument and the argument passed to the first function.

Real reason for all the ()s

[Uri]

Pitman mentions that all the ()s in Lisp make it easier to edit and help avoid problems with operator precedence. This true, but beside the point - the real reason behind the "program is data" paradigm is the amazing thing called Lisp macros.

Most production-level Lisp programs may well never encounter a single list during their execution. Hashtables, structures and arrays are all primitive types in Common Lisp, and CLOS lets you build multiply-inheriting object classes to your heart's desire. But these programs will all still be lists. This means that you can use LISP's list-processing tools to write and rewrite them.

Which is where macros come in. Unlike other languages, Lisp macros are not just a simple preprocessor. They put the entire language at your disposal in constructing the expressions you want. Hence you can add new control constructs to the language - with 5 lines of code you can add a for, as in (for (x 1 10) (print x)). You can introduce new tools for updating generalized variables - (setf (aref a n) x) and (setf (property object) v) are equivalent to a[n]=x and object.property=v, but what about a user-defined (setf (min l) n) that changes all values in l smaller than n to n, thereby enforcing the identity? You can even embed entire languages on top of Lisp, and write your programs in that. And because this is all handled at compile time, not only will you not incur the cost associated with using high-level interfaces, you could also use this opportunity to perform extra computation while compiling, based on values potentially already known.

The most obvious analogy is to XML. It too obeys the "program is data" paradigm and has delimiters everywhere (though its are more verbose). This means you can rewrite your XML content using the XSLT stylesheets, which themselves are XML documents and hence can be rewritten too. The main difference here is that XSLT is nowhere near as well equipped to deal with language rewriting as Lisp is (ever tried even a simple recurse across more than one axis?).

Lisp is like boot camp

[CresentCityRon]

I first encountered Lisp (MacLisp I think) in the early 80s in a course I took at the University of Illinois. We had to use the Lisp 1.5 Manual by McCarthy. A thin text that was terse as hell and made a tough task (learning lisp) even harder. I even read a review by E. Dijkstra of the book and he was critical of it (but he hates everything.)

Anyway I've come to the conclusion that Lisp is very tough and a lot of hard work. Just like boot camp in the marines! But just like a boot camp experience don't you notice that everyone who makes it through the torture claims it was the best experience in their lives? They have to justify the pain. I think there is a psychology term for that.

Anyone can learn Lisp but it might take more effort than one's previous efforts in learning computer science. Dont give up!

I'd like to add that the interview was quite thoughtful. A lot of time went into it. It was a very good read.

Re:Lisp is like boot camp

[cstacy]

Lisp continually evolved since its genesis in the 1950s, and major improvements and developments in many areas (such as IO, macro facilities, object-orientation) were made in the late 1970s and early 1980s. Things have come a long way since Lisp 1.5. By the 1980s, only about half a dozen schools in the country were even vaugely abreast of the developments in Lisp, and not very many books (or even manuals) were available until around then. So it's not surprising that your exposure to Lisp was about an obscure historical language. Even today, I suspect that many or most teachers are still uninformed about what's in Common Lisp. Most of the requests for help with homework that I see on the Internet are oriented towards list processing. While Lisp is obviously good for that sort of thing, it suggests that students are not taught about how to use Lisp for what it's true value is: writing large, complex, evolvable systems.

Re:Solution: you can write a little infix translat

[dan_b]

In fact you don't even need to write one, because it already exists. INFIX (catchy name, huh) is available from

http://www-2.cs.cmu.edu/afs/cs/project/ai-reposi to ry/ai/lang/lisp/code/syntax/infix/0.html

or if you have Debian, you can get it as part of cCLan (see http://cclan.sf.net/ for details)

Continued...

[Kaz Kylheku]

Writing a language preprocessor for C is a large granularity decision. It's going to impact how you build the program; it will have to correctly lexically analyze C source, generate syntactically correct C and so on. Writing a Lisp macro is a small, casual decision that is part of the normal flow of Lisp development; the macro is just part of your program.

Suppose you have 10 C programmers working on a project, and each of them wants to invent a few language features. So you end up with 10 translators, which require each source file to be passed through a 10 stage filter. Can you imagine that? What if there are subtle dependencies on the order of the filters, or if the output of one breaks the other? Or does not transparently pass through the language features understood by the next one? The scenario is almost unimaginable; quite likely, the very idea will be rejected as braindamaged early in the project.

In Lisp, the 10 programmers can easily have their own macro libraries contained in their modules of the program. They can use each other's macros easily, even nest them in the same code. There is nothing special to do, no code preprocessing to set up; it's not any different from using a library of functions.

The Largest Disservice to LISP

[Loundry]

...is most frequently done whenever a LISP advocate opens his/her mouth. LISP advocates have been, in my limited and biased experience, some of the most arrogant and condescending bastards in the world. They think that LISP is God's gift to everything and that anyone who doesn't know it is an ignorant dolt. I know that is a harsh criticism of LISP advocates, but I think it's a well-placed criticism. I have heard more than one LISP advocate state such subjective comments as, "LISP is the most powerful and elegant programming language in the world" and expect such comments to be taken as objective truth. I have never heard a Java, C++, C, Perl, or Python advocate make the same claim about their own language of choice. I have heard such claims from Philip Greenspun (LISP and Emacs advocate), who also wrote (paraphrased) about Perl: "Perl has 1/10,000th the power of Common LISP, and 1/1,000th the power of FORTRAN."

This article by Pitman, however, is more level-headed, and I appreciate that. It's nice to hear a LISP advocate describe and defend rather than criticize and condemn. The main reason I have stayed away from LISP (and Emacs and OpenBSD, for that matter) is because I don't want to be associated with the people who support it. Someone may say I'm a moron for boycotting those things for such a "lame" reason, but, then again, is it really such a lame reason? What, exactly, am I missing out on by not participating in LISP, Emacs, and OpenBSD? I can tell you that I'm missing out on cavorting with condescending, arrogant pricks, for one thing. My computing needs are served quite adequately without those technologies.

I think it would be good for the LISP (and Emacs and OpenBSD) community to realize that they will win many more converts to their cause if they drop the arrogance.

Re:The Largest Disservice to LISP

[NetSettler]

The second half of the interview has some places where it specifically takes the position that you should learn lots of languages, Lisp just among them. I think Lisp will compare favorably if you give it the same shake you give other languages. And these days, environments are heterogeneous so you often can't get by on just one. Tune in tomorrow or whenever for those questions.

Sorry about the arrogance you have perceived in some. We're a diverse community. We're neither all arrogant, nor I suppose all not. You just have to pick and choose, like most other things in life, even Slashdot. I hope you'll use this incident as a reason to give the language a second look. Thanks for the useful feedback in any case.

Re:The Largest Disservice to LISP

[dan_b]

It seems to be generally the case that any worthwhile OS/language/philosophy/religion/football team will atract these kinds of camp-followers. Think of the Amiga, or Linux, or KDE, or OS/2, or Slashdot, &c. They're not the people actually working on it, just the loud-mouthed minority who flame about it.

I wish it wasn't so.

Fwiw, my experience is that most of the people who say "LISP is the most powerful and elegant programming language in the world" go on to say "it's dead now, and you're inferior because you missed out on it, but you should definitely suffer through some horrendously abstract college course about it anyway because It Will Change The Way You Think(tm)"

Yes, I use Lisp. No, I've no bloody sympathy for this point of view. If it doesn't do anything useful for you, you don't have to use it. For me, it does (my web server and my window manager, for two things), so I do.

Incidentally, do you have a citation for that philg quote? I'm curious, he's usually a lot more level-headed than that

Re:The Largest Disservice to LISP

[Loundry]

Incidentally, do you have a citation for that philg quote? I'm curious, he's usually a lot more level-headed than that

No, I do not.

A while back I got into an argument with Philip on Slashdot about LISP. This was after I read his comments about Perl on photo.net. When I went back to photo.net to get a direct quote of his "Perl is 1/10,000th the power of FORTRAN", I could no longer find it. I don't know if he removed it due to the nature of our conversation on slashdot (I was, after all, making the claim that LISP advocates are, generally, arrogant pricks). I wouldn't have put such behavior beneath him, considering the condescending way he treated me in our discussion.

Here are a few of Philip's quotes about LISP, Emacs, and Perl, from his photo.net glossary:

• "Lisp is the most powerful and also easiest to use programming language ever developed."
  
• "The best introduction to Lisp is also the best introduction to computer science"
  
• "[Emacs is the] [w]orld's most powerful text editor"
  
• "Lisp programmers forced to look at Perl code would usually say 'if there were any justice in this world, the guys who wrote this would go to jail.'"
  

LISP advocates would do a service to their language if they distanced themselves from this guy.

Re:The Largest Disservice to LISP

[jaoswald]

Almost everyone thinks and says their favorite language is best. But only the Lisp people are RIGHT. :-)

More seriously, most people whose favorite language is C++ have never used or even seen a Common Lisp implementation. At most, they might have been scarred by a few-week introduction to a limited Lisp dialect, which is "obviously" only useful for toy recursion problems.

Whenever I read Andrew Koenig, for instance, criticizing Lisp, it's obvious he has never seriously used an industrial-strength Lisp implementation to write a large program.

I think the only people I've heard who really understand Lisp, yet favor other languagues are the extreme functional camp, using languages like OCaml.

Re:The Largest Disservice to LISP

[BitwizeGHC]

This article by Pitman, however, is more level-headed, and I appreciate that. It's nice to hear a LISP advocate describe and defend rather than criticize and condemn. The main reason I have stayed away from LISP (and Emacs and OpenBSD, for that matter) is because I don't want to be associated with the people who support it. Someone may say I'm a moron for boycotting those things for such a "lame" reason, but, then again, is it really such a lame reason? What, exactly, am I missing out on by not participating in LISP, Emacs, and OpenBSD? I can tell you that I'm missing out on cavorting with condescending, arrogant pricks, for one thing. My computing needs are served quite adequately without those technologies.

You're missing out on much more than that: LISP is the most powerful, elegant programming language in the world. :) (OK, OK, so Smalltalk approaches it in power and elegance.) The advantages to using LISP far outweigh the disadvantages of associating with arrogant pricks because you really don't have to deal with the arrogant pricks if you don't want to. My communication with the LISP/Scheme "community" is limited mainly to Slashdot and the GNU project's guile-users mailing list and most of the Lispers and Schemers I've met are genuinely good, level-headed people. (Though many have a taste aversion to Perl...)

LISP offers some advantages like complete self-introspection, closures, and the ability to scratch together deeply-nested data structures on the fly, that the Algol camp is still struggling with. And LISP has had these things for years. These things are not necessary for every task (I certainly wouldn't write an operating system kernel in LISP (though it is possible) or a really high-speed graphics routine), but they sure come in handy for many tasks on a high level of abstraction, and so LISP is a good thing to have in your toolkit.

Oh, and by the way, Emacs is probably the world's most powerful text editor. Which is a bit like saying the Space Shuttle is the world's most powerful airplane. It has its downside in that it's quite heavyweight if your intent is merely to edit text but it is infinitely customizable to nearly any task within that domain and can really make life easier on a programmer. And code bloat being what it is, the Microsoft Word of today is easily many times the size of Emacs. The Emacs model of customization and code reuse also beats COM hands-down.

Don't get me wrong. I know of what you speak. I've had to deal with arrogant Mac weenies for, like, a decade now and there are quite a great deal more of those than there are rabid LISP fanatics. Doesn't mean I want to dissociate myself from the Macintosh: Quite the opposite. My sister has started drooling when a Windows Xp commercial comes on and I want to show her there's a better way. :) Short version: Don't miss out on something cool because of a few lunatics.

Re:The Largest Disservice to LISP

[Tiny Elvis]

I remember seeing these kind of statements about LISP as well. I'm not sure why you get so upset and angry about it, to the extent that LISPers are labeled pricks and bastards. It merely led me to investigate why so many [apparently] smart people had so many praises for LISP. What I found was that IMHO common-lisp *is* that good; I would rather write in CL now than any other language. FWIW my background is 10+ years of Unix, C, Perl, SQL, /bin/sh etc.

Re:The Largest Disservice to LISP

[Matthew Austern]

More seriously, most people whose favorite language is C++ have never used or even seen a Common Lisp implementation. At most, they might have been scarred by a few-week introduction to a limited Lisp dialect, which is "obviously" only useful for toy recursion problems.

I've used Common Lisp, Franz, Interlisp, Maclisp, Scheme, Emacs lisp, Zetalisp, UCI lisp, and probably a few other lisp dialects I've forgotten about. I took 6.001 at MIT, which used Scheme. My first programming job was to work on an automated medical diagnosis system. (Originally written in Interlisp, later ported to Franz. I wrote the database editor.)

I mostly use C++ nowadays; it offers abstraction features that I haven't found in any lisp dialect I've ever used.

But then, on the other hand... I think MIT is right to use Scheme in its introductory CS class, and I do think that serious programmers ought to become familiar with lisp. It's always bad to be parochial, and lisp is likely to expose you to ideas you won't see otherwise.

Re:The Largest Disservice to LISP

[jaoswald]

Can you be more specific about the "abstraction features" in C++ that you are talking about?

Re:The Largest Disservice to LISP

[Loundry]

Almost everyone thinks and says their favorite language is best. But only the Lisp people are RIGHT. :-)

Your emoticon seems to imply that you're joking, and yet I have the impression that you actually believe what you're writing.

I think the only people I've heard who really understand Lisp

This is what I infer: If you really understand LISP, then you would like it and think it's God's gift to everything. Therefore, if you don't like LISP, then you don't really understand it. Is this valid?

Re:The Largest Disservice to LISP

[Loundry]

Don't miss out on something cool because of a few lunatics.

The problem with your statement is that the "few lunatics" are the most arrogant and condescending bastards I've ever seen in all of my computing experience, and their words comprise 99% of what I know about LISP. Because of that, I have yet to see "something cool" in LISP. LISP advocates usually talk about how elegant LISP is and how crappy C and Perl are and how much smarter the LISP advocates were than the C advocates. I rarely, if ever, hear "what LISP can do for me."

Compare this to Perl. Perl is one of the most useful computer languages I've ever used. It is so flexible that I can use it for most anything. Often times, if I want to teach something network-related, I want to use Perl to do it, becuase of that flexibility. Does LISP offer me that? How would I know? All I hear from the LISP camp is how "elegant" it is and how stupid everyone else is for not using LISP.

So let's examine your attempt at LISP advocacy:

You're missing out on much more than that: LISP is the most powerful, elegant programming language in the world. :)

Wow! I've never heard that before!

LISP offers some advantages like complete self-introspection, closures, and the ability to scratch together deeply-nested data structures on the fly, that the Algol camp is still struggling with.

I don't know what "complete self-introspection" is, so I can't comment on that. But the latter two benefits you mention are present in other languages. And saying that LISP is better than Algol is no praise of LISP since I have no need of Algol anyway. You might as well have said, "LISP beats befunge and Intercal hands-down!"

Though many have a taste aversion to Perl...

Wow, I've never heard this, either! But maybe you can answer me a question: why do LISP advocates hate Perl?

Oh, and by the way, Emacs is probably the world's most powerful text editor.

You know, the previous 1,000 times I heard this I wasn't convinced. But now I am! Emacs Rulez!

And code bloat being what it is, the Microsoft Word of today is easily many times the size of Emacs. The Emacs model of customization and code reuse also beats COM hands-down.

So what? I don't use Word or Microsoft products.

I've had to deal with arrogant Mac weenies for, like, a decade now and there are quite a great deal more of those than there are rabid LISP fanatics.

I agree, the Mac weenies are, at times, condescending, and there are certainly more of them than there are LISP weenies. But they don't have that special MIT-bred arrogance that LISP advocates wear on their sleeves.

Short version: You're preaching the same line! You need to tell me what's cool about LISP and how I will benefit from it. I have yet to hear that from you.

Re:The Largest Disservice to LISP

[NetSettler]

Re: All I hear from the LISP camp is how "elegant" it is and how stupid everyone else is for not using LISP.

Well, this statement is false on its face, since my interview doesn't say that. And so that isn't all you're hearing. Unless you're only doing selective listening.

I have argued (and continue to argue in part 2 of the interview), that people need to know a lot of different languages. I have no deathwish for other languages. I just wish people would stop having a deathwish for the language I choose to use. I find Lisp powerful and useful. Some others have different callings. But the aim oughtn't be be beat each other into not using things. It should be to make people aware of the choices that are available to people who want them.

I don't need to convince the world that Lisp is right and other languages are wrong to feel comfortable that Lisp has succeeded. I just want to make the knowledge available that Lisp is usable.

One reason I refer to languages as political parties is to underscore that it's sometimes better that not everyone is in the same one. Most democrats would not be happy being republicans, nor vice versa. That doesn't make one group right and one wrong. It says that sometimes clustering with people of like mind is good. But people should not be chastized for changing party in either direction, nor should parties concern themselves with killing other parties. They should just collaborate as best they can given their differing viewpoints, and they should live and let live.

Re:The Largest Disservice to LISP

[Loundry]

Well, this statement is false on its face, since my interview doesn't say that. And so that isn't all you're hearing. Unless you're only doing selective listening.

I was actually using conversational tone in my written word, so you are correct, the statement is false on its face. A more accurately-written statement would be, "The vast majority of advocacy I hear about LISP is along the lines of, 'LISP is the most elegant language,' and, 'Everyone who doesn't use LISP is an idiot' and similar things."

I have argued (and continue to argue in part 2 of the interview), that people need to know a lot of different languages. I have no deathwish for other languages. I just wish people would stop having a deathwish for the language I choose to use. I find Lisp powerful and useful. Some others have different callings. But the aim oughtn't be be beat each other into not using things. It should be to make people aware of the choices that are available to people who want them.

I want to reiterate that your defense of LISP breaks the status quo of LISP advocacy. The LISP camp needs more like you.

I do not have a deathwish for LISP. My beef is with the arrogant pricks who use it as a cudgel to beat up anyone else in the computing field who doesn't like or use LISP.

Re:The Largest Disservice to LISP

[jaoswald]

Well, strictly speaking it isn't valid, in that there might be reasonable complaints about Lisp's limitations (and, of course, as all things made by humans, it does have some.) However, *most* people who reject Lisp bring up criticisms which don't hold water.

That is, they are typically criticisms based on an inexperienced or outdated perspective. E.g. "I can't read code with all the parentheses." People who have used Lisp for more than a week no longer notice the parentheses, and as they further grow into the language, they begin to appreciate the other language features that the uniform syntax allows.

Another common criticism of Lisp is that "everything has to be a list." This was true back in 1960, but is most emphatically untrue now.

The most commonly voiced criticisms of Lisp would obviously not come from anyone who wrote real code in Lisp on a serious implementation for a couple of weeks with proper assistance.

Paul Graham likens it to ice skating. Sure, everyone is wobbly the first few times they try to ice skate. They fall down, and they are slow. But if they give up and say "ice skates are useless" they are not making a valid criticism. When someone makes the effort to learn to skate, ice skates are pretty much the fastest way to get around on ice. When an experienced ice skater makes this claim, he isn't being elitist, he's being honest. If the novice retorts "all these people who use ice skates are so elitist. Their mode of locomotion is obviously not as good as they say it is. Why, I tried it [for three whole hours,] and I couldn't get anywhere." then he is just betraying his ignorance, and deserves to be criticized for it.

If you concede that ice skates are best on ice, but mention that skis are better on snow, no honest skater can deny that. Then, there can be useful discussion.

Re:The Largest Disservice to LISP

[BitwizeGHC]

I have argued (and continue to argue in part 2 of the interview), that people need to know a lot of different languages. I have no deathwish for other languages. I just wish people would stop having a deathwish for the language I choose to use. I find Lisp powerful and useful. Some others have different callings. But the aim oughtn't be be beat each other into not using things. It should be to make people aware of the choices that are available to people who want them.

This is an excellent point, one that I made but perhaps didn't clarify sufficiently, when I mentioned that LISP is a good tool to have in your toolkit. I know many languages including C, C++, Java, Smalltalk, Perl, and a couple forms of assembly and I use them all because they're all suited for different tasks. They are part of my "toolkit" which I use to solve a wide variety of problems. For me, LISP (and Scheme) happen to be suited well to the kinds of problems that involve manipulation of complex structured data objects. Once you get the hang of programming in LISP, you will find it much easier to code, debug, and maintain because you can build and test your application incrementally. Some of my work involves managing HTML and XML text and data. Writing code to parse the data and assemble it into Web pages is trivial in Scheme; for me, even Perl is somewhat more difficult to make work.

What does LISP offer the average programmer? A clean syntax. A clean, straightforward Way of Doing Things. Interactive, incremental editing, compiling and debugging. Unit testing becomes a snap: in some other languages I find I must run an entire program to determine if there's a bug in function foo. In LISP I can interactively call just foo over a set of data before integrating it with the rest of my code. In many cases, tail recursion (which makes iterating over a list or a problem space a bit like programming by math induction; very cool and very intuitive). Symbolic representation of data (useful because our brains represent data as symbols, too). Closures for those functions you need only once. Self-introspection, and a powerful macro facility that lets me add OO (if it doesn't come with the language already), coroutines, generic functions and function generators, and other things that are tricky to implement in other languages. This is real power, and while many programmers don't need it all at once, they will develop useful skills from having been exposed to it. My Scheme experience has improved all of the code I write, even in C++ and Perl which brings me to the taste aversion. :)

Many Scheme and LISP hackers have a taste aversion to Perl because of its complex and arbitrarily abstruse syntax. This is something that the LISP community has been seeking to avoid. I don't like Perl the language very much for many of the same reasons but I do admire Larry Wall (and more so Heidi ^_^) and I will use Perl when the situation demands it (which is frequent given the number of Perl installations vs. Guile or Common LISP on Web servers though I'm pushing for a change in this area). But at least I took the time to understand Perl (as my well-thumbed Camel Book will attest) instead of dismissing it right away.

I agree!

[Tom7]

I had a +5 question about this in the asking phase, and I was disappointed to not see it answered.

I too first learned lisp, but (after the initial shock) found SML to be much, much easier to use.
In my mind, we win on:

- static typing: makes debugging so much easier,
module interfaces more expressive, and programs faster. Note that ML and OCaml both have
type inference, so this business about writing
down types all the time doesn't apply!
- datatypes and pattern matching: A very natural
way to represent recursive data structures.
Often saves you lots of typing over objects
and subtyping, while being more "safe" in
the sense of avoiding casts.
- Syntax. This is subjective, I guess, but
I don't need practically any punctuation
to program in SML, which makes it easier to
read (for me) than lisp or C.

From his response, it seems we're missing:

- "dynamic stuff". It's not clear to me that
this is actually useful for working on
large problems, but I suppose this is
not reconcilable with ML's static type
and scope rules.
- self-interpretation. This sounds fun, and
I had hoped to hear about how this is useful.
Any suggestions, anyone? It would seem that
this could be added to ML, though at a
cost of efficiency.

Re:I agree!

[NetSettler]

All of the +5 questions are answered. This interview is in two parts. The next part will appear in a day or two, and the question about ML will get answered.

Re:I agree!

[frank_adrian314159]

Here are my responses. Kent's would be different...
static typing
Yes it spots some errors, but at a great cost - greater difficulty in code modification. Most Lisp programmers don't hit that many type errors and when they do, they have the option of fixing the error or extending the interface to accept the new type.
It's not like strongly typed FP systems have complete type systems anyway. How do I specify a type "must be prime" for use in constructing hash tables, for instance? In Lisp, you just declare a variable as being of type (satisfies primep) and let the function primep do the checking. You can't do that in a statically typed language.
In summary, most Lispers see static typing as a very rigid answer to a non-problem.

datatypes and pattern matching
Datatypes I covered above. I'll only add that both structures and objects are available. As for pattern matching on said items, Lisp has that in CLOS. You can specialize a method on type or value. Here's an example:

(defmethod factorial ((i (eql 0))) 1)
(defmethod factorial ((i integer)) (* i (factorial (1- i))))

Syntax
Definitely subjective. But having written code that builds code in languages with more complex syntax, I know which one I'd pick...

dynamic stuff

I can't say if it is valuable for "big things" either, but it is very valuable for "important things" - things that can't go down.

self-interpretation
You can't even define a static type (as defined by most strong typing systems today) for this. I'd find it very hard for it to be put consistently into a statically-typed language.

Re:I agree!

[marcoxa]

I have looked at {OCa|S}ML language in the past
but have stuck with CL.

Type inference is surely nice and the only thing
you can say about CL as a language is that it does
not mandate it.

I use CMUCL most of the time, so I do not find this such a loss (CMUCL *does* quite a bit of type inference).

Pattern matching is implementatble in CL directly
and it has been in the past. Multiple dispatch
does help you in this respect also. E.g.

(defmethod factorial ((x (eql 0))) 1)
(defmethod factorial ((x integer))
(* x (factorial (1- x))))

is a perfectly good way to write the factorial
function in CL. Add a little macrology and you
can reduce the verbiage as well. (Something
you cannot do simply in ML languages - although
I have not seen OCaMLM4 at work yet).

I find the {OCa|S}ML syntax irritating. Especially in SMLNJ, I spent an inordinate amount
of time putting in parenthesis just to placate
the type inference engine.

I strongly believe that datatypes in ML languages
are overrated. Whenever I design a data structure
I know pretty well how it is going to look like
as far as the basic types are concerned. Datatypes
in ML languages are only as good as the type inference engine working underneath. Given that
you can have a similar thing in CL (admittedly
without the mathematical soundeness of ML languages), I do not find this to be a point
that would discriminate my choice of language.
The same applies to functors and modules.
They are nice, but they are not so much nice to offset
all the other things you miss when moving
away from CL.

Cheers

Re:I agree!

[Tom7]

> Yes it spots some errors, but at a great cost -
> greater difficulty in code modification. Most Lisp
> programmers don't hit that many type errors and
> when they do, they have the option of fixing the
> error or extending the interface to accept the new
> type.

Well, it is harder to have type errors in a language that has so few types!
The idea is that more types in a language allow you to express more things (say, invariants of your code, or interfaces to your modules) more precisely. I guess most lispers have a different idea of what 'static typing' means than MLers. ML types are a lot different from CL types.

> How do I specify a type "must be prime" for use
> constructing hash tables, for instance? In Lisp,
> you just declare a variable as being of type
> (satisfies primep) and let the function primep do
> the checking. You can't do that in a statically
> typed language.

Well, at least for this example that's easy. Your signature might be:

type prime
type hashtable

val hashtable : prime -> hashtable

val makeprime : int -> prime option
...

Most of the time you want to avoid runtime checks (like you'd incur in lisp), so we are working on something called 'refinement types' which will help that.

> Datatypes I covered above. I'll only add that both
> structures and objects are available. As for pattern
> matching on said items, Lisp has that in CLOS.

Above? I don't think you know what I mean by datatypes then. 'datatype' is a keyword in SML which introduces a named sum / recursive type and constructors/destructors for it. Think of it like a BNF description. Perhaps:

datatype exp =
App of exp * exp
| Lambda of var * exp
| Var of var

(or parametric types)

datatype ('a, 'b) tree =
Leaf of 'b
| Node of ('a, 'b) tree * 'a * ('a, 'b tree)

> (defmethod factorial ((i (eql 0))) 1)
> (defmethod factorial ((i integer)) (* i (factorial (1- i))))

That is the equivalent of a C "case", not pattern matching the way I mean.

Here's a function which counts the number of nodes with exactly two children:

fun twoc (Leaf _) = 0
| twoc (Node (Leaf _, _, Leaf _)) = 1
| twoc (Node (l, _, r)) = twoc l + twoc r

I sorta think that is pretty nice. Admittedly, not all structures can be described so beautifully, but it is an awfully useful feature and I haven't seen it outside the static functional languages family.

> I can't say if it is valuable for "big things" either,
> but it is very valuable for "important
> things" - things that can't go down.

I suppose it is kind of nice to edit a running system (I've never been in that situation, but I could imagine it). Personally, I'd prefer a stronger certificate of correctness *before* I run my program rather than the ability to fix my mistakes conveniently afterwards.

> You can't even define a static type (as defined by most
> strong typing systems today) for this. I'd find it very
> hard for it to be put consistently into a
> statically-typed language.

Well, this isn't really true. But the simple answer is that we know how to do it right (modal types are one way), there just isn't enough demand to add it (with its complications for implementors) into anything but experimental languages. You can go a long way with closures!

There might be, if people made a case for it. What do people use this for, anyway?

Why Lisp? .... CLOS

[Uri]

Say no more:

• Multiple inheritance scheme
• Polymorphic methods - multiple arguments from different classes
• Method combination - control order of method execution
• Class conflict resolution - use precedence lists or even combinations
• Generic function calls and message passing
• Run-time class redefinition and instance updating
• The Meta-Object Protocol

Correction

[Anonymous Coward]

The given definition of hello world:

(defun hello-world ()
(write-line "Hello, World!"))

is valid in e-lisp. But in common lisp, one would say:

(define hello-world ()
"Hello, World!")

Note that we merely return the collection of atoms, and don't need to evaluate anything.

Re:Correction

[hding]

Actually, it'd be a lot more likely to give you an error, since define isn't a standard function in Common Lisp.

Re:Correction

[Gabe Garza]

This actually isn't quite true.

(define hello-world ()
"Hello, World!"))

seems to work, because when you call the function in the Lisp read-eval-print loop (that's the name for the prompt you get when you typically start a Lisp system) it evaluates it, and prints "Hello, World!" because that is the string that the function returned.

Typically, the read-eval-print loop is only used for programming development. A "Hello, World" program should write the string "Hello, World" to a stream, analoguous to doing a puts("Hello, World") in C. Thus, the example using WRITE-LINE is more correct.

The read-eval-print loop is one of the greatest features of Common Lisp development. It allows you to evaluate arbitrary bits and pieces of Lisp code and incrementally add and compile functions, methods, classes, etc. to your program. This means you can be building a (compiled) program without having to go through the write-compile-run-coredump-debug-repeat cycle.

It also makes debugging far easier, because you don't have to write nearly as much testing framework as you would in a more ``traditional'' compiled language. Often, testing a function is a matter of telling having the Lisp system you're using to compile it, and then calling the function on made-up arguments in the read-eval-print loop! This is so much nicer then having to write seperate programs to test your programs.

Java fast?

[Anonymous Coward]

Am I missing something here? or did you imply that java was fast?

java fast

pre-runtime error detection

[Tom7]

"...The Lisp way is 'anti-bugging,' finding errors as they occur. Having an editor that enforces indentation helps enormously in finding all sorts of typos (missing quotes, etc.) before you run your code."

hehe.
I think this sentiment is great. Essentially you are saying that lisp's syntax (along with the help of an editor) is conducive to syntax-error-free programming, since it has checks (in a way) that occur while you program, not while you run.

The reason why I chuckle is that I often use this same argument to explain why I find ML's static type system so useful. Rather than catch syntax errors, it catches semantic errors in your program before it is run. I find this to be an incredible boon; I very infrequently have to debug a program that's type correct. Yet the "dynamic" camp doesn't buy into this -- they say that their dynamic typing lets through *more* programs, and therefore is somehow more powerful.

What's the deal here, do you believe the first and not the second, or am I merely making an unfair stereotype?

Re:pre-runtime error detection

[Anonymous Coward]

The "dynamic camp" doesn't buy into static-typing because you sacrifice too much flexibility in the process. I don't see any resolution to this in the near future, and I don't see a reason to force a compromise either.

Re:pre-runtime error detection

[omigod!kenny]

You are right, both are helpful in that they identify gaffes ASAP. But we happy dynamic campers don't like the inflexibility cost of static typing. And because we be in the dynamic camp, when we land in the debugger because of a type goof we can fix the offending code, recompile, return to the debugger and resume execution from some stack frame above or at the bug. hellasweet :) kenny clinisys

The psychological term...

[Macrobat]

...is "cognitive dissonance."

The idea is, after doing something tortuous and gruelling, people think, "WHY in the hell did I just do that?" There are at least two answers:

I really hated it, but people made me do it, but they didn't really make me do it, they just showed me that things were going to be more difficult for me if I didn't do it, so I went along with it, but I was really working so it wasn't just "going along with it", I was actively participating in it even though I hated it because....AARGH!

I must have really liked it.

People don't like living with contradictions, and the brain likes to simplify and condense, so the shorter answer becomes the truth, even it if wasn't to begin with. In other words, it reduces the cognitive dissonance.

Re:The psychological term...

[CresentCityRon]

No that is not the term. Thanks though.

system interface

[Anonymous Coward]

i like Lisp, but at my startup we're still using C, and not for speed, or (lack of) ease of use/debugging. It's because C gives you a handle on the machine. The (lack of) system interfaces in Lisp is a big problem.

For instance (and this is why we didn't use Perl, cuz at the time (now?) it's threads were buggy) we need to be able to use threads.

Maybe this is because Unix is written in C, not Lisp, but i think the Lisp community needs a little less "people don't use Lisp because they are stupid/lazy/afraid of change/old/don't get it" and more "why aren't people _really_ using Lisp?"

Re:system interface

[hding]

So why didn't you just use a Lisp with threads. E.g. almost any (or perhaps even every) major Common Lisp.?

Re:system interface

[Anonymous Coward]

it's not that lisp has _no_ thread interface, it's that it has a _bad_ one.

ditto for sockets, etc.

Re:system interface

[cstacy]

I am curious what system interface was missing or unsuitable for you in Lisp.

You mentioned threads, but all the commercial Lisp implementations include threads. (In some implementations, they are implemented using the underlying native OS threads, while in others, the threads are entirely internal to Lisp.) In Lisp, the facility is usually called "processes" or "multiprocessing", which is a slight terminology glitch. Lisp has had threads since about 1979, and the interface is very easy to use. What Lisp implementation were you using, and what problems did you have?

Lisp also has a very flexible system for dealing with filenames portably across operating systems, and it has the stream-oriented IO facilities. Most implementations also include interfaces to the network, either at the sockets or higher level.

And, of course, you can always just program using the operating system's facilities (by using the "foreign function call" facilities).

I think Lisp vendors are pretty interested to know what OS interfaces you think are missing. What exactly was the problem that you had?

Re:system interface

[hding]

Well, then please explain to us very specifically why you think the thread and/or socket interface from a major Common Lisp implementation such as Allegro is bad.

Still waiting on a real reason why to use lisp

[Anonymous Coward]

Problem 1: Selling your manager on using lisp or other non-mainstream language/tool. Easy to do if the project is trivial, but deadly if you are doing a large large system.

Problem 2: Writing each and every trivial/medium sized application in whatever language is hot at the time leads one to have a system which uses many different languages and does not promote maintainability.
This leads to another question: Has anyone analyized what languages/tools are needed to build linux, linux tools, and run normal linux daeomons/applications?

Possibly, it will show that a very small part of linux/unix uses very very outdated tools/applications (e.g., sed) which then could be dropped from unix/linux.

A simpler fully featured linux distribution would make it much much easier to focus on implement modern features into linux/unix, linux/unix tools and applications.
The same analysis should be done for system calls.

forth and lisp

[Anonymous Coward]

This guy and the forth zealot should get together and write an os, user interface, office suite, tcp compatable stack, device drivers....

in forth and lisp

Re:forth and lisp

[cstacy]

This of course has already been done in Lisp, about 20 years ago.

Scheme on JVM (Kawa)

[Per Bothner]

PseudonymousCoward in question 9 says: The rate at which Kawa has been developed, to implement a near-Scheme on the JVM has been frustrating to me.

I think you're asking a lot. Kawa has over 80k lines of code (as measured by wc), almost all of it written by one person (me) not working on it full-time, and much of it re-written as I improve things. That is a lot of code. Kawa includes a full compiler and a big runtime with lots of features. I get lots of compliments.

I attribute this at least in part to the absence in the JVM of a construct equivalent to Scheme's continuations.

In principle it is not that difficult to implement continuations on the JVM. Once you have full tail-call support (which Kawa does), you can implement continuations by a source-level transformation. What has mainly held me back is the desire to do it right, by which I mainly mean efficiently, building on top of the right calling conventions, and with interoperability with "direct" code. The other thing is I have never seen continuations as all that important. It's a check-off item if you want to claim to implement Scheme, but I suspect very few people actually would be able to use them. Still for those that do, I will get around to it as soon as I can.

Re:Scheme on JVM (Kawa)

[Anonymous Coward]

Kawa is great, I have to say. Kudos!

Re:Scheme on JVM (Kawa)

[Christopher Cashell]

Personally, I've been much impressed with Kawa, both in it's current capabilities, and it's pace of improvement (especially considering that you are doing nearly all the work on your own).

Thanks for the great software. ;-)

dynamic scoping, not!

[Kaz Kylheku]

Common Lisp is lexically scoped. Dynamic scope is available in the form of the ``special'' declaration. If you want dynamic scoping, you must explicitly request it like this:

(let (*dynamically-scoped-var*)
(declare (special *dynamically-scoped-var*))
...))

So now with this declaration you have effectively created a local ``override'' for a global variable. If some form you evaluate from within this context refers to the identifier *dynamically-scoped-var* it will resolve to the one declared here, not the global one (unless there is a local declaration there which shadows that reference, of course).

Once upon a time, in dialects of Lisp preceding ANSI Common Lisp, this dynamic behavior was the norm. Dynamic scoping is tremendously useful, so it is retained in the form of special variables.

Some ``old timer'' Lisp users should take a second look at the current state of Lisp, because important details change.

ANSI CL and the Lisp machine killed Lisp

[mj6798]

Lisp is great: a simply syntax, powerful semantics, and an extensible environment. Unfortunately, ANSI CL and the Lisp machine killed it. Why?

Lisp machines were expensive workstations that cost tens of thousands of dollars to deliver performance that, even at the time, could easily be had for a few thousand dollars. Contrary to popular claims, the programming environment has some serious limitations, including lack of source level debugging (eventually it got added, but only after the system had already fallen from grace). Those systems simply were not competitive and gave Lisp a reputation of requiring gold plated hardware, carried over into hugely expensive development and runtime licenses. And the use of those machines also kept Lisp from ever integrating well into mainstream environments.

An even bigger problem with Lisp was ANSI CommonLisp. ANSI CommonLisp failed to standardize some really important functionality, like threads, reflection, and networking. What it did specify it specified poorly: the meaning of type declarations and conditions (exceptions) is still vague. The upshot is that CommonLisp programs are a pain to port and require careful hand-tuning for each implementation. A program that runs fast on one implementation runs like molasses on another.

The most frequently named "issues" with Lisp never were issues as far as I can tell. People who put up with Perl syntax should have no problem putting up with Lisp syntax. And performance and resource requirements of Lisp implementations are small compared to Java or even modern scripting languages.

So, where is Lisp going? CMU CommonLisp is trying valiantly to maintain CommonLisp functionality and enhance it, but it is hampered by being based on a poorly written Lisp standard. Python actually gives you most of the power and convenience of Lisp but integrates much more nicely with its environment; Python's big drawback is the lack of good native code compilation. Java includes many Lisp features (Java was designed by people with a lot of Lisp experience) and it specifies reflection, runtime code generation, and exception handling much better than CommonLisp (too bad about the syntax, though). Scheme is probably the best variety of Lisp these days, and there are some really good implementations out there (Bigloo and PLT Scheme being some of them; Bigloo and Cygnus's Scheme compilers even compile to the JVM if you like). And the ML series of languages (SML, OCAML) give you most of the convenience of Lisp with full type checking and no type declarations.

Lisp continues to live in many forms, despite the Lisp machine and despite ANSI CommonLisp.

Re:ANSI CL and the Lisp machine killed Lisp

[Gabe Garza]

I wonder if you could elaborate for me a little bit.

You criticize ANSI Common Lisp for not standardizing threads, not standardizing networking, and not defining declarations well. You also claim that it is partially responsible for the downfall of Lisp. Then you say that Scheme is the best variety of Lisp out there.

How can you reconcile your recommendation of Scheme with your condemnation of Common Lisp? The Scheme standard (R5RS) does not standardize type checking at all. Nor does it standardize multiprocessing, nor networking, nor the compiler interface, etc. There is greater variability between Scheme implementations then between Common Lisp implementations on these issues.

You also claim that porting efficient code between Common Lisp implementations is difficult. This is true. What's efficient in one implementation can be innefficient in another. However, most vendors supply their product for a wide variety of computers. Also, porting the code without worrying about efficiency, is usually trivial, even between different implementations on different platforms (assuming CLIM or some other standardized interface was used). This means that you instantly get working code, even though it may not be as fast as it was on the originally implementation.

Compare this with C, C++, etc. where porting between different machines, even with the same compiler vendor, is often quite tricky. As for vendor differences, care to port something from Visual C++? :)

I also would like to know what you consider vague about the condition system. I've always considered it one of the strong points of the language and easily graspable. I also disagree with your statement that the ANSII Common Lisp standard is poorly written. I consider it to be a superb example of technical writing. I use it day-to-day as a reference when writing ANSI Common Lisp programs.

Re:ANSI CL and the Lisp machine killed Lisp

[mj6798]

How can you reconcile your recommendation of Scheme with your condemnation of Common Lisp? The Scheme standard (R5RS) does not standardize type checking at all. Nor does it standardize multiprocessing, nor networking, nor the compiler interface, etc. There is greater variability between Scheme implementations then between Common Lisp implementations on these issues.

That's a valid question. My response is that I don't view Scheme and CommonLisp as covering the same ground. CommonLisp really tried to claim being an industrial-strength application development language, and I think it failed badly at that. Scheme, at least to me, is a variety of things that CommonLisp never really was: an extension language, a scripting language, a prototyping language, and a teaching language. At its chosen problem domains, Scheme is quite good.

Also, porting the code without worrying about efficiency, is usually trivial, even between different implementations on different platforms (assuming CLIM or some other standardized interface was used). This means that you instantly get working code, even though it may not be as fast as it was on the originally implementation.

I have to disagree with this. It is easy to port code that was intended to be portable, but once you put in all the hooks to make it efficient, it fails. Some CL implementations, for example, tolerate incorrect type declarations, while they lead to crashes or runtime errors on other systems. And what is "incorrect" may itself depend on the implementation.

Compare this with C, C++, etc. where porting between different machines, even with the same compiler vendor, is often quite tricky.

Yes, it is very easy to write C/C++ code that is completely unportable. Even worse, the source code contains no indication of the use of unportable constructs. This is a major problem with C/C++. However, unlike CommonLisp, it is also very easy to write C/C++ code that is both efficient and completely portable. I think that has contributed to making C/C++ so popular.

I also would like to know what you consider vague about the condition system. I've always considered it one of the strong points of the language and easily graspable.

The condition system itself is OK, but the standard leaves a lot of leeway to implementations of what exceptional conditions are actually detected and what their consequences are. And the CL standard still contains many undefined effects. The hope was that this would allow implementations to be more efficient, but that doesn't seem to have panned out.

I think Java is a lot better in this regard, specifying precisely what exceptions get thrown by what primitives, and the runtime cost is small. (Java got a little overly zealous with numerical exceptions, to the point where it unnecessarily affected efficiency, but that's being fixed.)

I also disagree with your statement that the ANSII Common Lisp standard is poorly written. I consider it to be a superb example of technical writing. I use it day-to-day as a reference when writing ANSI Common Lisp programs.

I wasn't referring to style (the prose is nice), but to content.

Altogether, I think CommonLisp has the right idea in terms of overall language functionality for an advanced language for rapid development and prototyping: Lisp syntax, macros, reflection, powerful object system, interactive development, dynamic modification of code, etc. But the ANSI CL standard just got too many practical issues wrong as far as I'm concerned. The right thing to have done would have been to start over and not accomodate the half-dozen or so vendors with their oddball interests. In fact, some such efforts were around in the early 1990s, but the existence of the ANSI CL standard never let them get off the ground, and I think ANSI CL gave Lisp such a bad name that eventually people just gave up on it. In fact, in many ways, systems like Java and Python are Lisp systems disguised carefully enough so as to not offend a Lisp-weary public.

Re:ANSI CL and the Lisp machine killed Lisp

[jaoswald]

I don't understand. You hold up Scheme as the best Lisp variant, but complain that ANSI CL didn't standardize enough functionality? Does Scheme even have a standard object system yet?

Also, you fail to prove the case that ANSI CL killed Lisp (even if I somehow grant that Lisp is dead). What is your realistic alternative? A Lisp that somehow got all the features and market acceptance of Java? Would this have come about in the absence of a standardization effort like ANSI CL? Without the resources of Sun?

Standardizing threads, etc., is quite difficult in a language that is meant to run on a wide range of platforms and OS's. Commercial CL implementations manage to include interfaces to all of this functionality anyway. What in this "poorly written standard" prevents different implementations from choosing a standard networking interface, if the market really demanded it?

Lisp machines sure didn't help Lisp in the long term, but all independent workstation vendors have essentially lost to Intel. Their problems weren't unique to Lisp, but rather to independent microprocessor development.

Re:ANSI CL and the Lisp machine killed Lisp

[jaoswald]

ANSI CL never claimed to be an industrial-strength programming language. (Implementations might be, or claim to be, industrial-strength, but portability and industrial-strength are orthogonal concepts.)

from the Hyperspec:

In April 1981, after a DARPA-sponsored meeting concerning the splintered Lisp community, Symbolics, the SPICE project, the NIL project, and the S-1 Lisp project joined together to define Common Lisp. Initially spearheaded by White and Gabriel, the driving force behind this grassroots effort was provided by Fahlman, Daniel Weinreb, David Moon, Steele, and Gabriel. Common Lisp was designed as a description of a family of languages. The primary influences on Common Lisp were Lisp Machine Lisp, MacLisp, NIL, S-1 Lisp, Spice Lisp, and Scheme. Common Lisp: The Language is a description of that design. Its semantics were intentionally underspecified in places where it was felt that a tight specification would overly constrain Common Lisp [r]esearch and use. .... In 1986 X3J13 was formed as a technical working group to produce a draft for an ANSI Common Lisp standard. Because of the acceptance of Common Lisp, the goals of this group differed from those of the original designers. These new goals included stricter standardization for portability, an object-oriented programming system, a condition system, iteration facilities, and a way to handle large character sets. To accommodate those goals, a new language specification, this document, was developed.

and in

1.1.1 Scope and Purpose

The specification set forth in this document is designed to promote the portability of Common Lisp programs among a variety of data processing systems. It is a language specification aimed at an audience of implementors and knowledgeable programmers. It is neither a tutorial nor an implementation guide.

Personally, I think it is a lot more important to have a portable object model than to have a portable networking interface. When porting from implementation to implementation, the networking performance of different platforms is certain to be different, and require re-tuning anyway.

As for the issues you mention on type-checking being non-portable, optimization and portability are nearly opposite directions. Different implementations (and different (optimize ...) settings) will make different trade-offs. If you're spending the time to seriously optimize a program, you probably have gone past the point of worrying about your choice of platform.

Re:ANSI CL and the Lisp machine killed Lisp

[NeonSquare]

That's a valid question. My response is that I don't view Scheme and CommonLisp as covering the same ground. CommonLisp really tried to claim being an industrial-strength application development language, and I think it failed badly at that. Scheme, at least to me, is a variety of things that CommonLisp never really was: an extension language, a scripting language, a prototyping language, and a teaching language. At its chosen problem domains, Scheme is quite good.

If you don't think they are covering the same ground then you simply compare apples and oranges.

Yes, it is very easy to write C/C++ code that is completely unportable. Even worse, the source code contains no indication of the use of unportable constructs. This is a major problem with C/C++. However, unlike CommonLisp, it is also very easy to write C/C++ code that is both efficient and completely portable. I think that has contributed to making C/C++ so popular.

It is easy to write portable C/C++ code? I completely disagree here - there are plenty of ugly problems even between compilers like GCC and Visual C++!

In my experience it is by far more easy to write portable software in Common Lisp than in C/C++. I personally maintain a fullscale Webserver completely written in Common Lisp which originated in Franz Inc.'s AllegroCL and which now runs on LispWorks, CMUCL and Corman Lisp under Windows, several UNIX OSs including Linux. My first port of this webserver was the work of a half day - and this contained non-trivial topics like Multithreading, Network-I/O and OS interfacing. Having had several years of experience in C/C++ I was impressed by the general portability of Common Lisp which essentially ruled out any need for Java for my work.

The condition system itself is OK, but the standard leaves a lot of leeway to implementations of what exceptional conditions are actually detected and what their consequences are. And the CL standard still contains many undefined effects. The hope was that this would allow implementations to be more efficient, but that doesn't seem to have panned out.

This is not really true. The problems here are not efficiency issues but more the wish to collect more real-life experience before making a decision that is difficult to remove later. Your argument implies that there can be no consensus between vendors after the ANSI Standard - this is completely wrong.

Another problem with your rationale is that you merge "Community Standards" like those of Python and Java and "Institutional Standards" like ANSI Common Lisp. Neither Python nor Java have anything comparable to the ANSI CL Standard - but Common Lisp can have (and already has) not only it's ANSI Standard but also "Community Standards. So ANSI Common Lisp has in this comparison a much better base.

Altogether, I think CommonLisp has the right idea in terms of overall language functionality for an advanced language for rapid development and prototyping: Lisp syntax, macros, reflection, powerful object system, interactive development, dynamic modification of code, etc. But the ANSI CL standard just got too many practical issues wrong as far as I'm concerned. The right thing to have done would have been to start over and not accomodate the half-dozen or so vendors with their oddball interests. In fact, some such efforts were around in the early 1990s, but the existence of the ANSI CL standard never let them get off the ground, and I think ANSI CL gave Lisp such a bad name that eventually people just gave up on it. In fact, in many ways, systems like Java and Python are Lisp systems disguised carefully enough so as to not offend a Lisp-weary public.

I cannot really follow your rationale - it is all very fuzzy and subjective.

Nobody forces you to like or use Common Lisp but don't spread such FUD to the people. Most of what you have written on "better" or on what in your sole opinion the ANSI CL Standard got wrong is absolutely subjective without any concrete argumentation.

Re:ANSI CL and the Lisp machine killed Lisp

[mj6798]

ANSI CL never claimed to be an industrial-strength programming language. (Implementations might be, or claim to be, industrial-strength, but portability and industrial-strength are orthogonal concepts.)

I wasn't talking about what CL "claimed" to be but what it was actually being used for: large, real-world artificial intelligence systems. And it clearly wasn't all that good at the other areas: too messy for teaching and not well-enough integrated with UNIX for scripting.

Personally, I think it is a lot more important to have a portable object model than to have a portable networking interface.

That's kind of like saying that having a brain is a lot more important than a heart. Any modern programming system that wants to succeed needs to have both, as well as a lot of other things. ANSI CL failed to standardize those and many other important pieces of functionality.

As for the issues you mention on type-checking being non-portable, optimization and portability are nearly opposite directions. Different implementations (and different (optimize ...) settings) will make different trade-offs. If you're spending the time to seriously optimize a program, you probably have gone past the point of worrying about your choice of platform.

Well, you may not think it mattered, but the simple fact is that lots of CommonLisp users have voted with their feet. I'm just telling you why I and most other people I know stopped using CL for anything big and important. I expect a good language standard to allow me to write programs that are both portable and predictably efficient, and a language standard that fails to do that is of no interest to me.

Re:ANSI CL and the Lisp machine killed Lisp

[mj6798]

I cannot really follow your rationale - it is all very fuzzy and subjective. Nobody forces you to like or use Common Lisp but don't spread such FUD to the people. Most of what you have written on "better" or on what in your sole opinion the ANSI CL Standard got wrong is absolutely subjective without any concrete argumentation.

Don't be silly. If this were "my sole opinion", lots of people would still be using CommonLisp and I'd be the lonely holdout not using it. Reality is that most experienced CommonLisp users have switched to Java or other languages by now, and they didn't do so out of ignorance.

Re:ANSI CL and the Lisp machine killed Lisp

[NetSettler]

Re: Reality is that most experienced CommonLisp users have switched to Java or other languages by now, and they didn't do so out of ignorance.

In fact, indirectly, I think they did.

I know a lot of these experts you're talking about personally. Are they ignorant of CL and its strengths? No. But are they independently wealthy? Also no. So what happens? They have to get a job where people are offering. Would they have preferred Lisp jobs? In most cases I can think of, sure, absolutely. Did they dislike Lisp? Nope. But most people can't make their own job. People have families and kids, and they take conservative steps when they might prefer not to--because they have to.

But don't conclude from that that they have abandoned Lisp, that they don't trust it, etc. They haven't a choice. The ones with the choice are the employers. And in at least some cases, the prejudice against using Lisp is out of ignorance. So, indirectly, those skilled Lisp programmers are shifting jobs to non-Lisp jobs out of ignorance. Just not their own.

The fact is that many well-meaning people make arguments just like you're making, that you can't make money with Lisp. And that becomes a self-fulfilling prophecy because it convinces others not to offer Lisp jobs. But arguments of this kind are not good arguments because they are not based on causality, they are just based on observation. People mostly don't go to the moon, but that doesn't make it a bad idea. People often aren't even nice to each other, but that doesn't make it a bad idea.

Me, I don't have a family that depends on my paycheck, so I can take more risks than some you cite. My company is based on Lisp. I think it's a strategic edge that will save me from hiring armies of people to do what I need to do. And that works in my favor because I can't afford to hire armies of people right now. Still, I believe, now more than at any time in the last dozen or so years, Lisp is finally powerful enough that what stands between me and making money in the world is not the language or tools I'm using (which seem entirely adequate) but business ideas and business management (which I think I can do and I've set out to demonstrate). If my company fails, it will be because I did something wrong either in picking my market or managing my company, but not because some perfectly capable programming language let me down.

Lisp is just a tool. And it's a poor craftsman that blames his tools.

Re:ANSI CL and the Lisp machine killed Lisp

[cstacy]

Lisp machines were expensive workstations that cost tens of thousands of dollars to deliver performance that, even at the time, could easily be had for a few thousand dollars.

The Lisp Machine was the first commercially available workstation: the first machine you could buy that had such revolutionary features as high-res bitmapped display console, mouse, window system, high-powered processor, large disk, huge address space, and local area network. This was at a time when your personal computer options were Z80, 8086, or Apple II; however, this machine competed in performance with the PDP-10 or maybe VAX-11/750 (if you had one to yourself). The cost was originally around $70,000 per seat, which was considered quite reasonable. When other workstations were invented and some of the costs came down, the pricing was reduced competitively. By the time price/performance was an issue, it was all over anyway, for entirely other business reasons.

For those who are not familiar with the Lisp Machine: it was a proprietary processor and architecture designed for high-performance Lisp computing in a personal workstation format. (The word "workstation" had not yet been invented.) It was invented at the MIT Artificial Intelligence Laboratory around 1977, and was commercialized by several spin-off companies about 1980. The entire operating system and everything was written in Lisp.

Contrary to popular claims, the programming environment has some serious limitations, including lack of source level debugging (eventually it got added, but only after the system had already fallen from grace).

You are making some very strange assertions, there. I don't know about "popular claims", but I could point you to the documentation. During the early-mid 1980s, these machines were considered the Cadillacs of workstations (compared to the new SUN, Apollo, etc. machines that were coming out, and compared to mini/mainframe systems from DEC and others). They supported Lisp, and also many other languages (such as FORTRAN and ADA), and did most certainly have source-level debugging since the beginning. Many of the techniques that are common in today's advanced programming and debugging environments were pioneered on the Lisp Machine, and there are many useful debugging features that are still not available in today's C/C++/Java environments.

There's a lot more history here that I could expound upon. The Lisp Machine companies eventually failed, and there are many opinions and extensive analysis of why that happened. I wouldn't say that it was a simple matter of price/performance, however. The last thing that the major Lisp Machine company did, however, was to finally port the system to conventional hardware (DEC Alpha, sigh). But by then it was too late for the company to survive.

It sure as hell was not due to a lack of features!

I would take issue with many of your other claims, as well, but this is enough for one message.

Re:ANSI CL and the Lisp machine killed Lisp

[mj6798]

I know a lot of these experts you're talking about personally. Are they ignorant of CL and its strengths? No. But are they independently wealthy? Also no. So what happens? They have to get a job where people are offering. Would they have preferred Lisp jobs? In most cases I can think of, sure, absolutely.

Well, all the ex-MIT hackers that I know (myself included) stopped using CommonLisp because it was too hard to get our work done with it. Our employers would have been happy to keep paying for MCL or Franz or whatever, and there is always CMU CL.

The fact is that many well-meaning people make arguments just like you're making, that you can't make money with Lisp. And that becomes a self-fulfilling prophecy

I never made any argument about whether you can or cannot make money with Lisp, and that issue is of no interest to many of my projects (I'm a researcher).

Furthermore, the argument that CommonLisp isn't being used because management doesn't know any better fails because CommonLisp is conspicuously absent in the large fraction of projects where the opinion of PHBs usually doesn't matter: free software and open source projects.

Did they dislike Lisp? Nope.

Who ever said anything about "disliking Lisp"? The subject of this thread is "ANSI CL and the Lisp machine killed Lisp". In fact, I like Lisp a lot, and I think it's a shame that we don't have a better, more modern standard by now. Yale T, ISO Lisp, and Dylan all seemed like promising attempts, each in its own way.

Re:ANSI CL and the Lisp machine killed Lisp

[mj6798]

The Lisp Machine was the first commercially available workstation: the first machine you could buy that had such revolutionary features as high-res bitmapped display console, mouse, window system, high-powered processor, large disk, huge address space, and local area network.

That's not the history I remember. The Xerox Alto started being distributed outside Xerox in 1974. The VAX 11/780 came out in 1978. The CADR, I believe, came out in 1979, and LMI Inc. was founded in 1981, the same year as the Apollo. But if I got my years wrong, maybe you can relate the years as you remember them.

The cost was originally around $70,000 per seat, which was considered quite reasonable. When other workstations were invented and some of the costs came down, the pricing was reduced competitively.

Even in the late 1980's, you could get a Sun workstation with color screen for a few thousand dollars, while a black-and-white Lisp machine with similar performance would set you back tens of thousands of dollars.

[Lisp machines] supported Lisp, and also many other languages (such as FORTRAN and ADA), and did most certainly have source-level debugging since the beginning.

Not for a modern view of source level debugging. Until Genera 8, the Symbolics debugger would still show you an instruction backtrace for compiled Lisp code, and for interpreted code might give you an S-expression if you asked really nicely. None of that was tied to the source code in a way that any modern IDE does, or in the way that even GNU Emacs did at the time for C. (As an aside, Symbolics didn't use real overlapping windows as late as the late 1980's because of the oddball ways window contents were aliased into rectangular arrays.)

Many of the techniques that are common in today's advanced programming and debugging environments were pioneered on the Lisp Machine, and there are many useful debugging features that are still not available in today's C/C++/Java environments.

I think Smalltalk-80 has a much bigger claim to that than the Lisp Machine. In retrospect, it's just amazing to me how far ahead the Smalltalk-80 system was (you can try it out for yourself: go to www.squeak.org).

If you can name any Lisp machine debugging features absent from modern Java IDEs, I'd certainly like to know about them.

It sure as hell was not due to a lack of features!

You make the assumption that "more features" is necessarily better. That is probably the most concise way in which one could state the failure of the Lisp machine and of CommonLisp. In fact, good design requires careful tradeoffs and restraint. It's a shame that such more carefully designed Lisp systems didn't make it into the real world until after Lisp had already acquired a reputation for being overly complex and resource intensive.

Re:ANSI CL and the Lisp machine killed Lisp

[Bob.Kerns]

That's not the history I remember. The Xerox Alto started being distributed outside Xerox in 1974. The VAX 11/780 came out in 1978. The CADR, I believe, came out in 1979, and LMI Inc. was founded in 1981, the same year as the Apollo. But if I got my years wrong, maybe you can relate the years as you remember them.

Your years are about right. What's misleading, though is 1) suggesting that the Alto was "commercially distributed", as opposed to being made available to various educational institutions, and 2) suggesting that the Alto is in the same category. The Alto was an important ancestor, but it lacked the address space, horsepower, and disk space needed for commercialization, and wasn't ever commercialized.

It's also puzzling that you leave out Symbolics from your chronology; the LM-1 (a commercial repackaging of the CADR) is what came out in '79; the CADR was in use for quite some time before that within MIT.

Even in the late 1980's, you could get a Sun workstation with color screen for a few thousand dollars, while a black-and-white Lisp machine with similar performance would set you back tens of thousands of dollars.

Yes, that's true, depending on what you mean by "similar performance". Sun went agressively after the low end of the market, with tiny configurations. These weren't very useful configurations (no disks, in many cases!) but got their foot in the door. But we're talking about a decade later here. There is no question that after a while, price/performance (if it was hardware speed that was important, not programmer speed) began to favor high-volume conventional architectures (for economic, not architectural reasons)

.

Not for a modern view of source level debugging. Until Genera 8, the Symbolics debugger would still show you an instruction backtrace for compiled Lisp code, and for interpreted code might give you an S-expression if you asked really nicely. None of that was tied to the source code in a way that any modern IDE does, or in the way that even GNU Emacs did at the time for C. (As an aside, Symbolics didn't use real overlapping windows as late as the late 1980's because of the oddball ways window contents were aliased into rectangular arrays.)

I'm afraid your memory or your experience has led you astray here. Perhaps you were not aware that there were two debuggers? Perhaps you were not aware that with a single keystroke in either debugger, you could edit the precise location of the call in question?

And as for overlapping vs non-overlapping windows -- in fact, windows could overlap from the very first. This was a UI style issue, not any issue of how bitmaps were handled. I used to occasionally overlap windows back in those days; these days, I generally maximize my windows and switch between them, for the same reasons Symbolics windows were full-screen by default. (But not always, and the market and world at large has clearly concluded that overlapping windows are preferred).

Many of the techniques that are common in today's advanced programming and debugging environments were pioneered on the Lisp Machine, and there are many useful debugging features that are still not available in today's C/C++/Java environments. I think Smalltalk-80 has a much bigger claim to that than the Lisp Machine. In retrospect, it's just amazing to me how far ahead the Smalltalk-80 system was (you can try it out for yourself: go to www.squeak.org). If you can name any Lisp machine debugging features absent from modern Java IDEs, I'd certainly like to know about them.

Smalltalk certainly deserves credit. Many of the ideas Lisp built on came from Smalltalk. (However, Smalltalk-80 post-dates the infusion of smalltalk ideas into Lisp by quite a few years).

However, there are still a lot of lisp-debugger features missing. Edit & continue is just now beginning to make it into some environments -- but can you go back to an earlier frame, change the arguments, and re-invoke that frame (discarding the more recent ones cleanly (i.e. properly executing finally clauses, etc.)? Can you type in a new function, and invoke it -- without adding it to the source code first?

And sadly, I have yet to encounter a debugger as robust as the Lisp machine debugger. The uniform poor quality of debuggers has always been a mystery to me.

Finally, I think you and Chris are in agreement in saying that it was not lack of features that was the problem with Lisp. I'm pretty sure Chris would agree with your final paragraph; I know I do. But I would go further, and argue that even the right design tradeoff does not yield success; good marketing, good business practices, good sales, and good financing are all important to success. But the most critical is perhaps good timing. Compare the fates of Dylan and Java for another perspective on how each of these factors affect success.

Java's solution to the gc problem

[yerricde]

LISP, just like all the languages that have copied its gc system, neglects to understand that there are many other resources I need to manage other than memory (db handles, shared memory regions, mutexes, files, etc.).

The Java language provides a solution that resembles C++'s destructors. Before the Java runtime's garbage collector disposes of objects, it calls their finalizers.

Re:Java's solution to the gc problem

[brsett]

Of course, but in Java there is no guarantee that finalize() will ever be called (some flavors of Dylan and Smalltalk have the same behavior I think). Garbage collection is not guaranteed to occur ever, even if the system exits normally/abnormally. Obviously this isn't a deal breaker for any language, I just think that, imo, no language has a lifetime management scheme as expressive and flexible as C++.

Re:Java's solution to the gc problem

[frank_adrian314159]

Before the Java runtime's garbage collector disposes of objects, it calls their finalizers.

Almost every Lisp that's out there has finalizers, too. Yes, they figured out they needed them years before Java was around.

Most also have a concept of "weak references" as well. This allows an obect to be collected if only weak references to it exist. All weak references are replaced by NIL at that time. This allows one to automatically cache functionally computed variables and have them disappear when they are no longer needed. Saves a lot of space.

Snotty equivalent of the previous message... Java prosteletyzers should do their research before they try to ding languages with MORE features than their favorite one.

Emacs Lisp idiom

[yerricde]

Shouldn't you have made it a lambda function passed to global-set-key?

The Emacs idiom for defining new features is to define the function (giving it a long name suitable for an M-x call) and then use global-set-key to add a shortcut. For example, first make M-x tetris-on-drugs, and then map Ctrl+Super+T to it. (The super key on a PC bears a Windows logo.)

What about currying?

[zedman]

Something that I've been dying to ask someone in the LISP pantheon...

What's the deal with the apparent lack of support for currying. More purist functional languages support currying (but unfortunately often also force you to declare types) so why not LISP?

Why doesn't any LISP folklore I've seen not discuss (the lack of) this feature?

Ian

Re:What about currying?

[jaoswald]

Not that I'm in the Lisp pantheon, but I'll try to answer your question.

CL doesn't support currying (or continuations, or monads, or a bunch of other functional stuff) because Common Lisp isn't a purist language. It is rather a pragmatic language. Purists are welcome to look elsewhere while Lisp programmers still manage to write world-beating applications like Orbitz.

That is all.

Re:What about currying?

[Anonymous Coward]

Currying is easily done in Lisp, so I'm not sure why you think there is no support for it. In fact one can easily write this without even needing to know the arity of the function in question:

(defun curry (function curried-argument)
#'(lambda (&rest remaining-arguments)
(apply function curried-argument remaining-arguments)))

(funcall (curry #'+ 3) 4) => 7
(funcall (curry #'+ 4) 1 2 3) => 10


Although not shown in the example, the results of the curry function can be bound to a variable and used as well. Furthermore, one could also arrange to bind arguments other than just the first one as well.

Furthermore, there is a lot of other support for higher order functions (map and reduce are in the language) and closures allow proper semantics with free (lexically captured) variables in functions.

Re:What about currying?

[zedman]

Thanks for the response.

Two quibbles with the above: first, the curried function requires its first argument immediately,
and second, one has to ``curry'' a function
explicitly.

Ian

Re:What about currying?

[noc]

However, you can certainly build support for these into the language. Transform your code (by hand or programatically) to CPS and voilà, instant continuations (well, they only work once, unless you're using purely functional code).

Re:What about currying?

[Cartan]

I sometimes use this for currying:

(defmacro curry (func &rest args)
(let ((f (gensym))
(eargs (mapcar (lambda (arg)
(declare (ignore arg))
(gensym))
args))
(x (gensym)))
`(let* ((,f ,func)
,@(mapcar #'list eargs args))
(lambda (&rest ,x)
(apply ,f ,@eargs ,x)))))

Looks a little weird, but works pretty nice :-)

Re:What about currying?

[Cartan]

Sorry about the poor formatting, but when I replaced the tabs by spaces I got caught by some ``lameness filter'' that told me to remove ``junk characters'' so I put the tabs back in...

syntactic stupidity

[mj6798]

CommonLisp and the Lisp Machine had lots of design problems and it is no surprise that they failed. But Lisp syntax is easy to comment and it's easy to learn--much easier than, say, Perl. Scheme and other Lisp implementations carry the torch, and Lisp syntax and semantics won't go away.

(Incidentally, 10000 lines in any programming language isn't a lot of code, so by your own admission, you don't really know Lisp very well.)

Re:syntactic stupidity

[Bobo the Space Chimp]

Old Geezer: I'll never forget that month I did 60,000 lines of C code. A lot was duplication with variable name change, but my god...

True story.

Lisp/Scheme in Introductory CS Classes

[Squorch]

At Georgia Tech, we use Scheme as the language of choice for our intro to CS class, CS 1321. Since the courses after this one transition into Java and then C and *then* branch off into other languages, I'm still not sure why Scheme is taught first, but hey... I'm not a CS major.

Try Common Lisp, not Lisp 1.5

[Don Geddis]

Your experience in the early 80's has little to do with the state of the art today. ANSI Common Lisp is very, very different from Lisp 1.5. Just because you had poor (and now out of date) instruction doesn't mean that beginners today would have the same experience.

Re:Try Common Lisp, not Lisp 1.5

[CresentCityRon]

It wasn't out of date at the time. But the core which was has lived on is just as difficult. Not admitting it produces all the people who seem to really hate lisp. It is because they were lied to. "Its easy. Go ahead and learn it."

Re:Try Common Lisp, not Lisp 1.5

[omigod!kenny]

Not to quibble, but Lisp /is/ easy to learn. OTOH, there is a lot to learn. The upshot is one can quickly learn to do the easy stuff, but then you just keep on learning and learning more and more good stuff. I admit one trick I had to develop was to check to see if some functionality I wanted was already supplied by some built-in function. I say Lisp is easy to learn for two reasons. First, there is one syntax: (function arg arg...) Second, you can just execute snippets of code interactively to find out what unfamiliar functions do. No compile-link-run. kenny clinisys

How to Design Programs

[Anonymous Coward]

This book is an introduction to computer programming that uses Scheme to teach computer programming. You can find it at www.htdp.org.

evaluation order

[epine]

Kent's comments about arbitrary parentheses stuck in the back of my mind all day until suddenly the bubble burst.

r = (a/b)/(c/d);

How does Kent think I _should_ paren that?

r = a/b/(c/d); ???

Even if that's still correct, only a supreme wanker would write it that way.

Now lets get more technical. All variables are floats.

r = a+b+c;

In C/C++ the compiler gets to choose the evaluation order. Results might not be the same in the low precision

r = (a+b)+c;

Think you were clever? Wrong. In C/C++ the compiler is still free to reorder evaluation. Who thinks up these crazy rules?

temp = a+b;
r = temp+c;

Finally the compiler takes your word for it.

In Lisp, if I write (* (/ x 42.0) 42.0) I guess the runtime environment is not allowed to remove the costly division.

Personally I think we need to get with the program and start using symbol sets with about twice as many grouping sets. One set of parens for phrasing, another to mandate a fixed evaluation order.

People often complain that overloading is one of the worst features of C++. I agree. But not the operator overloading. The worst feature of C++ is the syntactic overloading of () to define function argument lists as well as to supply arguments for a function call. Not to mention the use of >> as an operator when the angle brackets are sorely needed to denote template parameters.

The subject of delimiter sets runs far deeper than just making it easy for emacs to hop forward and backward when the human eye is jangled.

Re:evaluation order

[Tiny Elvis]

I have no idea what the point of your post is.

Re:evaluation order

[lexpr-funcall]

Your example of "the runtime environment" not being able to "remove the costly division" from the expression is just plain wrong.

Lisp compilers are free to optimize expressions much in the same way compilers for other languages do.

Here's a real example:

(disassemble (compile (defun test (x) (* (/ x 42.0) 42.0))))

0 ENTRY: 1 REQUIRED, 0 OPTIONAL
2 PUSH-CONSTANT '42.0
4 PUSH-CONSTANT '0.023809524
6 MULTIPLY-FP|2
7 MULTIPLY SP|POP
10 RETURN-SINGLE-STACK

Python's missing Lisp's Macros; Java's missing Ace

[SimHacker]

What Python lacks that's extremely important to Lisp, is a macro facility.

String based macros like the C and C++ preprocessors are woefully inadequate. Representing code as data and transforming code with macros is essential to Lisp. Take macros and s-expressions away from Lisp, and you have Python. Take macros and gratuitous syntax away from C++, and you have Java.

Because of the syntax of languages like C, C++ and Java, there's no good way to design a macro language as powerful and easy to use as Lisp macros. The pointlessly ridiculous syntax of Perl make it impossible to implement Lisp-like macros for Perl in a meaningful way. The Byzantine parse-tree data structures required to represent the syntax of a Perl program are much too complex for macros to easily understand and transform.

Before he designed Java, James Gosling took a crack at the problem by designing and implementing a C macro language called "Ace".

Ace was a high level C parse tree macro transformation language, used to generate the low level raster-op code for the X11/NeWS server. The previous version of NeWS totally abused the C preprocessor in ways it wasn't designed to be used, in order to implement the low level high performance graphics code (a dark, unpleasant practice known as "macrology").

Gosling designed Ace in response to the problems and limitations of the C preprocessor, as he later designed Java in response to C++. You could give Ace several ways to implement loops like two dimensional raster operations, and it could different plug code into the middle of loops with different performance characteristics.

Commonly used rasterops could be expanded to different degrees, with many different cases separately coded (pulling the if statements to the outside and generating big fast code). Seldom used rasterops could be collapsed so the code was correct but compact (pushing the if statements inside of the loop and generating small slow code). Ace operated on the level of C parse trees, not text like C preprocessor macros. Ace would actually estimate the space/time tradeoffs, and decide how to expand macros according to the hints you gave it.

But Ace transformations were quite complex, special purpose and difficult to program. So James Gosling decided not to put macros into Java at all.

The success of Java proves that C and C++ preprocessor macros are not essential to those kinds of languages. But Lisp macros are vastly more powerful, and absolutely essential to Lisp.

Ace was an ambitious tour de force for a C macro language, but it was much too complex and unwieldy for Gosling to design into Java. But that kind of macro programming is actually quite commonplace and straightforward with Lisp.

-Don

C won the language wars, decisively

[Ars-Fartsica]

Come back in fifty years and see how much LISP code is still in use compared to C.

Yes, C will be around until you die.

Re:C won the language wars, decisively

[Tiny Elvis]

McDonalds won the restaurant wars, decisively. Must be the best food.

Re:C won the language wars, decisively

[Anonymous Coward]

Lisp has already been in use for 40 years.

-- Rahul Jain

Wrong!

[Kaz Kylheku]

In C and C++ parentheses influence the way the expression is parsed and hence the order in which operations are performed. They don't determine the order in which operands are evaluated.

So when you have, say

f() + (g() + h())

the functions can be called in any of the six possible orders; which order is chosen is unspecified. But there is no question that the addition on the right must be done first, in the abstract semantics.

It so happens that in C, the expresssion

a + b + c

has exactly the same meaning as

(a + b) + c

this is due to the left associativity of the + operator.

The compiler is not free to add the b + c first, if it could make some kind of difference, like a change in the result, or an exception that would otherwise not happen. The result has to be ``as if'' the abstract semantics were followed.

So for instance if a, b and c are integers, and overflow is reversible (as it is with most two's complement machines) then the addition can be done in either order. If they are floating point types, then it cannot be reordered, because floating point addition is not associative: a + (b + c) is semantically not equal to (a + b) + c.

If your compiler treats a + b + c as a + (b + c) and produces the wrong result, it's a broken (nonconforming) C or C++ implementation, as the case may be.

Thoughts from a toe-dipper

[harikiri]

I've dabbled with different programming languages, and profess to be adequate at C, Perl and Bash (does shell programming count?). A few months ago I looked into Lisp, excited after reading a paper by Peter Norvig that talked about "powerful languages" and how some languages were inherently more powerful than others (he argued why he thought Lisp was one of the best).

So I bought a book on Lisp (ANSI Common Lisp), downloaded the Clisp implementation, and started playing around.

One of the first things I noticed (in its absence) was the lack of supporting libraries. Where were the libraries for socket programming, text processing, cryptography, etc? After some searching it was possible to locate some TCP/IP libraries (their lisp equivalents), but they didn't appear as solid as I would've hoped for.

Sidenote: I'm not saying they sucked, but the fact that you had to search for third party support of what I considered fundamental requirements of a language (at least for what I would've been using it for) was annoying.

The above issue, combined with the apparent esoteric nature of Lisp drove me towards Python instead.

A person like myself uses programming languages to accomplish tasks. I want to be able to do this quickly (rapid development) with minimal learning curve required. Languages such as Perl and Python are great for this kind of work. They've got a large community supporting it, socket and text processing operations are natively supported.

Few people are going to use Lisp when it takes a lot less effort to do the equivalent in another language, regardless of its "power". Lisp may have a place for specialised applications, but at least for internet-related apps, it will not be most people's first choice.

Cheers,
H-

Re:Thoughts from a toe-dipper

[harikiri]

Oops. I think that paper was from Paul Graham, not Peter Norvig.

Re:Thoughts from a toe-dipper

[TheLink]

Yep. It seemed almost as if the typical LISP user doesn't mind rewriting everything from scratch (maybe coz it's easy for them).

However it's not encouraging for lazy and not so smart people like me who don't want to keep reinventing wheels, even though the wheels are perfect each time...

Cheerio,
Link.

Re:Thoughts from a toe-dipper

[cstacy]

The implementations from Franz and Xanalys do include network programming facilities.

One nice thing about Java (and to a slightly lesser extent, Perl) is that it comes with a wealth of standard libraries. The situation with Lisp is not very good in that respect. Whilte Lisp has many or most of the libraries you'd wish for,it's harder to find them and they are less standardized. The Lisp community is actively working on seriously improving that situation.

Re:Thoughts from a toe-dipper

[marcoxa]

In some sense you are right.
There is no "standardized" set of "libraries" for
Common Lisp, as there are for "one-implementation"
languages like Perl and (to some lesser extent)
Python. This is a problem due to the fact
that CL standardization was done essentially in
pre-Internet-boom times, and that there are several
implementations. I'd say that the numerous complete CL implementations have been a (IMHO welcome) delaying factor in the appearance of standardized libraries.

Pretty much all the CL implementations do offer
socket libraries, what you lack is a standardized
one.

However, the CL community is well well aware of
this state of affairs and you can find more or less
centralized, embryonical CPAN-like sets of libraries.
Just check http://sourceforge.net/projects/clocc and http://sourceforge.net/projects/cclan.
Another very useful pointer (besides the always useful http://www.alu.org) is
http://ww.telent.net/cliki.

You can find all you need in these places and start using CL in the same way you would other languages.

Cheers

Airline pricing boring?

[Stu Charlton]

"I hardly consider airplane logistics "forging into new territory and kicking the world's ass", by the way. Yes, it's a terribly involved problem, but it's also a boring one, and I seriously doubt that it would be significantly tougher in Java."

I think you've really proven your ignorance in this area. Rule-based expert systems are not for the faint of heart; one needs a dynamic language to even begin to approach the productivity needed to economically design such a system. To give an example, Object oriented programming in Java provides one inherent level of dispatch. LISP allows for multiple-dynamic-dispatch. In C++ or Java you'd have to create multiple-depth Visitors in order to achieve the same level of flexibility, and it would boggle the mind as to the complexity.

So, apparently tackling a complex problem is "boring". And creating a word processor *isn't* boring?

I guess I'm just astounded by your narrow-mindedness at "what is fun". Is it fun solving a routing problem that everyone's solved before 10 times (a word processor)? Or tackling an intellectual challenge that was once viewed as insurmountable - rewriting the airlines' antiquated pricing/logistics engines?

ITA software and Orbitz.com are revolutionizing an industry by creating a pricing & logistics system that saves millions of people hassle & money. Not to mention making millions of dollars for themselves in the process.

The only reason ITA could do what they did was that they recongized the power of expert systems, and their increasing importance. One will have a heck of a time doing that in anything other than a dynamic language like Lisp or Smalltalk.

Thank you

[Loundry]

Thank you for your non-arrogantly-expressed view of LISP. It's refreshing. It's also a bit short, and I am curious: What made common-LISP your language of choice? What can LISP do that C and Perl can not?

Re:Thank you

[NetSettler]

You're asking now what does it for me? This is not an attempt to convince you but merely a personal observation then. Please don't confuse this post with an attempt at debate.

I don't like C's syntax. Particularly the * thing. I regard C as an assembly language, so useful for some things, but not something I want to see all the time. I have much more respect for C than C++ in this regard. I don't want to do manual memory allocation, though. I don't like using pointers explicitly; everything is a pointer in Lisp, so we don't use the term pointer. I don't like being able to get a pointer to things that are not objects because that doesn't suit my normal need, though I recognize its value as a subprimitive, and that contributes to why I think C is an acceptable assembly language. Many Lisp kernels are bootstrapped from C. I don't want to type-declare my data. I very much don't like fixed-precision integers that can randomly be modded down when I add a number to them; I like addition of positive values to proceed monotonically.

What about Perl? I have some respect for the kinds of applications people write in it. It seems to be very robust and offers interesting power. The syntax simply does not speak to me. That's not a statement that the language is bankrupt, but I don't resonate to it. And it's not because I've never used odd languages. High on my list of favorite languages after Lisp is Teco, also a text-processing language.

But some of the reasons I use Lisp are not related to what the languages are but what they aren't. I detailed these in the article. I like and critically depend on interactively debugging with customizable read/print capability. I like having typed objects, not typed variables. I like a standard notation for structured (parsed) programs so that I can trade in programs.

What can Lisp do that other languages can't? Can you spell "Turing Equivalence"? I make no inequivalence claim. I just like using Lisp for these reasons and more that would bore you silly. There's still part 2 of my interview coming if you're addicted to reading me ramble on, which I somehow doubt.

Re:Thank you

[Tiny Elvis]

Sorry if this reply is a little long winded. I wanted to give some specific examples.
As has been stated before, technically there isn't anything LISP can do that C or Perl can't. It's just that I find doing those things in LISP much simpler. Some of the things (many have already been mentioned here) I like about LISP are:

1) uniform syntax -
- easy for emacs to autoindent, mark and copy, etc. because the editor can always easily identify an expression.
- s-exps are easier to read than things like "int *(*(*func)())[] "
(perl syntax such as "${$ref}->{$val}" is ugly and breaks the emacs autoindenter).

2) advanced abstractions -
- macros:
For example:

(defmacro defmethod-ds (name arg args &body body)
(let ((ds (gensym)))
`(defgeneric ,name (arg ,@args)
(:method ((,arg datasource) ,@args)
,@body)
(:method ((,arg symbol) ,@args)
(let ((,ds (find-datasource ,arg)))
(if ,ds
,(append (list name ds) args)
(error "Can't find ~A~%" ,arg)))))))

Lets me declare certain generic functions as


(defmethod-ds method-name object (arg1 arg2)
..code..)

Which is automatically expanded to a form like the above, where two methods are
produced so that a function can be called either by symbol or by actual object.
There is less code duplication because the duplicate code is written by the macro,
not me for each function declared this way. Note that a LISP macro works by
executing code to product code, not substituting values into strings.

Another example is the CL "with-slots" macro. The syntax is like this:


(with-slots (last-name first-name addr1 city state zip) cust-rec
...code...)

Within the above "..code.." block, read/writeable lexical vars have been created
and bound to the named slots. This can save huge amounts of coding when accessing
object slots. However my point is not just the utility of "with-slots". It is that
it is nearly trivial to write macros of this sort for any of your own structures.
So I can write code that looks like

(with-pdf-file (*output-file* :pagesize *report-paper*)
(with-ds book-list
(with-idx (book-list . book_id)
(iterate-rows book-row
(with-columns (title isbn author-list) book-list book-row
(with-indexed-pdf-page pageno :title title )
...code...
)))))

Macros can handle all of the repetitious "glue" code such as slot access,
opening/closing files, etc. , and I can concentrate on the ..code.. part.

- closures, destructuring, lambda forms, the reader, condition system,
mapping functions, CLOS, arbitrarily large ints, rational numbers

I used to spend lots of time in C or Perl trying to minimize code duplication.
Often I would have functions that were very similar but would receive different
arguments and execute different chunks of caller provided code at certain points.
In C or Perl this can be a huge pain. In LISP this sort of thing is trivial
using lambda forms, special vars, etc.

- commands like FORMAT, LOOP allow concise coding of common dull tasks, such as:

(format t "~{~{~&I received ~R number~:*~p: [~{~10:r~^ / ~}]~}~^~%~}"
(loop for idx below 6
collect (list idx (loop for jdx from 1 to idx collect (random 100000)))))

I received zero numbers: []
I received one number: [37,932]
I received two numbers: [89,603 / 53,797]
I received three numbers: [32,288 / 95,547 / 35,564]
I received four numbers: [41,133 / 54,848 / 7,337 / 98,224]
I received five numbers: [35,457 / 56,703 / 86,795 / 73,667 / 22,086]
NIL
*


3)simple interface to 'foreign' libraries. I just began work with LISP several months ago; it was simple
to integrate the ClibPDF and FreeTDS libraries with my code to produce PDF reports from LISP running
on Linux talking to SQL server.

Re:Thank you

[omigod!kenny]

First, if you are put off by Lispers, I am put off that apparently I am a bad person for considering CL to be without peer. Anyway, why I like Lisp: macros, GC, generic methods, fast, uniform syntax, auto-formatting editors, manipulating code easily thx to the parens!, large number of built-in functions, the meta-object protocol, and my new favorite, special variables which I did not even understand for five years. oh yeah, destructuring-bind, the ability to return multiple values, the OO condition system... kenny, clinisys

In Java language you can call the collector

[yerricde]

Garbage collection is not guaranteed to occur ever, even if the system exits normally/abnormally.

In the Java language, you can call System.gc(). The language specification guarantees that the system will run full garbage collection when your code calls this function.

Lisp has unwind-protect, and Scheme has the similar but slightly more powerful dynamic-wind, designed to allocate and free resources whenever execution enters or leaves a particular expression.

Re:In Java language you can call the collector

[brsett]

Hmm, is this a troll? Java does not have a specification -- at all. You could argue it has a reference implementation -- but that would be incorrect as well. System.gc() is not guaranteed to do anything when called, and the JVM on solaris certainly implements it exactly that way -- which makes alot of sense wrt to the java threading priority model. unwind-protect is no different than the with-open-file macro (only works on a single lexical block), and I've already explained why that is insufficient. My criticism is valid, no need to try to contradict. Many people do not find the feature useful, however.

Re:Are all people with lisp gay?

[Anonymous Coward]

Troll? How many Emacs, or eunuchs, users are NOT castrated fags who suck their father's cocks because they were molested and castrated by their poodles?

Re:TROLLS OWN SLASHDOT

[Anonymous Coward]

8. 72 virgin niggers.

dynamic-wind vs unwind-protect

[NetSettler]

Re: Lisp has unwind-protect, and Scheme has the similar but slightly more powerful dynamic-wind, designed to allocate and free resources whenever execution enters or leaves a particular expression.

unwind-protect's job is wholly unrelated to that of dynamic-wind. Neither subsumes the other.

unwind-protect's cleanup clause is like Java try's finally clause; it offers forms to be executed upon final return from a dynamic contour (regardless of how the exit occurs). This is for things like with-open-file that must close a file when you are finally done with it.

dynamic-wind runs wind/unwind forms every time you enter/exit a task in a multi-tasking "process". It's for implementing things like dynamic variables, which Lisp already has primitively, although it's capable of implementing other dynamic bindings. The point, though, is that since on every process switch it runs the wind/unwind, it is no good for things like with-open-file since one does not close the file every time you switch processes; it has to be held open the whole time.

One problem with dynamic-wind as a paradigm is it assumes a time-sliced model and doesn't work as well in the face of truly parallel multiprocessing because it is generally doing and undoing global side-effects. We talked about this in a recent discussion on comp.lang.lisp and people convinced me it was a bad idea for Common Lisp to adopt this, even though I do think it's kind of theoretically cute.

One reason Scheme does not have unwind-protect is that Scheme has no manifest notion of a "final exit" from a dynamic contour. An escape procedure could throw through out but then its state could be resumed later, so the only reliable time to run the protect clauses is not synchronously on unwind, but effectively asynchronously when the garbage collector notices there are no more pointers to the object. This makes it far less useful. Omitting it from the language hides this not-very-well-known wart in the Scheme continuation model.

I have proposed rectifying the Scheme continuation model by either making call-with-current-continuation take an argument saying whether to give out a single-use escape function or a multi-use escape function (so that single-use continuations could run unwinds at a more predictable time), or by making continuations given by call-with-current-continuation take an extra argument saying whether the use is intended to be the last exit from this context. Both of these make the continuation model more complicated than most of the Scheme Report authors (other than me) think is reasonable. So the problem festers and unwind-protect is omitted from the language in part to avoid confronting this problem head-to-head.

My criticisms of LISP

[Loundry]

You bring up some very good points, and you call me to task. You've made me think, and the question I ask myself is this: What are my criticisms of LISP? Well, here is the answer:

1. The resources for learning LISP on the Internet are scant compared to learning Perl, C++, Python, or Java.
   
2. LISP adherents are among the most arrogant people I've ever seen.
   
3. LISP has very few "claims to fame." E.g., are there any network stacks, OS kernels, or major software applications written entirely in LISP?
   
4. LISP has a very weak installation base. I can sit down at almost any *NIX machine and type "perl" and it will most always be there.
   
5. LISP's methods of doing things are often times counterintuitive.
   
6. LISP syntax is ugly.
   
   Now, before you berate me, allow myself to critique my own criticisms.
   
   Criticisms 1, 3, and 4 seem to be symptoms of a larger problem, and don't necessarily have anything to do with the language.
   
   Criticism 2 is true, but, then again, that's a criticism of LISP advocates, not of LISP.
   
   Criticism 5 may as well be a criticism of myself. *Nothing* in computing is "intuitive." Just becuase I see something as "counter-intuitive" doesn't mean it's inferior. I may as well find it to be superior once I understand it.
   
   Criticism 6 is completely subjective. I also find @{vals}{qw/$foo $bar $baz/} = @{$snoo->{blah}} to be ugly, but Perl at least allows many different ways to code things to avoid potential ugliness. I can't seem to find any LISP code that doesn't contain strings that look exactly like ")))))))))))))))))". Perhaps that's "easy to manipulate in Emacs," but I don't feel like learning another operating system. ;)
   
   So it seems that my biggest problems don't lie with LISP at all. I may find myself a LISP convert yet! Perhaps solving criticism #1 (above) may facilitate that. :)

Re:My criticisms of LISP

[BitwizeGHC]

So it seems that my biggest problems don't lie with LISP at all. I may find myself a LISP convert yet! Perhaps solving criticism #1 (above) may facilitate that. :)

Really? Good news! I prefer Scheme myself, and so would recommend you get a hold of Guile or DrScheme (IMNSHO, two of the most robust Scheme inplementations around) and grab a copy of Structure and Interpretation of Computer Programs off the Web. This is a general programming book that uses Scheme as a teaching tool. There's also Teach Yourself Scheme in Fixnum Days.

If you want to crack the spine of an actual book, The Little LISPer and The Little Schemer are good places to start.

As for your complaint about no applications: Yahoo! Store is a Common LISP application. The database system that Squaresoft developed in-house to manage the Final Fantasy movie project was also written in LISP. AutoCAD was once written in LISP (and still incorporates LISP); but these days Autodesk is so enamored with the Microsoft way I wouldn't be surprised if ACAD 2002 was written in C#. All of these are "major applications" though with the exception of AutoCAD you are not likely to find them running on a workstation near you. They all deal with handling massive amounts of complex, hard-to-define data. This is something that LISP excels at. Strangely enough, that definition encompasses a great many computer applications, so now you know why LISP advocates can sometimes wax obnoxious. Especially if their day job requires them to code in something grotesque like Perl or VB, a program that would have taken a quarter or less of the time if written in LISP!

Re:My criticisms of LISP

[NetSettler]

Please feel free to drop me a line in email with any suggestions you have on what you need froma book, since I'm working on several and could use your thoughtful input.

By the way, regarding success stories, I think there are several issues here:

First, for some issues where Lisp could be used or a "commodity" language could be used, the market seeks a commodity. You can hardly blame it and I can't either.

Second, for those issues that Lisp could solve and others can't, Lisp has different strengths than other languages and vice versa, so it's hardly surprising its success stories lie in different areas where you might not be looking, so that may not be why you don't see them.

Third, business success stories are about making money, not about promoting Lisp. If Red Hat or some other Linux or open source company went bankrupt, would it be the technology's fault or the managements? But who would get blamed. IBM could fall and people could blame it on the new Linux alliance they have. Scapegoats are handy. This could make the name Linux unpopular. Would it invalidate the tool? I think not. Might businesses who wanted to keep using the tool decide reasonably not to mention the use of the tool when advertising? Quite likely, I think. I know this happens in the Lisp community. Companies that use Lisp want to focus on their business claims in marketing, and can't risk the potential liability of mentioning a name that has become unpopular (note I didn't say "a technology that has become useless").

I think it's been long enough since AI Winter and the attachment of the "bad name" to Lisp and I'm encouraging people to come clean and start to do like Intel does with its "Intel Inside" campaign. People don't think Lisp is being used because they don't see Lisp is being used. You're right this is an impediment. But it's one that hasn't happened casually--there have been good reasons for it--reasons that could befall any technology, not just us.

My company proudly, and at some commercial risk, displays that it uses Lisp. Commercial risk of two kinds. Some people might not like Lisp. And some people might think I'm a starry-eyed Lisp evangelist more intent on pushing the language than solving their business problem. The former is a self-fulfilling prophecy that can only be changed by using Lisp and showing it can be liked. The latter is a challenge to me to make sure I do stay focused on people's business needs first and keep the related Lisp evangelism second.

Anyway, thanks for taking the time to plod through this discussion to the point of giving us a chance, and for documenting your thoughts. It's been very interesting to me, and I'm sure to others in our community as well. I know the Lisp marketing departments are reading these conversations even if they are not speaking directly. Well-articulated positions, pro and con, are what they're seeking, and what they've gotten here.

So very, very lame all of this

[Bobo the Space Chimp]

No, here is the proper "Hello, world!" program file in LISP:

"Hello, world!"

That's about it. It's loaded and returned on the command line as a string output.

Re:So very, very lame all of this

[NetSettler]

No, the string "hello world" is not active and so is not a hello world program. It only works interactively because the Lisp read-eval-print loop prints the results of evaluation.

But for program delivery, most commercial customers would not accept the read-eval-print loop as an application top-level. And in that case, a string would just sit there lifeless and not automatically display itself anywhere.

The reason I said to do
(defun hello-world ()
(write-line "Hello, world!"))
is that you also have to usually dump the program out as an exe, and you usually do that by doing something like the following (the syntax of which varies from vendor to vendor):
(save-image "my-app.exe" :start-function 'hello-world)

Of course, if you don't want to name the function, you can usually do something like the following instead, but I didn't want people confused by LAMBDA in describing hello-world ...
(save-image "my-app.exe"
:start-function (lambda () (write-line "Hello, world!")))

Don't try this save-image in your Lisp since as I said its syntax varies from vendor to vendor and I made up this syntax as a neutral compromise between various vendor syntaxes. Instead, consult your vendor documentation for details.

Re:So very, very lame all of this

[Bobo the Space Chimp]

(defun Hello-World...) doesn't start itself, either.

You must still, either at the command line, or at the end of the program input file, issue this command:

(Hello-World)

and that is functionally no different from typing:

(load-file "hello, world.lisp")

Re:So very, very lame all of this

[NetSettler]

Re: (defun Hello-World...) doesn't start itself, either.

Did you read my reply? The function whose name is usually called something like save-image takes an argument which is the name of the function to call when you start the exe that you are saving as an image.

Re:So very, very lame all of this

[Bobo the Space Chimp]

You've still got to load the image, though, and both will result in the same print to screen.

Re:So very, very lame all of this

[NetSettler]

Yes, but the invocation scenario for the scenario I describe works by:

Unix$ hello-world
Hello, World!
Unix$

The other one, associated with your apparent desire to use a Lisp expression rather than a Lisp function, must be invoked by:

Unix$ lisp
This is Lisp 437.23
Lisp > (hello-world)
Hello, World!
Lisp > (quit)
Exiting Lisp.
Unix$

Most implementations I've seen require you to write a function to be used for startup, not a form. One or two implementations allow you to execute a form from a command line, as in:

Unix$ lisp --execute '(write-line "Hello, World!")'

But remember that this requires you to distribute a raw Lisp (which in some cases require a license for the Lisp to be bought by the end user), and also risks that the user will have custom init files for Lisp that interfere with your application, and also requires you to make little .bat scripts or the equivalent to start Lisp. It can also mean the Lisp does a lot of setup/initialization in preparation for running things other than the one expression you give it, so that it starts slower than it needs to. The save-image facilities provided in some Lisps tend to provide better control of product presentation, allowing a native .exe to be distributed, sometimes allowing the irrelevant functional support to have been garbage collected away, avoiding the user getting direct access to the Lisp level of your application, etc.

Re:ANSI CL and the Lisp machine did not kill Lisp

[NetSettler]

First, not that it matters really, but you're just wrong about source level debugging. It was present in Lisp Machines much earlier (two or three major releases and a half dozen years) than you realize. It wasn't turned on for Lisp for unknown reasons, but it was there and the sources were available to users. We didn't suddenly implement it for Release 8--rather, we had a discussion where someone said "Hey, how come we have this source level debugging and no one uses it?" and someone else said "I dunno. I guess no one ever turned on the variable." So we turned it on. It probably had a bug or two, but if someone had set the variable earlier and reported those bugs, they'd have been fixed earlier. It wasn't like customers didn't have the sources. And source debugging was turned on and in-use for the Lisp Machine's "foreign languages" (Fortran, Ada, and I think one or two languages, maybe Pascal?). I remember seeing a demonstration when I arrived to work at the company in 1985.

Second, you're also wrong about what killed Lisp Machines. A combination of poor real estate deals (buying a 10-year long-term lease on space that didn't turn out to be needed and that cost many millions of unneeded dollars), guessing that the Mac would beat the PC and building the plug-in board for the wrong platform first (and then not getting to doing a PC one), improper pricing (e.g., charging the same $10K per seat for delivered database application royalties as was charged for development, failure to effectively counter Sun's drop in workstation prices), bad marketing (failure to recognize that Lisp Machines were being identified by market analysts as a separate market category from personal computers, failure to recognize that "you won't need as many employees" was not an attractive thing to say to a manager intent on maintaining the size of his power structure), confusion over whether to focus on hardware or software (where the software turned out to be the more commercially robust arena, but the hardware got most of the money), and bad management (failing to reduce the number of products when money ran short) killed the company. The Lisp language did not cause the problem. The number of Lisp software developers was tiny compared to the size of the company, most of which was hardware sales and production and infrastructure geared toward sale of iron. The company failed to adapt fast enough to dropping prices and new sales strategies. If anything, the power of the language kept the company afloat because years after the hardware could no longer keep pace, users were still willing to use slower machines with that software just to get its pleasant programming environment. I have one in my house right now and still use it for some work and some household things; I don't still use my Mac Plus...

And you're wrong if you think the demise of Lisp Machines killed Lisp. There are probably more implementations of Lisp now, in all kinds of price ranges, commercial and free, than there were at the time Symbolics went under. Lisp has been through some hard times, but has weathered them, and seems to be on the mend. Some Lisps and Lisp companies have undergone belt tightening, but few market segments have been spared that in the modern economy--it filters out bad management and spits up the technology to those who can manage it better. Even if all the companies went away, and that doesn't seem to be happening, there are still free implementations. Lisp is just not dead.

To be honest, I don't really understand why it's important to someone to declare a language or community dead while there are people using the language and happy with it. To assert that this is "dead" is simply insulting to those people. If you don't want to use the language, I think that's fine. But beyond that, it seems rude, pointless, and destructive to take a posture of such definitive negativity that can't possibly aid you in any way and can, by confusing people with misinformation, injure others.

sure they did

[mj6798]

First, not that it matters really, but you're just wrong about source level debugging. It was present in Lisp Machines much earlier (two or three major releases and a half dozen years) than you realize. It wasn't turned on for Lisp for unknown reasons"

Seems like you are confirming what I'm saying: the Lisp machine did not have source level debugging until Genera 8. Whether it was hidden somewhere in the source code where your customers couldn't get at it hardly matters.

Second, you're also wrong about what killed Lisp Machines. [...] The Lisp language did not cause the problem.

I didn't claim that Lisp caused the problem. I claimed that poor business decisions, i.e., delivering an overly expensive niche market product, killed Symbolics and LMI and gave Lisp a reputation for being expensive and complex, something you, again, seem to confirm.

To be honest, I don't really understand why it's important to someone to declare a language or community dead while there are people using the language and happy with it. [...] destructive to take a posture of such definitive negativity that can't possibly aid you in any way and can, by confusing people with misinformation, injure others.

You are still operating under the mistaken assumption that Lisp has become marginalized because I or others have an irrational dislike of it. Quite to the contrary. I think Lisp is the greatest thing since sliced bread. That is why it has been so painful to see its decline over the last two decades, a decline I attribute to greedy and poor management at various Lisp vendors and a poorly conceived standard for CommonLisp.

I hope a new generation of researchers and programmers will learn from this history and that over this decade, Lisp will make a comeback. But that's why it is important to understand what went wrong in the first place.

Another interesting link about the history of Lisp and the Lisp machine is here, which basically reaches the same conclusion that I did.

Oh, and if you would like to experience a little more the sensitivity and humility with which many in the Lisp machine community have criticized other systems, just take a look here.

Re:sure they did

[lexpr-funcall]

Seems like you are confirming what I'm saying: the Lisp machine did not have source level debugging until Genera 8. Whether it was hidden somewhere in the source code where your customers couldn't get at it hardly matters.

Source level debugging was documented at least as of Genera 7.0 (1986). If you wished to compile your definitions with source level debugging information you had two (documented) ways to go about doing this. The first was to compile your forms within the editor using c-m-sh-C, also known as "Compile Region Toggling Locators". The second way was to set COMPILER:*INHIBIT-USING-SOURCE-LOCATORS* to NIL, which caused everything to be compiled with source level debugging information (at which point c-m-sh-C would compile things with source locators turned off). Less elaborate forms of source level debugging were around and documented at least as of version 6.

Another interesting link about the history of Lisp and the Lisp machine is here [mit.edu], which basically reaches the same conclusion that I did.

Unfortunately, this paper has a fatal flaw: its only reference for Lisp Machine history is the Harvey Newquist book "The Brain Makers". Ironically, the authors totally messed up their bibliography entry for the Newquist book, which makes the accuracy and overall quality of the paper highly suspect.

While I found the Newquist book to be a fun read, it gets a large number of otherwise easily verifiable facts wrong. I certainly hope you did not reach your conclusions using only that book as a reference!

Re:sure they did

[mj6798]

Source level debugging was documented at least as of Genera 7.0 (1986). If you wished to compile your definitions with source level debugging information you had two (documented) ways to go about doing this. The first was to compile your forms within the editor using c-m-sh-C, also known as "Compile Region Toggling Locators".

The people I asked around the MIT AI lab didn't seem to know about it at the time, and as a Lisp machine user for half a dozen years, I never came across it in the voluminous documentation. I don't think "Lisp Lore" mentioned it either. I think if you look at how you say this was "documented", you can figure out yourself why nobody knew about it. Compare this with Smalltalk-80, which already had rich, obvious, powerful source level debugging around 1980 and presented the facility in an obvious, easy-to-use way. Overall, I think the Lisp machine had a decent development and debugging environment, but I personally wouldn't call it ground-breaking.

While I found the Newquist book to be a fun read, it gets a large number of otherwise easily verifiable facts wrong. I certainly hope you did not reach your conclusions using only that book as a reference!

Actually, my conclusions are based on my own experience: I was a Lisp machine user for half a dozen years and a CommonLisp user for a dozen years. I tried hard to introduce CommonLisp at several research labs and companies, but eventually gave up, for the reasons that I mentioned: the implementations cost too much and writing code that was both portable and efficient was a lot of work, negating much of the productivity advantage. Furthermore, the Windows and UNIX versions of CL never really seemed to integrate well with their environment.

I consider it a rather sad history because CommonLisp was quite a ways towards being a really great language and environment. Fortunately, many of its ideas live on in a variety of modern languages. And maybe, just maybe, CMU CL or some variant of Scheme will pick up the torch: a good open-source implementation that avoids some of the ANSI CL hair and integrates well with its environment might get picked up again by more users.

Re:sure they did

[lexpr-funcall]

The people I asked around the MIT AI lab didn't seem to know about it at the time, and as a Lisp machine user for half a dozen years, I never came across it in the voluminous documentation. I don't think "Lisp Lore" mentioned it either. I think if you look at how you say this was "documented", you can figure out yourself why nobody knew about it. Compare this with Smalltalk-80, which already had rich, obvious, powerful source level debugging around 1980 and presented the facility in an obvious, easy-to-use way. Overall, I think the Lisp machine had a decent development and debugging environment, but I personally wouldn't call it ground-breaking.

Bromley and Lamson's "Lisp Lore" most certainly does talk about source code debugging. If you have a copy handy, turn to the chapter on debugging. It starts on page 80. Prominently displayed information on source debugging and source locators can be found there, I promise! Symbolics published a large documentation set and provided elegant tools for finding what you want. Document Examiner's :show candidates is quite forthcoming. Did you every try using it in your search for source debugging? Lastlty, the System Index has really slick permuted indices which will point you to the very same places.

You seem to like a Smalltalk-style browser-centric debugging interfaces. Did you every try using the window debugger?

Actually, my conclusions are based on my own experience: I was a Lisp machine user for half a dozen years and a CommonLisp user for a dozen years. I tried hard to introduce CommonLisp at several research labs and companies, but eventually gave up, for the reasons that I mentioned: the implementations cost too much and writing code that was both portable and efficient was a lot of work, negating much of the productivity advantage. Furthermore, the Windows and UNIX versions of CL never really seemed to integrate well with their environment.

The reasons you cite for Lisp not meeting your needs (high prices, performance problems, lack of integration with the host environment) may have been valid complaints regarding the available Lisp systems of yesteryear, but are hardly relevant today. High performance Lisp systems which are well integrated with their host environments are readily available at all price points.

Re:sure they did

[mj6798]

The reasons you cite for Lisp not meeting your needs (high prices, performance problems, lack of integration with the host environment) may have been valid complaints regarding the available Lisp systems of yesteryear, but are hardly relevant today.

I think they are as relevant today as they were five years ago. If you stick with the CommonLisp standard, you only get very limited functionality. If you use the full spectrum of functionality available in any particular implementation, you make yourself a member of a tiny user community and dependent on some small company. Calling both CommonLisp and the vendor variants collectively "Lisp" is as misleading as it would be to refer to C#, Java, and C++ collectively as "C".

Compare the CommonLisp situation with, say, Java. If you write applications in Sun Java, you are writing for a platform with a huge user community, a vast set of libraries with detailed documentation, excellent performance, lots of dynamic and reflective features, and negligible licensing costs (too bad about the syntax, though). If Franz or some other vendor managed to do the same Job with their CommonLisp variant as Sun did with Java, I'd switch back in an instant and would have no problem using the system commercially.

High performance Lisp systems which are well integrated with their host environments are readily available at all price points.

Well, I've used Franz, CMU CL, AKCL, GCL, CLISP, Bigloo, and PLT. I have also checked the implementations at lisp.org every now and then. Which system are you thinking of?

Bromley and Lamson's "Lisp Lore" most certainly does talk about source code debugging.

No contradiction there. My claim was that source level debugging didn't make it out to customers until the late 1980's. Bromley/Lamson came out in 1987. I was referring to Bromley's Lisp Lore, which came out in 1986 and AFAIK doesn't talk about it. With Genera 8, the Lisp machine became a much better system, with better debugging support and a better GUI, but it was too late.

Re:intro to Lisp

[jaoswald]

Thanks for your thoughtful response.

I recommend http://www.lisp.org/ for on-line resources regarding Lisp. I think the best introduction, however, is Paul Graham's _ANSI Common Lisp_, which I believe is only available in dead tree form.

I happen to like CMUCL, a relatively robust public-domain implementation available for Intel Linux and a few other UNIXes, operated using GNU Emacs as a front end. Many other implementations are listed on the web page.

Java is Low Level?

[billr]

Come on.

I can see you not liking it for a whole host of reasons, but that just doesn't make sense.

lispy advantages still there with Kawa

[brlewis]

I think it's important to note that Common Lisp, upon which most of Kent's comments are based, does not have an equivalent to Scheme's continuations either. Nor does the spec guarantee tail call elimination.

It should also be noted that "outward" continuations (not captured) are supported by Kawa. I use them.

Scheme VM

[Anonymous Coward]

I saw at a recent seminar that there exists a third-party Scheme plugin for Microsoft's VisualStudio .NET. This plugin presumably produces MS IL for the .NET runtime.

Now, if I only had a DVD player, I might consider sacrificing a machine to the VS.NET beta I was given at that talk just to see if it works...