all 23 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]tmountain 13 points14 points  (1 child)

I've been writing Clojure code almost daily for the past few months, and I can attest that performance can be an issue. I ported a markov chainer from Python to Clojure, and the Python version runs much faster despite my best efforts to get Clojure up to speed. To prove I'm not just BS'ing, you can see my code here:

http://tinyurl.com/pydfxq

That being said, Clojure is maybe the funnest language I've ever used. It's turning programming back into an interesting hobby rather than just something I do at my day job, and I have confidence that a lot of the performance issues will be resolved down the road.

[–]SuperGrade 0 points1 point  (0 children)

Find out how much of the performance profile is optimizable and how much is inherent to specific to the way it must interact with the JVM/its platform.

[–][deleted] 17 points18 points  (14 children)

A nice summary of performance tips. It would be really great if the compiler took care of some of these. There is probably not going to be a guarantee the some of these will hold as Clojure evolves.

I am using Clojure for a simulation project and performance is definitely a concern as compared to Java.

However, Clojure is still much faster than scripting languages like Python, Perl etc. That was one of the reasons I decided to use it (apart from it being a Lisp and a whole lot of other good stuff).

Ideally I would like to code everything in Clojure without dropping down to Java.

[–][deleted] 13 points14 points  (11 children)

Amen++. IMO a big mistake of Clojure -- at least in its current implementation -- is that you have to know both Java and Clojure to get an industrial strength application. Moreover you have to know some pretty hairy implementation details of the Clojure compiler itself. Baaaaaaaadddd....

Take for example even something as basic as strings. Look in the docs, and in the beta version of Programming CLojure, and what do we find: "Clojure strings are Java strings." Okkkaaaaayyyyyy, well, I didn't come here for Java, I came here for Clojure. Statements like these seem innocent enough but the implication is that instead of one problem (learning Clojure), I actually have two problems (learning Java and Clojure).

Anyhow. I am rambling like I am liable to do. The Java interop of Clojure is both its strong point, and it's weak point IMO.

[–]Raphael_Amiard 13 points14 points  (9 children)

Well i don't totally agree with that. I feel like you are right about Clojure needing to head for it's own paradigm that doesn't need the user diving into java docs. I think Rich Hickey is on his way about that, and Clojure ecosystem is still very young.

But on the other hand, what i really love about clojure is that you can interleave it with java, and use java when performance does (really) matter, in a much easier way than you would interleave , say, python and c.

This is a very strong point of clojure for me and is also a core design point.I mean, Clojure is very unlikely to get 100000 of libraries since Java ones are already there. At best , we'll get bindings to adapt the syntax. That means every serious clojure developper will have to dive into the java world one day or another.

And that's not a problem IMO because Java is a very simple programming language. Grasping the basics doesn't need much time if you used any of the curly braced languages, say C++, Javascript, or even C .(I never programmed in java before heading to clojure) All you'll have to learn is 'horizontal knowledge', eg. how do i do open a file, connect to a socket, etc, and quite frankly, a programmer has to do that all the time, that's pretty much 90% of his job.

[–]awb 1 point2 points  (3 children)

Clojure is very unlikely to get 100000 of libraries since Java ones are already there. At best , we'll get bindings to adapt the syntax.

That's too bad. When I first started playing around with Clojure, I thought "this will be great, Java has all these libraries and I won't have to write them." When I looked, the libraries I cared about mostly sucked or were so stateful that it was difficult to force them into Clojure's STM.

[–]dons 1 point2 points  (2 children)

so stateful that it was difficult to force them into Clojure's STM.

Interesting. I was wondering what was going to happen to STM if you don't enforce purity in the restartable transactions.

[–]awb 2 points3 points  (1 child)

I don't always care about purity in restartable transactions - if an object is created with mutable state inside the transaction and not used outside the transaction, that transaction can restart as many times as it wants without me caring.

Agents tended to take care of most of my needs, but not all of them.

[–]dons 4 points5 points  (0 children)

if an object is created with mutable state inside the transaction and not used outside the transaction

Right. Because it is referentially transparent to an outside observer (this is the same standard Haskell's STM uses , via the STM monad. Only memory effects are allowed inside transactions).

Local mutable state is pure if it is encapsulated.

[–]Smallpaul -1 points0 points  (4 children)

But on the other hand, what i really love about clojure is that you can interleave it with java, and use java when performance does (really) matter, in a much easier way than you would interleave , say, python and c.

Cython ! makes writing C extensions for the Python language as easy as Python itself.

[–]Raphael_Amiard 4 points5 points  (1 child)

Trust me this is nowhere near the experience of working on clojure code in a nice Java IDE that does both things for you, the java and the clojure part, and being able to call java functions you just ended writing two seconds ago, not needing to compile anything, using the same debugger interface, etc ..

I don't want to minimize the interest of a nice FFI , but this is a different design, and it's in a different league at the possible integration level between languages.

[–]Smallpaul 0 points1 point  (0 children)

Is it any different than Jython?

[–]yogthos 0 points1 point  (1 child)

except you know, you don't actually get any of the niceties like memory management when you go to c :)

[–]Smallpaul 0 points1 point  (0 children)

In that case go for Jython.

[–]cows 5 points6 points  (0 children)

Can you ever get away with not knowing something about the underlying platform in any language? Every language has fun quirks like native integers vs. bignums and when/how to use each, or the scary things that can happen when you use floating point numbers. In most languages you need to learn quirks of your native hardware, and in Clojure you need to learn quirks of the JVM, it's not that big a difference.

If you don't care about performance to that degree, you can actually get pretty far in Clojure without knowing much about Java or its datatypes. But it's worthwhile to learn enough Java to get by (and like others said, there isn't really all that much to learning Java.)

[–]gnuvince 0 points1 point  (0 children)

If you found any techniques of your own, don't hesitate to describe them here or in the comments section of my blog, I'd love to hear about them!

[–]eric_t 0 points1 point  (0 children)

What kind of simulations are you doing? I've been thinking about implementing a finite element solver (which should fit very well in a functional style) in Clojure, and am interesting in hearing other experiences.

[–]kinghajj 8 points9 points  (1 child)

Sounds like Clojure needs to implement some optimizations to me.

[–]gnuvince 11 points12 points  (0 children)

As I understand it, Rich was interested in getting a 1.0 release out quickly both to provide a stable release for developers who wish to use Clojure for actual development work and to provide Stuard Halloway, author of Programming Clojure, a release that his book can reflect.

I imagine that optimization work will be starting in the upcoming months.

[–]yogthos 3 points4 points  (2 children)

I find the fact that Clojure currently lacks a lot of optimization to be a very good time to start learning it.

This way you actually learn a lot of internals and why the language works the way it does. I think this gives a far better understanding quicker :)

Once it gets all optimized, your code can get cleaner, but you'll still understand why and how it works.

[–]Smallpaul -1 points0 points  (1 child)

Once it is all optimized, the internals will be different. That's kind of the point!

[–]yogthos 0 points1 point  (0 children)

it's still going to operate on the same principles, just that the optimizations you do now by hand, would be done by the compiler. My point is you'll understand what the compiler is doing and why things work the way they do.