As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
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
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.
"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.
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...
When? As much as possible.
Why? Immutable Data Structures - they really are that good. There are plenty of other reasons too.
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).
There are lot's of reasons, some mentioned above. My take is:
The pre-existing libraries. This is such a benefit. I just can't praise this feature enough.
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.
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.
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.
A subset of Clojure can also compile to javascript
Clojure runs on the JVM (and on the CLR), so there is that.
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.
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.
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?
As a general rule of thumb, I tend to favor Clojure over other languages in cases where either of these fit the bill:
(1). The domain model tends to look very recursive and/or graph-like.
(2). There's an opportunity to leverage a multi-core JVM environment (e.g., Elastic Beanstalk)
(3). There's a fuzzy barrier between data and code (think RPN calculator where nodes can be operators or numbers)
These might sound a bit contrived, but a lot of my work involves dealing with graphs and trees of information, whether it's looking at social networks, some kind of constrained-based optimization, or semantic relationship building. I find that my other favorite language, Ruby, cannot give me the mix of expressiveness and raw computing power compared to Clojure, particularly when it comes to quantitative, recursive, concurrent-type problem solving.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I'm starting to understand Scala and I like it a lot.
How can you position yourself to get a paying job as a Scala developer (assuming those become more common)?
What parts of the Scala ecosystem have the best job potential (Lift, Actors?).
How can you gain credibility with a prospective employer without being able to point to Scala work experience (maybe experience on open-source projects?).
(The above questions are hopefully of somewhat general interest to Scala folk. If you want to factor my particular situation into your response, here are a few details about me: longtime developer (mostly Java) with a Computer Sci PhD; not currently working; I'm tied to a non-cutting edge location (Rochester NY), so I may be limited to remote work.)
Update 2010/07/30:
Thanks for the responses. I'd like to crank up the emphasis on the location issue. I'm tied by family to a location that probably won't have Scala work locally for a long time. Are there realistic prospects for getting remote Scala work, and if so how do you position yourself to get remote work? (A modest amount of travel would be doable, but not a full-on road warrior.)
Also, I was wondering about leveraging my teaching background. Would teaching a Scala class at a local university make a big difference in one's marketability as a developer, or just divert more effort than it is worth?
Pure Scala position:
Finding a pure Scala position is not very easy, but it is getting easier and easier. I am going on my first pure Scala job interview in a few days.
I hope we will see a lot of new systems being written entirely in Scala, and I think these systems will be mostly back-end, heavy duty systems. These systems will be using Scalas less error prone functional style to reduce bugs. I think Akka, SBT and Specs will be important frameworks for the Scala developer (this is not much of a prediction since they are already important).
If you do not find a pure Scala position:
Your credibility comes from your time with Java. Most big companies have heaps of Java code that must be maintained and developed. If it is your job to babysit the old Java code, and as an old Java guru, you should have some say in how this should be done. The first step is to change the Maven setup to allow mixed Java/Scala environment. Moving to SBT is probably your best choice. This is a one time investment you have to do or else you can not proceed!
If you work independently you could probably replace Java with Scala whenever you feel like, most likely when you have to re-factor some old code. Talk about Scala as a "framework" for Java (this is technically a lie) that boosts productivity when speaking to the non technical project manager, this might calm their worrying minds. In the end it will be your responsibility to see to it that Scala indeed integrates with Java. But since Scala does this very well it is not much of a problem. Actually, maintaining old legacy code is not a dream for anyone, so PMs are usually happy if they find anyone who would do it for more than 3 month. Management will probably put up with you rebellion.
If you work in a team it is a bit more tricky. In this case you have to teach the team Scala, or else they will not be able to understand your code. You have to persuade your PM to set aside resources for Scala training (might be hard). When you introduce Scala to a team, start small. My experience is that it takes a while for a Java dude to learn Scala, so this is not done overnight. Therefore, ignore everything that is "hard" when you teach Scala. When the team grasps the basics, start with writing tests in Scala (thank Davetron5000 for this tip), continue to use Java for programming in the application (the production code). Hopefully the team will learn and enjoy Scala and after that, well, it is all downhill from that point.
Good luck!
If I was hiring at the moment, I can tell you right now what questions I would be asking and they would be about the language. It is a hard language to understand at a deep level, even if it seems easy to use and, as a consequence, you might be expected to understand code written in a large number of different styles.
Knowledge of libraries (Akka and Lift being the obvious ones) the sbt build tool is great but it is an extra. I would want to know that you understand:
a bit (well, a lot) about the type system (and higher-kinded types)
something about the typeclasses approach
implicits and the pimp-my-library approach
good scala style (i.e. idiomatic scala)
recursion
the actors approach to concurrency
the standard libraries
functional programming
If you understand the language, you'll pick up the libraries with no problems, I'm sure.
Other libraries:
scalaz for functional programming
scalala for numerical programming (linear algebra etc)
scalaj for interacting with Java
I think your best bet is to get good at Scala and to get visible in the Scala community. These are not necessarily the same thing but luckily they are very closely related in the Scala community. Once you do this there are definitely opportunities to use Scala for fun and profit, whether as a consultant/contractor or as a (remote) full-time employee. As part of getting better and more visible I would recommend becoming active in one of the existing communities (Lift, Akka, ScalaNLP, you name it) or even going out in the wilderness and hacking away to solve a common problem, even if it's just making a native Scala alternative to a popular Java library (e.g. squeryl and Dispatch maybe weren't necessary but they're awesome).
I guess what I'm saying is that contributing to any good, useful Scala code will be good experience and I think the ecosystem is so young that there's no need (or benefit?) to specializing in only one part of it. Of course, if there's a specific subject that Scala is useful for and/or a specific field that benefits from Scala that jumps out to you, direct your attention in that direction.
Having had two full-time Scala jobs at this point, I'd say that the most important thing to do is learn the type system and the standard libraries inside and out. The individual technologies can then be picked up with relative ease.
Also, start using Scala (specifically Specs and ScalaCheck) for testing in your current project, today, if you possibly can.
Finally, as pr1001 said, get visible in the Scala community. Contribute to a project, interact on the mailing list, hang out in #scala on freenode, answer questions where you can.
Take your current job, and implement resume driven development. Just claim that xyz can't get done on schedule without Scala, and then use it. After that, take your project to success and either work elsewhere, open your own business, or continue developing Scala apps at your own company.
It worked for Dick Wall, so it should work for you. :)
we are considering Scala for a new Project within our company. We have some Junior Programmers with only PHP knowledge, and we are in doubt that they can handle Scala. What are your opinions? Some say: "Scala is a complicated beast!", some say: "It's easy once you got it." Maybe someone has real-world experience?
"My coworkers will not understand Scala" is simultaneously overstating its difficulty and insulting your coworkers.
Scala is not that difficult. It's just another programming language. Any trouble that junior programmers have with Scala is going to be more or less the same trouble they would have with any other language.
Your coworkers are smart. Of course, I don't know them, but it's a pretty safe bet unless your company is the kind of organisation that hires stupid people, in which case, you have bigger problems.
That said, at my company we have some core products developed in Scala, and we don't find that people have any more trouble with it than Java. The code is generally more clear and concise, easier to generalise and reuse, etc.
I guess Scala could be used as a "beginners" language. Even though there are tricky ideas behind it, you dont have to use/explain them in the beginning. If you explain pure OO with Scala, I would say it is straight forward and easily understandable. As Scala reduces a lot of code overhead from other languages it might even be easier to learn concepts with Scala than with Java/C++.
A major drawback I see with Scala as a beginner language is the lack of documentation. Don't get this wrong, the official Scala doc is very good and also the few books that are available are quite useful to get the details of the language, but those have not been written for beginners. For example in Java you find hundreds of books titled something like "Learning OO with Java" you wont find that for Scala which may be a show stopper.
As Hannes mentioned, only do new language introductions within research projects and not productive or even flagship projects. If you have some juniors, that makes the situation even better, take some internal tool, you always wanted and needed and let them create it during a research project. This is also a nice opportunity to experiment with different development-processes. And your juniors most probably like to be challenged and will deliver a good prototype and a very well proofed opinion if Scala can be used as a beginner language.
I believe that most people moving to Scala are experienced and enthusiastic coders. I'd suggest that you get in-house experience with a Scala project with your senior programmers first before forming a strategy for mentoring your junior coders. I'd also suggest that you only involve people who are eager to join in.
I would advocate it. But with the proviso that you have clear guidelines on what language features are acceptable for your team. For example, coding primarily in an imperative style (which is familiar for Java-trained people), or perhaps limiting the employment of recursion or closures.
Also plan for seniors to mentor the juniors. This may take the form of any combination of: pair programming, code reviews, info sessions, regular discussion forums, etc.
The opportunity that scala presents for vastly improved coding on the JVM is too great to pass up. When your seniors get into it I would not be surprised if they find renewed passion for development. When your juniors get into it they will be learning best practice JVM development from the start.
If you choose to go this route, perhaps they'll find easier to use the Scalate framework than a more traditional one like Lift, since it allows mixing HTML with Scala, much in the same way as PHP works.
Scala is a very 'normal' programming language. Any programmer should be able to learn this language. The people that have difficulties learning Scala mostly are experienced with imperative languages and are surprised by the functional concepts. So unexperienced programmers may learn it even faster. In my opinion should be no problem, to assign it to juniors. From a management point of view, I would assign a junior and a senior developer as a team (or more of both, depending on the size of the project).
I think it depends whats more importent for you. If you want to learn as possible about OO Programming and the standard stuff its a bad idea.
But what you really give them is a opportunity to learn something really cool and unique. Witch can be good motivation. Scala has many cool stuff in it. If you can handle Scala you can handle a lot of otherstuff as well.
Talk to the Programmers (all of them) and tell them why you wanne to use scala. Ask if the have to motivation to make and learn something not everybody can do and go the extra mile?
If the are go with it!
My initial thought would be that Scala will be too heavy for them but then I guess because Scala is an OO/Imperitave/Functional hybrid, one could introduce them to the OO/Imperative part of scala until their comfortable, but then again they will probably have bad PHP habits in Scala since scala authors mostly prefer the functional style over the imperative one.
So, it could work, but I would do it for a research project, and definately not for a flagship one.
Edit: Perhaps this should be said also: It seems that functional/OO hybrids like Scala is becoming more popular especially because of how functional languages handles parallel processing as opposed to how we know it in languages like in Java. The amount of cores found in a chip is increasing rapidly, so this is important. However, mentioning PHP, it seems that you are developing web server scripts where threading is less important. PHP doesn't even have threads.
This raises another point. Do you want to develop Scala Web applications i.e. Lift. If so then you have a doubled up learning curve which should also be considered.
Imagine that you would have picked Java and asked whether they could handle Java. If your answer is they could, then they can probably handle Scala.
Scala is only marginally more difficult due to:
No great IDE support. The support ranges from poor to good. Not necessarily an issue for a PHP programmer.
Documentation not as rich as Java
Both Java and Scala have new challenges for a PHP programmer (JVM, new libraries, compiled language, statically typed).
I don't think Scala is a complicated beast, but you do need to understand some of the syntactic sugar and design principles, which would be true of learning Java as well.
Yes, if...
Strategic decision has been made to go with Scala
Company can handle the hit (financial and time) that will come from the steep learning curve.
No, if...
No senior Java, C# or C++ programmers can be put on the project too
Can't find a Scala programmer to act as a lead
Programmers don't have the patience to learn Scala or deal with a language where Jars (libraries) are scattered all over the place, rather than in one or two neat packages like PHP.
*Note: if the junior programmers were C++, C#, or Java Software Engineers rather than PHP, then my answer would be different like, Go for it!
I would not recommend it. My experience of Scala is only from homebrew projects, but I would imagine the currently lousy IDE support, quite frequent API changes and a very flexible syntax (that allows one to hang himself and everybody else participating in the project) would cause a lot of problems in a bigger, more official project.
Give them IntelliJ and throw 'em in the deep end.
Here is a blog post I recently stumbled upon:
http://james-iry.blogspot.com/2008/07/java-is-too-academic.html
It shows that even Java can be too academic to be understood by programmers which have no experience in functional programming. On the other hand, Scala allows to write code the "imperative way", so you can avoid all the FP stuff if you do not understand it. In my opinion, Scala is much more concise than Java, so I guess a "junior programmer" should be able to handle it.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
For the next 3 years I will have to work with the JVM (project requirement) using a very specific third party API. They want Java but I've been given leeway to move away from Java. I was hoping we could move back to the .NET framework so I could develop code in F#, being absolutely in love with OCaml. .NET development has been struck down by our customer. It is a no go.
I've turned to looking, reading, and poking around programming blogs/forums trying to understand which language might appeal to me further: Scala or Clojure. Those seem to have the largest community/fan base. Being experienced with ML languages I see lots of people who compare Scala to ML. However, there are some real naysayers when making this comparison. If Scala was that close to ML my productivity and learning curve would benefit making this switch.
The internet is full of misinformation and wonder if I'm suffering from such. I don't like the syntax of Lisp (don't hurt me!) but if Scala has the warts I'm reading (poor IDE support, in flux Unit testing framework, performance issues) I'm wondering if Clojure is the better option. I want to be productive out of the gate, using functions as first class objects, and minimizing concurrency pain.
So anyways, before I spend too much time on the internet and not working... I'm stuck with the JVM, sick of Java and wondering where to go?
In my opinion, both Clojure and Scala don't have great IDE support, if that's really important to you. That said, here's what I can collect from my reading & experience.
Scala's pros
Faster than Clojure thanks to more static typing
Closer to ML (syntax, type-directed programming)
Bigger standard API (Clojure's APIs grow very slowly, because they want to make sure they find the best idioms before making them public. That said, Clojure still has semi-official supplementary APIs)
Better integration practices with the typical Java toolset (Clojure is still making some choices, so less firmly established yet on this regard)
Older than Clojure (but Clojure is built on top of a very old and proven core: Lisp)
People say it has chances to reach mainstream, while they wouldn't say the same about Clojure
Clojure's pros
Incredibly easy, fast and right concurrency thanks to MVCC-based STM and other concurrency mechanisms
Immutability by default helps doing the right thing first
More stable standard API
When things change, usually you don't have to rewrite any existing code
(Scala's collections are being remade again for 2.8)
(I have also read somewhere that it's common knowledge that Scala's Actors implementation needs a rethinking and rewrite.)
Easier to learn (small language, being a (very-clean) Lisp)
An opportunity for you to grow by learning something different
Clojure's performance will only get better with time; there's still room for nice optimizations in the compiler
Scala's tying to Java feels more limiting than Clojure's (interactions between Scala's and Java's static type systems). One could sometimes say the same about Clojure (Object-Orientation's support is not a 1:1 fit, but support for this will soon get better)
Rich Hickey has a gift for making choices that put Clojure in the position of having technical leading features that will be adopted by other languages in the decades to follow. And he also has a gift for explaining them. So use them today in Clojure, or wait to use them in another language in some number of years. :)
On distributed concurrency
If your concurrency needs are distributed, Clojure doesn't yet have anything for this unless you run it on top of Terracotta or something similar, in which case you'll be able to use all its concurrency features. If you do, you will end up with a better distributed concurrency experience than with Scala's Actors, IMO.
Conclusion
IMO Scala tries to do everything, and succeeds at doing most of it. Clojure doesn't try the same thing, but what it focuses on is more than enough and succeeds so well that most people really knowing Clojure wouldn't want to go back to something else. Disclosure: my personal preference goes, of course, to Clojure. I hope I've been able to be objective in what I wrote.
Have you considered Groovy? I don't think it is quite as functional as Scala/Clojure, but it's certainly a lot more functional than Java**. In general, I can get the same work done in Groovy with about 50% of the code it would take me in Java.
This is because Groovy is syntactically similar to Java and provides seamless access to the JDK libraries, but the addition of a lot of language features (closures, meta-programming, properties) and dynamic typing eliminates almost all the boilerplate associated with Java programming.
** I mean functional in the sense of 'functional programming' rather than 'working correctly'
I'll address the points you raised about Scala.
IDE support:
Scala doesn't have the same level or IDE support Java has -- or, for that matter, that F# should have with VS10.
That said, it has one of the best (maybe even the best?) IDE supports on JVM, outside Java. Right now NetBeans is good enough, and people have consistently said IDEA is still better (hearsay). The Eclipse plugin is unstable though.
But you mentioned a 3-years range, and the IDE support for Scala should be greatly enhanced once Scala 2.8 is out, as it will provide some compiler-support for IDEs. There's no release date defined, but it looks to be within the next six months, maybe three. And the Eclipse plugin will be updated right along with it.
In flux unit testing framework:
Yes, if you meant it is vibrant, evolving and well supported, instead of stagnant and abandoned. ScalaTest, Specs and ScalaCheck are top quality frameworks, compatible between themselves, and compatible with other Java frameworks and libraries, such as JUnit and JMock.
The testing frameworks, in fact, are almost a child poster of what is possible with Scala.
EDIT: Scala has basic unit test support in its standard library (scala.testing.SUnit). However, given that many superior, actively-supported and free alternatives have appeared, this has been deprecated and will likely not be part of the library shipped with Scala 2.8.
Performance issues:
I'm unaware of any, aside from the fact that you can write lousy code, just as with any other language. People not used to functional programming will often do stuff that's not efficient, such as not using tail recursion, or concatenating lists, and the paradigm shift that Scala enables brings that to light.
At any rate, you can write Scala code as fast as Java code (even faster with some upcoming features). And you can write Scala code with functional features almost as fast as Java code.
Quite frankly, get another job.
If you are to spend the next three years feeling uncomfortable on what you're doing, you should consider looking for more attractive alternatives.
Even if you manage to get a language you like, if you are part of a team ( which I guess you are ) the rest of the team might not like that language. If the rest of them code in Java and you in "fill in the blank" programming language, then problems may arise.
It is not that bad after all.
Talk with your boss, let him know how do you feel. Start looking for alternatives and have a nice and professional "leave".
There is no reason why you can't still have a good relationship with your current boss. If eventually they have a new project for .net you may come back. Talk about that also with them. Leave your doors open.
Its not really a zero sum game, learn them all!
ps: i vote for Clojure, i find it the most fun!
You should consider yourself lucky that you can use the JVM, because the JVM is becoming more and more popular for alternative programming languages than Java.
Besides Java there's Groovy, Scala, Clojure (a Lisp dialect on the JVM), JRuby (Ruby on the JVM), Jython (Python on the JVM), Jaskell (Haskell on the JVM), Fan (runs on the JVM as well as the .NET CLR) and lots more, and there's also an OCaml-Java, OCaml that runs on the JVM.
So, there's lots of choice in programming languages on the JVM, from purely functional to simple scripting and anvanced OO languages.
Tool support for Scala and Clojure may be immature, but it's steadily improving.
Since you like F#, then Scala is most likely your best bet. I say try it out and form your own opinion - you might find that the things people gripe about are things that don't matter to you, or things you can work around.
Don't forget jRuby, and note that an IDE is optional for non-Java
I think you have a great situation. How many people get permission to choose the implementation language? With everything available for the JVM having your environment chosen is not much of a restriction.
You won't need great IDE support in the less verbose languages
In a language as powerful as Ruby with no type declarations, you don't need an IDE at all
Scala was developed specifically to cure the verbose-java-blues
Count yourself lucky that you have three years of work lined up :-)
Clojure might be fun and provides functional concurrency-safe design patterns
Noop? http://code.google.com/p/noop/ (experimental though)
In terms of IDE support and other doubts you're having, Clojure doesn't do any better than Scala. And for a person with ML/F# background (or generally that in strictly, statically typed FP languages), you'll definitely find Scala much closer to what you're used to.
If you like ML you might like CAL which is more-or-less Haskell 98 for the JVM.
It is high quality and very stable, and has good IDE support on Eclipse, but sadly is no longer under active development.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I know there are a few different dialects of Lisp. Having decided that learning Lisp would be a new intellectual experience, I would like to know which Lisp dialect to learn, and why.
Is there one which is more popular than the others? Is any one of them more "complete", as in, better documented and supported? What are the pros and cons of this dialect?
You want to look for a balance between simplicity and cleanliness, attractive features, and a platform that will allow you to write interesting and useful software (to yourself) as well as serve as a learning tool. (This last will keep you going and learning for a lot longer.) Here are some possibilities:
Scheme. Probably the cleanest of all dialects. This is no doubt why The Little Schemer was translated from LISP into Scheme. The fifth Scheme standard specification, R5RS, is a wonderful education in and of itself; it may be the nicest language and library specification I've ever read, as well as the shortest that's reasonably comprehensive. The PLT Scheme (now Racket) platform includes a fairly decent interpreter and compiler, is good for scripting, and also has some visual tools that make it excellent for learning.
Common Lisp. Probably the most portable and comprehensive variant, this is most likely what you want if you want to be writing things such as commercial software. The standard defines extensive libraries, and many more are available beyond that, it has CLOS, which will probably teach you more about OO than any OO language could, and some of the compilers are very good. Disadvantages include some warts that Scheme doesn't have (such as having a separate namespace for variables that refer to functions), not being as clean and simple (as is the case with anything that has had to have the extensions and make the compromises necessary for large applications in the real world), not having hygienic macros, and emphasizing recursion much less than Scheme.
Clojure. This runs on the JVM, which may give it a leg up right there for Java developers. It's got a few warts (e.g., you must explicitly ask for tail call optimization, though this may change one day if TCO is added to the JVM). The macros, while not hygienic, do have some features to help you avoid variable capture, so you can capture variables if you really want to, while running less risk of accidentally doing so than in CL. You've got easy access to all the Java libraries; that's probably a good thing for "real world" code, and fairly pointless in terms of learning. It's got a set of libraries for persistent data structures and support for STM, which make it very interesting from a concurrent point of view; this makes it probably your best bet if you're interested in learning more about new methods of dealing with concurrent and parallel programming. It appears as if Clojure is as usable for large, production applications as Java, in the sense that it's going to have the ability to do the "ugly stuff" you do in production apps that you'd rather not do and don't do when you're learning.
Emacs Lisp. In terms of a LISP, this is not one of the better examples out there. One of its biggest faults is dynamic scoping, but there are many others. However, if you're an Emacs user, this may be the most powerful tool you can learn to improve your use of the editor. How much you'd really learn from learning Emacs Lisp, beyond how to extend Emacs, is for me an open question however; I don't know how often interesting techniques such as high-order functions are really used in Emacs Lisp.
2018 Update
It's been almost a decade since I wrote this post and the Lisp family of languages now appears to be gaining significant traction in the general programmer consciousness. Much of this appears to be related to Clojure which has not only become a properly separate dialect of Lisp in its own right, introducing many of its own good ideas, but also now has a near-identical version targeting JavaScript and has inspired many other Lisps targeting other platforms. For example, Hy targets the CPython AST and bytecode, aiming first for interoperability with Python, but using Clojure ideas "when in doubt." (Though from the latest commits, the latter may be changing a bit.)
The big change this brings in your decision-making process is that you should also be looking at whatever Lisps or Lisp-like languages are available for and interoperate with languages or platforms you already use, be it Perl, Ruby, Erlang, Go or even C++ on microcontrollers.
I would say Scheme, solely because of the Little Schemer, which is one of the most mind-blowingly fun yet extremely hard books I've ever tried to read.
I can recommend Common Lisp on SBCL. This combination is fast, powerful, mature and well-documented.
Also Clojure is a gaining a lot of mindshare these days, and for good reason. Great data structures, profoundly good concurrency support (puts Scheme and CL to shame in this regard), and a great community. It's also relatively simple, CL is as at least as complicated as C++.
This isn't to say I don't enjoy CL or Scheme. I learned Scheme with SICP. And CL brought me to Clojure. It all depends on your goals I suppose. If you want to learn a Lisp that is immensely practical go for Clojure. Otherwise CL or Scheme are both great.
I learned Scheme in school. It was a great learning experience and I will never forget the fundamentals of functional programming. It probably doesn't matter which version of LISP you pick up, as long as you understand the core of its usefulness - stateless lambda calculus.
Here's an interesting article on Why MIT switched from Scheme to Python in its introductory programming course.
I prefer CL, since I like object-oriented programming, and CLOS is the nicest object system around.
I would say all of them, at least at first. Eventually you will probably develop a preference for Scheme or Common Lisp, but they both have enough differences that it's best to get a handle on everything that's out there.
Scheme has continuations for example, and it's good to learn about those in Scheme, even though they can be implemented in Common Lisp.
Learning the difference between lexical and dynamic scope is important, and if you learn both Common Lisp and elisp you'll come across the implications of both.
LFE (Lisp Flavored Erlang) would be nice. You can have the lisp syntax on top of the Erlang VM.
Was a kind of "loaded" question to begin with but OP probably didn't know about it. Generally, Common and Scheme lispers are like PC and Apple computer "people", they don't mix. Which one is best is probably not as relevant as which one "works" for you. Really, there is not that much difference. Likely a preference for one over the other maybe influenced by which one you learn first. (To me, an empty list should be "nothing", known in CL as NIL, and that makes me a Common Lisper.) I like the integration of SBCL with Slime using EMACS, but SBCL is not for everyone. For one thing, SBCL is very strict. If you just want to "have fun" the GNU clisp is easy and available for virtually every platform.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have been programming in Python, PHP, Java and C for a couple or years now, and I just finished reading Hackers and Painters, so I would love to give LISP a try!
I understand its totally diferent from what i know and that it won't be easy. Also I think (please correct me if I'm wrong) there's way less community and development around LISP. So my question is: what's the best way to learn LISP?
I wouldn't mind buying books or investing some time. I just don't want it to be wasted.
The "final" idea would be to use LISP for web development, and I know that's not so common so... I know it's good to plan my learning before picking the first book or tutorial and spending lots of time on something that may not be the best way!
Thank you all for your answers!
edit: I read Practical Common Lisp and was: ... long, hard, interesting and definitely got me rolling in Lisp, after that i read the little schemer, and it was short, fun and very very good for my overall programming. So my recommendation would be to read first the little schemer, then (its a couple of hours and its worth it) if you decide lisp(or scheme or whatever dialect) is not what you where looking for, you will still have a very fun new way of thinking about recursion!
Try reading Practical Common Lisp, by Peter Seibel.
My personal favorite is Abelson & Sussman Structure and Interpretation of Computer Programs.
It uses Scheme, which is a nice and clean dialect of Lisp.
If you like a more practical approach maybe you should pick some Lisp framework for web design
(I have no idea if such a beast exists) and jump right in.
You might want to start with The Little Schemer as a warm-up. It's not a practical book about writing production Lisp programs, but it's a great book for learning how to think in Lisp.
MIT has made available an entire LISP course in DIVX and MPEG format. I highly recommend it.
http://groups.csail.mit.edu/mac/classes/6.001/abelson-sussman-lectures/
There is now a book out called 'Land of LISP' that teaches LISP programming through writing 80's style text games. I'm reading it now, and it's very well written and doesn't take itself too seriously, which I like.
There are several options here. First of all, Scheme and Common Lisp are fairly different in rather deep ways (like scoping); you should pick one to start with and stick with it for a while. I'm a Common Lisp fan, but that may be one of those vi-vs-EMACS religious questions.
For Scheme, go for Kent Dybvig's Scheme Programming Language, followed by SICP.
For Common Lisp, as well as Practical Common Lisp, I'd recommend David Lamkins's Successful Lisp. Successful Lisp is also available online for free.
After than, look at Lisp in Small Pieces by Queinnec, and Norvig's Lisp in AI book.
Marty Hall has a nice list at Johns Hopkins.
Updated: I don't mean stick to it forever, just that trying to learn both at once would be confusing.
Pick up The Land of Lisp by Conrad Barski. It is a fun filled introduction to Lisp programming using cartoons and games.
I'd recommend Project Euler as an excellent source of small bite-sized problems you can use to teach yourself any new programming language.
Ansi Common Lisp by Paul Graham is a good book.
I think it might be out of print, so your best bet to get it via Amazon.
I got the book for a "Natural Language Processing" class I took my sophomore year in college.
We had to write the programing projects in LISP, and so I needed to learn Lisp quickly.
The book helped me quite a bit.
Once I had a problem. I didn't know lisp. So I decided to download LISP in a box.
Then I found myself with an Emacs install without any help or documentation.
Then I had two problems.
For serious learners, I'd recommend PAIP from Norvig. It is an excellent resource to learn both Lisp and AI.
Berkeley offers CS61a in podcast format. This is an intro to CS class based around SICP. It's a more modern version than the 1982 videos MIT has available.
I'm working my way through Lisp right now and have come across "the book" to learn Lisp. It was suggested by Rainer Joswig
The book is called Common Lisp: A Gentle Introduction to Symbolic Computation and can be downloaded as a PDF. The author begins with a UML like approach to Lisp in the first chapter and gradually introduces more and more Lisp syntax.
I've also looked at practical lisp and I think that the author glosses over a lot of required information, even for a seasoned programmer. This book doesn't seem to do that (I'm not completely finished, but have found it useful enough to suggest).
one more thing, you'll need an environment to work in. I've found Lisp in a Box to work well. It runs on Windows and Linux and uses eMacs.
I've got attracted to LISP by its JVM dialect - Clojure. Clojure is sort of great LISP, since
it has "simplified syntax", that is less parathensis are required, there is cleverly design set of collections available
it is JVM based, so there is stable, performant runtime underneath, in addition whole Java ecosystem (libraries, e.g. database drivers, build tools, IDEs) is within our reach
Noir is a good web framework, apps can be deployed on Java web and applications servers
In other words, Clojure can be used in production right here, right now.
When it comes to resources, there are at least 4 books and planty online resources:
Books: "The joy of Clojure" - very insightful but can be difficult, so it's best read together with "Programming Clojure".
Online tutorials: Mark Volkmann tutorial is great
see also https://stackoverflow.com/questions/599519/which-tutorial-on-clojure-is-best
4Clojure website contains a number of simple programming tasks, so one can play with Clojure and see other people solutions
I enjoyed reading Practical Common LISP and ANSI Common LISP.
On LISP looks interesting, but at $190 seems a little expensive for a book.
For web development you might want to have a look at hunchentoot, a web server written in common lisp.
I found working through the exercises in "The Little Schemer" really helped hone the recursive, pattern-matching side of my thinking and made working in XSLT considerably easier.
I recommend Gentle Introduction to Symbolic Computation or Practical Common Lisp first, based on your programming experiences. For practicing, I use Allegro CL 8.2 Free Express Edition in Windows. It turns practicing into a lot of fun.
Sort of a difficult question to answer ... I think it all depends on your learning style.
I learned LISP in my A.I. and Expert Systems classes in college, but that's how I learn ... I'm not a great book learner, I prefer to have someone explain it to me in a class setting.
LISP is definitely a unique language and it requires a new train of thought if you're used to conventional C, Java, PHP programming.
Best of luck to you !
I found reading the book SICP really helped me learn. I used Steel Bank Common Lisp (SBCL) and had good success with it.
Good luck
I don't know that there's anything special about Lisp that makes it different from learning any other language. You just need to start using it and trying out its features.
One option might be to try a simple project.
Another option, that's specific for Lisp, would be to write an Emacs extension that assists you in your regular work.
Read these books in order: Gentle Introduction to Symbolic Computation, ANSI Common Lisp by Paul Graham and then move onto Practical Common Lisp. Or skip ACL and use it as a reference while working your way through PCL.