10 ms·

Chris Granger on the LightTable architecture

184 points by lemming 12y ago

ticking 12y ago
It's good that LT is finally acknowledged to have failed as "the uber clojure IDE". It's architecture is horrible, and its catering too much to other languages. Once it's dead the space it frees up can be filled again by something that actually works.
- seanmcdirmid 12y ago
  Failed experiments can lead to great results down the road. I'm predicting that LT was probably totally worth it.
  - ticking 12y ago
    LT didn't bring any new inventions, emacs, self, morphic, CL, they've all done some aspect of it 30 years earlier. LT has shown however that you can make a load of money of kickstarter without delivering a product, but people will still throw money at you for building the next big unfinished thing (see their new pet project with a broken architecture called EVE).
    - seanmcdirmid 12y ago
      This is why academia sucks so badly: they think because some features were released in some projects that "there is nothing new under the sun." Bull! There is still a lot to be explored and none of those projects you listed contain much of the live programming story at all (Chris Hancock at MIT did flogo II, which is more relevant than the Lisp and smalltalk projects). To make any progress at all, we just need to stop listening to those who are living in the glory of a past that wasn't so great anyways.
      - lmm 12y ago
        But LT hasn't achieved either half. It's not an innovative research project. And it's not a polished consumer product.
        zubairq 12y ago
        Did any of you guys even use Light Table. I bet you didn't as it did some pretty amazing stuff that no other IDE could touch!
        ticking 12y ago
        Yes, I also dug into its codebase. Have you actually used Self for example?
        zubairq 12y ago
        I guess if you are trying to use Light Table as "the uber clojure IDE" then it was never a goal for Light Table. Intellij Cursive is probably a better editor for that. Light Table's aim was for a form of interactive programming. Anyway, using an editor as an end user is very different to just playing around with its source code, although I applaud that you have done that. I will look into "Self" some more as I don't know enough about it. Do you have some good links on Self to get me started?
        ticking 12y ago
        http://www.selflanguage.org http://www.selflanguage.org You should watch the videos on the introduction page and play a bit with the system, it's interesting to see how much interactivity and liveliness was already achieved in the 80s/90s,
      - ticking 12y ago
        They didn't contain much of the live programming story? https://www.youtube.com/watch?v=Ox5P7QyL774 https://www.youtube.com/watch?v=Ox5P7QyL774 https://www.youtube.com/watch?v=3ka4KY7TMTU https://www.youtube.com/watch?v=3ka4KY7TMTU
    - nhangen 12y ago
      Not sure why this is getting downvoted. Perhaps the truth here is harsh, but it's the truth nonetheless. Perhaps not the whole truth, but at least part of it.
      - coldtea 12y ago
        The part about LT overpromising and underdelivering is true. The rest is not true, and said with a partisan rudeness to top, mostly like someone wanting to piss over LT and Chris than a genuine criticism. It starts: "It's good that LT is finally acknowledged to have failed as "the uber clojure IDE". It never said it was the "the uber clojure IDE", not even used any words to this effect. It was an experiment in IDEs in general, and in fact the very landing page of the project writes: "When we released our first blog post about Light Table back in April of 2012, it was just a new concept for an IDE. Thanks to the community, our concept was pushed to become a reality." Moreover the parent continues: >It's architecture is horrible, and its catering too much to other languages. "Catering too much to other languages"? What does that even mean? Did anybody signed to the parent that it would only be for his favorite language (the "uber clojure IDE" he dreamt?)? It was due to huge community demand that LT promised to support Javascript and Python too. >Once it's dead the space it frees up can be filled again by something that actually works. Nobody stopped the parent or anyone else from using something existing "that actually works" or creating something even better. In fact the project is already usable for a lot of us for daily exploratory coding, not to mention having put some nice ideas to the forefront of future IDE work, including having concretely inspired the Swift playground features (as the Swift designer admitted). It's just the usual old HN piss contest. As if it was all a scheme to make $300K off of kickstarter. I don't know where the parent lives, but for someone like Chris and with Chris' past, that's money you can make in half a year in the US software business -- not having to slave to create a whole new IDE, or hire other people to give them a chunk of the money off...
        smrtinsert 12y ago
        well stated.
        ticking 12y ago
    - tormeh 12y ago
      Combining old features is a new feature.
kristianp 12y ago
"Even with a principled approach, I think I managed to build a system that only I can really get around in." Interesting. Power vs difficulty in debugging. " BOT filled its goals of an architecture that is infinitely extensible and runtime modifiable, but that degree of power came at a cost - despite its simplicity the resulting program is very hard to follow. I've recently come to understand that this is because mixins are fundamentally an anti-pattern and BOT is basically dynamic mixins." BOT is described here: http://www.chris-granger.com/2013/01/24/the-ide-as-data/ http://www.chris-granger.com/2013/01/24/the-ide-as-data/
- seanmcdirmid 12y ago
  One developer writing code by themselves for 2 years will almost always produce a system that they can only understand. I did it with the Scala IDE back in 2006/2007, unfortunately, complete with mixin layer overuse.
- metasean 12y ago
  >Interesting. Power vs difficulty in debugging. Reminds me of this statement by Brian W. Kernighan, "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."
  - seanmcdirmid 12y ago
    This is all too harsh though. When you are doing something new, you aren't that sure what kind of extensibility and modularity you need internally, so you wind up over engineering and over architecting. Imagine you wanted to build a bridge without no one ever doing that before. It is an open problem, the resulting bridge might work, but it won't be pretty and probably used way too many materials, meaning it will be difficult to repair and upgrade. But your next bridge will be better, benefiting from the experience of the previous one, and you might be able to even do some design up front for the third one that actually sticks. Tl;dr get started on your first bridge early.
    - 12y ago
AceJohnny2 12y ago
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...
lemming 12y ago
Even though I make a competitor (Cursive) I'm still sad to see LightTable languishing. It had some interesting ideas, even if they never came to fruition. But the point about the code being incomprehensible is definitely true. I've tried a couple of times to follow a simple flow through the code to see how something worked, and it's difficult-to-impossible. It would be great if the community could pick it up, but this email makes that look very difficult. Interesting comments about using alternative languages, too. However I suspect that in the same way that ClojureScript wasn't really that much of a benefit compared to the architecture, it probably isn't the main impediment to outside contribution either.
Permit 12y ago
FWIW a friend and myself were very inspired by Light Table, Chris Granger and Brett Victor. We've been working on applying these ideas to C#. We've built http://codeconnect.io http://codeconnect.io for a function-by-function view of C# code. Now we're currently finishing up live coding: http://imgur.com/2QE5Bkw.gif http://imgur.com/2QE5Bkw.gif People have expressed sadness about the current state of Light Table. I think Chris did a phenomenal job demonstrating some of these ideas and exposing them to the developer community at large.
- seanmcdirmid 12y ago
  Interesting. What's your plan for dealing with state?
  - Permit 12y ago
    Run their code via unit tests. We've assumed if you've written a unit test for a function, the state will be taken care of.
    - seanmcdirmid 12y ago
      Ah, this is similar to what Gilad Bracha is doing in his live programming work for NewSpeak.
      - Permit 12y ago
        That sounds really interesting, can you share any articles or videos about his work on live programming?
        seanmcdirmid 12y ago
        It was some things he demonstrated at WGLD meetings; here is a blog post with the same title as his talk: http://gbracha.blogspot.com/2012/11/debug-mode-is-only-mode.html http://gbracha.blogspot.com/2012/11/debug-mode-is-only-mode.... And later: http://gbracha.blogspot.com/2013/04/making-methods-live.html http://gbracha.blogspot.com/2013/04/making-methods-live.html He is giving a keynote at ECOOP on the topic in June.
deleted 12y ago
[deleted]
nahuel0x 12y ago
I think the way forward is to add the Light Table main features to the Atom Editor as plugin. It has a bigger community (and facebook $$$ behind) and is a very good candidate for "the next Emacs".
justinmk 12y ago
Chris's post on the LT mailing list 1 year ago[1]: Depending on how things play out, it might make sense to try and merge [with atom.io]. [...] The main value of LT isn't about being a better standard editor, it's taking that editor and making it do things that standard ones can't do. [...] From the outset, our goal has been to make programming better and I've honestly come to the conclusion that LT on its own can't do that. [...] The truth is that I think we can do orders of magnitude better and I have some evidence of that already, but it's going to take more than a new tool. It's going to take a different way of thinking about the problem. That is what I think will end up being the ultimate legacy of Light Table - a version of programming that is meaningfully designed for humans. You've heard us mention "Aurora" a number of times now and I think that's the best description for this crowd of what we're out to accomplish; programming designed for humans. This often comes as a surprise to people, but I honestly don't like to program very much - it just happens to be the only way to create the things I want. It should have been clear by then that the LT author had lost interest. That's when I decided[2] to concentrate on making Vim/Emacs better instead of trying to find (or make) a "perfect" foundation upon which the already existing Vim/Emacs plugins could be rebuilt. There's a reason why Sublime re-uses Textmate themes; and Java is useful (tons of libraries) even though it's boring; and Linux is widespread even though it's inelegant compared to Hurd or whatever: there's a giant mountain of existing, working boring tools already built--tools that you will not want to rewrite after your perfect platform is done. Neovim popped up around that time and for the above reasons it made sense to me. If the foundation is imperfect, do the dirty work to make the foundation less-imperfect. With 10% of the work[3], I think Neovim can enable 90% of the goodies I (we?) wanted in LT (and 100% of the visual appeal). [1] https://groups.google.com/d/msg/light-table-discussion/YTuCHoOym1E/PNSnlYsM1i8J https://groups.google.com/d/msg/light-table-discussion/YTuCH... [2] http://www.reddit.com/r/vim/comments/1ztxgd/why_atom_cant_replace_vim/cfx0kyq http://www.reddit.com/r/vim/comments/1ztxgd/why_atom_cant_re... [3] Remember: don't discount the work of writing plugins.
- scott_s 12y ago
  Based on what he said just now, I do not think it is accurate to say he has "lost interest": In my particular case I'm basically working all but a couple of my waking hours, weekends and all - so relying on me won't work, though I'm here to help answer questions and point people in the right direction as much as I can. That is, he's still working on it all the time, which I take to mean he is still interested in it. Rather, he is giving a frank assessment for why LT has not gotten more traction as an open source project.
moron4hire 12y ago
This is what happens when you create a project. 99 times out of 100, you make something that isn't what you'd hoped it would be. So what? The key is to recognize that failure is not the lack of certain project XYZ being at certain state QPO. Most people will not have the lifespan long enough to see a project they work on go perfectly. This notion of failure, that it is the lack of some future state of being showered in dollars/accolades/kisses-and-hugs, means that every project, ever, is a failure. Failure is giving up. Failure is letting that experience, where you didn't magically achieve your hopes and dreams, and letting it drive you back into the warm bosom of punching a clock at a gigantocorp or cargocultup. Instead of relying on yourself for your livelihood, your purpose, your mark on society[0], you go somewhere safe where you get told what to do and you just bide your time, collecting a paycheck, until you escape that particular bouncing dead cat on to the next one. Success is not giving up. It's taking your lumps, "oooh, I made a shitty thing, woe is me, I'm not as smart as I thought I was" [1] and telling yourself that it doesn't matter, that you'll try again. Chris, if you're reading here: start another IDE project. Use what you've learned. If you really, actually cared about the things you said, don't let your perceived failure with LightTable[2] prevent you from starting something new. It won't be the same story all over again, because you aren't the same person now as when you started LT in the first place. In the end, no project is a failure, unless we let it have no impact on us, unless we learn nothing from it. Don't squander the lessons learned through bad projects by choosing to not continue onto new ones. [0] And don't for a second think you don't owe society a mark or two [1] Check my username [2] I wish my projects have failed so well as LightTable
- buovjaga 12y ago
  Did you see this about what Chris it up to currently: http://techcrunch.com/2014/10/01/eve-raises-2-3m-to-rethink-programming/ http://techcrunch.com/2014/10/01/eve-raises-2-3m-to-rethink-...
Rapzid 12y ago
Wow.. Am I the only one that actually likes using LT? I don't always write Clojure but when I do, I use LT. I dream of creating ClojureScript single page apps with OM in LT nearly every day.. :) I find the insta-RPL to be absolutely fantastic. I wish F# had insta-repl instead of just repl. I wish everything had insta-repl.
- zubairq 12y ago
  I love Light Table too. The inst repl is a killer feature!
qznc 12y ago
> architecture ends up being far more important than the specific language used Good insight.
zubairq 12y ago
I am quite amazed that so many people think that Light Table failed. Far from it, Light Table changed a whole industry: 1) Chris Lattner, the creator of Swift publicy acknowledged that Swift, used to develop all future IOS and Apple Watch apps is inspired by Light Table: http://nondot.org/sabre/ http://nondot.org/sabre/ 2) It inspired a whole generation of people and tools to move away from heavily typed and compiled languages like Scala to dynamic and repl based languages
- bad_user 12y ago
  That's interesting - so who moved from static to dynamic languages because of LightTable? Actually I'm not seeing any movement from static typing to dynamic typing in recent years, so wondering what you're talking about.
  - deleted 12y ago
    [deleted]
  - zubairq 12y ago
    LinkedIn for one: http://www.quora.com/Is-LinkedIn-getting-rid-of-Scala http://www.quora.com/Is-LinkedIn-getting-rid-of-Scala
    - frowaway001 12y ago
      Maybe you start reading your links?
    - eeperson 12y ago
      That doesn't really seem definitive. That page also includes a link to this[1] page, from a month ago, stating that LinkedIn is moving part of its stack to Scala. [1] - https://engineering.linkedin.com/frontend/new-technologies-new-linkedin-home-page https://engineering.linkedin.com/frontend/new-technologies-n...
      - zubairq 12y ago
patal 12y ago
Is this article restricted material? If not, could somebody please make it accessible in some way? Apparently, there's a google account necessary in order to read it... Thanks!
grandalf 12y ago
He makes a very good point about understandability in system design: Mixins hide control flow and add layers of indirection that make it hard to even see what the possible paths through the program are. Instead of a clear and obvious flow of data you have to hunt around to try and piece together the graph of possible events. My hope was that pushing as much of that into data as I could think to at the time would make it observable, but realistically a graph with more than about 20 edges is very hard to make much sense of and an IDE certainly has more than 20 edges.
_pmf_ 12y ago
> The industry has also changed pretty drastically since I started LT. During its creation CPS gained traction, React was created, the Clojure ecosystem basically rewrote itself... The software industry has not changed drastically for several decades. To call the introduction of a system (React) that is basically a workaround for a problem that should does not exist at all in a sane environment (DOM) a drastic change for the software industry is a bit much.

184 points by lemming 12y ago

It's good that LT is finally acknowledged to have failed as "the uber clojure IDE". It's architecture is horrible, and its catering too much to other languages. Once it's dead the space it frees up can be filled again by something that actually works.

seanmcdirmid 12y ago
Failed experiments can lead to great results down the road. I'm predicting that LT was probably totally worth it.
- ticking 12y ago
  LT didn't bring any new inventions, emacs, self, morphic, CL, they've all done some aspect of it 30 years earlier. LT has shown however that you can make a load of money of kickstarter without delivering a product, but people will still throw money at you for building the next big unfinished thing (see their new pet project with a broken architecture called EVE).
  - seanmcdirmid 12y ago
    This is why academia sucks so badly: they think because some features were released in some projects that "there is nothing new under the sun." Bull! There is still a lot to be explored and none of those projects you listed contain much of the live programming story at all (Chris Hancock at MIT did flogo II, which is more relevant than the Lisp and smalltalk projects). To make any progress at all, we just need to stop listening to those who are living in the glory of a past that wasn't so great anyways.
    - lmm 12y ago
      But LT hasn't achieved either half. It's not an innovative research project. And it's not a polished consumer product.
      - zubairq 12y ago
        Did any of you guys even use Light Table. I bet you didn't as it did some pretty amazing stuff that no other IDE could touch!
        ticking 12y ago
        Yes, I also dug into its codebase. Have you actually used Self for example?
        zubairq 12y ago
        I guess if you are trying to use Light Table as "the uber clojure IDE" then it was never a goal for Light Table. Intellij Cursive is probably a better editor for that. Light Table's aim was for a form of interactive programming. Anyway, using an editor as an end user is very different to just playing around with its source code, although I applaud that you have done that. I will look into "Self" some more as I don't know enough about it. Do you have some good links on Self to get me started?
        ticking 12y ago
        http://www.selflanguage.org http://www.selflanguage.org You should watch the videos on the introduction page and play a bit with the system, it's interesting to see how much interactivity and liveliness was already achieved in the 80s/90s,
    - ticking 12y ago
      They didn't contain much of the live programming story? https://www.youtube.com/watch?v=Ox5P7QyL774 https://www.youtube.com/watch?v=Ox5P7QyL774 https://www.youtube.com/watch?v=3ka4KY7TMTU https://www.youtube.com/watch?v=3ka4KY7TMTU
  - nhangen 12y ago
    Not sure why this is getting downvoted. Perhaps the truth here is harsh, but it's the truth nonetheless. Perhaps not the whole truth, but at least part of it.
    - coldtea 12y ago
      The part about LT overpromising and underdelivering is true. The rest is not true, and said with a partisan rudeness to top, mostly like someone wanting to piss over LT and Chris than a genuine criticism. It starts: "It's good that LT is finally acknowledged to have failed as "the uber clojure IDE". It never said it was the "the uber clojure IDE", not even used any words to this effect. It was an experiment in IDEs in general, and in fact the very landing page of the project writes: "When we released our first blog post about Light Table back in April of 2012, it was just a new concept for an IDE. Thanks to the community, our concept was pushed to become a reality." Moreover the parent continues: >It's architecture is horrible, and its catering too much to other languages. "Catering too much to other languages"? What does that even mean? Did anybody signed to the parent that it would only be for his favorite language (the "uber clojure IDE" he dreamt?)? It was due to huge community demand that LT promised to support Javascript and Python too. >Once it's dead the space it frees up can be filled again by something that actually works. Nobody stopped the parent or anyone else from using something existing "that actually works" or creating something even better. In fact the project is already usable for a lot of us for daily exploratory coding, not to mention having put some nice ideas to the forefront of future IDE work, including having concretely inspired the Swift playground features (as the Swift designer admitted). It's just the usual old HN piss contest. As if it was all a scheme to make $300K off of kickstarter. I don't know where the parent lives, but for someone like Chris and with Chris' past, that's money you can make in half a year in the US software business -- not having to slave to create a whole new IDE, or hire other people to give them a chunk of the money off...
      - smrtinsert 12y ago
        well stated.
      - ticking 12y ago
  - tormeh 12y ago
    Combining old features is a new feature.

kristianp 12y ago

"Even with a principled approach, I think I managed to build a system that only I can really get around in." Interesting. Power vs difficulty in debugging. " BOT filled its goals of an architecture that is infinitely extensible and runtime modifiable, but that degree of power came at a cost - despite its simplicity the resulting program is very hard to follow. I've recently come to understand that this is because mixins are fundamentally an anti-pattern and BOT is basically dynamic mixins." BOT is described here: http://www.chris-granger.com/2013/01/24/the-ide-as-data/ http://www.chris-granger.com/2013/01/24/the-ide-as-data/

seanmcdirmid 12y ago
One developer writing code by themselves for 2 years will almost always produce a system that they can only understand. I did it with the Scala IDE back in 2006/2007, unfortunately, complete with mixin layer overuse.
metasean 12y ago
>Interesting. Power vs difficulty in debugging. Reminds me of this statement by Brian W. Kernighan, "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."
- seanmcdirmid 12y ago
  This is all too harsh though. When you are doing something new, you aren't that sure what kind of extensibility and modularity you need internally, so you wind up over engineering and over architecting. Imagine you wanted to build a bridge without no one ever doing that before. It is an open problem, the resulting bridge might work, but it won't be pretty and probably used way too many materials, meaning it will be difficult to repair and upgrade. But your next bridge will be better, benefiting from the experience of the previous one, and you might be able to even do some design up front for the third one that actually sticks. Tl;dr get started on your first bridge early.
  - 12y ago

AceJohnny2 12y ago

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...

lemming 12y ago

Even though I make a competitor (Cursive) I'm still sad to see LightTable languishing. It had some interesting ideas, even if they never came to fruition. But the point about the code being incomprehensible is definitely true. I've tried a couple of times to follow a simple flow through the code to see how something worked, and it's difficult-to-impossible. It would be great if the community could pick it up, but this email makes that look very difficult. Interesting comments about using alternative languages, too. However I suspect that in the same way that ClojureScript wasn't really that much of a benefit compared to the architecture, it probably isn't the main impediment to outside contribution either.

Permit 12y ago

FWIW a friend and myself were very inspired by Light Table, Chris Granger and Brett Victor. We've been working on applying these ideas to C#. We've built http://codeconnect.io http://codeconnect.io for a function-by-function view of C# code. Now we're currently finishing up live coding: http://imgur.com/2QE5Bkw.gif http://imgur.com/2QE5Bkw.gif People have expressed sadness about the current state of Light Table. I think Chris did a phenomenal job demonstrating some of these ideas and exposing them to the developer community at large.

seanmcdirmid 12y ago
Interesting. What's your plan for dealing with state?
- Permit 12y ago
  Run their code via unit tests. We've assumed if you've written a unit test for a function, the state will be taken care of.
  - seanmcdirmid 12y ago
    Ah, this is similar to what Gilad Bracha is doing in his live programming work for NewSpeak.
    - Permit 12y ago
      That sounds really interesting, can you share any articles or videos about his work on live programming?
      - seanmcdirmid 12y ago
        It was some things he demonstrated at WGLD meetings; here is a blog post with the same title as his talk: http://gbracha.blogspot.com/2012/11/debug-mode-is-only-mode.html http://gbracha.blogspot.com/2012/11/debug-mode-is-only-mode.... And later: http://gbracha.blogspot.com/2013/04/making-methods-live.html http://gbracha.blogspot.com/2013/04/making-methods-live.html He is giving a keynote at ECOOP on the topic in June.

deleted 12y ago

[deleted]

nahuel0x 12y ago

I think the way forward is to add the Light Table main features to the Atom Editor as plugin. It has a bigger community (and facebook $$$ behind) and is a very good candidate for "the next Emacs".

justinmk 12y ago

Chris's post on the LT mailing list 1 year ago[1]: Depending on how things play out, it might make sense to try and merge [with atom.io]. [...] The main value of LT isn't about being a better standard editor, it's taking that editor and making it do things that standard ones can't do. [...] From the outset, our goal has been to make programming better and I've honestly come to the conclusion that LT on its own can't do that. [...] The truth is that I think we can do orders of magnitude better and I have some evidence of that already, but it's going to take more than a new tool. It's going to take a different way of thinking about the problem. That is what I think will end up being the ultimate legacy of Light Table - a version of programming that is meaningfully designed for humans. You've heard us mention "Aurora" a number of times now and I think that's the best description for this crowd of what we're out to accomplish; programming designed for humans. This often comes as a surprise to people, but I honestly don't like to program very much - it just happens to be the only way to create the things I want. It should have been clear by then that the LT author had lost interest. That's when I decided[2] to concentrate on making Vim/Emacs better instead of trying to find (or make) a "perfect" foundation upon which the already existing Vim/Emacs plugins could be rebuilt. There's a reason why Sublime re-uses Textmate themes; and Java is useful (tons of libraries) even though it's boring; and Linux is widespread even though it's inelegant compared to Hurd or whatever: there's a giant mountain of existing, working boring tools already built--tools that you will not want to rewrite after your perfect platform is done. Neovim popped up around that time and for the above reasons it made sense to me. If the foundation is imperfect, do the dirty work to make the foundation less-imperfect. With 10% of the work[3], I think Neovim can enable 90% of the goodies I (we?) wanted in LT (and 100% of the visual appeal). [1] https://groups.google.com/d/msg/light-table-discussion/YTuCHoOym1E/PNSnlYsM1i8J https://groups.google.com/d/msg/light-table-discussion/YTuCH... [2] http://www.reddit.com/r/vim/comments/1ztxgd/why_atom_cant_replace_vim/cfx0kyq http://www.reddit.com/r/vim/comments/1ztxgd/why_atom_cant_re... [3] Remember: don't discount the work of writing plugins.

scott_s 12y ago
Based on what he said just now, I do not think it is accurate to say he has "lost interest": In my particular case I'm basically working all but a couple of my waking hours, weekends and all - so relying on me won't work, though I'm here to help answer questions and point people in the right direction as much as I can. That is, he's still working on it all the time, which I take to mean he is still interested in it. Rather, he is giving a frank assessment for why LT has not gotten more traction as an open source project.

moron4hire 12y ago

This is what happens when you create a project. 99 times out of 100, you make something that isn't what you'd hoped it would be. So what? The key is to recognize that failure is not the lack of certain project XYZ being at certain state QPO. Most people will not have the lifespan long enough to see a project they work on go perfectly. This notion of failure, that it is the lack of some future state of being showered in dollars/accolades/kisses-and-hugs, means that every project, ever, is a failure. Failure is giving up. Failure is letting that experience, where you didn't magically achieve your hopes and dreams, and letting it drive you back into the warm bosom of punching a clock at a gigantocorp or cargocultup. Instead of relying on yourself for your livelihood, your purpose, your mark on society[0], you go somewhere safe where you get told what to do and you just bide your time, collecting a paycheck, until you escape that particular bouncing dead cat on to the next one. Success is not giving up. It's taking your lumps, "oooh, I made a shitty thing, woe is me, I'm not as smart as I thought I was" [1] and telling yourself that it doesn't matter, that you'll try again. Chris, if you're reading here: start another IDE project. Use what you've learned. If you really, actually cared about the things you said, don't let your perceived failure with LightTable[2] prevent you from starting something new. It won't be the same story all over again, because you aren't the same person now as when you started LT in the first place. In the end, no project is a failure, unless we let it have no impact on us, unless we learn nothing from it. Don't squander the lessons learned through bad projects by choosing to not continue onto new ones. [0] And don't for a second think you don't owe society a mark or two [1] Check my username [2] I wish my projects have failed so well as LightTable

buovjaga 12y ago
Did you see this about what Chris it up to currently: http://techcrunch.com/2014/10/01/eve-raises-2-3m-to-rethink-programming/ http://techcrunch.com/2014/10/01/eve-raises-2-3m-to-rethink-...

Rapzid 12y ago

Wow.. Am I the only one that actually likes using LT? I don't always write Clojure but when I do, I use LT. I dream of creating ClojureScript single page apps with OM in LT nearly every day.. :) I find the insta-RPL to be absolutely fantastic. I wish F# had insta-repl instead of just repl. I wish everything had insta-repl.

zubairq 12y ago
I love Light Table too. The inst repl is a killer feature!

qznc 12y ago

> architecture ends up being far more important than the specific language used Good insight.

zubairq 12y ago

I am quite amazed that so many people think that Light Table failed. Far from it, Light Table changed a whole industry: 1) Chris Lattner, the creator of Swift publicy acknowledged that Swift, used to develop all future IOS and Apple Watch apps is inspired by Light Table: http://nondot.org/sabre/ http://nondot.org/sabre/ 2) It inspired a whole generation of people and tools to move away from heavily typed and compiled languages like Scala to dynamic and repl based languages

bad_user 12y ago
That's interesting - so who moved from static to dynamic languages because of LightTable? Actually I'm not seeing any movement from static typing to dynamic typing in recent years, so wondering what you're talking about.
- deleted 12y ago
  [deleted]
- zubairq 12y ago
  LinkedIn for one: http://www.quora.com/Is-LinkedIn-getting-rid-of-Scala http://www.quora.com/Is-LinkedIn-getting-rid-of-Scala
  - frowaway001 12y ago
    Maybe you start reading your links?
  - eeperson 12y ago
    That doesn't really seem definitive. That page also includes a link to this[1] page, from a month ago, stating that LinkedIn is moving part of its stack to Scala. [1] - https://engineering.linkedin.com/frontend/new-technologies-new-linkedin-home-page https://engineering.linkedin.com/frontend/new-technologies-n...
    - zubairq 12y ago

patal 12y ago

Is this article restricted material? If not, could somebody please make it accessible in some way? Apparently, there's a google account necessary in order to read it... Thanks!

grandalf 12y ago

He makes a very good point about understandability in system design: Mixins hide control flow and add layers of indirection that make it hard to even see what the possible paths through the program are. Instead of a clear and obvious flow of data you have to hunt around to try and piece together the graph of possible events. My hope was that pushing as much of that into data as I could think to at the time would make it observable, but realistically a graph with more than about 20 edges is very hard to make much sense of and an IDE certainly has more than 20 edges.

_pmf_ 12y ago

> The industry has also changed pretty drastically since I started LT. During its creation CPS gained traction, React was created, the Clojure ecosystem basically rewrote itself... The software industry has not changed drastically for several decades. To call the introduction of a system (React) that is basically a workaround for a problem that should does not exist at all in a sane environment (DOM) a drastic change for the software industry is a bit much.