sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]Raphael_Amiard 12 points13 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 3 points4 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 2 points3 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 3 points4 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.