Comment by flavio81 | Hacker News Reader

Comment by flavio81 | Hacker News Reader

>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.

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.

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.

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.

> 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.

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).

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

Notably, according to GitHub, it's had precisely 1 substantial contributor in the 8 year life of the project.

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.

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

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.

>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.

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.

No, i'm not wanting to raise a language war; i just want to point out which direction Clojure should follow to keep improving.

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.

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.

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.

Reply on news.ycombinator.com