3 ms·

I'm pretty adept at Vim, and I still don't understand people who code using what's essentially a text editor with colors. How do you do debugging? Conditional

I'm pretty adept at Vim, and I still don't understand people who code using what's essentially a text editor with colors. How do you do debugging? Conditional breakpoints? Call stack/view stack? Watch? Step/Continue? Meaningful autocompletion? Meaningful project management and navigation? Syntax highlighting isn't even important to me and I prefer either semantic highlighting or no highlighting at all. I understand people who use something like a Vim plugin for a JetBrains IDE, sure -- Vim in my opinion is a superior editor compared to the usual thing, but when you skip the IDE altogether, how do you do the tasks I mentioned above? Do you just do print debugging and use the filesystem as a project manager, and just not take advantage of IDE's semantic insight into your code? That seems quite inefficient -- you're losing a lot. Do you add third party addons to make some of these things happen? Because I'm yet to find addons for Vim that don't destabilize it and also solve their problem as well as they're solved in full-blown IDEs. Please illuminate me, considering the number of people who do this, I must be missing something!

majewsky 10y ago
> How do you do debugging? I read the code and follow the state transformations in my head. The huge advantage is that this also works with software running in production, when all I can do is crank up the log level. When I have access to the code and the compile-test-run cycle is quick enough, I speed up the process with printf debugging. > Meaningful autocompletion? I have a second screen where I can browse API documentation. > Meaningful project management and navigation? https://www.gnu.org/software/coreutils/coreutils.html https://www.gnu.org/software/coreutils/coreutils.html ---- I don't know; maybe I'm just good at what I do. I have noticed that I can hold much more state in my short-term memory than other developers around me, and that helps enormously during debugging. The most important part of debugging is forming a mental model of what is going on. For some applications and subsystems that I wrote (between 100 and 10,000 LOC) my mental model is so fine-grained that when a user reports an error, I know which line of code is broken before I even cd into the source tree. It should be noted that I'm not ignorant of IDEs. I have done a lot of work in Visual Studio some 10 years ago, and I liked it very much. When I moved to Linux, I switched to a text editor and gcc because these were readily accessible, whereas choosing and learning an IDE would have required additional effort. Over the years, I've never found that effort worthwhile. I have used gdb a few times, and had some good times hunting memory management bugs in my C++ programs with Valgrind. Instead, I've come to appreciate that on every system that I ever SSH into, vim is always just a package installation and (optionally) a git-clone of my vimrc away. And if shit hits the fan, vi(1) will do. And if shit really hits the fan, sed(1) will do. Oh, I just remember that I had a relatively recent experience with IDEs: I had to use Java and Spring Boot for a university project, and was forced to use Eclipse because I could not get shit to build otherwise. It felt like being strapped in a straight-jacket, compared to the seemingly infinite freedom that a command prompt on a terminal has come to mean to me. I have two IDE-like features in my vim: Syntastic (a plugin that runs syntax checkers and linters and shows the errors and warnings in-line) and a tiny vimscript that runs gofmt/goimports when I save a Golang file. My other plugins are all focused on more comfortable text editing. ---- I don't intend to hate on IDE users. If they can work better with an IDE, then that's great. I'm more productive without them. ---- Sometimes I snicker when someone on HN complains that Rust is totally unuseable because there is no stable IDE support yet, or something like that. And I'm sitting here and writing syntax highlighting rules in vimscript for DSLs that I just made up. EDIT: One more thing. The choice of languages and frameworks shapes the choice of editor. I would never try to develop a Java project in vim, and working on Rails apps leaves much desired. (I could try to find a good IDE plugin for vim for the language in question, but I'm changing languages very frequently and don't want a bazillion IDE plugins clogging the editor.) And of course, the same applies in reverse. Because I'm a vim user, I will prefer languages that play well with vim. Right now, my most-used languages are Golang and shell script and YAML (if that even counts), and these all work nicely.
- jawilson2 10y ago
  Do you do work where you have to inspect large data arrays? The ability to pause execution (say, training a neural net on billions of rows of data) and inspect what the weights and biases are doing over several iterations is invaluable, and much easier to understand than running->printing/logging. Especially if it takes a significant amount of time to hit that point of the code. If there is a problem, I can work with the processed data, and make changes live, rather than edit code, run it, wait for 30 minutes, and hope it works, since it can take several iterations.

majewsky 10y ago

> How do you do debugging? I read the code and follow the state transformations in my head. The huge advantage is that this also works with software running in production, when all I can do is crank up the log level. When I have access to the code and the compile-test-run cycle is quick enough, I speed up the process with printf debugging. > Meaningful autocompletion? I have a second screen where I can browse API documentation. > Meaningful project management and navigation? https://www.gnu.org/software/coreutils/coreutils.html https://www.gnu.org/software/coreutils/coreutils.html ---- I don't know; maybe I'm just good at what I do. I have noticed that I can hold much more state in my short-term memory than other developers around me, and that helps enormously during debugging. The most important part of debugging is forming a mental model of what is going on. For some applications and subsystems that I wrote (between 100 and 10,000 LOC) my mental model is so fine-grained that when a user reports an error, I know which line of code is broken before I even cd into the source tree. It should be noted that I'm not ignorant of IDEs. I have done a lot of work in Visual Studio some 10 years ago, and I liked it very much. When I moved to Linux, I switched to a text editor and gcc because these were readily accessible, whereas choosing and learning an IDE would have required additional effort. Over the years, I've never found that effort worthwhile. I have used gdb a few times, and had some good times hunting memory management bugs in my C++ programs with Valgrind. Instead, I've come to appreciate that on every system that I ever SSH into, vim is always just a package installation and (optionally) a git-clone of my vimrc away. And if shit hits the fan, vi(1) will do. And if shit really hits the fan, sed(1) will do. Oh, I just remember that I had a relatively recent experience with IDEs: I had to use Java and Spring Boot for a university project, and was forced to use Eclipse because I could not get shit to build otherwise. It felt like being strapped in a straight-jacket, compared to the seemingly infinite freedom that a command prompt on a terminal has come to mean to me. I have two IDE-like features in my vim: Syntastic (a plugin that runs syntax checkers and linters and shows the errors and warnings in-line) and a tiny vimscript that runs gofmt/goimports when I save a Golang file. My other plugins are all focused on more comfortable text editing. ---- I don't intend to hate on IDE users. If they can work better with an IDE, then that's great. I'm more productive without them. ---- Sometimes I snicker when someone on HN complains that Rust is totally unuseable because there is no stable IDE support yet, or something like that. And I'm sitting here and writing syntax highlighting rules in vimscript for DSLs that I just made up. EDIT: One more thing. The choice of languages and frameworks shapes the choice of editor. I would never try to develop a Java project in vim, and working on Rails apps leaves much desired. (I could try to find a good IDE plugin for vim for the language in question, but I'm changing languages very frequently and don't want a bazillion IDE plugins clogging the editor.) And of course, the same applies in reverse. Because I'm a vim user, I will prefer languages that play well with vim. Right now, my most-used languages are Golang and shell script and YAML (if that even counts), and these all work nicely.

jawilson2 10y ago
Do you do work where you have to inspect large data arrays? The ability to pause execution (say, training a neural net on billions of rows of data) and inspect what the weights and biases are doing over several iterations is invaluable, and much easier to understand than running->printing/logging. Especially if it takes a significant amount of time to hit that point of the code. If there is a problem, I can work with the processed data, and make changes live, rather than edit code, run it, wait for 30 minutes, and hope it works, since it can take several iterations.