Actually, this IS your father’s text editor
This week, I’m doing all my coding on a borrowed MacBook. It’s the most time I’ve ever spent doing development on a Mac. I’ve done a bit here and there on my Mac Mini, but usually I just use that for web browsing, downloading episodes of Degrassi High, and such.
Of course I needed a text editor, so I figured I’d give TextMate a try since it’s highly recommended by many Mac hackers. My first impression has been good. It’s a got a nice, simple, no-frills interface, some slick built-in themes (Espresso Libre ftw!), and the bundles come in pretty handy.
I’ve found a few small things that have thrown off my rhythm though. The regular find command (⌘-F) doesn’t do an incremental search, and hitting Enter again doesn’t bring up the next match. Yes, I know about Ctrl-S, but geez, I gave up Emacs like eons ago, and I’m just so used to typing Ctrl-F (on Windows) or ⌘-F (on the Mac) to search. And I want it to work that way in every application.
Another thing that I miss is the way the Home and End keys work on Windows: they move the cursor to the beginning and end of the line. On the Mac, they take you to the beginning and end of the file, which you can also do on Windows by hitting Ctrl-Home and Ctrl-End. I really miss the Windows behaviour, because it’s my favourite way to nuke a line or a whole section of code: whack Home, then hold down Shift and use the arrow keys to select the lines you want to kill.
Anyways, the point of this post is not to complain about TextMate, because it is a fine piece of software, and I’m sure it won’t take long for me to adapt. But this experience got me thinking about the whole experience of programming in a text editor, and made me realize that this hasn’t really changed much in 30 years.
Where’s the innovation?
In 2008, on almost every operating system, your choices for a text editor are roughly the same:
- vi, the modal editor for UNIX-loving, bearded hackers
- Emacs, the non-modal editor for LISP-loving, bearded hackers
- Some kind of WIMP-y editor, for everyone else. Sure, there are plenty of “choices” in this category, but it’s like the choice between Coke, Dr. Pepper, and root beer: they’re still all sugary, caramel-coloured beverages. TextMate, Eclipse, Visual Studio, Notepad, etc. — the actual act of editing text is almost exactly the same in all of them. These guys basically work like your standard WYSIWYG word processor, with a few extra features for coding.
Now let’s go back 30 years, to 1978. I wasn’t breathing 30 years ago, let alone coding, so I had to go to Google for a little history lesson. But as I understand it, here were your choices in 1978:
- a line editor like ed, which I’ve been told was roughly like trying to write with a pen tied to the end of a metre stick
- vi, the modal editor for UNIX-loving, bearded hackers
- Emacs, the non-modal editor for LISP-loving, bearded hackers
- Some kind of WIMP-y editor, if you were lucky enough to be working at Xerox PARC
So where’s the innovation?
At this point, you might be thinking, who cares? Emacs/vi/TextMate is good enough. The thing is, the text editor is still the primary user interface for coding. That’s why some people get so religious about their preference. It just seems weird to me that there have been so few attempts to try something truly new. And I find it hard to believe we reached the pinnacle of programming UIs in 1978.
A few ideas
Most editors are just as good for writing a blog post or screenplay as they are for writing code. But the structure of code is completely different. You rarely open up a source file and read it from beginning to end. But most programming environments seemed to be designed for that kind of workflow.
In the end, I think that’s the real kicker: most programming languages are file-based. For some reason, we seem to be so attached to coding in plain text with 80-character lines. If you drop this assumption, things start to get a bit more interesting. But that only takes us to where Smalltalk IDEs were at in the 80s.
Anyways, most of the dynamic languages aren’t inherently file-based. By that I mean that it’s not too difficult to interface with the interpreter without using text files. So that’s not a good excuse.
Here are a few things I’d love to experiment with in a programming environment:
Better support for random access. The structure of code is more like hypertext than it is like a book.
Richer annotations. Comments take up valuable screen space. It would be nice to be able to have more unobtrusive comments in the code. This would also allow you to do things like have a discussion thread about a section of code, link to other relevant methods, etc. Even something as simple as comments that auto-wrap to the width of the window would be a nice touch.
Better support for looking at several sections of code at the same time. Some editors (including Emacs) allow you to split the window into several viewports. That’s a start, but it could be improved upon I think. That reminds me, I’ve been meaning to try Acme for a while.
Tighter integration between the editor and the runtime. One example is having your editor be able to tell you “every time you’ve run this method, this variable has been of type X”. Another example is if your editor visualized code paths — maybe you could overlay a heat map on top of the source code for profiling purposes
Explicit support for exploratory programming. When I code in Python, I like to keep an interactive console open, where I can try out little snippets of code. With a bit of tweaking (e.g., not tossing out my entire method when I make a syntax error on the last line), I could see this becoming a primary way to write code.
What do you guys think? What are your favourite programming editors/environments, and why? Any other ideas about how programming UIs could be shaken up?
