Chris Granger on the LightTable architecture
groups.google.com
groups.google.com
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.
http://gbracha.blogspot.com/2012/11/debug-mode-is-only-mode....
And later:
http://gbracha.blogspot.com/2013/04/making-methods-live.html
He is giving a keynote at ECOOP on the topic in June.
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)
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 [2] https://www.openhub.net/p/emacs (slow server) [3] http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=ce5584...
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.
> (for basic open/navigate/edit/save/search/replace) functionality in a few hours
Do you know how long it takes in Sublime / Atom / TextMate ? Approximately zero.
I use Spacemacs (Emacs with VIM inside) and even after months of working with it I'm still faster in Atom. That's not because I'm "doing it wrong".
Spacemacs fixes some of that integration. cmd-X C V S all work. but no cmd-F or cmd-R
and cmd-f is not the same as ctrl-f. in the emacs tongue it is referred to as s-f
predating is irrelevant. most of the younguns using text editors were born well after emacs was created.
Emacs is technically capable of being customized to suit established usage patterns. its only cultural stubborness that stops it.
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.
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.
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 [2] https://qa.debian.org/popcon-graph.php?packages=vim%2C+emacs... [3] http://popcon.ubuntu.com/by_inst
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.
People use what's available, having Vim preinstalled is a powerful headstart.
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.
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 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
Here are the results from the latest SO developer survey. The data may be biased, but it looks like vim outnumbers emacs by 5:1: http://stackoverflow.com/research/developer-survey-2015#tech...
Here's me complaining about slow text rendering: http://www.reddit.com/r/emacs/comments/2e8byy/slowass_text_r...
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!)
A tall order, I know :)
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.
If you are writing a tool to help java programmers program in java then writing it in java makes sense.
The problem is he was writing a tool that was not cutting edge enough for the clojure folks, and not easily approachable for its main users.
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.
[1] http://www.chris-granger.com/2012/04/12/light-table---a-new-...
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.
> 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.
So my point is; 'rediscovery' is a more apt way of expressing a lot of things today.
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.
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.
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
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 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.
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/
I did it with the Scala IDE back in 2006/2007, unfortunately, complete with mixin layer overuse.
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."
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.
A corollary is that if you are writing code with minimum repetition, you are effectively a compression algorithm, not a programmer.
I do not understand why that follows. Can you elaborate, please ?
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.
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
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.
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.
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...
[2] http://www.reddit.com/r/vim/comments/1ztxgd/why_atom_cant_re...
[3] Remember: don't discount the work of writing plugins.
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.
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
[1] - https://engineering.linkedin.com/frontend/new-technologies-n...
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.
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.
Once it's dead the space it frees up can be filled again by something that actually works.
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).
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.
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,
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...
In the beginning it was clearly marketed as a clojure ide, and if you look at the comments on HN at the time it's clear that it was perceived as such.
http://www.chris-granger.com/2012/04/12/light-table---a-new-...
https://news.ycombinator.com/item?id=3836978
>"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.
Good insight.
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.
Thanks!