views:

1244

answers:

11

I develop in Lisp and in Scheme, but I was reading about Clojure and then I want to know, in which cases is better to use it than using Lisp or Scheme? Thanks

+3  A: 

Clojure runs on the JVM (and on the CLR), so there is that.

Robert Harvey
Scheme and Common Lisp also run on the JVM.
Rainer Joswig
Yeah, but Clojure is /built/ for the JVM, from the very beginning. It isn't just a half-cracked JVM implementation.
Rayne
ABCL has been built for the JVM, too - from the very beginning. For the J editor. Originally started to be a scripting language for the J editor.
Rainer Joswig
+15  A: 

"Clojure runs on the JVM" means you get the whole cornucopia of Java libraries available. You can make pretty GUIs in Swing, use Apache's Web client or server code, connect a ready-built Sudoku solver... whatever you like.

Another big plus of Clojure is its very polished concurrency support, with about 3 different flavors. If you have a compute-intensive, parallelizable task, Clojure can make it easy. Well, easier.

Update: Another argument. Clojure is pretty strongly functional, so it's a plus if you want to force yourself to think and write functionally.

Carl Smotricz
Than I can have all the power of the Java Libarys and develop in a generic Lisp?
Nathan Campos
Yep, that sums it up pretty nicely. Except the "generic". Clojure is its own Lisp flavor. For example, function arguments go in [ square ] brackets. And `car` and `cdr` are called `first` and `rest`.
Carl Smotricz
You will have a small bit of adjusting to do to learn the changes. But Clojure is a rather "friendly" lisp. Believe it or not: ( Fewer parentheses! )
Carl Smotricz
Thanks very much. I've write generic, because of Scheme that is a generic Lisp, then I just generalized all **;)**
Nathan Campos
Generic: "relating to or common to or descriptive of all members of a genus". Shoot me for being pedantic, but Scheme and CL are both distinct dialects of Lisp, variations on a common theme; I wouldn't say either can claim to be generic. I'm not great with Lisp genealogy, but it's possible that there is NO generic Lisp. Or maybe I'm just being too picky :)
Carl Smotricz
Does Java have a built-in sudoku solver these days? Because it's not like Common Lisp is lacking for Sudoku solvers (googling for "lisp sudoku" turns up 1,370,000 hits). :-)
Ken
Not built-in. But there seem to be lots of 3rd party implementations. I'll see your 1.37M hits and raise to 2.45M in Java!
Carl Smotricz
CAR and CDR are FIRST and REST in Scheme and Common Lisp, too.
Rainer Joswig
+5  A: 

A subset of Clojure can also compile to javascript

Arthur Ulfeldt
So like all great forces, Clojure can be used for good but also for evil :)
Carl Smotricz
From Brendan Eich's blog: "I was recruited to Netscape with the promise of "doing Scheme" in the browser." ... so Javascript is like, the ugly child in the LISP family?
Jimmy
Scheme in C clothing.
Nosredna
Which probably makes JavaScript the most subversive of functional languages, teaching our kids functional programming right under our object oriented eyes!
Nosredna
+4  A: 

Clojure should be used when

  • you need to work with existing java code.
  • you work with people who are allergic to lisp ("boss, i would like to use a java concurrency library called clojue vs. I would like to re-write this in scheme" [1]
  • you will be programming for a multi-processor system.

Scheme would be better when:

  • you need to prove your code is correct. Clojures (call out to java) hinders but does not prevent this.
  • you are working with people who are allergic to java.
  • you are developing for a platform with no (new enough) JVM

[1] yes this is a bad bad bad reason. such is the world we live in...

Arthur Ulfeldt
+2  A: 

Clojure's design is concerned with accommodating several styles of concurrent programming safely, deliberately making it difficult to mistakenly write the dangerous, rickety, and often broken concurrency-tolerant code in other languages. If your problem domain involves concurrent programming, Clojure's array of integrated tools for managing concurrency may be a better fit than the implementation-specific or lowest-common-denominator libraries available in other Lisps and Schemes.

seh
+22  A: 

This question is impossible to answer. You should use Clojure nearly 100% of the time over CL and Scheme, is what I would say. But that doesn't mean you should listen to me. Others can make a good argument that the opposite is the case.

For me, the syntax and function names in Clojure aesthetically pleasing. Certain Java libraries are invaluable for what I do for data munging and web programming and GUI stuff. Functional programming is challenging and enjoyable. Clojure's flaws are unimportant and outweighed by its benefits in my eyes. Certain intolerable flaws in other Lisps are "fixed" in Clojure, because it's new and it can ignore backwards compatibility. It has a novel and arguably powerful approach to concurrency. The Clojure community is vibrant and welcoming and awesome. All of this says as much about me and what I value as it does about Clojure or other Lisps.

There are libraries for CL and Scheme that don't exist in Clojure or Java. There are people who dislike how Clojure uses too much syntax like [] and {} and want to use parens everywhere. If you want CLOS-style OOP or lots of mutable data structures, another Lisp is arguably better. The JVM is heavyweight, maybe too heavyweight and too much baggage for some people. A lot of Java leaks into Clojure (by design) and this offends some people's sensibilities. The STM and immutable data structures have overheads that make certain things (e.g. number crunching) slower or less elegant. Clojure is new and still rough in certain areas, still rapidly changing and evolving in others. Clojure has yet to pass the test of time, whereas other Lisps already have. Clojure is not a "standard" and some people find a language defined by an implementation to be unappealing. And so on. None of these things matter to me, but they may to you.

This is almost entirely subjective. Which language you should use depends on what you already know, what you are willing to learn, what libraries you want to use, what editors and tools you're comfortable with, what language flaws you're willing to live with and work around and what flaws you can't tolerate, and what helps you get your work done faster, more cheaply, more enjoyably, or achieve whatever your goals are.

Basically, whatever makes you feel warm and fuzzy. Learn them all and then make an informed choice based on your own tastes, and use whichever one you like the best. They're all good.

Brian Carper
For a question that's "impossible to answer", you did a pretty good job!
clartaq
Tell that to the anonymous down-voters. (Thanks, down-voters!)
Brian Carper
They aren't anonymous. They are the ancient Common Lisp fanboy community. They are probably butthurt that you recommended Clojure over their precious 10 thousand year old language. :\
Rayne
There's room in the world for CL and Clojure both. Honestly I think there's mutual respect for the most part from people in both communities, as it should be.
Brian Carper
Indeed. But CL fanatics tend to be territorial, and that's where I imagine your down votes are coming from.
Rayne
+7  A: 

When? As much as possible. Why? Immutable Data Structures - they really are that good. There are plenty of other reasons too.

Timothy Pratley
+2  A: 

One of the greatest things about Clojure is the plethora of libraries you can use with it. You have the power of Java with the expressiveness of Lisp, and that is a badass combination. Clojure is more suited for real world development, because it was made for real world development. With Clojure, you have awesome libraries, awesome modern features, and an amazing community of helpful, like-minded people.

I would have to say that Clojure is a better language, all the way around. That is a highly argumentative statement to make, so I will point out here that this is just my honest opinion.

Clojure rocks.

Rayne
+4  A: 

ABCL (Armed Bear Common Lisp) and a several of Scheme implementations (KAWA, SISC, ...) are also running on the JVM.

Generally Common Lisp is available in different 'flavors' - ABCL is one of them. Other compile to C, to native code, have extensive development environments or specialized extensions like logic languages or databases.

Clojure OTOH is a new Lisp dialect with emphasis on lazy functional programming and concurrent programming. Its author (Rich Hickey) is a very experienced software developer (he has also written Java and .net interfaces for Common Lisp) and did an excellent job with Clojure. Even though there is some hype around the language, it is worth checking out - it is definitely one of the better Lisp dialects developed in recent years (compared to say Newlisp or Arc).

Rainer Joswig
Armed Bear Common Lisp? Really? You're not just pulling our legs? Yep, them Lispers are crazy.
Carl Smotricz
'The right of the people to keep and arm bears shall not be infringed!'
Rainer Joswig
I find that Stoned Bear Common Lisp is a better implementation, generally less violent and more relaxed than ABCL.
Nathan Sanders
+4  A: 

There are lot's of reasons, some mentioned above. My take is:

  1. The pre-existing libraries. This is such a benefit. I just can't praise this feature enough.
  2. The language is more adapted to the hardware currently available (multi-core) and the development paradigms in use today. It is so much easier to reason about concurrency. The functional aspects are nicer too. You can do functional programming in Lisp, obviously, but it is very easy to break the paradigm unknowingly, unwittingly, and unintentionally.
  3. Cross platform. I run identical programs on Linux, Windows, and the Mac. There are lot's of native Lisps that run across platforms, but support for all features on all platforms is a bit spotty and you constantly have to be on the alert for things that are missing on one platform or the other. Likewise,the libraries you need are not always consistently supported across platforms. ABCL and some of the JVM Scheme implementations have this consistent support as well, but I still prefer Clojure because of point 2.
  4. The nature of the language community. Let's face it, a lot of the time the Common Lisp community is just nasty to deal with. That is not the case with Clojure at all. It's easy to get useful help without the condescension and meanness that often comes with an answer from the Common Lisp community. As I have learned for myself several times, there is no question so stupid that you won't get a polite and helpful reply from the Clojure community.

If I had to find one thing to complain about, it would be IDE support. Maybe it's a question of learning new habits, but it is still easier for me to handle the mechanics of Java development than Clojure. I have tried, and use, Clojure Box, enclojure on NetBeas, La Clojure on Intellij IDEA, and Counterclockwise on Eclipse. They all work fine if you are working primarily from the REPL, but for compilation and execution of class files, they all still feel a bit clumsy.

clartaq
+1  A: 

I'm always trying to learn new languages, so I'm interested in learning Clojure. But, aren't SBCL and some other Common Lisp implementations much, much faster than Clojure? Wouldn't you need considerably more than 4 processors (and a reasonably parallelizable task) to make up for the performance difference between a Clojure app and even a single-threaded SBCL version of the same app?

Donnie
From my personal experience, I'd say it's a misconception that Clojure should be systematically slower than [brand X]. I've been writing number-crunching stuff in it for Project Euler and, given similar algorithms my Clojure code performs on par with my carefully and (dare I say) expertly hand-tuned Java code, same machine, which is almost as fast as C as long as I stay away from lots of unnecessary object creation. If you need stronger evidence please let me know what you have in mind and I'll try. Have Linux and gcc, will benchmark :)
Carl Smotricz
And before you ask: I looked but was unable to find meaningful Clojure benchmarks. A few people posted some pretty random-looking stuff that gave me the impression they know much less about benchmarking than I do. So you can either accept my personal impression (though I was running puzzles, not benchmarking) -or- tell me what you'd like to see benchmarked (I'll post code and times) -or- do your own.
Carl Smotricz