
Chris Granger on the LightTable architecture - lemming
https://groups.google.com/forum/#!msg/light-table-discussion/2csnnNA1pfo/693EWDJVhuwJ
======
Permit
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
Interesting. What's your plan for dealing with state?

~~~
amadeusw
seanmcdirmid I just checked out your paper about live coding (with pacman
video). Did you see
[http://worrydream.com/LearnableProgramming/](http://worrydream.com/LearnableProgramming/)
? Do you guys consider collaborating?

~~~
seanmcdirmid
I saw that in 2012 (I started my own research in 2007). At the time...I sent
an email to Bret Victor, but he never replied (I hear he is busy).

------
AceJohnny2
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
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
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=ce5584...](http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=ce5584125c44a1a2fbb46e810459c50b227a95e2)

~~~
kenko
Does vim really have an order of magnitude more users than emacs? Is emacs
really lacking in mindshare? I have no real reason to doubt those claims but I
find them kind of mind-boggling. I'd have guessed they were close to parity
(for the first).

~~~
AceJohnny2
And then some.

I can't immediately find the survey that struck me, but here's a Quora answer
[1] that cites O'Reilley selling twice as many Vim books than Emacs, the
Debian PopCon results [2] that are rather striking (but Debian PopCon has
quite the preselection bias, and the data may not cover all sub-packages
properly), and Ubuntu's results [3] are a bit harder to parse but also
striking, with vim-common at 2714181 / 25488 installs / "votes" (regular
uses), vs emacsen-common (the highest-placed "emacs" package) at 330647 /
1669.

[1] [http://www.quora.com/Are-there-more-Emacs-or-Vim-
users](http://www.quora.com/Are-there-more-Emacs-or-Vim-users) [2]
[https://qa.debian.org/popcon-
graph.php?packages=vim%2C+emacs...](https://qa.debian.org/popcon-
graph.php?packages=vim%2C+emacs&show_vote=on&want_percent=on&want_legend=on&from_date=2010-01-01&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1)
[3] [http://popcon.ubuntu.com/by_inst](http://popcon.ubuntu.com/by_inst)

~~~
bandrami
Well, I'm an emacs guy, and I've bought a vi book (O'Reilley's in fact) and
not an emacs book, because I needed a book to figure out how to use vi and I
didn't with emacs. Just throwing that out there.

~~~
RBerenguel
Same here. I got _Practical Vim_ and then moved to emacs+evil because I liked
some of the vim concepts but wasn't willing to trade the usefulness of emacs.
Never bought an emacs book either, after all "emacs is the extensible,
customizable, _self-documenting_ , real-time display editor."

C-h (+ k or m) is probably one of the first key chords you are to learn when
starting emacs, from there everything is downhill.

------
kristianp
"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/)

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

~~~
dtjohnnymonkey
Your second bridge might not be better if this turns out to be true:
[http://en.wikipedia.org/wiki/The_Mythical_Man-
Month#The_seco...](http://en.wikipedia.org/wiki/The_Mythical_Man-
Month#The_second-system_effect)

~~~
erikpukinskis
The error is not building the second bridge, it's trying to create a new
design from the ground up rather than improving on the first one.

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

------
moron4hire
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
Did you see this about what Chris it up to currently:
[http://techcrunch.com/2014/10/01/eve-raises-2-3m-to-
rethink-...](http://techcrunch.com/2014/10/01/eve-raises-2-3m-to-rethink-
programming/)

------
Rapzid
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
I love Light Table too. The inst repl is a killer feature!

------
justinmk
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/YTuCH...](https://groups.google.com/d/msg/light-table-
discussion/YTuCHoOym1E/PNSnlYsM1i8J)

[2]
[http://www.reddit.com/r/vim/comments/1ztxgd/why_atom_cant_re...](http://www.reddit.com/r/vim/comments/1ztxgd/why_atom_cant_replace_vim/cfx0kyq)

[3] Remember: don't discount the work of writing plugins.

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

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

~~~
zubairq
LinkedIn for one:

[http://www.quora.com/Is-LinkedIn-getting-rid-of-
Scala](http://www.quora.com/Is-LinkedIn-getting-rid-of-Scala)

~~~
eeperson
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-n...](https://engineering.linkedin.com/frontend/new-technologies-
new-linkedin-home-page)

~~~
zubairq
Well, in the conclusion they do seem to indicate that Scala use is being re-
assessed with Java:

We built the new version of the home page using Scala because the language
adapted itself better to asynchronous programming. With the incorporation of
lambda functions in Java 8, it’s possible we’ll be utilizing Java more.

We will have to wait for more people from linkedin to weigh in on this, but it
does seem to indicate at looking at other solutions than Scala when they can.

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

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

------
ticking
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
Failed experiments can lead to great results down the road. I'm predicting
that LT was probably totally worth it.

~~~
ticking
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
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
But LT hasn't achieved either half. It's not an innovative research project.
And it's not a polished consumer product.

~~~
zubairq
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
Yes, I also dug into its codebase. Have you actually used Self for example?

~~~
zubairq
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
[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,

------
qznc
> architecture ends up being far more important than the specific language
> used

Good insight.

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

------
patal
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!

