6 ms·

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,

by edanm 15y ago

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 on a few of the differences: For one thing, the op mentioned that, while functions should be small, they usually aren't. And while functions, ideally, should be self-contained, most of the code people write is a mixture of calls to external sources, libraries, etc. I.e., things that can't be seen ahead of time. In practice, the OP is 100% correct. Most of the code I see, ends up being exactly this kind of code. I question whether anyone who claims otherwise has any experience with real systems. I just can't imagine anyone disagreeing that most code looks like this in the real world. Another point of disconnect is the "I don't use an IDE" theme that's common here. I think you'll find that HNers, as a whole, are a lot more prone to be anti-IDE. Much of the "real world" programmers would be shocked that so many HNers give up the comfort of all that the IDE provides. And, at least to my mind, there is an attitude here that using an IDE makes you a worse programmer. The truth is, the author is correct to point out that a lot of the cool stuff in the demo already exists. If for no other reason than to point out that, if you think a lot of the cool stuff shown in the demo is worth looking into, you might want to check out Eclipse or other IDEs. Finally, let me make one final point, specifically to zacharyvoase and the others who think this post is "against the spirit of Hacker News", etc. I totally understand you, and I agree, the LightTable creator deserves a lot of credit for what he's trying to do, whether successful or not. But I think that a critique of the project, especially showing which parts of it have already been created, is amazingly beneficial. No, the OP did not offer many suggestions. But I imagine that, if the LightTable group did not know about some of the things that Eclipse does already, this post will help them out. And this post will certainly get them thinking about whether some of what they demoed is possible. In fact, if it were me running the LightTable project, I might decide to start with an MVP of building LightTable as an Eclipse plugin, to check out some of their concepts. Edit: P.S. I shouldn't have to give "credentials" for expressing a view on HN, but I will anyway. I've been programming professionally for 8 years, and I now run a freelance/consulting software company so have seen many codebases. More importantly, I'm an IDE and editor nut. Most of the start of my career was on Visual Studio, then SlickEdit, and since then I've tried out many IDEs and editors. I now mostly use Vim, while sometimes dropping into SublimeText. I think Eclipse is an amazing tool, and couldn't imagine programming Java without it. I think most people here would be absolutely amazed at the help Eclipse gives in writing Java code, which I'm sure gives many programmers a huge boost in their time to code.

Aqueous 15y ago
""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 more efficient to use it and if the time of adoption doesn't outweigh those efficiency advantages. I don't have an answer to this question, because I haven't actually used it. I suggest that since everyone else hasn't either, we wait to pass judgment on whether it will work or not.
- edanm 15y ago
  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.
  - Aqueous 15y ago
    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.
  - tikhonj 15y ago
    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.

by edanm 15y ago

Aqueous 15y ago

""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 more efficient to use it and if the time of adoption doesn't outweigh those efficiency advantages. I don't have an answer to this question, because I haven't actually used it. I suggest that since everyone else hasn't either, we wait to pass judgment on whether it will work or not.

edanm 15y ago
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.
- Aqueous 15y ago
  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.
- tikhonj 15y ago
  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.