Emacs users are like Terry Pratchett’s Igors
chrisdone.com
chrisdone.com
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.
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.
- Nightwatch: Great idea, fantastically written
- Going Postal: Great book for everybody who reads HN. Great characters, storyline, and fantasy meets hacking.
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...
1) intial emacs setup: it feels really tricky to just get basic editor sanity configured (auto-indent, syntax highlighting, etc.)
2) I worry that by using evil mode, I lose out on a lot of the goodness of emacs major and minor mode's. Do you remap everything to be more vi-ish for each mode that you use? I guess that is fine but the transition just seems daunting.
I haven't seen any lost functionality by using evil; modes that define bindings continue to work, and the usual C-x/C-c/M-x/whatever works fine with evil. There is the odd major mode that doesn't work with evil out of the box (usually if it redefines j/k) but most have no problems. You can still use most (all?) regular Emacs movement commands with evil as well.
IMHO, Evil Mode makes to use emacs doable OTOH, the fact that there are so much extensions and possibilities under the hood makes to use emacs mandatory! :P
I'm still trying to figure out the emacs portions of emacs. I don't have the work flow quite right; things like buffer management, saving sessions, shell in emacs, etc.
1.http://www.emacswiki.org/emacs/InteractivelyDoThings
2. http://www.emacswiki.org/emacs/DeskTop
3. For 3 I just use built in shell-mode, but what is really neat is saving your shell session to a file "C-x C-w" every so often. Then if you reboot or crash or whatever, emacs-desktop will bring back all your open files and all your shells. I usually have 3, regular bash, a sql session, and maybe an ssh session to somewhere, all with a full record of what I've done, sometimes going back months.
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?
Oblig reference to classic essay on that topic:
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.
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.
> 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.
> 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.
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.
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.
[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.
- 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.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.
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.
I didn't just develop my contempt for the community all in one go. I had to WORK at it!
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.
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.
[0] I'm going to go ahead and assume that you aren't a smug, self-absorbed sociopath.
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.
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.
I have used the python django IRC channel when developing some sites, and "check the source" has been the most common answer when I run into walls. Usefully, the questions I make receives some basic "see if the documentation say something" which I had of course already done, and then after a few hours of silence, someone says "check the source". This was a 3-4 years ago so maybe it has been improved?
It is true that I don't go to an IRC channel except when documentation and extensive testing has failed to produce an answer. Maybe the smugness and lack of empathy is more a product of asking questions that are not easily answered?
I would say you had bad luck and met an ass (which could happen as anyone can go to #emacs and rant around)
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.
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...
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?
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.
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???
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.
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.
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.
I'm not sure why my work environment should be optimized for a <1% use case.
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.
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).
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.
"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."
As an entry point (but without the Igors (yet)) I recommend "Guards! Guards!", YMMV.
"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.
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.