There, I said it.
It's free online and is going to be published by No Starch eventually. Hope you find it useful!
(there are some formatting errors though, like unresolved org-mode symbols)
I've been trying to find and fix the formatting errors. I think most of them are fixed by now. At least, I hope so!
I personally find it more enjoyable to use than things like C. Then again, for one historical reason or another, C-type languages won, and nowadays are the easiest path to making software, since you'll inevitably have to interact with an OS, window toolkit, libraries, etc..., that all have a C/C++ interface...
How much did 'they' pay you to say that? :D
But seriously Lisps are by far the most advanced programming languages. They just take a huge amount of effort to learn.
I wish.
Seriously though, most modern languages have Lisp features. Even Java 8 will get Lambdas. Quite a few languages have macros. Many languages have eval and REPLs.
Right now I'm playing around quite a bit with Haxe. Cool language, static typing (w/ type inference), pattern matching, closures, macros, and compiles to half a dozen languages and nearly every platform known to mankind...
I use CL in my day job and would find it highly painful if I did not have all the editing tools I use. Basic things like auto closing parenthesis; this makes the whole I need to balance my parenthesis issue disappear, coupled with transforming existing symbolic expression.
Just curious, what kind of things do you do with CL at work? I'm always interested in how people use less-common languages :)
"Please don't assume Lisp is only useful for Animation and Graphics, AI, Bioinformatics, B2B and E-Commerce, Data Mining, EDA/Semiconductor applications, Expert Systems, Finance, Intelligent Agents, Knowledge Management, Mechanical CAD, Modeling and Simulation, Natural Language, Optimization, Research, Risk Analysis, Scheduling, Telecom, and Web Authoring just because these are the only things they happened to list." --Kent Pitman
The modelling is done in MatLab but the automated experimentation platform is all CL.
It's hard to appreciate the elegance of the language before experiencing years of pain working with others. I have similar feelings about learning Haskell (and not appreciating it) in college.
I took a class centered around SICP my first term in college, and it was an incredibly enlightening experience.
IIRC Richard Stallman also has a story about secretaries at MIT using Lisp for basically the same reason.
The quote your referring to is part of his statement exposing the imbalance of the the educational system within the US in the 80's. Here is the quote which also came from the first announcement to his emacs editor under the tag /Blue Sky/:
When large numbers of nontechnical workers are using a programmable editor, they will he tempted constantly to begin programming in the course of their day-to-day lives. This should contribute greatly to computer literacy, especially because many of the people thus exposed will be secretaries taught by society that they are incapable of doing mathematics, and unable to imagine for a moment that they can learn to program. But that won't stop them from learning it if they don't know that it is programming that they are learning!
I'm a sucker for punishment, so after my first (bad) taste of LISP, I took an AI course that was 100% LISP. My AI teacher studied under McCarthy at Stanford, so I probably can't blame him for anything.
(-> 3 (+ 6) (* 7) (/ 12))
or (just an example, fictional names)
(->> object reflector fields (map :balance) (filter #(> % 1000))
Which reads like (pseudo language)
object.reflector().fields().map(:balance).filter(field -> field > 1000)
I've seen a few old AI books where Lisp code is formatted unreadably. I wonder why.
[1] http://www.cavalierdaily.com/article/2002/01/cheating-scanda...
Seems like there are counterexamples here: http://www.nyx.net/~gthompso/quine.htm
Furthermore, it's possible to encode another programs' code into a single print statement, thereby writing one piece of code with another. As that's trivial, I suspect he meant something else. What was it? :).
Reasonably simple illustration: in Common Lisp, it is possible to write a function that takes a mathematical expression as an argument and returns another expression, as its derivative.
So basically I can write (pseudo-lisp-ish):
(defun diff (f) ... )
then call it like this:
(diff '(+ (pow x 2) x)
and I'd get the expression
(+ (* 2 x) 1)
as a result. The point is, however, that this expression is Lisp-callable code. If I already have a function p, I can write:
(setq dp (diff p))
and dp is now the function computed by (diff p).
This is not necessarily the most practically-useful example, but I think it's closest to being a strong illustration of the principle. In a nutshell, you can do symbolic manipulation with code from within your code.
Edit: I just read your other post from this thread. It's important to note that this happens at runtime, not at compile time.
This isn't impossible to do in C if you really want, but it wouldn't be portable (the reason for this is left at the user's discretion). Think about how you would do the same in C: write a function that takes a pointer to a function f, and returns a pointer to another function g, so that g is the derivative of f. It's obviously ok to restrict f to common mathematical operators.
I can think about ways of doing it, but it ain't pretty.
See Greenspun's tenth rule of programming.
Yes, of course. The language, being non-homoiconic, would require you to translate between a data representation that you can process and the data representation that the runtime can process.
However, if you were to do the equivalent thing -- that is, obtain the derivative based on the data representation that your runtime can process -- you'd have to examine the contents of the program memory itself. Needless to say, that would make things even unportable, or outright impossible due to compiler optimizations. But it would be the same thing :).
Edit: perversity bonus, you're working on a computer that does bank switching and the code that is computing the derivative is in a different memory bank than the function whose derivative it must compute.
After all, anything is "possible" with hand-written assembly code, too, but realistically speaking, it's not practical.
My ears perked up at the dual statement that although you can write a Lisp program that writes Lisp programs, nobody does it (um, macros?); and that you can't write a C program that writes a C programs (okay, maybe nobody does this, but you certainly can). I guess he means that C is not "aware" of its own constructs the way that Lisp is.
Also, he said that the algebraic languages were "dying out", but that because of this self-generating ability (which nobody uses), that the future of Lisp was "open".
Huh?
You can't do it in C unless you also implement a compiler or evaluator. And even then generating any sort of reasonably complex C code with C would be highly painful to say the least.
You can possibly nearly get there with C macros but I would argue it's not C writing C there, rather a text preprocessor.
Someone else already did that work. Your C compiler is very likely, in fact, already written in C. We don't expect a C-importable library interface for the C compiler, because none of the traditional old C compilers had one (gcc, MSVC, etc.) But libclang exists, and it's pretty easy to write a C REPL using it. From there, only a few steps to automation.
Also, because Lisp code is data rather than strings (code is represented as linked lists) it's much simpler to manipulate code in Lisp macros.
Also, historical context matters, in the late 50s I believe this was very foreign to how machines were seen and used.
