Fair warning (updated March 24th, 2010): This page is now all but unreadable. It has become a battleground between terrible, whiny Java programmers and circlejerking Lisp programmers. Proceed with caution!
i.imgur.com
Someone who is always eager to let you know that whatever it is you're doing would be done better in Lisp Language. Why? Don't ask, they can't explain it to the rest of us. The wise course is to stay clear and wait for them to go extinct.
Nonsense, they can and will explain it. Some of it isn't true, but a lot of it is.
[smug smug smug smug]
And whether they actually are able to explain it or not, quite often they will try. And this is not necessarily a good thing, depending on whether your ride's leaving.
See also Smug Non Lisp Weenie.
I guess I'm one of the SmugLispWeenies, except I (a) never hacked on a Lisp Machine (though I'd love to have a go one day) and (b) try not to be too smug, as it's unkind to those not fortunate enough to use Lisp. So, with the Caveat that SmugLispWeenies need not necessarily hack on Lisp Machines, and need not necessarily be smug, I propose a membership list of SmugLispWeenies! :-)
Lieven Marchand
Conditional S.L.W's:
Top Mind - The most flexible-yet-simple programming language known to man, but Lisp Is Too Powerful for most mortals in the setting of the work world. It's like issuing a nuke to a cop. Its root data structure is also a sub-optimal human Wet Ware mapping. See Masp Brainstorming. Lisp is definitely something to admire even if it's not so practical in the hands of Earthlings.
Imagine coding in Agile Language. Your smug user talks lambdas, and need for higer order methods will surely arise. After a period of resistance, you start parsing your agile lambdas into sexps, transforming those sexps, thinking in sexps, and soon, your Agile Languag is nothing but a beauty façade over Lisp... --Anonymous Donor
Edit Hint: sub-topic context or relationship is questionable. This is essentially a list of handles with brief comments. You might want to move them.
"A big obstacle within the Lisp community is the fact that we seem to have too many right-thing thinkers, whereas it would be more healthy to stress the diversity that Lisp allows us to have." -- Pascal Costanza
Common Lisp is an actively multiparadigm language and allows great ideas and syntaxes from other languages to combine, such as CL-AWK: lemonodor.com 
Such flexibility allows people to build powerful support for new paradigms, in many cases going beyond the original designers' intent. OOP + Meta Object Protocol is one example. Another example is the system for handling unusual situations like errors: it had deep Multics DNA.
Multics influence, hmm, that doesn't ring a bell - what was this?
Under "Influence of Multics PL/I on Symbolics Zetalisp": www.nhplace.com
Wasn't there a page on here somewhere about the Social Problems Of Lisp? One might hope that those could be discussed on the Common Lisp Wiki, but the authorship there suffers from all of said problems, so nothing interesting can be said. I was going to write something even ruder here, but decided that, though true, it was uncalled-for.
Unfortunately, they are right a disturbingly large percentage of the time. I am not sure what this implies for the current directions of hard/software.
Sorry - right about what? This question keeps getting deleted again and again and again. Do the Smug Lisp Weenies not like to answer?
Right that lisp, and for that matter the lisp machine, would do 'it' better. Or more concretely, often lisp had the right answer 20 years ago to a problem that your language (or you) is just realizing is a problem, today. Watching a Java programmer get all enthusiastic about garbage collection (never mind all the problems that Java has) 5 years ago was a painful experience for a lisper; similar experiences may be had with proponents of python, ruby, c++, etc.
It is not the language that needs Garbage Collection. It is the operating system that needs Garbage Collection. It makes software development much easier and more reliable.
At the end of the seventies we had a few machines (Xerox Smalltalk 80, Xerox Inter Lisp-D, MIT Lisp Machines, ...) with graphics and integrated environments written in Smalltalk or Lisp. These were mostly object-oriented and interactive. Later people saw these fancy environments and tried to copy them. Unfortunately only the user interfaces got copied and not the object-oriented and interactive environments. That's one thing that will eventually come back. Machines that are interactively programmable down to the bones. Operating systems and applications that are written in an interactive high-level language like Lisp or Smalltalk. Software that is implemented and extended in the same language. It will happen. But it may take some time. Maybe another 10 years.
Yeah, all that is great - but what is this "it" about Lisp that is so wonderful and powerful and able to leap tall buildings in a single bound? (We know it's not faster than a speeding bullet.) What is "it" that Lisp is the "right answer" to?
Please note that glibness is not the same as answering a direct question. Nice try, though. Well, you know - for a Lisper.
Quoting, from above:
...often lisp had the right answer 20 years ago to a problem that your language (or you) is just realizing is a problem, today.
And what might some of those problems be? On other pages I have asked for specifics. Repeat that here? Guess so.
Like XML or garbage collection? -- Baczek
XML is a problem, then? And garbage collection is a problem, too?
No, silly, they're the answers. (Representing arbitrary structured data (sexprs). Managing memory resources (gc).)
Lisp, because of its very minimalist syntax, very powerful macros and very complete set of built-in-types becomes extremely good at doing just about anything you can name. In Lisp, because your development cycle is REPL based, and you can modify an image as it runs with an interactive prompt, your development cycle is entirely different. Lisp users talk about doing things like Bottom Up Design, and extending the language to meet the problem, meta-languages, and other tricks that sound like vague and overly complex hackery to most other programming language communities. In Lisp, they are not because it's So Darn Easy to do it. These techniques are powerful, and Lisp makes them easy.
Lisp, like Extreme Programming, is good not just because of any one feature (Higher Order Functions, Lisp Macros, Lexical Closures, REPL-based development cycle, very good execution speed compared to its peers, etc...) but rather because of all of these things synergize to create a beast far greater than the sum of its parts. When the aforementioned glib poster answered "Programming", they were actually being serious, if rather curt about it.
Lispers insist on splattering code all over this Wiki in some vague attempt to win acolytes, one supposes. Code examples do not help to explain how the development cycle is "different," which, one presumes, implies "improved." As a simple example, what the heck does REPL mean?!? Lispers are constantly talking about car and cdr and sexp whatever other magic words go along with Lisp and simply ASS-ume that the rest of the community is following along. We're not. If you would like to convince us that Lisp is so superior you need to explain it in terms of solving specific development problems or speedier design-to-code cycles or whatever. Telling me that Lisp is the "right answer to programming" tells me exactly doodle. Actually, it tells me you can't defend the statement you've made and are falling back on Argument By Repeated Assertion. Eh?
Since you don't want anyone to explain Lisp to you, then perhaps you should make an effort to get off your ass and learn the language yourself instead of rambling on like the stupid whiner that you are. Why does everyone have to spoon-feed the benefits to you?
One effort to describe why Lisp is so powerful is made at www.defmacro.org -- Slava Akhmechet makes special effort to try to describe the power of Lisp through technologies he expects every (non-Lisp) programmer is familiar with. It's a very enjoyable read, too!
Well, your request is reasonable, even if your manner is crass. A "REPL" is a "Read Eval Print Loop". Lisp environments interact with the user via two methods:
Reading files, like the Ruby or Perl interpreter. Specific conventions exist, like in these languages or in C/C++, to run a "main" function after loading is complete. This is usually done with "deliverable" products.
"REPL" is an acronym for Read Eval Print Loop. The REPL is a prompt that accepts lisp code and evaluates lisp expressions and prints the result. Since all lisp forms are expressions, any valid expression may be entered. If you were to write a (defun ...) statement you would define the function for that session (basically). Likewise, you can look up variables and evaluate expressions and actually run the entire program from the REPL. This directly inspired ruby's "irb", so you might have had experience with it.
Because of the way the REPL works, you can write code, then directly and manually test it. This is a pretty nice feature in itself, but is barely the surface of it. One common example is in debugging. When Lisp signals a condition, it will drop you to a "debug" loop which is a REPL loop with special features (called Restarts). In this, you can now being to execute arbitrary forms to check exactly what went wrong. This is a whole heck of a lot better than incrementally adding printfs, and dovetails nicely with testing practices.
As far as the crassness of responses to the gushing smugness that Lisp proponents on this Wiki display - you'll have to put up with a certain amount of that. It seems to be a rather natural retaliation for the (unsupported) air of superiority that Lispers carry around here.
Ignoring Higher Order Functions... what about Garbage Collection? Lisp's had that nearly fifty years now, too. Of course, it ought to be pointed out that the recent acceptance of such higher-level programming constructs in the mainstream programming community has as much to do with Moores Law, and other issues of engineering economics, than anything else. For quite a while, it was more cost-effective (at least in the minds of those writing the checks) to throw more programmers at the problem and squeeze out every cycle and bit, than it was to have fast CPUs and oodles of memory; the latter were expensive. Nowadays, the economics call for making programmers, and not code, more efficient. Smalltalk Language is in the same boat as Lisp - they are languages ahead of their time; doing wonderful stuff but not practical for many production programming environments available at the time. Smalltalk especially, given its need for snazzy graphics terminals. (See Java Vs Smalltalk for more on this).
Some Lispers forget this - and act as though Lisp has always been the best choice for every conceivable application at any period in its history; and that the rest of us are dimwits for just figuring out that things like Higher Order Functions can occasionally be useful.
Objects And Closures Are Equivalent. Modern OO languages (including Common Lisp Object System) are nice because they Re Factor out a lot of the bookkeeping that gets exposed if you Use Closure Not Object (or if you roll your own vtables, etc), and thereby expose a simpler yet highly useful model.
Unfortunately, many programmers have trouble grokking OO; hell, many have trouble grokking procedural (which, despite not scaling well to large/difficult problems, is easy to understand and use for the simple stuff). And one simply doesn't need Higher Order Functions to write Crud Screens and the like. {I smell a Domain Pissing Match in that comment.}
"The phrase "object-oriented" can evoke strong feelings of hostility in Lisp aficionados. On the one hand they feel that Lisp has always been object-oriented in some sense and wonder what the fuss is all about; on the other, they are alienated from object-oriented programming as practiced in the C++ and Java worlds, with its heavy emphasis on compile-time bondage and discipline, and feel that the phrase has been hijacked in such a way as to exclude Lisp. (Tim Moore)
Of course, many in the C++ and Java communities accuse the Smug Smalltalk Weenies of trying to hijack the phrase to exclude C++/Java, so go figure. :) Seriously, CLOS is OO by all but the most restrictive of definitions; Lisp has had polymorphism of a sort for a long time. It was quite a while before Lisp got native polymorphic/generic functions/methods, though it could fake these if it wanted. And the phrase "compile-time bondage and discipline" is highly argumentative but hardly constructive; there are many legitimate reasons for wanting static typechecking and other whips'n'chains associated with C/C++/Java (besides masochistic pleasure) -- even if it means a less flexible typesystem and having to provide type annotations all over the place.
In fairness to XML - it has its genesis in the publishing community, not the programming community. And for "documents" - entities composed of "essence" (content) and "markup" (metadata), XML (and its ancestor SGML) is a reasonable choice. For structured data, sexprs might be a better choice - though I doubt that any advantages of sexprs are great enough that we should all abandon XML just to sooth the hurt feelings of the Lisp community. :) Plus, it ought to be pointed out that many objections to Ess Expressions coming from non-Lispers are objections to its use as a data entry format - in other words, many consider sexprs a pain to type and a bigger pain to read. YMMV. That objection doesn't apply nearly as much to XML, which is almost always generated and processed by machine - not by programmers banging away at Emacs.
Do Not Worry About The Credit. This constant fretting over Lisp "not getting its due" is one of the Social Problems Of Lisp (but is in no way, shape, or form restricted to Lisp! C coders reacted with spontaneous surprise when C++ came out, what with its fancy-schmancy Virtual Method support and all. After all, C coders can do that just fine, and have been, since the age of Unix on the PDP-11 via function pointers! Ahhh, but alas, it's perfectly alright for Smug Cee Weenies to kvetch about this, but as soon as a Lisper does it, oh lordie, look out, ye sky is a' fallin'.), and an annoyance to many. I know my programming history fairly well (though I have the "handicap", I suppose, of being in 1971; so I've never had to deal with punchcards and such). Besides - most of the folks worrying about Lisp getting the credit or not are seeking to bask in reflected glory anyway (like the C coders of years before) - I've seen quite a few Lispers worrying about the "credit" who (like me) were in junior high when Common Lisp was being developed. Kinda like sports fans crowing about their team winning a championship.
What do y'all want, anyway? Do you want to see a big disclaimer pop up every time we fire up our favorite Java IDE saying "this language contains technology originally developed in Lisp?" Should we put David Moon on the currency?
No, we want that engineers stop bitching about the language, and start writing applications and libraries. It seems like a week doesn't go by, when some young whipper-snapper doesn't come out with some new-fangled programming language that is just some ho-hum rehash of something that came before. So predictable. They spend all their time working on "tools" or "productivity" enhancements, that the applications they could have written in Lisp will wait decades to see the light of day.
Most programmers of any reasonable skill and training are familiar with the contributions made by Lisp
Not in my experience.
. . ., even if we use something else on a regular basis. If some VBA-coder in the IT department has never heard of Lisp, who cares?
We don't. But, what it boils down to is simple: if you want to program, learn to program. A mechanic doesn't bitch and moan about his socket sets. An architect doesn't bitch and moan about his pencils. An electrician doesn't bitch and moan about what copper wire goes into the walls. A coder shouldn't have to bitch and moan about the language he codes in. And yet, from our point of view, that's all we hear from you folks: oh, woe is me, for how art possible thy workings with all those horrid parentheses, the hyphenated symbols, and the verbose character designations? And the speed! Forsooth, it is slow! Lest I not forget that 'tis mere implementation issue, nay, can't be, 'tis must be universal for all implementations of Lisp! OFF WITH ITS 'EAD!
But, such is the fate of evolution, forever re-inventing the wheel. Imagine how much farther our knowledge of computer science would be, were we to not ignore our past, but embrace it instead?
And, of course, . . .
Quite a few of them are getting close; there's not much that can be done in Lisp that cannot also be done in Python, at least without serious Green Spunning. For example. And Python has the advantage of being far simpler to learn than Common Lisp; and far easier to do trivial stuff in.
People who complain only about the parentheses and car/cdr/setq/etc. probably can be ignored.
No, it isn't. Show us. Act it out. When you prove something to someone, you'd demonstrate it. Make a video of yourself coding in Lisp and one coding in another language, or show us one of your applications that just does so many more magical things in Lisp. Prove it. Do it. Demonstrate. Example. Theories don't help. You don't tell people you are going to the moon, you demonstrate it and prove it.
I'm not the one who asked the original question; though I'll happily supply something that resembles a rebuttal. :) -- Scott Johnson
This is a great idea. Who will step up to the challenge and create a Common Lisp Coding Video that shows the uninitiated what is so great about Common Lisp?
What do they have to show? Well, for starters, Common Lisp is basically a dumbed down version of Lisp Machine Lisp. So, every time you use Common Lisp, you basically use something that has been developed for and on the Lisp Machine -- though with some bits left and some added.
I consider myself both a Young Lisper and a SmugLispWeenie, as I fall under both criteria (owning and loving to use, even today, a Lisp Machine as well as not blaming the Ai Winter for Lisp's poor popularity). See First Language Learned. -- Dan Moniz
This is all getting out of hand... Why the need for negativity? Lisp isn't dead, even though Lisp Machines are. Our company is successfully using Lisp to deliver a commercial product. No fuss, no muss. You don't need to be smug and martyred, you just need to do it! -- Alain Picard
[By the way, Alain: what commercial product does your firm make that uses Lisp? Or is Lisp used as part of the production support or some such?]
We make a product called XOS, which you sort of can get a description of at www.memetrics.com . It's written using Lispworks + MATLAB + C + PostgreSQL. -- Alain Picard
Also, it is time to bring back Lisp Machines. How about a Lisp Os for Intel, SPARC, and Mips?
As a guy whose exposure to LISP was only half of a semester course in college, I have to ask what are the Lisp Scheme Differences. I'm already set to learn Scheme, but I want to know what I'll be missing/gaining.
The lisp machine was a great environment, but now it is gone. Remember what was good about it and look for that in the environment you work in now. How can we do things faster? What tools exist that would help us? -- Don Wells
Unfortunately, a lot of tools/environments seem to moving in the opposite direction. Bletcherous IDEs purporting to help you prototype "quickly" in a language (basic/c/c++/java/etc.) that is poorly designed for Rapid Prototyping. Not what I would call progress :( In lisp I didn't need to deal with lousy wizard-generated code and the illusion of rapid prototyping, I had the real thing. Sigh.
The good part of such tools is dealing with the visual elements and positioning. However, I think GUI layout should be meta-data and not application code. Plus, some people prefer "flow-based" layouts instead of coordinates. But, these are Holy Wars of their own.
Considering what Lisp has been and done over 50+ years of history, Lisp fanatics have some right to boast. The first LISP implementation was begun in 1958, the first publications describing that implementation came out in 1960, the LISP 1.5 Programmers' Manual came out in 1962, and that's when the non-MIT research implementations began. I am guilty, but proud. I've used Lisp on everything from Lisp Machines to DOS. I don't think I should apologize for having this experience and bringing it to bear on various discussions. I would like you to be as excited and interested in Lisp as I am, because I think we will both benefit from more attention paid to Lisp. But moreover since I am talking from the experience of Lisp and most of the popular approaches, our discussions would benefit from a common base of understanding. If you and I know X, but you don't know Y, you will not be on equal footing in a debate of X vs Y. -- Patrick Logan
Excuse me - did you say 50 years?!? Uh, isn't that stretching things just a little?
Some think that OO backers are as smug as LISP or FP fans. What are the measures or indicators of smugness? Unlike LISP, OO has had pretty good market acceptance. Then again, so has Microsoft :-)
So how to interpret this: one of the most powerful OO systems ever standardized (CLOS) is relatively unknown, while relatively poorly designed OO systems and language (c++,java,c#) are all the rage. Can't be simply OO backers, can it?
I wonder what percent of LISP and/or FP fans would also consider themselves OO fans. Paul Graham's group likes to complain about OO's assumptions as being narrow and limited.
Graham is unusual, but certainly not unique, in his disdain for OO. Plenty of CL'ers are fans of CLOS.
The LISP smugness just oozes here: www.paulgraham.com
So for people who know little about LISP, how would you recommend we get started? What's a good tutorial website? Should we try Common Lisp or this Scheme thing? If you want to make it more well known, let's get it out to a wider audience.
Dr Scheme is probably the Scheme implementation with the best support for learning the language. Click on the URL at the top of the page, then select the "Learning" section.
I recommend reading the book Structure And Interpretation Of Computer Programs from MIT press.
Speaking from personal experience, I began to learn CL a few months ago, but lost interest recently because of the terrible state of free tools and development environments available for lisp. Yes, LISP is an incredibly powerful language, beautiful in its grammatical simplicity, macros are incredibly powerful, and so on -- I grant you all that stuff - but the most important thing as far as I am concerned as a student of many languages is the learning environment, and emacs/ilisp is not even in the same universe as a decent java ide (like eclipse). I'm sure if one wanted, one could extend emacs/ilisp so that it does some of the things eclipse does out of the box, but one shouldn't have to.
Try Lisp in a Box!
Common Lisp doesn't even have an equivalent of the humble Idle that comes included with every Python download (providing syntax highlighting, auto-indentation, etc) for Python. Python help documentation available from the interpreter is also far superior to the lisp documentation in clisp (no, I can't afford to buy franz lisp for a decent implementation, and I don't have to in any other modern language. This is why lisp is so unpopular. We don't all have access to Lisp Machines and expensive Lisp environments).
I'm having the same experience right now. I find the IDEAS of Lisp fascinating and enlightening. I also see why Lispers would be so frustrated with the limitations of popular languages.
But I now ALSO see why "nobody uses Lisp" these days. The problem is the instantiations of these ideas into actual languages are pretty awful. "They all suck", as Paul Graham declared in his keynote at the recent Lisp conference. I totally agree.
As a Lisp user I actually think that Paul Graham sucks more.
I'm beginning to feel the same about Graham, but not because I think he's wrong about the shortcomings of today's Lisps. It's because I think that he, like so many Lispers, overestimates Lisp's advantages and is almost blind to the advantages of other languages. Nearly all languages have at least one advantage over Lisp or strong point worthy of note, but Graham will probably overlook most of them. He'll use his "can it return a function that...?" litmus test, and if it doesn't do things that way, he'll dismiss the language in its entirety. He'll note the concurrency advantages of Erlang because Erlang also happens to have first-class functions, but he'll miss the security or internationalization advantages of Java because it doesn't have first-class functions. Not exactly the guy I'd choose to design my dream language which, by the way, would almost certainly be a form of Lisp.
Note that my "dream language" would look different if I was building it for myself versus building it to be used by teams. I believe Lisp to be better for self projects than for teams. Economy of expression is less important on teams.
As a Lisp user I think that you are right. Erlang, etc. are all pretty nice. Really. My advice would be, if you are happy with Erlang, stay with it.
There are basically three such instances: elisp, Scheme, and Common Lisp. Elisp isn't used outside emacs and is barely tolerated, even by Lispers. Scheme is the best start of a Lisp language design among the three, but its spec is so minimal that it is almost useless for production work as is. (This hasn't stopped the authors of a certain otherwise excellent textbook from paring it down further still in an effort to demonstrate how one can derive everything from first principles.) So, it has to be extended dramatically by every implementation. There are lots and lots of Scheme implementations, all extended differently, mutually incompatible, with probably an average of 1.5 developers each, so you can forget about useful standard libraries or tools. You're left with a bunch of disjoint demonstrations of academic concepts instead of a real "platform".
The Scheme Requests For Implementation, an attempt to systematically develop a set of standard libraries for Scheme, are mostly intended to address these issues. However, while the quality of the resulting libraries is excellent, the breadth has been quite uneven, with a mix of very ambitious but overly-specific libraries side-by-side with skimpy or missing support for some basic functionality. A more recent project, CSAN, is an archive of existing Scheme code and tools inspired by Perl Language's CPAN. However, it has so far proven to be stillborn. In general, these projects has a feeling of, 'too little, too late'; only time will tell whether they will ever flesh out sufficiently to make Scheme a viable general-purpose language.
The good news is, those tools that do exist are excellent, especially the Dr Scheme Integrated Development Environment, which is comparable to many commercial IDEs available for other languages. - Jay Osako
That brings us to Common Lisp, the one Lispers usually point to as the "real, production Lisp". Unfortunately, it strikes me as a total relic of the 1970's. Yes, all the useful Lisp ideas are in there, but they are mixed in the clutter of other junk that appears to be the result of compromises made by diverse commercial vendors in the early Reagan years to support their customers' legacy software from the Nixon and Carter years. Scheme cast off this legacy baggage in the 1970's, but Common Lisp has carried it into the 21st Century.
Several companies have brought Common Lisp into the 90s. Apple, Harlequin and Franz were the most prominent. Most newbies don't understand much about the history and why things in Lisp are the way the are. They might only have seen Windows and Linux. Common Lisp has influence of systems that were here before.
Most developers are more interested in the present than the past. Lispers are a notable exception. Lispers will tell you that you have to understand how important certain legacy issues were in 1973. Non-lispers' natural reaction is, why don't you drop the 30-year-old balls and chains (some of which were dropped 25 years ago by Scheme) and create a new Lisp optimized for today's constraints?
There are several reasons for that. Most people see only the hill on which they are standing. Many people in the Lisp community have seen several hills (go up AND down). At one point Lisp was widely used in commercial settings. Up to the point where SUN, HP, Apple, etc. were selling Lisp systems (or reselling them). At that time commercial applications have been developed and stability of the underlying Lisp suddenly became very important -- since you don't want to rewrite a million line Lisp application every second year that it runs on a changed language. So, stability of the language became important for the commercial users. Lots of stuff at that has been done by users with complicated problems and deep pockets. Much of the development for Common Lisp for example was driven by the (US) military.
Later it has been tried several times to develop new Lisp platforms (languages, implementations, environments, ...). Just to list a few: Dylan [Dylan Language] (for application development by Apple), Eu Lisp (for application delivery by European research institutions), GUILE [Guile Scheme] (for system-level scripting)... and some more. Often these were taking technology that has been developed in the Lisp community applied to typical current non-Lisp users. Prominent example is Dylan. Which was developed so that it should be used by people who at that time were using C++ for application or OS development.
Some of these projects went very far (like Dylan) and took a lot of resources. But in the end the result was not the success that was promised/wished. So, as a Lisp user one is a bitten by the experience of prior attempts and very conservative. Common Lisp survived as a used language -- most of the other attempts not. So the reaction is, let's get Common Lisp more useful and improve it incrementally before starting another large attempt for a new Lisp.
My personal feeling is that some of these things are slowly rediscovered (like Garbage Collection). It will take some while. Quite a long time I fear. Sometimes it helps to know that things can be different and once were, sometimes it makes people feel uncomfortable. My personal advice: Yes, Common Lisp is ugly. We all know that. Get over it. Use it. It is still the best out there.
Well, first, thanks for the advice (seriously, not sarcasm), and I'm taking it. I will use it, but almost certainly as a learning vehicle, not for production.
Thanks for considering it. The advice was meant really honest.
Second, just think about what you're saying "Common Lisp is ugly. We all know that. Get over it." It has been almost unchanged for 20 years. If it has been ugly, and everybody has known it for twenty years, and the best advice is still just "get over it, it's the best we have", that's a sorry state for the world's best programming language to be in. If Common Lisp has been stuck this way for this long, I think it's time to retire it and start over with a new Lisp. I'd do it myself if I could.
As I wrote before these attempts were done already. Common Lisp also evolved a bit.
70-8* lots of different dialects/implementations (Mac Lisp, Standard Lisp, Lisp Machine Lisp, Inter Lisp, ...)
8* effort to create a unified industrial strength language. Based on Lisp Machine Lisp minus a lot of things. Common Lisp (CLtL1) was the result.
8* Lisp as an AI assembler. Common Lisp was seen as the low-level language on which many higher-level languages have been built.
8* CLtL2 adds object-oriented programming back into Common Lisp (OOP was already (differently) in Lisp Machine Lisp and others).
8*-9* ANSI Common Lisp. Cleaned up version of CLtL2. with stuff added and stuff removed.
9* Common Lisp experimentation in different implementations by vendors and implementors. But the base language stayed mostly the same. Unfortunately these experiments and extensions have not been standardized widely. Partly they have. For example both Harlequin and Franz worked on the CORBA-Interface for Common Lisp. Some standardization failed (CLIM for example).
Why can people live with the ugliness, you may ask. The reason is that the language in some areas (either by design or because of the implementations) is repairable. Common Lisp as a programmable language can often be repaired by writing a bit more Lisp code (the syntax is programmable, CLOS is programmable, ...).
Unfortunately the flexibility is also a big drawback. Simpler and less flexible languages have certain advantages. My feeling is that people are attracted by some of the features they don't have in the languages they currently use. But actually having the features (like the almost unbounded flexibility of Lisp) makes it worse for them.
So, Common Lisp is both ugly and beautiful (for example I think CLOS is really outstanding). If you mostly stay in the language and in some low-levels, you may experience much of the ugliness. If you build higher-level languages on top (by extending Lisp for example), you escape a bit from that ugliness.
I also agree that a cleaned-up version is very worthwhile to have, unfortunately I don't see much happening in that direction and I'm busy using the already existing and useful implementations. So its more a practical advice. If there would be an effort with some chance of success, it would be interesting to go in that direction. But since some time there is no effort that seems interesting. And, no, Arc isn't it either.
Don't bother waiting for some super new Lisp. It won't be here soon. And no, Arc isn't it.
I strongly suspect that you're right, but I hope you're wrong.
Currently people are busy improving the implementations. Other stuff will follow.
Yes, more implementations of Common Lisp. The Lisp community doesn't seem to have what it takes to create a new Lisp - something done many times in the early years - but does seem to have the resources to spend decades trying to make a silk purse from an "everyone knows it's ugly" sow's ear.
Yes, and the reason is that once you get over the ugly parts, you can get actual work done -- even with Common Lisp.
Heaven help you if you suggest a new instantiation of the Lisp ideas on comp.lang.lisp, though. Despite the name, the group is not about Lisp. It's about Common Lisp. And since CL long ago lost its ability to change (the standards committee is one guy at the commercial company Franz who annually writes into the minutes that "nothing happened this year"), those few who remain loyal almost have to be of the opinion that virtual perfection was achieved twenty years ago and today's newcomers who can't see that need to use it for ten years to understand the wisdom of the ancients before they deserve to even have an opinion.
They deserve an opinion. But it would be nice if they were willing to listen a bit.
If the Lisp community is really interested in having Lisp become really popular, it's the Lisp community's turn to "listen a bit". There appear to be quite a few of us who are interested enough to investigate it seriously and who then get very frustrated with what we find. Unfortunately, comp.lang.lisp and cliki are not places that encourage discussion of "if you could change Lisp in any way, what changes would you make?" Instead, they prefer "tell us what you love most about Common Lisp".
I think there are pages on CLIKI which were discussing things. Search for 'Lisp -- Next Generation' on CLIKI.
New stuff is not automatically better because it is new. Learning some existing stuff is sometimes harder than trying to reinvent the wheel (badly). They even more deserve an opinion if they not talk, but actually write code. I see lots of people talking about theoretic options.
It's hardly the hotbed of innovation that Lisp used to be renowned for. Since today's model of open source, cross-platform, simple language/large libraries, Net-centric, Unicode-centric, Unixy flavored (in pathnames, file-orientation, I/O, etc.) languages has existed for only half of the lifespan of today's average programmer, it's far too new to have had much influence on Common Lisp. (Franz has worked hard to add modern features on top of the legacy stack, but they then sell their Lisp for thousands of dollars: another sign that the Lisp community is still stuck in the 70's.) CL'ers refer to fossilization as "stability".
Sounds like another 'free everything' propaganda.
Not. It's an observation that languages compete today on more than just tail call optimization. It's hard for an underdog to catch up to market leaders. If the underdog is overpriced and the market leaders are free, I don't see it happening at all.
We really need a new Lisp language: one that both retains the power of the best Lisp ideas and meets the criteria of a modern language. All popular language fail in the former. Today's Lisps fail the latter. Language "expressiveness" is the only thing Lispers want to talk about, but it's no longer the only thing developers look for. Maybe Graham's Arc will be the one, but if he's working on it at all, he's clearly not interested in public input into the design. His Arc site has been a cobwebsite for years. His "please send suggestions" email address is just a one-way valve. [Not necessarily - I got a thoughtful answer to a suggestion I sent in sometime in 2004. However, that may be because I happened to use the term "DWIM", which led him to think I was a long-time Lisper. -- John Stracke] It's not a discussion list, so who knows if your suggestions are even relevant to what he's currently thinking, or whether he even thinks about it at all these days. I hope Graham is not our only hope for having a major, new Lisp.
Nobody really needs a new Lisp language. Common Lisp and Scheme are good enough. If you want to have a new Lisp language create one. Then we will see...
Well, I don't think CL and Scheme are good enough, but there's not much I can do about it beyond saying so, hoping that my feedback united with others' will encourage someone who is able to create a new Lisp.
Thanks for your thoughts.
And thanks for yours. I think your advice is quite reasonable: if you like the ideas that underlie Lisp, and really want to use some form of Lisp in practice, you'll probably have to learn to live with the ugliness of Common Lisp, because no cleaned-up, modernized, "New Lisp" is likely to be available for a long time, and some improvements in the larger CL platform (free implementations, installers, libraries, etc.) are on the way. I hope that accurately reflects your advice, because I think it's good advice. ;-)
I'll also hold out some hope that out of all of those hard-core MIT CS types who think that anything less than Lisp is a Language for the Masses, another Larry Wall or Guido Van Rossum or John Ousterhout or Bjarne Stroustrup or Anders Hejlsberg will emerge and do what Paul Graham claims he's doing.
Actually, what seems to be missing from Lisp are friendly Deep Grokkers, Perl has Randal Schwartz, Python has Tim Peters, (please add to this list for other names and languages).
I have to echo this sentiment. The usual data structures course was taught at my college, using Dylan. I know Dylan is not Lisp, but it's close enough to color my unrefined opinion of those types of languages. I didn't mind Dylan so much as I minded the buggy interpreter implemented as a Java applet (from the Early Bad Days Of Java). When the the mental energy used to avoid crashing the interpreter and writing around bugs in the interpreter exceeds the mental energy used to actually program, it turns you off to the concept. As a separate rant related to the course... a large percentage of us begin as procedural programmers. They really ought to have a small 'learning lispy languages' course as a pre-req. Wrapping your mind around both the intended coursework AND learning a language whose paradigm is incredibly different from what you're used to at the same time is doable, but not ideal.
Yeah, it is really sad that we don't all have some Lisp Machine. Really. Emacs + Common Lisp is not a replacement for that. But you should get quite far even with Emacs + Common Lisp. A Common Lisp mode for Emacs would be Ilisp, Slime (new) or ELI (only for few Lisps). With all of these you get some level of source coloring, interfacing to the underlying Common Lisp system and documentation. For documentation of the basic Common Lisp functionality one usual interfaces the Common Lisp Hyper Spec. For your own software one usually writes documentation strings and looking them up is a common functionality of the Emacs-to-CL interface. For learning both Franz and Harlequin have versions of their development environments.
Can I weigh in here? I have a love/hate relationship with LISP. Every time I look at it, I'm impressed with its elegance and ease of development. It's garbage collected and has a beautiful object system, and coding data structures in LISP gets easier every time I do it. Then I start looking at doing serious things with it and am unimpressed with its lack of standards for things like socket communication and threading and assorted system tasks that would be trivial in, say, C.
Right now I prefer C++ over anything else, but LISP could easily be my favorite if a few problems were worked out. -- Bruce Ide
---- What's important is that something gets done.
Most of this is based on money of course. If we create a program to do "a certain job", we will make money. So if not for money, then for what. Maybe pleasure - games. Free games as an example, or open source games. So does Lisp offer any advantages in games? If not games, what does it offer? Let's see some real world examples of Lisp then. If it's a good language, or it's a better language.. where are some examples. If you look at something like Delphi - you could find an example of where Guy A needed to create a text editor, but he needed to create it faster than in C++. Delphi would do the job (Visual basic wasn't good enough).
It is supposed to be a really good "AI" language. But when I was using xEmacs .. and I tried the "psychologist game", it was not impressive. So show me some good examples then. Was that just a badly coded AI game that I tried? If I was going by example, I wouldn't choose a language for doing "AI stuff" until I saw a practical situation where there was an example of an AI situation. We hear about how it was used in MIT lab and all that, but where are some examples that I can see? I hear a lot about people pissing in pickle jars at Mc Donalds, but I don't believe it until I actually witness it or see a bunch of people showing me that it actually happened with some examples. Where are all these AI intelligence software applications that actually do something? Until I see something, or until someone tells me about a real world experience they had with a pickle that tasted like piss, I don't waste time wondering about it. Just show me it, or describe to me the advantages, using a real world situation (I don't need an actual example in every case, I will take your word for it of course. The point is not that I actually need to see a real application and download it (although that could be a solution too); I haven't seen any real world examples or experiences - all I've seen is just theories and ideas.)
So give us some real world examples (not theories or ideas) of where Lisp is used, and is better than another language.
I know for sure that if a new programmer had to create a text editor really fast, it would be in Delphi. If someone wanted to do their taxes, the real world solution would be a spreadsheet, not a text file composed of code (because the code would take too long). If someone wanted a really complex text editor that was more advanced than anything created in Delphi, maybe they'd have to use Lisp, Or C++, but would they? show us an example of something BETTER in Lisp. I have even found cases where there are better Delphi apps (which are easier to create, in a general extent) are more complex than C++ apps. But these are all real world examples, you see. So where are the real world Lisp examples?
Sure, you can run an IRC chat in emacs, but I mean.. what's the big advantage, where is some real world proof that anything is better than anything. It doesn't matter as much what theory you have about why lisp is better - it matters what's done and what can be used. I get so much more satisfaction when I actually develop the program that I want to develop, than to just sit and ponder what would be the best language. If someone would show me some real world examples of a programming language that "kicked ass" I might choose that language. If I needed to do something, I'd need to see something real world. I know for sure I can go out there and test Delphi apps and see which one can compose what program that I need.. I can test out the apps to see if it's possible to create a similar app in Delphi to C++. I have examples to stand by. Where are the lisp examples.. what does lisp show for? where are some apps? You can bet that if I need to create a program, and I see an example of a program created by some guy in 60 minutes in Lisp, that I will use lisp. If I see that the same program was coded in 600 minutes using another language, obviously I would use lisp.
I think that I'd rather see a picture of cookies on the front of a box, and maybe even a few crumbs to sample, than to just read some ingredients on the box. Where are the real world examples? What's it used for, where is it?
When you do that, you end up eating cookies that are mostly chemistry
Many banks use Java and ASP. But when we go to the Perl websites they always seem to run fastest. So there are the real world examples: If I was a programmer I'd probably have to go with CGI, since I'd seen a real world example. I know that my customers would appreciate speed and they don't want to dick around on their PC's all day at the bank website. I know that almost all my small Delphi apps can even run on old 100mhz computers with CPU power to spare and hard drive space to spare. Java: no way. So there is a real world example: I know if I only have a 100 MHz computer (say a small message machine or a MP3 player for a car) then would probably, from real world experience, not use Java. I know that I can create small applications in Delphi and small applications in C++, so it'd probably be wise in a time restricted situation to use Delphi, since it is more visual. It's a real world example. So where are some lisp examples. Just show something.
If I wanted to design a sink that came on at 6:00 in the morning and filled up a glass of water, I have certain limits: there are only so many instructions needed to make this thing happen. I'd probably pick the language that was easiest to program in if I was time restricted. But if I had a long time, then I might choose something that was faster, but harder to program. The advantage with Delphi is that you'd have something efficient and easier to program in, so in some cases you can get the best of both worlds. The question is, does lisp offer any best of both worlds, or does it offer anything? what does it offer? show by example this one time, not theory. I guarantee you that you can sell a language by showing someone the power of it... try to sell a car and give the person a test drive. If you try to sell it without letting them test drive it, they probably won't buy - if they do buy, they aren't practical - you can't buy on theories, you have to buy on examples, otherwise you might be buying a dud.
Yeesh, what a rant. If you want to see examples, go search for Lisp code on the Web yourself -- there's tons of it. Web servers, build systems, editors, symbolic math applications, and on and on and on...
"Tons of it." Hmm...planet-source-code.com has less than 70 packages total of Lisp stuff; Sourceforge has a little over a hundred, but 80% of those are effectively dead, with little or no file activity at all; various schools and certain government institutions have a variety of packages, but no huge libraries of applications jumped out at me. Of course, there is Emacs.
'Perhaps nobody wants to admit to using Lisp because of the competitive advantage it provides. When I build Web sites on Lisp, I give the scripts names that end with .asp, just to throw you off. If I write a Windows desktop application, I'll tell you it was written in Visual Basic .NET. I don't want you to learn Lisp. When I show you an example of Lisp, I'll deliberately pretend that the only supported form of iteration is recursion, and that the only data structure is the list, to give you a bad impression. If there's a customer waiting for me to write the code, I'll release it six months after it's done, to simulate the extra time it would have taken to write it with your inferior tools (in the meantime, I'm working on other projects and leaving you in the dust). Nonetheless, governments and large corporations have on occasion admitted to using Lisp. For example, Honda's super-advanced ASIMO robot runs 100% Lisp, and NASA used it to write the code that runs in the Mars Rover. But that software is 100% useless, because it doesn't run on a Windows desktop, and it doesn't shuffle useless data around, like the typical Java program does. Any computer algebra system has to be written in Lisp: You'd have to slog away for 100 years to write Mathematica in Java.'
Try starting at cliki.net . You should find pointers to a number of repositories of open-source Lisp code. But also keep in mind that a language's mindshare in open source is not necessarily a good indication of its overall representation in software development.
Better yet, if you're really curious, spend a few weeks learning Lisp yourself and form your own opinion, instead of asking people to do a sell job on you. If you want the short version of my opinion: Great language, but a bit off-putting if you're working on Windows, due to a lack of affordable, good-quality implementations for that environment.
Kinda defeats the porpoise, don't it? Considering that 99% or more of today's deskstops are Windoze environments, why should I pursue Lisp as an alternative to everything else out there that is far better supported? I am certainly not going to spend weeks learning a language just to form my own opinion, particularly when I can have people like you tell me I can't use it under Windows. However, the CL Wiki looks like a good place to gather information. I might even find a freebie CL interpreter for Windows there, eh?
''For Windows your no cost options are:
CLISP - clisp.sf.net - Not a compiler, so not the most performant option, and there are some caveats around the Meta Object Protocol.
LispWorks Personal Edition - www.lispworks.com - Free As In Gratis with some restrictions, but it's a modern implementation with compiler and a fantastic IDE. Portable to Unix and Mac.''
Note: CLISP does compile and it compiles to bytecodes!
I didn't say that you can't use it under Windows. As you found out, there are indeed CL implementations for Windows. The free ones have some shortcomings; the good ones are a bit (extremely) pricy, but if I were using CL for a paying job, they would be worth the cost. Aside from the two that you listed above, there are also Gnu Lisp (free), and Franz and Corman Lisp (non-free, with free non-commercial versions). Corman is quite affordable even for commercial use, is specifically for Windows, and has some very nice features. Unfortunately it falls a bit short on standards compliance in a few areas.
To evaluate a language, you really need to try it yourself. There are monumental programs written in Basic and Forth. Showing you examples of systems written in Lisp won't (or shouldn't) convince you of anything. The question is whether a language fits the way you work and what you work on.
I personally find that a language fits the way I work when it forces me to write programs that read: 10 INPUT "Enter a piece of data", A$: IF A$ <> "Q" THEN POKE 1060, PEEK(1040)
Really, are we all going to take the time to learn every computer language out there then? Yes. We should take the time to learn any language we see out there? Yes. No. Then languish in your own bigotry. I use experience (says the folk who, not two sentences ago, made clear in no uncertain terms he desires no experience with Lisp at all) and examples and I do research (read, I read the opinions of others and parrot them, almost verbatim, as if they were foregone conclusions) first. I'm not going to try baking a loaf of bread in the sun outside if I have researched an electric or gas oven to do the job better, faster, more efficient, etc. (Actually, solar cooking is singularly the most efficient form of cooking known to all of man-kind -- it consumes precisely zero joules of energy from terrestrial sources, and while it may take a bit longer for the bread to rise, who cares? BTW, as a solar cook myself, you'll overwhelmingly enjoy such cooked foods over anything that an oven, broiler, or microwave can produce. But, I digress. So much for "experience" and "research.") I don't have to learn how to bake a loaf of bread in the sun outside in order to make a judgement on whether or not to proceed. (Read: I am above you, and because my parents used a stove, I don't see why I should buck the trend. Does solar-cooked foods taste better? Maybe, but I haven't seen of or heard of it! I certainly haven't tasted any myself! So why bother? Why should I, gasp, experiment? That's dangerous -- I might learn something.) Save yourself a bunch of time and learn from others, don't waste your life doing everything yourself. In fact this is part of what open source code is based on: the idea that other people's experience and effort should assist you, and vice versa. You don't have to do or experience all the human languages out there too, do you? Or are you some genius that can handle this? (Chinese, Japanese, French, German, etc., etc., etc.) We generally don't have to be genii to become polyglots. As I'm told by someone who does speak 7 languages, though, once you learn 3, they all start to make sense in a universal sort of way. So it is with learning C, C++, Python, Perl, BASIC, Pascal, Oberon, Forth, Lua, and even Awk. Get off your behind, go learn multiple languages, including non-Algol languages, and make yourself a better coder and designer. Until then, you sound like a pompous U.S.-citizen that drives around with two 2-ft US flags tied the rear latch of a pick-up truck with a muffler falling off, but yet cry like there is no tomorrow about having to spend $200 to fill their gas tanks every week. (True story -- a coworker where I work was complaining quite loudly how even $50 doesn't come close to filling a quarter tank on his SUV. Poor baby.)
Folks, it's people like this that give rise to Smug Lisp Weenies. If we didn't have pompous air-heads like this guy around to make us look like extraterrestrial intelligences in comparison, thus giving the illusion of our purported smugness, I can assure you, we would be perfectly amicable, polite, and even approachable. But as long as we are scorned, as long as we are ostracized from the software development community, and as long as we are looked upon with disdain, contempt, and sub-human stature, then this "divide" of Smug Lisp Weenies versus the Humble Masses will not only continue to exist, but will amplify and widen. Remember, the Great Flood supposedly occurred because God saw that the Humble Masses weren't so humble anymore, they thought they were better than everyone else.
If you only spend a few days learning a new language, you'll only notice all the things that annoy you because they're different from what you're used to. Spending a few weeks getting to know a language is not at all unreasonable - in fact, it should be the minimum that you expect to spend, if you're serious about learning about a language.
'What I notice is when a language is annoying because of the things you 'can't' do in it.'
No, you can actually make quick judgements if you are experienced. There are the quick first impression judgements and the "later" judgments, but you shouldn't only rely on your later judgments. With this attitude, you'll never run any useful software, you'll just spend time theorizing about why your language is so good, instead of actually coding a project and getting it done. Within a few days of programming in Delphi for example, one will notice that visual basic is very limited, and that even C++ is very tedious. Yet there are still people out there comparing visual basic to delphi, and still a lot of people thinking that you can't do anything visually... smug wheenies.
'Visual BASIC and Visual Pascal^H^H^H^H^H^H^H^H^H^H^H^H^HDelphi are basically the same thing.'
Some people called me a SmugLispWeenie because I've used scheme for some of my projects. This is really becoming too broad a brush. I like lisp a lot, but one of the major Social Problems Of Lisp is non-lispers. It's not the only social problem of lisp, and not the biggest one. I think lisp (including scheme) is beautiful and I want to share that experience. I don't mean to come off as boastful or smug. What am I to do, stop writing lisp? Would that satisfy you?
Goodness, no. We wouldn't (I wouldn't, anyway) dream of telling you to abandon Lisp. Using Lisp doesn't make you a SmugLispWeenie. Nor does discussing it in a constructive manner. Heck, even discussing it's advantages over other solutions is OK.
What makes one a SmugLispWeenie is the rather condescending attitude that some Lispers have to the rest of the computer science community - asserting that whatever we collectively do, 'tis inferior to Lisp; and those of us who don't actively choose to develop in Lisp are therefore inferior programmers. Ignorance of Lisp is assumed when any activity is commenced not involving/derived from Lisp - because, gosh, if we had considered Lisp then we obviously would have used it.
That is what makes one a SmugLispWeenie. If someone asks "Why didn't you use lisp?", a common response is "Shut up, you SmugLispWeenie". But if you use something that is better than lisp, of course I want to hear about it! And if someone answers you thusly to an innocent question; you can dismiss them as rude and boorish.
I guess that's what happened, then. As I said, the brush is becoming too broad. I've been hesitating to recommend lisp, actually.
If, on the other hand, someone gives you a perfectly good reason why not (even a non-technical reason like "my team doesn't know Lisp", or "the boss said we have to use Java"),
Yeah, I'd consider those perfectly good reasons. (And I'd call the second one of them one of the Social Problems Of Lisp.)
Depends on why the boss issued the edict; if Java is selected because the entire enterprise is coded in Java; 'tis a particularly good reason.
But the reason I even asked in the first place was just in case the answer would be "Oh, we are lisp experts but we found something much nicer for this particular job".
and then you proceed to claim that a) such reasons don't (or shouldn't) matter; or b) Lisp is so obviously superior that any failure to use it for any application is tantamount to professional malpractice; or c) no programmer not intimately familiar with Lisp can possibly claim to be competent - then you likely are a SmugLispWeenie.
Right; to avoid being called a SmugLispWeenie, I A) have to be kind (never condescending), and B) be prepared that some people will call me a SmugLispWeenie anyway.
A) is good advice in most circumstances regardless of whether you are seeking to avoid weeniedom or not. B) is life; I've been called lots of nasty things that ain't true before; doesn't make it any more true.
Besides - if you feel that SmugLispWeenie is a trivial insult which is dished out like business cards at a tradeshow to anyone who mentions Lisp, Scheme, or Ess Expressions, then treat the remark accordingly: ignore it. This page is intended to be in jest, anyway... though a bit of steam does get vented here (in both directions) which might give some discomfort or offense.
Some people here consider the designation Smug[Lisp|Smalltalk]Weenie a symbol of pride.
As I don't have a particular favorite language (I develop in C/C++ at work and think them useful; but I hardly consider either the pinnacle of computer science), I guess I'm not easily identified as a weenie. But if I were, it'd scarcely bother me...
I guess the reason I got sad was that it hit a little too close to home, it was almost true.
If the set of SmugLispWeenies were the empty set; or a tiny fraction of the language community - we wouldn't have this page. All communties, of course, have their bigots. Unfortunately, the Lisp bigots - much like clueless Yankee tourists asking foreign shopkeepers if they take "real" money (i.e. US dollars) rather than the local currency -- give the rest of the community they come from a bad name.
Well, I find that OO'ers are often smug. They seem to think that because they are "in style", at least using the Trade Rag Metric, they have no obligation to demonstrate objective superiority.
In general the most popular people often get away with name calling of less popular people. This page appears to be the same: The popular kids call the less popular smug and dare them to proof that they are not smug, which is then used as proof of their smugness.
The most powerful never get called smug because their smugness is accepted and therefore may not be called smug at all. Whereas any weak group will have to prove their claims, but no proof they can give will ever be enough. The point of demanding proof is indeed not getting proof, but giving proof that the other group is weaker, in which case it does not matter if they are right or wrong, it only matters that they shut up.
Maybe that some popular language bigots discovered that calling every one who proposes Lisp Smug made them shut up really fast?
100% of the power of lisp compared to other languages is the macro system. The macro system is a way to emulate structured programing in common lisp which has only a goto. Many Lisp compilers implement other control structures directly, rather than using macros that expand into TAGBODY forms another thing you can do with macros is write VHLL's, very trivially, because of the fact that you can manipulate the code into something that the interpreter can understand. but that is a lot of power in itself and can only be achieved by having a syntax like lisp. Lisp also allows the use of Functional Programming, which means you can minimize the amount of your code that relies on side-effects. This results in less debugging time. Thus about 60% of the power of Lisp over Java comes from Real Macros, and the remaining 40% comes from Functional Programming (all numbers are direct from my anus, which produces remarkably accurate percentages).
I'm speaking as a Lisp/Scheme newbie myself: I recommend anyone who is seriously interested in learning Lisp to check out plt-scheme. Just download the precompiled Dr Scheme for your platform and get started. It's easy to install and comes with many useful libraries (regular expressions, networking, two object systems, GUI toolkit, xml & html processing, threading, web server, ...) and loads of documentation. plt-scheme also has a powerful module and a packaging (for code distribution) system, unicode support, a compiler to produce native executables and a JIT compiler. I've tried free Common Lisp implementations before encountering plt-scheme because I've often seen statements like "Scheme is useful for teaching, use Common Lisp for practical purposes". But I have to say that plt-scheme is IMO superior to the free Common Lisp implementations I know.
Anyone who has used Common Lisp would find any dialect of Scheme to be akin to a straight jacket. PLT is certainly less restrictive than (for example) MIT Scheme, but it's still Scheme. It works as hard as it can to discourage the use of Real Macros (even though it is possible to implement CL's DEFMACRO form). The macro system that Scheme does provide is very poorly documented. As an advantage, however, PLT Scheme is a compiler that runs on both Windows and Linux, so you get better portability than you would if you used Lisp Works (Windows only) or SBCL (Linux only), and you don't have to code to some least-common-denominator standard to get that portability.
Right that's IT, up with this I will not put ...
I trawl the net day and night and the amount of these ridiculous My Language/Penis is Superior/Longer That/To yours flamewars I see makes me think "Gee, are you guys part or full time retarded?" On occasion I descend from my ivory tower to put the smackdown on some coding weenies. I'm not sure why I do it as it's not very sporting, (like shooting fish in a barrel,) but here goes anyway:
LISP CODE IS DATA. If you don't grasp the ramifications of that then frankly, you are doomed to remain a mediocre coder ... period. Pretty much the entire point of Lisp and its derivatives is that you can write Lisp programs that manipulate Lisp programs. Added to that (due to lisp's syntactic cleanliness), you can actually *prove* things about a piece of appropriately written Lisp. And by "prove" I don't mean "well, this looks like it should work", I mean in the "mathematically true for all time" sense. Now in theory, you can take a parse tree for a piece of code written in the godawful piece of excrement that is Java, flog yourself senseless distilling it down into something vaguely approaching a set of sexprs (without side effects of course!) and try to prove something about that, but why would you want to? It'd be like trying to do high-level pure math using Roman numerals.
There is a lot more to a real functional language than "it feels nice to code," there's a definite point to it. Shit, I'm saying this, and I'm not even a Lisper. My background is writing all manner of high performance C++ & assembly code to shovel polygons to video cards at speeds that would make your typical Java coding weenie's head explode. I'm a creature of the arcane hack, but at least I've bothered to pay a *little* attention to some of the theoretical underpinnings of computer science. (Y'know, the science that explains how these glorious piles of refined sand actually WORK?? You date yourself: Modern CS is merely Java Programming. If you want to learn how to refine the sand, the old textbooks are found in public libraries.) The simple fact is: a lot of the current fad of crapola languages are only around because the coding community (like all of humanity) consists of about 89% idiots.
Most "commercial grade" coders are little better than faeces hurling monkeys randomly bashing at their terminals and making the odd primitive grunt in the machine's general direction. Really, it's an insult for a computer to have to tolerate some of the shit I have seen spewed at them by their neuronally challenged masters. Go away and learn to actually reason about code before you start the "Language X is superior to language Y" pissing competition; otherwise you just look like a pack of nitwits. I can shoot a stream of piss much farther than you can, but that's because I'm standing on top of a mountain. Keep that in mind next time you think it's raining.
And while I'm laying into the status quo:
Now people are naturally stupid, but two things that seem to be making them stupider are Java and OOP. People with prior exposure to either should be considered mentally mutilated beyond all reasonable hope of recovery and should simply be shot on compassionate grounds. Once a simian learns a horrible ugly slow bloated way of doing things that just sort of works maybe, it's very hard to teach them a clean simple elegant way of doing things. If I had my way both Java and OOP would be *banished* from the syllabus in every computer science course the same way heroin is banished from pre-schools.
- God (wrathful) :)
I've been exposed to both OOP and BASIC (about which Ew Dijkstra made the same charge), but I've still managed to unlearn the bad habits that both of those Bad Things encourage. Perhaps Java and OOP should be banished from computer "science" courses (although if you think you're interested in CS you should probably be majoring in EE instead), but exposure to them is a curable illness.
Oh, I just love ripping into tripe like this.
If you don't grasp the ramifications of that then frankly, you are doomed to remain a mediocre coder ... period.
I don't think there is even a single person on this wiki that doesn't grasp the ramifications of this. However, as projects grow in size, and more coders get involved, however great their genius, you will inevitably find that the more free-form the language, the more people complain about not being able to read another's code. This is why there are so many arguments against macros in commercial-scope programming projects. (For the record, I'm pro-macro support, but those who oppose them have valid points too!)
Pretty much the entire point of Lisp and its derivatives is that you can write Lisp programs that manipulate Lisp programs.
Actually, the "point" of Lisp is that it is a conveniently parsable syntax to express and interpret arbitrary lambda expressions in. Macros and their full significance didn't come about until after the first generations of Lisp environments were written.
Added to that (due to lisp's syntactic cleanliness), you can actually *prove* things about a piece of appropriately written Lisp.
Actually, you cannot. Given the following:
(defun headOf (something) (car something))
Invoking headOf with a non-list thing will positively result in some kind of failure. Whether this is correct behavaior depends on the context in which headOf is invoked. In other words, if I don't say it's correct behavior, it isn't. For me. ...which is something you can prove... and since non-EMACS-Lisp is case-insensitive, you might as well call this function headof
This also raises the not-quite-so-small issue of someone (perhaps accidentally) redefining the meaning of car during run-time (perhaps by invoking eval with a dynamically constructed string). You cannot statically prove anything in this situation.
Nonetheless, the fact that Lisp fails utterly to prevent you from invoking it with any arbitrary parameter in the first place, knowing full well that non-list parameters will result in a failure only at run-time, means that you cannot prove statically that this code always works as intended. For static proofs, you MUST employ a strong, static, type system -- something at least as strong as Ml Language's. Perhaps this is implemented outside a language's normal environment (e.g., as a preprocessor that performs type inferencing, for example), but it has to exist.
I do not think that anyone, except God himself, denies this. The questions are when circumstances tend to prefer dynamic typing versus static typing, and how frequently those circumstances appear in "real-world" programming.
Now in theory, you can take a parse tree for a piece of code written in the godawful piece of excrement that is Java, flog yourself senseless distilling it down into something vaguely approaching a set of sexprs (without side effects of course! Good luck!) and try to prove something about that, but why would you want to?
Because Java beat out Lisp in the commercial sector. Because it is a breach of ethics and morals to proactively deny programmers who prefer language X the core technology developed by/for those who prefer language Y. Because the core principles distill into mathematical invariants, which are language independent. Because it makes people money. Need I continue?
Most "commercial grade" coders are little better than faeces hurling monkeys randomly bashing at their terminals and making the odd primitive grunt in the machine's general direction.
Ad hominem attacks won't get you very far here, particularly utterly unfounded ones. While I agree that the commercial sector prefers Disposable Programmers, I've worked with enough of them to know that many are substantially intelligent in their own ways. Lots of Java coding folk choose to work on other projects when they're not working, very often in other, perhaps even more interesting, languages. Don't blame the slave for his master's short-sightedness. Your intolerance blinds you.
otherwise you just look like a pack of nitwits.
No further comment necessary.
two things that seem to be making them stupider are Java and OOP.
Without getting into the merits of these, let me point out that those who think at a different level of abstraction than you are neither stupider nor smarter than you - just different. If you feel that Java and OOP make people stupider, then surely you must have some prior experience with Java and OOP yourself, on which to base this claim on (there certainly is a veritable lack of documented evidence to support your claim otherwise). If this is so, you must yourself be stupider than we first thought; so why should we believe you either way?
People with prior exposure to either should be considered mentally mutilated beyond all reasonable hope of recovery and should simply be shot on compassionate grounds.
False; I have prior exposure and regularly use both Java (for work) and OOP (especially when using C - I don't need C++, thank you very much. Where is your God now?). I also know and promote the use of Haskell, Lisp, and Forth, code in raw x86, 68K, MIPS, 6502/65816, and 6809 machine languages, and have written everything from OS kernels to e-commerce applications.
Oh, by the way, I don't have a degree either. I'm totally autodidactic.
it's very hard to teach them a clean simple elegant way of doing things.
Largely, it is because the adage that computer time is cheaper than programmer time is quite true. As you grow older, particularly into puberty, you'll find this out for yourself.
If the computer gives me a result to some computation or user activity in 0.1s or less, then I'm quite happy, on the whole. On the other hand, if I were to be responsible for writing the core software behind the B-2 bomber, then, yeah, I'd definitely be a bit more attentive to microsecond-resolution performance issues.
There are two ways of defining clean, simple, and elegant. The first way is to think in a clean, simple, and elegant manner. But remember that our central processing units are massively parallel neural nets - the "algorithms" with which our brains work best don't necessarily map as cleanly to a sequential, Von Neumann architecture. There will always be some impedance mismatch in the translation, at any level of abstraction.
If I had my way both Java and OOP would be *banished* from the syllabus in every computer science course the same way heroin is banished from pre-schools.
An interesting, if false, analogy. Pre-schools never banish heroin. Heroin is banished by the United States Code of Federal Regulations (or your nation's equivalent legal documentation). Since this subsumes all state, county, city, town, et al. levels of government, including business government, there is no need to explicitly banish heroin (or any other drug, save prescribed drugs). The only thing schools can do is enforce this Federal (or your nation's equivalent) law.
But, I understand your pain and suffering, and largely agree with what you're trying to communicate.
-- Atheist (smug)
Smug Lisp Weenies: intersects with the set of SmugEmacsWeenies.
Qualifying my opinion with the caveat that I am a relative Lisp n00b, I think it is a plain case of classical snobbery. Lisp is historically significant and its study provides a gateway to other interesting topics, such as the Lambda Calculus and the Curry Howard Isomorphism. In this respect Smug Lisp Weenies are akin to professional musicians who have studied Mozart and Beethoven; they may not take you seriously until you have too.
The proof is in the pudding though. All the, e.g., guitarists who have studied intensely the classical works (both classical music in general, and classical guitar in particular) are so far and above everyone else with an axe that it's not even funny. Steve Howe, Steve Hackett, etc. Contrast these folks with the total tripe (total Java?) coming out on CD and radio today, and their is a substantial difference.
I am a self-taught contemporary guitar player who has also suffered through the humiliating dehumanisation of classical training. I agree with the observation about classical snobbery. My experience is that the classical people look down their noses on everything else, and see nothing of value whatsoever in it. The response mentions, for example, Steve Howe, from Yes, who is undoubtedly great in the contemporary field. However, there are many non-classically trained guitarists who are also great, but in a different way. These are guitarists who may not be particularly technically brilliant, but nevertheless can use the guitar to express strong and deep emotion. They can make their instrument both sing and talk. They can move a crowd. They can excite and uplift. My experience is that the sort of classical training that I was receiving (in a Conservatorium, as a mature-age student) systematically devalues this kind of music. The result is guitarists who may (or may not!) be far and above everyone else with respect to playing scales and arpeggios and holding their hand just so - but are absolute crap when it comes to playing music that anyone cares about. In fact I will go further than that. My experience is that the Conservatorium where I studied seemed to specialise in training guitarists who were scared to perform in public because all their self esteem and confidence had been bullied out of them by their teachers (who were just perpetuating their own versions of classical snobbery).
However, I would say that Lisp has more than just historical or theoretical significance. I have used lots of different languages, including Forth, APL and Lisp. I have only used Lisp for little projects (eg to program my GWM and GWM2 window manager behaviour). I found Lisp to be a very nice language to use, and not particularly difficult to learn. I don't claim to be an expert by any means. The point I am making is that I didn't need to be. It is easy to learn how to do simple things, and I suspect that you can move from there in gradual stages to learning the rest of the language. I doubt very much that anyone ever mastered Java interfaces, generics, annotations and all of the various frameworks and libraries in the first week. Why would you expect to do that with Lisp? On the other hand, the concepts of Code As Data and Ess Expressions, and all of the syntax can easily be learned in a week. To me the importance of learning Lisp is that it does teach you a different way of looking at things and of solving problems. That is not a bad thing! The fact that it can also be used to write software at any level of complexity, and is amazingly expressive and flexible (and some say fun), is just a bonus. Apologies if this link has already been referenced, but I found the following quite enlightening: mitpress.mit.edu (Structure and Interpretation of Computer Programs). It explains how you can use Lisp to model a whole range of linguistic styles (including procedural, functional, logical and object-oriented), emulate a CPU and build a compiler. Not necessarily useful for writing a business application but great Mental Porn if you are into Mental Masturbation. Glenelg Smith.
This is not entirely unreasonable. However, I would be suspicious of any Lisp evangelist who has not researched, for example, www-formal.stanford.edu .
I wasn't even aware of this resource until you provided the link. Yet, I love Lisp. You better be suspicious of me then. I might sneak up behind you and hit you with a car with cdr wood panels! Or, strangle you with a parenthesis? Reference you with a hash? Hmmm...so many choices! :-)
-- J. Jakes-Schauer
First, it was not my intention to frustrate the noble objective stated below so, for some definition of last word, I will do my best to honor his goal.
However I really do want to become a Lisp Weenie even if it does make be smug, but it keeps falling off the low priority of my TODO List. I am thinking that starting with Scheme would be a good idea, as LISP does intimidate me a bit which is why I want to learn it. Good page even if a bit old. I will be stopping by for any hints.
I just wanted to get the last word in on a page that hasn't been edited in a year (it's February 2010 today)
Thank you for the amusing page.
Imagine writing a TEXT EDITOR in LISP!
See: Smug Smalltalk Weenies, Smug Erlang Weenie (Nothing like Smarmy Lisp Weenies), Wiki Warrior, How Can Something Be Super Great Without Producing External Evidence
Just for anyone who might be interested in applications developed with Lisp: Texas Instrument's Derive (computer algebra system used in the TI89, Voyage 200 and its precursors), Reduce, Maxima/Macsyma, Axiom (axiom-developer.org ) and I believe Mathematica, which was mentioned earlier.
See original on c2.com