[imiric]

For me it's not so much about the process of learning itself. To be honest, I'd rather avoid having to learn how a tool works to use it. Software that prioritizes ease of use and friendliness has a much broader appeal—and, consequently, user base—than those that don't. There's value in that.

I chose to learn Vim, Emacs and other tools with a steep learning curve primarily because of their return on investment. They have great extensibility, so I can customize them exactly to my liking. I know that they won't radically change, or worse, disappear in a few years, as a lot of software does. So taking the time to learn how to use them is purely a selfish endeavor. I even put up with their quirks and shortcomings because of this, even though there might be alternatives that do feature X better, are faster, etc. Using these tools simply minimizes the chances I'll have to re-learn something else every few years. I'd rather avoid that.

[globular-toast]

> Software that prioritizes ease of use and friendliness has a much broader appeal—and, consequently, user base—than those that don't. There's value in that.

Why is that? If a tool is so simple that you don't need to learn anything about why does it matter how many people use it? There won't be a community for it because there's nothing to say. That would be learning about said tool which is the very thing we're trying to avoid.

Perhaps you were thinking ubiquity. But, in fact, the most ubiquitous text editor is probably vi/vim!

[imiric]

> If a tool is so simple that you don't need to learn anything about why does it matter how many people use it?

Are you saying there is no value in a tool having a large user base? The web and mobile app revolutions happened largely _because_ the software was accessible. If people needed to read manuals to learn how to use Facebook or TikTok, those projects never would've become popular. Microsoft and Apple built their empires on making operating systems easy to use. Obviously this is very valuable to many people.

If a tool is popular, it is more likely to be a sustainable income source for its authors, and thus more likely to continue to exist. Everyone benefits from that.

> There won't be a community for it because there's nothing to say. That would be learning about said tool which is the very thing we're trying to avoid.

A community doesn't just exist to discuss how to use a piece of software. It may consist of enthusiasts, discussions about program features or changes, value added services, etc. Besides, a community about the software itself is not required for it to be successful. Software can be popular just because people enjoy using it, and what it allows them to do.

> Perhaps you were thinking ubiquity.

No, I wasn't. I'm just saying that accessibility and ease of use are large factors in how popular a piece of software can be. Vi(m) had very humble beginnings and its growth was gradual over several decades. Yet it still pales in popularity compared to something like VS Code (see the Stack Overflow Developer Survey). Why do you think that is? Do you think Vim or Emacs will ever make it to the top of that list? What would need to happen for that to happen?

I'm not saying that chasing that metric is important. But there's safety in numbers.

[globular-toast]

Not following your argument. You start by talking about tools with a network effect which is totally irrelevant for something like a text editor (assuming it supports common formats like utf-8). Then you talk about tools being simple to use making them popular, which I never disputed.

[SanderNL]

Developer productivity is not and never was bottlenecked by their tools.

One snap of the fingers in one of the many layers above us and million dollar projects succeed or fail. We are always a fancy dinner or business relation gone sour away from success or failure.

Vim or emacs come into play at layer 245 in the system and their impact on the final business reality is approximately 0,003%.

[globular-toast]

> Vim or emacs come into play at layer 245 in the system and their impact on the final business reality is approximately 0,003%.

Who cares? One fire or war and a carpenter's work all comes crumbling down. Should he then not care about his work or his tools or materials and nail any old shit together? Life is what happens when you're busy making other plans.

[SanderNL]

Who cares? Those who measure actual impact instead of showing off.

Focus on what matters is my only advice. Hint: it’s not your editor.

[freedomben]

Sure, sometimes higher layers end up killing a project before it ships. But there is still a lot of code that ships. For that code, the editor choice may have mattered. I have shipped a lot of code in my day, and since learning vim I have been much more productive. There are projects that may not have even existed were it not for Vim, because I would not have had time to get it done in the tight deadline needed.

But more importantly, I like Vim. It makes me enjoy the process much more. I do carpentry in my spare time, and I think of them much like I do my favorite carpentry tools. While they do enable some projects that otherwise couldn't have happened, most of the time their impact is just improving my experience and quality of output. That matters a great deal to me, regardless of whether it matters several layers up.

[globular-toast]

You can talk all day about high-level actions and wishes but, at the end of the day, someone needs to write some code. That's me. That's what I do. It matters.

[layer8]

For many, the editor is the software that they spend the most time using. It certainly matters knowing how to use it well.

[fragmede]

just because the project got cancelled and won't ship doesn't reduce the rate of developer productivity on the project though. it sucks when your code won't ship, but the craftwork imbued in the source is still there.