4 ms·

>I mean, why was I unhappy as a programmer after 18 years and said, "if I can't switch to something like Common Lisp, I'm going to switch careers". Why am I say

>I mean, why was I unhappy as a programmer after 18 years and said, "if I can't switch to something like Common Lisp, I'm going to switch careers". Why am I saying that? I'm saying it because I'm frustrated with a bunch of limitations in what I was using. >So, when I discovered Common Lisp, having used C++, I said that, "I'm pretty sure to the answer to this question is, 'yeah, absolutely'". And can we do that with a lower cognitive load? I also think, "yes, absolutely". And then the question is, "can I make a Lisp I can use instead of Java or C#?". Cuz you just heard my story, and I used Common Lisp a (?) couple of times, every time it got kicked out of production, or just ruled out of production, really not kicked out, it didn't get a chance. So I knew I had to target a runtime that people would accept. Poor Rich Hickey, he wanted to escape C++, Java and C# and rather use Common Lisp, but his employeers wouldn't accept it. Thus he invented Clojure, and now he can't escape Java, because, sadly, Clojure itself and its libraries are very coupled to the Java libraries and the JVM. Clojure makes really easy to invoke Java classes and methods; thus, rather than creating a comprehensive Clojure standard library, the choice was to mostly just use the Java libraries. Thus, migration to another VM (like the CLR runtime) means that a big amount of the Clojure code that runs under the JVM does not work anymore. Clojure is very coupled to the JVM even in it's choice of keywords, for example an "atom" in Lisp has a very different (and traditional, established) meaning than an "atom" in Clojure, which is directly tied to the java.util.concurrent.atomic class. Mind you, i am glad Clojure exists; next time a customer wants a project that should (or needs) to be heavily integrated with existing Java/JVM code, it would be my first choice; in fact, I pitch Clojure as a #1 alternative to Java. But the coupling to the Java and JVM is a problem.

wellpast 9y ago
> Clojure itself and its libraries are very coupled to the Java libraries and the JVM. .... Clojure is very coupled to the JVM This is not true. Clojurescript has been a very productive language for me and for many others.
- flavio81 9y ago
  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.
james-mcelwain 9y ago
I'm not a fan of Java, but the JVM is an incredible piece of software that centuries of man hours have been spent optimizing. And while Java might not be a pleasurable language, the enterprise masochists have written millions of lines of battle tested code in libraries. The deployment and monitoring model for the JVM is very well understood, which means Clojure is uniquely positioned to be introduced into large organizations.
- flavio81 9y ago
  I agree with you (and i'm surprised at people downvoting my post). Thus, i repeat: Clojure is an excellent (and for me, preferred) alternative to Java on the JVM. However i would have liked to see it progressing into a language where you could have the same code run without changes on many platforms -- at least the JVM, CLR, LLVM, and if possible the javascript engines.
gw 9y ago
People have tried, and failed, countless times to create thick abstractions over runtimes in order to allow code to easily port across them. They always fail, normally because they become too slow due to the added indirection and lost opportunities to optimize using platform-specific features. Moreover, it's not even that useful; how often do you want to move a large application from the JVM to the CLR? The code sharing capabilities between Clojure and ClojureScript exemplifies a better middle ground; you write .cljc files and use reader conditionals to write platform-specific code when necessary.
lucozade 9y ago
Don't feel sorry for him for his use of the JVM. Seems he's quite the fan as it sits quite neatly with his views on code dynamism. He's less supportive of the CLR runtime, calling it an example of static thinking, though he doesn't elaborate.

wellpast 9y ago

> Clojure itself and its libraries are very coupled to the Java libraries and the JVM. .... Clojure is very coupled to the JVM This is not true. Clojurescript has been a very productive language for me and for many others.

flavio81 9y ago
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.

james-mcelwain 9y ago

I'm not a fan of Java, but the JVM is an incredible piece of software that centuries of man hours have been spent optimizing. And while Java might not be a pleasurable language, the enterprise masochists have written millions of lines of battle tested code in libraries. The deployment and monitoring model for the JVM is very well understood, which means Clojure is uniquely positioned to be introduced into large organizations.

flavio81 9y ago
I agree with you (and i'm surprised at people downvoting my post). Thus, i repeat: Clojure is an excellent (and for me, preferred) alternative to Java on the JVM. However i would have liked to see it progressing into a language where you could have the same code run without changes on many platforms -- at least the JVM, CLR, LLVM, and if possible the javascript engines.

gw 9y ago

People have tried, and failed, countless times to create thick abstractions over runtimes in order to allow code to easily port across them. They always fail, normally because they become too slow due to the added indirection and lost opportunities to optimize using platform-specific features. Moreover, it's not even that useful; how often do you want to move a large application from the JVM to the CLR? The code sharing capabilities between Clojure and ClojureScript exemplifies a better middle ground; you write .cljc files and use reader conditionals to write platform-specific code when necessary.

lucozade 9y ago

Don't feel sorry for him for his use of the JVM. Seems he's quite the fan as it sits quite neatly with his views on code dynamism. He's less supportive of the CLR runtime, calling it an example of static thinking, though he doesn't elaborate.