Erik Naggum on Emacs and muscle memory(groups.google.com)
groups.google.com
Erik Naggum on Emacs and muscle memory
http://groups.google.com/group/comp.emacs/msg/821a0f04bab91864?dmode=source&output=gplain
6 comments
>Text editing in and of itself has no value.
I just don't know what to make of that. It's true, but only in an incredibly over-technical sense. Text-editing is one of the primary forces that drives the world. Pen or keyboard or voice to speech, text is primary.
Yes, of course, the meaning behind the text is more important. But the meaning doesn't appear at all without some means of creating the text. It's like saying that the teeth are not important, it's the food. You can't eat the food without teeth.
I just don't know what to make of that. It's true, but only in an incredibly over-technical sense. Text-editing is one of the primary forces that drives the world. Pen or keyboard or voice to speech, text is primary.
Yes, of course, the meaning behind the text is more important. But the meaning doesn't appear at all without some means of creating the text. It's like saying that the teeth are not important, it's the food. You can't eat the food without teeth.
I'm saying that the meaning of the text - be it prose, poetry or code - is all that is important. Text editors are tools, like paintbrushes and screwdrivers. They only important or valuable to the extent that they enable us to create stuff of actual value.
You can go down the route of text editing as art, like that Vi Golf concept that was floating around. And a well-made tool is indeed valuable and beautiful to behold. Nevertheless, I maintain that a text editor is strictly as important as the text it is used to create.
You can go down the route of text editing as art, like that Vi Golf concept that was floating around. And a well-made tool is indeed valuable and beautiful to behold. Nevertheless, I maintain that a text editor is strictly as important as the text it is used to create.
Honest question: Have you ever witnessed an emacs or vi master at work? Have you ever had the experience of watching one of those guys push some keys on the keyboard and then ask yourself how the bloody hell they just did that complicated manipulation in two seconds, when it would have taken you 45? That stuff adds up, more than linearly because they'll do things you wouldn't even consider due to effort. (You won't even consciously decide not to do them, you won't even consider them as a possible option.)
(The other day somebody linked a site that extracts the top 100 comments for any HN user. Somebody else started creating links to all the users on the leaderboard. I happened to catch them halfway through linkifying the people on the user board. You never would have caught me halfway through such a task, because I would have used an emacs macro to linkify one, then repeat it 99 times as quickly as I please. And I'm not very good with emacs. Many other tools can do this too, of course.)
Be sure you actually know what tool mastery looks like before you downplay the importance of tool mastery. Sure, what matters is results, but tools profoundly and inescapably influence the results you get, so while "all that matters is results" is a true statement on the surface, the actual claim being made underneath about the irrelevance of tools is deeply, deeply false.
(The other day somebody linked a site that extracts the top 100 comments for any HN user. Somebody else started creating links to all the users on the leaderboard. I happened to catch them halfway through linkifying the people on the user board. You never would have caught me halfway through such a task, because I would have used an emacs macro to linkify one, then repeat it 99 times as quickly as I please. And I'm not very good with emacs. Many other tools can do this too, of course.)
Be sure you actually know what tool mastery looks like before you downplay the importance of tool mastery. Sure, what matters is results, but tools profoundly and inescapably influence the results you get, so while "all that matters is results" is a true statement on the surface, the actual claim being made underneath about the irrelevance of tools is deeply, deeply false.
This still isn't an argument against using powerful text editors. If you're doing carpentry, both a hand-driver and a power-drill can drive screws, but one will get the job done faster. The advantage is, of course, situational; but power is especially important when refactoring and modifying existing text/code where being able to automate repetitive changes can speed things up significantly.
Of course it isn't an argument against powerful text editors. It's an argument against obtuse text editors.
> Nevertheless, I maintain that a text editor is strictly as important as the text it is used to create.
Absolutely. And what is the importance of that text to you? To me it is both my passion and my livelihood. In aggregate it's clearly #2 only to my family.
Absolutely. And what is the importance of that text to you? To me it is both my passion and my livelihood. In aggregate it's clearly #2 only to my family.
> Tools should get the hell out of the way of their users.
I think this was precisely the point that Naggum was making. Basically his thesis is that emacs is hard to learn, but eventually you can do amazing things without thinking about it. A novice tool on the other hand never makes anything but the most trivial task easy, so though it doesn't get in the way of a beginner, it never gets out of the way of the expert.
You can argue about how true this is, and debate the merits of the modern crop of text editors that make better use of GUI elements, etc; but I still found the argument he makes to be compelling and worthy of consideration even if we ultimately disagree. He didn't just invoke a religious argument about the superiority of his tool of choice—he drew up a meaningful analogy to what it means to devote the time and obsession to perfecting one's art.
I think this was precisely the point that Naggum was making. Basically his thesis is that emacs is hard to learn, but eventually you can do amazing things without thinking about it. A novice tool on the other hand never makes anything but the most trivial task easy, so though it doesn't get in the way of a beginner, it never gets out of the way of the expert.
You can argue about how true this is, and debate the merits of the modern crop of text editors that make better use of GUI elements, etc; but I still found the argument he makes to be compelling and worthy of consideration even if we ultimately disagree. He didn't just invoke a religious argument about the superiority of his tool of choice—he drew up a meaningful analogy to what it means to devote the time and obsession to perfecting one's art.
> A novice tool never makes anything but the most trivial task easy
I disagree with this statement in the strongest terms.
I disagree with this statement in the strongest terms.
Text editing is something that consumes so much of a programmer's time that ease of learning is only relevant if you're switching every couple of months. If I was forced to switch from my current editor to a new one, I would honestly not give two shits how easy it was to learn. Why would I care how bad the first month would be? I'd be using it for many years to come. (If I couldn't count on that, it would be the wrong editor anyway.) The only kind of text editor that can tempt me to use it for a few months knowing I'll never be completely comfortable with it is a full-blown IDE with enough functionality to make up for the awkwardness of not being able to slice and dice text efficiently.
Besides, what does it mean for a novice to be able to use an editor right out of the gate? Will a novice know the keystrokes to jump to the beginning of a line, jump to the end of a line, indent the current line, forward incremental search, backwards incremental search, delete to the end of the line, regex search and replace, display and hide the list of open windows, jump to the previous window, jump to an open window by filename, reload the current file from disk, diff two files, run Make (or Maven or what-not), or do any of the others things that a programmer does dozens of times a day when he's writing code? Obviously he won't, and he'll be working a little slower until he figures all those things out (or, for beginning and end of line, he'll be learning where the Home and End keys are on each different keyboard he uses.)
Even if you know how to cut and paste in a new editor, you still don't know 10% of what you need to know to use it productively.
Besides, what does it mean for a novice to be able to use an editor right out of the gate? Will a novice know the keystrokes to jump to the beginning of a line, jump to the end of a line, indent the current line, forward incremental search, backwards incremental search, delete to the end of the line, regex search and replace, display and hide the list of open windows, jump to the previous window, jump to an open window by filename, reload the current file from disk, diff two files, run Make (or Maven or what-not), or do any of the others things that a programmer does dozens of times a day when he's writing code? Obviously he won't, and he'll be working a little slower until he figures all those things out (or, for beginning and end of line, he'll be learning where the Home and End keys are on each different keyboard he uses.)
Even if you know how to cut and paste in a new editor, you still don't know 10% of what you need to know to use it productively.
This is incredibly pedantic, and yet, fails to point out parts of the problem. Or maybe the guy just wanted to flatter himself in saying that people that does not want to learn how to use a text editor (can't refrain the old joke : or the editor it lacks) are necessarily stupid morons that can't have a proper opinion on the subject.
I tend to orient my tool choice to one that will require the least effort and still allow to achieve the task properly, even though the least effort might be, sometimes, a huge effort. I concentrate on the least effort for a simple reason : if a better tool I could not imagine comes out, I will minimize the hard learned knowledge I'll have to discard. Putting effort in something gives you momentum, you won't let it go easily, because you make the balance difficult to evaluate. Jump between easy to switch solutions, and you are guaranteed to mostly enjoy the best tools (for its class at least) you can get.
I tend to orient my tool choice to one that will require the least effort and still allow to achieve the task properly, even though the least effort might be, sometimes, a huge effort. I concentrate on the least effort for a simple reason : if a better tool I could not imagine comes out, I will minimize the hard learned knowledge I'll have to discard. Putting effort in something gives you momentum, you won't let it go easily, because you make the balance difficult to evaluate. Jump between easy to switch solutions, and you are guaranteed to mostly enjoy the best tools (for its class at least) you can get.
> This is incredibly pedantic,
Agreed, but...
> and yet, fails to point out parts of the problem.
Which parts? You don't go on to say.
> Or maybe the guy just wanted to flatter himself in saying that people that does not want to learn how to use a text editor (can't refrain the old joke : or the editor it lacks) are necessarily stupid morons that can't have a proper opinion on the subject.
This is not the impression I got. Rather, he was expressing frustration at the concept of "intuitive" or "novice-friendly" software, emphasized by the commercial software industry, that saves initial learning time at the expense of training people to do mindless tasks over and over, instead of learning to use their computers more efficiently. I think he was saying that it is unfortunate that, due to the emphasis on this concept by commercial software, there is now a (perhaps large) segment of the population that won't accept any other kind of interface; and he was saying that Emacs development should probably not target these people.
Whether the expression was pedantic or not, this seems like a reasonable thing to be frustrated about, and a reasonable conclusion to draw.
Agreed, but...
> and yet, fails to point out parts of the problem.
Which parts? You don't go on to say.
> Or maybe the guy just wanted to flatter himself in saying that people that does not want to learn how to use a text editor (can't refrain the old joke : or the editor it lacks) are necessarily stupid morons that can't have a proper opinion on the subject.
This is not the impression I got. Rather, he was expressing frustration at the concept of "intuitive" or "novice-friendly" software, emphasized by the commercial software industry, that saves initial learning time at the expense of training people to do mindless tasks over and over, instead of learning to use their computers more efficiently. I think he was saying that it is unfortunate that, due to the emphasis on this concept by commercial software, there is now a (perhaps large) segment of the population that won't accept any other kind of interface; and he was saying that Emacs development should probably not target these people.
Whether the expression was pedantic or not, this seems like a reasonable thing to be frustrated about, and a reasonable conclusion to draw.
Sorry for the late response.
I'll just point out one part of your comment, and use it to illustrate what I wanted to say.
> instead of learning to use their computers more efficiently
What i wanted to say is just that, you might be just more efficient by avoiding spending a lot of time learning complex tool, and concentrate on simple one, with the hope that the loop of improvements of your tools will compensate the loss of productivity due to a non-optimum usage. The general idea is, if you spend of lot of time to learn a tool, you are betting that it will worth it on the long run, at the hypothetical cost of losing the time use to acquire that knowledge we you finally decide that an alternative is a better option - with the added momentum you'll have before quiting your hard learned cherished tool. On the contrary, when learning quickly, less efficient, simple tools you bet on the future evolution of that tools : you will gain in productivity on the later tools that might pop up, ones that you will also learn quickly, but will be a bit more efficient.
While I would completely agree with the author on the fact that some people will refuse to learn what would be more efficient tool on the long run, he fails to recognize that a chain of more simple tools, that improves over times and allow quick adaptation and optimization can be in some circumstances be an approach that leads to the exact same efficiency.
This is why I complain that the article was pedantic, because it states too strongly that mastering complex software is the way to go, whereas, while there is a regrettable tendency to discard complex tools too quickly, diving in them might be not always as wise as it could seem.
I'll just point out one part of your comment, and use it to illustrate what I wanted to say.
> instead of learning to use their computers more efficiently
What i wanted to say is just that, you might be just more efficient by avoiding spending a lot of time learning complex tool, and concentrate on simple one, with the hope that the loop of improvements of your tools will compensate the loss of productivity due to a non-optimum usage. The general idea is, if you spend of lot of time to learn a tool, you are betting that it will worth it on the long run, at the hypothetical cost of losing the time use to acquire that knowledge we you finally decide that an alternative is a better option - with the added momentum you'll have before quiting your hard learned cherished tool. On the contrary, when learning quickly, less efficient, simple tools you bet on the future evolution of that tools : you will gain in productivity on the later tools that might pop up, ones that you will also learn quickly, but will be a bit more efficient.
While I would completely agree with the author on the fact that some people will refuse to learn what would be more efficient tool on the long run, he fails to recognize that a chain of more simple tools, that improves over times and allow quick adaptation and optimization can be in some circumstances be an approach that leads to the exact same efficiency.
This is why I complain that the article was pedantic, because it states too strongly that mastering complex software is the way to go, whereas, while there is a regrettable tendency to discard complex tools too quickly, diving in them might be not always as wise as it could seem.
Your second paragraph is interesting. However, the problem I see is that some tools are better based upon your skill. When you have no skill, Emacs is almost useless. When you have great skill, Emacs is unimaginably useful. This is true for many traditional Unix tools.
This is true of all tools.
Erik Naggum is/was the quintessential pedant. He has rants a lot more entertaining than this one.
What is with this guy's aversion to uppercase?
The aversion is restricted to capitalizing the initial word of a sentence.
It's easier to rearrange words in a sentence and join or split sentences in a paragraph if the first word of a sentence is not capitalized.
Capitalizing the first word of a sentence can also lose information.
It's also helpful to identify people who focus on the trivial.
It's easier to rearrange words in a sentence and join or split sentences in a paragraph if the first word of a sentence is not capitalized.
Capitalizing the first word of a sentence can also lose information.
It's also helpful to identify people who focus on the trivial.
Except it isn't trivial; it materially damaged the ease with which I could read the essay.
As a long-time English reader, I've internalized the idea that there will be a capital letter at the beginning of a sentence. So when it's lacking, especially when the beginning of a sentence corresponds to a newline as in the beginnings of paragraphs in this essay, my immediate mental response is to assume that I've overshot the sentence's beginning, and immediately to backtrack to find it.
Overriding this behavior takes mental effort which detracts from the ease with which I can read. Making it harder for your readers to consume your ideas is hardly a trivial issue.
As a long-time English reader, I've internalized the idea that there will be a capital letter at the beginning of a sentence. So when it's lacking, especially when the beginning of a sentence corresponds to a newline as in the beginnings of paragraphs in this essay, my immediate mental response is to assume that I've overshot the sentence's beginning, and immediately to backtrack to find it.
Overriding this behavior takes mental effort which detracts from the ease with which I can read. Making it harder for your readers to consume your ideas is hardly a trivial issue.
For Emacs users:
(defun capitalize-naggum () "Capitalizes text written in Erik Naggum's annoying no-caps style" (interactive) (save-excursion (goto-char (point-min)) (aux-naggum (point))))
(defun aux-naggum (current-point) "Recursively capitalize the buffer, moving sentence to sentence. Valid punctuation symbols are [.?!]" (re-search-forward "[a-z]" nil 0 nil) (if (= current-point (point)) t (capitalize-word -1) (re-search-forward "[.!?]") (aux-naggum (point))))
(defun capitalize-naggum () "Capitalizes text written in Erik Naggum's annoying no-caps style" (interactive) (save-excursion (goto-char (point-min)) (aux-naggum (point))))
(defun aux-naggum (current-point) "Recursively capitalize the buffer, moving sentence to sentence. Valid punctuation symbols are [.?!]" (re-search-forward "[a-z]" nil 0 nil) (if (= current-point (point)) t (capitalize-word -1) (re-search-forward "[.!?]") (aux-naggum (point))))
[deleted]
e. e. cummings might have a thing or two to say about a thing or two regarding the use of capitalization. It can be worthwhile to overlook or adapt to someone's stylistic peccadilloes if the ideas they have are interesting and useful.
Not that I'm casting judgment in regards to that in what either Naggum or cummings wrote! ;-)
Not that I'm casting judgment in regards to that in what either Naggum or cummings wrote! ;-)
It wouldn't take that many lines of elisp to capitalize first word in sentence before gnus burped it out over NNTP.
Capitalizing the first word of a sentence can also lose information.
I've never heard this, but are you talking about proper nouns that override regular words?
It's also helpful to identify people who focus on the trivial.
Would you say the same thing about txt spk, or does that cross the line for you?
edit: s/pronouns/proper nouns/
I've never heard this, but are you talking about proper nouns that override regular words?
It's also helpful to identify people who focus on the trivial.
Would you say the same thing about txt spk, or does that cross the line for you?
edit: s/pronouns/proper nouns/
> Capitalizing the first word of a sentence can also lose information.
Only if you are using a lousy keyboard layout for your language. I'm a native French speaker, and my layout (Bépo) let me type ÉÈÊÀÆŒ without having to remember any weird combination.
I can't think of significant loss of information besides diacritics.
Only if you are using a lousy keyboard layout for your language. I'm a native French speaker, and my layout (Bépo) let me type ÉÈÊÀÆŒ without having to remember any weird combination.
I can't think of significant loss of information besides diacritics.
In English, it can make a big difference in meaning if something is a proper noun or not.
Yeah, I guess he wasn't concerned about putting any effort into making it easy for others to read his thoughts.
sigh
Written text is supposed to be written to be parsed by humans. Why do people forget that?
sigh
Written text is supposed to be written to be parsed by humans. Why do people forget that?
He's also inconsistent. He capitalizes 'I' and Emacs and Lisp (among other things).
I remember a study that said people read based on shapes of words, particularly ascenders, descenders and edges (i.e., first and last letters). Does capitalizing the first letter of the sentence make a difference? If it does, do people that read languages like German which has more capitalization (but the same script) adapt to it?
I remember a study that said people read based on shapes of words, particularly ascenders, descenders and edges (i.e., first and last letters). Does capitalizing the first letter of the sentence make a difference? If it does, do people that read languages like German which has more capitalization (but the same script) adapt to it?
> He's also inconsistent. He capitalizes 'I' and Emacs and Lisp (among other things).
No, you're missing the point.
Naggum didn't eschew all capital letters, only where they led to loss of information (ie. failure to separate common and proper nouns).
Emacs and Lisp are proper nouns and therefore capitalized. Common nouns that happen to start a sentence are not.
No, you're missing the point.
Naggum didn't eschew all capital letters, only where they led to loss of information (ie. failure to separate common and proper nouns).
Emacs and Lisp are proper nouns and therefore capitalized. Common nouns that happen to start a sentence are not.
How does a German adapt? Poorly. I nearly stopped reading because of that.
It freakes out my wetware text parser to have two spaces before punctuation and no capitalization at the beginning of sentences. At least he did not put punctuation inside quotes...
It freakes out my wetware text parser to have two spaces before punctuation and no capitalization at the beginning of sentences. At least he did not put punctuation inside quotes...
It's funny, because his capitalization and punctuation are his conscious decisions he wrote about quite a few times. He said it is easy to programmatically upcase first words of the sentences, but it is no easy to do it the other way, without losing meaning. Sentences without first word capitalized are also easier to manipulate.
I personally have no problem with reading text written in a such way.
I personally have no problem with reading text written in a such way.
Naggum was one of the net's all-time greatest cranks. He almost singlehandedly turned comp.lang.lisp into a minefield.
Blogs and Twitter killed the amazing Usenet rants.
?!?
The rants are still there. They just moved. Or did Usenet influence its users into writing thoughtful rants in ways that blogs and agregators don't? I never used Usenet, but this seems unlikely.
The rants are still there. They just moved. Or did Usenet influence its users into writing thoughtful rants in ways that blogs and agregators don't? I never used Usenet, but this seems unlikely.
Great article even if it was '97'. And I found emacs easy to use after: C-h t
Yes, but actually typing it is beyond the ability of most users: you have to read the presentation screen before hitting a key, and you have to guess that "C" means "the control key".
Sigh. The first (clickable!) item on the launch screen of the editor is "Emacs Tutorial". The first paragraph displayed in the tutorial after you select (with the mouse!) that item is contains:
C-<chr> means hold the CONTROL key while typing the character <chr> Thus, C-f would be: hold the CONTROL key and type f.
I'm not going to sit here and tell you that emacs is "easy" to learn (seriously: getting truly good at it will take months at least). But don't pretend that the documentation is hard to read. It's just documentation.
C-<chr> means hold the CONTROL key while typing the character <chr> Thus, C-f would be: hold the CONTROL key and type f.
I'm not going to sit here and tell you that emacs is "easy" to learn (seriously: getting truly good at it will take months at least). But don't pretend that the documentation is hard to read. It's just documentation.
First, Oops.
Second, I didn't want to say that it was difficult, but that many people behave like morons.
Second, I didn't want to say that it was difficult, but that many people behave like morons.
reminds me of QuickSilver talking about wu wei, and seems fairly accurate--the sequence "tap Command, pause about a quarter second, type "S", hit Space" for launching Safari feels a lot like "lean towards where you want to go" does on a bike (or maybe "steer one way and lean the other to make a tight turn without leaning the bike over as far", a more advanced technique).
Just because it used to be extremely painful to become a towering expert at text editing doesn't mean it should continue to be so. It's not like riding a bicycle-- text editing actually is easy. Or at least, it can be made easy, and there is no argument for keeping it difficult.
Remember, text editing in and of itself is of no value. Tools should get the hell out of the way of their users.