Thursday, January 24, 2019

Re: Evaluating the cost to type something in vim

> What I am talking about is "cost", which ultimately map to all
> programmer's time involved in typing and thinking about what to type.
> (But not include thinking about algorithm, data structure, etc.)

Hi Peng,

It sounds like you are measuring cost as equal to time. If you want to know
the answer to that, you would need a study that somehow compares time taken
between one or more people using Vim, and some number of other people using
various other editors. You can use google to see whether such studies have
been done and what their conclusions were ;)

Note that, different tools could be more optimal for different text. For an
extremely silly example, if you want to write out "lorem ipsum" text, you
can do it many times more efficiently with a lorem-ipsum generator than by
typing it out in Vim.

A less silly example is the difference between natural language and
programming code. Code is often line-based, and can thus take advantage of
Vim's linewise mappings; for natural language, new sentences do not
necessarily induce line-break (as you can see in the current email). So,
Vim is optimised for coders, and might appear less efficient when used for
natural language.

In other words, first define what type of text you are measuring the cost
for.

I would furthermore claim there exist other "costs" to consider, in
addition to the naive metric of "how long does it take to type something or
other".

I exclusively use Linux, and my work involves a lot of sshing around
between various servers. And all my workstations, laptops, raspberry pis
and NAS run Linux and can be accessed with ssh. For this ecosystem, Vim is
ubiquitous, fast, rock-solid, bandwidth-friendly, and integrates well with
other command-line tools. Regardless of whether I could save a few seconds
on writing this email by using some other editor, that would not stop Vim
from being the overwhelmingly correct choice for me.

In other words, it is not sensible to measure the "cost" of just one tool
as though it exists in isolation; it is better to focus on the pros and
cons of different working ecosystems of tools.

Eg, I would not recommend Vim to someone who has the unfortunate type of
job where they need to work a lot in Windows writing VBA apps (as I did in
a past life). For that kind of work, you are better off using the VBA
editor.

~ 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: