As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
For someone just starting to program, would you recommend using vim/emacs, or should you use some IDE? Like are vim/emacs better suited for more advanced users than for beginners? I'm just wondering because I'm trying to get some of my friends to program.
If they're just starting programming, I'd not recommend VIM to begin with.
they'll have enough on their plate to begin with learning the ins and outs of programming
depending on the language/platform, I think they'd appreciate an IDE with code completion , general language support etc. (I know you can do this in VIM, but it's a lot more seamless in an IDE).
Note. I'm a VIM fan, and I run my IDEs with VIM plugins, so I have nothing against VIM as such.
I note in your comments you're looking at teaching them Java. BlueJ is a Java IDE geared towards learning Java, and may be a useful introductory tool.
When I used to teach C & C++ commercially, back in the late 80s/early 90s, we did all our teaching on UNIX boxes, with vi as the editor. A lot of our clients were MSDOS (and later Windows) users. These guys used to have, on day #1 of a 5 day course, to learn the basics of UNIX and the basics of vi, at the same time as they were learning C and C++. They all bitched like mad (and I couldn't blame them) but they all managed it.
Perhaps we expected a lot more of each other back then. Still, we haven't changed genetically in that short period, so if they could learn vi easily then, programmers today can also learn it, without too much trouble.
Avoiding the subjective question of editor choice, it's not so much about advanced/beginner as learning too much at once. It's probably a good idea to separate the coding learning curve from the editor learning curve. If you're busy learning to code, use an editor you're already comfortable with (doesn't have to be an IDE, could be gedit, etc.). Once you're comfortable coding, you can move on to an editor of your choice if you're not happy with what you already knew. An advanced coder might still prefer a simple editor, and one who hasn't learned too much might still want to work faster and switch to Vim.
Since you say you'd suggest Java to them, Eclipse is probably the way to go. If you were suggesting Common Lisp, I'd say Emacs without hesitation. For Python and the like, I'd say to use whatever text editor they know now; vi, vim, Emacs, Geany, whatever. But for Java Eclipse is a pretty good standard choice.
Whatever editor you choose, have the cheatsheet sticked next to your screen.
People either like vi (or emacs) or hate it regardless of their skill level as programmers.
I am by no means an emacs whiz, but in terms of learning the basics of a new language I think it is handy.An IDE can be a distraction from what you are trying to learn (So you end up spending time learning an IDE rather than a language) and emacs provides both good indenting and syntax highlighting, as well as easy access for compiling, debugging, and accessing the shell.
I know I'm going to get voted way down by the legion of emacs/vi people here, but in terms of learning a language, an IDE with intellisense (or whatever the generic version is called) is absolutely indispensable. For instance, if you use visual studio, you will spend almost no time playing with the IDE. The automatic completion clearly shows the relationships of member variables, and makes it so that you don't have to remember minutia. Scope and type resolution is also invaluable for the beginner. Most important however, is that whatever you are using contains an industrial strength debugger. Logging with strings to a text file is no way to go through life. Even the legion of emacs lovers will probably admit that someone is far more productive with a professional IDE and a beginner is far less likely to get frustrated. Now, if you are going with something opensource/free, your experience may vary.
If you're just starting and you're learning Java, I would go for one of the graphical IDEs. Yeah, something like Eclipse or Netbeans is fairly bloated, but it doesn't change the fact that they make the barrier of entry way lower with suggested error fixes and the like.
vi or emacs in combination with gcc are great, but I would go with something more beginner-friendly to begin with.
If they are beginning to learn programming, it is better to start with a simplae text editor like gedit or geany. But learning to use emacs or vi down the road will be a hugely enlightening experience. It might be be a good idea to learn emacs by using for plain text files (notes, todo lists), so there is not the distraction of learning language specifics.
Run the vimtutor command. It's an interactive way of learning a lot of useful basics in Vim. Vim is very powerful and efficient. You won't learn everything there is to know about it at once. You'll continuously learn more handy features of it as you continue to use it. If you get the basics down, you'll start spending more time in command mode. Do not use the arrow keys. It may feel awkward at first using hjkl keys to move around, but it will soon feel natural and become faster because your hands do not leave homerow on the keyboard. One of the great things about Vim is the user almost never if ever needs to take his or her hands off of homerow.
As for Java, Netbeans kicks ass IMO. Why shouldn't it? It's made by the same people who developed the Java language. So when I am using Netbeans, I use it with jVi plugin that allows me to work with it just like I were using Vim.
vi and gcc, nothing else
Editors seem to be a touchy subject. It really seems to be personal preference. The only reason I ever learned vim was because of the workplace required me to. The only reason I ever used emacs was because of school. Having said that, I think just using the available development tools (VS for .net framework, Eclipse/NetBeans for Java, etc) would be best in my opinion, but again, its definitely personal preference.
It depends on what platform and language you plan to start and then boils down to individual preference. If it happens to be windows and you plan to do C#/VC++/VB then Visual Studio IDE is the best.
I used emacs when I started on Scheme and python and I found it handy.
cheers
I learned Java using a combination of DrJava, BlueJ and Eclipse. I started with DrJava since it had an interactive Java shell. Then I played with BlueJ and finally Eclipse once I thought I knew enough.
Now that I "know" a couple languages I just use Vim.
I'd recommend Vim for anyone working with a text editor, but not at the same time as learning programming.
I don't know about emacs, but I would recommend learning Vim for a beginner in a heartbeat. The vimtutor program is a great way to pick up the basics. It is a bit of effort, but you soon get used to it.
I started using Vim when I was learning HTML, and it was a massive improvement over something like Notepad. It soon replaced nano as my command-line text editor of choice in Ubuntu as it's easy to navigate around fast with Vim. Then, I decided to learn Python and I found it was easy to get started with it because I was already familiar with Vim. Now I'm learning C and it's great to have an editor I'm already familiar with as it means I don't have to worry about getting used to a new IDE or text editor. This means there's less work for me to do.
I've found knowing how to use Vim gives me a significant productivity boost over any other editor I've used. The only downside is the key bindings get burned into your brain, to the extent that I keep reaching for Escape when I want to move around in a Word document!
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I've used vim for a pretty long time and I'm still happy with it.
I started to learn clojure 6 months ago. It seems that emacs is the first choice for lispy language programming.
But I would rather learn something else than spend a lot time on learning how to use an editor which is not obviously superior to vim.
So I struggled to make my vim setup more suitable for clojure programming.
What I'm now using is:
vim-clojure-static, which provides basic syntax highlighting
paredit, which provides structural edit on s-expression
vim-fireplace, which can talk to a remote repl within vim
I also use vim-redl, redl to get a debug repl, but IMO the three above can already provide quite pleasant coding experience.
My question is, am I still missing some killer features of the emacs working flow?
Is emacs better for clojure/lisp development? Yes, it is. Can you do without it, of course. I used vim for Clojure development but I switched to emacs a couple of months ago and I'm very glad I did. Personally I find it a much better experience. The vim plugins probably have matured a bit in the meantime but vim has some serious limitations with regard to external processes and so on. I had some general vim plugins I really loved but luckily they all had alternatives for emacs.
Couple of things worth mentioning:
I use Evil mode. Like Tom mentioned it's a vim emulation layer. It's extremely good. I don't miss anything from vim. Text objects, all the vim modes etc are supported. Personally I can't remember all the strange emacs keybindings, they drive me nuts. Without Evil I wouldn't be using emacs. I created evil keybindings for paredit and some other plugins and you basically have vim on steroids. I only use vim for quick edits now.
Customizing Emacs was the hard part. I love Emacs now but I wouldn't know what to do without my customized Emacs config. Once you tweak everything to your liking it's very hard to go back to anything else. It took me a long time to get to that point though. Check https://github.com/otijhuis/emacs for my personal emacs config if you want to try it. It still needs a little work and I'm no Emacs guru but it works really well for Clojure development. It might be a good starting point.
I'd like to point to the upcoming vim-sexp, by the maintainer of vim-clojure-static:
vim-sexp
Precision Editing for Symbolic Expressions
This plugin provides mappings, operators, and text objects for Lisps including Clojure.
I don't use Clojure myself, so I can't tell for sure, but the plugin looks very promising and is under active development.
The reason Lispers tend to like Emacs is that Emacs is a lisp machine. If you're already familiar with the language family and its tendencies, it's really convenient to be able to use it for extending your editor.
From my own (admittedly Common Lisp, rather than Clojure) workflow, I like having autocomplete, argument hints, and the SLIME macroexpander. I'm pretty sure you can get each of these for vim, so don't stress too much about what everyone else is using.
As a note, if you haven't already, look into slimv and this article on setting it up with Clojure. I haven't used it myself, not being a vim user, but it seems close enough.
I am a quite happy user of Eclipse (I mostly develop in PHP and Python), however I found the answers to "What specific productivity gains does Vim/Emacs provide over GUI text editors?" interesting enough to make me wish to try out Vim or Emacs as well and see if they would turn out to be a better solution for me.
I have the general feeling that Vim and Emacs are not the kind of editor you learn by "playing with it" though. I have the impression you must dedicate some time and effort to "study" them a bit, before you can benefit from their power.
So, I have two questions for the community:
In the linked thread responders have essentially answered by commenting on Vim (often mentioning: "I'm sure Emacs has the same"). Google trends seems to indicate Vim is the mostly adopted between the two, however my first question is: knowing that I have no prior experience whatsoever on any of the two, and that I use and develop (mostly PHP and Python) on GNU/Linux systems (Ubuntu, Arch Linux), is there any of the two which would represent a better option to start with? (To be clear: my question is not about the quality of the editors but it is about what it is strategically better to learn in my situation).
What advice would you give me on how to learn using it/them? I know this is a broad question, but it is deliberately so. Have a look at this answer (unrelated topic) for an idea of the kind of information / style of answer I am looking for [but do not feel obliged to answer that way... any contribution will be welcome, in any form!]
EDIT (on picking the "accepted answer")
I picked one answer as the accepted one just now, but I would like to say "thank you" to all those who shared their experience and advice: almost all of it has being useful to me in some way. The thread has definitively exceeded my expectations! Thank you! :)
I would advise that checking out both is worth the time because of various reasons already covered by other answers or "Emacs vs vim vs XY" threads.
Still if you would have to pick one of them I'd go with vim because of one thing:
Availability
Vi(m) has the advantage that it is installed (not only available) by default on almost any *nix system. So no matter whether it is your system or someone else's or whether you are allowed to make changes to it or not, your favorite text editor and friend is there waiting for you.
Once you know vi(m) it feels awesome in those situations where you ssh into a machine and need to do something with text (navigating through a file, editing, whatever). You are going to feel like a King. I remember several times when I almost freaked out because nano or pico were not installed and I had to use "this ugly beast vi" which made unpredictable things when I started typing (because I wasn't in insert mode and didn't even know what that was) and when I was happy to have googled that ":wq!" gets me back out of hell. Now I can look back and smile about it.
I have the general feeling that vim
and emacs are not the kind of editor
you learn by "playing with it" though
Vim and Emacs are certainly editors that you "learn by doing".
Of course the question cries for including these highly scientific text editor learning curve graphs =)
Vim might be a bit harder in the beginning because its modal editing can feel quite unfamiliar at first. I think motivation is the key here. The article "Why, oh WHY, do those #?#! nutheads use vi?" explains the advantages quite well I think. In my opinion it really is worth to give it a try even while the learning curve might be steeper than with other editors and it sounds like you bring the necessary motivation.
Back to learning by doing.
Something I wish I would have done the first time:
Check out Vimtutor. It is an interactive tutorial which demonstrates the power of vim by showcasing it's basic commands and how they can be composed. Just type vimtutor in your terminal.
This helped me to really "get it" after trying to learn editing with vim several times in the past. The tutorial eases the learning curve dramatically as it explains the commands and makes you actually perform them so they become a habit. It really makes a difference compared to being frustrated because of feeling handicapped. Using vimtutor you also will see what the benefits of modal editing are and instead of fighting or ignoring it you are going to embrace it because you have experienced the advantages at first hand. I guess it would be pretty difficult to learn that all by oneself. So these 30 minutes are quite worth it.
I have the general feeling that vim and emacs are not the kind of editor you learn by "playing with it" though.
My experience with emacs is actually quite the opposite. I tried going through the tutorial, but it didn't seem to help much. The way I ultimately ended up learning is with a reference card and just forced myself to use emacs on my code until I got it correct*. Then again, I do also have a screw loose. Your milage may vary. Offer void where prohibited. You get the idea.
One other piece of advice I recall reading somewhere is to try writing down a list of about 10 commands you want to learn and keep it by you while coding. Once you've mastered those commands, make another list of 10 more. Keep doing this until you've got a big enough chunk of the editor committed to memory.
*Note that the linked reference card is out-of-date. If you google, you can get a more up-to-date reference card.
knowing that I have no prior
experience whatsoever on any of the
two, and that I use and develop
(mostly PHP and Python) on GNU/linux
systems (ubuntu, archlinux), is there
any of the two which would represent a
better option to start with?
I'm an emacs guy, so my opinion should be obvious. That said, you're likely best trying out the one that more people you know seem to use. Having someone who's experienced with emacs (and I'd assume vim) is a great help.
If you don't know anyone who uses either one, choose whichever one you feel is the prettiest or has the coolest name. You won't know enough to know which one you'll like, so you might as well choose arbitrarily.
For vim try vimtutor
I came to Vim when I started using Linux after years of Windows development, and had to do a lot of work on remote systems via ssh. For the first couple of weeks hated it. After that I could not live without it.
Probably the best way to start is to use Vim in easy mode ([g]vim -y), most installations have a shortcut called evim. This runs vim in a mode that is in insert mode by default and remaps keys to the usual Windows ones (ctrl-S to save, ctrl-X to cut etc). You can then use it like a regular Windowsy editor but still access the power of Vim.
There is also Cream which is Vim + a bunch of scripts to make it behave even more like a Windows editor.
I started out using evim and Cream, but found I gradually transitioned to using 100% vim.
Also if you use gvim then most of the functionality is also available through the menus and you can see the keystrokes for the same functionality.
Also read the docs - there are extensive help files available on every aspect. I still browse them from time to time and find something new.
Using VIM, I find the following quick reference card very helpful, especially for the stuff I don't do everyday:
VIM QuickReference
For emacs, you should read the GNU Emacs Manual. Don't try to do everything all at once.
Start with the basic stuff, and then move on to the more powerful features once you're comfortable with the easier stuff.
Some time ago I decided to learn vim beside Eclipse as well because of its powerful textual editing, search and navigation features. But - at the same time - I liked the project handling, code completion, refactoring and debugging features of Eclipse and I did not want to lose them.
Nowadays I use an Eclipse plugin called vrapper which provides me nearly all basic features of vim inside Eclipse without losing any Eclipse functionality. Of course it is not a full-featured vim but it gave me the productivity gain I 'expected' (motions, the dot operator, registers and marks). Also, this plugin can be considered the 'trial' version of vim where you can learn all basic and some advanced stuff within your 'best-known' environment.
There is another interesting approach called eclim. Eclim integrates Eclipse with vim from the vim side so you can use many features from Eclipse within vim.
For learning the basics of vim, this graphical cheatsheet helped me a lot.
I would go for Emacs.
Explicit command name will makes your task easier.
I switched to emacs after I had years of experience with vi and never looked back.
Go with tutorial first.
Hang out at #emacs in irc and people are happy to help you in real time, for whatever more you need.
My advice for learning emacs is to understand that everything is done by a command (written in elisp) that is connected (bound) to the key strokes that you make. The power of emacs comes from being able to write new commands and use commands that are not bound to keys (there are too many commands to bind each one to a command.) as well, of course, read and modify commands that are already in emacs.
Next learn how to use the Help key and how to make a key binding list, then how to search for relevant commands (apropos) and see if they are bound already.
Be ready to take learning diversions into the emacs manual (Help, Read manual, Emacs manual).
One argument in favor of Vim if you know Python is that you can write Vim scripts in Python. See :h python. Emacs requires you to learn elisp.
I find myself gravitating toward Vim for scripting languages like Ruby/Perl/Python/PHP, and for Emacs for languages that are more interactive (Lisp, essentially). If you develop your Python code using an interactive Python shell a lot, Emacs might be good, because you can embed a Python shell right into Emacs. If you write code and run it from commandline a lot, Vim can handle that easily enough via :make or :!.
I really recommend you learn both and pick whichever you like better. They are both worth knowing.
Wow, vi/vim vs emacs, what a temptation...
From a vi-user's perspective...
Always Therevi is on about every unix system ever released, in the default install, and available for Win
May save you from RSIvi uses home-row keys for just about everything, modifiers like control and meta are used only for rarely invoked functions and even shift-key use is moderate. This was probably all just a lucky accident, but don't laugh at RSI. It can happen to anyone, it's seriously painful, it's potentially career-ending, and it's hard to treat.
Starts up instantly.In the past, this was a huge advantage over emacs. Emacs users had to start up just once, and navigate everywhere within emacs. Today it starts faster, but in vi, it's perfectly reasonable to quit out of it entirely on every compile or test cycle.
Has an awesome line-mode The line mode in vi is backwards compatible to the original Unix ed(1) program, an editor that had only a line mode. That is, vi's regular-expression-substitution-engine-/-line-editor was once an editor all by itself.
Easily scriptableGot something you want to do to every .whatever file in your project? It's easy to write a declarative script that will edit a sequence of files. No need for imperative or procedural programming.
Easily extensibleVim, at least, can be extended in Python.
First of all, be humble.
As long as you remain aware that they are very powerful tools you'll be ok. If you are finding a task very difficult, and you are thinking 'it's just me that sucks not the editor', you're in the right mind to learn and improve.
Bram's 7 habits are a good tenets to go by
http://www.moolenaar.net/habits.html
Also I highly recommend having a go at writing a plugin. It doesn't matter what it does. It gives you the impetus to dive deep into the manuals.
Maybe, a good way is to learn vim/emacs while using eclipse. Try vimplugin or emacsplus plugins for eclipse.
This should really just be a comment, but against which answer ...
With Vim I'd suggest using the GUI version for a start, just dive in, the built-in help is excellent (:h and the screen splits adding a panel with comprehensive "hyperlinked" help pages). With vim the only potentially dangerous operation is a write, everything else you do is recoverable per command or edit (undo & redo).
The power acquired easily incentivises the learning.
Here's the way you learn: Start typing. When you hit a point where you want to do something other than typing, look up how you do that. Repeat. It helps to start with a few basics, say 7 fundamental commands. Other than that, when you run into wanting to do some operation, look it up and use it.
This great Tutorial was a big help for me for my first steps in Vim. It is a gently introduction and explain at the same time the philosophy of vim in a pleasant way:
aByteOfVim
The way I learned emacs was mostly by doing both of the following:
All the GUI menus show you the key-bindings you can use to execute the same command as that menu item. Pay attention to the bindings for the menu items you select a lot, and try them out manually next time you get a chance.
ctrl-h ctrl-h (think "Help! Help!") brings up a buffer that shows the various types of help available. If you then hit the "b" key (the buffer calls it "describe-bindings"), you will get a list of all the key bindings that are available in the buffer you are working on. Just peruse that every now and then with an eye for commands that look useful. Try them out when you get a chance.
As for vi, I learned it in the days before vim, so I pretty much had to use man vi to figure it out. Most of us emacs users will tell you that all the vi you need to know is :q! ("quit, and I really mean it"). :-)
But in truth if you are a Unix user you need to learn at least enough vi to do simple edits to config files and save them. You never know exactly what (if anything) you will get when you try to start emacs on a strange system Unix system, but vi is always there.
Nearly everything you see or interact with in Emacs can tell you about itself -- you just need to know how to ask it.
To learn Emacs, learn about the current Emacs context: what the values of things are, what the relations between them are, how they are denoted, how you can change them or otherwise interact with them.
The most important thing to learn is that Emacs is Emacs Lisp -- it is a Lisp ecosystem. Learning Emacs means also learning Emacs Lisp -- the more you know, the better. Lisp is the most flexible and most powerful way in which Emacs realizes itself as "the self-documenting, extensible editor".
Icicles can help you learn Emacs and Emacs Lisp. It helps you ask Emacs about itself. This page gives an overview of the ways it does that: Emacs Newbie with Icicles.
Don't get caught up in the vi(m) versus emacs religious war. They are both great editors. I originally started with VI (real VI not VIM) and later started using Emacs. These days, I tend to use both, but emacs more because emacs has some features I need which are not in vim.
The real challenge and what you should be aiming for is how to be as efficient, quick and accurate as possible with your editor of choice. Both VI and Emacs have a lot to offer in this respect. However, much of it boils down to two main habits you need to develop
Don't use the mouse. Both editors were created when mice were not the plague they are now. When it comes to editing, cutting, pasting, highlighting etc, both editors offer keyboard equivalents. Use them and keep your fingers on the keyboard. You will be surprised how much faster you will become
Avoid the arrow keys. This is for a similar reason. The arrow keys tend to make you move your hands off the main keyboard. In the end, this also slows you down and makes you less efficient. Both editors provide far more convenient functions which are faster.
These are the two main things to focus on when learning either of these editors. There is lots more, but to start with, just start with focusing on using the main keyboard.
After you have got that down pat, then begin to think about how you can tweak your environment to suit your needs. By this time, you will be familiar with the power of the editor you have chosen and will probably have some ideas. Both of these editors are very configurable. I find emacs is the most configurable, but you can easily get lost iin writing elisp to configure things and before you know it, your an elisp programmer who does a bit of PHP and Python. To some extent, the same can happen with VIM, but to a lesser degree. However, note that the defaults have usually been set by people with lots of experience and who probably know something you don't. Avoid making the mistake of trying to modify either editor to be what your use to. Learn how it works with minimal config first and then change once you have an idea of why it was done some way - know the rules before breaking them.
If your serious about programming, your editor will be your most important tool. Other important tools are your screen, your chair and your keyboard. The rest is incidental.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Does anybody have any tips for utilizing multiple languages at the same time? I use objective-c, c, perl, ruby, bash, ksh, rails, and other proprietary languages every day and am finding increasingly difficult to go back and forth between them on a daily basis. As a trivial example when switching between perl and ruby I constantly forget to use semi-colons in perl and find myself using $ for local vars in ruby. Things are even worse going from objective-c to c: I use function calls (instead meesage invocations) in objective-c. Does anybody have any tips on making working in several languages more productive?
For those of you suggesting IDEs as a solution, although I agree in principle with using an IDE to increase productivity. I tend to do all my coding in vi
A couple of tips:
Slow Down! We're used to working at a frenetic pace as developers. Switching between languages requires some more conscious thought and focus.
Use a good IDE - that shows your errors as you type them. This will be a gentle reminder that you are missing that semi-colon or leaving out a '$' (in many cases)
I have the same issue from time-to-time, but these two things help!
In my personal experience it's horrible to do this kind of task and technology switching, it totally messes up your brain, at the end of a day you're more a cabbage than a tired programmer. Don't do it. If your company forces you to do it start searching another job, if you are doing it for yourself, think once more if you really want this.
I use Java, Python, C, C++ and PHP(!) almost daily, and also trying to learn some more like Clojure and Perl. The best thing to do is to use a good, language-aware, syntax-highlighting, autoformatting editor/IDE that reveals trivial syntax mistakes right away. It definitely helps in switching the language mode of the brain.
I don't think that being able to code in multiple languages is much different from being able to move with a bus, car, bike or foot. The details differ, but the main idea is approximately the same.
Human memory is very context sensitive. Instead of going for one IDE/editor that covers all languages and helps you with error detection and syntax highlighting, you might want to consider going for one editor per language. I know this sounds like overkill and it probably is, so an alternative might be different themes for the editor that you switch when you switch languages. As a drastic example consider yourself using a red background when writing bash scripts and a blue background for your Python programming. With visual clues like that it should be much easier to distinguish what you are currently doing and after a little while this might work without any conscious effort.
Bullet point summary of things I've tried that have helped me:
Whenever reasonable & possible, take a break when you're switching languages
Use languages which are synergistic
Use consistent coding styles across languages
More detail from personal experience:
Switching like this can be very difficult. I've been in similar circumstances - earlier this year I was developing a web app at work with PHP, IDL (Interactive Data Language), JavaScript and some Bash and then doing some projects at home with Python. I found myself making lots of mistakes with syntax when switching from one to another.
The mistakes happened most commonly at work: E.g. when I'd been doing IDL for a while and then would switch to the PHP, I would forget to put dollar signs on the front of variables and semi-colons at the end of the lines. I didn't seem to have as many problems at home; I believe that was at least partly because it was always a few hours between getting home and starting my Python work, so the break probably helped my brain re-set from the languages I was using at work.
One thing that can help is finding languages with certain synergies: I've found that I can switch relatively easily between Python and Java ... yeah, I am still more likely to forget semi-colons at the end of my Java lines if I've been doing Python, but the two languages "sync" well in my brain, so switching isn't as difficult as going from Python to Perl, for example. I've also found it relatively easy to switch between Perl & PHP. YMMV, of course, and I expect different people will find synergies between different sets of languages.
Also, as much as you can, it may help to maintain a consistent coding style between languages. An example: for years I put an opening brace on the line after an if, for, etc. in Java, C, Perl, etc. However, after using Python as my main language for a few years, I've found that I no longer like that style, and have switched to putting opening braces at the end of lines. For me, this has helped create a more consistent appearance across languages, which I find helps ease the switching. Again YMMV.
While it gets better in time, the ability to do this kind of switching between a lot of languages on a daily basis is not for everyone. You should try "clustering" your work in such a way that you finish what you have to do in one language before taking a short break and moving on to the next. This would prevent you going back and forth and impose a schedule that will be easier to follow if you stick to it.
To issue a less abstract suggestion:
There are lots of plugins for Eclipse, and you can make it do most programming languages known to mankind (and probably a few not). However, many of those plugins are less than perfectly integrated. One is annoyingly full of advertisement for its creating company, another one is a memory hog...
For those who haven't heard about it: IntelliJ IDEA has gone (partially) Open Source, and in my experience it's very good at multi-language. I saw a demo a year ago where one of their developers built a program in 6 different languages. A toy, yes, but the IDE did a fine job on language-aware syntax highlighting, refactoring and so forth.
It won't do all your detail work for you, but it can help with some of it - and with good quality.
My recommendation is to give yourself a 15 minute break between switching languages. If you can't do that since you flip between client / server apps, then I would recommend dual screens. Separate client on left and server on right. As someone has already stated, the human mind is context sensitive. Therefore, the way you think and analyze things has a lot to do with it. Any way you can seperate the different contexes would help in making minor oops on a regular basis.
Frequently in my current job I will use different languages, the key for me to making this easier is to get the right tooling. There are some very good general purpose editors out there, which already have a long list of Syntax highlighters, checkers and even autocompletion. Most of which can be further customised. If you set these up to recognised the file extensions then a lot of the pain can be removed.
I generally use these in addition to IDEs, as most IDEs won't support ksh or other scripting, and are harder to customise so having another tool setup makes it easy to flick across. Ideally get one that runs both on Windows and the nixes
I've been using these for some time now
jedit
nedit
emacs
textpad
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I use full blown graphical IDEs such as Eclipse CDT (Linux) and Visual Studio (Windows) which have features like auto completion, built in debugging, etc. These are features that I feel I can't live without.
I keep hearing about how many people use emacs/vim on a daily basis. How come people still use console based editors when graphical IDEs appear to be easier to use? I know how to use vim and emacs, but for day-to-day programming I just use an IDE as I find myself being more productive.
This is not a vim vs emacs question so please don't argue one against the other, please instead argue graphical IDE against console IDE.
As I'm already familiar with graphical IDEs, am I likely to gain any productive advantage by using emacs/vim instead?
I expect the answer is "maybe not", simply because of the learning curve, and I'd miss the usual graphical IDE features such as auto complete and the built in debugger; but apparently emacs supports auto complete and debugging. However, to someone who uses a standard GUI text editor, I'd probably say that they should use emacs/vim. What do you think?
Related questions:
SciTE user wants to know if they should use emacs.
vi user wants to know if they should learn emacs.
There is an advantage to learning to master a command line editor for those situations where a full IDE is not available. I know people who swear by VIM and people who swear by Emacs. I think the latter is more configurable, but you might not even need that. Since you already know VI, it might be enough for your needs.
I humbly admit that in the few situations where I do need to edit not through an IDE, I just use pico... :(
All that being said, I do have the impression that for some people in certain programmer subcultures and companies, using emacs rather than an IDE is an issue of honor, like using leaves rather than TP on camping trips.
I would always suggest knowing at least one command-line only editor, be it Vi, emacs, pico, ed, etc., even if you do most of your developing in an IDE. If you're more productive in an IDE than in another editor, then by all means use the IDE.
That said, my reasoning is this: say you're installing a graphics driver on Linux, and the driver is not being co-operative. Your version of X doesn't start correctly using the new configuration, and you need to edit your X configuration. You could copy the backup of the working configuration over the edited configuration, start X, use a GUI editor to edit the X configuration, and then restart X, or you could do the edit very quickly using an editor that doesn't depend on X (typically, command line).
Eclipse has built-in support for Emacs key-bindings. The only support I've seen for Vim is a commercial plugin.
You certainly don't need to learn one or the other, and you don't need arguments extolling the virtues of one editor vs. the other, but if you do learn Emacs, you can customize your Eclipse environment to use the Emacs key-bindings (it's under Windows->Preferences->General->Keys). This (in my mind) can greatly increase your productivity in Eclipse as your hands rarely need to leave the 'home' line of your keyboard.
This feature is one (of many) reasons I use Eclipse for my 90% of my development.
I have been an emacs user for nearly 10 years. Emacs is an IDE with X support it is not console based. It does have auto completion it does have integrated debugger. The advantages i consider emacs over other IDE's are you said that you use eclipse in linux and visual studio on windows well i use emacs on both OS's. Don't need to change tools when switching OS's. Also on my daily work i work with multiple languages ruby,c/c++,java emacs supports much more languages than any other tool out there. And once you master using your keyboard you are 100 times faster than using an IDE. You can move around a file in blazing speed. i got my terminal , connection to my database server right in the editor no need to change windows and loose my train of thought. Another nice feature is i can edit files on machines half way across the world just like they are sitting on my local file system.
Disadvantages are both emacs and vi have steep learning curves in order to use them properly you need to invest some time on them but the way i see it why not master one tool that works on all languages and works on all OS's. then to learn how to use multiple tools and learn a new one when you wanna learn a new language.
Using emacs after knowing vim will make that task somewhat annoying. The editor war has been long and there have been many casualties.
In short, you should simply evaluate whether you think the editor(s) you are using currently are not up to your expectations. If you feel hindered, try something new. If you are working just fine, keep working!
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
A good while ago, I read an article by the creator of viemu, clearing up a lot of the misconceptions about vi, as well as explaining why it's a good idea (and why it's been very popular for the last 30 years+). The same guy also has a great set of graphical cheat sheets that teach the basics a few bits at a time.
I'm convinced.
I've been convinced for the past 2 years in fact. But I still really haven't gotten around to force myself to learn vi as my primary editor, the learning curve is just too high. When I get down to work, acceptable but immediate productivity (using my current editor) has so far won over tremendous productivity farther down the line (using vi).
Does anybody have any good tips to help get past the learning curve? It can be straight out tips, some other tutorial or article, whatever.
Edit: Note that I'm aware of the vim/gVim, Cream and MacVim (etc.) variants of vi. I kept my question about vi to refer to the vi family as a whole. Thanks for all the great answers.
Update (April 2009)
I've been using Vim (more precisely, MacVim) in my day to day professional life since last December. I'm not going back :-)
Good luck to everyone in their Vim mastery.
First of all, you may want to pick up Vim; it has a vastly superior feature set along with everything vi has.
That said, it takes discipline to learn. If you have a job and can't afford the productivity hit (without getting fired), I'd suggest taking on a weekend project for the sole purpose of learning the editor. Keep its documentation open as you work, and be disciplined enough not to chicken out. As you learn more, become efficient and start relying on muscle memory, it won't be as hard to stick with it.
I've been using Vim for so long that I don't even think about what keys to press to search or navigate or save. And my hands never leave the keyboard. To use Vim is one of the best choices I've made in my programming career.
The first thing I'd do is lay a piece of paper or a book over your arrow keys and your ins/home/end/pgup/down keys. Those aren't needed in Vi.
Next I'd get used to hitting ctrl+[ whenever you're told to hit escape. It's much faster and you won't need to take your hands off the keyboard.
Then I'd watch my screencasts:
http://www.youtube.com/watch?v=FcpQ7koECgk
http://www.youtube.com/watch?v=c6WCm6z5msk
http://www.youtube.com/watch?v=BPDoI7gflxM
http://www.youtube.com/watch?v=J1_CfIb-3X4
Then, just practice practice practice.
edit
The reason for avoiding the arrow keys is that they slow you down. One of the largest benefits of Vim is the speed it allows you. The arrow keys also prevent you from really embracing the modal nature, which is very powerful when mastered.
Step 0: learn to touch type. Seriously - if your fingers don't know where the keys are then vim is going to be a pain. And even if you reject vim, touch typing will improve your programming (ask Steve Yegge ) by making the mind to monitor link friction free. There is a lot of software that can help you improve your typing.
Step 1: use vimtutor to get you started. It is in gvim (under
the help menu I think) or you can just type 'vimtutor' at the command
line. It will take 30-45 minutes of your time and then your fingers will
know the basics of vi/vim and you should be able to edit files without
wanting to hurl your keyboard out of the window.
Step 2: use vim everywhere. See this
question
for tips and links for using vim and vi key bindings at the command
line, from your web browser, for composing emails, in your IDE ... You
need to use vim to embed the key bindings in your muscle memory.
Step 3: learn more about vim. You will only have scratched the
surface with vimtutor. You can watch this
video or
read this article (both about
the "Seven habits of effective text editing". You can
read
about
tips
and
tricks
on
StackOverflow.
You can browse vimtips. Learn a
litle often would be my advice - there is so much out there that
sticking to bite-size chunks will be the best way to make the knowledge
stick.
Step 4: Profit :)
I've been a on-again, off-again user of vim throughout the years (doing the occasional sys admin job). I just recently started spending more time doing my programming work in it. I'd suggest starting with gvim too. It integrates well with most OS environments, and (even better), you can fall back to the mouse when you need to :).
To get going with vim, run through the vimtutor (bundled with gVim) once or twice (takes an hour or so). I can't overstate how helpful it was for me! Especially the first parts about the different ways to move through a document, and how edit actions are recorded with motion commands, etc, etc. After that, things will be MUCH clearer.
Then, start doing quick, minor edits with it (notepad-replacement stuff) 'till you are comfortable enough to do useful editing at a rapid clip. Then try doing your day-to-day work in it. You'll find yourself pining for the "repeat last action" command in other editors in no time!
You asked for good tips to help get past the learning curve on the vi text editor. Many of the previous answers suggest you use no other editors. I think that is good advice. Switching to vi from a more graphical editor requires a change in mindset. It requires thinking in terms of commands, rather than visual changes.
I used nothing but vi for many years and believe the only way you can be productive is to memorize the commands you regularly use. The way I did this was to make a short list of the most common keyboard commands. I grouped and color-coded these commands by function, i.e. Moving the Cursor, Editing, Searching, etc. I was careful to only include the most commonly used commands I did not know. The idea is to create a quick reference that is also an aid in memorization – not to replace the available help screens. Then I printed this list and taped it to the wall behind my monitor so I could see it easily. (The graphical cheat sheets you mentioned might work better for some, but are probably a better reference source than a memorization tool.)
Here's the key. As I became comfortable with one of the commands, I drew a line through it with a pencil. I could still see it if I needed it, but it was symbolic to me that I had mastered that command. That gave me confidence and motivation as I could see regular progress. Once I had most of them crossed off, I removed them and added some of the more rarely used commands. I continued this process until I was satisfied with my command of vi. I knew I had reached that point when I realized I had not crossed off any commands or even looked at the list in a long time.
A couple years ago I had need to work on a UNIX platform where vi was the only editor available. I bought a little pocket reference book on vi, but hardly used it. I ended up making lists and posting them on the wall as I did the first time I used vi. By the end of the first week, I was very comfortable even though it had been five years since I had used vi.
force yourself not. the path to mastery love is.
For me VI is a good emergency editor, but not something I want to use if there is any other alternative available. I realize this is not for everyone though, I'm not saying it's horrid or anything, I just personally prefer a discoverable UI.
But you really have to know VI if you do anything significant in Linux!
So just learn the basics:
i=insert mode
esc=leave insert mode
:wq=save and quit
:q!=don't save and quit
x=when not in insert mode, delete the character.
/=search
That will get you through any editing emergency. There is nothing you can't do with those few commands (and navigation of course). The rest you can "Tack on" as you need them.
Keep a reference or book available though--when you NEED to use VI, you probably won't be able to browse the web--but the man page may be somewhat useful.
You should start with vim (Vi IMproved) and especially its GUI - gVim. The GUI has menus and on Windows you can use the copy, cut and paste shortcuts, so you can replace Notepad immediately. And since the menus display the shortcuts (vim commands) you could learn a lot.
Another thing that you should do from the beginning is to configure vi for your needs. For example, you can transform vim into a Python IDE. By doing this, you'll have no excuse for using another editor, because vi will offer you everything you need.
Every time you're doing a complex editing task, keep wondering if there is a more efficient way to do it. Most times, when it's something that you can describe in simple terms (like "swap paragraphs of text" or "delete everything after the X character in commented lines"), it's something you can do in just a couple of keystrokes in vim.
There are some key features that are extremely useful, and you'll end using all the time. The ones I love the most are:
Block selection (Ctrl-V)
Macro recording (q)
Virtual editing (:set ve=all)
Regular expressions
Piping to external Unix programs
Key mappings
Autocompletion (C-p, C-x C-p, C-x C-f)
The operation+movement combination (this is amazingly powerful)
Ask other programmers what features they find most useful and adopt the ones that fit better your brain. Steal ideas from other people's .vimrcs (here's mine)
delete all other text editor apps.
Then you will have to learn it.
The simplest way to force yourself might be just to remove all the other editors from your machine. Get rid of temptation :)
I wrote a guide to efficient editing with Vim a while back. You may find it helpful.
I'd step back for a minute and ask yourself "why do I want to learn this editor? What makes me think it'll be faster or better than my current text editor?" Then learn those features that will make Vi(m) indispensable to you.
For instance, Vim's CTags integration is completely indispensable for me. I work with a very, very large codebase, and the ability to jump to a function or class definition in one keystroke (regardless of which file it's in) is an absolutely killer feature, one I have trouble working without.
Use your .vimrc file to make macros that automate common tasks.
Your autopilot editor-chooser will pick the editor that will get the job done quickest and with the least amount of mental effort. A little prep-work will ensure that editor is Vim. :-)
EDIT: I've created a flashcard set over at the online spaced repetition site flashcarddb.com, in case you're interested ...
Use a spaced repetition flash card program such as mnemosyne, supermemo, or anki to incorporate learning and retaining new commands into your daily routine. It's not enough to be using vim as your daily editor. To master it, you have to be storing those codes in your head, laying in wait for the time when they're the ideal solution to the task at hand.
Maintain a .vimrc with customizations
Write or edit a vim plugin
Two things that will greatly improve your vi skills:
Practice, practice, practice
Nethack
My suggestion: start small. Just start by memorizing a small set of most useful commands. When I started vi, these were my top 10:
(Esc) to return to command mode (most important!)
a to add text after cursor
A to add text at end of current line
x to delete 1 character
dd to delete 1 line
R to replace text (overwrite)
u to undo
:q! (Enter) to quit without saving
:w (Enter) to save
ZZ to save and quit
A lot of basic editing can be done using only these commands. Once you get comfortable, the rest don't look too difficult.
BTW, I'd like to add that I used to rely on vi for my primary text editor, but now only if I have to. In my case, productivity is better when I use tools like Emacs or Visual Studio (please note: "in my case"). Try more than one tool and choose the one that helps your productivity the most. Good luck!
It sounds silly, but playing roguelike games (such as Nethack or Angband) is a fun way to get comfortable with using the h/j/k/l keys for cursor navigation.
Write down all the short-cuts and features that you use in your current editor while you're using it at work. Then sit down on Saturday morning and using Google and stack overflow find out how to do each one of those in vi. Probably best if you use a sheet (or sheets) of paper for this.
Now disable/delete the other editors at work so that it'll take you longer to find and re-install them than look at your comparison sheet and do it in vi - i.e. you have no choice.
Lastly, publish your list of crossover shortcuts from your old editor to your new one on your blog.
Good luck!
Don't use X11?
$ sudu rm /usr/local/bin/emacs
Change your login shell to vi?
First, force yourself to use ed, then vi will seem like a luxury?
Use the vi key bindings in bash?
Just start using vi all the time?
It seems to me that learning an editor isn't terribly different from learning a language. Immersion works best.
I use vi for really quick edits or when I can't use X11 for some reason, but I live in emacs. Really powerful editors are worth taking the time to learn.
My recommendation is to come up with some simple programs and write them, start to finish, using VI.
Odds are, you will be too frustrated at first by the learning curve to force yourself to use them at work or in any time-sensitive environment.
I've done this before to get familiar with environments/editors, and it works pretty well.
If you are having problems coming up with things to write, I recommend redoing projects you did in school (or anything else that you've done previously). This method has the added bonus of letting you see how much of a better developer you have become. :)
Edit: forgot to mention that you should do this entirely from the console to avoid any temptation to use the mouse!
I remember when I first started learning emacs, it was after I was already very comfortable with Vim, and I was in the same or similar boat that you were, where I knew how to get a lot done in another editor, so as I started using emacs, it was always painfully slow.
However, I think what you'll have to do is just absorb a little bit of the pain, and always, always, ALWAYS make sure that you look up the documentation for doing something that you know you can do in your previous editor, such as moving to the end of a line, or selecting a region of text.
It also helps if you have a local vi-expert on hand that you can ask questions, or if you're like our company, you promote pair programming. That way when you're trying to do something that should be easy, you can simply ask someone, they'll show you how, and if you're using the editor regularly for a few weeks, you shouldn't have to ask more then a couple of times before it becomes second nature.
If you don't have any local resources, there are plenty of books/tutorials/reference sheets online that should be able to answer most of your questions.
Ultimately, learning Vi is like learning other skills, there's no silver bullet, and you'll have to accept that, for a while, you're going to be less productive in it then your current editor. Just keep telling yourself, "Other people have been able to learn Vi, and I'm at least as smart as them" (That's what I tell myself anyway :) )
The main reason for me to use vi is ssh (or Putty on Windows): When you're logged into a Unix server remotely, then vi is always available. And it works with VT100 when neither the cursor keys nor backspace/delete are mapped.
Also having a book like VI Editor Pocket Reference helps greatly.
gVIM has a really good tutorial (link in the Start menu group).
I found working through that helped to get over the initial learning hump; and then switching my Visual Studio to ViEMU helped me hone my VI skills.
Also, the screencasts at http://vimcasts.org/ are great!
You could get your hands on one of the original Happy Hacker keyboards (no arrow keys) and place your (wireless) mouse out of reach each time you start editing.
It's easy to write out a big list of commands/shortcuts, but it's difficult to remember them all without practice.
Focus on one new command at a time. When it becomes automatic, say after using it for a week or two, add another to your repertoire.
You'll be taking the long way around to accomplish certain things in the short term - these are obvious opportunities for new shortcuts to learn.
In my experience it was easier when I tried not to take on too much at once.
My number one suggestion: learn to type fast, without needing to look at the keyboard.
If you can't touch type and are always hunting-and-pecking for the colon or the hjkl or :%s/foo/bar, forget about it. Typing can be faster than using the mouse, but if that's not the case for you, vi's not going to work.
But combine good typing skills, ssh and screen and vi will be natural.
Face the fact that it will create an immediate performance hit. When learning a new tool you need to be able to do something that you know how to do with other tools so the problem isn't your problem. After using the new tool a while it will disappear and you will be only focusing on the underlying problem.
With something like vim (as others have said, vim is vastly superior to vi) it is important to reread and browse the documentation periodically. The interface is completely undiscoverable without it. With each new reading you will see a feature and say, "ah ha, that would have solved this issue I was trying to figure out last week", and will file it away in your brain. Solutions connected to real-world problems that you've had are much easier for you to remember than random shortcuts.
In the end you can use vim with a fairly small subset of it's features, so don't be overwhelmed with all the bells and whistles. Think of all the features in Word, do 99% of the people use them?
ESC gg=G to reindent code and :retab to convert tabs to spaces or spaces to tabs was what hooked me to vim. So actually you don't need to be forced to use it, you just have to learn when it can help you increase your speed.
Go through vimtutor.
Start using vim for simple editing, like config files or html. Learn the commands as you need them.
Search google for a good .vimrc used by someone who uses a toolchain that resembles yours. Turn on syntax highlighting. Find a nice color scheme.
Learn macros because Vim is the best for automated tasks and snippet insertion, like formatting a few words into a complex XML tag or converting a CSV to an HTML table.
You might want to start out with Cream. Cream describes itself as "a modern configuration" of vim. Basically, it is a special version of vim which looks and feels like any other text editor for all practical purposes. But enable the "expert mode" and you have all the power and behavior of vim.
So you can start using Cream as a regular text editor and then experiment with the "expert mode" until you are comfortable enough to fully switch to vim.
Install gVim on all platforms you use.
Then run through the the vimtutor (:help vimtutor or vimtutor at the command line).
Watch the following lecture and follow its advice: 7 Habits For Effective Text Editing 2.0
I say you definitely want to start using it for all your editing. If you fear a loss of productivity then take a weekend to practice it solid (I once did this to switch to dvorak from qwerty and had my productivity high enough by Monday and managed to stick with it after).
It's worth the effort and you won't look back!
Personally, what I had to do was make sure that I could use the Vim key-bindings (or at least, close enough) in several applications. Having to completely switch how I edited text whenever I changed editors made it too hard to get the Vim editing style committed to muscle memory.
In my case, Viemu + vimperator did the trick.