10 ms·
None of these applies to Clojure, and by and large Clojure basically obsoletes Ruby and Python unless you have concerns about the jvm startup time (which you ca
by KirinDave 14y ago
None of these applies to Clojure, and by and large Clojure basically obsoletes Ruby and Python unless you have concerns about the jvm startup time (which you can work around with Nailgun, but many people don't). No, seriously, Clojure is a uniform attack on everything of value in the Ruby, Python and Node.js world, only with fantastic performance and more flexible syntax.
Indeed, criticizing "lisp" is difficult because it isn't really clear what you mean. Common Lisp? Well that has a lot of work done for you. Scheme? That's deliberately minimalist because it's not meant for everyday work until you go outside the core spec (e.g., PLT Scheme's libraries). Clisp? MacLisp? What?
Lisp didn't take off because it didn't take off. There isn't some deep unconscious wisdom being tapped by the masses that we can read with tea leaves and subtlety. These things are random. There is a parallel universe not far from this one where Anic is a big deal and Pike took off in place of Python.
Because to assume otherwise that would imply that everyone knows every language and some are uniform winners over others. Do you know every language you have rejected? Heck, do you even know the general characteristics of Lisp, or Haskell, or ML, or Anic, or Pike, or APL? No, and to really try and learn all of them would take a lot of time unless you're quite gifted. So the premiere and popular programming languages are as unpredictable as fashion.
All you and I can do in our quest to be great software engineers is try and choose tools that split the difference between The Best For the Job and the Best We Can Manage.
- drmrkela 14y agoWhy do you think it obsoletes Ruby&Python? It does target Ruby developer with borrowing some syntax, but the paradigm shift needed to jump on the "functional" train is quite big. It is nice language but it solves the problem that I don't have (performance&concurrency) so I am not all that eager to make a switch.
- KirinDave 14y agoEveryone has performance and concurrency problems, eventually. What's great about Clojure is it gives you a path to ease into them. Compare a Noir or even bare Compojure web service vs. a Sinatra web service. Is there really a big winner on brevity?
- drmrkela 14y agoI didn't try Compojure, but Noir seems succinct enough. It's just that functional programming doesn't blend well with my brain. For some problem it does, for some it doesn't. Since you mention performance, I am wondering and was not able to find any benchmarks in Noir vs. Sinatra for rest server for example.
- KirinDave 14y agoNoir is a series of extensions on Compojure. Anyways, I can give you bullshit benchmarks if you want. The numbers are sort of meaningless, the benchmark synthetic, the methodology poor but it's almost all against the server's favor. (GET "/hello" [] {:status 200 :body "Yo!"})) And then let's just httperf that from the same box like that is meaningful (it is not): ~ > httperf --hog --server localhost --port 9999 --uri=/hello --num-conn 5000 --num-calls 1 ... Connection rate: 4769.8 conn/s (0.2 ms/conn, <=1 concurrent connections) Connection time [ms]: min 0.2 avg 0.2 max 3.8 median 0.5 stddev 0.1 Connection time [ms]: connect 0.0 Connection length [replies/conn]: 1.000 ... Reply rate [replies/s]: min 0.0 avg 0.0 max 0.0 stddev 0.0 (0 samples) Reply time [ms]: response 0.2 transfer 0.0 Reply size [B]: header 98.0 content 3.0 footer 0.0 (total 101.0) Reply status: 1xx=0 2xx=4999 3xx=0 4xx=0 5xx=0 Similar benchmarks put a static sinatra responder at 3ms on my box. Again, these numbers are not precise or useful. They're just there to put some flags in the ground for further exploration should you want to do a rigorous comparison.
- drmrkela 14y agoDid I understand you correctly? 3ms vs. 0.2ms So we might be talking about order of a magnitude here?
- swah 14y agoI agree, some algorithms didn't translate well from Python to Clojure. Also, I wouldn't want to process mp3 files in Clojure... but that is probably a good match for Java.
- CJefferson 14y agoI don't think these things are as random as you would like to believe. A large number of people tried for a large number of years to get lisp to take off. It isn't just bad luck that lisp didn't take off, and I think this article does a good job of outlining some reasons why. I don't have to personally know every language. Languages grow in popularity by picking up users. It is clear lisp was and is very popular with certain segments of programmers, and ever caught on with others.
- KirinDave 14y ago> A large number of people tried for a large number of years to get lisp to take off. You know, it was fairly popular for a time. > I don't have to personally know every language. Languages grow in popularity by picking up users. This is a tautology. But let's pretend for a second what you meant to say was "Languages deserve the usership they gain in a sort of mindshare stock exchange." Then let's rewind 10 years and show you Clojure, Ruby, Java, and Javascript. Can you ever imagine someone from 2002 picking Javascript over those alternatives? Someone sane, I mean. All praise to the pragmatism of the 'net, but Javascript's popularity is a function of its largely unrequested deployment and the failure of competing products (mostly due to artificial and non-technical business-enforced nonsense). And yet here we are with Javascript being so popular that startups are raising $9m just to build frameworks in them. And yet by any reasonable metric Javascript is a "worse" language. The most highly-recommended starter book for javascript is "The Good Parts", because a whole lot of the language is just so bad it has to be ignored or worked around. All we're really doing is appealing to popularity as a justification for using perceived popularity instead of real technical metrics. Which is–to some extent, anyways–fine and good; it certainly is traditional for people to do this. But let's not pretend we have access to some deeper insight while we're doing it.
- moe 14y agoWhat's with the strawman? CJefferson didn't even mention Javascript. Javascript is not the only language that surpassed Lisp in popularity, far from it.
- 14y ago
- dhkl 14y ago> by and large Clojure basically obsoletes Ruby and Python Care to qualify how Clojure obsoletes Ruby or Python? Both of those languages have great tools (rails, for example) that those in the Clojure communities have great respect for. As a Clojure and Ruby/Rails programmer, I share your enthusiasm for Clojure and lisp, but I can't see Clojure pushing either Ruby or Python out of the water any time soon.
- KirinDave 14y ago> Both of those languages have great tools (rails, for example) I am surprised a Clojure programmer would have much respect for Rails. Its aggressive share-nothing approach leads to inconsistency, poor performance, awkward architectures, and over-reliance on external state management. Perhaps one might admire it for making a bold claim about configuration vs. convention, but a valid criticism of Rails is that they went so far along the convention line in rebellion of bad tools like Spring that now they get accused of excessive magic. > But I can't see Clojure pushing either Ruby or Python out of the water any time soon. Like I said, success is fashion. But then, people said this to me about Git Vs. SVN after I gave a tech talk to a bunch of ruby folks about how git would take over the world. Two people left that talk and went on to found Github, so... "High Fashion." Clojure has all the power of Ruby's dynamism, but with a better solution to the expression problem (protocols are namespace contained, allowing for monkey-patching that doesn't taint the world). It has access to a lot of fantastic high-performance libraries. It can safely deal with high degrees of parallelism with a degree of ease few environments can claim. It has a minimalist syntax which can compete with even the most terse and convention-driven ruby syntax (i.e., Compojure vs. Sinatra). Similar complaints can be leveled at Python with less of a performance angle and more of a power angle; Clojure gives you access to many of those features that the python community feels are "too awkward" to use in the OO world, but are entirely natural in the Lisp world. So yeah, every time someone writes a server in Node.js I think to myself, "You could have done it in Clojure and had just as much dynamism during development, just as easy a deployment story, and also perform easily an order magnitude faster under load, and you don't have to run like a scared child from parallelism."
- deleted 14y ago[deleted]
- plinkplonk 14y ago"Clojure basically obsoletes Ruby and Python" "Clojure is a uniform attack on everything of value in the Ruby, Python and Node.js world" This kind of smugness[1] is one reason why Clojure will never take over the world. It seems to be some kind of unwritten rule that every Clojure evangelist has to knock another language in any post anywhere [2]. Ugh. I am a great admirer of Rich Hickey (the man is a genius), and am happily using Clojure in my present project, but this kind of triumphalist rhetoric is a big turn off. I don't think Clojure "obsoletes" Ruby or Python, anymore than Haskell or Erlang "obsoletes" the various lisps. [1] This attitude seems particularly endemic amongst people who've moved to Clojure from the early Ruby on Rails community, where sneering at alternative frameworks was part of the culture. Rich Hickey, while justifiably proud of his language, as he should be, never makes silly statements like this. [2] see http://news.ycombinator.com/item?id=4272186 http://news.ycombinator.com/item?id=4272186 for an embedded gratuitous swipe at Scala in an otherwise insightful post.
- KirinDave 14y agoI am not going to be your proxy for every perceived irritant in the course of discussing lisp. Asking me to be this is unfair. You can say I am some sort of hater and now it's Rails's turn, but I've been consistent with this even when I was a full time rails programmer [1]. You can find essays by me on the inadequacies of Rails dating back years now [2]. The very things I was complaining about in 2007 are now the glaring flaws in modern Rails. So I made the decision to strike out for tools that don't have a cultural bias against progress in areas I believe important. So, if I am a Smug Lisp Weenie, then surely I am also a Smug Scala Weenie. And a Smug Erlang Weenie. And a Smug Haskell Weenie. And a Smug Ruby Weenie. And a Smug Hadoop Weenie. And a Smug C weenie... Because one thing I've made very clear is that I think attachment to tools is the problem. We should always aim to use the best tools at our disposal, and I think the place where Python and Ruby are the best tools are shrinking under the onslaught of the competition. Argument from familiarity is something I simply cannot bear to listen to anymore. If believing this makes me smug then I guess I am smug. [1] http://www.oreillynet.com/ruby/blog/2007/06/multicore_hardware_and_the_fut.html http://www.oreillynet.com/ruby/blog/2007/06/multicore_hardwa... [2] http://dave.fayr.am/posts/2008-11-20-the-opposite-of-momentum.html http://dave.fayr.am/posts/2008-11-20-the-opposite-of-momentu...
- batista 14y ago>Because to assume otherwise that would imply that everyone knows every language and some are uniform winners over others. Do you know every language you have rejected? Heck, do you even know the general characteristics of Lisp, or Haskell, or ML, or Anic, or Pike, or APL? No, and to really try and learn all of them would take a lot of time unless you're quite gifted. So the premiere and popular programming languages are as unpredictable as fashion. That's quite a jump to an (invalid) conclusion. Sure, no programmer has knows of all the languages he does not use or has rejected. But that doesn't mean that there is not a reason some language gain traction and get to be known by lots of programmers and others do not. You seem to have the simple minded view that simply because I haven't heard of all the languages I don't use, it is random which ones I do use. That's not how it works. It works by statistics and aggregates. I may not know language X I do not use, and I might know Y, which I do use. But this is not random, it's because of various forces at play, that made Y more widely known and X less so. For example, C provided raw speed with less memory use at a time it was very crucial, was easy to learn, had free/cheap compilers available, it was the language UNIX was written in, and it was simple enough. Oh, and portable. Those things got it traction. Lisp was mostly used in academia-AI, was slow at the time, compilers cost an arm and a leg and Lisp Machines even more so, and was associated with the "AI winter". Those are some reasons it did not do well.
- KirinDave 14y ago> You seem to have the simple minded view that simply because I haven't heard of all the languages I don't use, it is random which ones I do use. That's not how it works. But then: > But this is not random, it's because of various forces at play, that made Y more widely known and X less so. Where "various forces" is furious handwaving for the sheer randomness that made that set available to you. And let's say in a slightly different history that set is slightly different (but still contains your current choice), how do you know you would have ended up the same? But perhaps I am being lamentably simple minded. Every decision you make is deliberate and justifiable.
- batista 14y ago>Where "various forces" is furious handwaving for the sheer randomness that made that set available to you. You keep using that word, random. I don't think it means what you think it means. A coin toss is random. C picking up for the stuff we did in the eighties is not random. Lisp losing traction after the AI winter is not random. Javascript gaining traction with the web is not random. That the creation of C was effected by random events (the experiences of Ken Thompson, the position of AT&T, the decision to provide the source, etc), does not mean that the success was random. The success was logical and repeatable given the needs of the era and how the language came to be. To put it in another way, if another language had taken the role of C in the industry at the time, it would have been pretty similar to C, and with external qualifications (availability of source, portability, etc) similar to C. From this aspect, the (random) fact that it was C after all and not some other C-like language, doesn't matter at all. The language that would have filled C's role would have quacked like C, and that is the non-random, and substantial part. Read the "Worse is better" for some background.