Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I teach vim

blog.ceos.io

Post reply on HN
Print view View original

181–185 of 185 posts

Re: Why I teach vim

#181

Post by beny23 »

maccard wrote: post #68
beny23 wrote: post #65

The ability to efficiently navigate and edit files while SSH’d into an instance is a very useful skill. You just wouldn’t have the permissions to install your favourite editor and vi is almost everywhere. I had to learn vi when working on green screen terminals logged into HP/UX and there was no alternative but am very glad I did as I find that nothing as ubiquitous allows me to efficiently change files. Does that me…

I've been a professional developer for 10 years and programming for longer than that. In all of that time, efficiency of editing files on a remote server has never been something I've needed to optimize or been concerned about. Have I had to do it? Yeah, occasionally. Yet when I do, it's almost always changing a config file in a minor way. Back when I started it was editing the code on a live server so I used textwra…

Of course with the ubiquity of cloud and minimal images I think the likelihood of having any but the basic tooling on a remote instance is getting more prevalent than not less and the ability to diagnose/debug issues is getting more important. Might not be a Dev but more of an Ops “good to have” but with more places adopting “you build it you run it” and Dev merging with Ops, I don’t think this is an isolated use case.

Re: Why I teach vim

#182

Post by gen220 »

HowTheStoryEnds wrote: post #175
alvarosevilla95 wrote: post #104

Earlier quoted context omitted.

You should read about the language server protocol. As it continues to become the standard vim will match most IDE-specific features while keeping all the benefits of using vim, which if you can't see I won't bother listing here. I'm already working on java 100% from vim and I don't miss a thing from intellij

Would you mind elaborating a bit on that for those of us not in the loop, like myself? Which plugins are you using?

Not the OP, but the plugins you want to look up are ALE and coc.

I've used ALE for a while and love it, but coc is the new kid on the block that often shows up in discussions of LSP.

ALE is very tunable, so it's good for us performance-nuts who don't want anything slowing down their editor without their permission.

coc takes a more batteries-included approach, and will allow you to hit the ground running / see the light sooner.

Re: Why I teach vim

#183

Post by greggman3 »

gen220 wrote: post #180
greggman3 wrote: post #177

Earlier quoted context omitted.

Unfortunately I'm not understanding what makes vim special here > It works wonderfully with make, so you can run “make $file” in a couple strokes I can do this in any editor I've ever used > Another example is when I’m “cleaning” a large csv file. Most times, I can record my movements cleaning a single line, and then replay those actions N times. I can do this in most editors I used (VSC being an exception). I use re…

To clarify, I don't think these (or any) features are "vim-only". I was intending to say that it's the meta-feature of vim that vim-users find so sticky, that you can trivially write your own features: composing arbitrary executables and modal editing. I think most editors nowadays are taking a page out of vim's book, by exposing increasingly lower-level interfaces to extension authors and users. In these ways, I thi…

I've had all those features in every editor I've used since the late 80s so no, no one is taking a page from vim or emacs.

Re: Why I teach vim

#184

Post by gtsop »

greggman3 wrote: post #100
gtsop wrote: post #67

Earlier quoted context omitted.

> My current theory is vim users are like vegans/gluten free/paleo/etc, in that its a personal choice that some are public about. This is not a good theory. Surely, this effect appears wherever you've got conflicting choices about what is best, but there are always reasonable arguments on why you should do X over Y. And you know, there are always people who respect other's choices. I am a vim user and I 100% understa…

I am curious if any vim user has ever been able to see the benefits of other environments. I know I have never been able to see the benefits of vim. Part of me wants to give a try for 3-6 months just to prove to myself that it's all bullshit and that vim is just another editor. In any case. For a long time I was a fan of my editor of choice, slickedit. It definitely has a few features I use for which I don't know the…

> I am curious if any vim user has ever been able to see the benefits of other environments.

Yes they can. Let me list them: 1) Familiarity 2) Ready out if the box, less effort 3) For specific languages and projects, you can't do it vim. Javascript is not one of those. Maybe android development is.

> I am saying if I tried to start using vim today on the projects I'm working on the experience would be seriously inferior.

Correct, it would be a BIG pain, and I know because I have done it. It sucks hard. But if you suck it up and start molding this extremely flexible editor to your needs, after a few months you will get a far superior experience than your out-of-the-box IDE. The most important aspect of all is that you reason differently about writting and editing text, in a much more efficient way than normal.

But by no means do I judge people for not doing it, as I said in my initial comment, everyone has their needs. Vim turned out to give me great power and comfort after all and I can barely go back to another editor. Maybe it's not the same for you. All is fine.

Re: Why I teach vim

#185

Post by camgunz »

greggman3 wrote: post #178
camgunz wrote: post #160

Earlier quoted context omitted.

I'll bite; I'm real good w/ Vim. My thesis, which is a borderline polemic, is that if Vim doesn't suit your needs you are doing it wrong. If your program/language/environment needs a smart editor, you've built or chosen a program/language/environment that is too complex, and an IDE won't ever solve that fundamental problem. I get we don't always get to choose these things (wh o hasn't had to learn React, Typescript,…

hmmm, if I apply that logic in other places it doesn't seem to work. * if you can't cook with just a knife then it your food should be redesigned to need only a knife. * if you can't film in with a camera then you should rewrite your movie (no CG). * if you can't send it by paper then it should be re-written (no animation, no interactive diagrams, no apps) To put it another way, I'd much rather use Final Cut Pro or D…

It's not about force multipliers in general. It's about looking at what force multipliers incentivize/deincentivize and amplify/muffle.

With your examples, I would say something like:

OK I once only had a knife, but now I've invented an egg beater. This will allow me to do some things a lot more easily like:

- Bake cakes

- Eat soup

This will also mean I cut myself a lot less when I do decide to do something like eat soup.

So we're gonna have more cakes/soup in the world. Good? Great, egg beater stays. Bad? Woof, burying this thing in the yard. But wait I hate cutting myself. OK I'll figure out some other way to keep myself from gorging on cakes, or I guess be content with that.

So, broadly it's about thinking systemically--how the design of our tools affects how and what we build. Because it definitely has an effect. If it's easier to use a nailer than a screw gun, guess what, you're nailing more stuff. If it's easier to write a PRECONDITION clause in a function definition than a unit test, guess what you're writing a PRECONDITION clause.

Post reply on HN