Which piece of code do you think makes ClojureScript significant?


#44

Yup half of my friends who come from a ruby background outright disliked the idea that they have to know Java or look at Java docs to achieve any effect in their code.

Infact this hatred towards Java is a very strong sentiment in the ruby community mostly because of the handy work of DHH, who himself dislikes Java with a passion. Which is why it is very much ingrained in the community. And this passionate dispassion for Java is prevalent in many communities including Python and JS.

What Rich thinks is an Advantage for clojure to have a prebuild user library that can be leveraged from the host VM to get work done and be productive fast is also a problem for many who dislike Java Docs. I think Rich’s target demographic is the enterprise Java people who might be bored of writing Java.

Because clearly clojure isnt attracting many people from other languages unless they had some kind of earlier interaction with lisp/scheme/elisp.


#45

No idea about others, but I have never seen a lisp before clojure & language experience php, coffescript, python & js.

Tried building a full-stack app reactjs & node backend & ssr, it worked but despite following best practices, the end result was not something I would like to maintain (loved the single language on frontend & backend idea though).

FP & immutability + full stack story are what got me interested.

Now it’s mostly about the language and how much thought went into it… the more I learn the more it all clicks together.

A few highlights that I keep mentioning when talking about clojure are: Macros, Data oriented, Repl, Clojure.spec, Reactjs ecosystem: Fulcro, Re-frame, keechma, etc…

On the backend personally think there’s less value or at least less of an argument to be made that would justify the learning curve from something like python. But if you’re interested ReactJs & frontend… Clojurescript seems like the place to be, and the learning curve is worth the effort.

The adoption might be related “marketing” in the reactjs community. Might be just in my area but reactjs developers don’t really know clojurescript exists… not to mention how nice the reactjs ecosystem is in clojurescript. Strangely enough although not a lot of people have tried ELM, most devs know about it.


#46

But why do you need to convince these people? Please consider https://stackoverflow.com/tags. That’s nearly 3 million questions for JavaScript & Java alone. If you capture a small percentage of either population you will have a healthy sustainable community for decades to come. If somebody doesn’t like Java or JavaScript it’s a rounding error marketing wise.


#47

This simply isn’t true. Please look at the survey - 75% of Clojure users are Java, JavaScript, Python and Ruby programmers. <2% are coming from Common Lisp. See https://www.surveymonkey.com/results/SM-9BC5FNJ68/


#49

The survey does not indicate if they had any previous exposure with any other lisps, it simply indicates the previous language they were working on. I was a ruby dev and i was exposed to elisp due to my editor ‘emacs’. I think next time around a question asking if they had any previous exposure to any dialects of lisp/scheme would put more light on this.


#50

Well, it would always be nice to get more people excited and interested in ClojureScript, to help grow our community so that I have more people to geek out with about ClojureScript. And potentially more contributions to its ecosystem, as well as maybe more availaible jobs.

But the reason I bring it up now is more reactionary. I’ve noticed a shift in the kind of beginners that show up on the community forums and chats. They seem to come from Node and JS backgrounds, and are not Java devs. And I’ve noticed we don’t have as many learning material geared at them, we have inferior tooling for them, and we don’t have a lot of marketing around keeping them interested.

Since I’m not a JS & Node developer, its something I have to point out for myself, that I need to be inclusive to people coming from those backgrounds also and looking for pure ClojureScript resources and environments. So I tried it out, and the self-hosted ClojureScript story could definitly use more guides, tooling, libs, etc. So I guess my first question was, does it even make sense, self-hosted ClojureScript. Is that really better then just JS & Node? I think so, but can’t fully articulate it, and can’t be sure since I’m no JS & Node dev.


#51

True for me. David gave quite impressive talks to React community and convinced me that ClojureScript provides better solution than React+immutablejs. However as I began to learn ClojureScript, it took me years to figure out how to shift my React & Webpack developing experience all to ClojureScript, until shadow-cljs(and Lumo also) offered me lots of help. And I have friends worrying about the barriers between JavaScript and JVM too.


#52

Is this actual “informed hate” or just FUD circulating in that Community? I’d guess that the majority probably never even wrote a Java program, let alone a full project.

I was a Java Developer for a while and then went to Ruby for a few years being frustrated by the whole SomeFacadeFactoryImpl mess. I was happy for a while but when I actually got to “scale” my project all I could think was: This was so much easier with the JVM. I guess this is why JRuby exists. You can hate on Java all you want but equating that with hating the JVM is just ignorant.

It wasn’t a single piece of code that attracted me to Clojure(Script), to be honest the code just looked strange. It was the fact that I could use the same language on the Server and Client. I had zero exposure to any Lisp before coming to Clojure but I knew Java and JavaScript very well. The fact that I can use both seamlessly is what actually kept me around.

I think shadow-cljs proves that you can do ClojureScript development without ever actually noticing that you are using the JVM.

I have no idea how to attract people to use Clojure(Script) but I know that even the most beatiful code snippet in the World would not have convinced me to try it. The platforms matter more IMHO.


#54

I am not sure if they are entirely informed about it, but from personal experience i really disliked Java when i first learnt it. Although i already knew C++ but i still hated the strict OO paradigm. When i revisited Java after a few yrs of Ruby it still looked like a terse and verbose language.

For instance when i first learnt Java, interfaces made no sense to me. After a few yrs of ruby i understood interfaces are a contract for you classes. But now it made even less sense because i understood that you can always write your contracts as test/specs. So interfaces currently make little to no sense to me. In ruby Module/mixins actually made more sense.

My best guess is that for a lot of people in the ruby community, ruby is their first language and much of the Java hatred is propagated by the author of Rails, DHH. And most first timers are susceptible to religious ideas, it is only after a few yrs of development you see a clear picture and look beyond your current first love. You see the first love is always too infectious and languages are no different. Infact my own ideas about Java were reinforced in the ruby community before i realized that Java is bad but JVM is industrial strength VM second to none.

These ideas are very strong, although JRuby is a great implementation i dont know anyone who uses it in production. Mainly due to lack of gem support.

shadow-cljs is actually a good idea, but at the end of it API is what matters, and clojure needs a good standard library that is compatible across hosts. Nobody likes to use a language that requires you to know this ‘X’ language before you can use it.


#55

But for this you would have to compromise somewhere. Why limit yourself like that? The standard library that doesn’t require host interop (ie. immutable collections) is already top-notch. You can’t make a standard library for IO because the platforms vary so immensely in capabilities.

The JVM has threads and can do sync IO just fine. JS doesn’t have threads, sometimes can do IO, sometimes even sync but mostly async. Just having threads is such a gigantic difference that you’d have to take out of the equation for a truly platform agnostic “standard library”. On top of that even the JS runtimes themselves vary greatly in capability. Browser, node, react-native, nashorn and so on.

The reason there is no “standard library” is because it is pretty much impossible to write one. If you wrote one it would just be completely crippled compared to what you could actually be doing. As far as I can tell there are good wrappers for most “native” things so you rarely need to write actual Java or JS. Yes, you still need to be aware of the platform you are on but there is just no way around that. Learning Java and JavaScript will make you a better programmer, even if you just learn why you don’t like them and what not to do.

PS: I think interface in Java is one of its best features. But like all good features you can go overboard with it and the Java world certainly did. Same deal in Clojure(Script) though. You could create a defprotocol for everything or just use functions and maps. Knowing when to use what is the hard part and that is true for every single platform or language I have used ever.


#56

Your arguments are wise but i really dont think anyone can sell it, saying hey you should learn clojure and if anything is not supported just look at the Java Docs and you can reuse everything else from there.


#57

Whats wrong with Java Docs? It might not look fancy but once you figure out how its structured it is pretty good. I haven’t convincingly better API docs anywhere yet. They more or less look alike everywhere.

Seriously though … don’t tell anyone that you might need to use Java/JS sometimes. If anyone ever gets to this point they will probably have written enough code to be hooked. Figuring out how to do interop is just a natural step in the learning process. Having this option at all is very powerful and many languages fall apart at this point.


#58

It’s a lisp carefully designed from first principles around immutable data structures with a practical approach to functional programming. These are not features in the sense of a particular morsel of syntax sugar, as @thheller’s comment “it wasn’t a single piece of code that attracted me” exemplifies. It’s an entire programming style where each element has benefits that comes together as more than the sum of its parts. For instance, “as a dialect of Lisp, [clojurescript] has a code-as-data philosophy and a powerful macro system”, each of which sounds merely okay until you see firsthand all the implications that has across architecture and workflow.

I think that’s the pitch. This may not convince folks who want to avoid a big bite of “new way of doing things” but it is what it is.

(One aspect of ClojureScript that actually is a feature, and which we may sometimes not speak enough about, is Google Closure, both as a powerful library and as a path to the sorcery of dead code elimination.)

clojure needs a good standard library that is compatible across hosts

Doesn’t most of Clojure core already work the same in both ClojureJVM or ClojureScript? To the extent that it doesn’t, it largely shouldn’t. Regardless, Clojure is designed to be a hosted language, it’s fundamental to what Clojure is and to Clojure’s value proposition as a lisp with elegant interop, and I do not expect that to change. For the same reasons @thheller stated upthread I think such a change would be unwise.

Finally, I’d like to address this:

My best guess is that for a lot of people in the ruby community, ruby is their first language and much of the Java hatred is propagated by the author of Rails, DHH. And most first timers are susceptible to religious ideas, it is only after a few yrs of development you see a clear picture and look beyond your current first love. You see the first love is always too infectious and languages are no different. Infact my own ideas about Java were reinforced in the ruby community before i realized that Java is bad but JVM is industrial strength VM second to none.

This kind of infatuation with programming languages that you describe is a real thing. But the conclusion we should reach from it is that we should do outreach that focuses on explaining and teaching a better way, not that we should lie to them by saying that they will be productive in Clojure/ClojureScript without needing to challenge their own immature view of programming.


#59

I am not really bashing Java Docs, my limited point was if anyone who doesn’t know Java, would have a hard-time understanding it. And if you are trying to learn clojure, but parallely trying to learn Java aswell as a courtesy of clojure may not be such a welcome thing for many.


#60

It isnt consistent, for instance something as basic as edn serialisation and deserialisation in clojure vs clojurescript.

In Clojure

(defrecord Human [name age sex])
(def new-person (->Human "pankaj" 33 :M))
(read-string (prn-str new-person))

In Clojurescript

(defrecord Human [name age sex])
(def new-person (->Human "pankaj" 33 :M))
(cljs.reader/read-string (prn-str new-person)) ;; This would fail

Why does the reader in cljs fail? Why dont they just work the same?


#61

This is unfortunate yes but the technical reason for this is that ClojureScript cannot lookup classes dynamically at runtime. Therefore it cannot map the your.ns.Human symbol to the class. But in general records are not part of actual EDN so in a sense CLJS is correct.

Clojure 1.9.0
=> (require '[clojure.edn :as edn])
nil
user=> (edn/read-string "#cljs.user.Human{:name \"pankaj\", :age 33, :sex :M}\n")
RuntimeException No reader function for tag cljs.user.Human  clojure.lang.EdnReader$TaggedReader.readTagged (EdnReader.java:801)
;; which matches the CLJS error
Error: No reader function for tag cljs.user.Human.

clojure.core/read-string should not be used for reading EDN data since it is unsafe and can be used to eval things and other dangerous stuff.


Clojure.core/read-string not for reading EDN, then what?
#62

Try something as simple as a serialized edn string with record namespace :

(cljs.reader/read-string "{:name \"Pankaj\"}\n")

The above would work on lumo and planck but not if you bring a cljs repl using clj -Sdeps '{:deps {org.clojure/clojurescript {:mvn/version "1.9.946"}}}' -J--add-modules -Jjava.xml.bind -m cljs.repl.node


#63

This is getting way too off-topic. It works just fine in my node repl? Did you maybe miss a (require 'cljs.reader) first? Feel free to send me a direct message to help you troubleshoot this. Or open another thread, we should not hijack this one.


#64

In fact, a patch worth considering would be to alias clojure.edn to cljs.reader to ameliorate this confusion.


#65

I am one of those javascript guys who happens to hate Java. My first approach to programming was through video game programming on a language that mixed C and pascal. After that I have programmed in C, C++, php, python, javascript, bash, ClojureScript, Haskell and of course Java, and it happens that there is no language that I hate most than Java . My problem is not with the JVM at all, and I don’t think any smart person has anything against it neither, it’s an impressive piece of machinery. The problem (and makes sense, of course) is that everything related to the JVM involves in some way or another Java, which is the bad part: unless you are an end-user you will have to write or read some Java. I was first attracted to Clojure by the idea of writing code for the two mainstream virtual machines of nowadays, but after developing some toy projects with it I came to the conclusion that you need to know the host language very well to be able to use it. This is true for me in the case of javascript, but it will never be for Java. In fact being able of writing stuff that will run on the JVM without writing any Java was one of the main selling points, but seems to be impossible. That leaves me with ClojureScript alone, so I think that finding motivation to stick with Clojure even if your are not going to target te JVM is important for many people.
I have to admit that the weird syntax was also attractive to me, but I don’t think we can shell this to many people :smile: