10 ms·

> An IDE like Medium, not Vim Sorry. You lost me here. If you don't understand why so many developers are so committed to Vim, then I don't believe you underst

> An IDE like Medium, not Vim Sorry. You lost me here. If you don't understand why so many developers are so committed to Vim, then I don't believe you understand how actual developers (not beginners) interact with code well enough to replace it.

kybernetikos 9y ago
Having followed the project I don't think it's fair to assume that those working on it didn't understand why developers like vim. It's more just that traditional developers doing traditional developer things weren't the most important part of their target market. A lot of thought and experiment went into what became eve.
- jdbernard 9y ago
  Yeah, it's been a while since this effort has come up on my radar. Now that I'm remembering a little more, these are the same guys who were behind light-table, I think. So I guess it's fair to say that they've thought deeply about the problem. I still think that the path they are exploring will not bear fruit as in my opinion they seem to have a core, almost axiomatic disbelief in the inherent difficulty of software development and a corresponding disdain for the patterns of work that have led to what is actually productive today. I think that software development is fundamentally, irreducibly hard. Poor tooling can certainly makes it more inaccessible and good tooling can certainly make it more accessible, but the real difficultly is conceptual and not due to the nature to any particular language or tooling. Therefore tooling and language alone cannot make it fundamentally easier. I'm glad someone is exploring it. Maybe I'm wrong. Maybe this will yield promising results. But so far it seems like every time this kind of work come around again it continues to make big promises without concrete benefit. At best it provides a more gentle introduction for beginners, which is a good thing. But I have yet to see anything that would provide to me as a professional even half the utility and "accessibility" of my current toolset. Typically many of the simplifications they make in the name of accessibility become more of a hindrance than a help as you advance past the beginning stages.
abritinthebay 9y ago
Having been a programmer for 20 years I have no idea why so many developers are so committed to Vim (other than it is available almost everywhere, which is helpful when doing things on a remote server). I'm probably going to get down-voted to hell for this opinion here but it's literally the least productive, least intuitive, and most frustrating editor I've used. But "learning curve" it's advocates cry! The time I have to spend getting up to speed with vim is better used actually programming, not to mention the people I know who are advanced users don't appear to code any faster than I do. A couple of occasionally used text operations are faster perhaps (though in modern editors it's debatable) but it appears to not have much cumulative effect. As far as I can tell the only reason developers use vim is because developers use vim. It's a tautological tool.
- pasabagi 9y ago
  I think you're missing out a little here. Sure, vim doesn't make you more productive. Sure, time spent learning vim is probably better spent programming. However, vim is just great fun. That's why people obsess over it, fundamentally. It makes tricky and repetitive transformations of text intuitive and enjoyable.
  - abritinthebay 9y ago
    > However, vim is just great fun. This is such a fundamental disconnect from my idea of fun that I don't think we're going to see eye to eye on this ;) > It makes tricky and repetitive transformations of text intuitive and enjoyable. Given the fact that the number one phrase involving vim is "how do I do X in vim" I think intuitive is something that shouldn't even be in the same zipcode as it.
    - pasabagi 9y ago
      > intuitive is something that shouldn't even be in the same zipcode as it. That's the thing, though. It's very different to non-modal text editors, so there's this learning 'cliff', where you get frustrated by how unfamiliar it is. However, when it comes down to it - the neat thing about Vi is it's a re-imagining of what a text-editor is. Non vi-like editors essentially derive from the metaphor of a typewriter. You have a cursor, the print head, and you enter text there. You can use your hand (mouse) to change where the print head is pointing. You can highlight sections, as if with a pen - copy and paste stuff, as if you were using scissors. These functions are displayed a bit like the extra functions of one of those late-model electronic typewriters, where you could press a key-combination to get some neat functionality. The nice thing about Vim is it accepts that editing text on a computer isn't like this. When you edit on a computer, you jump into a pre-existing text, mostly, adding or changing. So, for this reason, it has lots of functions for accurately manipulating sections of text, like words, or things between brackets, or sentences. This kind of functionality is pretty standard for a good editor, but I think the thing Vi got really right is organizing these functions. The problem with having lots of functions is that they're hard to remember. So Vi structures them like a language. So in the end, I think it's more intuitive than other editors. It doesn't work within the context of an outdated metaphor, and, it structures the functions that allow it to surpass that metaphor in a way that makes them extremely easy to discover and to remember.
heavenlyblue 9y ago
Actual developers interact with live systems (see strace), which is exactly what medium is to vim.
ibdknox 9y ago
For what it's worth, I have used Vim since ~2004. When I built Light Table, one of the first things I did was put a Vim mode into it. I understand pretty well why at least I use Vim. I also believe that these days there's relatively little payoff given the cost of investment. Rarely is the speed of text-editing the bottleneck in building something real. Moreover, there are far more powerful ways to interact with code than at the text buffer level.
- jdbernard 9y ago
  > Moreover, there are far more powerful ways to interact with code than at the text buffer level. This is actually one of my core reasons for using Vim. I agree, but all of those "more powerful ways to interact with code" happen in my head, not in an IDE. And my head is far more flexible than the IDE. In pretty much every IDE I've used you start thinking according to the patterns of transformation that the IDE supports, which can be helpful for a beginner, but is ultimately very limiting. New languages start with no IDE support. This is mostly for practical reasons I concede, but it is usually also often the case that the new language is being written because it represents a new paradigm of thinking. It's not until the language matures and the common patterns of thought become known that they then become encoded as "helpers" in IDEs. The other main objection to this, I think, is to point out that linear textual encoding of code is itself a bottleneck, and that a strict text editor like Vim will never let you move past that. Implicit in this assumption, however, is the belief that there is a better way to represent code than linear text. However, I would point out that throughout all of mankind's history, language (and text as it's persistent form) has been the highest form of communicated logical representation. We have had access to pictography and other forms of communication for millennia, but none has had the same ability to encode and transfer knowledge and logic like text. I think we are primarily adapted as humans to think in terms of language. My bet is that there isn't a more powerful abstraction than this given the structure of our brains. I'm happy to be proved wrong though. Given both of the above, personally I find the most productive means of working is to work primarily at the conceptual/abstract level in my head, model the problem and solution in thought, then translate the solution into the most natural form for expressing thought: language (as text). So most of the tools that the IDE gives me (especially regarding code transformation, etc.) are hard-coded, less powerful versions of the kind of mental processes I am already doing. I don't need those. What I do need is a way to encode my thoughts in text as quickly and efficiently as possible. I don't want to have to think about that at all. I want it to flow naturally from my mental model into prose (though not English prose, obviously). For that an IDE again gets in the way. It's slow and full of distractions. The Vim keybindings have become so ingrained that it's muscle-memory. And I've yet to find another paradigm that lets me manipulate text as effortlessly.
Bizarro 9y ago
Developers are more committed to vi-keybindings than Vim.
Sohcahtoa82 9y ago
> If you don't understand why so many developers are so committed to Vim The only real reason I've heard people use vim instead of a GUI IDE is because it's simply what they're used to and don't want to change. (EDIT: And the fact that it's available on every system, but that only gives a reason to learn vim, not a reason to prefer it over an IDE) In terms of features, there's not a damn thing vim can do that an IDE can't, while there are tons of things IDEs can do. It's excruciating to hear developers say "I use vim instead of an IDE because I can do X in vim" when every IDE made in the last 10 years can do X. And it does it out of the box without needing plugins! I've literally heard people say they like vim because they can do some key combination to highlight several lines of text and then hit TAB to indent them all at once.
- greptomania 9y ago
  I avoid IDE's for three reasons: 1.) They abstract important (to me) details. For example, build system integration. I prefer to see the actual Makefile to ensure that things are being linked correctly. This is especially important on large HPC clusters where there are a plethora of compiler options. 2.) They are too graphical. Essentially all of my programming is done through the terminal, which is fast and lightweight as compared to, say, Visual Studio or XCode (or w/e the standard OS-X IDE is). 3.) They do too much to 'help' the user, which ultimately just gets in the way. This is obviously a highly personal and biased opinion on my part. However, it is important (to me) to physically type the source, rather than starting from some template with boilerplate and adapting it to my needs. This is perhaps a reflection of the poor design of many languages (e.g. Java, C++) which necessitate such quality of life 'improvements' for some. But, for me, I just want to code what I want to code without an IDE getting in the way ala the maligned Microsoft Paperclip. While I personally prefer emacs to vim, I have no doubt that these points may be common to developers who prefer either to an IDE. To your point, I do not know (but would not be surprised) to learn that some fantastic modern IDE could do all of the above. But, why do all that when emacs works so darn well for me?
- Sylos 9y ago
  Then you don't actually know Vim. Vim is at the end of the day also just a text editor, so no, there's no things that it does that you cannot achieve in some way or another with any other text editor. The point is how quickly you can achieve these things. Vim requires a lot of learning before you can use it effectively, but if you do know it, you can do things with it quicker than you can with other text editors. For example, to delete the last three words in a line, you can type into Vim's command mode "$ 3b D". The $ moves your cursor to the end of the line, the 3 does three times whatever comes next, the b moves your cursor back a word, and the D deletes everything to the end of the line. This is the kind of stuff you can do with it. And well, you can mix and match these to do lots of different things. It is somewhat ridiculous, but for people who actually know these commands, they have every right to feel horribly slow in any text editor that doesn't work like this. And aside from that, Vim is really extensible, so whatever feature an IDE might offer, you can probably get that in Vim, too.

kybernetikos 9y ago

Having followed the project I don't think it's fair to assume that those working on it didn't understand why developers like vim. It's more just that traditional developers doing traditional developer things weren't the most important part of their target market. A lot of thought and experiment went into what became eve.

jdbernard 9y ago
Yeah, it's been a while since this effort has come up on my radar. Now that I'm remembering a little more, these are the same guys who were behind light-table, I think. So I guess it's fair to say that they've thought deeply about the problem. I still think that the path they are exploring will not bear fruit as in my opinion they seem to have a core, almost axiomatic disbelief in the inherent difficulty of software development and a corresponding disdain for the patterns of work that have led to what is actually productive today. I think that software development is fundamentally, irreducibly hard. Poor tooling can certainly makes it more inaccessible and good tooling can certainly make it more accessible, but the real difficultly is conceptual and not due to the nature to any particular language or tooling. Therefore tooling and language alone cannot make it fundamentally easier. I'm glad someone is exploring it. Maybe I'm wrong. Maybe this will yield promising results. But so far it seems like every time this kind of work come around again it continues to make big promises without concrete benefit. At best it provides a more gentle introduction for beginners, which is a good thing. But I have yet to see anything that would provide to me as a professional even half the utility and "accessibility" of my current toolset. Typically many of the simplifications they make in the name of accessibility become more of a hindrance than a help as you advance past the beginning stages.

abritinthebay 9y ago

Having been a programmer for 20 years I have no idea why so many developers are so committed to Vim (other than it is available almost everywhere, which is helpful when doing things on a remote server). I'm probably going to get down-voted to hell for this opinion here but it's literally the least productive, least intuitive, and most frustrating editor I've used. But "learning curve" it's advocates cry! The time I have to spend getting up to speed with vim is better used actually programming, not to mention the people I know who are advanced users don't appear to code any faster than I do. A couple of occasionally used text operations are faster perhaps (though in modern editors it's debatable) but it appears to not have much cumulative effect. As far as I can tell the only reason developers use vim is because developers use vim. It's a tautological tool.

pasabagi 9y ago
I think you're missing out a little here. Sure, vim doesn't make you more productive. Sure, time spent learning vim is probably better spent programming. However, vim is just great fun. That's why people obsess over it, fundamentally. It makes tricky and repetitive transformations of text intuitive and enjoyable.
- abritinthebay 9y ago
  > However, vim is just great fun. This is such a fundamental disconnect from my idea of fun that I don't think we're going to see eye to eye on this ;) > It makes tricky and repetitive transformations of text intuitive and enjoyable. Given the fact that the number one phrase involving vim is "how do I do X in vim" I think intuitive is something that shouldn't even be in the same zipcode as it.
  - pasabagi 9y ago
    > intuitive is something that shouldn't even be in the same zipcode as it. That's the thing, though. It's very different to non-modal text editors, so there's this learning 'cliff', where you get frustrated by how unfamiliar it is. However, when it comes down to it - the neat thing about Vi is it's a re-imagining of what a text-editor is. Non vi-like editors essentially derive from the metaphor of a typewriter. You have a cursor, the print head, and you enter text there. You can use your hand (mouse) to change where the print head is pointing. You can highlight sections, as if with a pen - copy and paste stuff, as if you were using scissors. These functions are displayed a bit like the extra functions of one of those late-model electronic typewriters, where you could press a key-combination to get some neat functionality. The nice thing about Vim is it accepts that editing text on a computer isn't like this. When you edit on a computer, you jump into a pre-existing text, mostly, adding or changing. So, for this reason, it has lots of functions for accurately manipulating sections of text, like words, or things between brackets, or sentences. This kind of functionality is pretty standard for a good editor, but I think the thing Vi got really right is organizing these functions. The problem with having lots of functions is that they're hard to remember. So Vi structures them like a language. So in the end, I think it's more intuitive than other editors. It doesn't work within the context of an outdated metaphor, and, it structures the functions that allow it to surpass that metaphor in a way that makes them extremely easy to discover and to remember.

heavenlyblue 9y ago

Actual developers interact with live systems (see strace), which is exactly what medium is to vim.

ibdknox 9y ago

For what it's worth, I have used Vim since ~2004. When I built Light Table, one of the first things I did was put a Vim mode into it. I understand pretty well why at least I use Vim. I also believe that these days there's relatively little payoff given the cost of investment. Rarely is the speed of text-editing the bottleneck in building something real. Moreover, there are far more powerful ways to interact with code than at the text buffer level.

jdbernard 9y ago
> Moreover, there are far more powerful ways to interact with code than at the text buffer level. This is actually one of my core reasons for using Vim. I agree, but all of those "more powerful ways to interact with code" happen in my head, not in an IDE. And my head is far more flexible than the IDE. In pretty much every IDE I've used you start thinking according to the patterns of transformation that the IDE supports, which can be helpful for a beginner, but is ultimately very limiting. New languages start with no IDE support. This is mostly for practical reasons I concede, but it is usually also often the case that the new language is being written because it represents a new paradigm of thinking. It's not until the language matures and the common patterns of thought become known that they then become encoded as "helpers" in IDEs. The other main objection to this, I think, is to point out that linear textual encoding of code is itself a bottleneck, and that a strict text editor like Vim will never let you move past that. Implicit in this assumption, however, is the belief that there is a better way to represent code than linear text. However, I would point out that throughout all of mankind's history, language (and text as it's persistent form) has been the highest form of communicated logical representation. We have had access to pictography and other forms of communication for millennia, but none has had the same ability to encode and transfer knowledge and logic like text. I think we are primarily adapted as humans to think in terms of language. My bet is that there isn't a more powerful abstraction than this given the structure of our brains. I'm happy to be proved wrong though. Given both of the above, personally I find the most productive means of working is to work primarily at the conceptual/abstract level in my head, model the problem and solution in thought, then translate the solution into the most natural form for expressing thought: language (as text). So most of the tools that the IDE gives me (especially regarding code transformation, etc.) are hard-coded, less powerful versions of the kind of mental processes I am already doing. I don't need those. What I do need is a way to encode my thoughts in text as quickly and efficiently as possible. I don't want to have to think about that at all. I want it to flow naturally from my mental model into prose (though not English prose, obviously). For that an IDE again gets in the way. It's slow and full of distractions. The Vim keybindings have become so ingrained that it's muscle-memory. And I've yet to find another paradigm that lets me manipulate text as effortlessly.

Bizarro 9y ago

Developers are more committed to vi-keybindings than Vim.

Sohcahtoa82 9y ago

> If you don't understand why so many developers are so committed to Vim The only real reason I've heard people use vim instead of a GUI IDE is because it's simply what they're used to and don't want to change. (EDIT: And the fact that it's available on every system, but that only gives a reason to learn vim, not a reason to prefer it over an IDE) In terms of features, there's not a damn thing vim can do that an IDE can't, while there are tons of things IDEs can do. It's excruciating to hear developers say "I use vim instead of an IDE because I can do X in vim" when every IDE made in the last 10 years can do X. And it does it out of the box without needing plugins! I've literally heard people say they like vim because they can do some key combination to highlight several lines of text and then hit TAB to indent them all at once.

greptomania 9y ago
I avoid IDE's for three reasons: 1.) They abstract important (to me) details. For example, build system integration. I prefer to see the actual Makefile to ensure that things are being linked correctly. This is especially important on large HPC clusters where there are a plethora of compiler options. 2.) They are too graphical. Essentially all of my programming is done through the terminal, which is fast and lightweight as compared to, say, Visual Studio or XCode (or w/e the standard OS-X IDE is). 3.) They do too much to 'help' the user, which ultimately just gets in the way. This is obviously a highly personal and biased opinion on my part. However, it is important (to me) to physically type the source, rather than starting from some template with boilerplate and adapting it to my needs. This is perhaps a reflection of the poor design of many languages (e.g. Java, C++) which necessitate such quality of life 'improvements' for some. But, for me, I just want to code what I want to code without an IDE getting in the way ala the maligned Microsoft Paperclip. While I personally prefer emacs to vim, I have no doubt that these points may be common to developers who prefer either to an IDE. To your point, I do not know (but would not be surprised) to learn that some fantastic modern IDE could do all of the above. But, why do all that when emacs works so darn well for me?
Sylos 9y ago
Then you don't actually know Vim. Vim is at the end of the day also just a text editor, so no, there's no things that it does that you cannot achieve in some way or another with any other text editor. The point is how quickly you can achieve these things. Vim requires a lot of learning before you can use it effectively, but if you do know it, you can do things with it quicker than you can with other text editors. For example, to delete the last three words in a line, you can type into Vim's command mode "$ 3b D". The $ moves your cursor to the end of the line, the 3 does three times whatever comes next, the b moves your cursor back a word, and the D deletes everything to the end of the line. This is the kind of stuff you can do with it. And well, you can mix and match these to do lots of different things. It is somewhat ridiculous, but for people who actually know these commands, they have every right to feel horribly slow in any text editor that doesn't work like this. And aside from that, Vim is really extensible, so whatever feature an IDE might offer, you can probably get that in Vim, too.