Shared publicly  - 
This is one of the mot interesting concepts for an IDE I've seen in awhile.
12 Apr 2012. Light Table - a new IDE concept. Despite the dramatic shift toward simplification in software interfaces, the world of development tools continues to shrink our workspace with feature aft...
Nick Stott's profile photoMichael Wright's profile photoAlec Story's profile photoJohn Gunderman's profile photo
I especially like the idea of using the function as the smallest unit of code, instead of the file.
Agreed. My only concern with that is when you're writing code you have to at some point determine what file that function goes in so that people not using Light Table don't just see a giant file full of functions :) This seems like a trivially solvable problem though.

It's a very cool project, and I'm excited that alternative styles to editing code are starting to pick up steam. I'm still a huge fan of VIM, but I think there's something that's in between VIM and big IDEs like Eclipse. Plus did I mention how good looking that editor was?
You can probably solve that problem trivially by grouping your functions into files by module.
Yeah, definitely reminded me a bit of code bubbles. The editor is more closely related to some of Bret Victors prototypes however (and if you haven't seen his talk on Inventing on Principle [1], I highly recommend you take an hour and watch it).

I hope this gets popular enough to be usable for myself. Because of the integrated interpretation environment, it'll be expensive to extend it to new languages. That, and I want vim keybindings...

Looks amazing, though!
I think that it would be a good idea for compilers to expose their parser more. That would make applications such as this much easier to implement.
+Alec Story I think that's my eternal problem: I want vim bindings for any given text editor. And even when I get vim bindings, they aren't as good as the real vim bindings.
hey hey, what about those of us who prefer emacs bindings? :P
+John Gunderman How do you propose parsers exposing their compilers more? I mean, it'd be great if we had some kind of universal parsing infrastructure, but many languages want to be self-hosting, which defeats the point.

+Michael Wright Yeah, and it's probably not going to be integrated into vim. It's too bad there isn't some kind of wacky heterogenous programming mode for vim that would let you implement this in something other than C.
I mean exposing in the form of an API that lets you visit nodes in the parse tree. Go has something of this sort, which is super nice. A few other languages do as well, but it just doesn't feel accessible.
Ah, I see. But even so, unless the API is socket-based (which might be needlessly complex), you'd have to ship your editor with huge amounts of code.

And in some languages, you don't know what code you're running until after type checking, which is even more complexity.

I wish it were simpler!
The biggest hack of this kind I've seen is the FlyMake tool for Emacs, which loads your file through the gcc frontend in "check for syntax errors" mode, and then turns that into squiggly underlines. On large projects, this isn't particularly practical.
Add a comment...