That and the clear lack of experience with anything different than Java is clearly heavily influencing his perspective.

And I think there is no malice, it's just biased without realising it

Never used it, looks interesting and useful for Java. That's where I think the problem is: if you have used only one tool you tend to see everything from that perspective.

You seem to attack his argument on his background as a Java developer and not on parts of his argument. As far as I know, this is called an ad hominem attack and in my opinion does not belong on Hacker News.

If you can find good counter arguments on his arguments:

- Light Table is not novel or groundbreaking since Eclipse has had these kind of features for at least a decade (and several Smalltalk IDE's have had them for several decades), - Light Table's examples are contrived because real world examples do not behave in this way,

we'd be having a real discussion.

There are plenty of other comments here that explain why pdeva1 is coming from the wrong angle therefore I'm not going to repeat them.

Chris never mentioned novel or groundbreaking, others have so go and ask them but please before you do that look up the difference between invention and innovation and also remember that novel really means fresh or refreshing (although it's used most of the time to indicate new)

"Since he's a Java developer, he delivers critique on LightTable".

thereby pointing out that any other kind of developer would probably not have made such critique, thereby relating the validity of his critique with him being a Java developer/Eclipse user, thereby being an ad hominem attack.

On your last argument I would like to add that on Hacker News it is clearly branded as the next big thing since sliced bread.

Of course languages such a Clojure, Scala and Haskell need more sophisticated IDE's than vim + plugins. Especially for larger projects. And as such I think the features in the POC are a good idea. Still, they are nothing new and I'd expect them in any modern IDE. I could add some idea's of my own (stealing from an IDE I use daily):

- annotate the source with a git history - highlighting based on AST instead of regex's - outlines

Anyways, we agree that Light Table is not novel, nor groundbreaking and it's not an invention. Exactly the point Prashant Deva was trying to make. Nothing to see here, move along.

thereby pointing out that any other kind of developer would probably not have made such critique, thereby relating the validity of his critique with him being a Java developer/Eclipse user, thereby being an ad hominem attack.

No, it's more that he's writing as if he's unaware how parochially Java-centric his viewpoint is. Many of his points aren't very useful for other languages.

Well, although that point has been answered on other parts of the forum, it seems the auto-eval function is reserved for immutables only and non-recursive languages. So it seems this restriction reduces to number of applicable language to around zero. Thus, at least one of his points applies to all other languages. Do you want to hear argumentation for the other points?

It seems we've touched a nerve, which is a bit embarrassing. Clearly, the kinds of things the Light-Table gentleman is talking about are applicable to more than zero languages. I know because I've spent 1.5 decades coding in one. That you'd make such an argument indicates you aren't in command of all the facts, or you're willing to take or build up strawman interpretations.

(One famous gentleman once said, "If you ever get someone upset, you've struck gold!")

That said, "auto-eval," if this means automatic re-evaluation of everything is slick demo stuff. But nimbly being able to edit and save any source code, then being able to fearlessly rewind the stack to an appropriate point and go on as if the change was always there would be appropriate even for very involved and long running code, and is quite real.

Similarly, I know for a fact that everything else in the Light Table video has approximations in real environments.

I'm upset because the method of discussion here seems to revolve around tainting the credulity of the author ("That you'd make such an argument indicates you aren't in command of all the facts"); by claiming a conflict of interest while this is not applicable (the OP does not claim authority!); or by appeals to authority ("because I've spent 1.5 decades coding in one").

By the way, I feel that those who have to play the "If you ever get someone upset, you've struck gold!"-card, should listen to some more gentlemen talk about syllogisms.

You don't. I think the Light Table author is naive here. Instead, you let the programmer rewind the stack at will.

I'm upset because the method of discussion here seems to revolve around tainting the credulity of the author ("That you'd make such an argument indicates you aren't in command of all the facts")

The facts in question have to do with things I've seen implemented. Your argument is an indication you aren't aware of the same. That's not tainting your credulity. I'm questioning if you have all the facts.

By the way, I feel that those who have to play the "If you ever get someone upset, you've struck gold!"-card, should listen to some more gentlemen talk about syllogisms.

You are the one who is upset. You are also incorrect about what you purport to be upset about. (My intentions in pointing out certain facts and their implications.) Please process this data.

You should read Eristic Dialectics: The Art Of Being Right by Arthur Schopenhauer.

Saying he is biased because he is a java-only programmer isn't clearly a wrong statement, and it doesn't mean he's totally wrong either.

Just saying, but that's not the point of the article.

What would have happened if the author took those objections and turned them around, asking instead, what sort of language would need to exist to work ideally with a tool like light table? And, possibly, what sort of problems could more easily be solved if we adapted our language/development model to work with an environment like light table?

There may well be no amazing breakthrough here, just as the OP seems to argue, but it certainly seems as though it could (or should) function as an opportunity to rethink our tools and development methods a bit...

edit: Also, to the claim that many of the features of light table have been implemented elsewhere already, I'd point out that rarely are good ideas purely new, but successful advances come from sticking many little bits of innovation together in a powerful way

As with all things in life, sometimes even the best of us get into arguments. From semi-colons to jumping the shark because your app is published on multiple platforms, geeks have been known to have their fair share of silly rants. And this article represents one of them.

Let's ignore the obvious confirmation bias of the author with their Eclipse background and ask ourselves the pertinent question: even if the author is correct, so what?

With open choices, we can choose to use any IDE we feel like. Some, like myself, feel that Eclipse is too cluttered and would prefer a visually streamlined system. Why then devolve yourself into putting down the work of others because you don't like it?

There's an absolute difference between a review and the way the author propositioned and explained his rationale as to why Light Table was not for him, explained by the reactions here in HN.

Let's be critical, rather than criticise.

The instant evaluation model doesn't play nicely with side-effects. Exactly where side-effects occur can be difficult to determine, there's no simple way to work around this.

This is less of a problem in Clojure, thanks to its immutable data structures, but they're not a panacea. I'm also not sure how well this would work in JS and Python, the other languages that Light Table intends to initially target.

One possible solution is to have hooks into side-effects: you could display console output or logging alongside the instant evaluation. The real difficulty is network communication: even if you're okay with actually sending requests over the wire, there's an awkward balance between visibility and generality. Something like libpcap [1] is very general, but gives minimal insight into the content. Hooking into a particular HTTP client library gives you a lot more visibility into what's going on, but you'll need to do this every time you want to use a new library.

[1] http://www.tcpdump.org/

What is important is the execution and new wrinkles in the CURRENT iteration - NOT whether something vaguely or even pretty similar was attempted or proposed at some point in the past.