LightTable detailed critique: Concept vs Reality

You're comparing Java to Clojure. Conceptually, they're insanely different--Apple and Oranges, really.<p>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.<p>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:<p><pre><code> (defn my-fn "This is the documentation, can be inspected on the fly" [] …) </code></pre> Instead of being a series of very reliable hacks on top of a language that doesn't support docs, docs are part of the environment.<p>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.<p>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.<p>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.<p>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).

I find this 'critique' (it's not a critique, it's a takedown) to run against the spirit of Hacker News.<p>Someone built a concept showing how the experience of writing code, for their corner of the software ecosystem, could be improved. They found popular support, and they're now setting about to make that concept happen. Congratulations; this is what Hacker News is supposed to be all about.<p>And here's someone summarily piecing apart and nitpicking on that concept (and the details of the demo video) for no apparent reason—there's no feedback or suggestions for improvement, it's just saying "well Eclipse does this and this and this already". I'm not impressed.

I find the OP to be off-base in critique of the LightTable concept. To be sure, the concept has some likely drawbacks and would need real-world application to gauge viability, but I thought the critique by comparison to Eclipse missed the point. If there is anything that good design has taught us, it's that doing things better has significantly greater value than simply doing more things.<p>For example, the first comparative in this critique is the "docs everywhere" feature. The OP shows that the LightTable concept "eats up half the screen", "can't resize", etc. while showing that Eclipse has the same feature (with the javadoc tab at the bottom of the screen.) The OP sees documentation show up in both places, so it's called a wash/irrelevant.<p>When I view those same two screenshots, I see a significant difference. In Eclipse, I see yet another tab/doc/thingy with information crammed in it; in LightTable, I see information displayed in parallel with the code, not having to compete for screen space. The OP's comment about documentation "eating up half the screen size" implies that more information on the screen is better than less information. I find the LightTable design in this scenario as saying some information is more important than others.<p>It's mostly just aesthetics, but aesthetics is kind of the point behind LightTable.

I agree with most of the points - documentation is well covered by IDE's, yep, I guess (don't use IDE's myself) ... finding functions is also pretty solved (personally I just use grep).<p>But I disagree with the part about small functions and the example being contrived because real world functions aren't small and you can't just get your output directly like that.<p>First of all, functions <i>should</i> be small. Anything you can unit test, you can put in this sort of instant feedback. It's basically just a unit test! Input goes in, output comes out. Without side-effects or other horrors.<p>Okay, so not <i>all</i> functions make sense to be unit tested. Sometimes you need an integration test and the function can't have direct output like that ... you have integration tests don't you? Why not just evolve the "Instant feedback" feature to being your set of tests?<p>I honestly don't care about much else in the LightTable demo. But I <i>love</i> the idea of instant feedback. Especially when working with Haskell or something.

Of course the original video was not perfect. It is a concept, not a fully fleshed out product.<p>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.

Everyone is jumping in to disagree with the OP.<p>I have to be honest: I thought the OP's points were very well made, and as much as I loved the LightTable demo, I think I immediately dismissed it, in my mind, as "looks cool, but can't be made".<p>I think there is a big disconnect between this author, a "working programmer" who actually writes code, and at least <i>some</i> of the commenters in this thread. Let me give my take on a few of the differences:<p>For one thing, the op mentioned that, while functions <i>should</i> be small, they usually aren't. And while functions, ideally, <i>should</i> be self-contained, most of the code people write is a mixture of calls to external sources, libraries, etc. I.e., things that <i>can't</i> be seen ahead of time. In practice, the OP is 100% correct. Most of the code I see, ends up being <i>exactly</i> this kind of code. I question whether anyone who claims otherwise has any experience with real systems. I just can't imagine anyone disagreeing that most code looks like this in the real world.<p>Another point of disconnect is the "I don't use an IDE" theme that's common here. I think you'll find that HNers, as a whole, are a lot more prone to be anti-IDE. Much of the "real world" programmers would be shocked that so many HNers give up the comfort of all that the IDE provides. And, at least to my mind, there is an attitude here that using an IDE makes you a worse programmer.<p>The truth is, the author is correct to point out that a lot of the cool stuff in the demo already exists. If for no other reason than to point out that, if you think a lot of the cool stuff shown in the demo is worth looking into, you might want to check out Eclipse or other IDEs.<p>Finally, let me make one final point, specifically to zacharyvoase and the others who think this post is "against the spirit of Hacker News", etc. I totally understand you, and I agree, the LightTable creator deserves a lot of credit for what he's trying to do, whether successful or not. But I think that a critique of the project, especially showing which parts of it have already been created, is <i>amazingly</i> beneficial. No, the OP did not offer many suggestions. But I imagine that, if the LightTable group did <i>not</i> know about some of the things that Eclipse does already, this post will help them out. And this post will certainly get them thinking about whether some of what they demoed is possible.<p>In fact, if it were me running the LightTable project, I might decide to start with an MVP of building LightTable as an Eclipse plugin, to check out some of their concepts.<p>Edit:<p>P.S. I shouldn't have to give "credentials" for expressing a view on HN, but I will anyway. I've been programming professionally for 8 years, and I now run a freelance/consulting software company so have seen many codebases.<p>More importantly, I'm an IDE and editor nut. Most of the start of my career was on Visual Studio, then SlickEdit, and since then I've tried out many IDEs and editors. I now mostly use Vim, while sometimes dropping into SublimeText.<p>I think Eclipse is an amazing tool, and couldn't imagine programming Java without it. I think most people here would be absolutely amazed at the help Eclipse gives in writing Java code, which I'm sure gives many programmers a huge boost in their time to code.

I'm a bit unconvinced about the 'language agnostic' assumption.<p>For Java, you want to get the most out of your static typing. So, you need an IDE filled with analysis tools.<p>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.<p>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.<p>My thinking is that Light Table will live or die by how responsive it feels.

Apart from a sparser screen, the heart is "instant feedback". There are challenges in scaling this up from the demo, but I want to see what can be done - it's Research and Development, not simple implementation. Chris Granger has a solid background for this (on the Visual Studio team). And working code. :-) IMHO there are obviously solutions to these problems, but I'm not sure how graceful/usable they'll be. Maybe great; maybe just a significant improvement; maybe just good for some niche cases - we'll see!<p>Firstly, we can sandbox - including the file-system; even make a copy, so it runs without "really" changing anything (in the limit, there's virtualization). Second, some of these problems are common to testing, where mocking is a standard solution to the same problem of wanting to run just <i>some</i> code. [Perhaps a significant result will be a way of auto-mocking?] And even if you don't Test, you still run code to see if it's working - this is the same; just faster. How do you control what code you run? Light Table can incorporate the same techniques. OTOH, I run code with ctrl-tab, up-arrow + return. It's pretty fast. Easing the setup of that would be good though.<p>The full version is not going be as magical as the demo; but it seems unlikely that current IDE tech has reached perfection, and cannot be improved upon...

&#62; Even if it were somehow to ignore api calls that say, modify your filesystem, how would the IDE 'know' about that api. Will someone have to manually go through all the apis in existence and make a list of which ones to emulate and which ones to not? That doesn't seem practical.<p>Why do Light Table need to emulate something? People have been <i>executing</i> code in REPL since forever, Light Table instant feedback seems like an extension to the REPL concept, with an ability to substitute all variables visually in-place. I can't see why it should be any different.

Don't agree with everything the author has to say (particularly functions) but I think it's fair criticism.<p>LightTable isn't going to be a great fit for some languages, specifically c, c#, java and c++ style languages; I'm extremely dubious you'll be able to get the sort 'instant feedback' shown in the demo for that sort of compiled complex language with cyclic dependencies (A imports B imports C, imports A. Yay, java... :P).<p>...but really, that's not what it's targeting.<p>So, fair criticism to the author I feel: don't complain you won't be able to use a hammer to cut down a tree.

I had an idea of creating IDE which frees developer from organizing files and functions etc. Every class definition and functions will be stored in CodeDB. Compiler/Interpreter talks to CodeDB to resolve. Controller seats in the middle and talking to All three, developer, CodeDB and compiler. Maybe I should create concept demo/video/image of it.

This critique seems to be analogous to a low level language programmer dismissing the benefits of a high level language because both are Turing complete.<p>Yes both IDEs may be able to do similar things, but it's the immediacy with which you can do them which sets them apart.<p><a href="http://www.paulgraham.com/avg.html" rel="nofollow">http://www.paulgraham.com/avg.html</a>

There are many <i>many</i> comments from people who watch the Light Table video, which is clearly written in a Lisp, and come away thinking that it'll work for their Javas, Pythons, or C#s. Yet, it is not at all clear to me that Light Table is an appropriate IDE for languages that are not functional and are not homoiconic.<p>I don't think it is entirely Chris's responsibility for dispelling Java developers of this crazy notion that Light Table is for <i>them</i>, and it might hurt the fundraising effort; but would you really want to be funded by people who have no real grasp of what you're building?

The OP comes off as a jerk, mistakenly claiming that Light Table was presented as "game-changing" or "revolutionary, outright dismissive of things that "were done 10 years ago" and, worst of all, critiquing in detail something that doesn't even exist.

Nobody said it was going to be easy. Where's the author's imagination? My guess is it was slowly killed by working inside of Java for many years.

Is the demo a bit contrived? Sure, but it's an inspired vision that was whipped up <i>inside of a week</i>. I don't think the creator has any illusions that making the vision a reality will be <i>easy</i>. However, it is clear that this vision is inspiring to a lot of developers and has some traction.

I don't much care for trendiness or bandwagon hopping, but there are a few things about lighttable clearly hit on the future of computing (though quite by accident, I imagine).<p>First, programs and databases will grow together continuously. The missing piece of the puzzle here is that currently most people view databases as a single correct representation of the world, and assume that whether you have an acid database or a nosql solution, all transactions must eventually be reconciled, and a single truth must emerge. This is patently false. In actuality, database systems will begin to resemble distributed version control systems very closely over the next five to eight years, until they are almost indistinguishable. The two will meet in the middle as all distributed revision control systems end up using off the shelf graph database systems, and these graph database systems incorporate additional functionality to support one them. At some point most editors will be capable of speaking directly to the database systems without file intermediates, and if we need to transmit program data from one place to another, it will be via cloning/replication, or a textual dump and restore in some (rare) circumstances. Make no mistake about it, the key-value and column based architecture of current nosql solutions is going to transition to graph databases in the not to distant future - the algorithms to make efficient use of graph databases aren't <i>quite</i> there yet but it is getting very close. The idea of a single consistent world view is going to shift to various contexts and sub-contexts where consistency need not hold throughout the hierarchy (exactly in the manner of forks and branches). We will share data by establishing contextual nesting and hierarchies of information primacy.<p>Files are an artifact of early computing architecture, and holding on to them beyond their useful lifetime will only anchor us.

There is definetely room for an IDE that is more intuitive and slick than Eclipse - I find Eclipse's many views and modes distracting. Perhaps Light Table is not a revolution of IDEs, but it is certainly a welcome leap in the evolution.

&#62; <i>I am assuming java here, so i will refer to classes instead of functions for my examples.</i><p>This particular difference makes this part of the comparison meaningless. Functions and classes don't operate at the same level of granularity. Thinking classes vs thinking functions can produce very very different code, especially if your classes are assignment happy, and your functions avoid side effects. Plus, you wouldn't search the same way. In a class setting, one would search for <i>data</i> to process, while in a function setting, one would seek to <i>process</i> data.

I'm really impressed with LightTable, and I was hoping for a more insightful critique of the project.<p>The integrated prototyping playground within the app is an excellent idea. Yes, LightTable is borrowing many ideas from WorryDream.com and that is one of the reasons it is so promising.<p>Anyway, seeing so many people missing the point of this project finally pushed me into sponsoring it on KickStarter.

I'm not sure why so many people are up-voting this. It isn't constructive or useful. It seems to be a guy who has a vested interest in Eclipse and Java trying to downplay a possible future competitor to a framework and environment he is comfortable with...

Eclipse as a good ide ? mpprfrffrt

<i>Also even if the code were indeed based on just basic numerical or string primitives, how would the 'instant feedback' work if the code were in a long, tight loop or did heavy cpu intensive stuff?</i><p>I think this is a critical point, has the author of LightTable considered what would happen with instant feedback for less trivial pieces of code?<p>Besides that, I think this critique is fair, because honestly when I saw LightTable, it seemed like smoke and mirrors. I have a friend quietly writing an innovative new text editor, I expect it will be more 'ground-breaking' than LightTable, but I don't see him trying to take everybody's money.

classic example of "a little knowledge is a dangerous thing". Many of the other comments explain why.

herein someone who doesn't program functional or dynamic languages concludes light table is contrived or impossible because Eclipse already does the job for them.<p>likewise, criticizing the long term potential for a project like this because it had tabs in the concept video is silly.

"Since I am a Java guy and the IDE concepts are defined as being language agnostic and that support for additional languages can be added later, I will compare the examples using Java code and Eclipse as the IDE."<p>And you end up proving nothing more than Java isn't a dynamic language where everything is available to you all the time without recompiling - and therefore won't really fit into to LightTable very well. The examples in LightTable are not contrived as you call them - people using dynamic programming environments work with instant feedback like this all the time.

Java is an Integrated Develompment Environment scripting language that is incompatible with Light Table.