If you don't know lisp or you don't want to know why you should know lisp, go take Scala or Haskell or Python. If, however, you do know—or you're willing to read a handful of Paul Graham's essays on lisp—let's continue:
Most importantly, Clojure is a lisp that is 1) not a toy, 2) not too standalone without a supported platform, and 3) not Common Lisp.
1) Most lisps are toys. It is logical because lisps are fun, profound, and nearly everyone (out of a certain demographic) has written a few. Then there are various Common Lisps, Scheme lisps, Emacs Lisp, and then few others that come as a part of some fairly important software library, and those aren't toys but usable at least in some specific environments. Clojure is a full-blown language that has actual development history past the "gee, i think this is going to be interesting" phase.
2) libraries and compatibility are so important these days. The Python language is gold because it has a fairly extensive standard library and bindings to nearly everything, even if it isn't a lisp. Most lisps have marginal effect and impact because they are so disconnected from the 2000's state of affairs. They're only drawn from the chambers and wielded in superimportant projects where the cost of building a suitable environment to host the lisp system is negligible to the actual problem to be solved.
3) Common Lisp was a good, practical, multi-paradigm lisp by the 80's standards. (Ok, path abstraction could've just worked everywhere right from the start.) But the technology ship has sailed 15 years ago and CL wasn't on it. So far, Common Lisp has been the best we lispers have got. But now that there's Clojure, it doesn't matter we lispers weren't on the ship because with Clojure we just got a jet flight to fifteen years in the future. And I don't think we even saw the ship sailing below during our flight.
> 1) Most lisps are toys
Like SBCL, Clozure, Gambit/C, DrScheme/Racket, Franz, Lispworks? These, and others, are very solid tools.
> 3) Common Lisp was a good, practical, multi-paradigm lisp by the 80's standards
I still get work from people who want Common Lisp development. CL still has legs :-)
re: 2) I largely agree, which is why I use Ruby for a lot of work
No, those are quite solid tools. Regardless of that, his point still stands -- most lisps are toys. I'm pretty sure that with a little looking I could find 10 toy variants for each practical variant you can name.
What about the huge piece of crap that is the GIL? I mean come on. Clojure is a good reason to care about the JVM. I'd completely given up on the JVM until Clojure landed since there was no great way to tap into it's power without adopting Java's problems. The JVM rocks.
But for long-running applications, the performance is very good, and the time it takes to load doesn't really matter. The startup time mostly effects the programmer, who has to start it up to debug the system so often. Clojure sort of mitigates this by having a REPL where you can do testing/debugging without restarting the JVM every time.
All the Java applications that I am required to run are slow, and when they perform well it is because they are using 10x the hardware required by a comparable C++ application.
Of course, if you are creating a network-bound application this doesn't matter much (I can even use Python or Perl for that), but when you want reasonable performance (e.g., on desktop applications), this idea shows to be completely wrong.
Today, developer time is more expensive than CPU time.
2) can you show some of these results where common lisp is at least 10x slower than java?
And performance is not that bad, really. Except for the startup time, it is better than most other languages, not just scripting languages. There has been a lot of effort invested in making JVM better.
If no, you probably shouldn't care too much about clojure. There are other languages which can help you with the same problems as clojure.
If yes,
do you find that Common Lisp is carrying too much legacy baggage?
or
that the various lisps lack the libraries you need?
or
that you can't use lisp for the jobs you want to because the infrastructure is considered too esoteric by those you answer to?
If yes to any of those,
clojure runs on top of the jvm and can be installed in a normal jvm infrastructure which many companies already run. It interoperates quite well with java so you have a vast array of existing libraries. it removes a lot of legacy burden that many lisps have.
that would be my quick primer on why you might care.
> Do you like lisp(s)? Do you like the flexibility it provides?
The questions should be:
* Do you like dynamic languages ?
* Do you interactive languages ?
* Do you hate wasting time recompiling your entire program
in your static language for a small change?
* Is your dynamic language too slow ?
* Do you want concurrency to be like child's play ?
* Are you tired of depending on immature libraries ?
* Do you want an evented webserver like Node.js that
doesn't force you to write callbacks?
* ... etc ...
EDIT: it's not that Clojure being a Lisp is not important. It's just not the first question I would ask myself when considering to adopt. My questions are specific to the process by which I want solve problems in a particular domain. The fact that is getting upvotes shows just how surface of an assessment people make when looking at Clojure - "Oh ... it's a Lisp".
* Do you like puppies?
* Do you hate murder?
* Would you like something like the tool you're using right now, but better?
Anyways, my questions are exactly the set of questions that led me to Clojure. Honestly, the main advantage of Clojure being a Lisp is macros. And I didn't bother mentioning those, because that's not something most programmers need/want (not without understanding how they work).
I think my list a pretty real list of things that many programmers want after some experience that Clojure satisfies that other languages do not, or not all at the same time.
You are correct that I didn't address the 'I have no experience with a lisp' crowd at all. I was specifically addressing those who have some experience with a lisp.
If you don't like lisp, I suspect that something like Scala would probably be more to your liking. I'd be very interested to hear from people who use clojure and enjoy it after not liking lisp before starting. I suspect they are few and far between, but I'm open to the idea that all of clojure's pluses ( ease of concurrency, ability to tap into java libraries etc ) might win people over.
I don't like, for example, reading Lisp books where half of the time is spent on selling the language: why it is the best thing since sliced bread and all.
Just let the features talk by themselves. Nobody needs to be indoctrinated into liking a language. Anyway, at the end, emotions are not gonna decide what language is used in a project.
While this is more opinion than strict fact, characterizing Lisp as "just another language" is a terrible mistake. Lisp's utterly malleable syntax and exceptionally good semantics make it a very powerful language, one of the few that has managed to keep reviving over and over despite massive change in our industry.
It's very unfortunate that modern programmer culture has taken so long in America to catch up with what Academia has been arguing for years: functional programming matters. Lisp has an even more obscure thesis: semantic customization matters. Clojure strikes a good balance in this regard; it does not ask the programmer to do much macro programming and many of the things you need are already written.
This kind of rhetoric is found on all programming discussion boards. What seems strange to me is what isn't expressed, especially in a place like this originally oriented toward real-world start-ups.
Someone who believed this and had an entrepreneurial spirit wouldn't think it was "unfortunate". They would be positively salivating and would think this fact was fantastic. If functional programming matters in the industry, what's stopping you from using it, and the parts that make a difference, to tackle some problems and solve them in a more effective and profitable way than your competitors?
Yes, fine, nobody will hire you. Well save up some ramen money and do it yourself. What am I missing? If all of the people who use this "functional programming matters" rhetoric really and truly and passionately believe this, they would accomplish proving their belief, benefiting the programming world as a whole, and making some fantastic profit in the process. Why don't I see more of this attitude (or barely any of it at all) from functional enthusiasts? What am I missing here?
Forgive me for not thinking of my golden parachute first.
P.S., As a Clojure programmer I am actually in demand. I've had the luxury of turning down job offers. I also made a lot of money working on Erlang, and I could still get a job doing that. There is no shortage of these jobs.
Want an example? Condition handlers and restarts; no one else does this as well as Common Lisp did in the early 90's.
I switched to Common Lisp and have been happy. There are some really great books for it and it's helped my overall programming skill. If I had to work with Java I would consider Clojure, but I didn't find it a particularly enlightening language, at least if you're trying to learn Lisp.
* The documentation is fantastic. Insanely easy to browse around, very well formatted, and interconnected nicely.
* It comprises of multiple languages, and they can all interoperate - r5rs, r6rs, racket, etc. This has always been a major pain point for me when it comes to Scheme dialects - lots of implementations clinging to r5rs and using incompatible module systems.
* PLaneT has a ton of libraries covering many fields, and it's great that it's integrated into the language (requiring something from PLaneT will automatically download it).
* The community seems nice enough.
I also love that the new site immediately shows off the language: http://racket-lang.org/
There are a lot of books that teach intro to programming in scheme so there is plenty of offline material as well. The little schemer, SICP, How To Design Programs.
See http://docs.racket-lang.org/.
It also has an active mailing list that is quite noob friendly.
EDIT: oh yes, and it is very a 'batteries included' environment. so you can worry about learning the language rather than getting your environment setup.
I recently started working through The Practice Of Programming and I wanted to compliment it with a functional language. I thought it would make the on ramp to functional languages a little smoother by first coding something in a language I'm familiar with and then port it over (producing more idiomatic scheme is the next iteration). I chose scheme as the compliment and PLT/Racket as the environment. So far, it has been working well.
It is.
"... pure Lisp ..."
There is no such a thing as "pure Lisp". Lisp is not a programming language, it's a family of programming languages that share some common properties.
To put it more clearly, we could represent Lisp and its members hierarchically:
Lisp
Common Lisp
CLISP
SBCL
...
Scheme
Racket
Gambit
Chicken
...
Clojure
...Then i tried clojure (with netbeans which has at the time quite a easy IDE integration that allowed me to not focus too much on the java side of things, unlike using clojure on the command line was at the time). I used it first to solve some project Eulers problems, and then began toying with some libs, notably QT Jambi, swing, compojure, etc. All this to say that learning it was a lot easier than learning Common Lisp, because at the time i began, it was a lot simpler language than Common Lisp. It still is, but i wonder if the protocols thing is not gonna considerably complicate a noob's approach to the language.
My advice to clojure newbies is, start with an IDE that makes it easy to interact with libraries and let you concentrate on the code, not on the ugly java stuff. You will have plenty of time to handle that later on if you really enjoy clojure ;)
Why that would rise to the level of 'furious hate', I don't know. I find it hard to grasp how anyone could hate a language. Hating a job where you have to use a language that frustrates you, that I can understand- but that has an easy solution. Find another job.
However java's standard libraries seem to have been designed to make you write a metric ton of code to do the simple stuff and a planets worth of code to write anything actually useful. I used to joke that someone needed to write a java.lang.{python,perl,ruby} namespace where sane people can use code to just get stuff done. Then along came JRuby,Rhino,Jython, and now Clojure so I guess in a way that's exactly what people did.
You need to know a few basic stream/reader concepts to do any I/O, and of course you'll need to know more if you want to use some Java libraries; most of it is easy to pick up as you go. But you can do a lot with pure Clojure.
Seriously, clojure.org includes a rationale for the language. Maybe you should give that a look. If you care about any of the points in the rationale, and if Clojure delivers on those points, then you may be in the ballpark of caring about Clojure.
That is to say, the reason for asking a question like this is not always laziness.
Clojure itself has better solutions to common shared-state concurrency patterns than other lisps (and most languages in general!): efficient persistent data structures, STM, various atomic reference types, etc.
And of course running on the JVM has many benefits: performance via the excellent JIT and GC, high quality libraries, great development and operations tools, and so on.
For veteran lisp hackers http://clojure.blip.tv/file/1313398/
For people just finding lisp http://blip.tv/file/982823
before the vast majority really accepts some technology, early adopters come in. they figure out better ways of doing stuff. until someone has a success story, people doubt new technologies. Ruby brought us a great object model and introduced a lot of perl / php people, or simply web developers shifting from anything else to metaprogramming. probably, until i faced Ruby, coming from .net / java background, i didn't know (that much) about it. neither about dynamic typing.
closure is - yet - another language, that's quite true. we don't speak much of a performance here (even though it seems to be great), hence it does introduce us to functional programming and makes us think differently about objects and persistence. it doesn't mean that you have to quit your job and start looking for haskel / closure / scheme / lisp job. it means that you _may_ benefit just from knowing how stuff works there.
remember s-expressions in Lisp? they nicely fit into .net expression trees, no surprise. smalltalk object model did work for Ruby. you may benefit from traits from scala in your Ruby code. and so on.
so, until there's some success story and bunch of libraries / great codebase / frameworks for development, most of people will stay aside. though you have a chance to get into the crowd :)
Clojure attempts to fix this by piggybacking on the vast Java platform. F# is another that uses this strategy.
[1] Want to use Oracle? Check out Franz's pricing. Commercial database connectivity is free with all the other languages I mentioned. I'm just not interested if I can't kick the tyres and take it for a spin.
i find boilerplate and attempts to protect me from myself to be the opposite of friendly. i also find jvm infrastructure to be less easy to deal with than the infrastructure that many other languages have.
i would replace 'friendliness of java' with 'breadth of support for'.
I really enjoy how I can look at the clojure code and easily see the flow of what I'm actually trying to do.
I would call allowing me to easily express what I want 'friendly'. I find lisps, smalltalk and their brethren to be friendly under my definition.
I know some authors recommend learning lisp as a first language because there are not a lot of syntax and you can focus on the important problems. However, from my experience, my university colleague hated lisp and prolog, preferred C++ and really liked C# and Java. Lots of them were pretty beginners or bad programmers, but still, you can't start somewhere and be already an expert.
So, hope it clarified what I mean by Java being friendly. And then, Clojure might be less friendly than java.. but still, in this mentality, might be more friendly than scheme .
plus, i hate managing memory when i don't have to.
if i still wrote stuff that had to snuggle up to the hardware, i would probably still be using c or c++ but, i'm not writing that type of code anymore so i don't have need to use c or c++.
Also perhaps if you are stuck in Java land, it might provide a means to escape.
It's still a significant advantage to have the option, and some of the Java libs aren't so bad.
It's a shame that apparently Clojure does not run well on Android yet. If you are forced to use Java (as is the case on Android), Clojure would probably be really sweet.
To each their own, but I highly suggest you take a weekend and experiment. You won't regret it.
My suspicion is that it is as close to a proven fact as you get in technology that real-world business programmers don't want Lisp. Yet it creates unequaled excitement and enthusiasm, as it has for half a century. A whole generation of top programmers trained at places like MIT were trained in Lisp from the very beginning. It had a firm foothold in places like Nasa. Yet how many of these programmers now use Lisp in the industry? I don't think very many, especially relative to the amount of enthusiasm people have for it. Lack of education and exposure and trials has most emphatically not been the issue here. Do the lead engineers at Google let their employees use Lisp? No. Now do all of you know something they don't or is it the other way around? Was Paul Graham's genius (as a programmer who spent his formative years learning BASIC) to use Lisp or was he a brilliant person with an ingenious idea to build a customizable online store in the mid 1990s and could have succeeded in any language? It seems to me that Lisp is so old and has failed to maintain a real foothold in the industry for so long that these questions demand answers. Postulating that maybe there are companies using Lisp in secret doesn't cut it here.
As a side note, one of Paul Graham's famous essays has a bizarre pieces of logic that goes "If Lisp makes you a better programmer, why not use it all the time?" It does not follow. Swinging a weighted bat might make you a better hitter, a ballroom bar might make you a better dancer, training at high altitudes might improve your cardio.
I close with this interesting quote from Tim Sweeney:
"Of course, it's easy to see how this undercurrent arises. When you release a language, you receive complaints from users about all the things they want to do and can't, and the ultimate way to satisfy all of these requests is to expose all metadata: make it extensible, make objects dynamic, and allow the possibility of completely dynamic typing. The end of the road here looks an awful lot like LISP and SmallTalk.
"If you go this route, one day you'll realize you evolved the ultimate hacker language, and it became a godawful mess for writing real programs."
Then people discover that during learning and experimenting one can create a huge mess using Lisp. There are many degrees of freedom. Additionally via meta-programming one can turn things upside down. That creates not much confidence for some people who like a more straight forward tool that provides one obvious way to do things.
Next one discovers that Lisp comes with its own ideas of deployment and runtimes. Numbers can be fixnums or bignums. Dividing two integers creates a rational number and the sauare root of -1 is not an error, but a complex number. There is an 'image' and it generates garbage that needs to be collected.
Lisp still is unique when seen at in its full incarnation, but for many it is not clear why they need its feature set and why they should live with the consequences its design choices bring.
Lisp is best, when one needs a symbolic language often using interactive tools for exploratory programming. Lisp is also fine, when one needs a programmable language for example offering macros. Once people get to like that, Lisp is a choice for domains where it would not be the first choice, just because these people like the tool.
For many other developers meta-programming, code as data, symbolic representations etc. is sounding more like baggage. Often intellectual baggage, which simply adds more layers to worry about.
But there is also a bunch of people coming to Lisp who used other tools, are fully understanding them and are looking for a new intellectual challenges. Some might go to the more theoretically pleasing languages (like Haskell), but some might be attracted by code as data and simple meta programming.
Thus I don't think Lisp will ever be a wide-spread first choice (because it is slightly too complicated for many users), but it will offer for a long time an alternative view of software development. Often you see people just taking from Lisp what they find useful (functions, macros, code as data, interactive use, ...) and bring those to the tools they use. That often creates the impression that most Lisp features are now available in other languages (like GC, virtual machines, self-hosting compilers, ...) and often in improved forms.
Fortunately Lisp still has areas and tools that are used to write interesting applications - it may just be that some of those applications are not that important for many people. Who cares about scheduling the use of space telescopes? Still planning and scheduling is a domain where Lisp is used and for example the usage of the Hubble Space Telescope is planned with a Lisp system (SPIKE). There we have symbolic representations of plans and a software that can create those. Sounds like a great core domain for using Lisp. Others, may find it fun hacking web sites using Lisp. It is for some a tool that they like to use, often because it fits their style of thinking.
A Stradivarius (a kind of ultimate hacker tool) in the hand of a master can change people lives. A Stradivarius in the hand of a lesser musician will probably still sound pretty good. A master with a second hand violin can still move us. A busted up violin can't be made to sound good.
There's a lot of coders out there with second-hand violins. I wonder what they could do if they all had the Stradivarius. In real life there is physical scarcity, in the world of code the scarcity is a product only of our lack of curiosity and drive.
In order to take this conversation in a more adult direction we should ask this: What the advantages and disadvantages of s-expr syntax, a jvm foundation and a pure functional core? What problems are made easier to solve by these features? What problems are made more difficult to solve by these features? What are the key tradeoffs vs the alternatives?
If you're one of those people that think FP is a silver bullet you're a missionary, not an engineer.
Just because you don't pay attention to something doesn't mean it doesn't exist.
If it makes programming more fun for you, great, but I think even that (if it's systematic for lots of different programmers) should impact the bottom line in some way that I could imagine measuring?
It just seems to me from casual observation that the success of Lisps is disproportionately low (not to be straw-manned into zero) compared to the enthusiasm and the exposure so many programmers have had to it through means like SICP at MIT. This is admittedly unscientific.
Please define "successful." If "success" is wide use, then you have defined your success in the most un-profound of manners.
> It just seems to me from casual observation that the success of Lisps is disproportionately low (not to be straw-manned into zero)
I'm not going to play this game with you. You've defined nonsensical metrics and then demand we play by them. Any specific examples I give (of which you could easily get for yourself with 5 minutes and a search engine) will be dismissed as "anecdotes" as you move your goalposts.
I do not care what you think, because I do not think you're interested in considering what I have to say. Let's enjoy our mutual indifference.
"Profitable", compared to using another language. There are many objective ways this could be shown that wouldn't be vulnerable to being shot down by a non-falsifiability engine (i.e. any data I don't like is just an anecdote). For example, someone could attempt to sample startups at different time periods and look at financial growth over some timeframe.
Basically I'm looking for a metric that would show that pure functional language choices matter in a positive way. Any metric would fascinate me. Even success in contest problems of some type, when others had a chance to compete on equal footing would be something.
Can you show these for any other language? In a way that's not arbitrary and self-selecting.
> For example, someone could attempt to sample startups at different time periods and look at financial growth over some timeframe.
Thanks for the laugh.
I suspect you could have sampled Java web startups vs those still using C, Perl and CGI back during the time of Java's explosive growth and seen a systematic difference in profitability.
> Thanks for the laugh.
So any idea that there could be some statistical correlation between language choice and any kind of measured success is, on the face of it, absurd?
Amazon.com has made a lot of money, hasn't it?
So any idea that there could be some statistical correlation between language choice and any kind of measured success is, on the face of it, absurd?
A relevant statistical correlation? Yes.
I think it isn't explored enough why Lisp, as such, (not to be straw-manned into the many brilliant and pioneering ideas that originated from it), has just not caught on very much. E.g. why does Google, with an army of PhDs, very consciously not let their top engineers use Lisps?
I postulate that, like Tim Sweeney's quote implies, that there really is a great cost (in terms of the problems that industrial programmers face) to the sort of extreme dynamicism that Lisps offer. Now some of the largest of those problems include what a company should do when their lead engineer quits in the middle of a project, managing extreme changing requirements, managing staff writing automated testing and creating documentation, and other things that may not be considered in pure academic study but where language choices and methodologies may make a large difference.
This has been the #1 troll on any lisp forum for 30 years. It has been explored ad nauseum. If you're being sincere (which I doubt) read Richard Gabriel
http://www.gemstone.com/pdf/OOCL_SuccessStory.pdf
I know many people who work on 'real programs' written in lisp and smalltalk. Just because usage of the language isn't common doesn't mean you can't write real programs in it.
I've heard plenty of horror stories about how you can write real programs in php yet, people do ( witness facebook ). IMO, you can write real programs in any language- it is just that each make different things easier to do than others.
Clojure (and possibly other Lisps) feels kind of like Vim to me. It's harder to understand at first, often un-intuitive, but I get the feeling that if I took the time to learn it I would have a new powerful tool that saved me a lot of time down the road.
I'm sure there are performance/capability reasons why it is a good language, but for me the terseness is it's most attractive aspect.
"It's harder to understand at first, often un-intuitive"
I always felt that way about VIM. With programming languages, 'the lisp way' has always been the best expression of how I usually think about solving problems.
My brain naturally gravitates towards solution that involve macros, recursion etc. I can remember the first time I came across Common Lisp's condition system- my brain immediately went- 'this is so much more logical than exceptions in java/smalltalk etc'.
I know people who find Haskell's pattern matching and guards completely foreign but are entirely at home with switch/case and if/else whereas to me they seem very close to one another.
Which is ironic because they keep suggesting to learn Emacs alongside Clojure and other Lisps!
The real irony is that there's barely any distinction between vim and emacs. The "editor wars" included a lot of size arguments, but with the rising popularity of vim as the de facto default vi (and increasing memory capacity), this is a pretty moot point. Vi have become ze enemy.
(The number of people who stick to a smaller vi is probably the same as uemacs users)
a couple big differences:
syntax is totally different. clojure is a lisp. haskell has more in common on a syntax level with ML ( amongst others ).
clojure runs on the jvm. haskell doesn't.
clojure is a dynamically typed language. haskell is statically typed.
http://searchyc.com/clojure?sort=by_points
http://groovyguts.wordpress.com/2010/01/08/10-reasons-to-lea...
http://stackoverflow.com/questions/2120946/what-kind-of-appl...
---------------
http://news.ycombinator.com/item?id=1072822
http://news.ycombinator.com/item?id=1074136