Do you think/write differently in vim and emacs?

In many scripts that I write, I often construct programs in a "functional style". That is to say, I basically define a lot of functions at the beginning, and then later apply these functions. This results in a sequence of nested function calls, wherein I type out:

1. function name
2. its arguments
3. next function name
4. its arguments

...and so on.

For cases in which functions are "piped" together, the output of one function is an argument (usu开发者_Go百科ally the first, but not always) to the next function, the output of which is an argument to the next function, and ad infinitum. In prefix-notation, the key movements can be very jumpy if you type out this sequence from left to right. For example, how would you type out the second line of the following [Python] example (~mul~ is multiply, ~truediv~ is divide)?

from operator import add, mul, truediv
print(truediv(mul(add(1,1),2),4))

If I had to write the same set of operations linearly (from left to write, without jumping around), I am more likely to use the notation of function composition. Building on my previous example in Python, I might write

from functional import foldr, compose, partial, flip
print(foldr(compose,add,(partial(mul,2),partial(flip(truediv),4)))(1,1))

I think this is because I associate each function with its own arguments and prefer to type them out in succession, rather than filling arguments to another function before the argument list for the first function is complete (as would be required to type out the first example from left to right).

I noticed this because I've been an emacs user for a long time and only recently tried out viper/vimpuse and vim. In emacs, I might do something like

1. [type function name and arguments]
2. C-a
3. [type next function name]
4. C-e
5. [fill in rest of arguments]
6. C-a
7. [type next function name]
8. C-e
9. [fill in rest of arguments]

...and so on, with occasional use of M-b, M-f, M-DEL (backward-word, forward-word, backward-kill-word) if I mess up or forget something.

I recently found out about C-o in vim, which is a lifesaver - but I find that the equivalent keys would be

1. [type function name and arguments]
2. C-o 0
3. [type next function name]
4. C-o $
5. [fill in rest of arguments]
6. C-o 0
7. [type next function name]
8. C-o $
9. [fill in rest of arguments]

...and the rest; backward-word, forward-word, and backward-kill-word equivalents would be C-o b and C-o w, and C-w.

So this got me thinking that to program in vim, I may have to grow a larger working memory, so that I can pause the construction of one function as I fill out another, and so on down the stack. Also, in construcing text documents, I find that I edit (kill, copy, yank) quite frequently even before I finish a complete thought, which is not so amenable for vim's operational style of "stay in normal mode, burst of text in insert-mode, and back to normal mode", which seems to presume that I am capable of producing something worth editing during my forays into insert-mode. To use vim, I find that I deliberate more as I type to reduce the frequency of switching between modes. Is this because I'm naturally spastic, or once I master or commit a suitable range of vim key commands to muscle memory, I'll stop thinking they're so different?

If you program in both emacs and vim, do you find yourself thinking about and construcing your programs and blocks of text differently in each editor?

I used vi from the good old days of 1992 and now I use Emacs since 2001. I haven't noticed any difference in my thinking when programming functions and blocks of code. Both editors has their own peculiarities and ways of doing things, but they are not so strong that they could change your way of thinking and how you program.

I've always tried to find ways to do what I intend to do. I don't let my editor force me to do something I don't want. When I do procedural programming of a new piece of code, I use the technique called "wishful thinking" that is mentioned in Structure and Interpretation of Computer Programs :

You imagine yourself in the perfect world having all the procedures you need at your disposal. You code your algorithm with all those helpful functions that you'll need to implement but that you only have prototypes for the moment. It's similar to a top-down approach.