5 ms·

I don't have anything against Lisp, I program Emacs with it, but wouldn't you get mostly the same features if Emacs used Javascript for its programming, for exa

I don't have anything against Lisp, I program Emacs with it, but wouldn't you get mostly the same features if Emacs used Javascript for its programming, for example?

codemonkey-zeta 6y ago
Macros and symbols (even though he technically has Symbols) come to mind as indispensable aspects of elisp which cannot be replicated in JavaScript. Ignoring the fact that Emacs predates JavaScript significantly of course.
- tarruda 6y ago
  Aren't macros a just form of code generation?
  - mpereira 6y ago
    Hey Thiago! You are mentioned in the essay that contains the article in this HN post btw :) Check out the Neovim section in https://www.murilopereira.com/how-to-open-a-file-in-emacs/#the-values-of-emacs https://www.murilopereira.com/how-to-open-a-file-in-emacs/#t...
    - tarruda 6y ago
      Hi Murilo, thanks for the mention :)
  - Scarbutt 6y ago
    Aren't cars just a form of transportation? (sometimes cars are just more convenient than walking)
  - PuercoPop 6y ago
    Yes, but they are an 'in-process' form of code generation. The distinction is important. Especially when you are extending the system on the fly. A lot of the pain regarding JS build-systems could be avoided with macros (and reader macros/a customizable reader). Babel is literally macros + a reader.
Jtsummers 6y ago
I've been pondering this for a while. I think you could have a JS-based editor that approaches or achieves what emacs offers, but I haven't encountered it. One useful thing about emacs and elisp is that lisp is one of the primary modes of interaction for users, whereas (IME) many JS-based editors seem to hide JavaScript from you to some extent. Not in the sense that it's not there, or that there's a second language that the JS interprets. But when you open emacs without specifying a file to open you are dropped into a buffer called *scratch* which lets you directly execute elisp code. It really is a central part of the experience of using emacs. Similarly, your configuration file(s) are written in elisp, versus often a subset of JavaScript (perhaps JSON) used in JavaScript-based editors. And you're not just supplying configuration data, but extending the program. And then there's completeness. While emacs has parts written in C, that portion really exists to enable elisp. Essentially every capability of the editor is directly reachable through lisp. The same doesn't seem (or at least feel) true of JavaScript-based editors I've tried. In those, it often feels more like the creators have selected a portion of the internals to expose to users, but it's more the minimal amount needed rather than the maximal amount possible that emacs strives for. EDIT: I've finally figured out how to insert an asterisk around a word on HN without needing spaces. Is this documented anywhere? Just use double asterisks on either end like **foo** *foo* Turns out this is in the FAQ, it's been a while since I looked at the formatting part of that so I guess it changed since 10 years or so ago or I'd forgotten.
- adamnew123456 6y ago
  The Advent of Computing [1] podcast recently put out their episode 47 which I think provides a sort-of explanation of this line of thinking. The short answer is that the context in which Emacs was originally developed (a contemporary of Unix, and not Unix itself, which was something I wasn't aware of before) emphasized user power and lack of restriction to a much greater degree than much of the current computing landscape does. Why would you lock users or developers into a fixed, defined plugin API when you could write the application in such a way that they have access to whatever they need? Excluding maybe NodeJS, most of the Javascript you encounter is going to be executed by a browser which has a whole ton of sandboxing and mitigation mechanisms to prevent the big bad web from abusing your computer. I don't blame it for working that way given how few trustworthy (I mean really trustworthy, as in "free range within $HOME") actors exist on the web these days, but one wonders how far we could take the web ecosystem if we tossed the idea of granting special access through WebGL or WebUSB and just gave the browser full access to calling C or executing processes on your system. Don't get me wrong - it would be a security nightmare, but there's a cost to trying to guarantee security through mechanism rather than trust. [1] https://adventofcomputing.libsyn.com/episode-47-its-open-computing https://adventofcomputing.libsyn.com/episode-47-its-open-com...
DDSDev 6y ago
I think this is a good counter point, which is why I made a version of emacs fully scriptable from javascript and typescript [0] [0] https://github.com/emacs-ng/emacs-ng https://github.com/emacs-ng/emacs-ng Disclosure I've posted about this on HN in the past, but I felt it was very relevant to the parent comment.
timonoko 6y ago
There are plenty of Emacses programmed in C-like languages. Oldest I can remember was Epsilon. "Epsilon was first released in 1984, long before Emacs was available on personal computers, and modestly priced, so it provided an attractive alternative to the usual DOS editors for those accustomed to Emacs."
- timonoko 6y ago
  Corrección:"Programmed" in C, but "programmable" in EEL, simplified C-language.
mhh__ 6y ago
I guess you could but why would you choose to use javascript?
bumbada 6y ago
No, js is not powerful enough for getting the same features that Emacs have, because emacs is almost an operating system. With js you could create a very simplified version, if you remove 95% of the emacs codebase. Most people just use 1-2% of emacs anyway, and there are editors that just do that, control a simple text editor with js.

I don't have anything against Lisp, I program Emacs with it, but wouldn't you get mostly the same features if Emacs used Javascript for its programming, for example?

codemonkey-zeta 6y ago

Macros and symbols (even though he technically has Symbols) come to mind as indispensable aspects of elisp which cannot be replicated in JavaScript. Ignoring the fact that Emacs predates JavaScript significantly of course.

tarruda 6y ago
Aren't macros a just form of code generation?
- mpereira 6y ago
  Hey Thiago! You are mentioned in the essay that contains the article in this HN post btw :) Check out the Neovim section in https://www.murilopereira.com/how-to-open-a-file-in-emacs/#the-values-of-emacs https://www.murilopereira.com/how-to-open-a-file-in-emacs/#t...
  - tarruda 6y ago
    Hi Murilo, thanks for the mention :)
- Scarbutt 6y ago
  Aren't cars just a form of transportation? (sometimes cars are just more convenient than walking)
- PuercoPop 6y ago
  Yes, but they are an 'in-process' form of code generation. The distinction is important. Especially when you are extending the system on the fly. A lot of the pain regarding JS build-systems could be avoided with macros (and reader macros/a customizable reader). Babel is literally macros + a reader.

Jtsummers 6y ago

I've been pondering this for a while. I think you could have a JS-based editor that approaches or achieves what emacs offers, but I haven't encountered it. One useful thing about emacs and elisp is that lisp is one of the primary modes of interaction for users, whereas (IME) many JS-based editors seem to hide JavaScript from you to some extent. Not in the sense that it's not there, or that there's a second language that the JS interprets. But when you open emacs without specifying a file to open you are dropped into a buffer called *scratch* which lets you directly execute elisp code. It really is a central part of the experience of using emacs. Similarly, your configuration file(s) are written in elisp, versus often a subset of JavaScript (perhaps JSON) used in JavaScript-based editors. And you're not just supplying configuration data, but extending the program. And then there's completeness. While emacs has parts written in C, that portion really exists to enable elisp. Essentially every capability of the editor is directly reachable through lisp. The same doesn't seem (or at least feel) true of JavaScript-based editors I've tried. In those, it often feels more like the creators have selected a portion of the internals to expose to users, but it's more the minimal amount needed rather than the maximal amount possible that emacs strives for. EDIT: I've finally figured out how to insert an asterisk around a word on HN without needing spaces. Is this documented anywhere? Just use double asterisks on either end like **foo** *foo* Turns out this is in the FAQ, it's been a while since I looked at the formatting part of that so I guess it changed since 10 years or so ago or I'd forgotten.

adamnew123456 6y ago
The Advent of Computing [1] podcast recently put out their episode 47 which I think provides a sort-of explanation of this line of thinking. The short answer is that the context in which Emacs was originally developed (a contemporary of Unix, and not Unix itself, which was something I wasn't aware of before) emphasized user power and lack of restriction to a much greater degree than much of the current computing landscape does. Why would you lock users or developers into a fixed, defined plugin API when you could write the application in such a way that they have access to whatever they need? Excluding maybe NodeJS, most of the Javascript you encounter is going to be executed by a browser which has a whole ton of sandboxing and mitigation mechanisms to prevent the big bad web from abusing your computer. I don't blame it for working that way given how few trustworthy (I mean really trustworthy, as in "free range within $HOME") actors exist on the web these days, but one wonders how far we could take the web ecosystem if we tossed the idea of granting special access through WebGL or WebUSB and just gave the browser full access to calling C or executing processes on your system. Don't get me wrong - it would be a security nightmare, but there's a cost to trying to guarantee security through mechanism rather than trust. [1] https://adventofcomputing.libsyn.com/episode-47-its-open-computing https://adventofcomputing.libsyn.com/episode-47-its-open-com...

DDSDev 6y ago

I think this is a good counter point, which is why I made a version of emacs fully scriptable from javascript and typescript [0] [0] https://github.com/emacs-ng/emacs-ng https://github.com/emacs-ng/emacs-ng Disclosure I've posted about this on HN in the past, but I felt it was very relevant to the parent comment.

timonoko 6y ago

There are plenty of Emacses programmed in C-like languages. Oldest I can remember was Epsilon. "Epsilon was first released in 1984, long before Emacs was available on personal computers, and modestly priced, so it provided an attractive alternative to the usual DOS editors for those accustomed to Emacs."

timonoko 6y ago
Corrección:"Programmed" in C, but "programmable" in EEL, simplified C-language.

mhh__ 6y ago

I guess you could but why would you choose to use javascript?

bumbada 6y ago

No, js is not powerful enough for getting the same features that Emacs have, because emacs is almost an operating system. With js you could create a very simplified version, if you remove 95% of the emacs codebase. Most people just use 1-2% of emacs anyway, and there are editors that just do that, control a simple text editor with js.