[2008] On The Flight to Old Text Editors(al3x.net)
al3x.net
[2008] On The Flight to Old Text Editors
http://al3x.net/2008/10/22/on-flight-to-old-text-editors.html
9 comments
The difference is that in the case of hammer vs. nailgun, the old solution (the hammer) is the simple one, and the new solution (the nailgun) is the complex one.
With editors it's the other way around. Old editors are in no way simple, quite the contrary. Emacs is complex, and Vim, while seemingly simple, is complex once you want to change its default mode of working.
As in the case with the hammer, simple tools often work best - but in the world of editors, the new tools are often the simplest ones.
With editors it's the other way around. Old editors are in no way simple, quite the contrary. Emacs is complex, and Vim, while seemingly simple, is complex once you want to change its default mode of working.
As in the case with the hammer, simple tools often work best - but in the world of editors, the new tools are often the simplest ones.
It's not clear that nailguns are more complex than hammers. What is the measure of complexity? Nailguns are easier to use for a complete newbie, so a nailgun could be seen as a simpler tool. Becoming an expert hammer user takes literally years.
There are many different ways to measure complexity. Learning curve, interface, potential for virtuosity, amount of time implementation took, etc.
Nailguns are wayyyyy simpler to use than a hammer.
There are many different ways to measure complexity. Learning curve, interface, potential for virtuosity, amount of time implementation took, etc.
Nailguns are wayyyyy simpler to use than a hammer.
As a one-time (long ago) silver smith, I can tell you that while there were more than 30 hammers on the wall, there was not one nail-gun. A brief tour of books on subjects from book-binding to leather engraving should demonstrate that there is not a one-size fits all replacement for a tool whose many forms have been developed over centuries (if I handed you a hammer used by a roman carpenter, you would know a.) what it was and b.) how to use it) is just silly. Try making the last finishing cut with a carving tool using a nailgun before you say anything about simplicity...
I think you missed my point. What you're saying actually supports my opinion on this issue.
Okay, I wasn't aware of that. I still think modern editors are simpler and easier to deal with than Emacs and Vim, but that's a different story.
There's an argument here struggling to get out. As an emacs user, I agree with some of the ideas he is attempting to express, but then it just sort of gets buried in "I don't like emacs or vim." and "too much customization bothers me."
Maybe a better discussion than: "why are all these developers still using vim and emacs" is: "why haven't we come up with development tools in the past 30 years that are compelling enough to draw people away from vim and emacs?"
Maybe a better discussion than: "why are all these developers still using vim and emacs" is: "why haven't we come up with development tools in the past 30 years that are compelling enough to draw people away from vim and emacs?"
Yeah, I've never been able to stand eclipse. I get a big monitor and a fast computer, and eclipse ends up showing me code in a 20 row by 40 column window and jeez, I could see more code and faster using emacs in the first crts.
But the article, titled "On The Flight to Old Text Editors" told me little about why people are moving back to vim or emacs. What is the value that longtime eclipse or textmate users are seeing in emacs or vim? Speed? Keyboards? What problems of modern text editors does emacs and vim solve?
Mostly what I get from the article is that the flight to old school editors is a hipster thing. Oh yeah, gotta use the old school editors because we're hipsters. Eclipse is a sellout man. Textmate is for Lady Gaga. I edit it old school vim and emacs.
But the article, titled "On The Flight to Old Text Editors" told me little about why people are moving back to vim or emacs. What is the value that longtime eclipse or textmate users are seeing in emacs or vim? Speed? Keyboards? What problems of modern text editors does emacs and vim solve?
Mostly what I get from the article is that the flight to old school editors is a hipster thing. Oh yeah, gotta use the old school editors because we're hipsters. Eclipse is a sellout man. Textmate is for Lady Gaga. I edit it old school vim and emacs.
Which is funny, because I remember a few years ago (circa 2007) when Rails was just starting to get big and Textmate was the hipster editor.
All of which is idiotic, because anyone who chooses an editor based on image is most likely a terrible developer. That said, I think Textmate is a very good editor and one of the few capable contenders in the editor "wars". The biggest downside is that it is Mac-only.
All of which is idiotic, because anyone who chooses an editor based on image is most likely a terrible developer. That said, I think Textmate is a very good editor and one of the few capable contenders in the editor "wars". The biggest downside is that it is Mac-only.
Finally, a sane voice.
The notion of an editor 'war' is laughable. I'm sure in five years or so someone will innovate in the graphical editor arena and the pendulum will swing back. And, lo and behold, all of the bloggers and Tweeters will gush about their "10x" productivity increases. I never seem to get those sorts of massive productivity gains, as the hard/slow parts of development take place in my mind.
The notion of an editor 'war' is laughable. I'm sure in five years or so someone will innovate in the graphical editor arena and the pendulum will swing back. And, lo and behold, all of the bloggers and Tweeters will gush about their "10x" productivity increases. I never seem to get those sorts of massive productivity gains, as the hard/slow parts of development take place in my mind.
I switch between Vim and Textmate. One is better for some jobs, the other is unbeatable at others.
There's still ed(1), of course...
There's still ed(1), of course...
I think this is a case of the classic fallacy of evolution. Which is more evolved: E. coli? or Humans? Before you answer, consider that E. coli has been living successfully in various ecological niches literally all across the globe for a couple billion years.
In other words: just because something is newer doesn't mean it is better, especially when we're talking about a complex system like life...or text editors.
In other words: just because something is newer doesn't mean it is better, especially when we're talking about a complex system like life...or text editors.
But computers really are better than 30 years ago. The fact that we haven't come up with a better text editor is actually surprising. I don't think that emacs is the best that we are capable of.
Modern vim is quite a lot more convenient than the original vi; I agree that there's no revolution, but there definitely is progression.
This. The point of the evolutionary fallacy is that when evolving, creating new forms is not better (necessarily) than improving the existing forms. E. coli today are probably nothing like E. coli 2 billion years ago, but they have been continually improving in their own niche while other organisms have gone off trying to find new niches. Similarly, emacs and vim of today are nothing like emacs and vim of even 10 years ago, but instead of creating new devices they continually improve on a proven model.
Agreed. I've been using emacs a lot lately and the thing I like most about it is that I feel like I'm a hacker in the 80s.
I think the flight to old text editors is caused because of the problems with modern ones. At some point you just think "SURELY this problem has been solved before". But it seems like it hasn't.
I think the flight to old text editors is caused because of the problems with modern ones. At some point you just think "SURELY this problem has been solved before". But it seems like it hasn't.
I think it's a bit of an indictment of the industry, actually. We're not that good at making tools to think with for people less skilled than ourselves, and that's the most important thing we can be doing.
Here's an example. I'm not the most technical guy round here – I mean, I write code but it's not magic – but even taking all weekend, I couldn't get either emacs or vim to do reasonable Python code completion. This shouldn't be hard.
Here's an example. I'm not the most technical guy round here – I mean, I write code but it's not magic – but even taking all weekend, I couldn't get either emacs or vim to do reasonable Python code completion. This shouldn't be hard.
And that reminds me of a post by Steve Yegge saying that the language interpreter/compiler should make it easy for Emacs to offer completion. Otherwise is very hard to implement a great completion...
Which, as an emacs user, I completely agree with. Certain things in emacs are much more difficult to get working than they should be. Emacs sucks, but other editors just suck more (I'm not talking about you vim). To be fair, though, emacs was designed in a completely different development world, and yet it can still compete against modern development tools. That is more of an indictment of modern tools than it is of emacs.
People forget that Unix itself is one big IDE. I use emacs to edit code, but in another terminal window I use make to compile or run tests, "find" and grep to look for stuff, tail to look at logs, custom shell scripts for lots of other things, etc etc. So emacs isn't an IDE, it is just a text editor, and the best one I know at that (I love vi for quick configuration tweaks, but not real coding).
I use Emacs for almost everything. I used to use IDEs but became tired of waiting for all of the extra features to load. When I first began using Emacs I struggled for probably 6 months. Now I really can't do without it. I don't use it for email. I don't use it for the web. But I do use it for Twitter, I've written papers in it using org-mode and LateX and I'm currently writing my third book on it.
Once your fingers get used to all of the bizarre key-presses the editor just seems to fade into the background and you can just get on with your work.
As a C/C++/C# developer I can't imagine giving up IDEs for vi. vi is my editor of choice for quickie edits on Linux but for project work it's Eclipse and VS. I've used IDEs since UCSD Pascal but really only recently got convinced they are a real productivity enhancer.
If I ask myself why I use IDEs I can really only come up with Intellisense, if I worked in a language that doesn't allow a high degree of completion, browsing, etc. I could easily go with something simple.
If I ask myself why I use IDEs I can really only come up with Intellisense, if I worked in a language that doesn't allow a high degree of completion, browsing, etc. I could easily go with something simple.
I plugged viemu into VS, now I've got all the nice IDE stuff but with the vim editing model, which I'm completely addicted to now.
I agree with you. When I use C#, MonoDevelop (or VS) is my choice. I can barely write a class without an IDE's intellisense.
Python or Javascript: I use Vim with joy.
Python or Javascript: I use Vim with joy.
I think the amusing thing here is the assumption that people could make something better without first understanding what they are replacing. How can you expect someone to make a better vim/emacs, without understanding what made it great in the first place?
And perhaps that's what made us stuck since folks that don't understand what makes it great can't make something better, and the ones that do understand it are satisfied with them like they are.
My primary objection to both of the 'sacred' editors mentioned (not talking TextMate---I've no knowledge of it) is that they violate the original Unix tool rule: 'One task, done well...' All of the bolt-ons so the programmer could sit on his virtual dead ass without leaving his environment just make chalk-board-scrapping noise as far as I'm concerned.
Slightly off topic, but jEdit is an excellent editor on OSX. I'd highly recommend it.
I wrote a little guide about my jEdit setup a while back: http://dhotson.tumblr.com/post/443485667/making-jedit-awesom...
I wrote a little guide about my jEdit setup a while back: http://dhotson.tumblr.com/post/443485667/making-jedit-awesom...
I used jEdit for many years on linux and windows, but development has been stalled for a long time. Presumably moment dropped off quickly after the author Slava moved on to other projects. It's a shame. I'm trying http://www.vicoapp.com/ instead these days. Not as good as jEdit, but at least people are actively maintaining the code.
I think you'd be surprised. It's picked up a bit over the last year or two. The jedit-users list is still reasonably active.
By far my most heavily used program is KEdit which is a PC version of the IBM VM/CMS editor XEDIT written by an IBM guy in Paris.
In both cases, there is a macro language based on Mike Cowlishaw's Rexx which is elegant.
Why such heavy use of KEdit? I am a heavy computer user, and, except for Web browsing, nearly all my computer input is via typing. So, the first issue has to be, what software to type into?
Well, I don't want to type into just a standard graphical user interface (GUI) 'multi-line text box' 'control' because the functionality is meager.
Yes, I'm a Windows user: So, in particular I don't want to type into Outlook or Visual Studio. Since my most important work is applied math, I use TeX for that and for all my high quality word whacking; so, I don't want to type into Word. I use SQL Server Management Studio for data base 'browsing' but won't type anything important into it.
So, here's much of what I type into KEdit:
(1) e-mail to send,
(2) input to TeX for mathematical and high quality word whacking,
(3) blog posts such as this one,
(4) notes on everything I want to remember in programming, shopping, equipment repair, medical care, financial records, phone numbers, addresses, abstracts of Web pages -- everything,
(5) software source code, including T-SQL for input to SQL Server,
(6) most of my important program test input,
(7) looking at program test output,
and more.
E.g., a little KEdit macro does my telephone dialing. Another little KEdit macro types mailing labels.
More? I'm developing a Web site; it's my first serious HTML programming. Since I'm a Windows user, I'm using ASP.NET. Well, I want some good logging for the Web site. ASP.NET has some default logging, but I didn't like it. Well, .NET also has some lower level tools for logging; these tools do handle the important issues of multiple threads of multiple programs on multiple machines all writing to the same log at the same time. Good -- that's the crucial functionality I needed.
So, now I have some good data logging.
Since the log file is 'circular', the first thing to do when reading one is to sort it on, say time, date, and machine. And with multiple log files, there can be some duplicate lines. In using the log files it can be important to 'select' lines based on the user's IP address, the name of the Web page, the routine in the Web page that wrote the line to the log, the message number of the message within the routine, etc. Sure, all this can be done with relational data base, but for log files of reasonable size it can also all be done more easily just within KEdit, especially if write a few KEdit macros.
So, I look at and do the first cut analysis of log files just within KEdit.
To be clear, on the title of the article 'On The Flight to Old Text Editors', I never left my "old text" editor. I've been using KEdit or XEDIT since 1985 and was using good text editors before then.
Alternatives? I see no good alternatives.
Why?
Well, the article lamented:
"That a new generation of programmers flocking to these old tools is concerning, if for no reason more selfish than the desire for peers in my dissatisfaction. Without a consensus that we can do better, there’s no incentive, no motivation, no market for improvements. If as modest a step towards a better editor as TextMate is abandoned, what hope is there for a true leap forward?"
Well, there's been no "true leap forward?" apparently mostly because of the overwhelming theme of the 'graphical user interface' (GUI) from the bean bag chairs and 'cognitive psychology' people at Xerox Palo Alto Research Center (PARC) and the use of GUI ideas by Apple, Microsoft, X-Windows, and now, with further development, smart phones.
In particular an important special case has been the Web and Web browsers.
The PARC goal was to make computer interaction easy for the pre-school children of the PARC employees for future Xerox office machines, and the approach was to have a user interface much like that on, say, a microwave oven.
So, with GUIs what we've got is for pre-school children using microwave ovens, and that's not promising for a "true leap forward".
So, the assumption in the computer industry has been that humans should interact with computers via a GUI, almost exclusively.
For a user mostly just receiving information, maybe that assumption is okay, but, for a user generating information, no.
The good text editors were designed by some of the best programmers ever for use by some of the best programmers ever. So, it's no surprise that good programmers prefer good text editors.
Bluntly, for generating information, it is still very important to type, and so far for people doing a lot of typing a good text editor is by far the best software to type into, in particular, much, Much, MUCH better than any of the check boxes, radio buttons, text boxes, and multi-line text boxes of the GUI standards.
In particular, for programming, I've been doing that for a long time. I've always found programming to be fast, fun, and easy giving the input just via a good text editor. I could count on one hand all the times I got any benefit from 'interactive debugging' tools.
So, I tried Visual Studio. I saw a window with many 'panels', and I could never find what all the panels were for. Some of the panels were said to be 'dockable', and the intended meaning was obscure and not in my copy of Webster's. The one little window was cramped, and in strong contrast when I program I typically have a dozen or so windows open at once, using either KEdit or my favorite Web browser, for entering source code, for documentation, for earlier versions of the program, for other programs I can use as samples, for various notes, for program output, for searching for information on Google, etc. The one cramped window from Visual Studio is, in comparison, a bad joke. For just the typing, Visual Studio gives me just some little panel within the one window, and KEdit is MUCH better. It's easy to write powerful macros in KEdit, and I do, and I saw no promising way to write macros in Visual Studio.
When I saw that with Visual Studio the work is to be a 'project' and even a project to report "Hello World" starts with 50 MB, I concluded that Visual Studio was from the far side of Xerox PARC in luna-land.
For my present development I'm mostly using just Visual Basic .NET via a script program from command line text windows. I'm thrilled: The complier is fast, easy to invoke, gives good error messages, so far appears to be essentially free of bugs, and generates surprisingly small EXE files. Terrific. What's in the Visual Studio 50 MB has to be glop, gorp, and goop I very much don't want to have to work with when things go wrong, and with that much glop, gorp, and goop some things are very likely to go wrong.
So, yes, I do a lot of typing and do my typing into the best text editor I know of, KEdit.
In both cases, there is a macro language based on Mike Cowlishaw's Rexx which is elegant.
Why such heavy use of KEdit? I am a heavy computer user, and, except for Web browsing, nearly all my computer input is via typing. So, the first issue has to be, what software to type into?
Well, I don't want to type into just a standard graphical user interface (GUI) 'multi-line text box' 'control' because the functionality is meager.
Yes, I'm a Windows user: So, in particular I don't want to type into Outlook or Visual Studio. Since my most important work is applied math, I use TeX for that and for all my high quality word whacking; so, I don't want to type into Word. I use SQL Server Management Studio for data base 'browsing' but won't type anything important into it.
So, here's much of what I type into KEdit:
(1) e-mail to send,
(2) input to TeX for mathematical and high quality word whacking,
(3) blog posts such as this one,
(4) notes on everything I want to remember in programming, shopping, equipment repair, medical care, financial records, phone numbers, addresses, abstracts of Web pages -- everything,
(5) software source code, including T-SQL for input to SQL Server,
(6) most of my important program test input,
(7) looking at program test output,
and more.
E.g., a little KEdit macro does my telephone dialing. Another little KEdit macro types mailing labels.
More? I'm developing a Web site; it's my first serious HTML programming. Since I'm a Windows user, I'm using ASP.NET. Well, I want some good logging for the Web site. ASP.NET has some default logging, but I didn't like it. Well, .NET also has some lower level tools for logging; these tools do handle the important issues of multiple threads of multiple programs on multiple machines all writing to the same log at the same time. Good -- that's the crucial functionality I needed.
So, now I have some good data logging.
Since the log file is 'circular', the first thing to do when reading one is to sort it on, say time, date, and machine. And with multiple log files, there can be some duplicate lines. In using the log files it can be important to 'select' lines based on the user's IP address, the name of the Web page, the routine in the Web page that wrote the line to the log, the message number of the message within the routine, etc. Sure, all this can be done with relational data base, but for log files of reasonable size it can also all be done more easily just within KEdit, especially if write a few KEdit macros.
So, I look at and do the first cut analysis of log files just within KEdit.
To be clear, on the title of the article 'On The Flight to Old Text Editors', I never left my "old text" editor. I've been using KEdit or XEDIT since 1985 and was using good text editors before then.
Alternatives? I see no good alternatives.
Why?
Well, the article lamented:
"That a new generation of programmers flocking to these old tools is concerning, if for no reason more selfish than the desire for peers in my dissatisfaction. Without a consensus that we can do better, there’s no incentive, no motivation, no market for improvements. If as modest a step towards a better editor as TextMate is abandoned, what hope is there for a true leap forward?"
Well, there's been no "true leap forward?" apparently mostly because of the overwhelming theme of the 'graphical user interface' (GUI) from the bean bag chairs and 'cognitive psychology' people at Xerox Palo Alto Research Center (PARC) and the use of GUI ideas by Apple, Microsoft, X-Windows, and now, with further development, smart phones.
In particular an important special case has been the Web and Web browsers.
The PARC goal was to make computer interaction easy for the pre-school children of the PARC employees for future Xerox office machines, and the approach was to have a user interface much like that on, say, a microwave oven.
So, with GUIs what we've got is for pre-school children using microwave ovens, and that's not promising for a "true leap forward".
So, the assumption in the computer industry has been that humans should interact with computers via a GUI, almost exclusively.
For a user mostly just receiving information, maybe that assumption is okay, but, for a user generating information, no.
The good text editors were designed by some of the best programmers ever for use by some of the best programmers ever. So, it's no surprise that good programmers prefer good text editors.
Bluntly, for generating information, it is still very important to type, and so far for people doing a lot of typing a good text editor is by far the best software to type into, in particular, much, Much, MUCH better than any of the check boxes, radio buttons, text boxes, and multi-line text boxes of the GUI standards.
In particular, for programming, I've been doing that for a long time. I've always found programming to be fast, fun, and easy giving the input just via a good text editor. I could count on one hand all the times I got any benefit from 'interactive debugging' tools.
So, I tried Visual Studio. I saw a window with many 'panels', and I could never find what all the panels were for. Some of the panels were said to be 'dockable', and the intended meaning was obscure and not in my copy of Webster's. The one little window was cramped, and in strong contrast when I program I typically have a dozen or so windows open at once, using either KEdit or my favorite Web browser, for entering source code, for documentation, for earlier versions of the program, for other programs I can use as samples, for various notes, for program output, for searching for information on Google, etc. The one cramped window from Visual Studio is, in comparison, a bad joke. For just the typing, Visual Studio gives me just some little panel within the one window, and KEdit is MUCH better. It's easy to write powerful macros in KEdit, and I do, and I saw no promising way to write macros in Visual Studio.
When I saw that with Visual Studio the work is to be a 'project' and even a project to report "Hello World" starts with 50 MB, I concluded that Visual Studio was from the far side of Xerox PARC in luna-land.
For my present development I'm mostly using just Visual Basic .NET via a script program from command line text windows. I'm thrilled: The complier is fast, easy to invoke, gives good error messages, so far appears to be essentially free of bugs, and generates surprisingly small EXE files. Terrific. What's in the Visual Studio 50 MB has to be glop, gorp, and goop I very much don't want to have to work with when things go wrong, and with that much glop, gorp, and goop some things are very likely to go wrong.
So, yes, I do a lot of typing and do my typing into the best text editor I know of, KEdit.
Sometimes the old thing is really the best solution, and attempts to improve it are misguided and fail. Carpenters will give the newfangled tools an honest shot and then decide that the old tools had a certain je ne sais quoi that made them better.
It's not that you can't build a better hammer. Nailguns do exist. But still.. nailguns aren't hammers. A scaffolder can't use a nailgun to do his work, for instance. But I bet the guy who invented the nailgun claimed it would totally replace hammers and just forgot to consider the scaffolders. And now laymen on the outside ask, "What are those scaffolders doing carrying around hammers in 2011? That tech is like a million years old! Surely we can do better!?"