The process of writing Emacs-Lisp: open the scratch buffer, write a function and eval. The process of understanding what any part of the editor is doing: C-h f <function name>, read the documentation and link to the source is again right there. You can go to the source, set up a breakpoint, step through the code, understand it and even modify in place if you feel like it.
There is no other environment I know of, apart from smalltalk, that makes the process of extending and customizing the environment that frictional-less.
I have tried to understand the process of extending vs code, but it seems to require a lot of ceremony.
For instance, everything needs to belong in an extension, and you run the extension in different instance of vscode rather than the one in which you are editing the extension, which you have to reload/restart everytime you change the extension's definition.
The difference in experience is similar to the difference in experience in REPL-driven development in an interpreted language v/s developing in a compiled language with the whole edit/compile/run cycle.
There is no other environment I know of, apart from smalltalk, that makes the process of extending and customizing the environment that frictional-less.
I have tried to understand the process of extending vs code, but it seems to require a lot of ceremony.
https://code.visualstudio.com/api/get-started/your-first-ext...
For instance, everything needs to belong in an extension, and you run the extension in different instance of vscode rather than the one in which you are editing the extension, which you have to reload/restart everytime you change the extension's definition.
The difference in experience is similar to the difference in experience in REPL-driven development in an interpreted language v/s developing in a compiled language with the whole edit/compile/run cycle.