Related
While reading Peter Seibel's "Practical Common Lisp", I learned that aside from the core parts of the language like list processing and evaluating, there are macros like loop, do, etc that were written using those core constructs.
My question is two-fold. First is what exactly is the "core" of Lisp? What is the bare minimum from which other things can be re-created, if needed? The second part is where can one look at the code of the macros which come as part of Common Lisp, but were actually written in Lisp? As a side question, when one writes a Lisp implementation, in what language does he do it?
what exactly is the "core" of Lisp? What is the bare minimum from which other things can be re-created, if needed?
The minimum set of syntactic operators were called "special forms" in CLtL. The term was renamed to "special operators" in ANSI CL. There are 24 of them. This is well explained in CLtL section "Special Forms". In ANSI CL they are 25.
where can one look at the code of the macros which come as part of Common Lisp, but were actually written in Lisp?
Many Common Lisp implementations are free software (list); you can look at their source code. For example, here for SBCL, here for GNU clisp, etc.
when one writes a Lisp implementation, in what language does he do it?
Usually a Lisp implementation consists of
a lower-level part, written in a system programming language. This part includes the implementation of the function call mechanism and of the runtime part of the 24 special forms. And
a higher-level part, for which Lisp itself is used because it would be too tedious to write everything in the system programming language. This usually includes the macros and the compiler.
The choice of the system programming language depends. For implementations that are built on top of the Java VM, for example, the natural choice is Java. For implementations that include their own memory management, it is often C, or some Lisp extensions with similar semantics than C (i.e. where you have fixed-width integer types, explicit pointers etc.).
First is what exactly is the "core" of Lisp? What is the bare minimum from which other things can be re-created, if needed?
Most Lisps have a core of primitive constructs, which is usually written in C (or maybe assembly). The usual reason for choosing those languages is performance. The bare minimum from which other things can be re-created depends on how bare-minimum you want to go. That is to say, you don't need much to be Turing-complete. You really only need lambdas for your language to have a bare minimum, from which other things can be created. Though, typically, people also include defmacro, cond, defun, etc. Those things aren't strictly necessary, but are probably what you mean by "bare minimum" and what people usually include as primitive language constructs.
The second part is where can one look at the code of the macros which come as part of Common Lisp, but were actually written in Lisp?
Typically, you look in in the Lisp sources of the language. Sometimes, though, your macro is not a genuine macro and is a primitive language construct. For such things, you may also need to look in the C sources to see how these really primitive things are implemented.
Of course, if your Lisp implementation is not open-source, you need to disassemble its binary files and look at them piece-by-piece in order to understand how primitives are implemented.
As a side question, when one writes a Lisp implementation, in what language does he do it?
As I said above, C is a common choice, and assembly used to be more common. Though, there are Lisps written in high-level languages like Ruby, Python, Haskell, and even Lisp itself. The trade-off here is performance vs. readability and comprehensibility.
If you want a more-or-less canonical example of a Lisp to look at which is totally open-source, check out Emacs' source code. Of course, this isn't Common Lisp, although there is a cl package in the Emacs core which implements a fairly large subset of Common Lisp.
I use Emacs everyday as it is the standard editor for Erlang.
I decided as my New Years Resolution to learn to programme eLisp. I decided that writing a book about eLisp was the best way to learn.
I have make pretty good progress:
Learn eLisp For Emacs
The strategic structure of the book is
getting started/basics
more advanced eLisp
writing a minor mode
writing a major mode
I have got through the basics (ie the first of these 4 points), covering:
evaluating expressions
debugging
adding menu items/toolbars
loading your own emacs files
etc, etc
If you are writing a book about a programming language you usually start by knowing the language well - well I don't - so my major problem now is a completeness problem:
How do I know that I have covered all the features that an Emacs programmer should have mastered?
How do I ensure that there aren't gaps in the content?
So I thought I would address these by asking the community here. My question is What Is Missing From My Table Of Contents? (in particular what should the more advanced eLisp Section contain).
Now that's an interesting way to learn a language...
I think you've probably skipped a bunch of the fundamentals in the getting started/basics section. If you've not already read it, I recommend reading "An Introduction To Programming In Emacs Lisp" (at gnu.org), which covers what I'd expect to see in the "basics" portion. I won't bother cut/paste the table of contents.
As far as knowing when you've written a complete book... Well, once you've re-written the Emacs Lisp manual in "how to" form, you know you're done. Alternatively, if you've written a book that can be used to answer/interpret all of the elisp and emacs questions, then you've probably got decent coverage.
What advanced features could you write about? There's advice, process communication, non-ASCII text, syntax tables, abbrevs, text properties, byte compilation, display tables, images, and a bunch more in the manual.
Note: The proper capitalization of elisp is either all lowercase, or possibly an uppercase E. The GNU documentation doesn't use "elisp" very much at all (mostly as a directory name, all lowercase), it prefers "Emacs Lisp."
Note: In the current version of your book, you treat global variables negatively. It's probably worth reading the RMS paper to gain some insight into the design decisions made, specifically on global variables as well as dynamic binding (the latter which you've yet to cover, which is a key (basic) concept which you've already gotten wrong in your book).
Instead of asking the community here, why not use what the community already offers? Review all the questions tagged "elisp" and see where they fit it your book. A survey of what people actually want to understand could be some of the best information you will get.
"I have read both the GNU manuals - but they are not so much use if you don't know Lisp/elisp."
Tip: Emacs is not much use if you don't know Lisp.
Not really true, of course, but you get the idea. This one is really true:
Tip: Emacs is much, much, much, much more useful if you know Lisp. Not to mention more fun.
Wrt what to learn:
symbols (they are simple objects, with properties -- not just identifiers)
lists -- cons cells, list structure (including modification/sharing)
evaluation
function application
regexps
text/overlay/string properties (values can be any Lisp entities)
buffers and windows
I'd suggest you'll take a look what the two Info manuals included with Emacs Emacs Lisp Intro "An Introduction to Programming in Emacs Lisp" and Elisp "The Emacs Lisp Reference Manual" already have to offer and then decide what you would like to add to or do differently than those.
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.