4 ms·
"While Storm's Clojure implementation served it well for many years, it was often cited as a barrier for entry to new contributors. Storm's codebase is now more
by zenlot 7y ago
"While Storm's Clojure implementation served it well for many years, it was often cited as a barrier for entry to new contributors. Storm's codebase is now more accessible to developers who don't want to learn Clojure in order to contribute." - interesting phrasing. Seems that the authors assuming that new contributors are more willing to learn Java instead of Clojure. And those who know Java find Clojure difficult to learn? Clojure, in fact is quite easy to grasp - especially for someone coming from Java, as you would still be working on JVM and always have Java Interop. I guess same thing goes to someone coming from Erlang to Elixir, where you are still working in the familiar ecosystem.
- dvfjsdhgfv 7y ago> Seems that the authors assuming that new contributors are more willing to learn Java instead of Clojure. No, many more people know Java than Clojure, that's it. Whether it's the right decision for the future of the project, time will show, but I don't think it was taken lightly.
- twblalock 7y agoMost new contributors already know Java.
- cygned 7y ago> Clojure, in fact is quite easy to grasp - especially for someone coming from Java I disagree on that point. In my experience as a programming language teacher, people often struggle to learn functional programming and even more to learn a Lisp, especially if they are used to a C-like language. And learning both at the same time is even more difficult. I liked working with Clojure but I have yet to meet someone who easily grasps the language and - more important - development patterns.
- adz5a 7y agoHello, this is an interesting take. Clojure has been a hobby of mine for some time but now I am a professional Clojure developper (clj/cljs). I knew the language before starting my new job but I found it really different than know the "platform": how a project is layed out, tests are written, some libs, how to pinpoint potential technical debt/suboptimal code accurately and so on... But I guess this would have been true if I had transition to any other new language. Would you have any example of what your trainees stumbled upon or found difficult in the language? That would be useful I guess when we try to onboard new people on the project. Have a nice day :)
- eecc 7y agoHey, once you get over accepting a = a+1; without gagging it’s all downhill from there ;)
- kazinator 7y ago> even more to learn a Lisp, especially if they are used to a C-like language Ah, you're mixing up Clojure and Lisp. The restrictions in Clojure have nothing to do with Lisp tradition. Someone used to a Lisp-like language will also struggle with Clojure. Traditional Lisps like Common Lisp are multi-paradigm languages in which variables and most aggregate types are mutable. They are not hard to pick up for someone with a background in C. C has pass-by-value functions; so does proper, traditional Lisp. C has mutable variables, arrays and structures; so does Lisp. Lisp data structures like lists or hash tables are easily understandable by a C programmer with a good background in data structures. cons is like malloc-ing and filling-in a two-field struct, except that freeing is taken care of. People have written Lisp systems in C (and written more than one book on that exact subject: Nils M. Holm just put a new one out: http://www.t3x.org/lsi/index.html http://www.t3x.org/lsi/index.html), with a lot of the internals being written in C over the Lisp library functions. E.g. visiting and printing the elements of a list can literally look like this, in the internals of a C-based Lisp implementation: for (val iter = list; list; list = cdr(list)) print(car(list)); val is some typedef for a pointer to a "struct lisp_object" or whatever. The nil value is represented by null, and so it goes.
- agumonkey 7y agoAlso, java 8 and above is getting a lot leaner to use, api, linguistics .. so the gap with clojure is a bit less than before.
- kamaal 7y agoIt will take years if not decades for these things to seep into regular programming practice in the Java world. I still see people writing for(i = 0; i < something; i++) { } Java could get cleaner, but habits die/change when programmers retire not when Java makes new releases.
- agumonkey 7y agoReally ? surprising.. (genuinely)
- hatch_q 7y agoIt's not about the language, it's about the code... understanding Clojure code that someone else wrote is harder than writing your own.
- yogthos 7y agoI don't find that to be the case at all. I worked with Java for around a decade and I never contributed to a single open source project. Every time I'd see a bug or a feature I'd like to add, I'd open the source and it would be a nightmarish maze of classes and interfaces with business logic being sprinkled across them. Meanwhile, I've successfully contributed to plenty of Clojure libraries I use, and many people contribute to my projects. Clojure code is far more direct and concise making it much easier to understand the intent. And majority of the code is written using pure functions that can be reasoned about in isolation. On top of that you have an editor integrated REPL, so you can just run any code you're not sure about as you're reading it.
- cutler 7y agoA dynamic, functional Lisp built with immutable data structures and inherent laziness is about as far-removed Java's mutable OOP as I can can imagine.
- kazinator 7y ago... and from Lisp. Please, folks, don't assume Lisp is weird, opinionated and hard to use based on trying Clojure.
- kazinator 7y agoThat's like saying going from any language to any language on the Unix platform is easy because the POSIX system calls are the same. In any half-decent language on Unix you can get access to a file descriptor and call fcntl() on it, so it's all the same.