4 ms·
Editing text is maybe 9% of what I do. Most of my work consists of reading text, thinking about it, running tests, reading the results of those tests, thinking
by marssaxman 9y ago
Editing text is maybe 9% of what I do. Most of my work consists of reading text, thinking about it, running tests, reading the results of those tests, thinking about what I've read, discussing what I've been thinking about with coworkers, reading more text, and thinking some more. It has been this way for most of my career. This is what I see most of my coworkers doing, too. Editing text more efficiently simply wouldn't make any measurable difference in my productivity, because editing text doesn't take up that much time to begin with.
- rebootthesystem 9y agoThat is precisely my point. To devote any effort at all optimizing this is to go after the wrong optimization target. Just buy or use a good IDE that helps you with tasks beyond text entry and move on. There is no value to be gained doing anything else.
- thomastjeffery 9y ago> Just buy or use a good IDE that helps you with tasks beyond text entry and move on. Why can I not have both? > IDE Integrated Development Environment. Why would you want your compiler and your debugger to implement your editor? That's like selling a hammer with every box of nails. Sure, I will be using both, but I really like my hammer. The handle feels right in my hand. The balance is just right. Your hammer is cheap and clunky. It may not bother you, but that is no reason for me to use it.
- thomastjeffery 9y agoPersonally, I don't care about "efficiency". I care about usability. Having a tool designed to edit text let's me focus on everything else. Sure, there is a learning curve, but you don't need to be an expert to find the tool useful.
- rebootthesystem 9y agovi wasn't designed to efficiently edit text. It was designed to deal with shitty keyboards of the time. And now it is a cult. I challenge anyone to prove that a non-trivial project, say, a year of work for a team of five developers, would get done any faster, better and with less bugs because of the single act of adopting vim vs. a top grade IDE.
- thomastjeffery 9y ago> vi wasn't designed to efficiently edit text. That's entirely my point. It's not about efficiency. It's a lot like using an alternative keyboard layout. Sure, it isn't faster, but it's a lot more comfortable. Vim is great for editing text. There are functions that can easily be used to accomplish the editing task you want to do. Having tools designed for the task at hand makes working easier, and more comfortable. It's akin to having more leverage. > It was designed to deal with shitty keyboards of the time. And now it is a cult. That's very true. Like many other projects, with age Vim has held to tightly onto tradition. The functions available in normal mode are the same functions bound to the same keys. Any change to that behavior is so fundamental, it simply doesn't happen. > adopting vim vs. a top grade IDE That is not what I, or most others are asking. Most people who use vim enter the "vim cult" simply because they enjoy using the tool. Even after decades of stagnation, they prefer vim to an IDE. If there is something the "vim cult" wants, it is for you to let them use the tool they enjoy. IDEs inherently push tools out of their tightly defined (integrated) ecosystem. If someone wants to use the tool they like, and an IDE, they have to integrate the two. More often than not, that means a minimal implementation of vi inside the IDE. TL;DR If I am in the "vim cult", you are in the IDE cult. All I want from you is to let people use their tools.
- flukus 9y ago> Most of my work consists of reading text, thinking about it, running tests, reading the results of those tests Vim is quite good at that too, you can set the make program and error format to execute the tests and easily navigate to the source of errors for example.