4 ms·

> for me, the main strength is having persistent data structures at its base for everything. Agreed, but also: - The ISeq abstraction - Software Transactiona

> for me, the main strength is having persistent data structures at its base for everything. Agreed, but also: - The ISeq abstraction - Software Transactional Memory for state management - Structure-sharing of the persistent structures, for added efficiency/performance And of course, all the nice reader macros that make things so much easier to read. This project is cool, but what I'd rather see is Clojure becoming parasitic, living on all the host VMs it can. We've got the CLR version, and ClojureScript for V8/JS, but we could also have it properly on top of Python, Ruby[1], Lua, Erlang, and LLVM. [1]: I know Rouge exists, but I'm not sure how well it's progressing.

derengel 12y ago
STM/Refs are not really used in the Clojure community, its a great a concept but in practice almost no one uses it, at least that's what you can see from public Clojure projects.
- sarnowski 12y ago
  At some point most applications have to have some state. Most clojure projects are nice functional libraries that work without state but somewhere are one or to refs (or atoms). A good example is Datomic where Rich Hickey said, it only has 6 refs. Its 99% persistent but somewhere you need at least a pointer to your current state. Of course you can push the problem to your database or some libraries but I really like refs with their optimistic locking and am using them to have in-memory consistency.
- mtrimpe 12y ago
  Wouldn't you generally want an STM in your domain model in places where it's essential rather than in (ideally generic) open source libraries?
mtrimpe 12y ago
Clojure itself would also love to become parasitic just as you described. It's actually one of it's explicitly stated goals if I'm correct. Apparently implementing Clojure on the LLVM is no easy feat though; judging from references to previous discussions on the mailing list. [1] There is some work on it already though [2,3,4] and I'm sure we'll get there eventually. [1] https://groups.google.com/forum/#!topic/clojure-dev/bex25u9hWIw https://groups.google.com/forum/#!topic/clojure-dev/bex25u9h... [2] https://github.com/ohpauleez/cljs-terra https://github.com/ohpauleez/cljs-terra [3] https://github.com/halgari/clojure-metal https://github.com/halgari/clojure-metal [4] https://github.com/halgari/mjolnir https://github.com/halgari/mjolnir
- pjmlp 12y ago
  I would say it is also a matter of focus. A real compiler backend takes a bit more than a weekend project, and it is hard to know the real reasons, technical or personal life of the coders, for the current state of the projects.
  - mwcampbell 12y ago
    I think the real problem with the native Clojure compilers is that Clojure is designed to be symbiotic with host platforms that offer a much higher level of abstraction. For example, to perform well, all those persistent data structures require an advanced garbage collector. The JVM, the CLR, and the leading JavaScript implementations offer this; it would take a lot of work to implement one in the absence of one of these mature platforms.
bjeanes 12y ago
> Structure-sharing of the persistent structures, for added efficiency/performance I think the structural sharing is the definition of persistent data structures, as distinct from immutable data structures in general.
- Slackwise 12y ago
  > I think the structural sharing is the definition of persistent data structures, as distinct from immutable data structures in general. Oh, yes, you are very much correct. I just wanted to highlight that is itself a feature of Clojure's behavior.
- eru 12y ago
  Not directly, but nearly. Structural sharing / copy-on-write is basically the only way to satisfy the actual definition.
dschiptsov 12y ago
ISeq is considered to be harmful, because partly due to ISeq over use Clojure's code is cluttered with unnecessary and costly (making a new copy) "casts" (or what a proper clojurian term for this?) from one kind of a container to another. There is an opinion that classic lists, sequences (only on lists, vectors and strings) plus series are good-enough.

derengel 12y ago

STM/Refs are not really used in the Clojure community, its a great a concept but in practice almost no one uses it, at least that's what you can see from public Clojure projects.

sarnowski 12y ago
At some point most applications have to have some state. Most clojure projects are nice functional libraries that work without state but somewhere are one or to refs (or atoms). A good example is Datomic where Rich Hickey said, it only has 6 refs. Its 99% persistent but somewhere you need at least a pointer to your current state. Of course you can push the problem to your database or some libraries but I really like refs with their optimistic locking and am using them to have in-memory consistency.
mtrimpe 12y ago
Wouldn't you generally want an STM in your domain model in places where it's essential rather than in (ideally generic) open source libraries?

mtrimpe 12y ago

Clojure itself would also love to become parasitic just as you described. It's actually one of it's explicitly stated goals if I'm correct. Apparently implementing Clojure on the LLVM is no easy feat though; judging from references to previous discussions on the mailing list. [1] There is some work on it already though [2,3,4] and I'm sure we'll get there eventually. [1] https://groups.google.com/forum/#!topic/clojure-dev/bex25u9hWIw https://groups.google.com/forum/#!topic/clojure-dev/bex25u9h... [2] https://github.com/ohpauleez/cljs-terra https://github.com/ohpauleez/cljs-terra [3] https://github.com/halgari/clojure-metal https://github.com/halgari/clojure-metal [4] https://github.com/halgari/mjolnir https://github.com/halgari/mjolnir

pjmlp 12y ago
I would say it is also a matter of focus. A real compiler backend takes a bit more than a weekend project, and it is hard to know the real reasons, technical or personal life of the coders, for the current state of the projects.
- mwcampbell 12y ago
  I think the real problem with the native Clojure compilers is that Clojure is designed to be symbiotic with host platforms that offer a much higher level of abstraction. For example, to perform well, all those persistent data structures require an advanced garbage collector. The JVM, the CLR, and the leading JavaScript implementations offer this; it would take a lot of work to implement one in the absence of one of these mature platforms.

bjeanes 12y ago

> Structure-sharing of the persistent structures, for added efficiency/performance I think the structural sharing is the definition of persistent data structures, as distinct from immutable data structures in general.

Slackwise 12y ago
> I think the structural sharing is the definition of persistent data structures, as distinct from immutable data structures in general. Oh, yes, you are very much correct. I just wanted to highlight that is itself a feature of Clojure's behavior.
eru 12y ago
Not directly, but nearly. Structural sharing / copy-on-write is basically the only way to satisfy the actual definition.

dschiptsov 12y ago

ISeq is considered to be harmful, because partly due to ISeq over use Clojure's code is cluttered with unnecessary and costly (making a new copy) "casts" (or what a proper clojurian term for this?) from one kind of a container to another. There is an opinion that classic lists, sequences (only on lists, vectors and strings) plus series are good-enough.