5 ms·

Emacs is a little harder to write plugins for, but it runs natively and the only impediment is that more people know JS than they do elisp.

by ue_ 10y ago

dahauns 10y ago
Lots of emacs functionality runs via its lisp VM. I'd hardly call that 'native'. I mean, Emacs had jokes about being bloated decades before Javascript (and Java, another contender for these jokes) even existed. :)
- gmfawcett 10y ago
  Most of those jokes are completely out of date. "Eight Megs and Constantly Swapping" used to be a big deal, but today it's not. I don't think running Elisp in Emacs takes away from it being "native." At least insofar as there are no popular text editors (that I know of!) which expect you to compile your plugins and macros to native code. They all have interpreters of one kind or another. What Emacs doesn't have, though, is an inner platform effect: Emacs is the platform, there isn't a second one underneath (no browser engine).
  - pantulis 10y ago
    Which begs the nice corollary: the definition of "native" doesn't happen to be fixed and changes with time.
    - gmfawcett 10y ago
      Well, language is like that. :) But I don't think describing Emacs as "native" here is very different from how the word was used decades ago. To me, "native" is less about how the logic is represented (compiled vs. interpreted code) and more about its execution context. If the host system is an operating system, then the application is native; if the host system is another application, then it's not. I agree that the boundary is blurrier for applications that have scripting interfaces; but I think that most applications don't live very close to that boundary, and are clearly in one camp or the other. (Maybe Emacs is nearer to the edge: there's an old joke that Emacs is a great operating system, it just needs a better text editor.) Having said all that, I don't think that "non-native" is a pejorative. I use Emacs, but would switch to a "non-native" editor if there were a good reason. I use IDEA (native or not? you decide!) when working on big Java projects, and Emacs for everything else, because Emacs affords me a lot of power that I find lacking in other editors. "Nativity" isn't really part of the equation, it's really about functionality.
      - lispm 10y ago
        GNU Emacs comes with its own portable execution platform (the byte-code Lisp execution engine), where Java applications typically use a provided virtual machine. As such GNU Emacs is just as 'non-native' as a JVM-based editor.
        gmfawcett 10y ago
        Almost agree with you! If the Emacs VM were used for applications other than Emacs -- if it were a general purpose VM -- then I'd completely agree.
        lispm 10y ago
        There are lots of applications written on top of GNU Emacs, but most of the time they use the specific UI and features of an editor, or integrate with the editor. Example: the calculator of GNU Emacs. https://www.gnu.org/software/emacs/manual/html_mono/calc.html https://www.gnu.org/software/emacs/manual/html_mono/calc.htm...
    - dahauns 10y ago
      Case in point: https://news.ycombinator.com/item?id=13944757 https://news.ycombinator.com/item?id=13944757 :)
  - lispm 10y ago
    GNU Emacs Lisp code is certainly not native - not until a JIT will be widespread. GNU Emacs usually compiles Lisp code to a byte code which is interpreted by a byte code engine written in C. If you use a Common Lisp based editor like Clozure CL, Allegro CL and LispWorks have, they don't use a C-based byte code interpreted. The Lisp code is compiled directly to native code. Which makes editor extensions running in natively compiled Lisp code. The advantage of the c-based byte code engine is compact code and improved portability - since the C compiler will already be provided with most platforms, whereas a native Lisp compiler is typically not something provided by a platform (CPU/OS/...) vendor...
    - gmfawcett 10y ago
      I should be more clear. I don't think that just because Emacs contains an Elisp interpreter, we should call it a "non-native" application -- even if Elisp is integral to Emacs' operation. If forced, I would say that Emacs-the-platform is native, and Emacs the system of Editor MACroS is not, since the macros run on the Emacs platform. But it seems kind of pedantic.
      - lispm 10y ago
        The Lisp code is not natively executed. Some features like memory management (garbage collection) are layered on top of the OS. The UI is not 'native' - it's based on a portable substrate written in C/Lisp, which works both on WIMP and terminal systems. The user interaction is not native (commands, buffers, undo, preference dialogs, window/frames, ...). etc.etc.
        gmfawcett 10y ago
        I never said the Lisp code was natively executed. I'm not sure where you got that idea. Let's just agree to disagree. We are talking past each other at this point. Best regards!
        deleted 10y ago
        [deleted]
  - dahauns 10y ago
    Of course - I should have added that I don't neccessarily share the sentiment behind those jokes (quite the contrary). For me they are just inevitable (social) indicators for "non-native" software (i.e. I'd say anything with significant code running through an intermediate representation or virtualization at runtime). As such I simply found emacs an odd choice as an example. BTW: Notepad++ uses .dlls as plugins. (Which doesn't neccessarily make it a better editor than emacs :) )
- Philipp__ 10y ago
  Not true. Big chunk of Emacs is written in C.
- lispm 10y ago
  The jokes of GNU Emacs being bloated are from a time when machines with 8MB RAM were modern. The original NeXT computer was introduced in 1988 with 8MB RAM... The Mac II from 1987 started at 1MB, max at 8MB, ... today phones have 2GB RAM.
  - sqeaky 10y ago
    I bought a phone with 6GB of RAM. It keeps getting bigger.

Emacs is a little harder to write plugins for, but it runs natively and the only impediment is that more people know JS than they do elisp.

by ue_ 10y ago

Emacs is a little harder to write plugins for, but it runs natively and the only impediment is that more people know JS than they do elisp.

dahauns 10y ago

Lots of emacs functionality runs via its lisp VM. I'd hardly call that 'native'. I mean, Emacs had jokes about being bloated decades before Javascript (and Java, another contender for these jokes) even existed. :)

gmfawcett 10y ago
Most of those jokes are completely out of date. "Eight Megs and Constantly Swapping" used to be a big deal, but today it's not. I don't think running Elisp in Emacs takes away from it being "native." At least insofar as there are no popular text editors (that I know of!) which expect you to compile your plugins and macros to native code. They all have interpreters of one kind or another. What Emacs doesn't have, though, is an inner platform effect: Emacs is the platform, there isn't a second one underneath (no browser engine).
- pantulis 10y ago
  Which begs the nice corollary: the definition of "native" doesn't happen to be fixed and changes with time.
  - gmfawcett 10y ago
    Well, language is like that. :) But I don't think describing Emacs as "native" here is very different from how the word was used decades ago. To me, "native" is less about how the logic is represented (compiled vs. interpreted code) and more about its execution context. If the host system is an operating system, then the application is native; if the host system is another application, then it's not. I agree that the boundary is blurrier for applications that have scripting interfaces; but I think that most applications don't live very close to that boundary, and are clearly in one camp or the other. (Maybe Emacs is nearer to the edge: there's an old joke that Emacs is a great operating system, it just needs a better text editor.) Having said all that, I don't think that "non-native" is a pejorative. I use Emacs, but would switch to a "non-native" editor if there were a good reason. I use IDEA (native or not? you decide!) when working on big Java projects, and Emacs for everything else, because Emacs affords me a lot of power that I find lacking in other editors. "Nativity" isn't really part of the equation, it's really about functionality.
    - lispm 10y ago
      GNU Emacs comes with its own portable execution platform (the byte-code Lisp execution engine), where Java applications typically use a provided virtual machine. As such GNU Emacs is just as 'non-native' as a JVM-based editor.
      - gmfawcett 10y ago
        Almost agree with you! If the Emacs VM were used for applications other than Emacs -- if it were a general purpose VM -- then I'd completely agree.
        lispm 10y ago
        There are lots of applications written on top of GNU Emacs, but most of the time they use the specific UI and features of an editor, or integrate with the editor. Example: the calculator of GNU Emacs. https://www.gnu.org/software/emacs/manual/html_mono/calc.html https://www.gnu.org/software/emacs/manual/html_mono/calc.htm...
  - dahauns 10y ago
    Case in point: https://news.ycombinator.com/item?id=13944757 https://news.ycombinator.com/item?id=13944757 :)
- lispm 10y ago
  GNU Emacs Lisp code is certainly not native - not until a JIT will be widespread. GNU Emacs usually compiles Lisp code to a byte code which is interpreted by a byte code engine written in C. If you use a Common Lisp based editor like Clozure CL, Allegro CL and LispWorks have, they don't use a C-based byte code interpreted. The Lisp code is compiled directly to native code. Which makes editor extensions running in natively compiled Lisp code. The advantage of the c-based byte code engine is compact code and improved portability - since the C compiler will already be provided with most platforms, whereas a native Lisp compiler is typically not something provided by a platform (CPU/OS/...) vendor...
  - gmfawcett 10y ago
    I should be more clear. I don't think that just because Emacs contains an Elisp interpreter, we should call it a "non-native" application -- even if Elisp is integral to Emacs' operation. If forced, I would say that Emacs-the-platform is native, and Emacs the system of Editor MACroS is not, since the macros run on the Emacs platform. But it seems kind of pedantic.
    - lispm 10y ago
      The Lisp code is not natively executed. Some features like memory management (garbage collection) are layered on top of the OS. The UI is not 'native' - it's based on a portable substrate written in C/Lisp, which works both on WIMP and terminal systems. The user interaction is not native (commands, buffers, undo, preference dialogs, window/frames, ...). etc.etc.
      - gmfawcett 10y ago
        I never said the Lisp code was natively executed. I'm not sure where you got that idea. Let's just agree to disagree. We are talking past each other at this point. Best regards!
        deleted 10y ago
        [deleted]
- dahauns 10y ago
  Of course - I should have added that I don't neccessarily share the sentiment behind those jokes (quite the contrary). For me they are just inevitable (social) indicators for "non-native" software (i.e. I'd say anything with significant code running through an intermediate representation or virtualization at runtime). As such I simply found emacs an odd choice as an example. BTW: Notepad++ uses .dlls as plugins. (Which doesn't neccessarily make it a better editor than emacs :) )
Philipp__ 10y ago
Not true. Big chunk of Emacs is written in C.
lispm 10y ago
The jokes of GNU Emacs being bloated are from a time when machines with 8MB RAM were modern. The original NeXT computer was introduced in 1988 with 8MB RAM... The Mac II from 1987 started at 1MB, max at 8MB, ... today phones have 2GB RAM.
- sqeaky 10y ago
  I bought a phone with 6GB of RAM. It keeps getting bigger.