LightTable detailed critique: Concept vs Reality • Hacker News Board

Re: LightTable detailed critique: Concept vs Reality

#81

Post by dibbeke » Sun, Apr 22, 2012, 4:48 PM UTC

Rage wrote: post #46

dibbeke wrote: post #42

Earlier quoted context omitted.

Ah, another ad hominem! Let me reply with an ad hominem: Would you translate your statement into: "It is difficult to get Prashant Deva to understand something, when the salary of Prashant Deva depends upon his not understanding it"? No? Then don't make your senseless statement. Please argue his statement instead. Or, maybe you're not a computer scientist, because you're not able to comprehend and participate in a no…

Well, Eclipse is slow, crashes, has a lot of features but doesn't really do anything nicely (javadoc integration is damn awful tu use). More features doesn't mean better. What i like about LighTables is that it seems to have few features, but do them well. It has a nice clean UI (even if it's just mockup, i don't think it needs anything else) and the UX seems nice too from what i understood. Maybe what you didn't und…

Eclipse needs a good amount of memory and recently, unfortunately, has a tendency to crash. Most of the features can be disabled; the UI can be reconfigured to your liking. Btw, I generally disable the javadoc view and just F3 to the location to see the code and docs together (docs are often wrong anyways).

The problem with mockups is that they haven't touched reality yet: there is always so much detail you don't see at the start.

Re: LightTable detailed critique: Concept vs Reality

#82

Post by cgray4 » Sun, Apr 22, 2012, 5:00 PM UTC

dibbeke wrote: post #42

andos wrote: post #31

Earlier quoted context omitted.

"It is difficult to get a man to understand something, when his salary depends upon his not understanding it." That's the blog of a company that makes a tool that integrates with Eclipse.

Ah, another ad hominem! Let me reply with an ad hominem: Would you translate your statement into: "It is difficult to get Prashant Deva to understand something, when the salary of Prashant Deva depends upon his not understanding it"? No? Then don't make your senseless statement. Please argue his statement instead. Or, maybe you're not a computer scientist, because you're not able to comprehend and participate in a no…

If a scientist is funded by the petroleum industry and publishes articles saying that climate change isn't happening, is his connection relevant?

If a doctor is funded by a drug company and publishes articles saying that the company's drugs are good, is her connection relevant?

Even the best scientists can be biased, and being aware of the biases can help one decide how much attention to give arguments. If Prashant Deva is biased by his experience and funding against the technology that he is critiquing, then that is relevant information to me and many other people who read his critique. To suppress that information, as you seem to be trying to do, would be a blow against transparency. In my opinion, that would be a bad thing.

Re: LightTable detailed critique: Concept vs Reality

#83

Post by richardk » Sun, Apr 22, 2012, 5:05 PM UTC

Zak wrote: post #75

richardk wrote: post #40

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 think this is a critical point, has the author of LightTable considered what would happen with instant feedback for less trivial pieces of code? Besides that, I think this critique is fair, because honestly when I saw Lig…

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? Some of the code in his demo talked to the web framework he wrote (that I use in production code) and IIRC to the SQL abstraction layer he wrote (that I also use in production code). Something makes me think that he has given some thought to how these things might interact…

I'm not sure about others, but I wouldn't give my money to any software project that didn't describe in detail how it might overcome such glaring design challenges.

Re: LightTable detailed critique: Concept vs Reality

#84

Post by tikhonj » Sun, Apr 22, 2012, 5:14 PM UTC

edanm wrote: post #55

Aqueous wrote: post #51

Earlier quoted context omitted.

""looks cool, but can't be made". Why not? It's definitely cool and definitely can be made. The question is: will anyone want to use it, or is it just cool? Is the learning curve too steep to make us want to adopt it as our primary text editor? Does it really confer efficiency advantages over Emacs/Vim/TextMate/XCode/Eclipse/etc? To me, it stands a good chance of being widely adopted if and only if it is actually mor…

Efficiency is actually not the only, or even most important, concern. At least, not necessarily. For example, one important consideration is how easy to use it is, especially for new programmers. For better or worse, Eclipse makes programming in Java easier for many programmers. This is a pretty important consideration for most organizations.

I think valuing how easy it is to learn over efficiency is not the best option: learning even a difficult text editor takes a constant and reasonably small amount of time. Being more efficient is a benefit proportional to how much you use the editor. So anybody planning to program for a long time is probably going to be well served by learning a more efficient but "harder" editor.

Now, in the real world there are other considerations and the question is more complicated with regards to actual editors. However, given a hypothetical choice between something harder to learn but more efficient or easier to learn but less efficient I'd go for the former each time.

Re: LightTable detailed critique: Concept vs Reality

#85

Post by dibbeke » Sun, Apr 22, 2012, 5:54 PM UTC

Rage wrote: post #47

dibbeke wrote: post #38

Earlier quoted context omitted.

His argument is on how most concepts in light table are not novel. Branding light table as novel or groundbreaking is therefor incorrect and his post is called for. 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 a…

Ad hominem aren't always a logical fallacies, and, in this case, might not bet at all. Ad Personam are. 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.

Thanks for the reference, I'll surely read it. [Pause] I've just read the first couple of chapters and it is most surely an enjoyable read. It brings the current discussion into a completely different light. Thanks again.

Re: LightTable detailed critique: Concept vs Reality

#86

Post by [deleted] » Sun, Apr 22, 2012, 5:56 PM UTC

zacharyvoase wrote: post #25

I find this 'critique' (it's not a critique, it's a takedown) to run against the spirit of Hacker News. 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. And here's someone summaril…

[deleted]

Re: LightTable detailed critique: Concept vs Reality

#87

Post by nickik » Sun, Apr 22, 2012, 6:14 PM UTC

Tuna-Fish wrote: post #73

edanm wrote: post #58

Earlier quoted context omitted.

> I disagree, at least when it comes to 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 programme…

> 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, sh…

He later said that this is not true after some people provided some examples. Its more a 99% rule.

Most of them are Java Interop related but sometimes a algorithem is clearer in one function.

Re: LightTable detailed critique: Concept vs Reality

#88

Post by NathanRice » Sun, Apr 22, 2012, 6:23 PM UTC

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

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

Files are an artifact of early computing architecture, and holding on to them beyond their useful lifetime will only anchor us.

Re: LightTable detailed critique: Concept vs Reality

#89

Post by granitepail » Sun, Apr 22, 2012, 6:42 PM UTC

edanm wrote: post #58

weavejester wrote: post #52

Earlier quoted context omitted.

> 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 v…

> I disagree, at least when it comes to 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 programme…

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.

Re: LightTable detailed critique: Concept vs Reality

#90

Post by xer0x » Sun, Apr 22, 2012, 6:45 PM UTC

I'm really impressed with LightTable, and I was hoping for a more insightful critique of the project.

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.

Anyway, seeing so many people missing the point of this project finally pushed me into sponsoring it on KickStarter.