[travislane]

Two questions:

With the advent of capable editors like Visual Studio Code, is Vim still a relevant skill to have?

Is SLIME still the state of the art for Lisp development environment? Is there no way to get started with Lisp programming without having to learn Emacs or Vim?

[least]

Vim, the text editor, might be relevant if you want a powerful text editor that's installed on basically any *nix system ever. Nano has become nearly as ubiquitous so it's unlikely that you'll need to know vi/m on most hosts these days.

Vim, the editing paradigm, is a relevant skill if you value trading time to learn a way of editing text that is vastly different from traditional. It's a faster way of editing that once you grok it will probably make you annoyed about editing text in editors that don't support it. VS Code has a pretty good vim implementation, though. I personally think it was worthwhile, but people value different things. You might not like the investment of time it takes to become proficient or may not find it as useful as I have.

I can't speak to what is the state of the art for Lisp development. I'm confident that you can use editors other than Emacs or Vim for it, though.

[mark_l_watson]

I have no idea why you were downvoted for your questions. Weird. I will try to answer your questions:

One killer application of Vim and Emacs is development on powerful remote servers, for example, you might want 16 cores, a powerful GPU, and 64gig memory for a task so remote exploration and development makes sense. (VSCode does have a remote mode but I haven’t tried it.)

I have been using Emacs for 20+ years with Lisp. I just use Vim for quick edits to I can’t speak to using Lisp dev Vim support.

For local development on my laptop, I now use Emacs or VSCode about equal amounts for Common Lisp, Racket, and Haskell depending on what I am doing. Both are fantastic dev environments.

EDIT: Slime may be old, but it is tried and true technology. LSP is more modern and is a common autocomplete, etc. interface for many languages.

[mwgkgk]

Just want to mention since it's not obvious from your comment, that there are both Vim and Emacs plugins to offer LSP support, and also Neovim is getting a built-in LSP implementation.

[F-0X]

Here's one maybe-reason and one definitely-reason VSCode cannot replace vim for me:

1) Logs are often compressed. Can VSCode open .gz files? Vim behaves pleasingly unixy: 'zcat logs.gz | vim -' opens the file pretty quickly in vim. No fuss with explicit de/recompression. This also ties in to the usual "but ssh" argument, since of course you're likely to be getting logs on remote machines.

2) Bash pipelines are usually an iterative affair. It has some tricks in place to mitigate the issues of very long commands. C-x C-e will open vim to allow you to enter a command, and fc will open vim with the previously executed command already there (short for fix command).

Lastly, vim has an expansive collections of extensions. So much so that if vim is ever "not enough", then neither is VSCode, and I should just use a full IDE.

[harryposner]

A slight correction: C-x C-e and fc open $EDITOR, which is vim by default on most machines. You can change it to anything, though.

[ksaj]

I just use zless and then press v to invoke vim if I need to edit. I don't usually edit logs, mind you. But for other .gz text files, that I might read and then decide on a whim to edit, definitely.

[knolax]

> With the advent of capable editors like Visual Studio Code, is Vim still a relevant skill to have?

That's such a weird dichotomy to present, what feature of Vim did other text editors lack that VS Code managed to replace? Vim is a "relevant skill" because it is a better editing paradigm. VS Code is no more competition to it than Nano or Emacs were.

[abjKT26nO8]

Disclaimer: I'm a long-time Vim user who can't stand editing text without the modal editing paradigm anymore.

Emacs is a competition to Vim, because it has a couple things that Vim does not have:

1. It can understand that a certain part of a file is written in one language and another in another language; and then give you appropriate syntax highlighting, indentation etc. in these specific parts. Vim can't do that.

2. It is an actual GUI application as opposed to GVim which is basically a terminal with vim and a toolbar. It (Emacs) can render proportional fonts, which is really nice when you edit org/LaTeX documents.

3. Its scripting language is a lot nicer to work with.

For these reasons, whenever I can, I use Emacs with evil-mode. For the occasional editing of a file on a server or an embedded device I will still fire up vim (or vi in the latter case, since then vim will usually not be available). I encourage you to try it.

[earenndil]

> [Emacs] can understand that a certain part of a file is written in one language and another in another language; and then give you appropriate syntax highlighting, indentation etc. in these specific parts. Vim can't do that.

Sure it can! Here[1]'s an example of someone using it for html embedded in heredocs.

> [Emacs'] scripting language is a lot nicer to work with.

This is not a fundamental limitation. E.G. neovim uses lua. (I'm not counting python and lua embedded in vim, because afaik they're a total pain to work with.)

I actually recently started transitioning from vim to emacs recently, but I don't think any of your arguments in favour of it are particularly strong. I do, however, agree that vim and emacs are at the cutting-edge of text editing, possibly along with some more niche editors like vis, sam, and kakoune.

1: https://forum.dlang.org/post/[e-mail]...

[mikorym]

Or PyCharm, or Eclipse, or ...

It like asking what do the cool kids code in? And happily, one prudent quora.com user answered: "Smalltalk!" [1]

[1] https://www.quora.com/Which-should-be-my-first-programming-l.... OK, not quite in my words. Also: looks like there is now a subscribe wall...

[stewbrew]

I don't know about VSC but most IDEs are rather difficult to extend. VIM makes it quite easy to create a plugin or prototype new ideas. If you don't need clever code completion etc., VIM is still very useful. Other than emacs, VIM also has some guidelines wrt to code organisation (pack, plugin, autoload, ftplugin, syntax etc.) that make things easier. vimscript is a simple language that has its warts but actually is quite useful in the context of this editor. To some extent, you can write (parts of) your plugins also in python, ruby, lua, mzscheme etc.

So, to some extent it's still useful and relevant. VIM also runs on your android phone, VSC, Idea, Eclipse etc. don't.

WRT to learning lisp, I'd recommend racket. It's scheme and unfortunately mzscheme lacks the libraries, e.g., common lisp has. It's very useful nevertheless.

[williamdclt]

> With the advent of capable editors like Visual Studio Code, is Vim still a relevant skill to have?

My own experience:

- I use VSCode in Vim mode because I'm just more productive with Vim keybindings

- I use Vim for Git commit messages

- I use Vim to edit the odd file (dotfile, config...) or when I'm in a deep terminal session

- I use Vim to view/edit files on servers or local containers

[bananamerica]

Vim and Emacs have a bunch of features that you won't find on editors like VS Code. VS Code has some features you won't find on Vim and Emacs.

One of the great advantages of these "old-school" text editors is the extent to which they can be customized. This is even more true about Emacs, which is mainly written in its own "scripting" language. Almost everything on Emacs is exposed to the user during runtime. It's very easy to make both temporary and permanent changes. Emacs is self-documenting: there are handy commands to find keybindings, variables, and functions definitions. If this is not good enough, you can go straight to the source code and redefine whatever you want. You just need to evaluate the code for it to become available at runtime: no reboot necessary. Once you get used to this level of freedom, it's hard to get used to other platforms.

One thing I'd like to point out is that, even though Vim and Emacs are old, this doesn't mean they're stuck in time. They are constantly updated to support all the current technologies that people might associate with newer text editors like Atom and VS Code.

[Zelphyr]

The answer to your first question is: Yes.

As you say, there are some really great editors like VS Code available these days and I have used many, if not most of them but I keep coming back to Vim. The reason is that I feel so much more productive in it. I can do things with three simple keystrokes that are quite a bit more involved in other editors. And that’s pure, stock Vim without any plugins. It’s astounding what I can accomplish with the addition of some plugins.

Really, in the end, it’s just another tool that fits me well. It may not fit you as well and that’s ok. But there is definitely still a place for old-school editors like Vim and Emacs in a modern developer’s toolkit.

As an aside; I don’t know why OP was downvoted so heavily. There is absolutely nothing wrong with asking a question such as this. I have to account for the possibility that it was edited to be less caustic by the time I read it but, if that wasn’t the case, I think all who downvoted it should re-evaluate their decision to do so. We should celebrate the desire to understand something and, from what I can see, that’s all this person is trying to do.

[threatofrain]

In my mind the main reason why Vim still has relevance today is for seat-of-your-pants SSH'ing, which admittedly shouldn't be done but it still is. Outside of that...

I still have hope for structural editing but I don't see Vim as the innovator in that space anymore.

https://www.youtube.com/watch?v=CnbVCNIh1NA

[mikorym]

I think you should use the environment that makes you the most productive (and happiest).

For me that is vim.

But I also have the questionable (and questioned) opinion that, for that matter, you can write a state of the art program in Fortran. If you happen to find a O(n) algorithm for prime factorisation, and you write it in Fortran, would it not be state of the art?

[aidenn0]

SLIME has a successor now called Sly, but yes that's still state of the art for Lisp programming.

No, you don't have to learn emacs to get started with Lisp though. You'll just have an inferior experience.

As a side note, if you do start to learn without emacs, please use something like this[1] for formatting your code. Most editors lack a Lisp indentation plugin, and any time you ask a question online, whomever answers it will have to reformat otherwise.

1: https://github.com/ds26gte/scmindent (it's even in npm)

[lokedhs]

I don't think it's fair to call it a successor since it intentionally doesn't implement all the features of Slime.

I'm specifically talking about presentations which were removed because the author of Sly never uses them. For the first people who do, however, Sly can never be a successor to Slime.

It may be an alternative, and a pretty good one, but not enough a successor.

[aidenn0]

I didn't realize it lacks presentations, as I'm still using slime. That's good to know.

[ksaj]

> You'll just have an inferior experience.

I detect an emacs joke here.

[pletnes]

I use, or have used, vim bindings in vscode, visual studio on windows, etc etc.

Sometimes you run across large ascii files, e.g csv data files, and vim is the only editor that can open them.

Vim is available virtually everywhere you have a unix-resembling system, including gitbash on windows.

And sometimes you need to edit some config file in a weird environment over ssh and there’s nothing else present.

Oh, and macros can help with laborious file conversion processes. Etc.

[Aperocky]

Vim is highly customizable, the one you get on most unix systems are engines and transmission only.

The engines and transmission are incredibly powerful, the only problems is you sit on top of metal with a stick as your wheel.

But you can turn all that into a fully working luxury car/truck/whatever you like by digging in and customizing it. In the age of "don't build the wheel", you can also do that by installing component that other people have built already.

[lispm]

I don't think learning GNU Emacs using a window-based version would be too difficult. The obvious advantage is better tool support via SLIME for interactive Lisp development with SBCL.

Support for development with Common Lisp in Visual Studio is relatively primitive and has very little momentum - at least that's my impression.

[kgwxd]

If you're running on a battery and aren't sure you'll be able to plugin in the next 10 minutes.

[microcolonel]

I don't really see why you would write any lisp in an editor that isn't Emacs. Visual Studio Code is very capable... of jumping in to a hot loop periodically to crash or require you to kill it, sapping your battery at idle, and making rookie mistakes long-since corrected by the 40-year editors.

If I were looking to replace Emacs, replicating CIDER is a tall order, especially CIDER over TRAMP. Tell me when you can automatically shell into your high-memory remote machine with an editor running locally, and get a full REPL with inline evaluation on the remote machine.. and it "just works" (i.e. install the package from MELPA, and it works out of the box).