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

101–110 of 136 posts

Re: LightTable detailed critique: Concept vs Reality

#101

Post by GlennS »

weavejester wrote: post #71
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…

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

I don't think it's even a matter of 'well written' as such, just how the language works.

When every code path must end in a return value, writing large functions becomes difficult.

Re: LightTable detailed critique: Concept vs Reality

#102

Post by incongruity »

djhworld wrote: post #34
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…

I don't even see it as a critique, it's more of a "I use Eclipse and I like Eclipse because it is tailored to my needs as a Java developer" article.

Exactly... though it really underscored the idea that the tools we use (and the tools that go with those tools) can shape our worldview.

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

Re: LightTable detailed critique: Concept vs Reality

#103

Post by richardk »

Zak wrote: post #98
richardk wrote: post #83

Earlier quoted context omitted.

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

I'm not familiar enough with Clojure to comment.

Re: LightTable detailed critique: Concept vs Reality

#104

Post by stcredzero »

dibbeke wrote: post #80
stcredzero wrote: post #65

Earlier quoted context omitted.

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

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.

Re: LightTable detailed critique: Concept vs Reality

#105

Post by stcredzero »

prospero wrote: post #62
nightpool wrote: post #49

Earlier quoted context omitted.

you could mitigate side-effects by running all of lighttable in a VM, assuming no files and creating all the ones you need. Network requests could be intercepted. The key to make this workable would be sensible defaults, allowing you to just open it up and start a new project instantly, and allowing custimization for complicated projects.

The side-effect could also just be updating a mutable hash-map, which has much of the same issues, and isn't something that you can sandbox.

In Smalltalk, this isn't a problem. Our Dictionary instances are mutable. Usually, we realize it while continuing the debugging/editing (they happen at the same time) and we either rewind the stack a little further to get a new instance of the dictionary, or we can easily undo the side effect. It usually happens in less than the amount of time you took to read the previous sentence.

Re: LightTable detailed critique: Concept vs Reality

#106

Post by lemming »

eternalban wrote: post #54
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 think you are arguing a cultural phenomena. I am an Eclipse power user myself but alas Eclipse is not an effective option if I need to drop into a remote server and cut some code. (Yes, I use VIM for these occasions.) And let's be perfectly frank: developers who get their start on IDEs are typically (not all, don't be offended) relatively clueless on the command line. IntelliSense gives these what unix commands hav…

To wit, IDEs encourage complexity and bloat and fat function/methods

I write all my Clojure code in IntelliJ, using a (customised) version of La Clojure. Could you explain to me how this encourages complexity and bloat in my code?

Re: LightTable detailed critique: Concept vs Reality

#107

Post by lemming »

sirn wrote: post #11

> 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. Why do Light Table need to emulate something? People have been executing code in REPL since forever, Light Table instant feedback seems lik…

Because when you execute code in a REPL you choose when to do so, presumably because you understand the side effects. The IDE doesn't but has to execute the code anyway to give you the feedback. This might be useful for pure functions but you'd need some kind of integrated mocking functionality for impure code.

Re: LightTable detailed critique: Concept vs Reality

#108

Post by brazzy »

tel wrote: post #99
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 wi…

On could also see it exactly the other way round: Java's strong typing makes it possible for an IDE to do amazing things, which help you cope with horrible codebases, which in turn makes code viable that would be completely unmanageable in other languages.

As for "Java is essentially designed to be impossible to code without an IDE.", I'd say that's a pretty ridiculous statement given the state of art of IDEs at the time Java was designed and became widely used. They did little more than integrate editor, compiler and debugger.

Re: LightTable detailed critique: Concept vs Reality

#109

Post by [deleted] »

tel wrote: post #99
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 wi…

[deleted]

Re: LightTable detailed critique: Concept vs Reality

#110

Post by dibbeke »

cgray4 wrote: post #82
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…

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

In peer-review, the original authors are redacted, so the peer-review committee's bias is reduced (not eliminated, of course).

When a scientist is funded by the petrol industry, but has a long history of showing sound scientific results, I'd give him my full attention. Perhaps my reading of his results would be biased negatively if I would know his research is funded by a certain industry.

When that doctor publishes an article on his new drugs, I question where it is published, whether there have been similar results by other researchers, whether similar approaches have seen widespread application, whether the author can connect the results logically with other research, whether there has been a good peer review and whether I can understand his results. These metrics give me confidence. The funding of the researcher might interest me, but another researcher with a perfect clean sheet might get his funding in a more black-market way. They say you should follow the money, but generally it is difficult, if not impossible, to find the trail.

This means I question almost everything I read and unfortunately have little certainties. Then again "Nothing is so difficult as not deceiving oneself." -- Wittgenstein

Post reply on HN