Hard to argue with. I don't have a Clojure environment running, but I'd like to see a comparison of Norvig's spell-checker, and Rich Hickey's Clojure translation: http://norvig.com/spell-correct.html
There is a port of the spell checker to clojure. What it does is grind the swap file for about two minutes, then abort with an out of memory exception. Sorry, don't have the link handy.
YMMV. I find that stuff I write in Ruby is faster than that I write in clojure. I suppose it depends on the problem space, if your problems are greatly speeded up by mutability and C bindings then clojure is not a perfect fit.
Sure. I'm not saying I'm a good programmer. From the comments here a lot of people seem surprised that any clojure version isn't automatically faster than a python one, just by the intrinsic fastness of clojure. I just don't think clojure is the go-to language for simple raw speed, but apparently I hit a nerve saying it's not super-fast because I'm getting downvoted.
As a clojure novice I would assume that just by using pmap over map, computation would be faster, but it doesn't seem like it, I've experimented a little but never gotten very good at optimizing speed in clojure, here's a little test where I thought I could get at some multi-core goodness by using pmap, but probably the lazy structures are fooling me.
I'm not sure why your comment is being down-voted, but I can say that my question to you definitely was not meant to imply that you might be a bad programmer. My only point is this: as a budding Haskell enthusiast I am constantly shocked by the difference in succinctness between my solutions and those of the experts. However, I would never say that because of my lack of familiarity with Haskell idioms Haskell is a verbose language.
The rote replacement of map with pmap will never work as a general solution because there is overhead involved with using pmap. The impact of the overhead requires thoughtfulness in usage on a case-by-case basis.
I find that a few real-life experiments with clojure has been disturbingly slow, and that it's not trivial to optimize speed with lazy structures and magic background threads. Although some web stuff I've done has been pretty spiffy.
Anecdotally, at what point this is true also seems to depend on the host OS. Windows 7's pmap was beneficial at a lower n than Mac OS X's for a simple O(n) function. I have always wondered why this is.
While sometimes it's great that you have the option to use C bindings in Ruby, my take is that if possible you should write stuff in Ruby when doing Ruby. If that's not the case you are not doing ruby, you are doing C.
I would write clojure and drop back to java for speed. Only in a extrem case I would then use C, but its possible. I haven't done it but read that its not all that bad. (there is a clojure wrapper.
Remember the mantra: servers are cheap, programmers are expensive. If you have a language that's significantly faster to develop with but at a small performance price, i'd still go with it.
If the app becomes a Google-sized success, then I'll worry about performance. Chances are I'll never have to.
You know, part of the reason Google is Google is that they were worried about performance from day 1 - every possible kind of performance.
AltaVista was king at the time. It gave low quality answers, true -- but it was also slow. All the early adopters that I know of that switched to Google were impressed more by its speed than by its quality - if you knew what you were searching for, you DID get high quality content from AltaVista at the time (much like you could with Google even before the recent "farmer" update, despite the complaints from all over). What you couldn't get from AltaVista, no matter how much you tried, was a speedy answer. AltaVista would take 5 seconds; Google would have a response in 0.05 seconds.
Unless your app is defining a new niche, you have to compete with the current players. Facebook needed to compete with MySpace. Google needed to compete with AltaVista.
Google did it by storing an index of the whole internet in Ram. That's performance you worry about from day one, not something you can add in retrospect.
> Google did it by storing an index of the whole internet in Ram. That's performance you worry about from day one, not something you can add in retrospect.
It really depends on implementation. I have changed many applications from RDBMS-based to file-based to memory-based when the need arose. Of course, if you intend speed to be your competitive advantage, then you need to optimize early.
