3 ms·

>text entry speed is irrelevant Tools help you think in units of your usage of them. If you produce more words in a given amount of time with one editor over a

>text entry speed is irrelevant Tools help you think in units of your usage of them. If you produce more words in a given amount of time with one editor over another, then the faster editor will enable you to begin thinking/planning in bigger blocks of a text at a time. Arguably though, vim's strength isn't text entry speed alone but faster abstract manipulation of text. Use a tool long enough, and it's best use cases become the default cases you lean towards when planning your next move.

robomartin 7y ago
Nope. Text entry facilitation is useful but irrelevant. Go work on code for an MRI machine, a spacecraft or an implantable insulin pump (all of which I have worked on) and see just how much you care about how quickly you can enter text or manipulate it. The answer: It is absolutely irrelevant. You will spend 10x, 100x, 1,000x longer doing other things that are actually important. I said this in another comment: Real software development is not assembly line work. It isn't mass data entry. Because of that text entry speed and efficiency is immaterial. It can feel good to have auto-completion and such tools, but, at the end of the day, it doesn't produce better code with less bugs any faster than any other approach. If text entry speed were important I would still be using APL (which I used professionally for ten years). In one line of code you can write what would require tens to hundreds of lines with other languages. If this were the case everyone would be using APL, because, if you want to compute at the speed of thought you need that kind of an approach. Reality, on the other hand, is that solving problems computationally is far more than text entry. A simple thought exercise would be to take three teams solving the same real problem. For example, writing the code to run an implantable insulin pump. One team uses vi/vim. The other uses Notepad++. The third uses a modern IDE. Which team will deliver a fully-functional, safe, bug-free product that will pass all necessary tests and ship to customers without killing them? Which one will do so faster? The answer is: The editor/IDE choice has nothing to do with both of these questions. And, in fact, when things really matter, you care far more about good bug-free code than how fast you wrote it. Banking or spacecraft are other examples of this. It's OK to use whatever tools make one happy, no issues there. Just don't lie to yourself about what they are and what they are not. Another view: I would not hire anyone who insists on using vi/vim. I don't deliver code-writing athletic performance. I deliver hardware+software products that have to work correctly and, ideally, not kill anyone. Coming in with a misplaced religious view about code entry means the person has no clue about the reason we do what we do and what's important.
- trepatudo 7y ago
  If you won't hire anyone using vim, you might not want to hire anyone using VS Code, I would say since most of "modern vim" users share LSP usage. But better yet, if you will hire people based on their tools and not their skills, you might want to stay away from that department.
  - jdlshore 7y ago
    I suspect the key phrase there was "insists on." And I can see where they're coming from. If choice of editor is so important to someone's programming style that they won't accept anything else, it makes me suspect their priorities are misplaced.
  - robomartin 7y ago
    That is exactly diametrically opposite what I said. And I did not discuss “tools” just the vi/vim cult. I don’t have a problem with someone using vi/vim so long as it isn’t a cult. I don’t care about tools or how many ways someone can write code to identify a palindrome or generate Fibonacci. I care vastly more about how people think, how creative they are, their attention to detail, resiliency, philosophy when faced with failure, ability to learn, approach to facing areas where they might be weak, ability to communicate, organizational skills, honesty, humbleness and more. Notice I could not care less about coding speed or someone being a code puzzle database or how quickly they can enter 300 lines if code. In the context of what real work is about these things are as irrelevant as what brand if shoes they wear.

robomartin 7y ago

Nope. Text entry facilitation is useful but irrelevant. Go work on code for an MRI machine, a spacecraft or an implantable insulin pump (all of which I have worked on) and see just how much you care about how quickly you can enter text or manipulate it. The answer: It is absolutely irrelevant. You will spend 10x, 100x, 1,000x longer doing other things that are actually important. I said this in another comment: Real software development is not assembly line work. It isn't mass data entry. Because of that text entry speed and efficiency is immaterial. It can feel good to have auto-completion and such tools, but, at the end of the day, it doesn't produce better code with less bugs any faster than any other approach. If text entry speed were important I would still be using APL (which I used professionally for ten years). In one line of code you can write what would require tens to hundreds of lines with other languages. If this were the case everyone would be using APL, because, if you want to compute at the speed of thought you need that kind of an approach. Reality, on the other hand, is that solving problems computationally is far more than text entry. A simple thought exercise would be to take three teams solving the same real problem. For example, writing the code to run an implantable insulin pump. One team uses vi/vim. The other uses Notepad++. The third uses a modern IDE. Which team will deliver a fully-functional, safe, bug-free product that will pass all necessary tests and ship to customers without killing them? Which one will do so faster? The answer is: The editor/IDE choice has nothing to do with both of these questions. And, in fact, when things really matter, you care far more about good bug-free code than how fast you wrote it. Banking or spacecraft are other examples of this. It's OK to use whatever tools make one happy, no issues there. Just don't lie to yourself about what they are and what they are not. Another view: I would not hire anyone who insists on using vi/vim. I don't deliver code-writing athletic performance. I deliver hardware+software products that have to work correctly and, ideally, not kill anyone. Coming in with a misplaced religious view about code entry means the person has no clue about the reason we do what we do and what's important.

trepatudo 7y ago
If you won't hire anyone using vim, you might not want to hire anyone using VS Code, I would say since most of "modern vim" users share LSP usage. But better yet, if you will hire people based on their tools and not their skills, you might want to stay away from that department.
- jdlshore 7y ago
  I suspect the key phrase there was "insists on." And I can see where they're coming from. If choice of editor is so important to someone's programming style that they won't accept anything else, it makes me suspect their priorities are misplaced.
- robomartin 7y ago
  That is exactly diametrically opposite what I said. And I did not discuss “tools” just the vi/vim cult. I don’t have a problem with someone using vi/vim so long as it isn’t a cult. I don’t care about tools or how many ways someone can write code to identify a palindrome or generate Fibonacci. I care vastly more about how people think, how creative they are, their attention to detail, resiliency, philosophy when faced with failure, ability to learn, approach to facing areas where they might be weak, ability to communicate, organizational skills, honesty, humbleness and more. Notice I could not care less about coding speed or someone being a code puzzle database or how quickly they can enter 300 lines if code. In the context of what real work is about these things are as irrelevant as what brand if shoes they wear.