5 ms·

Clojure rationale: "Customers and stakeholders have substantial investments in, and are comfortable with the performance, security and stability of, industry-s

by mbil 11y ago

Clojure rationale: "Customers and stakeholders have substantial investments in, and are comfortable with the performance, security and stability of, industry-standard platforms like the JVM. While Java developers may envy the succinctness, flexibility and productivity of dynamic languages, they have concerns about running on customer-approved infrastructure, access to their existing code base and libraries, and performance. In addition, they face ongoing problems dealing with concurrency using native threads and locking. Clojure is an effort in pragmatic dynamic language design in this context. It endeavors to be a general-purpose language suitable in those areas where Java is suitable. It reflects the reality that, for the concurrent programming future, pervasive, unmoderated mutation simply has to go. Clojure meets its goals by: embracing an industry-standard, open platform - the JVM; modernizing a venerable language - Lisp; fostering functional programming with immutable persistent data structures; and providing built-in concurrency support via software transactional memory and asynchronous agents. The result is robust, practical, and fast." via http://clojure.org/rationale http://clojure.org/rationale

zeveb 11y ago
Of course, one can run Common Lisp on the JVM and one can integrate CL with the JVM; one can add immutable persistent data structures to CL (but all the mutable stuff would still be available under the covers). I imagine that it'd be easier to add that stuff to CL than it would be to create a new language from scratch. I honestly don't know how hard it would be to add software transactional memory and asynchronous agents to CL. I don't think it would be bad, but perhaps the end result would be so unlike CL that it wouldn't be pleasant to work in.
- brudgers 11y ago
  It's not so much that Common Lisp couldn't be implemented on the JVM and with transactional memory, it's that if one is going to do that much work, why not tune the language for that environment and for the programmers who live there? And once you do that, then picking a semantics for \.\ becomes a point of interest. Does one pick Common Lisp's or Java's usage for clarity , or the third option of complexity by overloading it?
- PuercoPop 11y ago
  FYI: STM is available for Common Lisp, including in the JVM https://github.com/cosmos72/stmx https://github.com/cosmos72/stmx
  - zeveb 11y ago
    That's pretty cool. I imagine that one could use that with (say) SBCL's threads and or with ABCL and the JVM's threads and have a decent environment.

by mbil 11y ago

zeveb 11y ago

Of course, one can run Common Lisp on the JVM and one can integrate CL with the JVM; one can add immutable persistent data structures to CL (but all the mutable stuff would still be available under the covers). I imagine that it'd be easier to add that stuff to CL than it would be to create a new language from scratch. I honestly don't know how hard it would be to add software transactional memory and asynchronous agents to CL. I don't think it would be bad, but perhaps the end result would be so unlike CL that it wouldn't be pleasant to work in.

brudgers 11y ago
It's not so much that Common Lisp couldn't be implemented on the JVM and with transactional memory, it's that if one is going to do that much work, why not tune the language for that environment and for the programmers who live there? And once you do that, then picking a semantics for \.\ becomes a point of interest. Does one pick Common Lisp's or Java's usage for clarity , or the third option of complexity by overloading it?
PuercoPop 11y ago
FYI: STM is available for Common Lisp, including in the JVM https://github.com/cosmos72/stmx https://github.com/cosmos72/stmx
- zeveb 11y ago
  That's pretty cool. I imagine that one could use that with (say) SBCL's threads and or with ABCL and the JVM's threads and have a decent environment.