[NOGDP]

If your development productivity is entirely reliant on how quickly you can reload your changes, then you're doing something wrong. Though I guess you'd have to write mounds of unit tests and constantly rerun them to prevent common issues that Java's type system solves for free.

[kaliszad]

Actually, Java, its syntax, the explicit types and how its often taught only obscure the solutions that could be much more obvious. Since I have seen Clojure, I was swearing why nobody has shown it to us right in the beginning when I was in the university. Back then, Clojure was already an established, stable language and that has been a decade. I could just skip the C, Java and other classes and would be a much better real-world problem solver/ engineer much earlier. If I needed the specifics e.g. for embedded or legacy applications, I could always look-up/ learn the details for C/ Java etc. but that is not needed for more than 95% of the tasks a software engineer would encounter in the real world.

[NOGDP]

You're not saying anything specific about what's wrong with Java. Java is not perfect, but you haven't actually given a single good reason. The type system alone is a huge benefit over languages such as Python/Ruby. Lisp has existed and been taught for a long time, and I like Lisp languages such as Clojure, but the allusion to Clojure being some kind of magic bullet is also pretty baseless.

[kaliszad]

Well, I did say at least 2 specific things (syntax, explicit types). But maybe approach this a bit differently and talk about what is great in Clojure that is not good in Java: - persistent datastructures that can easily be made transient in specific performance critical cases - consistent syntax - the language itself is a datastructure so manipulating of code is very easy and you have a serialization format (again EDN) basically for free - the REPL - most of the code transfers 1:1 to ClojureScript, that is not the case for Java and JavaScript which are completely different languages and have very different strengths - dynamic types, but out of the box type hinting is available for some corner cases where it improves performance/ makes interoperability a bit clearer and e.g. using clojure.spec you can with some effort make something approaching depend type systems/ very strong tests incl. generative testing - Clojure/ ClojureScript interoperability with the Java/ JavaScript ecosystem - developer productivity - actually performance especially compared to Python/ Perl/ Ruby, very carefully written Java would win microbenchmarks but in Clojure you can probably improve the overall performance of a large codebase because in the same time as you would need with Java you can do many, many iterations more and therefore explore the optimal solution - you can become very proficient in Clojure in about 6 - 12 months where with Java you probably need maybe 3-5x that time to tackle the same problem space

Yes, some of those things are not so specific to Java. If you only care about performance in micro-benchmarks Java would probably win but probably 95% of the problems in the real world are way more complex. Also, good luck writing correct multi-threaded code in Java vs Clojure. Clojure is uniquely positioned for multi-threaded workloads thanks to persistent datastructures, atoms, agents etc.

[tracer4201]

I don’t think op was stating developer productivity completely relies on reloading changes, but developer experience does matter. Many folks end up working with legacy code bases that don’t have clean code, weren’t designed with testability in mind, among other issues. Reloading changes, writing to a logger, etc. end up being common techniques. Depending on the complexity and how much your org is willing to invest in such a system, you can be in a tough spot.