Off topic, but the best explanation I've seen of the trade-off between OOP and functional approaches is in the book Crafting Interpreters where they explain the Expression Problem - https://craftinginterpreters.com/representing-code.html#the-...

That is off-topic, but it is an interesting explanation. It’s a useful example for thinking about a lot of design situations where two different approaches both seem equally feasible yet are very different and incompatible.

God that is a phenomenal explanation, it's beautifully put together.

many of our positions are emotionally-driven, and then backwards-rationalized

reality: this is too complex for me rationalization: I didn't think there was market fit

reality: It's hard to learn technology x rationalization: OOP / framework / language sucks

But Emacs IS better than vim. ;)

Can't we all just get along?

And by that I mean, can't we all just gang up on nano?

I know you kid but the killer features for nano are that

one it is very simple and intuitive

And two, it has the (two? It has been a few years) row footer that literally tells you what buttons to push to save or exit. I didn't know how to exit vim when I first started with git, as is tradition.

I agree about there being no good reason for Vim being so difficult to terminate.

I've introduced a few people to Vim and I have to start out with an apology for how annoying it is to close. If the user hammers the Esc key, it should at least flash up with a hint of how to quit.

It does this if you press ctrl-c, so it's not as if it can't be done.

That's a great idea. I can take it even a bit further though. The defaults matter. Maybe show a persistent thing at the bottom on how to exit and maybe even throw in what to do if you pressed Ctrl + s and now vim is "not responding". But this involves changing the defaults so it will likely never happen, same way as we will probably never see curl automatically enter a new line at the end of a response.

Personally I wouldn't want that cluttering my Vim sessions, but it would make sense for some sort of 'introductory mode' of Vim.

(gVim Easy seems to just be gVim restricted to insert mode. Not sure I see the sense in that - isn't that just Notepad++ but worse?)

If I could change one thing about curl, it would be for -L to be the default behaviour, so that it would just do the right thing regarding redirects. Instead, wget does the right thing by default, but curl always needs the flag.

We recently got a very green new hire at work. I told him to learn some vim because it would be helpful for him. He went rogue and used nano instead.

If they're new to the command-line, I can see why they'd want to go with something approachable like Nano.

If they're already comfortable with the command-line, but don't know Vim or Emacs, I'd keep encouraging them to take the dive.

Of course, there's also gVim, so perhaps that's not quite the right way to think about it.

The vscoders are the real black-hearted traitors.

Vimmers used to mock Emacs as Eight Megabytes And Constantly Swapping. We can make that Eight hundred in the case of Electron-based editors.

(I'm also fond of Escape Meta Alt Control Shift.)