Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

LightTable detailed critique: Concept vs Reality

eblog.chrononsystems.com

Post reply on HN
Print view View original

71–80 of 136 posts

Re: LightTable detailed critique: Concept vs Reality

#71

Post by weavejester »

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…

I can say that all of the Clojure code I've personally seen for "real world" systems in Clojure tend to have a very small average method size, but I can't speculate on proprietary code I haven't seen. Certainly most open source Clojure code is very well written.

And if Light Table is only an IDE for "better programmers" then I don't think that's necessarily a bad goal to have. That said, since Light Table is supporting Javascript as well, it's not exactly only catering for minority languages.

Re: LightTable detailed critique: Concept vs Reality

#72

Post by gnaritas »

zerostar07 wrote: post #14
jsmcgd wrote: post #10

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. 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. http://www.paulgraham.com/avg.html

You gave the answer yourself: if you want to make programmers more productive build a higher level language , not an IDE. 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)

Your critique is off the mark. IDE can do things that make no sense as a language feature but help you write code very fast. Command keys for things like show me all senders of this method, show me all references to this class, show me all implementations of this method, show me all inheritors of this method, go to the definition of this thing, show me a tree of the class hierarchy, rename this method fixing all senders, extract this code into a new method, extract these methods into a new superclass, push these methods up or down in the hierarchy.

These are things IDE's can do for you to enable you to code much faster by being aware of the structure of the language rather than editing everything as streams of text. I work in sublime text 2 doing ruby code, and I miss the hell out of these Smalltalk IDE features, text editors just can't compare; they're great at slinging text, but I don't want to sling text, I want to sling around semantically relevant chunks of code in ways that don't break it automatically.

Re: LightTable detailed critique: Concept vs Reality

#73

Post by Tuna-Fish »

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…

> 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, show it to me, and I'll prove you wrong."

That is some of the ethos behind the language.

Re: LightTable detailed critique: Concept vs Reality

#74

Post by Zak »

Someone wrote: post #44
twelvechairs wrote: post #16

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

Yes, but most, if not all, of the concept has been done before. Given that, I think the question why things would work better this time is one that the backers of this project should think about before starting development. My input would be that I think the cute displays in the video will not work on real-scale projects. One reason is that I do not see how the most interesting part, the live display of a call graph,…

I also would like to see a system that forbid me to write code that is not covered by a unit test yet.

I suspect that would lead to the people who are currently not writing unit tests writing useless tests just to circumvent the requirement. It would also make exploratory programming, where you haven't completely figured out what you want it to do much more difficult.

Re: LightTable detailed critique: Concept vs Reality

#75

Post by Zak »

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 with the real world.

I think it's fair to ask for money. Chris Granger has a track record of building useful, production-worthy libraries and tools both professionally and as a hobby. If he's going to not work for a while, possibly hire other people and build an open source IDE, it's reasonable to ask for outside funding.

Re: LightTable detailed critique: Concept vs Reality

#77

Post by pbreit »

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…

The gap probably isn't that wide, if at all, when only considering folks who might use Light Table.

Re: LightTable detailed critique: Concept vs Reality

#79

Post by SoftwareMaven »

edanm wrote: post #41

Everyone is jumping in to disagree with the OP. 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". I think there is a big disconnect between this author, a "working programmer" who actually writes code, and at least some of the commenters in this thread. Let me give my take…

For one thing, the op mentioned that, while functions should be small, they usually aren't.

Functions shouldn't be small just to be small. Functions should be exactly the size needed to encapsulate their function. I had to wade through a few thousand lines of JavaScript in which every function was made as small as possible (since functions are supposed to be small). Stuff like (and I am not exaggerating):

  var xor_it = function(a,b) {
    return a^b;
  };

  var xor_them = function(l) {
    out = 0;
    for (x in l) {
      out = xor_it(l[x], out);
    }
    return out;
  };
Turns out that, when functions are written based on small size alone, it is nearly impossible to build a mental model of a system. I've reverse engineered some ugly code (the previous worst was an object oriented system hand-built in C (with constructors, vtables, and all)). That was child's play next to a few thousand lines of three-line functions.

On topic, I tend to agree with you. The best parts of Light Table have existed in one form or another for years, but that doesn't mean it isn't worthwhile to "Try, try again". Approaching an old problem with new vigor can result in amazing things, or nothing, but if you aren't willing to listen to criticism, you will never make a better mousetrap.

Re: LightTable detailed critique: Concept vs Reality

#80

Post by dibbeke »

stcredzero wrote: post #65
dibbeke wrote: post #45

Earlier quoted context omitted.

As far as I can see, you're arguing: "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…

"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. 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 ver…

Ah, finally, here we have the gist of the argument: "Many of his points aren't very useful for other languages." The rest is all noise and no signal.

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?

Post reply on HN