> I still think to some degree SE shoots themselves in the foot
Do they? The reality is that SO and SE sites are optimized as a business, not so much as a community: short, common and quickly answerable questions generate much bigger traffic from search engines, and hence more ad revenue. I can imagine Joel and Jeff realized this very early on, and thus set themselves in a mission to encourage the questions that generated the most traffic and punish the ones that fall in the opposite end of the spectrum. It's really a pity, but SE is not a non-profit organization.
I'm still hoping someday someone will come up with an alternative that gathers the people and the quality of SO where lengthy and thoughtful discussions are welcome. Some argue that's Reddit, but I'm not entirely convinced.
I think the common view of looking at great answers like this and thinking, "wouldn't SO be great if discussion was allowed" is similar to looking at a great work of graffiti art and thinking, "wouldn't be great if every kid with a spray can could paint all over the city".
These answers are outliers, special snowflakes among a sea of crud that fills the programming PHPBB boards out there. Joel and Jeff were trying to solve the bigger problem - having a decent Q&A system -, and that can only be done by looking at the average case and not the exceptions.
> "wouldn't be great if every kid with a spray can could paint all over the city".
The thing is that, unlike in other places, people can upvote/downvote stuff on SO/SE sites, and just like crappy questions and answers are quickly buried by the community the same could happen to subpar discussions, so I don't really think that's a valid excuse.
I disagree. I don't think SE turns people off when questions are closed, or discourages people from asking another question. Sometimes, you'll see a closed question asked by the user who go their question closed come up in meta, and the user will receive very constructive feedback.
The SE community works very hard to keep things on topic. The questions that come up on Hacker News are very interesting, but often times fit the definitions of being off-topic or not constructive. I don't think their closure has had any effect on the frequency of those really interesting off-topic questions.
Also, imagine if SE allowed these types of questions. The community would be overrun by flame wars and turn more into a discussion board, not a place to get answers.
On the other hand, I don't think closing questions has a strong enough effect to discourage people from asking off-topic or otherwise poor questions (see the Programmers.SE board for an example). It's been going through Eternal September for a couple of years now. (I'm not going to give an example of, what is in my opinion, the best moderated SE board since I don't want it to get any exposure and suffer the same fate)
So in closing, there's rhyme and reason to SE closing questions, and I don't think it hurts the site.
Two sites with two different intentions. Hacker News is for reading interesting things and learning, StackOverflow is for getting answers to problems. I don't think SO would benefit from leaving popular non-constructive questions unlocked.
Not if you choose the right venue. Now that I read the question, you're right that it'd probably be blocked on any SE site because it's a poor fit for their Q&A format, but SE is not the only programming community online.
oh- and in the interim, it will receive attention from but 1% of the qualified posters SO has.
So? Should I start posting the results of the UEFA Champions League here just because there are many interesting posters here?
I've never understood the appeal of vi(m). Programming is a thoughtful, creative, deliberate process. I'm never in a situation where I've got so much to type that my productivity would drop if my fingers stopped touching the keys. Rather the opposite in fact.
Actually, if you are in 'insert' mode in Vim all the time "you're doing it wrong". Vim shines when editing and tweaking existing code. You should be in 'normal' mode almost all the time, where you do your "thoughtful, creative, deliberate process" by reading and navigating the code base, and reformatting, moving, copying and deleting code, to get it just the way you want.
If you are just doing straight-ahead typing, you're right, Vim won't help.
The book "Practical Vim" has a nice analogy with how artists work. "Pause with your brush off the page." Painters do a lot of things besides applying paint to the canvas. "The painter does not rest with a brush on the canvas. And so it is with Vim. Normal mode is the natural resting state."
I'd really like to see a usability study between Vim experts (10y+ usage) and Sublime Text 2 (1y+ usage) experts on a keyboard+good touchpad combo. We could even do it in theory by counting number of actions and assume the APM in vim to be 10% higher (which is quite optimistic).
Surely if you need to pack reformating, moving, copying and deleting code into as short a time as possible you're doing it wrong even more than if you had to insert a lot of text!
This leaves navigating as the main reason for vi's UI. And macros, apparently. If that's what you want, great, but it's not for me.
As others have said: You didn't learn touch-typing to churn out text as fast as possible. You learned it because it creates a more direct interface between brain and machine. It doesn't hinder your toughts, doesn't break the concentration.
It's the same with vim editing: The idea is not to be able to move code around as fast as possible but to do it without thinking. It's a step closer to the perfect brain-reading computer with which writing code is only a matter of imaging it.
For a new code base, you might be right. As code bases grow, so does cruft - and the older the code gets, the more it requires moving things around just so before you can add new items.
For me, it isn't typing speed that makes vim better. It is the speed at which I can make very direct and precise edits to something that I have already typed. Especially repetitive edits, where the pattern can be recorded.
When trying to hold a problem in my brain's working memory, a bad editor turns a simple change into a swap-to-disk event.
Right, it becomes automatic thought->fingers edits. So yesterday, when I was dealing with some javascript on a webpage, i had a realization that if I did some restructuring of my closures, the code would be smaller and simpler to understand. As soon as I was thinking my fingers were already setting a couple of marks, and putting various lines at various indent levels[1]. Then I thought, these need to be grouped together by indent level, and the reordering was happening, again almost background. I never once thought get rid of this line here and put it here. I thought, ok move this line down a few, move this chunk to the outer scope. Put these lines in a separate function.
Yes I could do this slower/more methodically with other editors, but I tend to think visually, so I visualize the text transforming as I think about the code. The power of vim for me is that I have a language of text transformation that can be simply translated to commands at a speed near to me thinking it.
Much like when typing documents, words in head -> text on screen doesn't involve a lot of "and now i press 'a', now i press 'b'".
[1] at one point this would have been a conscious decision, but since I try to maintain consistent indenting to help define scopes, and since vim has a lot of good indent/unindent commands, I had a realization that this could help refactoring. After some practice it became automatic since its a simple << or >> in normal mode to change indent level. Now it has become a wired pathway in my head, so I just think, "oh this goes up a scope" and the actual steps of "so dedent which means press <<" never registers.
This is something to aspire to (for me). I rely on a core subset of vim commands far too often, and need to expand my vim vocabulary. It's a matter of investment in one of my most important tools. Unfortunately I'll probably need to do it a few times so it sticks, or review everything but only focus on integrating into my daily routine a subset of that each time so there's a chance it sticks.
Every 3-6 months I review my understanding of VIM, browse the help manual, browse the vim tips site, and browse the vim subreddit. I find a few things I don't know but actually look useful to me, and queue them up for workflow integration.
Then I pick one for a week. I consciously keep it in mind, and when I notice I didn't use it, I undo and force myself to do the other way. Eventually it's enough to get the habit. So I move on. Repeat until the queue is empty. Then let all those things settle in for a while and after a few months, go to the top.
The other thing I forced myself to do is: become aware of random frustrations or annoyances when using Vim. The question "is there an easier way to do this?" has a disproportionately high nubmer of "yes" answers, so I track down then and there how to do it better. The reasoning is that - if I'm getting annoyed, it's because I keep having to do something, so right now is a good time to learn the solution while I have a bunch of practice available in my normal working day. The trick is to realize that it's like writing a script: i'll put some time in up front right now, but the work will overall get done faster, and the long tail of future improvements will add up to huge gains.
The final thing to note: I regularly rediscover Vim features. Like you mention, stuff just slips out sometimes, it's no big deal. My current workflow and common command set is different than it was a year, or 2 or 3 years ago. Some things I'm sure I'm less efficient with, and other more. But overall the trend is towards more proficiency and better usage, so it's OK that stuff comes and goes from my awareness :)
Do you understand the appeal of touch typing over hunting and pecking?
Touch typing is hard at first. You have to force yourself to learn it. But once you do, you don't have to think about typing anymore. Isn't learning to touch type liberating to your productivity and thought process?
Touch typing is a great skill to have of course, as is using keyboard shortcuts. But I can get by with standardised shortcuts, and I'd prefer not learning a new set of shortcuts used by a single program, especially when that program has a modal interface. Maybe modal keyboard interfaces are used by more than vi, but I don't know of any other programs that have one.
So what other programs do you use that have a balance parens command? or shift text left or right? Beyond the basic movements, all your "interesting" shortcuts are specific to your text editor anyway.
Unless you're using emacs on a Mac, in which case you have emacs keybindings in all the standard text fields anyway.
Or if you're using MacVim, which supports the standard mac cursor movements (command-arrow to end of line, option-arrow to move by word, option-delete to delete word, etc)
Once I fell in love with modal editing, I started using it everywhere I could. vi(m) bindings in my shell, web browser, etc. I wish it were seamless everywhere but it's certainly more ubiquitous than just one program. Couple that with a working knowledge of emacs navigation keys which work throughout OSX and thing become a lot nicer.
Having to touch the mouse while just editing text slows me down and breaks my rhythm.
My standard vim configuration is this:
set ts=3 "I like a tab space of 3
map <F5> :set hls!<bar>set hls?<CR> "Turn text search highlight on/off with F5 key
You can add more stuff, but the basic functionality I use everyday is just there. It takes me the actual time to install vim (if it's missing) and plug in those 2 lines and I'm ready to edit.
Using buffers comes and goes for me, I'm not a vim power user, I usually cut/paste blocks of text by checking the line numbers and doing :<start#>,<end#>y to copy, and p to paste. I learned to edit back in the day using a modified version of ed on a MUD, so my approach probably
isn't the norm, but it's always worked for me. Adding
Cscope as a backend pretty much makes it do everything Eclipse can do, only faster.
I usually am not adding tons of text at once, more usually I have my window split (:split <filename>) between a couple
of source files pondering what is broken/working/needs to be added.
However, someone starting out can make more sense of one of the Wysiwyg editors, vim and the like (emacs comes to mind obviously), require a little more time to make productive. Once you have enough arcane incantations, the thought of doing something and the action happen almost instantly, and it's very, very, very hard to go back to having to interact with a mouse-based editor (I still use my mouse for copy/paste in some situations, though, so I suppose it's not as big a deal as I feel like it is).
seems like instead of copy and pasting like that you would be better served pressing V and using some form of block navigation.([,(,{, etc.) see :help text-objects for more examples. or a search would work as well for some queries. /textToFind then enter and then navigate to fine tune your selection if it's off by a bit.
Right, the line number is mostly just my habit. Occasionally I'll just yank with a regex, ie: y/<regex>, but that usually requires stopping to think.
I guess my point is there are a lot of ways to do things in vim, and even just learning a couple of them is in general quite powerful. Additionally, being able to use regex's with commands is very useful, and something not readily apparent if you aren't much of a regex user.
The line number thing is generally a search to first line (line number is in the ruler at the bottom of my vim window), search forward to last line, execute command. I suppose this is actually an ed-compatible command, older than vi.
I think people overestimate how much time they spend doing repetitive tasks like copying and pasting with definable patterns. I'm a Java programmer, and I certainly do this, but I can almost always use a simple search and replace to make it work in IntelliJ. But, for the sake of argument, let's say that if I were to do this once a week, maybe for five minutes, copying and pasting manually with a mouse, that five minutes might feel like an eternity. Vim would do this quickly, but it would also slow me down when I do project-level refactoring, like renaming a method, which IntelliJ does globally in a matter of seconds. Sure, you can configure Vim to do this kind of stuff, and you can combine it with other tools... but at what point are you getting diminishing returns?
On top of it, as a web developer, I already need to know so much, from front end with HTML, CSS, JavaScript, jQuery, to Servlets and Spring MVC, to SQL and all of the glue that binds all of this mess together like XML and supporting tools like SCMs. My head is absolutely full of information. In this environment, I am convinced that Vim is a complete waste of my time. A good IDE is ten times better at handling the vast majority of tasks I encounter day-to-day.
If anything, I think Vim is like truck nutz for programmers. It's all about projecting an image of competence and bravado.
I agree with parts of your comment, except for two extremely erroneous phrases. «My head is absolutely full of information.» and «...Vim is like truck nutz for programmers...»
- If your head is absolutely full, do yourself a favour and stop working in IT. Go do something else. There is now other way to put it.
- Go watch someone proficient in vim at work. You'll lose that image of truck nutz you have.
I do consider vim the wrong tool for the job of editing Java code. Refactoring with Eclipse (in my case) is wonderfully powerful and something impossible to achieve with vim. HTML/CSS/Javascript/XML/most everything else? VIM. Absolutely.
Even with the wonders of Eclipse refactoring tools, I do miss vim many times. VIM is like the command line of text editors: lots of small tools, with incredible combinations.
As for the bravado, everyone knows real programmers program using butterflies: http://xkcd.com/378/
A few examples of why vim has some non-obvious power:
* html you can change inside of a text object. If you are say anywhere inside of a link <a href="som|e link"> you can ci< and you have deleted the whole thing and are left with <|> (where the cursor is denoted by |) If instead you typed ci" you would be left with <a href="|"> this is a very powerful pattern
* you can script little macros that do text editing on a macro scale very efficiently. This is more useful than a simple find and replace.
you want to make a list that starts with a number, has that number in it and is incremented by one(or two or...) every time.
Type the first sentence
1, xv001, "", more stuff.
exit out of insert mode. jj or esc
start recording the macro into register r: qr
yank the line and paste it yyp
go to the beginning of the line 0 or ^
increment by one and move one word right and increment the next number: ctrl-a w ctrl-a
move down one line, j
exit recording q
run macro r 100 times 100@r
The nice thing is that if you mess something up you can paste whatever is in register r, edit it, yank it back into register r and run it. It sounds like it's slow but it's all real time editing and you are doing it interactive so you don't have to do it blind.
There are many more things that make vim style interactions a boon to your productivity but I don't have a lot of time to comment on it. hopefully I touched on enough that it piques your interest to at least give it a shot.
Vim is so popular that you can get pretty good emulation in a lot of IDEs so you can have the best of both worlds. vimemu for Visual studio is supposed to be very good. eclipse has eclim, hell even emacs has evil mode.
Well the formatting got messed up and it's too late to edit it:
* html you can change inside of a text object. If you are say anywhere inside of a link <a href="som|e link"> you can ci< and you have deleted the whole thing and are left with <|> (where the cursor is denoted by |) If instead you typed ci" you would be left with <a href="|"> this is a very powerful pattern
* you can script little macros that do text editing on a macro scale very efficiently. This is more useful than a simple find and replace. you want to make a list that starts with a number, has that number in it and is incremented by one(or two or...) every time.
Type the first sentence 1, xv001, "", more stuff.
exit out of insert mode: jj or esc
start recording the macro into register r: qr
yank the line and paste it: yyp
go to the beginning of the line: 0 or ^
increment by one and move one word right and increment the next number: ctrl-a w ctrl-a
Java is not a language I program in. I have used it in the past in its typical environ: over-engineered, over-abstracted monstrosities and during that time I indeed had to refactor a piece of code a couple of times.
Currently I work in C++, Python, JavaScript and Common Lisp. Auto-completion is pretty OK and the need to refactor comes up, well... never. Note that these two features are brought up the most when people want to praise the advantages of IDEs over powerful text editors like Vim and Emacs.
(Actually, Emacs' default Common Lisp environment is unsurpassed by modern day IDEs.)
One gains so much editing power in manipulating text objects and navigating through code by using Vim (well, Vim emulation in Emacs in my case) that I gladly trade in the ability to effeciently refactor enterprise-level Java or C++ code.
Even in a non-Vim text editor, I dislike moving my hands off the keyboard. It's not a productivity thing for me; it's a preference thing. As a web dev (and I hate that most of the interactivity I have to program is mouse-based), I prefer to bring up the dev tools using the keyboard shortcut, and then another shortcut to focus the command line.
I make it a point to stay relatively vanilla on my web browsers, because it helps keep my experience roughly the same as those of my users. If I ever stop developing professionally for the web, I probably will check Vimium out. :)
I've never understood it either apart from the initial euphoria of it being "something that hardcore Linux fans use". I'm not dissing it either. We should use any editor that we are comfortable with, if it's vim or something else. If your code sucks, it'll suck equally on vim or any other editor.
I can only say that when I'm using a keys-and-arrows editor like Notepad, I can barely think because I'm typing - a - key - at - a - time, but when I'm using vim I'm just thinking and seeing my thoughts.
For me it's the little things. I use the keyboard constantly to move around my code. I switched to SublimeText2 for a couple of days and the 1 second of added time it took to move my hand to the mouse to move around or use a gui interaction really slowed me down. It really surprised me how that little bit of time was just enough to break my flow. So when I say vim makes me faster, I mean that it itself is fast enough to keep up with my train of thought.
I always kept switching from Vim to Sublime text until I found this:
http://vim.spf13.com/ The Ultimate Vim Distribution
It's a collection of plugins and common shortcuts such as :W becomes :w, :w!! for saving as root, etc...
In the beginning it was mostly the file-drawler that make me want to leave Vim but that was easy solved by using this version:
https://github.com/alloy/macvim
In combination with iTerm on mac it's my preferred way to develop, the only thing I miss is an easy way to reload, visit pages etc in the chrome-window on my second screen without having to lift my hands from my keyboard, but cmd+tab and Vimium help me with that.
I wish vim was a little bit more "international" because some commands that involves {,^,[ combined with ctrl are tricky to trigger on non-us keymaps and don't feel as natural as `yy`. Some obvious keys that only need 1 keystroke for an US user requires a combination of alt-gr or something for french users. Soon I'll be remapping my keyboard for coding but I also need those é,à,ç,è :)
For a time, I was working on gathering some good data on keyboard layouts. I wanted to work out which keys were commonly available, which weren't, and so on. I wanted to work out which characters were the most "i18n-friendly" for developers worldwide.
One day, I happened to take a programming class in Brazil. I noticed that a lot of students were simply switching their keyboard layout to US English in order to write code. I ditched that project.
Still a bit weird if you type on keys that actually mean something else. Especially german keyboards are not designed to code with (for instance \ required three key strokes on a Mac keyboard, [ and ] are also pretty hard to reach...)
After a year of coding on a German kezboard (sic) set to US eng I finally bought little stickers and relabeled the []{}<>#_| keys. So much better not to have the cognitive friction anymore.
This, and learning to touch type helped a lot. And on top of that all kind of shortcuts different programs use become more logic, such as the [-key for changing the brush size in Photoshop, cmd+[ for indenting in textmate...
Besides mapping these keys to other keys you rarely use, such as the capslock, you can also change your keyboard layout on the fly. I use Cmd+Space to switch layouts.
I have switched to US-International with AltGr dead keys. Took me 3 weeks to adapt to the new layout - but man what an investment! I had learned before this German and French layouts - it was a loss of time if I look back now. On Linux you have this layout almost on all distributions, on Windows you have to install it separately. Concerning the accents: with the US-International you have all the French accents + a lot of more - I can now write French, German and Turkish with a single keyboard, without changing the layout! And it is possible even to write capital letters with accents: ÇÉÈÂ. If you need to sometimes work with the keyboards from other people - at least the US layout is ALWAYS installed (in Windows most of the time you can switch to it with Alt+LeftShift). The downside is that there are not many Laptop vendors that allow you to chose the US-International layout, this is one more argument for me to stick with ThinkPads.
From the accents that you posted it looks like you use AZERTY layout. Do the switch to US-International and you will not regret. The AZERTY is awful for developers (and even for normal writers).
It is totally legitimate to remap keys so that they are comfortable for you, that is why everything is customizable, don't let anyone tell you that there is only one way you have to use vim
I already re-binded many things but I think changing the keymap might be easier in the long-term because I don't have to support my modifications and keep them up-to-date when I add more functions or when I discover more vim bindings.
It seems as though the asker doesn't know about mapping, which wasn't really addressed and would answer the implied "I don't like how this feature works and it's slowing me down" question. It only takes a few lines to work around vim's "horrible" copying and pasting:
let mapleader = ","
let g:mapleader = ","
noremap <leader>a ggVG
noremap <leader>c "+y
noremap <leader>v "+gP
noremap <leader>x "+x
I love Vim. I understand the 'Vim is a language' concept, and use it every day.
But I have to wonder: is this the best that Vim can do? Vim as a language is a great concept. But IMHO, the execution sort of sucks. Twenty years have gone by, and 'Vim as a language' is still a big mystery that takes a long long time to understand...
Someone should take that concept and run with it. Surely 'editor as a language' can be done better.
One way to improve stuff would be to show you how you could have done stuff more efficiently.
For example if you press v and then repeat l until you're at the end of the word, and then do something with the selection, vim (or a plugin maybe) could tell you 'hey, you could have done that with ve (e moves to the end of the current word)'.
The idea that really excites me is 'STRUCTURE editor as a language' - that is, the same sort of grammar as Vim, but manipulating semantically meaningful structures like expressions or functions instead of text. I'd love to see an editor reenvisioned completely around that concept, with "normal" text editing only as a fallback.
(Of course, Vim does have text objects, which are fantastic - one of the chief reasons I use Vim. But they have limitations; I think you can go a lot further.)
Take a look at the E editor, it marries Vim's exceedingly efficient editing language with semantically meaningful text objects.
http://en.wikipedia.org/wiki/E_Text_Editor
(The website seems to be down, which is a shame)
Or if you have days to burn, emacs+paredit+evil can russtle quite a few jimmies if you take the time to define some custom keybindings for it.
The significant development there is to efficiently work with ASTs for the different languages. Maybe the only reason that kind of implementation isn't shared is because it is typically rolled into commercial IDEs rather than being opened up and exposed in a way that is accessible to existing editors.
so have I got a deal for you :) Anyway, my recently published "nestgrid" framework is precisely that (among other possible uses). A mix of xml editor, spreadsheet, direct manipulation of objects ui, and all around cool thing; flash demo included. See http://nestgrid.wordpress.com/nestgrid-paper/
Believe it or not, Emacs is quite a fluent speaker. I was surprised to find that even esoteric things like rectangle selections work perfectly and :%s incrementally showing the results of your search and replace as you type is a hoot.
Sure, emacs has its own accent and quirks, but after using emacs+evil as my only text editor for the last year, I'm now convinced that emacs is a better "vim" than vim itself is.
I could go on and on about how using evil+emacs brings vim keybindings to my editor, mail client, music player, IM client, etc which vim could never provide. I could talk about how wonderfully extensible elisp is for hacking up Emacs' core internals. But at the end of the day, I only use emacs+evil because it's an environment that I'm comfortable with.
If you have a few days/months/years to lose yourself down this rabbit hole, why not give it a try?
Any language takes some time to understand and even more to use effectively.
Understanding Vim's nOm command pattern is pretty easy (repeat n times operator O to text motion command m moves over). But using it effectively takes some practice. Committing it to muscle memory takes about 6 months (same amount of time it takes to master touch typing). You cannot do this faster.
Becoming an expert (which means not only effectively choosing and using commands to transform some text, but knowing a decent subset of entire functionality and also knowing how to extend the functionality) takes even more time.
And if your language were that primitive that mastering it can be done in a day or two, would it really be that complete and high level enough?
That wasn't true for me. Working through vimtutor for vim and the `C-h t' tutorial for emacs, followed by some spaced repetition over the next few weeks, got the basic motion commands of both editors fully ingrained in my muscle memory. It took longer for my fingers to internalize using operators on text objects in vim, but you can definitely master the basics in a few days. Even though I use vim as my daily editor and haven't really used emacs (at least with emacs-style keybindings) since working through the interactive tutorial years ago, it only takes me a few seconds to get comfortable navigating an emacs buffer without having to think.
Granted, emacs keybindings deliberately don't constitute a language (the whole point of emacs is to remap them for different functionality in different contexts), but I don't think it took me much longer to "become an expert" at vim's language of editing.
There's a lot more that the language of Vim can do than what's in this article. You should check out this screencast on vi/vim's command/text equivalence (analogous to LISP's code/data equivalence):
http://blog.extracheese.org/2010/11/screencast-custom-vim-re...
Also, this thread's article doesn't go into keys like ftFT;,#* or the incredibly useful Vim-specific feature called text objects. This gives a good introduction to a lot of that: http://www.viemu.com/a-why-vi-vim.html
I am a Vim user too! Because of my curiosity, I tried Emacs and I was amazed how easy it is for beginners! There are very simple quick-start guide that don't force to use all the great features just yet. And all things that can be confusing for beginners are turned off by default. We can learn something. :)
Also, I like to think that Vim is not an editor. It's a language or, you may even say, a concept of editing text.
The mouse is a much easier language to learn and more versatile (it took me fifteen years to become as fluent with the trackpad as I got in a few hours with a mouse). It doesn't make you think you're more productive, but it does actually make you more productive. (See "Tog on Interface".)
The fact that die hard vim users are amazed whenever they learn a new trick they never encountered in ten years of using vim every day speaks for itself. (And happy mouse users look at the obscure shortcut for incrementing an integer and shrug.)
Sometimes, the mouse is all you need. That's understandable.
Other times, what you need, is to append a certain string to every line in the text containing a certain regular expression. Other times, you need to delete a column of characters and move that column somewhere else.
Vim (and emacs) is not about the most common keystrokes. It's about every other obscure and relatively rare task that comes up, that in total, add up to become a huge chunk of the working programmer's time. Yes, adding characters to the beginning, middle, or end of a line is easy without vim. Yes, moving up and down paragraphs or around the file can be done without vim. The power of vim is not manifest in these simple maneuvers, but in its expressiveness in handling every other exceptional case.
Every time a vim or emacs user tries to convince me of the virtues of their insanely "powerful" editor I ask them to demonstrate a use-case and have yet to be impressed by a single response. Every example in the stack overflow thread leaves me bored -- if you like tinkering with macros rather than actually getting something done, enjoy your "language". This is the old command-line versus GUI argument writ small.
What I like is watching the vim or emacs advocate show me their macro examples and then showing them how BBedit (for example) leverages regexp (and provides lots of learnable shortcuts, macros, and scripting support) while getting you enormous benefits out of the box because it uses a mouse.
The difference between CLI and GUI is simple. The latter is highly optimized for a particular workflow and to perform a set of preconceived tasks that are baked with a release that gets an occasional update.
If you asked me to show you why I find value in editors like vim and emacs, I'd show you a DSL I wrote for work purposes and show you the extensions I wrote to edit them efficiently. Alternatively, I'd show you a number of customized workflows for cross compiling lua to C# or something.
I've used sublime text, textmate, bbedit and I'm not saying they aren't well designed editors. They are and if the stuff you are doing is stuff that everybody is doing, then great. But I don't think you understand that at this point in time, none of these GUI-based editors come even close to satisfying my personal needs as a developer.
Although I'm a Vim user I appreciate your comment and think you have a good point. However, I can't stand when a commenter anticipates a negative reaction to their post and dares readers to downvote them.
Of all the communities online, let's have faith that at least on HN a well-argued comment will receive recognition whether or not it reflects a popular opinion. To bait downvoters is to imply that this community prizes popularity over integrity, and in doing so polarizes the discussion.
No. The vim language has a simple and easy to understand grammar that is very close to that found in many natural languages. That part is freaking easy to grasp. The vocabulary is a lot bigger, though, but like with natural languages, you can be a perfectly functional speaker/user without knowing everything there is to know. As long as you make yourself understandable and know how to use a dictionary you are fine.
And, like with all natural languages, practicing, making mistakes… are keys.
vim is not for everyone and if it was too easy, it would probably be limited, perhaps even loose some respect. To attain a certain high level of usability things naturally start becoming more complex.
>Surely 'editor as a language' can be done better.
everything can always be done better, but its a matter of doing. When the doing starts, it will appear that its not as easy in execution as conception.
The thing is that vim is actually pretty simple to learn. The arrow keys still work. in macvim you have a high level of usability out of the box with mouse support enabled, copy and paste from the system pasteboard using normal keys, etc....
Even if you are using vanilla vim you can learn the basics of how to edit a file to notepad levels in about 1 min. (command line vim "new file name", press i, use as a normal editor, press escape, press :wq)
vim -y starts vim in "easy" mode where vim essentially behaves like dumb editor like Notepad++ would. And even in terminal (at least in OS X with iTerm2) you get mouse support for cursor positioning and visual selections.
I am only interested in hearing about this from people who already actually understand vim. It is not that hard to understand, but if you do not understand it then you are just going to produce something else you like and fail to capture what worked in vim.
On the contrary, I think people who are already comfortable with vim have a harder time identifying the pains of learning it.
There are many problems that started out as pains but are second nature to us now, so we don't think to optimize them.
I remember spending a ridiculous amount of time trying to figure out link and include paths to add a new library in visual studio when I was a new programmer. Doing so now is so easy I hardly need to think about it, but in reality it hasn't gotten any easier. I am simply familiar with the process.
Really, installing a new library should be as straightforward as installing an extension in a web browser. There is little essential complexity there, and yet this process has not become easier (in C/C++) for decades.
Anyone who knows enough about how to solve the problem has already groked it and isn't interested in solving it anymore. This is the problem I see with wanting an improved vim from someone who is already a vim expert. The problems they have with vim are disjoint from the problems a new programmer would have with vim.
What I will say is that if you are going to create a new editor, by the time you are done you should have become an expert in all the major text editors. You're absolutely right that any new editor should have seriously considered the features available in vim and emacs and others. However I have no problem with someone who isn't an expert getting inspiration to create their own editor out of their frustrations with vim. Many great things were stared in similar ways by people who weren't experts (yet).
I still think to some degree SE shoots themselves in the foot with the strict enforcement of their rules every time this occurs.