3 ms·

I'm currently hiring 5 software developers for a startup that I'm consulting with. On some level, I'm aware that it would help team cohesion if we could all use

I'm currently hiring 5 software developers for a startup that I'm consulting with. On some level, I'm aware that it would help team cohesion if we could all use one text editor. But for the most part, it's a decision that I leave to each developer, as it is a decision that can be left to individuals. If we were going to use a language such as Clojure, where the whole eco-system tends to use emacs and offers examples in emacs, then I might try to introduce emacs, but the opposite is also true: the feeling that developers should learn emacs is one of the things that makes me wary about recommending Clojure to clients, even though Clojure is the only language I use in my personal projects. But for this current client I think we will mostly be working with Javascript, so I think most of the people we hire will be happier with their IDE of choice, or with Sublime. I do wish something like emacs existed in slightly more modern form. I'd be thrilled if there was a modern text editor that allowed me to customize the app however I wanted by writing additional code in the language that the text editor is also written in (that is, repeating the relationship that emacs has with elisp). But it seems unlikely that anything like that will ever exist, so I go on using emacs, but I don't recommend for any clients.

resoluteteeth 5y ago
> I do wish something like emacs existed in slightly more modern form. I'd be thrilled if there was a modern text editor that allowed me to customize the app however I wanted by writing additional code in the language that the text editor is also written in (that is, repeating the relationship that emacs has with elisp). Is there some reason you don't consider this to apply to vs code?
- lkrubner 5y ago
  VSCode is very good. I could write something about Lisp being homoiconic, also I don't know the VSCode equivalent of "advise", macros rewriting core functions of the editor, but I'll let someone else make that case, if they feel like it.
- alex_smart 5y ago
  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. https://code.visualstudio.com/api/get-started/your-first-extension 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.
monsieurbanana 5y ago
Calva on vscode is probably the most beginner-friendly way to start doing Clojure, and has a lot of features thanks to the use of clojure-lsp. It even includes a quick interactive tutorial for Clojure and structural editing (which is something mandatory to really give lisps a try, IMO).

resoluteteeth 5y ago

> I do wish something like emacs existed in slightly more modern form. I'd be thrilled if there was a modern text editor that allowed me to customize the app however I wanted by writing additional code in the language that the text editor is also written in (that is, repeating the relationship that emacs has with elisp). Is there some reason you don't consider this to apply to vs code?

lkrubner 5y ago
VSCode is very good. I could write something about Lisp being homoiconic, also I don't know the VSCode equivalent of "advise", macros rewriting core functions of the editor, but I'll let someone else make that case, if they feel like it.
alex_smart 5y ago
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. https://code.visualstudio.com/api/get-started/your-first-extension 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.

monsieurbanana 5y ago

Calva on vscode is probably the most beginner-friendly way to start doing Clojure, and has a lot of features thanks to the use of clojure-lsp. It even includes a quick interactive tutorial for Clojure and structural editing (which is something mandatory to really give lisps a try, IMO).