Earlier quoted context omitted.
There are few abandoned attempts. Writing from scratch those Java libraries, including a good quality AOT compiler and GC is not something to do as hobby on the weekends.
Don't need all those Java libraries if you've got good FFI with C libraries. Don't need AOT compilation; if you want performance, just stick with regular Clojure on the JVM. I'd love to just see a small general-purpose interpreted Clojure (quick start up, small memory footprint, easy access to C libs), even if it lacked concurrency features.
Simple Made Easy (2011)
31–38 of 38 posts
Re: Simple Made Easy (2011)
#32Earlier quoted context omitted.
There are few abandoned attempts. Writing from scratch those Java libraries, including a good quality AOT compiler and GC is not something to do as hobby on the weekends.
Don't need all those Java libraries if you've got good FFI with C libraries. Don't need AOT compilation; if you want performance, just stick with regular Clojure on the JVM. I'd love to just see a small general-purpose interpreted Clojure (quick start up, small memory footprint, easy access to C libs), even if it lacked concurrency features.
There's the abandoned ClojureC project (https://github.com/schani/clojurec). There's also JVM-to-native compilers like gcj or ExcelsiorJet.
But at the moment, it doesn't seem like there's an established way to do all that.
Re: Simple Made Easy (2011)
#33Earlier quoted context omitted.
Don't need all those Java libraries if you've got good FFI with C libraries. Don't need AOT compilation; if you want performance, just stick with regular Clojure on the JVM. I'd love to just see a small general-purpose interpreted Clojure (quick start up, small memory footprint, easy access to C libs), even if it lacked concurrency features.
For that I fail to see the point of why not use a Scheme or Common Lisp compiler instead.
Re: Simple Made Easy (2011)
#34One thing I've found super helpful on my current project (which happens to be node) is using OSS concepts and npm as a unit of modularity. Eg, everything is just a grab bag of functions in an npm module (sometimes with a closure holding some state - I either reject or don't understand FP people when they claim FP doesn't have state). Each module has tests, dependencies, a README, and if it is reusable by other projec…
If a function closes over immutable values, then the resulting closure is an immutable value. If a function closes over mutable state, then its mutable state, often even uglier then mutable objects or structs which actually make the exact contents easier to identify at least.
Re: Simple Made Easy (2011)
#35One thing I've found super helpful on my current project (which happens to be node) is using OSS concepts and npm as a unit of modularity. Eg, everything is just a grab bag of functions in an npm module (sometimes with a closure holding some state - I either reject or don't understand FP people when they claim FP doesn't have state). Each module has tests, dependencies, a README, and if it is reusable by other projec…
FP people have never claimed they don't have state. That's a straw man used to argue against something no one is saying. The claim is that there is no hidden state - everything is made explicit.
Re: Simple Made Easy (2011)
#36Earlier quoted context omitted.
Don't need all those Java libraries if you've got good FFI with C libraries. Don't need AOT compilation; if you want performance, just stick with regular Clojure on the JVM. I'd love to just see a small general-purpose interpreted Clojure (quick start up, small memory footprint, easy access to C libs), even if it lacked concurrency features.
For that I fail to see the point of why not use a Scheme or Common Lisp compiler instead.
* literal syntax for maps, vectors, sets, and regexes
* keywords
* clear separation of functional constructs (`for`, `map`, etc.) vs side-effecting ones (`do`, `doall`, `when`).
* large standard library of built-in functions, with overall fairly nice naming of things.
I've looked at Scheme, but it appears to be missing those things. I think some of them may be provided by srfi's, but upon a quick reading I couldn't make much sense of how to include and use them.
Re: Simple Made Easy (2011)
#37Earlier quoted context omitted.
I felt like that, like Clojure was the future, around 2009/2010. But then Java libraries and their impossible stack traces got in the way. I've been waiting for a native Clojure implementation (or on top of Python or the Erlang VM) ever since.
There are few abandoned attempts. Writing from scratch those Java libraries, including a good quality AOT compiler and GC is not something to do as hobby on the weekends.
The best chance to get it is to extend something that is ClojureScript based. I think you can get pretty close to it.
My implementation was never really targeting production use, but rather exploring some ideas in the VM.
I would love to continue working on it, but I simply do not have time for such a project.
See github.com/clojit if you are interested.
Re: Simple Made Easy (2011)
#38Earlier quoted context omitted.
For that I fail to see the point of why not use a Scheme or Common Lisp compiler instead.
Thank you. Though I really like having Clojure's: * literal syntax for maps, vectors, sets, and regexes * keywords * clear separation of functional constructs (`for`, `map`, etc.) vs side-effecting ones (`do`, `doall`, `when`). * large standard library of built-in functions, with overall fairly nice naming of things. I've looked at Scheme, but it appears to be missing those things. I think some of them may be provide…