> Any sufficiently complex system (whether it's a text editor, biological ecosystem, or vehicle) is going to be difficult to interact with for a new user.
Counterexamples: MS Visual Studio. MS Word 2010. MS Excel 2010.
Counterexamples: MS Visual Studio. MS Word 2010. MS Excel 2010.
Just an anecdote: I work in a computer lab for these type of new users, and after being trained for many years to go to a file menu, the round button that serves as a menu access in Word 2010 trips a lot of people up. I get tons of "Where's the print button?" questions.
Each cycle, Microsoft does usability tests with new users doing moderately complex stuff. One of their designers did a series of blog posts and videos about their approach to usability and usability testing for Office 2007 that was really interesting. The whole point of the Ribbon UI for Office 2007 and later was to make it easier for users to discover and use the advanced features of Office without training.
Yes they are ... "really interacting with them" is not their purpose.
You can open an Excel spreadsheet even if you haven't done so in your life and only have experience using Word ... you can move around, search for text, change styles, print. That's because it uses common interface elements that have been used for years.
Yes, Office 2010 brings interface changes, but it's nothing to worry about ... once you clicked the round button once, you'll learn its position. It took me a whole week to not trip over C-x C-s in Emacs, or to remember C-x C-c, and I had to setup my own shortcuts for common stuff (like C-w which deletes the previous word ... as in Vim, because even if my life depended on it, I couldn't learn the Emacs shortcut). And I still don't know how to print from Emacs.
We are talking about technically-inclined people here. Textmate is a lot more intuitive to use ... I'm still using Emacs because it is much more powerful, but boy what a painful experience it was the first months.
Just fire up a VirtualBox, and install Ubuntu in there. The hardest part about a Linux installation is most often the partitioning--but you can just use the whole virtual disk.
Or you just download a pre-installed image of a VM.
But dig any deeper into the build system and you will quickly realize that the editor is the easy part of the job. You mistake the whole job for the easy part. Visual Studio (and Word, and Excel) are enormous tools with vast functionality.
Yes, I am an Emacs user. Today I decided to add two more mouse gesture bindings to my init.el - scroll-wheel action when the pointer is in the mode line - in addition to the bunch I already have that make my life easier. And the kind of Lisp you have to master to do that is material for a 5 minute tutorial - in the end, two lines were added to the init.el file. They are very easy to understand, BTW:
(global-set-key [mode-line mouse-4] 'next-buffer)
(global-set-key [mode-line mouse-5] 'previous-buffer)There may be some minor counterexamples, but overall, Visual Studio is a _vastly_ superior development experience (for C++) than any other environment.
I'll take the "you have to know what you are doing" route any day.
This attitude of "to drive a car well you have to be a mechanical engineer!" is dangerous to efficiency. As is the Stockholm syndrome that so many make users seem to be suffering from. The difference between the two is that with Visual Studio, you can defer learning about the build system in depth until the moment that you actually need it, whereas with make you need to spend a whole of time upfront, for no discernible gain. I'll take a 'easy things are easy, hard things possible' approach any day.
My point is that with a single download (and no real installation besides a single click), you can get a new environment up and running in Visual Studio.
I'm not saying VS is the world's greatest IDE (I use it strictly for .NET work, and use gVIM for everything else--and use, I've used emacs, too). I'm merely talking about it in the context of the ease of integrating new languages/frameworks.
Most probably, they will start with a book or something like that to learn the basics.
In contrast, I still don't know how to do "Go to Definition" in Emacs; in fact, I don't even know how to tell Emacs how to find all the source files for a project. I doubt I would have been able to complete the same task in the first day I'd used Emacs.
Emacs can be used as an IDE. I use it every day that way. I can use it like that because it's completely programmable. When I needed a Pyccuracy-specific editor, it took me an afternoon to write one (not from scratch) in Emacs-Lisp. I could probably have a spreadsheet inside it, if I really wanted.
Try to build a Lisp IDE inside Excel... ;-)
About the "go to definition" thing, it depends on what major/minor mode you are using. There is probably something like that for C-ish development. I just never used it.
And for finding all files in a project, there must be something that parses makefiles and rounds up source files. Emacs is older than many of us and someone must have already solved this specific problem in the past 40 years.
I am playing with "nav" in order to build special-purpose browsers. I would love to have a YQL-mode, but I feel I should replicate the multi-pane tool Yahoo makes availabe.
The way you interact with Emacs is through a text editor.
I mostly do C/C++ stuff. I use gnu global for code tagging and navigation [1](aka "goto definition" thing). As for project organization, I have no experience but you might want to check out CEDET [2]. It appears that CEDET has made it into emacs trunk, so hopefully you can get some nicer "project" stuff in emacs soon.
"The first time I used Emacs I found all kinds of Lisp functions I already knew. It has a familiar grep command that lets me click on results to jump right to each matching line in a set of files. I used the online help to find a command that evaluates Lisp expressions immediately allowing me to extend my environment just like typing into a REPL. ..."
You probably get the idea.
You might try "definition", but the hits for that aren't programming-related (emacs has a much wider scope of functionality than Visual Studio), so you'd probably go up to the top level of the manual. One of the topics there is "Features for maintaining large programs". That would tell you exactly what you want.
In your example you talk about "shortcuts of every other program on my computer". So you're assuming a programmer comfortable with windows. If I take the same liberty and assume a programmer comfortable with Unix, s/he will look in the Tools menu, see "Search Files (Grep)" and have immediate success finding the definition without any use of the emacs help system.
Office is a much better example in my experience, particularly Excel.
(No, I don't personally care. I don't use Word.)