Emacs users are like Terry Pratchett’s Igors

http://chrisdone.com/posts/emacs-users-are-like-igor

by nkurz • 13 years ago

151 83 13 years ago

FatalBaboon2• 13 years ago

Emacs is one of those things everybody knows is good, but few take the time to learn.

Over the years I've learnt quite a few languages, and what strikes me is that they're all so very alike. You find the same features with slight syntactic changes. At the end of the day, what really makes a difference is not which language you chose but what tools you are using. Do you have to memorize every important method or are they helping you find the documentation? What happens when something is a little broken, wait for a fix or patch the code immediately? Give up and live with it?

With Emacs, the languages change but the tool stays the same, you just extend it. In a way akin to how programming enhances my mind to be able to solve tough problems, emacs enhances my capacity to hack by letting me hack the tool itself.

Having a userbase made of people hardcore enough to learn some Lisp so they can hack their tool is just a bonus. Please keep fearing the parens!

Emacs is still being actively developed, v24.4 is in feature freeze: https://github.com/mirrors/emacs/blob/master/etc/NEWS (that's 1200+ lines of changelog for 24.4)

How many pieces of software can you name that have been around for 36 years and are still kicking? Do you think it has something to do with Lisp?

SkyMarshal• 13 years ago

Oblig reference to classic essay on that topic:

http://www.osteele.com/posts/2004/11/ides

nabla9• 13 years ago

Learning something that takes time should be seen as investment. If you invest your time and effort, you want to know that your investment pays dividends in the future.

I feel that Emacs is one of those tools where my investment is safe and the code I write to ~/.emacs produces huge value over several decades. It's not going away. Development community is so big that it supports all new stuff that comes along.

actsasbuffoon2• 13 years ago

Over the years I've learnt quite a few languages, and what strikes me is that they're all so very alike.

I used to think this as well, then I learned some Prolog. For those who aren't familiar with it, Prolog is a logic programming language (as opposed to imperative and functional languages). Instead of telling Prolog how to solve a problem, you give it a set of facts and tell it what you want to know. Prolog takes care of the rest, without writing any conditionals, loops, etc. At least in theory; in my (small amount of) experience most non-trivial Prolog programs usually involve some imperative style code. Still, it's wildly different and a lot of fun.

There's also lambda calculus, which is crazy, and wonderful, and absurdly difficult, and one of the most joyous experiences I've ever had. It's a language with nothing but functions applied to other functions. Even numbers are functions in lambda calculus, which has some fascinating implications. I wouldn't want to build anything non-trivial in LC, but I've learned a lot about programming as a result of studying it.

Discovering how to create singly linked lists in LC using nothing but partially applied functions was a profound and emotional experience. I remember how hard I laughed when I noticed that LC's false function is the same as the Church-encoded numeral for zero. These are things most other developers don't think are funny because they have no idea what I'm talking about. I think a few of my co-workers suspect I should be institutionalized when I start talking about lambda calculus.

Of course, there's also Haskell. A lot of lambda calculus is applicable to Haskell, which makes sense as Haskell descends from the ML family of languages, which in turn come from lambda calculus. Haskell doesn't look or feel like most other languages, and it makes some decisions that seem really strange at first glance. Lazy evaluation, all functions are curried, no mutable state, all functions are pure, there are no variables, no exception handling... the language sounds almost unusable. Then you learn about monads and you realize that it's trivial to add support for something that looks and feels like mutable state, except it's a system of your own design. Imagine what would happen if you could change the way variable assignment works in your language of choice. For instance, software transactional memory was originally implemented in Haskell as a monad. They didn't have to modify the language to add support. I can't think of many other languages where that's the case, and it's a thing of beauty.

That's a long and rambling way to say that lots of languages are really similar, but there are some wonderful languages that are extremely different. I highly recommend experimenting with them, but be aware that your friends and co-workers are unlikely to have any idea what you're talking about. And on the off chance that they do understand, please let me know where you work. I want to work with you people.

decasteve• 13 years ago

I agree.

Over the years I've learnt quite a few languages, and what strikes me is that they're all so very alike.

The Sapir-Whorf hypothesis would seem to be even more applicable to programming languages (and fields of mathematics) than to spoken language itself.

* http://en.wikipedia.org/wiki/Sapir-Whorf

jordan0day• 13 years ago

This is a great comment!

I remember how hard I laughed when I noticed that LC's false function is the same as the Church-encoded numeral for zero.

Those sort-of "eureka" moments when a bit of programming language enlightenment materializes through ones own investigation are a joy.

wonderzombie• 13 years ago

Agree w/ siblings that this is a great comment. I'd like to amplify it.

A lot of imperative languages end up being really similar once you've learned a few of them. I'm not an expert on PL history but, AIUI, ALGOL was the progenitor for many modern languages, especially imperative ones. So it makes sense as to why, but there are paradigms other than imperative or even functional.

Of course this is not to say that all imperative languages are the same. Rather it is to say that alikeness is relative. Relative to C, Java is quite different. Relative to Prolog or Forth, C and Java are more similar than not.

If anyone really wants to expand their brain to new ways of thinking wrt programming, I think exploring these off-the-beaten-path programming languages is a great idea. I agree that many people around you will think you're nuts. As long as you don't lose your sense of practicality, pragmatism, and/or proportion, you shouldn't listen to them.

al2o3cr• 13 years ago

+1 on the lambda calculus stuff. Here's a related talk about deriving the Y combinator in Ruby by Jim Weirich:

http://www.youtube.com/watch?v=FITJMJjASUs

(skip to about 28:00 if you're impatient)

There are additional versions of this same presentation circulating with the code in Javascript and (I believe) Clojure. Full disclosure: Jim is a co-worker of mine.

agumonkey2• 13 years ago

I second you on LC. It profoundly impacted my brain. Mostly for the reason you mentioned, Closures, Church Encoding[1], Y, Combinators. It's almost vacuous yet it works. I love to rewatch talks about LC in ruby or javascript (well named 'programming with nothing').

[1] I like the fact that CE'd numbers are structural, a CE 2 will apply twice another function, instead of the usual stored symbol to be read/interpreted in most systems. Reminds me of 2.times(<fun>) in ruby IIRC.

agumonkey2• 13 years ago

Two thing that I found lacking for less-than-good hackers like me :

  - idiomatic (minor|major) mode organization (I found a book and a pdf which are old and might not represent the best way to do so)

  - at emacs conf, jwiegley showed some old and tiny extensions (edebug, redshank) part of his workflow. Very interesting to discover dark corners of the large emacs extensions space and how people solve problems their way.

seivan• 13 years ago

Hmm, I am probably missing something, but isn't Igor from Mary Shelley (Frankensteins assistant)?

Udo• 13 years ago

From the article:

"This really reminds me of Terry Pratchett’s Igor clan. I discovered this amiable race in The Fifth Elephant. Igors are a people inspired from the typical hunchbacked Igor archetype, but in Discworld, they are also self-modifiers. Their bodies consist of mixed and matched and patched and swapped body parts among other members of their clan, of scars and self-adjustements. They are infinitely self-improving, self-experimenting. They might end up with a botched job and have to hobble around for a few days, but in the end it’s always fixable.

And they lisp."

ColinWright• 13 years ago

Yes, you're missing something. You need to read some Terry Pratchett. There are several entry points to the canon, some better suited than others to different readers. The Igors first arrive in The Fifth Elephat, or possibly Thief Of Time.

As an entry point (but without the Igors (yet)) I recommend "Guards! Guards!", YMMV.

rbobby• 13 years ago

Small Gods is also a fun place to start.

InclinedPlane• 13 years ago

"Igor" as Dr. Frankenstein's assistant achieved prominence through Bela Lugosi's portrayal of the character "Ygor" in the film "The Ghost of Frankenstein". (No character named "Igor" appears in Mary Shelley's novel "Frankenstein: or the Modern Prometheus".)

"Igors" are a community of folks within the fictional "Discworld" universe created by author Terry Pratchet. Dr. Frankenstein's assistant is merely a lab assistant. Igors on Discworld are folks who remake themselves by way of transplants, as described in the article.

masklinn• 13 years ago

Hmm, I am probably missing something

You seem to have never read Pratchett, and should definitely fix that.

Pratchett often takes existing tropes, settings, historical and fictional characters, etc… and breaks, rearranges and/or reinvents them to make things more interesting and/or funnier.

In this case, he took Shelley's Igor (and hunchbacked assistants of a thousand films of the line) and made him into a clan, all called Igor. They're a clan of assistants, surgeons, bio-engineers and self-improvers, they're patched up because "what goeth around cometh around"[0], and with Igor it's parts. They'll exchange limbs, they'll replace eyes, etc… others and theirs both. They lithp for tradition and people's expectation (some of them regularly forget to lisp, or just can't seem to get the trick right) and have highly apparent stitches as something akin to clan markings (they've got dexterity enough for those not to be needed on patients).

The traditional funerals and wake of an Igor consist in other Igor swinging by and leaving with loot bags, with parts of the deceased inside (they'll generally make their parts's destinations known beforehand).

[0] the clan's full motto is "What goeth around, cometh around... or thtopth.": they will help anyone anytime at no charge, but if they have helped and provided a new spleen or replacement eyes they will come by and "rummage around" for healthy organs when the person dies. If they are turned around they will not make a fuss, but no Igor will come by the village ever again.

etfb6• 13 years ago

I'm a recovering Emacser, happy enough with less powerful but more modern text editors. It wasn't the program or the UI that finally did me in, but the community: I had a problem with how Emacs worked, I wanted to figure out a solution, so I asked on #emacs on Freenode and got nothing but abuse. I realised there's something about Emacs that attracts the sort of users I don't want to associate with: people who are smug, self-absorbed and utterly without empathy. Did I want to be one of them? No, I did not. Did I want to have to rely on them for help in my work and play? No, I did not. So I found a text editor that has sufficient extensibility and I installed that, and uninstalled all the emacsen on all my machines. And I felt a lot better afterward.

FatalBaboon2• 13 years ago

They probably tried to make a common point: do not give the solution. For a given specific issue, the most you should give is pointers.

For the function that solves your problem saves the day but knowing how to find any when needed solves a lifetime of problems. Pointers help to put you on the right track so you're not discouraged.

etfb6• 13 years ago

I was asking all the right questions -- is this possible, what hooks should I consider, what should I take into account to make sure that the stuff I add doesn't stamp all over other stuff. I'm a programmer with thirty years experience and twenty years with Emacs; I know this stuff.

Basically, they shut me down. The thing I was asking was contrary to the whole philosophy of Emacs. I had, they assured me, no right to ask it. I was an idiot for having the problem that I was seeking to solve. And nobody, they told me, had ever had the problem ever in all of history.

Were they right? Well, no, not even slightly. They were horribly, evilly wrong. But even if they had been right, their response was wrong. Their argument was "if you have this problem that can be fixed by a change to Emacs, change yourself". This, in the most extensible editor on the planet. It was like being told that my car's tendency to pull sharply to the left when passing another car was normal and expected and I should take care not to pass other cars.

etfb6• 13 years ago

A cynic's TL;DR:

Give a man a fish, he'll eat for a day. Teach a man to fish, he'll eat for a lifetime. And if you really hate the man, get RMS to design him a fishing rod.

to3m• 13 years ago

I don't know. For a given specific issue, I've actually found the solution pretty helpful!

And pointers can be given at the same time; there's no reason why an answer can't include both, as is most usually practical. It's fun to play the role of delphic oracle, but only as a joke that all concerned are in on, as it's terribly frustrating to be on the receiving end of it.

yen223• 13 years ago

And because of that, the Emacs community lost yet another potentially helpful member[0]. This here is an example of how toxic communities are formed. Once you reach a critical mass of abusive members, the community can only grow more toxic over time.

[0] I'm going to go ahead and assume that you aren't a smug, self-absorbed sociopath.

etfb6• 13 years ago

Well, not self-absorbed.

belorn2• 13 years ago

attracts the sort of users I don't want to associate with: people who are smug, self-absorbed and utterly without empathy.

I think you have just described the normal IRC experience for any software project in existence. IRC just tend to breed cliques and inside jokes, and the most common form of reply I have ever gotten while looking for help is "check the source code". Never mind that its a few thousands line of low level C, magic numbers and possible some assembler instructions.

etfb6• 13 years ago

My experience is otherwise. I've found the IRC groups for Python and PHP to be quite friendly. The one for Wordpress suffers a bit from "I don't know you, so I presume you're an idiot" but not to the same degree as the Emacs or Lisp ones. I think there's some interaction between IRC and Lisp that causes this sort of sociopathic behaviour in a small but loud subset of the community -- and the rest don't do enough to discourage it, which makes them all complicit.

riffraff2• 13 years ago

I think you are exxagerating, some places tend to become like that and some don't.

I found the python, ruby and perl channels very nice when I was learning the languages a decade ago or so, and by my occasional lurking they still seem to be.

Recently I was on #elm on freenode and it also was a nice place.

Cliques and inside jokes obviously are part of what a community _is_ but that doesn't necessarily translate to smugness and lack of empathy.

davexunit• 13 years ago

You sure seem bitter about something. Every time I've visited #emacs for help I have left with my problems resolved.

dontmakemelaugh2• 13 years ago

Weird experience you had there. I have been to many IRC channels on Freenode and found pretty much all of them abusive and unfriendly with the big exception being #emacs, where people seem to be more open and tolerant, also very helpful.

I would say you had bad luck and met an ass (which could happen as anyone can go to #emacs and rant around)

justinhj2• 13 years ago

Stackoverflow is a good place to get fast answers to emacs questions. By the way I use IDE's like PHP Storm, Intelli-J and Eclipse in conjunction with emacs. Switching between the two depending on the task. Sorry you decided emacs wasn't for you but it doesn't have to be an either/or. Use the best tool for the job at hand.

klibertp• 13 years ago

Well, http://c2.com/cgi/wiki?SmugLispWeenie had to go somewhere and what place would be better for them than Emacs? ;)

Actually I had exactly the same feeling when I started using Emacs: the very first thread on some newsgroup I remember reading was about moving lines up and down, like in sublime(?) with M-S-<up>/<down>. The poor guy who dared to ask was immediately told that this is "not the emacs way", that there are many better ways to do this and so on. Ofc, halfway through the thread I found working code which implemented this feature, but the impression it made was not very good.

But Emacs architecture and it's consequences, like extensibility and customizability, and giant heaps of free, working code are enough for me to just ignore people like this. Or rather to ignore most Emacs related discussions. It's good that Emacs makes it easy to just stay away from other people: all the docs, and the source, are there in the editor itself, so if you don't mind spending a bit of time you can figure anything on your own. Which is what I do and what I like doing.

But I certainly do understand your feelings in this matter and think they are justified.

JackMorgan4• 13 years ago

Amusingly, I asked that same question on SO, and got a couple very polite suggestions within hours.

snogglethorpe• 13 years ago

Er, I drop in on #emacs regularly, and people there are generally very nice, nothing like you describe.

Maybe you tried at the wrong moment and happened to get the attention of the rare jerk or two, or maybe you were doing something that managed to annoy people (you sometimes see people asking questions in very overbearing and demanding manner ... "Give me the answer now!!" etc).

Indeed, I'd say #emacs is actually a lot better than typical tech channels / mailing lists etc, and the stereotypical techy "attitude" is largely absent there. If anything the biggest problem with it is not attitude, it's that 95% of the discussion on #emacs is not about Emacs (it's kinda ... laid back), and your question might get lost in the noise...

dontmakemelaugh2• 13 years ago

so I asked on #emacs on Freenode and got nothing but abuse.

I checked my logs. It was one guy that was abusive. Everyone else was friendly and helpful.

So you doom the whole Emacs community because of one user on #emacs the one time you were there?

stiff2• 13 years ago

In common understanding of emacs, its use of lisp recieves perhaps too much attention, while its overall wonderful architecture is underappreciated. Emacs isnt just an editor with embedded lisp, its more a vm for bootstrapping editors. You could do an emacs with python, but the hard part is providing an environment where the extensions dont interfere with the user input loop, with buffer redisplay etc., while still staying easy to write. The emacs buffer-based async handling of external processes is a masterpiece of software engineering, much better than things like unix pipes. Doing extension languages for interactive programs is much harder than it seems at first, and emacs is a prime example of doing it right.

leephillips2• 13 years ago

"The emacs buffer-based async handling of external processes is a masterpiece of software engineering, much better than things like unix pipes."

This sounds intriguing. Do you have a pointer to something I could read that might expand on what you're saying here? (Aside from the emacs source.)

Amusing coincidence: the only Pratchet book I've read is The Fifth Elephant.

mr_luc• 13 years ago

Seconded! Like a lot of Emacs users, sure, I love Lisp. But I don't really understand how it's architected.

Sure, I understand that there is this abstraction of a Buffer. But it's quite abstract. I'd love to know what's happening under the hood.

I think a blog post that even gave a 37signals-blog-post-sized expansion of the grandparent's comment would probably be frontpaged on HN.

thirdtruck3• 13 years ago

Just wanted to recommend reading more Pratchett. :) I bought a couple more novels last week and couldn't help but finish one (Equal Rites) less than twenty four hours later.

stiff2• 13 years ago

I will try to explain. When I came to emacs as a user, a "buffer" seemed just a weird way of saying "tab" without displaying actual tabs. The word choice only started making more sense once I wrote non-trivial amounts of emacslisp. The buffer is the fundamental emacs data structure, like the file is the fundamental unix data structure, so it's really important to understand it well.

The definition is really simple: a buffer is just a bunch of text from some unknown source, but in fact it is a very powerful abstraction, for two reasons. First, every time you do something in Emacs when simply editing files, you are really executing emacslisp functions on the buffer that is currently displayed. A lot of things you learn in Emacs can be used in three ways: interactively in editing sessions, when automating editing tasks with emacslisp, and finally when doing programming in general, even when it has nothing to do with editing files.

Second, a buffer can represent anything, it can of course contain the text of a file, but also of only fragments of a file, or a directory file listing, and, what's really great, Emacs binds TCP/FTP/HTTP/... network connections and external processes to buffers as well, allowing asynchronous streaming of incoming data into buffers, so that a emacslisp callback is called every time new text arrives from the process or socket, you can transform it as you wish and insert into the buffer the part to be shown to the user or kept for future processing. Then there are lisp primitives implemented in C like save-excursion which let you execute functions on buffer off-screen, so the same commands that are used for editing can be used for processing HTTP requests or grep output without the user noticing the cursor jumping back and forth or anything of this kind. So, when I am processing HTTP requests in Emacs, I use the same commands I sometimes use in interactive editing sessions, for example I can use re-search-forward to check if the headers were sent completely already and to get number of bytes they contain (the location in the buffer of the end of the headers, in other words). A lot of the weird emacs word like point, mark etc. that seem like anachronistic words for interface elements really are powerful abstractions that apply as much to programming as to the interactive editing.

Then there is a lot of other stuff that makes this yet more powerful, you can have buffer-local variables, timers that check buffer input periodically, transaction queues for those asynchronous processes, modes that define buffer-specific key-bindings, menus and behaviours etc., it goes on an on. It's a lot like node.js or other asynchronous networking stacks. There is also lot of magic that makes all this work concurrently without Emacs having implemented threads, and that makes it not interfere with the user interface.

A lot of the cool things Emacs does follows from this architecture, like the SLIME package for interacting with Common Lisp interpreters (local or remote), Dired for editing directory contents, Tramp for editing files on remote servers, Comint for running interactive processes of various kind inside Emacs etc. It's a really great lesson in how naturally features flow out of powerful design ideas.

As for resources, I learnt by reading the GNU Emacs Lisp Reference [1], and have done a lot of M-x describe-function and source code reading in the process of writing some elisp more sophisticated than just small editing helpers. E.g. the process stuff is described here:

http://www.gnu.org/software/emacs/manual/html_node/elisp/Pro...

ehudla• 13 years ago

The classic Emacs architecture paper: https://www.gnu.org/software/emacs/emacs-paper.html

bachback• 13 years ago

beautiful post. the learning curve for getting into elisp land is steep. we need something like emacs in the future, something to evolve the emacs model as the self-evolutionary programmer's environment. the 1M LOC code is much too bloated for the modern age. it should be more tightly integrated with bash/linux/git, and have better exploration methods. i am not sure why nobody is working on this, besides lighttable. perhaps that is the problem with emacs/lisp. finding the valuable stuff out there takes time and is not build around sharing.

progman• 13 years ago

the 1M LOC code is much too bloated for the modern age.

Why reinvent the wheel? Emacs works well enough, and computers are getting faster every generation. Many editors appeared, they all had the chance to make Emacs obsolete but they ALL failed. Every editor could challenge Emacs but obviously it is not so easy to compete.

I use Emacs for decades now because of its extreme stability (almost same version among many operationg systems) and extreme reliability (not a single crash ever). I have tested new editors from time to time but Emacs is still superior.

These are some raasons why Emacs is still alive today despite its ancient source code. Another reason is that Emacs depends on Lisp which is much more stable than modern standards like Python, Javascript and HTML5 which change pretty fast and make it difficult to keep big software up to date. For instance, imagine an Emacs like editor written in Python 2. Now the codebase would have to be changed to Python 3, and possibly soon to Python 4.

By the way, Haskell provides excellent support for DSLs. So it should be no problem to develop a tool which converts Haskell plugins (or Python or whatever) to Emacs elisp.

chrisdone• 13 years ago

By the way, Haskell provides excellent support for DSLs. So it should be no problem to develop a tool which converts Haskell plugins (or Python or whatever) to Emacs elisp.

I've been thinking about adding Haskell as an additional language for Emacs alongside Elisp. It would be nice to be able to use both.

dbalan• 13 years ago

one thing I struggle with emacs is that I can't find a place which documents the emacs way of doing things. Emacs has multitude of features, there are just too many to master, yet even to know that they exist.

One example would be rectangle select http://www.gnu.org/software/emacs/manual/html_node/emacs/Rec..., I absolutely love them - but till one of colleague introduced them to me, I had no idea they existed.

wglb• 13 years ago

I often go to http://www.emacswiki.org/.

mickeyp2• 13 years ago

I try to write long articles explaining Emacs workflow over at http://www.masteringemacs.org. You may be interested in my latest post on discover.el.

ttuominen2• 13 years ago

I must say your blog seems like a an excellent resource, thanks for what you are doing!

ttuominen2• 13 years ago

I've found emacs-fu useful. http://emacs-fu.blogspot.fi/

mathattack• 13 years ago

Perhaps I'm nerdly enough to go to the Terry Pratchett part of the story first.

This really reminds me of Terry Pratchett’s Igor clan. I discovered this amiable race in The Fifth Elephant. Igors are a people inspired from the typical hunchbacked Igor archetype, but in Discworld, they are also self-modifiers. Their bodies consist of mixed and matched and patched and swapped body parts among other members of their clan, of scars and self-adjustements. They are infinitely self-improving, self-experimenting. They might end up with a botched job and have to hobble around for a few days, but in the end it’s always fixable.

And they lisp.

Pratchett litters his books with lots of unexpected gems - I view it like Easter Eggs for books. Could he have possibly added the lisp on purpose???

aetherson4• 13 years ago

I'll take issue with this claim: "Work environments are a very personal thing. They exist to serve only one person: you. Me-me-me is a winning attitude when dealing with your environment."

I think it's considerably more important to have a (basically good) work environment in which your colleagues can sit down and use fluently than to have one that's absolutely optimized to your individual tastes.

wting• 13 years ago

Do you share workstations with your co-workers or do significant amounts of pair programming?

I'm not sure why my work environment should be optimized for a <1% use case.

aetherson4• 13 years ago

I do significant amounts of pair programming. But even more so, I don't think that your coworkers using your workstation should be a <1% use case even if you never pair.

My contention is that:

1. Work environments -- including ones that don't formally pair -- should be highly collaborative.

2. It's typically massively less efficient to help someone past a block or communicate a new coding technique via telling them what to do rather than doing it. Much less anything even remotely iterative, where you need to, say, write some code, look at some output, and write some more code.

3. The difference between "a basically good development environment" and "a development environment that is specifically optimized for just specifically you" is actually quite small. There's no real need to sacrifice much of anything in order to get an environment optimized specifically for you.

JackMorgan4• 13 years ago

If you pair a majority of the time, sure, make a standardized workstation with your team. My team uses viemu in VS, which the rest of our office detests, but hey, we are the ones pairing 99% of the time.

When I am not pairing for the majority, I setup my machine to my tastes, and simply install a "default" editor for the few times someone else actually needs to type on my machine. Emacs and IDEA both have good ways to revert everything to defaults temporarily.

I do not believe, however, that a perfectly customized setup has only small gains. For example, consider two tools that I have never seen as defaults in any editor or IDE: rainbow parens/brackets and paredit mode. Rainbow parens just highlights pairs: http://stevelosh.com/media/images/blog/2010/09/rainbow.png

And here is a short minute paredit mode explanation: http://www.youtube.com/watch?v=D6h5dFyyUX0

When actually editing code, those two tools save me several hundred keystrokes an hour. And those are just the first two tools I thought to use as an example out of the entire toolbox that is emacs.

If I was to now give up just those two tools, I would be sentencing myself to the mental equivalent of tying five pound weights to my legs for the marathon that is the rest of my programming career. Why would I intentionally require myself to type more keys per hour to do the same editing, rather than just learning a faster way to edit? This is, obviously, also my argument for learning the vim editing system (which I also use in emacs).

aetherson4• 13 years ago

I'm not advocating accepting an editor or IDE default, I'm advocating a standardized environment for a company. If rainbow parens are super-useful, then they can be super-useful for everybody.

And that's another thing that a standardized environment does: it gets techniques out there for the whole team. Because honestly I don't really believe that all that many people are truly getting their environments perfectly optimized for themselves. I think that most people in a shop where everyone does their own thing end up with high un-optimized environments.

Good environments for all, that everyone can use is better than perfect environments for a few, and mediocre environments for most, plus lack of interoperability.

Emacs users are like Terry Pratchett’s Igors

Related Stories