
Learn Emacs in Ten Years - pw
http://edward.oconnor.cx/2009/07/learn-emacs-in-ten-years
======
wglb
I like the ten year rule. I have a similar rule for cars--it takes about one
year for a driver to completely master the peculiarities of a new car--its
handling, judging exactly where the tires are relative to curves, potholes,
how well the mirrors tell you when to stop backing up.

But I have been using emacs for way more than ten years daily and still have
much to learn.

Yes, I can imagine that you can learn vi in a shorter time, but I know very
little about it. I actually know more about 'ed' than I do vi.

One (strenuous) exercise is to write a full, complete tutorial for a language.
Explain it to your grandmother, for example. That will get you there quicker.
And you will learn things about the product that you would not otherwise know.

Another exercise to completely learn a language is to write a compiler for it.
This will flush out the corners of the language for you.

But these are admittedly a bit extreme methods.

I agree that it is worthwhile to master your tools.

~~~
mahmud
_Another exercise to completely learn a language is to write a compiler for
it. This will flush out the corners of the language for you._

Warning, there is a strong tendency to write a compiler for the language as
_you_ understand it, not as it is. The surface structure of the language, it's
syntax, can be mastered by reading its grammar, and the kinks ironed out by
actually implementing a lexer/parser for it.

However, it's deep structure, the semantics and evaluation are only understood
through rigorous mathematical semantic models, or at least through implicit
understanding after 10 years of use. At least for sophisticated languages.

A previous knowledge of other superior languages will corrupt your current
attempt to understand an inferiour language. To give you an example, I think
any Scheme programmer will have a difficult time implementing Pascal as it's
specified. He will see the language lacking in drastic ways that _can_
improved with little effort.

~~~
wglb
Well, not sure how to write a compiler that generates machine code without
fully understanding the semantics and evolution. I have done two of them and
did not do rigorous mathematical semantic models. One was an implementation
language targeting 8085 with the compiler written in Bliss 36, which had
clearly superior semantics, and there was no hint of the corruption that you
suggest.

I think it would be a fun project to write a pascal compiler in scheme.

I argue that there are things that you are likely to run across in generating
code that you might not see in mastering the language.

See, there are two kinds of study going on here. One is the study that I have
done of emacs, which is what I think the article was talking about and that is
starting with a small set of knowledge and expanding bit by bit as you use it
in daily life.

The other kind of study, which I was trying to illustrate (and apparently
failed) is a thorough, directed study (e. g., reading the User Manual and
Report until it is about ready to fall apart), or reading the spec for the
target language and working with the users closely. In the second case, we
(three of us) wrote the compiler in a year, and just about replaced the use of
assembler language in the OS project.

~~~
mahmud
I can't think of one non-procedural language you can "teach yourself" by
writing a compiler for. That was my point of reference.

Even if you don't do any semantic modeling of the language itself, you most
likely will be reading similar research done for a similar language.

You can teach yourself an Algol dialect by implementing it first (same thing
with Forth) but that's pretty much about it. Even Griswold's Icon, procedural
at it's, is more sophisticated than anything Algolish.

~~~
wglb
I'm a little more familiar with SNOBOL, but ICON is imperative and procedural
and a bit complicated, and it looks tempting as a target for this little
thought experiment that we have, writing a compiler to understand how it
works.

Now it would not be a fair test to go after scheme or lisp, as there are many
examples out there of people who have implemented toy schemes and toy lisps.
Toy here in the sense of tutorial or exploratory.

So being a simple country boy, I seem to be having trouble coming up with
examples in line with your point. I wonder if you could give me some examples
of non-procedural languages for which this exercise would not work--the
exercise of writing a compiler for a language not being successful for
learning the language without doing extensive rigorous mathematical semantic
modeling?

~~~
mahmud
I would say nearly all functional programming languages are beyond the scope
of the dedicated hacker with nothing to go with but the Dragon book and Lex
and Yacc manuals. The strict ones are more approachable, but even an FP in its
most primitive form, the untyped lambda calculus, is hard to reason about
without some form of mathematical tools, at least enough to understand
_efficient_ implementation of recursion. (Anyone can implement recursion, even
in assembly, but its consequences are far more reaching than just "set base
pointer to stack pointer, add sizeof(locals) to stack pointer, and jump to
routine entry point"; that's why you have people like GvR struggling with it,
20+ years after the lambda papers.)

Type theory would send anyone insane; static typing is trivial when you have a
set of "primitive" types and another "derived" types; neither C nor Pascal nor
another Algol dialect _actually_ implement proper types. C gives you a bag of
bytes in the form of a struct, and pointer to that back; you create your data
structures with that. ML dialects take type theory to fantastic extremes.
Throw pattern matching into the mix and your _regular_ compiler hacker is off
to reading the semantics literature.

Reasoning about lazy evaluation is also not trivial. It doesn't even show up
in the mainstream compiler literature, which, by the way, has always been
about creating the fastest Fortran dialect. Compiler research IS Fortran
research, while the PL research is mostly FP research (even if it masquarades
as OOP sometimes, usually for grant and resume purposes.)

Logical languages also are beyond the reach of someone coming from a classic
compiler hacking background. LPLs are so far out that not even mainstream PL
enthusiasts grok them.

All is not lost, however. At least one language, Forth, is trivial to
implement, and best learned by implementing it first, as much as it's
difficult to reason about. The problem with Forth is that there is nothing
magical going on; it's a simple and beautiful little perversion, something
that could only come out of a mind untainted by theory. Ditto with Perl,
though by no means pretty. Perl has the finger prints of a hobbyist all over
it.

~~~
wglb
So if i were nuts enough to try this experiment, which language would you
recommend? Ok to reply via email off list as well.

~~~
mahmud
Call me selfish, but I treasure programming languages, specially the weird and
unconventional ones, and specially if they have some sort of
academic/theoretical brownie points.

You have already done BLISS, I have been meaning to clone it ever since I read
an old rant by Dennis Ritchie on usenet. I am weirdly attracted to CMU
languages, so I am gonna say Dylan :-) Marlais is open source and you can use
it as a starting point. I am half way through cloning DUIM for Common Lisp
and, frankly, all their "syntax" innovation would be lost to me. I am forever
ruined for non-Lisp syntaxes, I think. ISO Lisp would be cool too.

If you weren't a compiler hacker I would have recommended Oberon.

For some reason, I could never see compiler hacking outside the traditional
code generation for a real machine. If I wanna do source translation I would
probably stick to macrology.

Miranda would be cool too, specially since there are no FLOSS compilers for
it.

Mozart/Oz has a tiny kernel which you _can_ clone, but I don't want you to
learn this in that matter. Instead, get the book by van Roy and Haridi and
enjoy at a leisurely pace.

Someday I would love to implement an APL and a Prolog dialect. Someday.

------
fogus
I've been using it for only 2 years and feel like such a loser when I pair
with the true veterans. Watching a true Emacs master is an amazing thing.

~~~
kentosi
Are there any websites/screencasts that show such "masters" in action?

I really can't see where the fuss is. And I particularly agree with the
following comment on the page:

"Wow, you spent ten years learning how to use emacs. In the same period of
time you have earned a PhD, learned a few foreign languages, scaled a few
mountains, learned several other computer languages like F#, Ruby, Scala, C#
4.0, started your own dot com, and gotten into great physical shape..."

I know I'm being pessimistic here, but it's not without reason. Back when I
was a teenager I spend hours, weeks, months tweaking with linux kernels and
the OS in general to make it run as smoothly as possible. Back then it was my
passion, and I did learn a lot. But at the end of the road I realised that I
could have done so much with my time because all that knowledge is now either
lost or obsolete due to newer versions of linux software coming out fixing old
bugs.

I went down the path of trying to master vi. This was more for the sake of
looking "l33t" in the linux community than any job prospects/etc. It was
painful and made me appreciate eclipse and other IDEs a lot more.

There seems to be a perception out there that being able to code an entire
stand-alone application using vi or emacs is really awesome and cool. This
inspires beginners to want to be just as cool and elite. And when they find
out it's gonna take years they see it as even more of a challenge (and some
sort of ego-boost), without actually thinking of the return on investment.

~~~
mattrepl
I'm surprised your comment has been voted up, it hinges on the assumption that
learning the intricacies of a programming tool, in this case an editor,
prevents accomplishing anything else with you life.

There may be other people out there that use an editor, or an OS, to impress
others; but from personal experience and those of friends, there are plenty of
people that learn vi and Emacs because they needed to get things done.

The right tool for any job depends on the person. Someone familiar with the
details of HTML and CSS would likely be better off not using a WYSIWYG editor,
but for someone unaware of and uninterested in DOMs and stylesheets that
editor would be great.

~~~
extension
Whatever time you spend fiddling with your editor is time that you have not
spent editing code. Over 10 years, it must add up.

What's dangerous is that the fiddling _feels_ productive, even when you're
just learning/making useless gimmicky features.

~~~
jacoblyles
I've been using emacs for about a month now. I've definitely saved a lot more
time than I've spent fiddling with it.

~~~
silentbicycle
You won't _really_ blow time fiddling with it until you get the hang of elisp.
:) Then every little thing that bugs you makes you think, "Oh, I could just
override this..."

(defalias 'yes-or-no-p 'y-or-n-p) ;don't bug me

------
cema
The article should more properly be titled "Learn anything in ten years".

One thing about Emacs (mentioned in another comment in this thread) is that it
is more than an editor but mostly used as an editor. It does not take 10 years
to learn to use it as a better notepad (I mean, better pico... whatever), but
mastering its existing (elisp) code base and adding to it (more than the
trivial customization) takes a while indeed.

The article mentions some of the general reasons why it takes a while. Another
one is that few people actually set out to "learn Emacs" as such, they just do
it as an afterthought while working on other projects, and therefore not in a
consistent and steady manner. So there may be months between "lessons" and,
therefore, 10 years to complete a course, so to speak.

~~~
silentbicycle
The name is a a reference to Peter Norvig's "Teach Yourself Programming in 10
Years" (<http://norvig.com/21-days.html>), which is linked in the essay.

The part of Emacs that takes years to learn is integrating it with everything
else. The core editor doesn't take long.

------
GeoffWozniak
_I recommend trying Gnus. The several weeks you waste trying to figure out how
to point Gnus at your mail server more than pays for itself by the amount you
learn while driving yourself mad._

I have a hard time agreeing with this statement, especially since I
experienced just that. The only thing I learned was that the documentation for
the process was awful.

Furthermore, the statement is some curious attempt at irony that undermines
his argument. I don't want to spend 10 years setting up a development
environment, I want to spend 10 years _learning_ a development environment.
Such a line can be very fine, indeed.

(This being said as a regular Emacs user.)

~~~
silentbicycle
Data point: I can't stand gnus. It was a paon to config, and I never got RSS
working. (mh-e is nice, though.)

Building a mail system into a single-threaded text editor seems a bit silly to
me...

~~~
sielskr
_Building a mail system into a single-threaded text editor seems a bit silly
to me..._

Why's that? The (not gnus) mail system I use on Emacs will hang the Emacs
process for a few seconds sometimes when I hit send while the Emacs process
talks to my ISP's mail server, but that is the only way the mail system's
single-threadedness ever really bites.

When I check for new mail on my ancient Pentium III system, the Emacs process
hangs for less than a second or 2 usually.

Those delays are nothing compared to the time I waste waiting for Firefox to
do something.

~~~
silentbicycle
I prefer the Unix (and Erlang!) model of having lots of independent processes
communicating, and individually serving a specific function. While I _really_
like using Emacs's buffer-based environment as the common interface (such as
working in a shell buffer and being able to edit results), I'm not convinced
that adding more and more functionality to the same process is a good idea
from an architectural standpoint. (And unlike Firefox, GNU Emacs doesn't even
have good namespacing / isolation for its extensions, hence all of the
variables with package-variable-name-with-several-parts names.)

Plan9's ACME preserves most of what I like about Emacs, but it's mouse-chord-
based UI is a dealbreaker for me.

------
igrekel
I know how to do basic editing in emacs, I use it when I need to edit files
from the command line, I don't use it for long programming sessions or reading
a lot of code tough. I tried to become better in emacs and to use it a few
times for programming sessions; I am still puzzled by posts like this.

Maybe it is because we were using Eclipse at my day job and I kept forgetting
all the emacs commands, kept having the reflex to use the common key shortcuts
for copy, paste undo etc. from the other applications I use. Maybe it was how
slime would go crazy when doing scheme. Or maybe the fact that finding the
keys for emacs sometimes proved problematic (when using cygwin outside of
xwindows for example). Or the fact that aquamacs was slow to open on my mac,
or that its default configuration was slow to open from the command line on my
linux machine when I wanted to edit a line in a config file. How jumping
around or scrolling a file was slow when you didn't know exactly what you were
looking for. There were tons of small things that eventually added up and I
always abandoned after a few weeks because I was losing productivity, was
wasting time configuring or customizing it and the actual gains in
productivity or features weren't that big compared to Eclipse, NetBeans,
TextMate, XCode or other IDEs or editors.

Most of the comments raving about emacs (or at least the people I have met
raving about emacs in real life) somehow seem to believe other editors are
like notepad and lack search and other useful things. So I naïvely ask, is it
really worth it?

------
Ben65
Cool, nothing better than a discussion about which editor to use. Of course
you could learn vi in five years.

~~~
kirubakaran
'Editing' is just one tiny subset of what Emacs does[1] and vi competes with
that part well. But why is vi brought up whenever Emacs is discussed?

[1] Or rather, "empowers you to do"

~~~
igorgue
because they're both awesome and we always want to know which one is
awesomer!, now please lets not include TextMate in this conversation :)

I'm a VIM user and I always like the cool things Emacs users can do, even
though I'll never use Emacs.

~~~
yters
The only editor anyone should ever need is that which the blessed pg provides
in these little text boxes.

------
bayareaguy
Apart from rudimentary key bindings, the two features I immediately miss
whenever I use another editor are _query-replace-regexp_ and _dabbrev-expand_.
Oh and _display-time_ also earns honorable mention.

