Hacker News new | comments | show | ask | jobs | submit login

You probably don't understand well enough how big a difference these tools can make in your efficiency. Of course number one priority is to know the technology, nobody argues that.



In my experience, when working with anything but very small projects vim is a liability. Vim's main feature (speed of editing) is of marginal use when you only write about 10 LOC per day (as I would say is still the case 40 years after The Mythical Man Month was published, at least on average). The time when you're not writing code (which is most of the time) is used switching back and forth between files, going to declaration/definition, debugging,(auto)refactoring, changing between project configurations and so on. All this is very difficult to do with vim since it comes naked out of the box and you need to use all sorts of crutches to make is resemble a modern IDE. And when you switch another machine all you usually get is another barebones vim.

For instance, when working on a C++ code base, vim will never come close to the ease of use of Visual C++. It might be better at "delete 2 lines starting at line #256", but that's about it. This can be improved by plugins that most of the time will not do exactly what you'd like them to do, so you will have to "adjust your workflow" to work around that.

My original point was about using tools because it's cool or because the internet said so, and there's load of stories where people buy into how good vim is and then after a few months they still don't 'get it' so they are told they're doing it wrong (or just not smart enough). Ditto for git, lisp and other silver bullets.

If you ask me, if efficiency were important people would be using hg instead of git most of the time because most of the things you can do in git you can do easier/simpler in hg - at least for the most usual cases. After a short intro to hg people will keep using it happily ever after, whereas the git user will keep coming back to StackOverflow questions to find out how to hard reset to head after rebasing from origin and rewinding. Speaking of SO, this quote matches my thoughts exactly:

"It seems to me, that people using Mercurial are not so easily impressed. This is reflected in how each system do what Linus described as "the coolest merge EVER!". In Git you can merge with an unrelated repository by doing: git fetch <project-to-union-merge> GIT_INDEX_FILE=.git/tmp-index git-read-tree FETCH_HEAD GIT_INDEX_FILE=.git/tmp-index git-checkout-cache -a -u git-update-cache --add -- (GIT_INDEX_FILE=.git/tmp-index git-ls-files) cp .git/FETCH_HEAD .git/MERGE_HEAD git commit

Those commands look quite arcane to my eye. In Mercurial we do: hg pull --force <project-to-union-merge> hg merge hg commit"

I would like to read your insights related to efficiency.


Part of speed of editing for me is low RAM usage. When I'm doing web development, I tend to have a few browsers open (at least Firefox and Chrome), running web servers and databases, or the same in a Vagrant-managed VM.

When you've got a browser or two and a Linux VM running, finding the extra 500Mb for an IDE can be rather taxing. I've tried IntelliJ, Eclipse and NetBeans. Always end up coming back to MacVim, saving a few hundred megs of RAM and not really getting any significant hit in productivity.

I was trying out PyCharm the other day (IntelliJ's Python IDE) and it was unable to keep up with my fingers. The text was lagging a I was typing it in. What was I getting from the IDE? Debugging? I know my way around pdb, haven't got time to work out how the IDE fucks that up. File navigation? I've got Ctrl-P. Changing between project configuration? Meh. Got Vagrant for that kind of thing anyway. That leaves autocomplete (can take it or leave it. Not bothered.) and refactoring (mostly I use Python and Ruby at work, so mostly it's a shit show anyway IDE or not).

Even on Scala projects, I've gone in thinking "IDEs are the answer" and ending up back in Vim after a few hours of flailing around trying to get the IDE to talk to the compiler.

Agreed on Mercurial though. I like Git, I like Mercurial. Both have upsides and downsides. More important is that we are finally moving away from centralised VCS.


I understand where you're coming from and I concede that you might be more efficient with your current setup, but I disagree about the debugger. Pdb, gdb and any other command-line based *db-s are what people first started using a few thousand years before entering the stone age. I've used gdb extensively and I can tell you there's no substitute for a good IDE where you can see the code, variable values, stacks, threads and watches, all at the same time; it makes life so much easier. It can be done in the old fashion way but there's nothing to gain from it.

On the other hand I haven't seen any good free Python IDE-s (like Visual C++ is for C++) and you are sometimes forced to use pdb for the lack of a better option (Python Tools for VS are decent but took me a lot of time to setup properly and I didn't like the workflow). That said, the lack of good tools doesn't mean the old ones are good, only that the language lacks good tools, mostly because people get used to the stone age tools. And sadly that is the case for a lot of programming languages.


Well, JetBrains have now made PyCharm3 Community Edition, which is free and open source, and they are charging for the premium edition with support for web frameworks like Django, Flask and Pyramid.

The RAM thing still bites. When I get a new laptop in a year or so, I'm going to go all out on RAM. :)


We agree on that it's stupid to use tools because others said so. We agree on that you don't immediately need these tools if you are just starting out or write simple code, BUT I think it's very easy to reach a point (I mean you are efficient enough in the technology itself) when you feel the need for these tools. For example I'm not quite there yet, so I use SublimeText or an IDE but every time I edit a line I just hate these tools, because they feel so slow, and in that exact moment, when I won't have to look up the manuals every time, because I don't know the framework/language/technology I will switch to Vim for sure, because I think at that point when you are a pro in the technology, an IDE will get in your way. When you can crank out hundreds of lines without even blink, Vim is the way to go. Again, for beginners this is not the case. For casual coders? They probably do it for fun, so why not do cool things? I cannot comment on Mercurial vs Git, because did not use Mercurial, I only read that with Git, you can do anything you want and with Mercurial, you can do most of the things simply.

TL; DR: There is a point in your knowledge about the technology when you simply NEED these tools. Early on, you probably don't.


When using Visual C++ I'd use ViEmu. Other IDEs have similar vim plugins of varying strength.

To put things into perspective, in terms of productivity if given a choice between Visual Studio without ViEmu or just vim I'd pick Visual Studio. Fortunately I don't have to choose.


> All this is very difficult to do with vim since it comes naked out of the box and you need to use all sorts of crutches to make is resemble a modern IDE.

Well, that's your problem: Vim has never been, is not and will never be an IDE.

Vim is a very powerful text editor, use it as such and you'll get a neverending smile on your face.

If you need an IDE by all means drop Vim and use an IDE. If you prefer a text editor, go with a text editor.

I use Vim for HTML/CSS/JS/PHP, learning Python and as a general purpose text editor.

I also use Flash Builder for AS3 and AndroidStudio for… Android because I have somewhat bigger needs.


Fully agree with you.

I do know VI (there was no VIM when I learned it) and Emacs. Yet I prefer to live in the cozzy world of IDEs.

Every time I read a story like this, it resembles a macho attitude of being able to develop software in a UNIX System V world environment, talk about time travel to the 70's.




Applications are open for YC Winter 2018

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: