Can someone explain to me the main differences between a language like Common Lisp and Haskell?
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.
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.
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.
As others have mentioned, CL is not a pure functional language like Haskell.
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".)
Common Lisp is functional in the sense of being based on Lambda calculus, but with all sorts of imperative and OO things bolted on.
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.
One of the most important differences is the type system of Haskell vs. the dynamic typing of CL. This is not a trivial distinction and they are quite different ways to program.
You can write purely functional programs in CL, but it's not a purely functional language in the way haskell is, and I think most people don't use it that way.
To say it more correctly (hopefully): Haskell contains a purely functional sub-language. It also has impure parts (provided by monads). Just like most programming languages have pure and impure parts. The difference is that Haskell employs the type system to segregate the two parts.
> 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?)
For anyone reading "functor" and moving on, this (http://www.catonmat.net/blog/on-functors/) is a great post discussing how the term is used in a variety of languages.
I love common lisp. That being said, i feel like this effort might be better spent contributing to modernizing and cleaning up / updating the existing community sites like cliki.net.
Out of curiosity, what would you like to see updated on cliki.net? I wrote cliki2 with Andrey Moskvitin so a lot of the changes from the first cliki ended up being our opinions.
I guess the point I was trying to make wasn't that cliki in particular has any shortcomings, but that more hands on any particular open source effort tend to yield more fruit that those hands spread across as many independent efforts.
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.
I used to work at ITA. I seem to recall Carl admitting at one point that the choice of language had mostly to do with the fact that he and Jeremy were most familiar with Common Lisp, having used it while pursuing their doctoral degrees, and that he probably would have chosen Java in retrospect (this was in 2007). The actual code was not the clean functional code you might expect (and as the email above notes, much of it was also written in C++, half by line count IIRC). In fact, there was interest in parallelizing parts of QPX (the low airfare search engine in question) to speed up search, but it was not amenable to such changes without first having to untangle a bunch of single threaded side effecting code and without incurring penalties in performance or resource consumption.
Not sure if bug, but the right curly double quotes in the CL snippets bother me way more than they probably should. In the source, it's simply a " character, so the CSS is likely conflicting somewhere.
I love (sarcastically) how the Start here -> First Steps does not include any instructions on how to get a Common Lisp installed and running on your computer.
Learning Scheme with SICP right now, and there's a question I'm now pondering: how does one choose between Common Lisp, Scheme, Racket, Clojure and others? Is there a good comparison of Lisp-derived languages somewhere?
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.
There are many comparisons online, but opinions are cheap, so I will offer mine.
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.
Put up a pdf (if you have TeX you can get a pdf), but don't make some technical argument that makes you sound slow. This is marketing not a technical talk.
The CLHS[1] they mentioned has been available online for ages. What they're talking about is making a more modern site. Generating a PDF from the spec wouldn't get them any closer to that goal.
Then don't put a specification link on the home page and wait until it is done. The text is non-helpful to marketing the language particularly when books are actually available and linkable that can be read now.
IIRC the legal situation of the hyperspec is a bit weird and converting to other formats could be problematic. (Perhaps someone else may be more precise)
It's an extremely large language, with most of the things that are normally availible as libraries, defined as part of the language itself. So of course the conversion is going to take a while, especially if the input data isn't very well formatted.
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.
I hate the current trend for websites to have about a page's worth of information spread over about eight pages' worth of space. I'm used to seeing it on startup websites, where it doesn't bother me so much because I expect those to be trendy. But I'm recently seeing it infect websites of old school geek projects that I feel should know better. This is one example and the new emacs website a few days ago was another.
I'll allow it. Lisp in general (and Common Lisp in particular) desperately needs better marketing, which unfortunately is susceptible to the vagaries of fashion. If dressing it up a little makes it more attractive to the next generation, then mission accomplished.
Sorry, but a "website" which is basically a set of powerpoint slides in Javascript is certainly not going to help "market" anything.
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/
You may have found it to be a waste of time, but I thought it was a pretty good introduction. Probably the furthest I've gotten into Common Lisp over the past ten years or so.
The problem is not that it's flashy but that it's hard to use. You have to accidentally scroll because the site is designed to hide the fact that there's more content at the bottom. At first glance it's a huge blue rectangle with a big "Common Lisp" in the middle, no other information. It's the kind of website someone who isn't already really motivated might just close because they can't immediately figure out how to proceed.
So no, good marketing isn't an argument for this kind of website, if anything I think it's one against.
I can almost see your point, but these days I think most people who are interested in programming languages know to scroll, and that doesn't seem particularly onerous to me. Granted, they probably should make it a little more obvious, but it's not that bad.
Seriously, the entire first screen is empty space and "Common Lisp". Haven't these people heard of "the fold"? Please, someone, anyone, tell me what the point is of having no information on the entire first screen. This is a web page, not a PPT with an intro slide!
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.
