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

91–100 of 136 posts

Re: LightTable detailed critique: Concept vs Reality

#91

Post by alphakappa »

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…

Speaking of Sublime Text (2), I find that it has a lot of the features that Light Table is supposed to have. I can work with an abstracted view of file heirarchy (need to find a file? Shift+Cmd+P and then type anything - the fuzzy search beats wildcards any day). Need to find a function? Cmd+P and then type what you need.

Maybe in some version of ST2, they will add the ability to see documentation in an overlay when you mouseover a method (or maybe someone will write a Python plugin to do that). This editor already seems to be a long way towards the goals of Light Table.

Re: LightTable detailed critique: Concept vs Reality

#92

Post by loup-vaillant »

> I am assuming java here, so i will refer to classes instead of functions for my examples.

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 data to process, while in a function setting, one would seek to process data.

Re: LightTable detailed critique: Concept vs Reality

#93

Post by politician »

There are many many 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.

I don't think it is entirely Chris's responsibility for dispelling Java developers of this crazy notion that Light Table is for them, 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?

Re: LightTable detailed critique: Concept vs Reality

#94

Post by Someone »

Zak wrote: post #74
Someone wrote: post #44

Earlier quoted context omitted.

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.

See, THAT is why you think before you leap. Iteration #1: make it 'forbid to commit code' instead of 'forbid to write code'.

And I agree that that might only work fine in safety-critical code.

And writing useless tests won't help if this would be as strict as I envision. Imagine a project where you cannot commit

   if flag:
     doA
   else:
     doB
unless you have a test that hits the doA part and a test that hits the doB part. Complete code coverage, enforced by the system. I am thinking more and more that I do want to see such a tool, but not really will want to use it. Maybe iteration #2 is "hm, that is not the best of ideas". Although, if somebody would want to pay for such enforced code coverage, it could be fun to search for with design patterns that help it make easier to write such code...

Re: LightTable detailed critique: Concept vs Reality

#95

Post by catshirt »

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.

likewise, criticizing the long term potential for a project like this because it had tabs in the concept video is silly.

Re: LightTable detailed critique: Concept vs Reality

#96

Post by andos »

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…

I would translate it exactly like that, though it's actually not ad hominem but ad humanitatem, really. We are all biased creatures, as others have pointed out. I think the critique is biased, I think it is biased because the author put a lot of effort in his (otherwise awesome) Java product, and therefore I quoted Upton Sinclair.

For instance, he argues that it would take a lot of working around to provide instant feedback for code with side-effects, but isn't that obvious? The LightTable video doesn't claim it magically mocks every external component or does some other fancy stuff. That doesn't make the feature less useful, especially in a language like Clojure, which was used for the demo. For me, that part reads much like "since it ws so hard to create Chronon, one cannot pretend the LightTable features are so easy to implement. Let me prove that by putting LightTable in the context of my product."

There was — deliberately, yes — a bit of snide and a lot of cynicism in my post, but I hope to have made it clear that it was not without a reason (for the cynicism, at least).

Re: LightTable detailed critique: Concept vs Reality

#97

Post by Someone »

twelvechairs wrote: post #64
Someone wrote: post #44

Earlier quoted context omitted.

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

Yeah, I think thats a very reasonable viewpoint to take. To me there was a lot more depth in what you just said that the OP. What I will say though is that to me when you 'envison.. in a somewhat ugly way' its basically a guess that they won't find a nice way to solve the UI difficulties of things that weren't in the video. You might be proved right, but to really know (rather than guess) this, you need to spend prob…

"you need to spend probably some days thinking about and prototyping it"

I would _guess_ that "thinking about it and researching it" will be time better spent. Inventing the wheel often is a lot of fun, but it also can be a waste of time. I do not know the literature, but it would not really surprise me to learn that there is some cheap knowledge to mine from it.

Re: LightTable detailed critique: Concept vs Reality

#98

Post by Zak »

richardk wrote: post #83
Zak wrote: post #75

Earlier quoted context omitted.

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.

You seem to be focused on the instant feedback and stack display issues.

Instant feedback is not meaningfully different from a REPL in this respect. It is unlikely you would type imperative things like "delete this directory" in to a source file. You might define a cleanup function that deletes files, but it would be pretty unusual to call it at the toplevel unless you were intentionally using the code buffer as a REPL. I'll grant that immediate evaluation of such things might be a little dangerous, but Clojure, though the JVM does have mechanisms to dangerous things like file IO.

Stack display seems like an easier problem to solve: only display a certain depth, or just put a scroll bar on it. It doesn't matter how much stuff there is as long as you're looking at the part you're likely to want by default.

I think the one downfall of this project as currently envisioned might be that this is a great concept for Clojure and perhaps some other functional languages. It could be good for JS if written in a mostly functional style. Python is a little less functional and is commonly used for scripts, which wouldn't play as nicely with instant feedback.

Scripts are distinct from applications or daemons in that they normally contain a sequence of imperative actions that they evaluate and then quit. They might not define any functions at all. Applications and daemons typically run code from an entry point like a main() function. LightTable seems to be designed with Clojure in mind, and Clojure was not designed with scripts in mind.

Re: LightTable detailed critique: Concept vs Reality

#99

Post by tel »

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…

I can't help but feel that every person I've seen who loves their IDE codes Java. I, for years, did not understand this finding vim and emacs perfectly sufficient. I liked SLIME, but found it only marginally better than any non-"superpowered" editor/repl pairing.

Then I tried programming Java. I concede totally. It's not just easier to program Java with an IDE, Java is essentially designed to be impossible to code without an IDE. The language is simply too large and spread out to be held in your head without the help of tools.

I think the complexity you talk about---large functions in particular---are also endemic of "Java style". Clojure is a great example of code designed without an IDE in mind where functions need to be small and orthogonal just to make it possible to survive without an IDE. I think Light Table embraces that idea and seeks to solve organizational issues involved with "Clojure style" coding.

Re: LightTable detailed critique: Concept vs Reality

#100

Post by tel »

SoftwareMaven wrote: post #79
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…

That's definitely pathological, but not from a "small function" point of view. xor_it is simple unnecessary to write and xor_them is just a fold on xor_it. This is undue multiplication of names.

    _ = require 'underscore'
    xor_them = (them) -> _.reduce(them, (a,b) -> a^b)
Or better

    import Data.Bits (xor)

    xor_them :: Bits a => [a] -> a
    xor_them = foldl1 xor
Post reply on HN