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'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.