| HN Mirror

>Here's a reason to start from scratch: You don't need to dig through the complex, customized setup of someone else and figure it all out. You also don't need to learn unfamiliar software without even knowing what parts are integrated by default and what's customized.

>Starting from a clean setup means I know exactly what every part of my configuration does. I can still use a default Vim setup on a server because I started from that and added every change myself step by step as I learned new things about the editor.

Again, vim itself constitutes a complex, customized setup of someone else that you have to figure out. There's obviously a scale here -- you've just picked a point on that scale and declared it the correct place to be (write your own vim clone, and you'll really know what every part does). And really, if you want your knowledge to be truly portable, you probably shouldn't be modifying vim whatsoever (or perhaps specifically, none of the defaults), because you'll deviate from a default Vim setup on arbitrary servers (change jk to <ESC> and you'll burn the wrong thing into your muscle memory, and perhaps even forget ESC...).

But the value of customizing vim is... to customize it! To adapt it to your workflows and fashion. Treat default/server vim as some unique, pure instance of vim, perhaps even as a separate editor altogether, and treat your own vim.. as your own! And then it doesn't really matter. And regardless, unless your vim package is doing some dramatic changes to vim's fundamental model and design, it's rather trivial to know both -- so trivial I'd consider it an overblown non-concern.

The bigger concern with these packages (and where I think the "start from scratch" mentality generally derives from) is that vim's extension model is rather fragile, and pretty much lacks any useful debugging tool, so when it comes time to debugging why your copy is so slow in certain scenarios, there's really not much you can do except read and reason about the config file(s) thoroughly, which of course is much harder if you didn't write it.

>The "stealing" part of that phrase, in its original meaning, implies deep understanding of what's being acquired.

I've always interpreted it as taking ownership over the concept -- you copy it, and then infuse your own mutations into it to produce something uniquely qualified for the constraints and context you're plugging it into. A deep understanding is a nice to have (to better mutate it more effectively, and correctly), but not necessary for usage of the concept/tool (in the fashion that, for vim, I must understand the "vim mindset", but I don't need to know vim internals to be successful, or to have succesfully stolen it for my own machinations). Understanding is not the key here, it's ownership.

Another way to view it is like christopher alexander's pattern theory -- the base patterns are communally known and shared, and can be plugged in freely to the design. However, to be made beautiful, the pattern must be modified to fit within the constraints of its environments... including the other patterns in use (as well as any unique constraints for the situation, e.g. the home owners requirements, geographic requirements, etc). Those modifications impact the others, which then impact the object under question, in a kind of feedback loop until you reach an equilibrium.

That is, patterns (usage of libraries, packages, frameworks, etc) are not at all a problem. The mistake would be to stop there, and not further adapt it as needed. Or rather, to misunderstand the pattern as the final design. Another example from a programmatic perspective, to take a pattern like OOP FACTORY and construe the design as somehow "pure" and refuse to modify it despite your requirement really being "a bit like a factory, and a bit like a singleton" or what have you.