3 ms·

Please don't misunderstand my use of the word "museum". I'm not saying Emacs is useless or that we should never improve or use it. But Emacs is more or less the

Please don't misunderstand my use of the word "museum". I'm not saying Emacs is useless or that we should never improve or use it. But Emacs is more or less the only surviving relic of a very different paradigm of doing computing and software, one which many of us still cherish. >What's wrong with spreading all this to other spaces, and letting other people learn about them, making them more accessible? Because the philosophy of Emacs and the computing tradition it grew out of is fundamentally at odds with those other spaces. Everything being in one dynamic language is a huge and intrinsic part of that tradition. I suppose you could write an Emacs entirely in javascript if you wanted to, if you followed the same software philosophy. But personally I think Javascript is such an inelegant language that a lot of the power of the idea would be lost even in that case.

PurpleRamen 3y ago
> But Emacs is more or less the only surviving relic of a very different paradigm of doing computing and software, one which many of us still cherish. I don't think that's true at all. Emacs is a lisp-machine, but that's just the means, an implementation-detail, not the culture and the aim. Every shell, web browsers, any REPL is pretty much the same as Emacs, just in a different flavor. The culture I'm talking about is to have a customizable tool & workspace. Something that adapts to you, a canvas where only your time and imagination is the limit. Limiting Emacs to being "just" lisp, is doing it a disservice.
- taeric 3y ago
  Thinking that any REPL is the same as Emacs feels... wrong. Same for shells and other items there. I can almost see the argument for browser, but we left user customization as the default in browsers a long long time ago. To make my point a bit more concrete, the culture of lisp-machines was that the user was in full control. Curious what will happen if you type something? You can literally lookup what will happen on any keystroke or button press. Curious what code runs for a function? Odds are high that you can jump into the code for any feature and edit it on the fly. Yes, there are some native code sections that you can't do this for, but the vast majority is not that.
- mtlmtlmtlmtl 3y ago
  No, you're not getting he gist here. Browsers are nothing like Emacs in design philosophy(except Nyxt, which gets close, but falls a bit short due to intrinsically having to deal with a bunch of JS; an excellent example of my point, come to think of it). Take Firefox for example. It has extensions, but they're intrinsically limited by the fact that they're sandboxed and can only interact with the browser through a limited API. And yes, you could certainly extend it arbitrarily by changing the C++/Rust/whatever code and recompiling it. But it's not designed to be extended that way by users. In emacs, the configuration is really just patches applied to the code at runtime. There fundamentally is nothing you can't do through the configuration. But why Lisp you say? Precisely because Lisp is a dynamic meta-programming language, which is the ideal paradigm for this. It can be molded to be a highly abstracted configuration language without losing the ability to run arbitrary code. You get all the upside of JSON, YAML, XML and other configuration languages with none of the downside of being limited in what you can do. Adding javascript to the mix just complicates this simple and elegant model. You gain nothing in extensibility, and will probably lose quite a lot unless you take extreme effort to avoid it through clever design.
  - PurpleRamen 3y ago
    > Take Firefox for example. It has extensions, but they're intrinsically limited by the fact that they're sandboxed and can only interact with the browser through a limited API. That's design, a choice. It used to be different in old Firefox, and other browsers are different in that aspect even today. But to be fair, I mainly meant the page-context, not the application-context. Most normal web browser support userscript, bookmarklets and debugging some way or another. Or should I say, still. Because this is a bit in decline. And if you take something like web- or electron-apps, the page-context becomes the app itself. All just a matter of implementation and architecture. > There fundamentally is nothing you can't do through the configuration. You can't patch the C-core, can you? Another necessary implementation-detail. > Precisely because Lisp is a dynamic meta-programming language, which is the ideal paradigm for this. It was ideal when Emacs was created. Today, we have many alternatives. > You gain nothing in extensibility, Except more ability, more heritage, more users... At the end, it's all a matter of managing the tradeoffs, the implementation-details.

PurpleRamen 3y ago

> But Emacs is more or less the only surviving relic of a very different paradigm of doing computing and software, one which many of us still cherish. I don't think that's true at all. Emacs is a lisp-machine, but that's just the means, an implementation-detail, not the culture and the aim. Every shell, web browsers, any REPL is pretty much the same as Emacs, just in a different flavor. The culture I'm talking about is to have a customizable tool & workspace. Something that adapts to you, a canvas where only your time and imagination is the limit. Limiting Emacs to being "just" lisp, is doing it a disservice.

taeric 3y ago
Thinking that any REPL is the same as Emacs feels... wrong. Same for shells and other items there. I can almost see the argument for browser, but we left user customization as the default in browsers a long long time ago. To make my point a bit more concrete, the culture of lisp-machines was that the user was in full control. Curious what will happen if you type something? You can literally lookup what will happen on any keystroke or button press. Curious what code runs for a function? Odds are high that you can jump into the code for any feature and edit it on the fly. Yes, there are some native code sections that you can't do this for, but the vast majority is not that.
mtlmtlmtlmtl 3y ago
No, you're not getting he gist here. Browsers are nothing like Emacs in design philosophy(except Nyxt, which gets close, but falls a bit short due to intrinsically having to deal with a bunch of JS; an excellent example of my point, come to think of it). Take Firefox for example. It has extensions, but they're intrinsically limited by the fact that they're sandboxed and can only interact with the browser through a limited API. And yes, you could certainly extend it arbitrarily by changing the C++/Rust/whatever code and recompiling it. But it's not designed to be extended that way by users. In emacs, the configuration is really just patches applied to the code at runtime. There fundamentally is nothing you can't do through the configuration. But why Lisp you say? Precisely because Lisp is a dynamic meta-programming language, which is the ideal paradigm for this. It can be molded to be a highly abstracted configuration language without losing the ability to run arbitrary code. You get all the upside of JSON, YAML, XML and other configuration languages with none of the downside of being limited in what you can do. Adding javascript to the mix just complicates this simple and elegant model. You gain nothing in extensibility, and will probably lose quite a lot unless you take extreme effort to avoid it through clever design.
- PurpleRamen 3y ago
  > Take Firefox for example. It has extensions, but they're intrinsically limited by the fact that they're sandboxed and can only interact with the browser through a limited API. That's design, a choice. It used to be different in old Firefox, and other browsers are different in that aspect even today. But to be fair, I mainly meant the page-context, not the application-context. Most normal web browser support userscript, bookmarklets and debugging some way or another. Or should I say, still. Because this is a bit in decline. And if you take something like web- or electron-apps, the page-context becomes the app itself. All just a matter of implementation and architecture. > There fundamentally is nothing you can't do through the configuration. You can't patch the C-core, can you? Another necessary implementation-detail. > Precisely because Lisp is a dynamic meta-programming language, which is the ideal paradigm for this. It was ideal when Emacs was created. Today, we have many alternatives. > You gain nothing in extensibility, Except more ability, more heritage, more users... At the end, it's all a matter of managing the tradeoffs, the implementation-details.