On Aug 16, 2012, at 8:52 AM, Timothy Baldridge wrote:
With pip/easy_install and virtual_env, there's really not much of a point.
Would lein-py be nice? Yeah, but it's hardly a show-stopper.
What's the story like for code that depends on another clojure-py library?
Would the Python Package
Hey All,
ClojurePY is actually quite amazing. It has none of the complexities with
libraries and projects like Clojure and is suitable for crunching data
(because it's on Python) unlike Node.js/Clojurescript. You can use all the
python libraries. You can even import ipdb and step through your
It also uses less memory and has a faster startup time than Clojure. I'm
not sure how it compares to clojurescript in terms of speed and memory.
On Thu, Aug 16, 2012 at 8:00 AM, Sean Neilan s...@seanneilan.com wrote:
Hey All,
ClojurePY is actually quite amazing. It has none of the
You seriously think the lack of Leiningen is an advantage ?
facepalm
On Thursday, August 16, 2012 3:00:50 PM UTC+2, Sean Neilan wrote:
Hey All,
ClojurePY is actually quite amazing. It has none of the complexities with
libraries and projects like Clojure and is suitable for crunching data
You seriously think the lack of Leiningen is an advantage ?
facepalm
With pip/easy_install and virtual_env, there's really not much of a point.
Would lein-py be nice? Yeah, but it's hardly a show-stopper.
Timothy
--
You received this message because you are subscribed to the Google
Groups
It is absolutely an advantage. What I want is different from what you want.
I want standalone script files and Clojure will not do that. Tell me, why
do you like having project files for everything? If you're doing bigger
projects, I can understand why you want project files.
On Thu, Aug 16, 2012
Clojure is incredibly complicated.
I'd be careful about going that far. Clojure itself is not really that
complicated. I think it's more the restrictions the JVM puts on it. As an
example, see RestFn.java, AFn.java, etc. Since the python VM supports
first-class functions all that complexity
Yeah, you're right. Clojure itself is just a functional Lisp.
But, Clojure is at least 2 languages: Lisp Java. Lisp by itself isn't
that complicated but adding Java makes it much harder.
ClojurePY is Lisp and Python. Python has a lower barrier to entry than Java.
On Thu, Aug 16, 2012 at 9:11
With pip/easy_install and virtual_env, there's really not much of a point.
Would lein-py be nice? Yeah, but it's hardly a show-stopper.
To me, maintaining / distributing (virtual) python environments, even in a
small (but mixed) organisation, is more of a hassle than plonking in a few
I haven't really investigated clojurescript yet, but I was planning on
looking at it for small scripts where the startup time of the jvm is a
problem. Do you feel that clojurepy fills this need better than
clojurescript for any reasons other than speed? Or is it libraries like
numpy that
Clojure is Clojure, Java and how much of the core of the is written in it
is an implementation detail.
No build tool = pain in the In large projects.
Luc P.
Yeah, you're right. Clojure itself is just a functional Lisp.
But, Clojure is at least 2 languages: Lisp Java. Lisp by itself
No build tool = pain in the In large projects.
Why would you need a build tool for a language that isn't compiled?
Remember, Python != Java...there's no compiler in Python. More correctly
there is a bytecode compiler, but it's not really worth talking about. With
the proper hooks in
A lot of these implementation details bleed out into everyday language use,
let alone using platform libraries. I agree with Sean on that.
On Thursday, August 16, 2012 7:29:34 PM UTC+2, Luc wrote:
Clojure is Clojure, Java and how much of the core of the is written in it
is an implementation
Build tool here means a way to manage dependencies We have a product here
with
70 external dependencies, not convinced I would like to manage these by hand.
Btwy, we AOT our code before deployment for the following reasons
a) avoid shipping source code at a remote site
b) make sure all
Then its the same with the python implementation, read my other post :)
Having lein-py would hide some of these implementation details.
A lot of these implementation details bleed out into everyday language use,
let alone using platform libraries. I agree with Sean on that.
On Thursday,
I should add that Clojure on the JVM compiles to byte code on the fly and
it makes it as dynamic as the python implementation.
It has nothing to do with Java itself aside from Clojure's internal
implementation.
You can write Clojure code never referencing Java directly in your code.
Where the
The criticism towards Lein is totally uncalled for, it's small, simple,
lightweight and for the JVM it's a great clojure-centric way to gather and
manage dependencies. Yes, there's lots of options, but for simple projects,
you're done with a few lines of configuration. No-one could say it
Your comparison of Clojure's internal code is also slightly unfair. Afaik,
clojure-py is based on the Clojurescript codebase.
This seems to be a common misconception (and I'm not exactly sure why).
Clojure-py is a complete from scratch re-implementation of Clojure in
Python. It's more akin to
Clojurepy is nice and all, but with a slow startup time, I really don't
have a use for it. Coming from Clojure, I found clojurepy more complicated
than Clojure itself. Probably due to lack of documentation. What bothered
me the most is that it seems like they've changed things making it
This seems to be a common misconception (and I'm not exactly sure why).
Clojure-py is a complete from scratch re-implementation of Clojure in
Python
Didn't know that, that's pretty cool. You taking the effort to do it is
even more impressive.
I'm going to stop here and say that I
On Thursday, August 16, 2012 9:00:50 AM UTC-4, Sean Neilan wrote:
Hey All,
ClojurePY is actually quite amazing. It has none of the complexities with
libraries and projects like Clojure and is suitable for crunching data
(because it's on Python) unlike Node.js/Clojurescript. You can use
21 matches
Mail list logo
