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.
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.
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.
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.
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?
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.
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.
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.
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.
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..."
>Are there any websites/screencasts that show such "masters" in action?
Purely for the sake of motivation.
I can get things done with Textmate but I feel I've hit a wall in what I can do with it. I've used emacs off and on for about 6 months now and I really want to take it on full time.
I started using Emacs because I was interested in learning Lisp (and had been using vim for several years, so I figured it would shake things up). The thing I've seen that best captures how full-on Emacs wizardry looks is Marco Baringer's Slime screencast (http://common-lisp.net/project/movies/movies/slime.mov). It's a sort of IDE for Common Lisp. (Edit: Better link, thanks kirubakaran.)
While really learning the nooks and crannies of Emacs's functionality can suck up a lot of time, it's also not going anywhere. I've only been using Emacs for about three years now, FWIW, but I'm a bit of a toolsmith, and I've learned enough to teach others. (FWIW, I'd also jump ship if a better editor comes around, but Emacs and Vim are each good enough that getting sufficient momentum with a new editor to displace them would be incredibly difficult. The most interesting alternative I've seen is Acme / Wily from Plan9, but I don't like its mouse-y interface.)
The best way to learn Emacs is to start with the tutorial (start Emacs, then press Control-h and then t), and then learn how to use the built-in help system. Everything is meticulously documented, though sometimes with unfamiliar terminology. It helps if you have a focus, like learning how to run make, a Python interpreter, etc. inside it. The Emacs Wiki (http://emacswiki.org) has quite a bit of good advice, as well.
Don't forget to keep your Emacs config under VC. :) Extension recommendations - pabbrev, tagging.el, uniquify, saveplace, recentf, remember, midnight, anything, and emacs-w3m if you're using Unix.
Once you put in something like 10 hours towards learning Emacs, you'll become productive with it. After this initial investment, for every n minutes per day that you put it, you'll get m back in terms of increased productivity. In my experience |m| >> |n|. And remember that time saved = mt - n, where t is the number of days you have been reaping this productivity boost, and t tends to infinity. You won't "lose" any time after that (however, you can if you want to, by doing obscure fun stuff), and your productivity will continue to go up.
Marco Baringer's is the only good Emacs screencast I've seen so far. Please share if you find any other.
Being new to Emacs, I am wondering if you could enunciate how these gains might come in a particular case -- of course, a hypothetical one. Suppose Joe User has configured Auctex on a squeaky-clean Emacs 23 installation. Joe had been trying to understand coherent sheaves and Serre duality, and so, having spent the morning reading "Lectures on Riemann Surfaces" by R.C. Gunning, he took some notes with paper and pencil. Then, he wrote a corresponding set of notes in his brand new Auctex system. It was all running and well, and Joe C-x C-s'd and went to bed and dreamt of Gammas and Pics and Strange Os. Joe woke up the next morning and went into zazen, looking at the sun rising through the treetops in the forest behind his home.
And he did it again that day, and made a bit more progress, and learned a beautiful proof for Weierstrass's theorem using the induced sheaf cohomology of the exponential sheaf sequence. Joe decided to use Windows XP -- he didn't want to think about all that lisp stuff today, and having nothing but Internet Explorer 6 (Joe only reads one page at a time) and Notepad to do his work with, he wrote the rest of his Latex notes in Notepad. And he felt happy, and went to bed -- which wasn't a bed, just a floor, as Joe was really a minimalist sort of guy.
==
How will Emacs enhance his experience (in any broad sense)? He doesn't compile often. Come to think of it, he probably doesn't need the preview-latex function either. In which forms do these gains come for him? Generally, what is the least complex form of editing that Emacs can still produce gains for?
First biggest productivity gain[1] for Joe will be in using forward and reverse search for navigation (C-s and C-r in default key bindings).
C-s or C-r, type a few chars, <Enter>, continue editing
is an amazingly powerful way to jump around even a simple text file. No arrow keys, no mouse. I dare Joe to use this feature for a few days and try to go back to Notepad. (You'll be using it even to jump to a different point in the same line.) Also Emacs can be as minimal as you want it to be.
Any data formatting and parsing is extremely simple and easy, since this essentially becomes programming by doing. Much quicker than any other method I know and awesome for the many, many quick hacks one needs throughout the day.
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.
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.
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.
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.
Firefox, actually. (Which is the new program-with-a-million-extensions.) I just use gmail for mail these days, though I would probably go back to mh or mutt if I started using a client program again.
I've never found an RSS reader I've been satisfied with, though. I was working on one at one point that had an interface like mh, but I haven't gotten back to it in a while.
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?
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.
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.