Editing the Future – Light Table, and Atom, and Then What?

Github recently announced their project to create their own programming editor called Atom. (Nice logo! wink) If you haven’t seen it, here’s a great hands-on post showing off its features.

In 2012, Chris Granger announced a project called Light Table, which I think was a recent mile marker on the same road as Atom.

Here’s some of what Light Table shares with Github’s Atom:

  • Both offer a web-based programming platform targeting customizability (AtomLightTable).
  • Both leverage modern languages to implement the editor itself (AtomLightTable).
  • Both envision open-source communities of 3rd party plugins (AtomLight Table).

So if these two recent programming environment projects are points on a line, where does that line point?

But I’m so comfy using {editor}!

There’s no shortage of editors or opinions on them. What really interests me about new editors are the forces that bring these new projects to the surface. What makes someone say, “Let’s just start from scratch”?

For Chris Granger, it was aspirations to change the way programming happens. He was inspired by Bret Victor’s talk Inventing on Principle, and cites some big historic landmarks on this path as the spark for Light Table: Smalltalk, Symbolics Genera, Logo, and HyperCard. Light Table is based on exploring a future of building software.

Atom has some lofty goals too. From their intro page:

[We are] building the text editor we’ve always wanted. A tool you can customize to do anything, but also use productively on the first day without ever touching a config file. Atom is modern, approachable, and hackable to the core. We can’t wait to see what you build with it.

It sounds like Atom is trying to hone what TextMate and Sublime Text had both started to deliver, though we can likely guess that that’s just the starting point.

What are we looking for?

Considering a larger list of modern programming environments (at the end of this post) we get an expansive view of the landscape of features we’d like to see our editors include. They should:

  • Let us navigate projects and edit source code
  • Know the syntax of our languages
  • Integrate with compilers, interpreters, REPLsCI
  • Allow a network of collaboration to easily build and maintain language and platform support within the editor
  • Allow real-time remote collaboration
  • Integrate with modern app dev environments, browsers, source control, cloud and mobile deployment, etc.
  • Allow free-form presentation of more than code: text markup, hints, refactorings, function flows, live previews, etc.
  • Interpret our code as we type it, showing results locally to reduce cycles
  • Abstract above the files and folders paradigm of code organization and navigation

The last three, and especially the last two, are more timeless goals than the rest. They seem to reach beyond making a kick-ass modern editor and ask for a more fundamental change, as Chris Granger hinted shortly after Atom’s announcement:

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. For example, showing functions individually actually introduces another level of cognitive load through the loss of locality. It turns out that the way we organize code files ends up being very important, and there’s no way to glean a lot of the information that is stored in that organization purely through code walking. By virtue of the way we program now, really important notions like “flow” are lost and hidden under layers upon layers of indirection. And so we have to live with those limitations (which exist in even fantastic languages like Clojure).

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.

Following the conversations on Twitter and Reddit, I got the sense that for some people the important aspects of Atom revolve around its license and its performance. But to me the most important features are those that move us closer to getting that whole list and then seeing what’s on the next horizon.

Sure, it’d be nice if it was fast, free, and cross-platform. But what if an editor could make you look at your programming language in a new light, or usher in the need for new languages entirely? What if an editor could change the way its users are able to communicate about the code they write? As these new projects move forward and evolve, those are the kind of questions I’ll be looking to answer.

Editors (of) Note

Let me save you some googling if you are new to any of these:

Not to leave out our more mature friends:

 

Conversation
  • mempko says:

    You should look at projectional editors. Completely inverting the idea of editing. Imagining reaching into your computer and manipulating the AST with your hands.

    • Karlin Fox says:

      Yes, those are exciting ideas! An interesting example I’ve seen is Lisping which really delivers on the “with your hands” part.

      What examples of projectional editors have you seen or used?

  • Comments are closed.