Any idea what happened to Chris Granger and the original LightTable/Eve plans? If I am not mistaken they took some VC money right? How did that work out? Would be really interested to hear their story and lessons learned.
Aside from that I was a big LightTable fan and really enjoyed its inline instarepl and other features, so it is definitely great to see that LT is not completely forgotten! Kudos!
I just watched a recording of a talk Chris gave a few months ago. It's a retrospective about building Lighttable/Aurora/Eve. If you were interested in the project(s) I suspect you'll find it interesting.
Thanks, will definitely watch!
LightTable and its instarepl definitely inspired me but as time went I somehow lost track of the project. Inspired by LightTable I even created an instarepl for java and clojure workflows in my pet project (titanoboa.io). So definitely will watch his talks as I might even face similar struggles (albeit in slightly different area/industry).
I think the Light Table guys inspired many people to work on this stuff. As an investor of LightTable/Eve mentioned in the video I was pretty inspired by these guys too. I am now working on my own Cloud editor, at yazz.com
Hi, author of the post here, LightTable is cool, right?
Yeah, I'm trying to get the inline code evaluation and instarepl features working on new updates.
I'm glad you asked it. It's in my future plan. It shouldn't be much hard. I would like to pursue it after of course getting LT stable(and maybe with some funding).
One thing that bothers me about new code editors/IDEs is that their developers really don't do a good enough job researching and deriving inspiration from the editors that already exist.
For example, I have yet to find any modern editor that draws inspiration from the brilliantly designed ideas used in Plan 9's 'sam' and 'acme' editors.
For example structured regexps, 3 button mouse chording, and the 'plumb' feature thats basically a context-aware, smarter version of a unix pipe between two executables.
I mean i can go on and on but another thing that i find absolutely annoying about newer editors is that they all use Webkit as the base of their apps core foundation.
This makes it irritating to consider trying to make changes to the code that I believe would overall improve the editor and make it more useful. (at least as far as im concerned)
I can literally make a list a mile long of things I like in other editors and wish i could see condensed into one ultimate code editor to supplant all code editors that had come before.
Given the amount of time that people spend using editors, you think it would be worth some kind of wide ranging academic review article summarising the history of this area.
Can you recommend a place where I can read about these "plan9 paradigms"? I have an interest in it from a design perspective, but don't quite have time to read the source code.
Look up a YouTube of somebody using it and discussing its features. Basically you could mount computational resources like cpus/ram/network/etc from an external resource server. It also had a graphical equivalent to the Unix pipe between applications.
Acme was different to the 'sam' editor and most other Plan 9 programs up to that point (aside from its predecessor, "help", a similar system that was replaced by acme).
Typing only on the keyboard can be very nice for posture, but I feel that Vim users may think slightly differently if people invented a better keyboard with a pointer device attached.
Then you wouldn't be "taking your hands off the keyboard", you'd just be engaging in a different motion.
Thinkpad external keyboards, both USB and bluetooth - currently typing on one of the former, with one of the latter in my jacket pocket for use with my android tablet.
I feel like your point was missed in the sibling comment. An academic review of editor history would be fascinating, and if it thorough enough might even inspire editor authors to adjust their philosophy.
I guess if it was thorough enough and tried to synthesise some kind of framework for analysing these things there might even be a PhD in it for someone?
It’s been years since I first heard of sam and acme. Perhaps I should try them. Is it possible to run them in MacOS/Linux/Windows? Or perhaps a virtual machine?
BTW, does chording work well with mice where one of the ”three” buttons is the scrool wheel?
Clickable scroll wheel works fine, it is mapped to the same button.
I can't, however, imagine left+middle chord on modern laptops, there are not that many laptops (mostly ThinkPads as far as I can tell) that have three physical mouse buttons.
Those brilliantly designed ideas used in Plan 9's 'sam' and 'acme' editors were taken from how Mesa XDE, Mesa/Cedar and Oberon used to work across the whole OS, not just the text editor.
So a proof that even that point needs better research. :)
Since we are on a Lisp thread, same applies to those that just bother with Emacs, eventually SLIME, withouth ever spending one second with actual Common Lisp IDEs.
One of its strengths was discoverability. Jeff's son Aza iterated on a number of the ideas from the Cat with Enso and Ubiquity but those efforts were not specific to an editor.
There isn't much to it. Windows, for example, implements plumbing as the ability for the user to double-click, in an Explorer window, on, say, a PDF file and have it opened automatically using the default PDF viewer; the command-line equivalent is the 'start' command.
That's true, but with UX, there are sometimes trade-offs to make around discoverability and productivity.
A more discoverable UI may take a greater number of steps to perform. If the application is used rarely or briefly, that's a good trade-off. But if an application will be heavily used by a user who is incentivized to learn the tool, then their total productivity matters more since it amortizes over the lifetime of their use with the tool.
Text editors definitely fall into the "heavily used" bucket, so a good user experience might mean "you gotta read the manual, but once you do you can go 10x faster".
They're basic verbs you use to interact with text; not a full command. E.g instead of executing "format document" from a menu, you select the document with the left mouse button, and then middle click on the word "format". This executes the "format" command on the selected text. Somewhat like running gg=G in vim.
Pratik will be able to talk more definitively about this, but the LightTable project is seeking maintainers. If you'd like to help out, please consider joining Code Shelter[1], this will enable you to join LightTable (after talking with Pratik) and potentially a slew of other projects that need help[2].
Back when i learned about Lighttable years ago i found the instant preview and live editing of running code very cool!
I just realized thats basically what we already do today: i use WebStorm and my webapp hot-reloads any code i type. If i wanted i could even rewind the app state. And when i enable JS debug in IDE its like inception and matrix-view combined, but surprisingly userfriendly still.
The difference is that LightTable gives you inline previews of individual expressions, not just the final result. This is really nice to have for debugging why the final result isn't what you expected.
Maybe starting a flame war, but isn’t this exactly what GNU Emacs & SLIME and for other languages, REPL, LSP/DAP protocols for? While I appreciate his/her effort (I appreciate everything related to developer’s ergonomics), I’m not sure what differentiates lighttable. Maybe I’m missing something? Can anyone explain?
Pretty much the only advantage LT ever had over Emacs was the GUI layer unburdened by decades of development and compatibility with TTYs. In other words, the hope for LT was that it will allow a wide range of scriptable graphical effects. While never explicitly stated, if you read early posts on LT you'll see its feature list is basically 80% Emacs, 10% Smalltalk and 10% eye-candy.
Many (five?) years later, from what I gather, LT has the eye-candy - the rest is perpetually "under construction". It would be hard for it to be anything else, though, as the main developers jumped ship a few years back to work on Eve (which, as a karmic retribution for all my crushed hopes for LT, also tanked and died recently).
Emacs may be less pretty than newer editors, and lots of its APIs are decades old at this point, but it's still the only self-documenting, easily discoverable and extensible editor this side of Pharo and Squeak, which can be used in practice (due to a giant amount of plugins which bring it up to modern standards) for almost any task.
TLDR: LightTable as a powerful editor for programmers is dead - it may be still possible to revive it, but its scope would have to be massively scaled down. It's not going to compete with Emacs & co. anymore, which is a shame, because when it started it had the potential for this.
Oh, if LT is also advertised as a 'scriptable/extensible' editor that can accomplish 80% of GNU Emacs with eye-candy, that is actually a pretty good advantage...
One of the biggest complaint of GNU Emacs (at least for me) is the super bad defaults and esoteric GUI that doesn't mix with other apps because of it's tty-inspired nature...
If LT can become a GUI-first Emacs-competent editor, it will be big! :-)
It's probably quite substantial, since it runs on several platforms, has a GUI on some, etc. Most of the C code is probably used, but the larger part of the Lisp code is modes (tools, games, apps, ...).
The "core" - ie. Elisp code which is preloaded/included in the final 'emacs' executable (as a memory dump of interpreter state) it's less than 80kloc of Elisp. Emacs ships with ~300kloc of "standard" libraries and applications written in Elisp (keep in mind: it's 300kloc of a high-level, fairly expressive, Lispy language - so it translates into a giant pile of features). Further 400-500kloc of Elisp is from add-on packages available via a built-in package manager. Actually, there's more code available, I just counted the plugins I have installed locally.
IIRC Emacs' C code numbers ~300kloc and includes both bindings to low-level, systems and GUI functionality, some parts of standard Elisp library (writen in C for performance), as well as Elisp virtual machine, byte-compiler and so on. No JIT yet, but at least there's threading support (take that JS :P).
Starting from scratch has many advantages, but it doesn't really work with programs and systems large or complex enough. Otherwise we'd be using a fresh OS every five years instead of working on one of the 5-6 OSes which were all created 30+ years ago.
66 comments
[ 12.1 ms ] story [ 1904 ms ] threadAside from that I was a big LightTable fan and really enjoyed its inline instarepl and other features, so it is definitely great to see that LT is not completely forgotten! Kudos!
The project is dead [1][2] as of Jan 24, 2018.
[1] https://news.ycombinator.com/item?id=16227130
[2] https://groups.google.com/forum/#!msg/eve-talk/YFguOGkNrBo/E...
Part 1: https://www.youtube.com/watch?v=WT2CMS0MxJ0
Part 2: https://www.youtube.com/watch?v=ThjFFDwOXok
I think the same is true of Chris.
For example, I have yet to find any modern editor that draws inspiration from the brilliantly designed ideas used in Plan 9's 'sam' and 'acme' editors.
For example structured regexps, 3 button mouse chording, and the 'plumb' feature thats basically a context-aware, smarter version of a unix pipe between two executables.
I mean i can go on and on but another thing that i find absolutely annoying about newer editors is that they all use Webkit as the base of their apps core foundation.
This makes it irritating to consider trying to make changes to the code that I believe would overall improve the editor and make it more useful. (at least as far as im concerned)
I can literally make a list a mile long of things I like in other editors and wish i could see condensed into one ultimate code editor to supplant all code editors that had come before.
Does such a thing exist?
But I also wish plan9 got more awareness. Unix pipes are so useful that it’s a shame the plan9 paradigms have largely been ignored or reinvented.
Acme was different to the 'sam' editor and most other Plan 9 programs up to that point (aside from its predecessor, "help", a similar system that was replaced by acme).
Then you wouldn't be "taking your hands off the keyboard", you'd just be engaging in a different motion.
Not everybody agrees, of course.
BTW, does chording work well with mice where one of the ”three” buttons is the scrool wheel?
I can't, however, imagine left+middle chord on modern laptops, there are not that many laptops (mostly ThinkPads as far as I can tell) that have three physical mouse buttons.
So a proof that even that point needs better research. :)
Since we are on a Lisp thread, same applies to those that just bother with Emacs, eventually SLIME, withouth ever spending one second with actual Common Lisp IDEs.
"The Mesa Programming Environment"
http://www.digibarn.com/friends/curbow/star/XDEPaper.pdf
"The Cedar Programming Environment: A Midterm Report and Examination "
http://worrydream.com/refs/Teitelman%20-%20The%20Cedar%20Pro...
One of its strengths was discoverability. Jeff's son Aza iterated on a number of the ideas from the Cat with Enso and Ubiquity but those efforts were not specific to an editor.
This is the first time I hear about this. What make it better? How I learn more?
This has never given me an impression of a good UX.
A more discoverable UI may take a greater number of steps to perform. If the application is used rarely or briefly, that's a good trade-off. But if an application will be heavily used by a user who is incentivized to learn the tool, then their total productivity matters more since it amortizes over the lifetime of their use with the tool.
Text editors definitely fall into the "heavily used" bucket, so a good user experience might mean "you gotta read the manual, but once you do you can go 10x faster".
They're basic verbs you use to interact with text; not a full command. E.g instead of executing "format document" from a menu, you select the document with the left mouse button, and then middle click on the word "format". This executes the "format" command on the selected text. Somewhat like running gg=G in vim.
[1]: https://www.codeshelter.co/
[2]: https://www.codeshelter.co/projects/
I just realized thats basically what we already do today: i use WebStorm and my webapp hot-reloads any code i type. If i wanted i could even rewind the app state. And when i enable JS debug in IDE its like inception and matrix-view combined, but surprisingly userfriendly still.
To easily try this with just about any IDE check out https://github.com/facebook/create-react-app
Many (five?) years later, from what I gather, LT has the eye-candy - the rest is perpetually "under construction". It would be hard for it to be anything else, though, as the main developers jumped ship a few years back to work on Eve (which, as a karmic retribution for all my crushed hopes for LT, also tanked and died recently).
Emacs may be less pretty than newer editors, and lots of its APIs are decades old at this point, but it's still the only self-documenting, easily discoverable and extensible editor this side of Pharo and Squeak, which can be used in practice (due to a giant amount of plugins which bring it up to modern standards) for almost any task.
TLDR: LightTable as a powerful editor for programmers is dead - it may be still possible to revive it, but its scope would have to be massively scaled down. It's not going to compete with Emacs & co. anymore, which is a shame, because when it started it had the potential for this.
The core GNU Emacs is quite a bit less lines of Emacs Lisp.
Do you have any idea how many lines of elisp/c the core is? And how gnarly it is? I've read some stories.
IIRC Emacs' C code numbers ~300kloc and includes both bindings to low-level, systems and GUI functionality, some parts of standard Elisp library (writen in C for performance), as well as Elisp virtual machine, byte-compiler and so on. No JIT yet, but at least there's threading support (take that JS :P).
Starting from scratch has many advantages, but it doesn't really work with programs and systems large or complex enough. Otherwise we'd be using a fresh OS every five years instead of working on one of the 5-6 OSes which were all created 30+ years ago.