[StreamBright]

Every programming environment has down sides and Clojure is no exception but I still think that using Java instead of Clojure is not better because simply you have 3-10x source code to maintain and the number of bugs are correlating with number of source code lines. On the top, I quite often see null pointer exceptions in Java when in theory that should never happen because we are statically typed.

[hota_mazi]

Pick a more modern language than 20 year old Java, such as Kotlin, and you get the best of both worlds: static typing and type inference.

[StreamBright]

Yeah it is on my list to check for a while. If it has the same interop with Java as CLojure than I will give it a try.

[gered]

I'm not sure why you're contrasting Clojure and Java, but nowhere was I recommending using Java over Clojure (nor would I ever offer such a recommendation). Certainly there are much, much better choices for a statically typed language out there.

[StreamBright]

People usually not just chose languages. The VM, libraries and dependency management all together are chose. Btw. this is why Rich started Clojure on the JVM. If you stay on JVM land I quite often hear that the developers do not want to try Clojure because of the lack of types (which refers to static typing in this context). Good luck implementing a Hadoop project in OCaml or Haskell.

[platz]

It seems like you're jumping ahead to conclusions waay to quickly here.

Instead of that, it would be better to respond directly to the specific points the OP made, rather than move the argument to a bunch of new topics.

OP did not say anything about other languages, be it Java or otherwise. OP is just describing experience with closure.

In order to understand clojure better, it would be good to not shut out feedback.

[StreamBright]

This is exactly the point, you can't just chose languages because of type systems there is a lot more to these decisions. OP has an experience with Clojure (which has closures) but these experiences are do not exists in the vacuum, there are tradeoffs that you take with every language.

[logicchains]

>On the top, I quite often see null pointer exceptions in Java when in theory that should never happen because we are statically typed.

In this sense Java is actually dynamically typed: there's no way of knowing at compile time whether an object is actually an instance of that object or is null. In languages like Kotlin, Haskell and Ocaml, which specify in the type system whether or not something can be none and force the user to check before using something that can be null, null pointer errors don't happen.

[lvh]

> In this sense Java is actually dynamically typed: there's no way of knowing at compile time whether an object is actually an instance of that object or is null.

That is an extremely unusual definition of dynamic typing. If I have an Integer it might be null but it won’t be a BeanFactory (unless someone did a reflective call or wrote some bytecode or otherwise subverted the type checker).

[StreamBright]

Well in my ideal word nulls are not part of Integers or Floats or BeanFactory.

[thoughtfunction]

Static type systems have scopes in how much they type. Some newer ones add nullable annotations, like kotlin or swift, others don't have it yet.

I hope java gets native support for @nullable, but for now we have stuff like error prone and @nullable annotations.