> 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 values of variables, and I wonder how well Light Table would work for Javascript. However, since Clojure is a functional language, there's very little hidden state to worry about.
Most of the critique seems to be either "This isn't new" or "This wouldn't work in Java". But just because something isn't new doesn't mean it isn't beneficial to do it, or that existing UIs could not be improved. The Light Table demonstration of inline docs seems more responsive and more immediate than the equivalent functionality I've seen in Eclipse.
Secondly, even though Light Table is supposed to be language agnostic, it doesn't really seem designed for languages like Java. The dynamic code traces demonstrated would work very well for Clojure, but I can certainly imagine production Java code being too complected for it to be useful. But that's fine; just because it isn't suited for Java doesn't mean I can't take advantage of it in 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 programmers (e.g. Paul Graham's article on Python programmers tending to be better).
Having said that, please don't be offended - I'm speaking in generalities here. If you specifically have evidence that real world systems written in Clojure still look this tidy, that just makes me want to learn Clojure all the more.
Btw, I completely agree that making an amazing IDE for only one language is still a great goal, even though I would personally find it hard to work with a different IDE for Clojure and for my other code.
For those of you who don't know, weavejester is the creator and maintainer of a few of the more prominent (and, in my opinion, production ready) clojure libraries (thanks!), mostly centered around web serving. His code is concise and chunked into many small functions, abstracting out as much functionality as is possible -- this is the lisp way.
If you've written much clojure (or any other lisp, really) you likely realize that writing massive functions is not a part of the lisp paradigm, and for good reason -- not only are large functions tough to read, but the notion of everything being a function makes it natural to build what are essentially nested function calls into more abstract functional representations.
I understand why Chris has mentioned support for other languages (raising money + support), but anyone who approaches this project should really keep in mind the fact that it is being built with Clojure in mind. I'm sure that, should it be funded and seen to completion, Light Table will provide a rich experience for other languages, but what is most exciting about this project is its potential to truly cater to the needs of a functional programmer. As he correctly states in his introduction, functions are the most often used "block" in functional programming, and editors/IDE's should reflect that and I am hoping Light Table manages to do this.
Regarding the criticism of live code evaluation, I see it as a bit absurd. It should be obvious that the main goal of such an interaction with one's code is not to test functions on live inputs. I see this being most useful in scenarios where the programmer wishes to, say, process strings read in through a socket. Live code evaluation could be immensely useful in a situation in which someone writes their parsing functions and then calls the higher level function on that test input and sees the string progress through their parsing functions, making it much easier to debug. This is just one example.
This response is a bit scattered, as I wrote it piece-wise while cleaning up. Sold as-is.
> If you specifically have evidence that real world systems written in Clojure still look this tidy, that just makes me want to learn Clojure all the more.
Go look at any Clojure project on github. Seriously.
Stuart Halloway, one of the more prominent Clojure committers and evangelists once (semi-)famously said: "No function should ever be longer than 5 lines. And if you think you have one that needs to be longer, show it to me, and I'll prove you wrong."
I can say that all of the Clojure code I've personally seen for "real world" systems in Clojure tend to have a very small average method size, but I can't speculate on proprietary code I haven't seen. Certainly most open source Clojure code is very well written.
And if Light Table is only an IDE for "better programmers" then I don't think that's necessarily a bad goal to have. That said, since Light Table is supporting Javascript as well, it's not exactly only catering for minority languages.
>>I'm speaking in generalities here. If you specifically have evidence that real world systems written in Clojure still look this tidy, that just makes me want to learn Clojure all the more.
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.
This made me go check our Clojure code base at work: including comments, docstrings and whitespace, our functions average about 11.5 lines each (and I know we could clean up some of our earlier code to reduce that average). So, yeah, I'll consider that evidence that real world Clojure is pretty tidy.
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 values of variables, and I wonder how well Light Table would work for Javascript. However, since Clojure is a functional language, there's very little hidden state to worry about.
Most of the critique seems to be either "This isn't new" or "This wouldn't work in Java". But just because something isn't new doesn't mean it isn't beneficial to do it, or that existing UIs could not be improved. The Light Table demonstration of inline docs seems more responsive and more immediate than the equivalent functionality I've seen in Eclipse.
Secondly, even though Light Table is supposed to be language agnostic, it doesn't really seem designed for languages like Java. The dynamic code traces demonstrated would work very well for Clojure, but I can certainly imagine production Java code being too complected for it to be useful. But that's fine; just because it isn't suited for Java doesn't mean I can't take advantage of it in Clojure.