Earlier quoted context omitted.
> I just can't imagine anyone disagreeing that most code looks like this in the real world. I disagree, at least when it comes to Clojure. The size of the functions in the demonstration is about average for Clojure. The author of the critique suggests that the examples are "contrived", but speaking as a Clojure programmer, I didn't get that impression at all. Hidden state change might cause problems for tracing the v…
> I disagree, at least when it comes to Clojure. This hits on another difference: Java is much, much, much more likely to be used in the real world over Clojure. The set of people who use Clojure are very likely to be in the set of people who write small functions, both because they're more "cutting edge" in terms of TDD, because they're only writing "toy" or "hobby" projects, or because they're just better programme…
The number of people even wanting to learn clojure are generally going to be in the bracket of people who are going to learn not just for a living but to perfect their craft. So you are likely to find good programmers in Clojure than in Java. In fact it might be difficult to find bad clojure programmers.
On the hand other chances of finding good programmers among java programmers is going to be difficult. And your average Java programmer can't even write a fully functional program let alone a full app without eclipse doing 90% of the auto completion, and vast part of code automation happening automatically for him. So the IDE use case for a java programmer is totally different. What a java programmer needs is a tools that can program in itself with little inputs from him.
Light table is not for code automation and auto completion in itself. Its for programmers who like think instead of IDE doing that for them.