

[2008] On The Flight to Old Text Editors - swah
http://al3x.net/2008/10/22/on-flight-to-old-text-editors.html

======
forensic
This reminds me of carpenters who use old hammers.

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!?"

~~~
logermoore
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.

~~~
forensic
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.

~~~
hsmyers
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...

~~~
forensic
I think you missed my point. What you're saying actually supports my opinion
on this issue.

------
hvs
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?"

~~~
jerrya
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.

~~~
hvs
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.

~~~
mattgreenrocks
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.

------
forkandwait
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).

------
dogriffiths
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.

------
zwieback
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.

~~~
DennisP
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.

------
taeric
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?

~~~
swah
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.

------
hsmyers
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.

------
dhotson
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...](http://dhotson.tumblr.com/post/443485667/making-jedit-awesome-on-
osx)

~~~
focusaurus
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.

~~~
dhotson
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.

------
NY_USA_Hacker
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.

