vseloved

The question should you program in Emacs Lisp or Common Lisp is meaningless. If you program for Emacs, you use Emacs Lisp, otherwise — Common Lisp. It would be very hard for you to do it the other way. I, actually, wonder how much knowledge about Lisp do you have, since you pose such question.

Regarding the question "Which Lisp?", it wasn't appropriate in that discussion, as the article was clearly about the use and features of Common Lisp. It was not discussing how an S-expression-based macro-language was a very good choice. To reduce the essence of Lisp to a simple notion of s-expressions + macros is a huge misconception, that I'm fighting here. Lisp is much more than s-expressions + macros. The proper question would be "Which S-expression-based language I want to use?" And posed in such way you should clearly see, that it is not a fit for this discussion. It would be much better, if everyone understood well the full feature-set of Lisp :)

I would agree with you, if the notion of Lisp was actually well-understood. But, unfortunately, I observe the contrary very often. That's exactly why I've wrote this rant.

For example, just a day ago in the previous Lisp discussion on HN (http://news.ycombinator.com/item?id=5031505):

> It's not so much a question of "Why Lisp?" as it is a question of "Which Lisp?," if you ask me.

I can't imagine a similar question about C: "Which C would you use, gcc or clang, C++ or Java?" Can you? And that is because everyone understands what is C. Yet, I think, this understanding won't impede people from discussing something in the lines of "Is Go an acceptable C?" Just because C is so well understood you can clearly reason of it. But if you will say, that you use Lisp in a broad sense, this won't tell anything about your project, because it can be a very functional Clojure entangled with a lot of Java, or very academic and "pure" Scheme, or Common Lisp, or some obscure and very different dialect, like Nu or newLisp, or you've added your own "Lisp" dialect into a project... This doesn't help understanding, and it so happened, that there so many misconceptions about Lisp, that you have a hard time discussing it with people: first you have to educate them.

Speaking of Emacs Lisp. Indeed, it is a Lisp, and it is, actually, very similar to Common Lisp, just a more dated version, lacking some of the current Lisp features. But this case, likewise the case with AutoLisp, isn't a problem, as everyone can clearly draw a line between a general-purpose language and an embedded environment.

Here's a more detailed answer: http://lisp-univ-etc.blogspot.com/2013/01/common-lisp-is-jus...

I also agree, that Racket is not Scheme, it's a new language. But I stand, that Common Lisp is still a Lisp. Lisp 1.5 would be BCPL or B :) (Why? Because C is in active use, while Lisp 1.5 isn't, so your analogy isn't quite correct)

Let's translate it to C:

C99 is C.

C++0x is C++.

C++ is C.

Clang is C99.

Do all the lines seem correct?

There are more reasons to use Lisp actually: the biggest one of which is, probably, that many programs become much simpler in it.

But, actually, such argument is meaningless. The only meaningful argument would be to compare the pros and cons of using Lisp versus some other language for a specific field with some specific constraints.

For instance, I won't be trying to use Lisp over JavaScript for writing Firefox plugins, but, probably I would use it over Objective C for this task ;)

Common Lisp. Everything else is so much Lisp as php is perl or C++ is C.

Well, Common Lisp is Lisp, Racket is Scheme, they are different. This perpetual confusion is just useless. Let's call things by their names. You don't call C++ C or php perl, right?

Gosh, if you had an extensible reader, you could do so much more... Oh wait, why don't we try it: http://lisp-univ-etc.blogspot.com/2013/01/real-list-comprehe... ;)

Actually, here Haskell is just like any other language: i.e. you can use the described properties to define similar operations in any language. It's not Haskell, that allows to define them, but the abstract properties of this class of objects

One more essential meatspace activity is knowledge transfer. It may not be the most productive thing to sit with someone at a computer and show them, how you do certain stuff, discussing different issues, that arise in the process - but definitely you won't be able to do it with email or chat. Although I may miss some other approaches to this - I'd be glad to find out about them...

then, here's an old classic for you: https://groups.google.com/forum/?fromgroups#!msg/comp.lang.l... ;)

Finally, someone has the guts to say, that failed logins should tell the user, what is wrong: username or password

Actually watch button really does what it should: let's you keep track of the project. If you want like button, just ask for it instead.

Erlang is actually done right for its use case. Hard to tell about Go yet...

Quicklisp works differently: it gives you a consistent set of libraries. If you want to get the library with some exact version (which may be inconsistent with the current quicklisp dist), you can download it separately and use at your own risk. (And quicklisp will quickload it as well, because it gives preference to local libraries - nice :)

This isn't ideal, but here you have to make some trade-off, because in both Java and Lisp you can't have two versions of the same library loaded at once (actually, in Lisp you can do that with some rename-package trickery, but that's beyond the scope of quicklisp. I wonder, can you do the same thing in clojure? ;)

Considering specifying dev-dependencies. Once again it's not in the scope of quicklisp, which is a library distribution tool and not a dependency management tool. But ASDF, the build tool and dependency management system, allows to do that quite easy: for example, you can define a separate system for dev, which you may load or not load, depending on your needs.

Actually, leiningen tries to do all at once: dependency management, library distribution and building. And that's why it's quite complicated (in the sense of Rich Hickey's complecting, I mean)...

Thanks, good to know, that it's fixed.

Btw, I think it's a good chance to ask, why there's no way to specify several directories for leiningen to use as java-source-path?

And some comments: http://lisp-univ-etc.blogspot.com/2011/11/videos-from-eclm-2...

Rich is a good philosopher. Although it's often hard to strictly follow your own principles in your real-life work - and Clojure shows that often ;)

> The use of Functors, Applicative and Monad (as well as other classes of types) is just like following the GoF design patterns. How true: another set of tricky patterns, instead of just doing the simplest working thing. ;) (Hint: dynamic languages render most of the patterns unnecessary - http://norvig.com/design-patterns/ - and that also applies to functional programming)

> Most of Lisp's other features are common now.

Special variables, restarts and flexible reader are some of the basic features, that are not only uncommon, but, actually, unseen in any other language. Just to name a few.

The only correction is that in this phrase "Facebook works on the theory that when you have a lot of people, you don't have to make as much per person, because the amount of money you make is the number of customers times the amount of money you make off of each one" you confuse customers and users. Facebook users are not their customers. The customers are advertisers, and there ain't 500m of them. So, although their profit hugely depends on the number of users, it's not the only component in the formula.

Clojure is nice, although I didn't use it in production. But it is Java deep underneath (so not completely homoiconic) and comparing to CL there are restrictions, albeit mild.

For some specific tasks I might have preferred it (until CL catches up with concurrency support). But in general CL gives you more freedom.

It's funny, that the decision to choose Common Lisp for some project often has to defend itself (because of so much FUD around the language). CL has one killer feature, that will appeal to any mature developer: it's the only production-ready language around, in which you are virtually not constrained by any third-party design decision. That's it. Discussing other details just boils down to the question of tastes (that differ).

It has already happened: they've screwed up search, when moved away from PageRank to some reputation-based algorithms (and set-up the Facebook & co. as sites with biggest reputation, which is nonsense, as that's UGC). It's not so visible in English-language search, although begins to be, but, for example, for Russian I've stopped using it altogether.