Defo worth posting. Reminds me of when I wrote a BASIC interpreter in Scheme. It came in two parts: a line parser and a “BASIC abstract machine” whose instructions were data structures consisting of a line number, a keyword, and arguments.

Carcinization is the Greenspun’s Tenth Law of aquatic arthropod evolution.

It’s an iron law of software development that the more you can prove at compile time, the fewer bugs will creep in at run time. The future of software development will look a lot less like Lisp and a lot more like Rust. Strong static typing with parametric types is table stakes for a modern language. Ideally you want static object lifetime management too. Inasmuch as Lisp can adopt these things it still might be a niche contender.

If you want a VS Code-like experience with no effort, you know where to find VS Code.

You use Emacs for an Emacs-like experience – that is, a reasonable starting point, but with infinite customizability, to the point where you are modifying and extending your editor as you work with it.

You can begin coding in Python, Go, and Bash today with no additional add-ons. You may have a tough time of it at first if you’re used to relying on autocomplete. Generally the first must-have package you should get is the major mode for whatever language you’re working in (if it doesn’t already come with Emacs). I generally use ivy to provide completion for things like file and buffer names, M-x commands, etc. so that’s also a good choice. Eglot or lsp-mode is commonly used to provide autocomplete via Visual Studio Code’s LSP.

Finally I recommend enabling auto-revert-mode, so that Emacs keeps itself automatically in sync with changes made to a file outside itself. This is built into Emacs.

Yeah, t and nil are self-evaluating symbols in Lisps that use them, like Common Lisp and Emacs Lisp. Don’t sweat it, just keep that in mind.