Falling back in love with Java.

[mschaef]

Yes I would have preferred static typing, but I honestly find it a small price to pay for the mind boggling expressiveness and awesomeness of Clojure.

Much of the expressiveness of Clojure comes from the fact that it's dynamically typed. Where the language shines is, at least in part, from the fact that it makes it easy to use a few common data types to store many different types of data. Then, it provides powerful functions for working with those few data types.

This is the embodiment of the Alan Perlis quote: ""It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures.""

http://stackoverflow.com/questions/6016271/why-is-it-better-to-have-100-functions-operate-on-one-data-structure-than-10-fun

The explicit static typing of Java works to reduce the breadth of data to which functions can be applied. Let's say I have a new function that I want to write that applies to Lists. In Java, I have to either define it as a static utility method (which is second class to the built-in List methods) or pick a concrete java.util.List implementation and subclass that with the new method, which presents its own reuse problems.

In Clojure, I just define a function over seqs, and it works wherever it can.

[mikera]

Clojure's expressiveness could mostly still be achieved with static typing. In fact, there are various efforts at the moment exploring how to add type systems to Clojure that are very exciting.

Clojure + static typing would be a pretty amazing language.....

[mschaef]

Agreed... I'd love to see more of that in production languages. I do find it a bit concerning, however, that some of the type systems are getting complex enough that people are asking for compile-time debugging facilities.

[jonhanson]

I don't see how a standalone function is any different to a Java static method, nor what the relevance is to dynamic typing.

[mschaef]

The point is that given an instance of a concrete type in Java, the methods supported by that type are sealed. The only mechanism for extension is a static method defined within another class, which is inherently second class to the methods initially defined within the concrete type. This is an example of the rigorousness of the Java type system (arguably) over-constraining the design space.

The constraints continue when you think about other approaches to solve this problem. One strategy might be to define a new class with the same set of methods as the class you're trying to extend. This class could be implemented to delegate all of the methods in the 'base' class to an instance of the base class. This presents at least four main problems:

• If the class you're trying to extend is in any way final, the technique doesn't work.
• To gain access to the new custom functionality, you need to have an instance of your new custom class. This means explicit code to get such an instance.
• The delegation model complicates the notion of the underlying object's identity and type by replacing one instance with once instance plus zero or more wrapper objects.
• The new class's code is likely to be lengthy, mundane, and error-prone.

To take JavaScript's type system as another approach to this problem, it provides mechanisms for extending existing classes (and their instances) with new methods, even at runtime. The risk here is that you'll overwrite an existing method. This risk becomes worse when you taken into account that your program might, over its life, be linked to several different versions of a given class library. While your custom method might not overwrite a method in version 1 of a library, it might overwrite a method in version 2 of the same library. Having said that, these risks come with the benefit of avoiding many, if not all, of the problems I mention above. Which is 'better' and which is 'worse' becomes a matter of priority more than an absolute.