New Common Lisp website
lisp-lang.org
lisp-lang.org
I'm planning on learning on a purely functional language this year and I've narrowed it down to Haskell and CL but I don't know which to pick. Haskell has sort of been winning due to my friends knowing it and using it.
If you have any resources as well, please let me know. I don't know if this is the right place to post this.
CL is either multi-paradigm language or Lisp paradigm language. There is lisp style programming.
It has many functional primitives but typical CL programmer is not programming functionally. Other languages like Scheme or Clojure are more functionally 'oriented' Lisps.
The most caracteristic feature of Lisp in general is that, its whole syntax is the literal representation of one of it's core datatypes, the linked list. This allows for creating idioms of arbitrary complexity and reusable abstractions with ease, one a tiny kernel.
Another wording of this is that the Lisp family of languages represent their programs as data that those programs directly manipulate, and thus, programs can manipulate themselves. This is homoiconicity.
For who likes laconicisms, Lisp is a pleasant way to write and execute a parse tree.
The advantage to this is that you can create syntactic abstractions that fit in nicely, that work on structured data instead of strings not parsed and verified yet (hey CPP!) and are reusable by other abstractions.
The disadvantage is that your set of abstractions can become very easily dialects, and the language ecosystem is prone to (and damned by) fragmentation (i.e. every Scheme has it's own module system, and then there's a late standard that nobody uses).
Another advantage of Lisp, though not unique to it neither theoretically nor practically, is the image, that is, the state of the interpreter. Your average Lisp process is code running on a Lisp VM, and the VM allows you to modify the running code. This allows you to pause the thread when an exception happens, modify the code, and play it again, and the program uses the new, modified version of the code. These are called restarts and supported at least in Steel Bank Common Lisp, and are well integrated into SLIME, the canonical Emacs mode for Common Lisp and other uncommon (!) lisps. This is so powerfull, I read that in one space mission, when they spotted a bug in the code of a research apparatus already in space, they connected to its image and hotpatched the code fixing the bug, saving NASA millions of dollars.
"Your average Lisp process is code running on a Lisp VM, and the VM allows you to modify the running code"
Thank you. As a non-Lisper, this is probably the clearest explanation of Lisp's qualities I've ever read.
Just for others reading this; this is correct, but note that it is typically not a bytecode based VM like the JVM, but rather running native code.
Haskell is functional in the sense most people think (maths 'n things, functions with no side effects), with a few 'outs' (monads or 'containers' for doing imperative-like things).
If you want a 'functional' language, choose Haskell. If you want a language you can bend to your will, where you'll be making your own abstractions, writing a DSL, etc..., choose Common Lisp. Actually Haskell isn't even bad for that, so if your friends are using Haskell, just try that.
However it is possible in CL to write parts of many programs in a functional style. Further, my functional collections library, FSet [0], greatly expands the amount of code that can be written this way, bringing CL much closer to being a functional language. One FSet user told me that it had changed the way he thinks about programming in CL -- which I think reflects an intellectual transition that is at least a good part of the transition one would hope to make by learning Haskell.
If you do go with CL, you might want to check it out. (It's in Quicklisp as "fset".)
Since we're going for precision, I note that monads have nothing to do with impurity (https://wiki.haskell.org/What_a_Monad_is_not#Monads_are_not_...). It just happens that IO, in which the impurity lives, is a monad. It is also a functor (in the category-theory, not Prolog or C++, sense), but that doesn't make functors impure, and it doesn't make monads impure (or impurity inherently monadic: https://wiki.haskell.org/What_a_Monad_is_not#Haskell_doesn.2...).
> To say it more correctly (hopefully): Haskell contains a purely functional sub-language. It also has impure parts. Just like most programming languages have pure and impure parts. The difference is that Haskell employs the type system to segregate the two parts.
(Anyway I'd be interested in how to access IO without using the IO monad; is there a lower-level type to use instead?)
The CL community in general has some amazingly prolific contributors, though perhaps fewer in number than other languages enjoy. One thing I've always noticed, though, is that the resources out there lack the "glue" to tie everything together. Cliki is definitely one resource that does that, Quicklisp and its doc page (https://www.quicklisp.org/beta/UNOFFICIAL/docs/) is another. Here's something of a motivating example... I wanted to mess around with building a multi-threaded server the other day. I went to Cliki, found usocket and bordeaux-threads, from their descriptions it sounded like they would be a reasonable starting point to build on. The API documentation and tests in their repository for both projects left me scratching my head... Then I started searching for applications that used them and between Cliki and Googling didn't find many great examples. Then I said, well, let's step back and see how Hunchentoot handles its networking layer. Turns out it uses -- wait for it -- usocket and bordeaux-threads.
Maybe it would be helpful to link from the "recommended libraries" (and other topic pages) to projects that use each library? I don't really have any concrete advice, I just feel like one of the things the CL resources out there lack is some layer that ties everything together. Cliki is a great starting point, but it might benefit from more hands.
That's certainly not (not by a long shot) the only place where the scattered CL resources out there could benefit from volunteers. There are untold numbers of things like (https://common-lisp.net/project/common-lisp-beginner/) this floating around that more hands would help.
Sometimes the answer isn't, hey, let me make my own site -- maybe step back and consider whether your efforts could benefit the community more if you lent your time to something that already exists. Just a thought.
It's all good stuff but I would wonder about any language community that hadn't gotten any other big hitters onboard in the last 15 years.
The link is above the 'Tutorials' heading. Maybe it needs some custom style to make it stand out.
For SICP, stick to Scheme. The ideas are valuable in themselves, and IME it’s easier to learn the author’s obscure language than to translate to another language. When you’re struggling to learn something, I prefer not to waste time figuring out whether it’s not working because it wasn’t translated properly or because I made a mistake in the procedure. Especially when SICP uses Scheme’s tail call optimization, which few other Lisps have. Racket is one of the few.
Other than that, it’s just a matter of personal taste and practical considerations. I especially like how Clojure and ClojureScript run well on dominant legacy platforms, the JVM and the browser, but you could choose otherwise.
As for the other Lisps, I think you should give them all a lengthy and serious try. It's worth it.
For Common Lisp, when you have learnt it a bit, get the book Let over Lambda. It's a great bus-ride read and, IMHO, is one of the best Lisp books I've read.
When you get to Clojure, don't be put off by the JVM and the harsh stack traces and unhelpful error messages. Look at the Rich Hickey video presentations and realize Clojure is its own thing. There are lots of smart and practical choices made in Clojure.
I've not had time to give Racket a try yet. But it seems a very nice language with good implementation, docs and community.
This might take a while."
Yeah, that's probably not the message you want to send after all the virtues (e.g. speed) listed on the first page.
[1]: http://www.lispworks.com/documentation/HyperSpec/Front/index...
I don't really see how difficulty porting document sets to a nicer format translates into "This language isn't/doesn't foo", since that's more human error than the fault of the language itself.
And to add insult to the injury, when you actually suffer through those empty marketing slogans, you get down to a big link "Start here" - which unveils a link to few very basic tutorials.
What exactly is the point of such "website"? The information value of this is zero. What a waste of time.
A much better (but not the latest web framework buzzword compliant) resource is this: http://www.lisperati.com/
So no, good marketing isn't an argument for this kind of website, if anything I think it's one against.
Whenever I see this pattern, I usually hit the back button, because it tells me that the site is a waste of time, put together by someone who doesn't critique their own work and has no attention to detail (not that something as enormous as the big, blue, empty first screen is a "detail").
The entire first page could be filled with useful information, key points to get people's attention, show Lisp's advantages, and convince people to give it a try. Instead it's useless, and visitors have to dig through screen after screen to find anything.
Most people will not bother. If they were interested enough to put that much effort into it, they'd probably already be using Lisp.