Dear Cooking Show, I really liked your recipe for the shrimp-avocado salad, and I tried to make it, but since I was out of avocados I just substituted them with potatoes. Also, it turns out I didn't have any shrimp, so I just used some hot dogs I found in my freezer. OMG, this recipe is amazing. You just made my day.
---
That's what using X instead of Lisp to make "a better Emacs" sounds like, okay? Emacs is a Lisp-machine, it's built on top of Lisp, it needs Lisp to be Emacs. Otherwise it wouldn't be Emacs. Like at all. Don't be stupid, stop saying stupid shit like "python instead of lisp"...
GNU Emacs is a Lisp implementation with an abstraction layer over the hardware and OS. I would like to reserve "Lisp Machine" to computers with an actual Lisp operating system or emulations of those.
Of course. I understand that calling Emacs "a Lisp Machine" is quite a stretch, but due to the lack of any actual prominent hardware-based Lisp machines these days, I think it is a permissible simplification for the orange-site discussions. Yet it is, indeed, an important clarification, I appreciate it.
These are interesting from historical educational point of interest, but they rather don't have practical use for modern software development, do they?
> I do understand that for you Emacs is a Lisp development environment first
It's not "for me", it is what it is. Emacs first and foremost is a Lisp machine, with a text-editor built into it, not the other way around, it's not a text-editor that uses Lisp as its configuration language.
"user experience of Emacs" is to be able to send any expression and sub-expression without any preceding ceremony directly to the REPL. Everything what Emacs does stems from that. No, Python doesn't have the same REPL. Every single stage of it in Python is different. Lisp's Read, Eval, Print, Loop - they all have slightest differences. Those differences are possible because of Lisp's homoiconic nature. Because of that you get Lisp macros, because of that you get advising functions, because of that you can do source blocks in Org-mode that can interact with and modify their own execution environment. Lisp's homoiconicity allows code to be treated as data and vice versa, enabling powerful metaprogramming capabilities. This means you can:
1. Manipulate code at runtime
2. Create domain-specific languages easily
3. Extend the language itself
In Org-mode, this translates to source blocks that can:
1. Dynamically generate and execute code
2. Modify their own content or other blocks' content
3. Interact with the Emacs environment seamlessly
This level of flexibility and power isn't achievable in Python's REPL due to its more rigid separation between code and data. While Python is highly versatile, it lacks the deep introspection and self-modifying capabilities that Lisp's homoiconic nature provides, making Lisp uniquely suited for certain advanced metaprogramming tasks and interactive development paradigms.
So the bottom line is: you can imagine really hard, but it would remain just an imagination, if you want to build something like Emacs - a REPL that has a built-in text editor, you need a Lisp, because non-homoiconic languages DO NOT HAVE exactly same REPLs. Now, do you want me to get seriously pedantic and explain how every step in ReadEvalPrintLoop differs in Lisp and Python?
> if you want to build something like Emacs - a REPL that has a built-in text editor, you need a Lisp, because non-homoiconic languages DO NOT HAVE exactly same REPLs.
I don't think it makes sense. One can build programmable editors in many interactive languages. The language for an editor doesn't need to be Lisp. It could be Python, JavaScript, Ruby, PERL, Forth, ... Typically a form of EVAL or compile/load is enough to do so.
> One can build programmable editors in many interactive languages
Of course, one can - VSCode is a "programmable editor", no? Emacs is a bit different though, wouldn't you agree? It's rather a Lisp REPL that has a text-editor built on top of it.
Dired is a file browser, sure, it can be written in anything. But what about something like Org-mode - with all its source-block magic, code execution, etc. etc.?
You're just so full of yourself, aren't you? You know the one true way to do programming, it's lisp and everyone else is an idiot? This was old before you were even born.
Now, you're just being rude, I never said things you're implying I did, and I never claimed anything of being "one true way to do anything", I only tried to point out in a humorous way of your uninformed opinion, but I guess you lack basic sense of self-irony. Okay, if you rather remain sanctimonious, stiff-necked "professional", fine. I'm sorry if I hurt your tender feelings and I apologize if I angered you - I promise, my intentions were quite the opposite. Also, you have no idea when I was born, let's not get too personal, okay?
Maybe it's just personal preference, since I think it's easier for me to think in python over lisp (which I've known for longer, but I still fumble through)
I do think python would make emacs more accessible to a wider audience.
> I do think python would make emacs more accessible
It would not be Emacs anymore. Emacs is specifically tied to Lisp. Emacs is not a text editor that uses Lisp as the configuration language. Emacs is a Lisp machine that has a text editor built into it.
An "Emacs-like" editor built on Python might be interesting, but it wouldn't be a "better Emacs" or even "like Emacs", it would be a completely different thing.
You may dislike Lisp, you may even hate Lisp, but the fact remains unchanged - there is an emerging class of applications that is significantly more difficult to build around non-homoiconic languages. Emacs is one of them. Stop fetishizing your favorite programming language as the quintessence of Emacs. The best one can do is to build a compiler/transpiler to spit out Lisp code, and people have tried that. Yet somehow, in over forty years nobody has succeeded in dethroning Elisp from ruling Emacs.
GNU Emacs is tied to Elisp. But Emacs is a much wider family of editors written in a multitude of languages.
> Yet somehow, in over forty years nobody has succeeded in dethroning Elisp from ruling Emacs
That might have several reason. Maybe few people are interested to reimplement GNU Emacs in a different language. Like nobody has succeeded in dethroning C from the Linux kernel, using Lisp.
> Emacs is a much wider family of editors written in a multitude of languages.
Sure, there's Guile Emacs, there's MicroEmacs - both not Elisp-based, still built on top of Lisp dialects; there's XEmacs, Remacs - both still use Elisp, there's also mg which afaik completely not lisp-based, but I don't know how much of it still 'emacs-like'. In general though, GNU Emacs is what people usually mean when they speak about Emacs, unless they're explicitly talking about others.
If you say only Lisp can be used to implement Emacs, would you mean a specific Emacs or an editor belonging to the larger family of Emacs-like editors? When I would speak about how to implement "an Emacs", I would include the option to use different programming languages. For example I could imagine that C and Python is a valid combination, even Python alone would be an option. Python can be used interactively, which would be sufficient for an interactive extension language.
You can see that there is a multitude of editors in the Emacs category. The list also mentions the implementation and the extension language.
> GNU Emacs is what people usually mean when they speak about Emacs
That's a bit sad. It's like saying "Linux" and think that its the same as "Debian Linux". Similar there are a lot of different Emacs-like editors. Claiming that there is only a single way to implement Emacs goes against the evidence that there are a lot of Emacs-like editors, which are not implemented in C + Emacs Lisp, including the original first Emacs.
I would think that by far the most important Emacs is GNU Emacs, but I don't think its implementation language choice (C + Lisp) is necessary to implement an extensible Emacs-like editor. Also be aware even though GNU Emacs is a popular Emacs editor, there are some people who are using different Emacs-like editors instead. I typically use a Hemlock variant written in Common Lisp and Zmacs, written in ZetaLisp. Both core designs date back many decades, actually even before GNU Emacs existed.
> I typically use a Hemlock variant written in Common Lisp and Zmacs, written in ZetaLisp.
So, I still can't see how that doesn't prove my point even further. These Emacs variants are based on Lisps, like you just said. I don't see anything "Emacs-like" today that's hugely based on a non-homoiconic language. Please, if you know any editor that allows me to modify the behavior of any given function/procedure/command with the same level of granularity as the advising mechanism of GNU Emacs, I would love to know about it.
Look at the list of Emacs-type editors. Plenty of them were not written in Lisp.
> Please, if you know any editor that allows me to modify the behavior of any given function/procedure/command with the same level of granularity as the advising mechanism of GNU Emacs, I would love to know about it.
Zmacs did that before GNU Emacs existed. It also allowed ALL parts of the editor to be changed, not just the ones written in Emacs Lisp for GNU Emacs. Remember, the core of GNU Emacs - both the core Lisp implementation and some core editor and UI functionality - is written in C.
Btw., on a real Lisp Machine the editor (Zmacs) was not the main user interface. For example on a Symbolics (but also in Interlisp-D), the listener and a file browsers were their own applications. Zmacs in Genera has a Dired mode, but no listener. Also Genera can run multiple Zmacs windows in the same Lisp, running concurrently -> the Lisp supports multiple threads and the applications use that feature.. Something which GNU Emacs can't easily do. It's mostly blocking and single threaded. Something which can't be easily fixed in Emacs Lisp.
Run Lisp code in GNU Emacs in the REPL (m-x ielm) and it blocks the UI. That can't trivially fixed and is a major implementation fail of GNU Emacs.
Other Emacs-like editors can run multiple things, without blocking the user interface.
