Sunday, August 23, 2015

Re: vim suitable for professional software development?

On 2015-08-23 16:33, taschentuch@posteo.de wrote:
> i'm wondering whether VIM is really suitable for professional
> software development.

I've been using it for over a decade for professional software
development. So I'd guess the answer is "yes".

> 1) Let's assume your vim configuration is broken at work and you
> can't fix the issue within 20 minutes. I assume sth like 20 minutes
> is the upper limit for vim configuration things, before your
> colleagues or boss gets angry. Most, if not all of your needed
> plugins aren't working correctly.
>
> * How would you react in such a situation? Would you temporarily
> switch to e.g. Eclipse?
> * How would you react when you have very important stuff to do?
> * How often does such a situation happen?

I tend to run with a pretty minimal configuration, not much beyond
the resetting "vim -u NONE" so if for some reason my vimrc wasn't
working, it wouldn't be too hard to track down what's going on. And
wouldn't switch to anything else. I've occasionally used Notepad for
quick edits on Windows machines where I didn't have vi/vim installed,
and occasionally turn to /bin/ed when my $TERM settings get messed up
on *nix but vi/vim almost never gives me grief.

As for how frequently such a hypothetical situation occurs, almost
never. The only times are when I've just gone in and tweaked my
vimrc, in which case I just back out (or comment out) the settings
that I changed/added.

Once you start introducing plugins, things get a little hairier, but
if you learn to use vi/vim without plugins, then even if you have to
disable a troublesome plugin, you still have stock vim readily
available.

> => I'm not very experienced with vim, so i have honestly very big
> fears about such situations, standing helplessly in front of a
> unusable editor and a lot of work to do.

Because of the recovery-mode (the aforementioned "vim -u NONE" which
starts up without loading global/local config files) your only limit
is actually learning vim.

> 2) I'm not familiar with frameworks like Spring, Tomcat or Maven.
>
> * But how much do they depend on some vim plugin? I mean, is it
> possible to work without a vim plugin? I assume, they make the
> repeated tasks of your work very easy and fast.
> * Let's assume, your company transfers to another, related
> framework, which doesn't provide a vim plugin. How would you react?
> would you change your IDE, work with the command line or try to
> write a plugin?
> * At needs to happen that you'll decide to change your editor?

As above, I don't generally use plugins, so it doesn't impact me.
I'm a Python developer so can't speak to Sprint/Tomcat/Maven, but I
don't call myself an expert in a language/framework unless I can
develop without the hand-holding of an IDE. But the bulk of the work
simply involves editing code, so the plugin features don't impact me
greatly.

> => I have also very little experience with vim or shell scripting,
> therefore i fear that someday i can't write a convenience
> plugin/script and have to work in a (compared to e.g. eclipse)
> inefficient way - or change the editor, because the support fore
> that language/framework is not enough.

Fortunately, vi/vim doesn't lock you in or start to spurn you if you
make use of other editors. If Eclipse gives you some magic
functionality that solves a problem where vi/vim can't, feel free to
use Eclipse for that. The only time I've had to go that route with
some Embedded Visual C++ where the MS Visual Studio (MSVS) interface
created the required project layouts, build options, etc. Even then,
once I got the projects and settings configured, I did most of my
actual code-editing with vim, and just used VS to do the builds.

> 3) GUI development. I've learned recently that vim's intention is
> just not to be a GUI builder for some language. But,

Vim is a text editor. Some GUI builders allow you to edit the
underlying structure and bindings which make them more flexible and
more useful when combined with version-control. Other GUI builders
store their layout in an opaque binary format that is good neither
for editing in other editors, nor versioning (comparing opaque binary
blobs is pretty useless).

> * How good/fluently do they interact with vim?

Both gvim and MSVS recognize when a file has been edited externally
and offer to let you reload the file fresh from disk. When I have to
use both together, this functionality saves the day. I can't speak
to others like Eclipse but assume they're not brain-dead and also do
similarly.

> => As a beginner, i don't understand the complexity of the
> connection between the GUI Builder and vim, respectively what does
> VS in the background for me. So I wouldn't know how i should be
> able to create snippets that could handle the XML/metadata things.
> While programming in VS, i've never touched the XML and rarely the
> auto generated C# code in the background. I fear that that could
> hinder developing with vim.

Again, feel free to use both. Most editors notice if changes happen
externally, so you can edit in either one and have the other one
notify that the file changed to let you reload it.

The big thing to know is that vim is a *text editor*. It's not a GUI
builder. It's not version-control. It's not a build-process. It's
not a testing framework.

In the *nix world, usually these are each provided by separate tools
(git/subversion/mercurial, make/cmake/imake/ant, etc). I the
Windows/Java world, often there's a canonical IDE (Visual
Studio/Eclipse) that provides most of that--though you can swap in
your own pieces like using vi/vim as your text-editor.

There are some popular pieces written on the topic:

http://blog.sanctum.geek.nz/unix-as-ide-introduction/
https://michaelochurch.wordpress.com/2013/01/09/ide-culture-vs-unix-philosophy/
(NB: a fair bit of profanity in that 2nd article, in case that matters)

Here's hoping it's a fun adventure for you, and this list is here to
help you out the best we can.

-tim






--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

No comments: