8 ms·

I am sad that LT didn't succeed as I hoped (I was a backer), but this email highlights a very important feature for succesful open-source projects (which LT was

I am sad that LT didn't succeed as I hoped (I was a backer), but this email highlights a very important feature for succesful open-source projects (which LT was meant to be from the start), which is to make them accessible to other contributors. Building your project in a niche language (not just Clojure, but ClojureScript) is a risk. Making it tough to follow the code/data flow is indeed a terrible decision (though usually a silent one as a side-effect of other architectural choices). Etc... I'm an Emacs user, and I'm still waiting for the Next Great Editable Editor. (Though since it moved to Git [thanks ESR!], maybe Emacs itself will get a new wind)

melling 12y ago
What would it take for Emacs to become "the next great editor"? It extremely extensible now. Packages like Helm and Company mode have made emacs more competitive, for example. https://github.com/emacs-helm/helm/wiki https://github.com/emacs-helm/helm/wiki http://company-mode.github.io http://company-mode.github.io
- AceJohnny2 12y ago
  Yeah, Emacs may already be the Next Great Editor and not know it yet ;) It needs to be more novice-friendly, having pre-CUA [1] shortcuts and terms ("windows" & "frames") is a trivial but powerful obstacle, I think. It needs to modernize its extension language: I still can't believe a 'then' clause needs a 'progn' if it's to contain multiple statements, but 'else' doesn't. I'm crossing my fingers for Guile, which, though still a niche language (Scheme), is at least more modern and standardized. I don't know how robust the interaction between the elisp (which is, like it or not, is here to stay) and Guile code is. Emacs has a humongous codebase at over 2M lines of code [2] (of which, admittedly, 1.5M of that is elisp), with some deep black art as legacy from what it needed to run on when it started (thanks to ESR's work, the git history actually spans the entire 30 year history of the project! Here's the very first commit: [3] [Though admittedly because of RCS's per-file semantics, the early history is a bit weird). But more importantly, it needs more mindshare. I'm hoping the git transition can help that. [1] http://en.wikipedia.org/wiki/IBM_Common_User_Access http://en.wikipedia.org/wiki/IBM_Common_User_Access [2] https://www.openhub.net/p/emacs https://www.openhub.net/p/emacs (slow server) [3] http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=ce5584125c44a1a2fbb46e810459c50b227a95e2 http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=ce5584...
  - AceJohnny2 12y ago
    Maybe the CUA thing doesn't matter. After all, Vim is much worse in first impression, but it's more popular by an order of magnitude. Maybe Emacs just needs to be installed by default, and for that, needs to slim down. Make more of its embedded elisp optional?
    - wodenokoto 12y ago
      To me it is all about a sane starting point. With Sublime I could jump in and start writing code in a beautiful and immediately helpful environment, even though I had never programmed before. As I got better at programming I wanted more advanced features and most of them I found in the included batteries, and a few I got from plugins (although all the good plugins I want seem to have died). With VIM or Emacs I have no idea where to start, except for maybe a few weeks in the terminal and manual before I can even start to code. Then it is still an open question about what it will scale to. I am not sure I want my environment to look like [this].(http://blog.jetbrains.com/pycharm/files/2013/06/vim3-1024x748.gif http://blog.jetbrains.com/pycharm/files/2013/06/vim3-1024x74...) With Spyder, RStudio and Octave GUI I can start programming right away, I can see the benefit of the IDE right away, the only problem is I have 3 different text editors with their own short cuts and features.
      - tincholio 12y ago
        If it takes you a few weeks to get started with the basics (in either Emacs or vim), you're doing it wrong. Following their respective tutorials you can get up and running (for basic open/navigate/edit/save/search/replace) functionality in a few hours. You won't be proficient, but you should be able to get stuff done. The rest comes with usage; you can't learn either editor properly by reading the whole book and then not using them. Proficiency comes from constant use, and you never stop learning. I'm an Emacs user of 13 years, and using Evil for the last 3 or so, so I'm comfortable in vim as well, and I still learn new stuff about them all the time.
        crucialfelix 12y ago
- Touche 12y ago
  It would have to run in a web browser, for me.
- dilap 12y ago
  For me, the problem with emacs is that (1) it's slow and (2) so many features are half-broken. To use the most random example, I'm using something to intelligently soft-wrap code (which is great!), but for some reason sometimes it doesn't work in C# mode. And in fact, loading C# code gives some random error in font-lock sometime. (Maybe these are slightly unfair since they're 3rd party code, but trust me, the entire emacs ecosystem lives in a state of "kind of, sort of" works.) Here's me complaining about slow text rendering: http://www.reddit.com/r/emacs/comments/2e8byy/slowass_text_rendering/ http://www.reddit.com/r/emacs/comments/2e8byy/slowass_text_r... Still, I keep using emacs because so far nothing else I've tried touches it. But I dream of an editor with the flexibility of emacs, but a strong focus on speed and correctness. (And terminal support -- terminals are very much still with us!) A tall order, I know :)
  - peatmoss 12y ago
    The interesting projects I've been keeping an eye on are the port of Emacs to Guile and the Haskell-based Yi editor. Guilemacs will be an incremental improvement to Emacs, whereas Yi could be something entirely new.
- lmm 12y ago
  The extensions would need to be maintainable. And interoperable. And integrated, at which point they'd possibly cease to be extensions. My problem with extensible editors is that you have a combinatorial explosion of possible configurations, which therefore aren't fully tested. So you always end up with something slightly buggy.
sheepmullet 12y ago
"Building your project in a niche language (not just Clojure, but ClojureScript) is a risk." If you are writing a tool to help java programmers program in java then writing it in java makes sense. The problem is he was writing a tool that was not cutting edge enough for the clojure folks, and not easily approachable for its main users.
SCdF 12y ago
> I am sad that LT didn't succeed as I hoped (I was a backer) Ditto. I'm especially sad that while it's a cool editor that does some neatish things, it's still just an editor + some neat stuff. The demo that was originally shown and pitched[1] was much more of a re-imagining of the concept of how we use editors, and _that_ was what I was looking forward to. I downloaded LT once and then decided to wait until those concepts arrived. At this point it's pretty clear that day will never come. [1] http://www.chris-granger.com/2012/04/12/light-table---a-new-ide-concept/ http://www.chris-granger.com/2012/04/12/light-table---a-new-...
- seanmcdirmid 12y ago
  Chris didn't give up, he just changed his approach to something that has a better chance of working. Those of us who have been working in this field for awhile already guessed that many of the features promised by the original lighttable kickstarter would require a new programming model to really work out.
  - SCdF 12y ago
    I don't mean to imply that Chris gave up, just that LT is not going going to reach the features discussed in the original pitch. > Those of us who have been working in this field for awhile already guessed that many of the features promised by the original lighttable kickstarter would require a new programming model to really work out. I guess I was naive, I presumed Chris knew something I didn't.
    - seanmcdirmid 12y ago
      Reinventing programming is still a new field. We aren't really sure what is possible or not, and there are bound to be overly optimistic as well as pessimistic predictions.
      - marktangotango 12y ago
        The problem I have with the notion of 'reinventing programming' is, you know what? Those guys in the 60's and 70's where pretty damn smart. A lot of really cool tech came before, but has been forgotten. We are living in the age that Richard Gabriel predicted the unix/c perfect virus won just as he said[1]. Which is sad and good in different ways. One of the sad parts is; all we have to show from xerox parc[2] is modern windowing systems (imo). So my point is; 'rediscovery' is a more apt way of expressing a lot of things today. [1] http://www.jwz.org/doc/worse-is-better.html http://www.jwz.org/doc/worse-is-better.html [2] http://en.wikipedia.org/wiki/PARC_%28company%29#History http://en.wikipedia.org/wiki/PARC_%28company%29#History
zubairq 12y ago
I disagree. I think LightTable was a great success. Personally, the product we made with LightTable positively affects thousands of people here in Scandinavia. What were your expectations from Light Table?

melling 12y ago

What would it take for Emacs to become "the next great editor"? It extremely extensible now. Packages like Helm and Company mode have made emacs more competitive, for example. https://github.com/emacs-helm/helm/wiki https://github.com/emacs-helm/helm/wiki http://company-mode.github.io http://company-mode.github.io

AceJohnny2 12y ago
Yeah, Emacs may already be the Next Great Editor and not know it yet ;) It needs to be more novice-friendly, having pre-CUA [1] shortcuts and terms ("windows" & "frames") is a trivial but powerful obstacle, I think. It needs to modernize its extension language: I still can't believe a 'then' clause needs a 'progn' if it's to contain multiple statements, but 'else' doesn't. I'm crossing my fingers for Guile, which, though still a niche language (Scheme), is at least more modern and standardized. I don't know how robust the interaction between the elisp (which is, like it or not, is here to stay) and Guile code is. Emacs has a humongous codebase at over 2M lines of code [2] (of which, admittedly, 1.5M of that is elisp), with some deep black art as legacy from what it needed to run on when it started (thanks to ESR's work, the git history actually spans the entire 30 year history of the project! Here's the very first commit: [3] [Though admittedly because of RCS's per-file semantics, the early history is a bit weird). But more importantly, it needs more mindshare. I'm hoping the git transition can help that. [1] http://en.wikipedia.org/wiki/IBM_Common_User_Access http://en.wikipedia.org/wiki/IBM_Common_User_Access [2] https://www.openhub.net/p/emacs https://www.openhub.net/p/emacs (slow server) [3] http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=ce5584125c44a1a2fbb46e810459c50b227a95e2 http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=ce5584...
- AceJohnny2 12y ago
  Maybe the CUA thing doesn't matter. After all, Vim is much worse in first impression, but it's more popular by an order of magnitude. Maybe Emacs just needs to be installed by default, and for that, needs to slim down. Make more of its embedded elisp optional?
  - wodenokoto 12y ago
    To me it is all about a sane starting point. With Sublime I could jump in and start writing code in a beautiful and immediately helpful environment, even though I had never programmed before. As I got better at programming I wanted more advanced features and most of them I found in the included batteries, and a few I got from plugins (although all the good plugins I want seem to have died). With VIM or Emacs I have no idea where to start, except for maybe a few weeks in the terminal and manual before I can even start to code. Then it is still an open question about what it will scale to. I am not sure I want my environment to look like [this].(http://blog.jetbrains.com/pycharm/files/2013/06/vim3-1024x748.gif http://blog.jetbrains.com/pycharm/files/2013/06/vim3-1024x74...) With Spyder, RStudio and Octave GUI I can start programming right away, I can see the benefit of the IDE right away, the only problem is I have 3 different text editors with their own short cuts and features.
    - tincholio 12y ago
      If it takes you a few weeks to get started with the basics (in either Emacs or vim), you're doing it wrong. Following their respective tutorials you can get up and running (for basic open/navigate/edit/save/search/replace) functionality in a few hours. You won't be proficient, but you should be able to get stuff done. The rest comes with usage; you can't learn either editor properly by reading the whole book and then not using them. Proficiency comes from constant use, and you never stop learning. I'm an Emacs user of 13 years, and using Evil for the last 3 or so, so I'm comfortable in vim as well, and I still learn new stuff about them all the time.
      - crucialfelix 12y ago
Touche 12y ago
It would have to run in a web browser, for me.
dilap 12y ago
For me, the problem with emacs is that (1) it's slow and (2) so many features are half-broken. To use the most random example, I'm using something to intelligently soft-wrap code (which is great!), but for some reason sometimes it doesn't work in C# mode. And in fact, loading C# code gives some random error in font-lock sometime. (Maybe these are slightly unfair since they're 3rd party code, but trust me, the entire emacs ecosystem lives in a state of "kind of, sort of" works.) Here's me complaining about slow text rendering: http://www.reddit.com/r/emacs/comments/2e8byy/slowass_text_rendering/ http://www.reddit.com/r/emacs/comments/2e8byy/slowass_text_r... Still, I keep using emacs because so far nothing else I've tried touches it. But I dream of an editor with the flexibility of emacs, but a strong focus on speed and correctness. (And terminal support -- terminals are very much still with us!) A tall order, I know :)
- peatmoss 12y ago
  The interesting projects I've been keeping an eye on are the port of Emacs to Guile and the Haskell-based Yi editor. Guilemacs will be an incremental improvement to Emacs, whereas Yi could be something entirely new.
lmm 12y ago
The extensions would need to be maintainable. And interoperable. And integrated, at which point they'd possibly cease to be extensions. My problem with extensible editors is that you have a combinatorial explosion of possible configurations, which therefore aren't fully tested. So you always end up with something slightly buggy.

sheepmullet 12y ago

"Building your project in a niche language (not just Clojure, but ClojureScript) is a risk." If you are writing a tool to help java programmers program in java then writing it in java makes sense. The problem is he was writing a tool that was not cutting edge enough for the clojure folks, and not easily approachable for its main users.

SCdF 12y ago

> I am sad that LT didn't succeed as I hoped (I was a backer) Ditto. I'm especially sad that while it's a cool editor that does some neatish things, it's still just an editor + some neat stuff. The demo that was originally shown and pitched[1] was much more of a re-imagining of the concept of how we use editors, and _that_ was what I was looking forward to. I downloaded LT once and then decided to wait until those concepts arrived. At this point it's pretty clear that day will never come. [1] http://www.chris-granger.com/2012/04/12/light-table---a-new-ide-concept/ http://www.chris-granger.com/2012/04/12/light-table---a-new-...

seanmcdirmid 12y ago
Chris didn't give up, he just changed his approach to something that has a better chance of working. Those of us who have been working in this field for awhile already guessed that many of the features promised by the original lighttable kickstarter would require a new programming model to really work out.
- SCdF 12y ago
  I don't mean to imply that Chris gave up, just that LT is not going going to reach the features discussed in the original pitch. > Those of us who have been working in this field for awhile already guessed that many of the features promised by the original lighttable kickstarter would require a new programming model to really work out. I guess I was naive, I presumed Chris knew something I didn't.
  - seanmcdirmid 12y ago
    Reinventing programming is still a new field. We aren't really sure what is possible or not, and there are bound to be overly optimistic as well as pessimistic predictions.
    - marktangotango 12y ago
      The problem I have with the notion of 'reinventing programming' is, you know what? Those guys in the 60's and 70's where pretty damn smart. A lot of really cool tech came before, but has been forgotten. We are living in the age that Richard Gabriel predicted the unix/c perfect virus won just as he said[1]. Which is sad and good in different ways. One of the sad parts is; all we have to show from xerox parc[2] is modern windowing systems (imo). So my point is; 'rediscovery' is a more apt way of expressing a lot of things today. [1] http://www.jwz.org/doc/worse-is-better.html http://www.jwz.org/doc/worse-is-better.html [2] http://en.wikipedia.org/wiki/PARC_%28company%29#History http://en.wikipedia.org/wiki/PARC_%28company%29#History

zubairq 12y ago

I disagree. I think LightTable was a great success. Personally, the product we made with LightTable positively affects thousands of people here in Scandinavia. What were your expectations from Light Table?