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

61–70 of 136 posts

Re: LightTable detailed critique: Concept vs Reality

#61

Post by stcredzero »

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…

Real world Smalltalk projects have mostly short methods, with some exceptionally long ones.

Re: LightTable detailed critique: Concept vs Reality

#62

Post by prospero »

nightpool wrote: post #49
prospero wrote: post #36

Earlier quoted context omitted.

There is a valid point lurking in there. 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…

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.

Re: LightTable detailed critique: Concept vs Reality

#63

Post by Aqueous »

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.

Right - I include that under the learning curve question. But, that said, there are plenty examples of editors that are obviously not easy to use(cough Emacs?) and yet tons of people still use them because (apparently) they are more productive in Emacs. I'm not one of those people - I tend to prefer TextMate or TextMate-like GUI editors. But I can see how people are willing to suffer through a steep learning curve in order to ultimately become more productive. LightTable might end up being the same way.

Re: LightTable detailed critique: Concept vs Reality

#64

Post by twelvechairs »

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

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 probably some days thinking about and prototyping it, which assumedly they will do (and we have not).

I think they should be encouraged to do so, and my main problem with the OP was its basically discouraging tone of 'its never going to work because you haven't shown me a perfect final version that covers all bases'.

Re: LightTable detailed critique: Concept vs Reality

#65

Post by stcredzero »

dibbeke wrote: post #45
ABS wrote: post #39

Earlier quoted context omitted.

first: I replied to zacharyvoase's comment and therefore my comment was related to his, don't take it in isolation. 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…

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 very useful for other languages.

Re: LightTable detailed critique: Concept vs Reality

#66

Post by spooneybarger »

edanm wrote: post #59
stcredzero wrote: post #56

Earlier quoted context omitted.

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". As a longtime Smalltalker and contributor to a Smalltalk development tool, I think it is possible, though the odds are long, based on what the LightTable guy doesn't know. More importantly, I'm an IDE and editor nut. Most of…

Several people in the original LightTable thread mentioned that SmallTalk has many of these ideas. I confess that I know nothing about SmallTalk - can you please point me to a description specifically about SmallTalk IDEs and how they do all these things?

I'd suggest as a simple introduction, downloading a copy of "Pharo By Example" and working through everything in it.

Pharo isn't the prettiest of Smalltalk experiences, but It will give you a glimpse into Smalltalk but really, it takes a good amount of time of use ( for me it was 9 months ) before I really got Smalltalk.

I'd also be completely happy to have an ongoing email conversation where I could answer any questions you have and fill you in on both the good and bad points of the current Smalltalk experience.

Re: LightTable detailed critique: Concept vs Reality

#67

Post by spooneybarger »

dibbeke wrote: post #29
kenneth wrote: post #18

You're comparing Java to Clojure. Conceptually, they're insanely different--Apple and Oranges, really. Clojure, Lisp, and similar languages are homoiconic. That means they're beautifully suited to an interactive environment such as that provided by LightTable. Conceptually, unlike typical IDEs, LightTable is not a series of scripts that will attempt to help you deal with common development tasks such as looking up do…

Java's annotations could be seen as 'part of the environment' (whatever that may mean). I often use annotations which indicate how a method should be used, and those annotations are used by static analysis to validate correctness. When using Java, I often change my program while it is running. recompiling classes on the fly. It works in most cases, and when it doesn't work, I believe other languages would fail as wel…

"When using Java, I often change my program while it is running. recompiling classes on the fly. It works in most cases, and when it doesn't work, I believe other languages would fail as well."

I use Java fulltime at work and also have some problems where recompiling classes on the fly doesn't work. I never had the problem with Smalltalk. To assume the problems in one environment will be problems in another is exactly the problem with the original article. It assumes that because something similar exists in X, it would be the same in Y and have the same sorts of issues and rewards.

"Finally, lighttable is a proof-of-concept... It's not there yet; there are no reviews; leagues of smart engineers have tried to reproduce something similar and could not escape the POC phase at all."

A large chunk of what is in light table has existed in over a quarter century in Smalltalk environments and been used to build large and complex applications.

Re: LightTable detailed critique: Concept vs Reality

#68

Post by spooneybarger »

dibbeke wrote: post #38
ABS wrote: post #32

Earlier quoted context omitted.

not really, just that all of us come with a point of view and I think his is made clear by the work he is doing on that project. 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.

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…

I'd say that instant eval in the 'inventing on principle' fashion does make it novel and groundbreaking. Everything in it don't have to be. The core premise, a general purpose IDE based around those ideas is.

Re: LightTable detailed critique: Concept vs Reality

#70

Post by spooneybarger »

iamgopal wrote: post #6

I had an idea of creating IDE which frees developer from organizing files and functions etc. Every class definition and functions will be stored in CodeDB. Compiler/Interpreter talks to CodeDB to resolve. Controller seats in the middle and talking to All three, developer, CodeDB and compiler. Maybe I should create concept demo/video/image of it.

You should check out a Smalltalk environment that isn't Gnu Smalltalk or Redline Smalltalk, neither of which currently has the full Smalltalk IDE experience.

"Pharo By Example" would be a good starting point. If you are interested, feel free to email me, I'm quite happy to introduce people to what a Smalltalk environment has to offer so they can take it back to their day to day and start to spread the ideas.

Post reply on HN