LightTable detailed critique: Concept vs Reality

For Java, you want to get the most out of your static typing. So, you need an IDE filled with analysis tools.

For dynamically typed languages, Eclipse doesn't cut it. It gets sluggish and crashes too often and that's not acceptable when your language is designed for rapid feedback.

I want something that gives me feedback as if I were using Firebug, but feels like I'm typing into Notepad++, and it seems like LightTable could fill that need.

My thinking is that Light Table will live or die by how responsive it feels.

IMHO IDEs are overrated. If any process can be automated, it will eventually end up in code, not in a GUI.

[disclaimer: i dont use any IDE)

It piqued peoples interest for good reason, because of a combination of many ideas working together in a clean interface. To criticise it for details ('this takes up half the screen', 'some of these things have been done before', 'this particular feature might not work for the kinds of work I do') is to entirely miss the point of a 'concept'. It needs constructive input (eg. 'this is a good idea, but would work better if done like that'). The kind of criticism provided here doesn't help anyone much at all.

Clojure, Lisp, and similar languages are homoiconic. That means they're beautifully suited to an interactive environment such as that provided by LightTable. Conceptually, unlike typical IDEs, LightTable is not a series of scripts that will attempt to help you deal with common development tasks such as looking up documentation and refactoring. Instead, you're interacting directly with the language.

I think it's quite telling that in Java, documentation is done through Javadoc comments, which are ignored by the compiler and sought out by a completely separate tool in order to build docs. In Clojure, documentation is part of the homoiconic code itself:

    (defn my-fn
      "This is the documentation, can be inspected on the fly"
      [] …)

Additionally, when programming in Clojure, you can do it interactively by modifying the environment on the fly. This was popularized by smalltalk, and is an extremely gratifying way to program: you can inspect and edit your program code while it's running, and have a fully-featured REPL into your program. This way of doing things blows GDB completely out of the water.

Note also that when coding functionally, files are often made up of many small single-purpose functions, which is actually much more maintainable than the example "real-world use case" function you provided.

Essentially, your entire argument is based around the assumption that Java is the right set of design patterns. I would argue that the Java language is deeply flawed, and leads to a 30:1 ratio of boilerplate code, markup, and structure to useful code. It's what makes Javadoc and IDE refactoring tools possible, but it's also what makes Java a nightmare to maintain and (for me) an extremely unpleasant language to work in.

I have never used LightTable, but for me, what it represents is a different way of thinking about programming. It's about interacting with your code directly and interactively. And actually, when writing Clojure, I often program in quite a similar fashion with existing tools (VimClojure / Clojure.tmbundle / Cake).