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 I just checked out your paper about live coding (with pacman video). Did you see http://worrydream.com/LearnableProgramming/ ? Do you guys consider collaborating?
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)
> 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.
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.
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.
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.
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.
A lot of tech comes and goes because either (a) the time isn't right or (b) it isn't that good and gets superseded by something else.
Those guys from the 60s and 70s were smart, but we are smart also! It is time for us to stop living in the past and start moving to the future. Full on live programming hasn't been accomplished yet, the best achieved are simple REPLs, hot code swapping in Erlang/Smalltalk (which does nothing with state), and...direct manipulation (you can just update your objects directly, screw any code).
Some things just haven't been accomplished yet, and to claim they have been is just seriously dishonest and damaging since it dissuades people from trying. (I'm not referring to RPG here, I bet he is as frustrated as I am).
So ignore the haters and just get things done, I guess.
> the best achieved are simple REPLs, hot code swapping in Erlang/Smalltalk (which does nothing with state), and...direct manipulation (you can just update your objects directly, screw any code)
I think that sort of supports the point of the GP. Lisp had all the above and more (e.g. a proper REPL, live recompiling of everything in your image) since almost forever and yet not many people know about that. There's a lot of knowledge that was just forgotten by the fashion-industry IT is.
So I don't think we should stop trying - but it's really worth to go through the work done in 60s and 70s, because we could use it.
It's just not useful, they needed to go farther and wound up with a PX that some liked, but most didn't feel was worth it. Take the REPL for example, you are stuck in a linear command driven level of interaction if state is involved (and if state isn't, it is only useful as a fancy calculator). Take fix and continue in smaltalk - you can change the code, but you can't really fix the state (I.e. By time traveling), leaving your program in a seriously fragile state. And take morphic: where you can change the state (by directly manipulating objects) but not the code, so if you change something driven by code, your changes are completely ephemeral.
Each experience is serious lacking, and there are good reasons they haven't taken over the world. Chris Hancock does a better job than me in describing this, which is why I keep bringing up his dissertation:
https://llk.media.mit.edu/papers/ch-phd.pdf
>>So ignore the haters and just get things done, I guess.
Not sure if you're implying I'm a hater here or not, but being charitable I'll assume not.
>> It is time for us to stop living in the past and start moving to the future.
The old saw about those who don't know their history and repetition springs to mind. Edit: not imply you don't know the history, as you clearly do, but many don't.
I was referring to the sentiment in general, with specific people in mind that I dare not say out loud.
I know my PL history pretty well, from Sutherland, McCarthy, Kay, Steele, Papert, Lieberman, not to mention all the VPLs, constraint programming systems, and so on. Ya, there is a lot of work, but that is no excuse to stagnate.
Edit: I'm not sure it is useful to shame people for not knowing their history. There isn't much wrong with reinvention, and who knows, it might be better than what was invented before. Our legacy sometimes does us more harm than good.
Yep, there's nothing intrinsically magical about that time that made language designers better than now. In fact, 30-40 years later we even have more collective experience under our belts!
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.
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.
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).
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.
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.
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.
I consider myself an emacs user but if you counted invocations I probably invoke vi significantly more frequently than emacs (I'm not going to wait for emacs to start to edit some little thing in /etc).
There are people who can program very productively in vi (I'm not one of them), so they can use vi for long and short tasks. I can program very productively in emacs but I don't consider it the right tool for quick one-off edits of something. Also vi comes with pretty much every UNIX-like base system I know of, while emacs is often off in a port system somewhere.
I too fit that description for some time. Vim is what I would use when starting an editor to do something to a file, and emacs when wanting to live in the editor and reach out to external tools like a repl for some extended time.
Using emacs in daemon mode with launchctl on osx and then making a shell alias and an automator launcher for emacsclient that just connects makes starting the new client so fast that I can use emacs for the quick jobs, too. The only thing I have to do now is get used to the emacs command equivalents for the quick edit jobs. For example, in vim I can open a file to a specific line, delete that line and then the first 5 characters of the next 50 lines, and exit the editor in just a few keystrokes, while in emacs I'd still be playing with C-h a and googling. The things I've spent the most time in emacs doing, common lisp, clojure, latex, and so on, have a very different set of common operations than the common sysadmin tasks I used vim for.
I'm primarily a windows user, but I learnt vim so that I could more easily edit files on linux servers, since it's pretty much guaranteed to be there on any box I'm on.
I don't particularly enjoy programming in vi, but I tend to do it quite a bit when making small changes to our codebase on my dev box in the sky and I don't want to deal with the overhead of starting an IDE locally.
It also stopped people from laughing at me when I ran nano. :p
Definitely not close to parity. If you search for "[programming language] emacs" and "[programming language] vim", you'll find more results for vim -- often many more -- for every language except "Lisp." (But even Lisp variants like Racket have more results for Vim.)
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?
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-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.
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.
Sorry to chime being negative, but it takes you approximately zero because it uses the same paradigm as software you learnt years ago. It probably didn't take you zero time to learn how to open a file, what a files was, what a search-replace was, how it worked, etc, the first time you were confronted with it
Well, the keybindings on emacs predate most other keybindings. I don't use it very often, but Cmd-F is forward-word, to move forward a word (heh.) For keyboards without arrow keys it is very handy (my oldest laptop didn't have them.) Cmd-R I have never used its binding (so I could rebind it, but what binding would you like to have in it? "Reload"?
From my angle, I've been learning/using the CUA-type keyboard shortcuts since I was about 8 years old - so that's 20 years now, and 16 or so before I wrote a line of code.
The question is not 'how quickly can I learn open/save/etc in vim/Emacs?', or even 'how quickly can I learn open/save/etc and remember it next time I open vim/Emacs?' but 'how quickly will I be more productive in either of them than something that does use all the shortcuts I've been using for two decades and are basically wired into my unconscious as deep as the need for oxygen, food and sex?'
On that scale, I think a few weeks is the most generous estimate possible. I understand why people love vim and Emacs, but they often underestimate how steep the learning curve is if you're very, very used to doing the same things slightly differently.
Hours? It's more like about one minute --- that's how long it takes to do lesson one of vimtutor, which tells you how to save and quit, move the cursor, and insert and delete text. Going all the way to the end of vimtutor would probably take about 15 to 20 minutes, and assuming you remembered it all would make you pretty effective (I've been using vim for years and there's basic stuff in there I've never used; skimming it just now I kept going 'huh, I did not know that').
I will admit that the vi learning curve can be stupidly steep in places, but right down at the novice end it's not bad at all.
What prevents you from programming in Emacs out of the box? It has a superset of Notepad functionality straight away, and more complex functions are easily learned through built-in help.
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.)
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!)
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.
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.
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?
"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."
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."
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.
> 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."
A corollary is that if you are writing code with minimum repetition, you are effectively a compression algorithm, not a programmer.
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.
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
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.
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).
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.
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:
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
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.
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.
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.
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.
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".
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.
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).
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.
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?
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,
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.
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...
>"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.
This is what broke it's back though. By trying to go with all languages at once they failed to focus on getting one right first. They should have added new ones later on.
>Nobody stopped the parent or anyone else from using something existing "that actually works" or creating something even better.
I've heard it many times over the years in the clojure world, "I'd start on an editor, but it looks like LT is going to be exactly what I want so I'll just wait." Only after its failure was apparent things like Gorilla-Repl popped up.
> including having concretely inspired the Swift playground features (as the Swift designer admitted).
I'd like a source for that. LT is directly inspired by the work of Bred Victor who _worked for apple_ and Swift has at least one of the Factor devs, which is a highly dynamic language with a live coding environment.
> As if it was all a scheme to make $300K off of kickstarter.
He made a lot more than that on Kickstarter, and has some Venture capital as well iirc.
Chris has a history of half finished unmaintained projects, so especially with his past I'd be suspicious.
Eve is the same, it promises to make programming mainstream but storing your UI in a Datalog DB is a huge mess. DL is great, but the stuff he does with it is just horrid.
> 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.
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...
We've built 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
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.