Related
In the article Technical Issues of Separation in Function Cells and Value Cells, Kent Pitman and Richard Gabriel explains the decision of making Common Lisp a Lisp-2:
There are two ways to look at the arguments regarding macros and namespaces. The first is that a single namespace is of fundamental importance, and therefore macros are problematic. The second is that macros are fundamental, and therefore a single namespace is problematic.
According to that, when programming macros, a single namespace in macro programming is inherently problematic.
But Clojure's approach is a little bit different: the backquote does namespace resolution.
In chapter 9 of the book On Lisp, Paul Graham talks about avoiding variable capture by separating code in packages:
However, packages do not provide a very general solution to the problem of
capture. In the first place, macros are an integral part of some programs, and it
would be inconvenient to have to separate them in their own package. Second,
this approach offers no protection against capture by other code in the macros
package.
As far as I can see, Clojure's solution to variable capture looks like the packaged option showed by Paul Graham.
One of the major drawbacks pointed by Paul Graham is that it would be inconvenient to separate macros in different packages, but Clojure's backquote does it automatically, by prepending the namespace of the symbol, right?
So, is it a complete solution to variable capture? Or Kent Pitman's words still apply? If there is any problem that Common Lisp's separeted namespaces can handle that Clojure cannot, could you write down an example?
I have never encountered a limitation with Clojure's macro system. It's a fully general macro system, and to my knowledge it is exactly comparable with Common Lisp in terms of fundamental capabilities.
There are obviously many syntactical differences, but I think they are mostly superficial and don't affect the expressive power that you can achieve with macros.
My view is that Clojure gets a lot of design aspects right here:
Lisp-1 is simpler and conceptually clearer than Lisp-2, particularly in a functional language where you actually need to treat functions as first class values.
Symbol capture generally isn't a problem - the Clojure syntax quote and namespace system do a good job of making macros both usable and readable.
As a final comment, the summary of the linked article is quite illuminating:
The bulk of arguments that focus on clean semantics and notational
simplicity tend to favor uniting the function and value namespaces..... We feel that the time for
such radical changes to Common Lisp passed, and it would be the job of
future Lisp designers to take lessons from Common Lisp and Scheme to
produce an improved Lisp.
In my humble view - Clojure is a good example of an "improved Lisp".
I am a pretty experienced Ruby, Objective C, and Java programmer and I was watching a video on emacs (because I have been using Vi) and noticed that it is also a LISP interpreter. That spiked my interest, and brought up an interesting question: For someone that knows modern high level languages such as Ruby, Java ,and Objective C, is there any practical benefit to learning LISP? Would I gain anything by setting aside some time to learn LISP or not? I would like to hear what you guys have to say. Thanks.
There are definitely benefits to learning a language built on a different paradigm from the one you are used to (which I note are merely object oriented with strong imperative roots). LISP is the granddaddy of functional languages (one of my favourites, Scheme, is a LISP dialect).
Besides widening your horizons, functional languages and constructs are highly likely to grow further in importance as a reasonably straightforward way of using multi-core hardware efficiently.
LISP as such might not be my recommendation to start with, since it's enormously fragmented: on the other hand, there's a lot of history, and you can make use of it directly if you plan on moving to Emacs.
Lisp, in a sense, is the logical extension of von Neumann's revelation that "code is data is code".
The things figured out in Lisp before 82 or so are still working their way into mainstream programming languages like C# and Python. Due to the reasonably uniform Lisp syntax, they probably won't ever get all the way in with the ease of using them in Lisp.
Things like:
dynamic typing -- Possibly a Lisp invention, possibly smalltalk. Not sure.
object orientation -- mooched from Smalltalk by Lisp I think
reflection -- C# just got this one
DSLs in-language -- hello Linq.
macros -- a few ultra-researchy languages have these now besides Lisp
compilation in the interpreter -- never heard of other languages having this one
And other stuff I can't think up on the fly.
I suggest you get hold of a good Lisp book (they abound on the web) and try some Lisp yourself. You will be amazed to find that this 50 year old language is so "modern" and in some respect, way ahead of other "modern" languages. (For instance, find out why Lisp is called the programmable programming language). If you are too lazy to actually try some Lisp code yourself, read this and this.
Watch some of these: http://groups.csail.mit.edu/mac/classes/6.001/abelson-sussman-lectures/
Learning Lisp per se isn't particularly practical, but it will make you a better programmer as you can apply the understanding you gain to languages you think you already know.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
To begin, not only are there two main dialects of the language (Common Lisp and Scheme), but each of the dialects has many individual implementations. For example, Chicken Scheme, Bigloo, etc... each with slight differences.
From a modern point of view this is strange, as languages these days tend to have definitive implementations/specs. Think Java, C#, Python, Ruby, etc, where each has a single definitive site you can go to for API docs, downloads, and such. Of course Lisp predates all of these languages. But then again, even C/C++ are standardized (more or less).
Is the fragmentation of this community due to the age of Lisp? Or perhaps different implementations/dialects are intended to solve different problems? I understand there are good reasons why Lisp will never be as united as languages that have grown up around a single definitive implementation, but at this point is there any good reason why the Lisp community should not move in this direction?
The Lisp community is fragmented, but everything else is too.
Why are there so many Linux distributions?
Why are there so many BSD variants? OpenBSD, NetBSD, FreeBSD, ... even Mac OS X.
Why are there so many scripting languages? Ruby, Python, Rebol, TCL, PHP, and countless others.
Why are there so many Unix shells? sh, csh, bash, ksh, ...?
Why are there so many implementations of Logo (>100), Basic (>100), C (countless), ...
Why are there so many variants of Ruby? Ruby MRI, JRuby, YARV, MacRuby, HotRuby?
Python may have a main site, but there are several slightly different implementations: CPython, IronPython, Jython, Python for S60, PyPy, Unladen Swallow, CL-Python, ...
Why is there C (Clang, GCC, MSVC, Turbo C, Watcom C, ...), C++, C#, Cilk, Objective-C, D, BCPL, ... ?
Just let some of them get fifty and see how many dialects and implementations it has then.
I guess Lisp is diverse, because every language is diverse or gets diverse. Some start with a single implementation (McCarthy's Lisp) and after fifty years you got a zoo. Common Lisp even started with multiple implementations (for different machine types, operating systems, with different compiler technology, ...).
Nowadays Lisp is a family of languages, not a single language. There is not even consensus what languages belong to that family or not. There might be some criteria to check (s-expressions, functions, lists, ...), but not every Lisp dialect supports all these criteria. The language designers have experimented with different features and we got many, more or less, Lisp-like languages.
If you look at Common Lisp, there are about three or four different active commercial vendors. Try to get them behind one offering! Won't work. Then you have a bunch of active open source implementations with different goals: one compiles to C, another one is written in C, one tries to have a fast optimizing compiler, one tries to have some middlle ground with native compilation, one is targeting the JVM ... and so on. Try to tell the maintainers to drop their implementations!
Scheme has around 100 implementations. Many are dead, or mostly dead. At least ten to twenty are active. Some are hobby projects. Some are university projects, some are projects by companies. The users have diverse needs. One needs a real-time GC for a game, another one needs embedding in C, one needs only barebones constructs for educational purposes, and so on. How to tell the developers to keep from hacking their implementation.
Then there are some who don't like Commmon Lisp (too big, too old, not functional enough, not object oriented enough, too fast, not fast enough, ...). Some don't like Scheme (too academic, too small, does not scale, too functional, not functional enough, no modules, the wrong modules, not the right macros, ...).
Then somebody needs a Lisp combined with Objective-C, then you get Nu. Somebody hacks some Lisp for .net. Then you get some Lisp with concurrency and fresh ideas, then you have Clojure.
It's language evolution at work. It is like the cambrian explosion (when lots of new animals appeared). Some will die, others will live on, some new will appear. At some point in time some dialects appear that pick up the state of art (Scheme for everything with functional programming in Lisp in the 70s/80s and Common Lisp for everything MacLisp-like in the 80s) - that causes some dialects to disappear mostly (namely Standard Lisp, InterLisp, and others).
Common Lisp is the alligator of Lisp dialects. It is a very old design (hundred million years) with little changes, looks a little bit frightening, and from time to time it eats some young...
If you want to know more, The Evolution of Lisp (and the corresponding slides) is a very good start!
I think it is because "Lisp" is such a broad description of a language. The only common thing between all the lisps that I know is most things are in brackets, and uses prefix function notation. Eg
(fun (+ 3 4))
However nearly everything else can vary between implementations. Scheme and CL are completely different languages, and should be considered like that.
I think calling the lisp community fragmented is like calling the "C like" community fragmented. It has c,c++,d,java,c#, go, javascript, python and many other languages which I can't think of.
In summary: Lisp is more of a language property (like garbage collection, static typing) than an actual language implementation, so it is completely normal that there are many languages that have the Lisp like property, just like many languages have garbage collection.
I think it's because Lisp was born out of, and maintains the spirit of the hacker culture. The hacker culture is to to take something and make it "better" according to your belief in "better".
So when you have a bunch of opinionated hackers and a culture of modification, fragmentation happens. You get Scheme, Common Lisp, ELISP, Arc. These are all pretty different languages, but they're all "Lisp" at the same time.
Now why is the community fragmented? Well, I'll blame time and maturity on that. The language is 50 years old! :-)
Scheme and Common Lisp are standardized. SBCL seems like the defacto open source lisp and there are plenty of examples out there on how to use it. It's fast and free. ClozureCL also looks pretty darn good.
PLT Scheme seems like the defacto open source scheme and there are plenty of examples out there how to use it. It's fast and free.
The CL HyperSpec seems as good as the JavaDoc to me.
As far as community fragmentation I think this has little to standards or resources. I think this has far more to do with what has been a relatively small community until recently.
Clojure I think has a good chance to become The Lisp for the new generation of coders.
Perhaps my point is a very popular implementation is all that is required to give the illusion of a cohesive community.
LISP is not nearly as fragmented as BASIC.
There are so many dialects and versions of BASIC out there I have lost count.
Even the most commonly used implementation (MS VB) is different between versions.
The fact that there are many implementations of Common LISP should be considered a good thing. In fact, given that there are roughly the same number of free implementations of Common LISP as there are free implementations of C++ is remarkable, considering the relative popularity of the languages.
Free Common LISP implementations include CMU CL, SBCL, OpenMCL / Clozure CL, CLISP, GCL and ECL.
Free C++ implementations include G++ (with Cygwin and MinGW32 variants), Digital Mars, Open Watcom, Borland C++ (legacy?) and CINT (interpreter). There are also various STL implementations for C++.
With regards to Scheme and Common LISP, although admittedly, an inaccurate analogy, there are times when I would consider Scheme is to Common LISP what C is to C++, i.e. while Scheme and C are small and elegant, Common LISP and C++ are large and (arguably) more suited for larger applications.
Having many implementations is beneficial, because each implementation is optimal in unique places. And modern mainstream languages don't have one implementation anyway. Think about Python: its main implementation is CPython, but thanks to JPython you can run Python on the JVM too; thanks to Stackless Python you can have massive concurrency thanks to microthreads; etc. Such implementations will be encompatible in some ways: JPython integrates seamlessly with Java, whilst CPython doesn't. Same for Ruby.
What you don't want is having many implementations which are incompatible to the bone. That's the case with Scheme, where you can't share libraries among implementations without rewriting a lot of code, because Schemers can't agree on how to import/export libraries. Common Lisp libraries, OTOH, because of standardization in core areas, are more likely to be portable, and facilities exist to conditionally write code handling each implementation's peculiarities. Actually, nowadays you may say that Common Lisp is defined by its implementations (think about the ASDF package installation library), just like mainstream languages.
Two possible contributing factors:
Lisp languages aren't hugely popular in comparison to other languages like C/C++/Ruby and so on - that alone may give the illusion of a fragmented community. There may be equal fragmentation in the other language-communities, but a larger community will have larger fragments..
Lisp languages are easier than most to implement. I've seen many, many "toy" Lisp implementations people have made for fun, many "proper" Lisp implementations to solve specific tasks. There are far more Lisp implementations than there are, say, Python interpreters (I'm aware of about.. 5, most of which are generally interchangeable)
There are promising projects like Clojure, which is a new language, with a clear goal (concurrency), without much "historical baggage", easy to install/setup, can piggyback on Java's library "ecosystem", has a good site with documentation/libraries, and has an official mailing list. This pretty much checks off every issue I encountered while trying to learn Common Lisp a while ago, and encourages a more centralised community.
My point of view is that Lisp is a small language so it is easy to implement (compare to Java, C#, C, ...).
Note: As many comment that it is indeed not that small it miss my point. Let me try to be more precise: This boll down to the entry point price. Building a VM that compile some well know mainstream language is quit hard compare to building a VM that deal with LISP. This would then make it easy to build small community around a small project. Now the library and spec may or may not be fully implemented but the value proposition is still there. Closure it a typical example where the R5RS is certainly not in the scope.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I picked up a LISP book at a garage sale the other day and was just wondering if it was worth spending some time on.
Yes. I'll stick to Common Lisp, here, though Scheme is also a superb language that has a lot to recommend it.
In Common Lisp, you have a largish multi-paradigm language that provides some things that either don't exist widely outside the Lisp family of languages, or are limited to CL and even more obscure/niche languages.
The first feature, which you can get in one way or another from CL, Scheme and quite a few other dialects, is a real macro system.
I say "real" because the system is much more complete, flexible and reliable than, say, C preprocessor macros. It's extremely difficult to get CPP macros to do even simple things (like swapping the values of two variables, or making a foreach construct) in a reliable fashion, but these are trivial with Lisp macros. This turns out to be a very powerful tool for introducing new abstractions and dispensing with "boilerplate" code.
The second feature, which is effectively limited to Common Lisp, is CLOS, the Common Lisp Object System. Despite the name, it's not a conventional OO system like that of Java with methods being part of a class's definition. Instead, it provides polymorphism through "generic functions" which are what methods are attached to, and by default allow you to do multiple dispatch.
I vastly prefer CLOS to the more usual approach to object orientation, as it makes a number of "patterns" (like the Visitor pattern) completely unneccessary and because extension of existing generic functions is so easy; others loathe it because it takes an extremely cavalier approach to encapsulation and because extension of generic functions becomes arguably too easy. Either way, CLOS is different enough that I think it's worth learning just for the different perspective it provides.
The third feature, which is available outside of Lisp but still fantastic if you've never experienced it before is dynamic, interactive programming. CL debuggers tend to be extremely powerful tools, and CL provides for dynamic definition and redefinition of functions, classes and methods, all of which dramatically improves one's ability to explore a problem, test solutions of that problem and its subproblems, and finally put together a program that works correctly and efficiently.
Lastly, for a lot of classes of problems, Lisp is a great practical language. It provides good performance (usually not as fast as C, but dramatically faster than most "scripting languages"), safety, automatic memory management, a decent "standard library" of functions and tremendous opportnities for easy extension.
It is worth learning for "mind-expansion" purposes but not so popular for building apps these days.
However, it is powerful, and mature, and there are fast and free compilers out there. So there is no reason not to choose it for a program if you like.
The way in which Lisp treats data structures and program structures the same offers amazing power which is worth understanding.
Its history is fascinating and it has shaped the world of computer science.
Be sure to check out Ableson and Sussman's Structure and Interpretation of Computer Programs at MIT OpenCourseware
Clojure: a Lisp on .NET and Java VMs
GNU CLISP.
CMU Common Lisp
Depends on the book. Which book?
Common Lisp is worth learning today because it's one of the few languages that pretty much "does everything". If there's some mainstream or obscure programming idiom or technique, odds are Common Lisp has it already in some form. About the only thing CL lacks is continuations (many argue it doesn't need them, but that's not helpful if you want to explore them).
Anyone spending any serious time writing in Common Lisp will come out Changed in some way, typically for the better, IMHO.
Even if you can't carry all of the Lispy concepts you learn and use in to other environments, knowing about them and how they work is still useful.
Good programmers expose themselves to as many different programming paradigms as they can - not as many programming languages as they can.
The LISP family (there are several variants) is very worth while getting to know. Your objective should be getting your head wraped around functional programming and the lambda calculus - the paradigm that LISP is based on. Focus less on becomming an "ace" LISP programmer (that could take years).
If you find functional programming "flips your switch", try having a look at PROLOG too - here the paradigm is based on evaluation of Horn Clauses (predicate logic).
I may have spent the last 20 years earning a living as a COBOL programmer (OMG - they still have those!), but I think I am a better programmer because of the time spent learning what LISP, and a number of other programming languages were really all about.
Have a blast...
Here's a Google Tech talk worth watching about a company currently producing large, complex software for the airline industry in Common Lisp:
Lisp for High-Performance Transaction Processing (The video is now unavailable. Here's some note by Zach Beane.)
Other topics are mentioned in that video, including Clojure, a new variant of Lisp for the JVM (some work is now being done to develop Clojure for the CLR too, but that is not as far along), which is worth checking out for the way it addresses concurrency issues. See the Clojure site at:
http://clojure.org/
and, in particular at first, check out the link in the upper right on that page to some excellent Screencasts with overviews of the concurrency issues and Clojure features.
If you get interested in Lisp, and the book you found is not that great (I have an old one myself that didn't do much for me), Paul Graham's book On Lisp is available free at http://www.paulgraham.com/onlisp.html and is very good. The general Lisp idea is the same for Common Lisp or Scheme or Emacs Lisp or Clojure, but the specifics will be different - so keep that in mind if reading Graham's book, which focuses mostly on Common Lisp (with some mentions of Scheme specifics.) On Lisp is probably not the best beginner book, but it's worth going through it and just skimming over specifics you're not ready to follow in detail yet to see what is there, particularly with regard to macros, which On Lisp really explores.
One benefit of Lisp is that you develop an appreciation for prefix and wonder why everyone else in the world doesn't us it too (like with Latex or vim)
+ 1 2 3 4 5 6 7 8 9
is much easier to code/edit/paste than
1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9
See this question, and especially the third answer, the one that explains that Lisp is good for solving complicated problems, those problems that are hard to decompose into more manageable modules if you were to try to solve them in another language. In other words, if you are keen on exploring ways to solve convoluted problems, that involve, let's say Natural Language Processing, or Knowledge Aggregation... then, yes, Lisp might just be useful to you.
Learn lisp to learn about macros, and that code is data, and to learn that you can reach enlightenment w/o the self-flagellation of C++.
Learn Common Lisp to learn about reader macros and compiler macros. I don't know any other language that has them.
Learn scheme for continuations.
Learn Clojure because it's going to make Java obsolete :-)
It (Common Lisp) is still heavily used by academics working in Artificial Intelligence. Scheme is a Lisp-like language used by many (most?) CS departments as well. Personally I think learning Lisp is worthwhile whether or not you end up using it. It's a classic language that we've learned a great deal from over time.
Learning LISP is a good way to learn functional programming effectively, and is often used as an introductory language for undergraduate students. Many people feel that Structure and Interpretation of Computer Programs, which uses the Scheme dialect of Lisp, is a book that should be on every programmers shelf.
Paul Graham has been a big proponent of Lisp, and in his book, Hackers and Painters, he describes how he used the power of Lisp to dominate the competition in creating ViaWeb for Yahoo Stores.
Elsewhere, I've seen Lisp dialects used prominently in the aerospace industry, as scripting tools for integration frameworks like Comet, and AML. Lisp will always be tied to the early AI experiments in the 1950's.
As other have alluded to, Lisp isn't that popular anymore for general programming, and it definitely (IMO) has some major problems for writing real systems in, but of course others disagree (for instance much of ITA's software is written in Lisp, and they make crazy bank).
Even if you never write a 'real' program in Lisp, it is absolutely worth learning. There are many programming techniques originally pioneered in Lisp that, knowing them, will help you write better code in Python, Perl, Ruby, ML, Haskell, and even C++. For instance, check out Higher Order Perl, which shows how to do all kinds of amazing tricks in Perl; to quote the introduction "Instead of telling you how wonderful Lisp is, I will tell you how wonderful Perl is, and in the end you will not have to know any Lisp, but you will know a lot more about Perl. [...] Then you can stop writing C programs in Perl. I think you will find it to be a nice change. Perl is much better at being Perl than it is at being a slow version of C."
And there are some great books out there that use Lisp, and it will be easier to understand them if you know the language - SICP, Norvig's Paradigms of Artificial Intelligence Programming, and The Reasoned Schemer all come to mind as must-reads.
Some people here are recommending Clojure. While I would say that Lisp in general is good, I would caution against Clojure, at least for beginners. This is not out of any difficulty using Clojure, just in the fact that Clojure is gratuitously inconsistent with Common Lisp and Scheme. If you want JVM integration, use Armed Bear Common Lisp: https://common-lisp.net/project/armedbear/ , though for general use, I would recommend Steel Bank Common Lisp: http://www.sbcl.org/
This is like questioning if "it's worth to learn C these days of web programming?". Only you can decide if it's worth. What you have to ask yourself is: what am I trying to achieve reading the book?
Learning new languages sometimes aren't useful in the practical sense of things (maybe you're aren't going to use LISP ever in your life), but in the long term it's going to be useful because of the knowledge acquired by different paradigms you aren't too familiar with - and you could use some of you learned in what you already use today.
It's been awhile since university, but after I took a 3rd year CS course that required learning Lisp and writing Lisp programs, writing and thinking recursively was a snap. Not that I had problems with recursion before the course, but afterwards, it was 2nd nature. I also used CLOS in the course (University of Toronto), but it was so long ago, I barely remember what I did.
I've read JRM's Syntax-rules Primer for the Merely Eccentric and it has helped me understand syntax-rules and how it's different from common-lisp's define-macro. syntax-rules is only one way of implementing a syntax transformer within define-syntax.
I'm looking for two things, the first is more examples and explanations of syntax-rules and the second is good sources for learning the other ways of using define-syntax. What resources do you recommend?
To answer your second question: syntax-case is the other form that goes inside define-syntax. Kent Dybvig is the primary proponent of syntax-case, and he has a tutorial on using it [PDF].
I also read the PLT Scheme documentation on syntax-case for a few more examples, and to learn about the variation in implementation.
The JRM Syntax-rules primer is quite good, but Chapter 36 of Programming Languages: Application and Interpretation, by Shriram Krishnamurti http://www.cs.brown.edu/~sk/Publications/Books/ProgLangs/) also has good coverage of writing Scheme macros. That material has been used and improved over several short articles, tech reports, etc, over the past 10 years, so it's not a 'this was true about the X implementation of Scheme in 1983 that is no longer accessible' paper.
The list of resources at The Scheme Cookbook is a great place to start.
If you prefer papers, then don't hessitate to visit readscheme.org.
Fear of Macros is a practical guide for using macros in Racket. It shows many ways of using define-syntax. The material may not be completely applicable to Scheme, but you might find some of the examples useful for knowing what can be done.