3 ms·

I never said Clojure wasn't productive, i'm pointing out that it is too tied to the underlying platform. ClojureScript is an excellent replacement for Javascri

I never said Clojure wasn't productive, i'm pointing out that it is too tied to the underlying platform. ClojureScript is an excellent replacement for Javascript, however code is not 100% compatible between Clojure and ClojureScript for the reasons cited in the paragraphs above (plus the limitations of Javascript).

bpicolo 9y ago
There's a dotnet clojure too: https://clojure.org/about/clojureclr https://clojure.org/about/clojureclr
- frou_dh 9y ago
  Notably, according to GitHub, it's had precisely 1 substantial contributor in the 8 year life of the project.
  - bpicolo 9y ago
    True, but he's maintained the heck out of it. It's more or less a 1:1 translation of the Java -> Dotnet bits. Any pieces implemented in clojure are just copy pasteable at that point.
grzm 9y ago
You're right that code is not 100% compatible between Clojure/ClojureScript/ClojureCLR. Clojure from the outset has embraced the fact that it's a hosted language and leverages that to provide easy interop with the host. Providing a way of writing portable Clojure* code is the motivation for reader conditionals. https://clojure.org/guides/reader_conditionals https://clojure.org/guides/reader_conditionals You may choose to view Clojure as inextricably tied to the JVM given that a lot of new development on the language starts there and that it does consciously break from some traditional Lisp terminology and syntax. I don't think that's fair, however, given that these are conscious decisions in an effort to make a more pragmatic language. The project itself wouldn't consider these limitations (e.g., host interop, divergent syntax, use "atom" to describe a concurrency primitive as opposed to an aspect of language/syntax), but strengths.
- flavio81 9y ago
  >Providing a way of writing portable Clojure code is the motivation for reader conditionals.* Yes, this is a great idea. Reader conditionals are available in Common Lisp as well, however in CL, unlike Clojure, there is a big (some would say huge) standard library available, so when you find reader conditionals in CL, it is usually because the code uses a very specific implementation-dependent feature like sockets or C interface. In Clojure, the language spec and 'standard lib' is small, thus Clojure libraries often rely on Java libs for many tasks. This often can prevent Clojure code from running straight away on ClojureCLR. More than reader conditionals, Clojure needs a "batteries-included" standard library for successfully becoming a language that can produce portable code.
  - grzm 9y ago
    Certainly having more portable libraries available is a good thing. With the adoption of reader conditionals, people are increasingly writing portable (granted, mostly clj/cljs) library code. I think it's fair to say that, in part, the many years the CL ecosystem has on Clojure contributes to the larger CL standard library, as well as different language goals. You acknowledge that CL also uses reader conditionals for implementation-dependent features: one difference between Clojure and CL is where the line is drawn as to what is considered implementation-dependent. Clojure is 10 years old. According to Wikipedia, work on CL started in 1981, 36 years ago. It's not my goal to convince you that Clojure is equivalent to Common Lisp. I do think you're being unnecessarily harsh in your characterization of Clojure with respect to Common Lisp and faulting it for features that the designer consciously chose to embrace, not through lack of thought. Having a preference for a language is great. Let's try to keep things in perspective, however. I'll sign off now as this looks increasing like a language war rather than a reasoned discussion.
    - flavio81 9y ago
      No, i'm not wanting to raise a language war; i just want to point out which direction Clojure should follow to keep improving.
tmountain 9y ago
Keeping Clojure close to the host language was a design decision that was made at its inception. Choosing the JVM and Javascript as the target runtimes (for lack of a better term), has provided Clojure/ClojureScript a huge amount of reach, and I credit these decisions as the primary driver for the success of the languages. I think that saying that the languages are too tied to the underlying platform represents a misunderstanding of the goals of the languages. If you want a self-hosted language, there are plenty of options to choose from, and each simultaneously carries with it the benefits and disadvantages of a platform that's built from the ground up.
- Jach 9y ago
  CL has had ABCL and Parenscript to integrate with Java and JavaScript fairly nicely for a long time, so I don't see why Clojure having the same abilities should be the primary driver of success, except maybe long term. Clojure piggy-banking off of Maven definitely helps though. To me it was more about finding a nice middle ground of immutability that is better than most language's defaults and not as strict as Haskell, having nice lazy sequence-oriented abilities to do data processing, and offering a fresh syntax to traditional Lisp code, even if it's arguable whether it's "better", with that syntax having nice (and normal wrt other modern languages) data literals for vectors and maps out of the box. In other words I would have tried it and probably liked it without all the JVM stuff, I think it hooks a lot of people for similar reasons (i.e. its actual features, not just its runtime platform), and the JVM integration just adds momentum and can propel it into enterprise situations that traditionally reject anything that's not Java or C++. CL has even more great features, but it's not able to draw new users just because of the "hip new thing" status languages like Clojure have enjoyed because it's so old, and if you have native deployment available chances are you're going to use it and not always consider a JVM option, which in turn leads to never taking Lisp into the enterprise world.

bpicolo 9y ago

There's a dotnet clojure too: https://clojure.org/about/clojureclr https://clojure.org/about/clojureclr

frou_dh 9y ago
Notably, according to GitHub, it's had precisely 1 substantial contributor in the 8 year life of the project.
- bpicolo 9y ago
  True, but he's maintained the heck out of it. It's more or less a 1:1 translation of the Java -> Dotnet bits. Any pieces implemented in clojure are just copy pasteable at that point.

grzm 9y ago

You're right that code is not 100% compatible between Clojure/ClojureScript/ClojureCLR. Clojure from the outset has embraced the fact that it's a hosted language and leverages that to provide easy interop with the host. Providing a way of writing portable Clojure* code is the motivation for reader conditionals. https://clojure.org/guides/reader_conditionals https://clojure.org/guides/reader_conditionals You may choose to view Clojure as inextricably tied to the JVM given that a lot of new development on the language starts there and that it does consciously break from some traditional Lisp terminology and syntax. I don't think that's fair, however, given that these are conscious decisions in an effort to make a more pragmatic language. The project itself wouldn't consider these limitations (e.g., host interop, divergent syntax, use "atom" to describe a concurrency primitive as opposed to an aspect of language/syntax), but strengths.

flavio81 9y ago
>Providing a way of writing portable Clojure code is the motivation for reader conditionals.* Yes, this is a great idea. Reader conditionals are available in Common Lisp as well, however in CL, unlike Clojure, there is a big (some would say huge) standard library available, so when you find reader conditionals in CL, it is usually because the code uses a very specific implementation-dependent feature like sockets or C interface. In Clojure, the language spec and 'standard lib' is small, thus Clojure libraries often rely on Java libs for many tasks. This often can prevent Clojure code from running straight away on ClojureCLR. More than reader conditionals, Clojure needs a "batteries-included" standard library for successfully becoming a language that can produce portable code.
- grzm 9y ago
  Certainly having more portable libraries available is a good thing. With the adoption of reader conditionals, people are increasingly writing portable (granted, mostly clj/cljs) library code. I think it's fair to say that, in part, the many years the CL ecosystem has on Clojure contributes to the larger CL standard library, as well as different language goals. You acknowledge that CL also uses reader conditionals for implementation-dependent features: one difference between Clojure and CL is where the line is drawn as to what is considered implementation-dependent. Clojure is 10 years old. According to Wikipedia, work on CL started in 1981, 36 years ago. It's not my goal to convince you that Clojure is equivalent to Common Lisp. I do think you're being unnecessarily harsh in your characterization of Clojure with respect to Common Lisp and faulting it for features that the designer consciously chose to embrace, not through lack of thought. Having a preference for a language is great. Let's try to keep things in perspective, however. I'll sign off now as this looks increasing like a language war rather than a reasoned discussion.
  - flavio81 9y ago
    No, i'm not wanting to raise a language war; i just want to point out which direction Clojure should follow to keep improving.

tmountain 9y ago

Keeping Clojure close to the host language was a design decision that was made at its inception. Choosing the JVM and Javascript as the target runtimes (for lack of a better term), has provided Clojure/ClojureScript a huge amount of reach, and I credit these decisions as the primary driver for the success of the languages. I think that saying that the languages are too tied to the underlying platform represents a misunderstanding of the goals of the languages. If you want a self-hosted language, there are plenty of options to choose from, and each simultaneously carries with it the benefits and disadvantages of a platform that's built from the ground up.

Jach 9y ago
CL has had ABCL and Parenscript to integrate with Java and JavaScript fairly nicely for a long time, so I don't see why Clojure having the same abilities should be the primary driver of success, except maybe long term. Clojure piggy-banking off of Maven definitely helps though. To me it was more about finding a nice middle ground of immutability that is better than most language's defaults and not as strict as Haskell, having nice lazy sequence-oriented abilities to do data processing, and offering a fresh syntax to traditional Lisp code, even if it's arguable whether it's "better", with that syntax having nice (and normal wrt other modern languages) data literals for vectors and maps out of the box. In other words I would have tried it and probably liked it without all the JVM stuff, I think it hooks a lot of people for similar reasons (i.e. its actual features, not just its runtime platform), and the JVM integration just adds momentum and can propel it into enterprise situations that traditionally reject anything that's not Java or C++. CL has even more great features, but it's not able to draw new users just because of the "hip new thing" status languages like Clojure have enjoyed because it's so old, and if you have native deployment available chances are you're going to use it and not always consider a JVM option, which in turn leads to never taking Lisp into the enterprise world.