In regard to getting up and running in Windows, the smoothest FOSS alternative is Lispcabinet. It allows multiple Lisps to be installed (e.g. it will install Clisp, closure, and sbcl), it integrates all of them with SLIME, and installs GNUemacs along with many useful utilities. It is about as painfree as anything which requires learning Emacs can be.
LispIDE is another Windows option. It is very minimal but doesn't require dealing with emacs.
The big problem with libre Lisp is Emacs. I love it to death - most of my time on the computer is spent in Emacs, but a great deal of people absolutely hate it.
One tool that got some love at one point was Cusp, a Lisp plugin for Emacs. Unfortunately, as I note here[1], it's been unloved for some time.
The problem with SLIME: A programmer wants to learn Lisp, now he has two things to learn. Lisp and Emacs. That's what is good about LispIDE. It's very lightweight (and being lightweight is also a disadvantage).
I no longer feel lost in Emacs. I was able to anchor it to my background with AutoCad - and there are huge architectural similarities between Emacs and pre-Windows versions of AutoCad. Both have a command driven interface.
The difficulty with the Emacs tutorial is that it is written around social mores. Thus it teaches the shortcuts which distinguish emacs community insiders from outsiders [1]. Yes, no sane experienced Emacs user will type:
You meant Eclipse, obviously. But I'm not sure that is a good platform for a lisp IDE, cusp probably became abandonware for a reason. Perhaps something half usable can be done with sublime?
You know, Sublime Text integration might be possible. But Eclipse is, as near as I can tell, the canonical mainstream GUI IDE. I think getting Swank(SLIME) integrated into a mainstream IDE would add to Common Lisp's usability for the non-command-line crowd by leaps and bounds.
I see the computing world as fundamentally bimodal: people trend hard towards GUIs and mice or they trend hard towards CLIs and keyboards. Common Lisp's development environment is built by and for the second crowd. You might call them... hackers. :-) But I would dearly love to see the non-hacker computing world walk in the wonders of Lisp. I've attempted to teach several people Lisp, and the development environment is, hands down, the major stumbling point (after the parentheses whining is finished with). This is a major barrier to getting people onboarded. I suppose that means I should try to get Cusp/lispdev compiling this weekend and see what state its in. :-)
Other barriers include no modern GUI library[1]; no popular webapp framework[2], no single point of contact for the language, and a lack of a flagship thing to raise the flag around (Ruby/Rails, Python/NumPy|Django, Clojure/not-java, etc).
[1] The libraries that exist are fairly thin bindings over QT, SDL, and TK. They are far behind the sleek usability of, say, Clojure's seesaw or the even clunkiness of C# autogenerated code.
I have a question to all LISPers out there. It's just, cause I really don't know. I read a bit about LISP, but never used it or anything. Anyway. Here it is:
LISP (or Lisp) is a family of languages, not a single language. There are two main categories of Lisp dialects, the Lisp-1s and the Lisp-2s. Scheme is a Lisp-1.
Scheme is itself not a single language; it's a subcategory of Lisps. The main Scheme standard these days is R6RS (http://www.r6rs.org/), but different implementations may or may not comply with R6RS (Racket does not, for example, even though it was formerly known as PLT Scheme).
Common Lisp is the most well-known Lisp-2, and is what's generally implied when people say 'Lisp', even though that's technically a sloppy use of terminology.
Clojure is another dialect, but people generally specify Clojure and Scheme by name when referring to them. There is no logic behind these nuances of the terminology and their inconsistent usage; it's just what's evolved over the last 50+ years.
So, to answer your question, there's no reason why one should learn Scheme over Common Lisp (or vice versa), if all you're looking to do is learn the concepts.
There are differences between the different dialects (and their many implementations), but if you're looking to expand your knowledge and not necessarily write production code, pick Scheme (using Guile) and Common Lisp (using Clisp or SBCL) and you're good to go.
So, to answer your question, there's no reason why one should learn Scheme over Common Lisp (or vice versa), if all you're looking to do is learn the concepts.
Once you scratch the surface, Scheme, Common Lisp and Clojure emphasize very different concepts, in some cases they even conflict in philosophy fundamentally. I'd say give all three a chance and pick a favorite. I picked Common Lisp, but that's just me.
> Scheme, Common Lisp and Clojure emphasize very different concepts,
As I discovered when I was looking for TAGBODY in scheme (don't ask; it seemed to be the most convenient way of solving the problem). Then I realized I didn't need it, I could get the same effect with internal definitions (internal function = tag) and calls. A call in tail position IS essentially a goto. (More powerful though as it also binds arguments, if any.)
Scheme also looks more conceptually clean. For example, (define add +) does exactly what you think. In CL, you'd have to do something more contrived.
Scheme emphasizes building your software out of a small set of primitives. These primitives are themselves as conceptually simple as possible. an example is the map function which works on lists. In cl, the map function takes a designator for a return type and can take an arbitrary sequence(list, array or string). so if I want to turn a string into a list of characters in CL it would be (map 'list #'identity "hello") and I would get (#\h #\e #\l #\l #\o). For the special case, there is mapcar, which is the equivalent of map. There are also a bunch of other "map" like functions in CL. CL emphasizes a rich set of tools in this way.
Another example is the member function. member checks to see if an element is in a list. In CL member takes an element, a list as well as several keyword arguments that control how the searching is conducted. One such keyword argument is test which is used to compare the element to the items in the list, and another one is key, which is called on the items in the list before they are compared to the searched element. In scheme you don't have the key argument, which is already a drag, and instead of having a test argument, you have 3 functions: member, using equal?, memq which uses eq?, and memv, which uses eqv? for comparison. If you need anything more than that, in scheme you'll have to write your own such function. in CL, you just pass two functions to member to control how it works. In that way, CL is actually much more conceptually simpler than scheme, but we have to keep myths alive, don't we :)
Another example is the CL concept of a generalized boolean. In CL nil is false, and everything else is true, with T being the canonical true value. In scheme you have special values representing true and false, which again complicates code a bit, but is more conceptually simpler. I consider this to be a great design blunder on schemes part.
Another example is that CL is very much an OO language, much more than an FP one. You have classes, methods, inheritance, mutable slots, and all sort of messy and complicated things that come in handy every once in a while.
I can go on for ever, but I won't even get to clojure, which is I think much more interesting. Clojure emphasizes immutability and laziness. Neither CL nor Scheme force you to be use immutability, but clojure does everywhere it makes sense to do so. Laziness is something else clojure emphasizes. And although there are libraries for CL to make it very much a clojure like language, it isn't the default.
If you're going to try Scheme and you're scared of emacs/vim, I'd suggest Racket. It's got a nice IDE (DrRacket) and a lot of the community is focused on teaching so there's a lot of resources for newbies http://racket-lang.org/learning.html
Clojure is a nice choice if you're looking to write production code, especially if you're already using other JVM languages (Java/Scala/JRuby/etc.)
However, Clojure strays from a number of standard common idioms in other Lisps, which, IMHO, makes Clojure a less-than-ideal candidate if you're looking to get the "full SICP" experience. It has a lot of other benefits as a language, but for a learning experience, you'll miss out on some of the idioms common to other Lisps.
But, give it a shot and see if it works for you. Once you've learned one, it's really to learn another dialect.
And, in the end, the only wrong answer to 'Which Lisp?' is the empty list[0]. :)
[0] This is an example of a super-nerdy Lisp joke which works in Common Lisp but not Clojure - in Common Lisp, 'nil', 'false', and the empty list are all the same value, (and all other values are considered "truthy"). In Clojure, they are three distinct entities, and there is a discrete "true" value.
The closest Clojure has to car/cdr is first/rest. It supports "cons" but only for creating sequences. Traditional Lisp car/cdr is one-location/other-location, and its cons puts together pairs of data. Often this is used for constructing sequences, but it is also often used for trees.
Yeah those error messages completely baffled me for the first few hours I spent in the Clojure REPL. It was strange enough to not have car/cdr and cons for working with tuples, but then I wrote a simple recursive algorithm and got a java.lang.StackOverflowError. I now understand why and the alternative idioms that Clojure provides, but at the time it was a WTF moment.
There isn't really a great cost to learning the basics of a language. Lisp dialects are very easy to learn, at least to a beginner level. You can learn enough of any lisp dialect to start writing "useful" programs in a few days, just try them out in whatever order you prefer and see which one you like to get deeper into.
Depends on your environment. If you get Clojure set up with Light Table, it's pretty easy to mess with. I think Clojure is not as intuitive as Common Lisp or my brief explorations of Scheme.
3) Type declarations and a compiler (CMUCL/SBCL) that can take full advantage of them;
4) Better tooling (CMUCL/SBCL + SLIME);
5) More commercial support options (Clozure, LispWorks, Allegro).
R5RS doesn't even have hash tables! You can patch together alternatives for Scheme for most of those things, but the fact that they're not built-in causes problems when integrating code from multiple sources.
> You can patch together alternatives for Scheme for most of those things, but the fact that they're not built-in causes problems when integrating code from multiple sources.
There are a few good reasons that one might prefer common lisp to scheme.
It has been stable for a good long time. Which is nice if you've got a giant repository of old code that you dust off and run from time to time.
CL has a standard way of specifying variable types when you want to do so, so it's possible to write high performance numerical code in a portable (across different compilers) manner. Or write macros to write portable code.
My view on macros is that being code transformers, when you write a macro you are basically writing a quick and dirty compiler. And like everything that's quick and dirty, they are full of bugs and gotchas. The fact that CL has separate function and value namespaces helps with decreasing the gotcha cross-section. The scheme community early on spent a lot of time dealing with this and developing hygienic macros, but as a lisper this just always felt a bit heavy. (This is probably just a lack of exposure).
From my perspective, the appeal of scheme as been its more pure focus on functional programming. But when I'm in that sort of mood I just reach for haskell now.
> It has been stable for a good long time. Which is nice if you've got a giant repository of old code that you dust off and run from time to time.
I think CL is one of the few languages that I can see myself using for a decade, continuously, without having to go back and refresh pieces to conform to the latest version & compiler. Not only that, you can essentially reprogram it to keep up with advances in the field.
Because you have to write multiple-value-bind yourself, no &optional and &key parameters, no try/catch or condition system and verious other reasons.
Scheme is case sensitive by default though, which I like.
It's sort of like asking 'Why C++ and not C?'. It's the features or lack thereof that you have to want or not want that lead you to your initial decision.
Then you switch to the other to see what you're missing.
Piggybacking on this.. After reading SICP over the new year, I had a look into using Racket for various things, and although it seems to have an excellent, well rounded set of libraries and excellent documentation there seems to be less drive of people doing practical things with the language. Is there a glaring reason why, or is it simply lack of mindshare?
Because 1001 different Schemes exist and the code between them is not portable because the Scheme standard is so tiny.
Scheme code is so hopelessly unportable,that you can not even talk about "writing Scheme". You are either writing Gauche, or Chicken, or Racket, and once you write it, your code stays in that tiny little ecosystem with not more than 10 different users each.
Check out this article here comparing Common Lisp and Scheme. I'm not the author, but I thought it was a really helpful overview of the differences between them, and I hope it will help you all too.
Both "Common Lisp" and various (!) Schemes are dialects of lisp.
As for why CL is preferred - it's probably about the ecosystem, tools and libraries. No Scheme and very few languages can compete with CL in this matter. However there is Rachet, a Scheme that has a chance to approach CL in the next decade (only my opinion).
Yes, it's a lighter (very minimalist) version of lisp, as opposed to common lisp. Scheme seemed like more of a fun academic exercise. If I wanted to actually do more complex work I'd probably look to common lisp instead of Scheme.
Scheme does have a feature that would be handy in Common Lisp: continuations with indefinite extent. PG has an interesting way to simulate this with macros in On Lisp, but that hardly suffices. It is not something that I frequently need, but I have had one or two cases when such a continuation would have come in handy.
Right, came here to say the exact same thing. My eyes aren't the best. First thing I did was to open chrome dev tools and fiddle in 'p { color: black }' to make it readable at all for me..
I wondered what everyone was talking about here, then realized that since I have noscript installed, I was looking at the site with no javascript - and it was perfectly readable. Once I activated javascript I saw what the fuss was about. So much clearer without javascript.
I use the Evernote Clearly extension on web pages like this. It does a great job of improving the readability. It also removes a lot of the non-content stuff around the edges.
I use an extension called 'change colours' in Chrome. It lets me set different background and text colours, and it allows me to change the link colours, and it allows me to change the font and font size.
Great start! I wish You a lot of sales. Just an idea: maybe You should present some Lisp web projects you've developed to give Your buyers an idea of what it's like to run Lisp web apps.
LispIDE is another Windows option. It is very minimal but doesn't require dealing with emacs.
http://lispcabinet.sourceforge.net/
http://www.daansystems.com/lispide/