Everyone seems to be all up in arms about Clojure latley. Isn't this just another language? I have to admit I have not done any deep digging into what makes it so newsworthy which is why I am asking here...What am I missing?
Clojure is a lisp and a lisp is rarely just another language.
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.
I think what he means by most lisps is the fact that there are literary thousands of toy lisps implementing only the basic functionality of lisp ( lambda, logical operations , define, ca(d)r, first class functions,etc...) that people write just to learn how to write a lisp. They don't have any libraries or nearly anything to do something useful.
> Like SBCL, Clozure, Gambit/C, DrScheme/Racket, Franz, Lispworks? These, and others, are very solid tools.
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.
Clojure is great if you happen to be tied to the JVM. It is fantastic to have something usable on such an environment. However, outside that environment there is little advantage compared to Common Lisp, since Clojure drags this huge piece of crap that is the JVM. I would much prefer to have libraries in the Python style -- that is, being able to connect to real, native object code in several architectures.
Clojure drags this huge piece of crap that is the JVM
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.
Many of the problems of Java are inherited from the JVM: poor performance compared to native code, long load times, funky classpath issues. Hell, Java could even be a better language if it didn't require a JVM (this is probably what the Android guys think, too). I don't see why a Lisp needs to use it, if is not for compatibility with existing Java code.
The performance of the JVM is phenomenally good with any modern implementation. The only issue remaining is the relatively poor loading time of the JVM. Hence, short tasks/scripts make little sense to run because the overhead of the startup overshadows the performance of the JVM.
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.
This is the official truth, and I agree that it must be true when you talk about benchmarks. But there is not application written in Java that I know of that runs faster than a similar application written in C/C++.
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.
It's unfair to compare JVM performance with that of C/C++ ones. Given the kind of high-level language that Clojure is, it doesn't matter if it's slightly slow than a C program.
Today, developer time is more expensive than CPU time.
Those aren't problems with Java, they are (respectively) something that isn't important in many cases (and not even always true), something that is really only bothersome for short-running scripts, and a severe annoyance that can nonetheless be overcome fairly easily. There are plenty of reasons for a Lisp, or any language for that matter, to use it - a highly developed GC and JIT compilation capability that you don't have to write and maintain yourself not least among them. And the massive array of existing libraries that already run on the platform is not a negligible benefit in the least.
When will I stop hearing this story about "poor Java performance compared to native code"?
Just look at the shootout results, where Java is as fast as fastest native code compilers and and an order of magnitude faster then all other lisps there.
Java was about, dragging the C++ programmers half way towards Lisp. Maybe Clojure is about moving them further up to 90%... (and the last 10% is the JRE)!
JVM may be crap (or not), but it is widely deployed. In other words, widely available.
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.
Do you like lisp(s)? Do you like the flexibility it provides?
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?
You don't have to like lisps to like Clojure. In fact it's just irrelevant. There are plenty of people in the community for whom Clojure is their first lisp.
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 ...
Your list is the completely wrong set of questions to be asking when considering Clojure.
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".
Except I have answers for those questions. And those influence my decisions in real life. I like puppies. And I abhor murder.
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.
I have found lisps to be one of the more polarizing languages when it comes to opinion. Most people who have experience with one, either love them or hate them.
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 think this is a problem with Lisp people. Lisp is a good language, but their users are too emotional about it. They always think in terms or loving or hating it.
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.
since Clojure is a lisp, how can you like Clojure without liking lisp in the abstract? Clojure might be someone's first exposure to lisp, but then they would answer "I don't know if I like lisp or not".
It's a modern lisp with exceptionally good concurrency primitives. Unless you're an Erlang programmer, you will be hard-pressed to find a library that gives you such effortless multiple-core options.
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.
> 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.
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?
Yes, well I'm an engineer first and an entrepreneur second. I would love to see the whole world use great technology so everything works better and is easier to extend.
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.
We're all (almost) using some subset of functional programming. (Even working in something like PHP.) We're also almost all not using Lisp, Haskell or even Scala. Lisp had brilliant ideas that became mainstream and widespread; that is not contestable.
There are still many more brilliant and powerful ideas from Common Lisp that have not been adopted, despite being demonstrably superior. Hopefully everyone else can catch up so your pronouncement of Lisp's death can be made true.
Want an example? Condition handlers and restarts; no one else does this as well as Common Lisp did in the early 90's.
I wanted to learn a Lisp so I started with Clojure thinking it would be the more practical choice. Unfortunately, I found that for every 1 part lisp I was learning I had to learn 2 parts Java, which kinda defeated the purpose of my goal of learning a lisp in the first place.
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).
It has been designed for teaching so there is a lot of material on their site geared towards learning. As part of that, it has a nice set of tools that make it easy to get started.
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.
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 also think Racket is a good introduction to Lisp. The documentation is great. Take a look at the vector documentation as an example http://docs.racket-lang.org/reference/vectors.html?q=vector&.... If you are not familiar with the language, there are plenty of examples to help you get going.
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.
Racket is great, and I'm not trying to pick nits, but it's not a Lisp, it's a Scheme dialect. If you want to learn pure Lisp, I'd recommend Paul Graham's book, On Lisp, which is available online for free.
I'm looking forward to Land of Lisp being released to help me learn. Noticed it when that No Starch 50% off e-books offer was mentioned on HN the other day. Looks like a good started guide, plus making games always helps with motivation.
Well to offer a counter perspective, i began and tried to learn lisp with Common Lisp and Seibel's "Practical Common Lisp" book. I got totally overwhelmed by the sum and quantity of knowledge to absorb, and by the fact that finding libraries to do "fun" things was very difficult.
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 ;)
I know many people are put off by what they see as the paternalistic nature of Java. Trying to protect the programmer from themselves by reducing the power and expressiveness that is available in many other languages.
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.
For most people I talk to and for myself as well the hate is not for Java the language per se. It's for Java the Standard library and ecosystem. Java the language doesn't suck.
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.
Where's the "furious hate" in noting that you're not just having to learn the language in question, but also an environment that's built around another language entirely?
Every language that gains a big following will be hated upon. Compare it PHP, which is still the most used web scripting language. Even though it has it's pitfalls it's WTF's, it still seems to recieve much more hate than it deserves.
You aren't at this time going to get around knowing the jvm infrastructure. That is a requirement. But, you can accomplish a lot without getting too dirty with java itself.
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.
I wouldn't have recommended the rationale if he had asked "Why do YOU care about Clojure." Not knowing anything about him other than his self-confessed lack of effort, I thought it best to point him to some source material, not tell him what suits ME (which he didn't ask anyway). Also, no fair someone else getting karma for posting the link to the rationale. I left it out in hopes that the lazy questioner would lift at least one finger in his quest for Clojure knowledge (no, not THAT finger).
Lisp-style languages give you homoiconicity and macros which allow you to build complex abstractions. For example you can write (with-resource x (do....)) where with-resource handles resource allocation and cleanup. That particular example can of course be done with decorators in Python or blocks in Ruby but lisp macros go further by letting you rewrite code at compile time.
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.
same thing happened to Ruby as well. and to Python. and to Java. .net is a different thing, lot people were just forced into it.
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 :)
Lots of people regard lisp language as toys or "scientists" languages that isn't usable in the real world to solve real problem. (It might not be the opinion on hacker news, obviously). So, then, come clojure which is a lisp based language that is smartly integrated with the java platform.. so now, you get the power of lisp with the usability and friendliness of java.
Well the thing is, 50 years ago, the Lisp guys were 30 years ahead of everyone else. Back then, they would say, look at our huge standard library! and everyone would be impressed. But next to J2EE or .NET or even batteries-included distros of Python, Ruby, Tcl, Perl + CPAN, the Lisp library looks pretty paltry[1], especially when it comes to interacting with the outside world (databases, GUIs, web programming, etc etc) - the sorts of things that working programmers do every day. Most people aren't researching algorithms, they're doing what we used to call forms and reports.
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'.
One of my favorite things about Clojure is how it does away with much of this boiler-plate. With macros and the general style of lisp, I turned a very boiler-platey java project into an extremely compact clojure project.
I really enjoy how I can look at the clojure code and easily see the flow of what I'm actually trying to do.
It's friendly in more the social/cooperative sense than the sense that it's easy to work with in itself: there are a lot of very good libraries, the runtime is pretty much fully baked, and you get a wide choice of development tools.
So there is a breadth of support you don't get elsewhere? I wouldn't argue with that. When it comes to breadth of support, it is hard to argue against java, php etc.
Compared to many of the alternatives, Javas is very friendly. There aren't too many ways you can shoot yourself in the head, and it mostely does what you would expect it to do.
We have a difference of opinion on what is 'friendly'. I don't consider protecting me from shooting myself in the head to be 'friendly', I would call that 'paternalistic'.
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.
(As the author of the first comment), I said friendly in the sens beginner-friendly. Where they are a tons of documentation (online and books) available, tons of libraries, tons of person actually using it, lots of job opportunities, easy to learn, etc.
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 .
because i prefer the 'meta power' that smalltalk and lisp provide me.
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++.
It is important to point out that many of those Java libraries are not pleasant to use, to the point that I once found it easier to write a basic CSV library in Clojure than to interface with any of the Java CSV libraries I could find.
It's still a significant advantage to have the option, and some of the Java libs aren't so bad.
I admit that since I am tired of Java, so far I have shied away from trying Clojure because at the end of the day, I figure I should rather try one of the other interesting languages that are completely independent of Java.
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.
I've had more eye opening experiences programming in Clojure than in any language I learned before it. (C, C++, Java, Python, Ruby, common lisp) It provides a fairly unique set of tools that really let you boil programs down to their essence: persistent data structures, software transactional memory, and an amazing standard library for operating on maps, sets, and sequences. Instant access to Java libraries means it isn't just about academic beauty.
To each their own, but I highly suggest you take a weekend and experiment. You won't regret it.
I'm waiting for more than a few cherry-picked examples of people who talked their boss into letting them use it, and academic papers, to be interested. Clojure start-ups using it as a competitive advantage to make money competing against others trying to solve similar problems would be very very interesting. Some people seem to believe that its constructs for dealing with concurrency have such potential, but on the other hand I can't tell if any of this is real or cult-like hype. (Flame bait: look how excited people were about Haskell a couple of years ago, and to some extent still are.)
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."
"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."
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.
You'd think experienced engineers would know better than to say language A is categorically better than language B when the one thing real-world programming experience should teach you is that context is everything. Any engineering solution is a careful balance of tradeoffs and language design is no different.
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.
My question is not about art, but about who is using Lisps to make fantastic profit, against competitors trying to solve the same problem, in a way that would not be possible with more mainstream languages. If very few, it's not interesting in the industry. This is a shallow and narrow view but it also has the benefit of being observable and objective.
ITA's product backing the Orbitz system used Lisp heavily. They were just bought by google for a large sum of money. This isn't cherry picking, this is one of many real world examples you've never bothered to research.
Just because you don't pay attention to something doesn't mean it doesn't exist.
Using anecdotes to prove a point is precisely what I mean by cherry picking. I know that Lisp projects can be successful, but is there some systematic way to show that they're in fact more successful? Google and others throw money around at a lot of non-Lisp shops too. Because it's possible to succeed with method B does not mean that there is a reason to switch if what I value is success.
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.
> but is there some systematic way to show that they're in fact more successful?
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.
> 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.
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.
> Can you show these for any other language? In a way that's not arbitrary and self-selecting.
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?
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.
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?
At this point you are simply being a troll. You are using a classic troll script, i.e. a variant of "You suck. Prove to me that you don't." Are you actually looking to get something out of this conversation?
I take a Devil's Advocate style sometimes where I make a case and then learn by someone shooting me down in a logical manner, and when that happens I change my mind. (And that is one of the great pleasures of life). I am being sincere here. I am confrontational but I do learn things from conversations quite frequently.
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.
I think it isn't explored enough why Lisp, as such...has just not caught on ...
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
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.
Using Lisp in education generates surprisingly few Lisp programmers. The few are often very good, but they are still few. Using Lisp with SICP teaches quite a bit almost practical computer science, but not so much about writing 'real world' applications. Often students, after taking courses which use Lisp, get the impression that one calculates numbers using church numerals or that everything is done via hairy multiple recursive functions. Learning to reverse a list also does not leave a lasting impression on students.
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.
My two $0.02. I just built a small project in Clojure/Compojure. In this particular project the JVM, not the language, proved to be a bad fit (so I rewrote it in another language).
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.
This is one of the areas of programming language conversations that fascinates me. The area where differences in how people think bubble to the surface.
"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.
"They"? VimClojure seems to be pretty popular. Most people who use Clojure and Emacs combined already used Emacs for other Lisp programming projects before, so it definitely depends on the direction you're coming from. Java refugees tend to stick to Eclipse.
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)
How does Haskell compare to Clojure? Arbitrarily, I started with Haskell, and I have found it fascinating but very hard to apply to daily problems (given the difficulty of IO).
There's been some long, impassioned threads here (YC), stackoverflow, reddit, Lambda-ultimate. I invite you to dig deeper. You can't summarize a language's spec, implementations, libraries, community and tool support very well in a 2000 word blog post.
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.