Live data from Hacker News

Emacs Is a Lispboard

en.andros.dev

21–30 of 62 posts

Re: Emacs Is a Lispboard

#21
post #3

Something like Lem[1][2] could go even further because of the richer CommonLisp ecosystem compared to Elisp one. [1] https://lem-project.github.io/ [2] https://github.com/lem-project/lem

What do you mean by "richer ecosystem"? Have you ever seen GitHub language stats - there's so much Elisp on GitHub alone, it's absolute bananas. The amount of Elisp in the wild probably surpasses the amount of Clojure, CL and Racket combined. And mind that it isn't "a general use" PL - it exists for one and single purpose.

Lem is great and I'm happy there's finally something out there to challenge Emacs' hegemony, yet pragmatically, unless someone builds a way to run Elisp in Lem, it's unlikely to overthrow Emacs anytime soon, and that's just not gonna happen.

Org-mode, Magit, and thousands of packages aren't just "Elisp code" - they depend on Emacs' specific buffer model, text properties, overlays, markers, the display engine, process handling, and countless quirks packages rely on (intentionally or not). A Lem Elisp interpreter that didn't also reimplement all of that faithfully would run trivial `.el` files and choke on anything real. At that point you've reimplemented Emacs inside Lem.

Elisp is not the biggest point here and Neovim proves that with pivoting to Lua; the crux is the runtime and the corpus, and reimplementing those is the actual mountain. That is real ecosystem for whatever reason you're choosing to simply ignore.

Re: Emacs Is a Lispboard

#22

Earlier quoted context omitted.

I chose the JS ecosystem. Why does the power of Emacs not belong in the browser? These days JS is a powerful enough FP language to do it.

Nearly 40 years of stuff. People iterating on a problem space over time is the best way we have found to improve things. The JS ecosystem is not that old and also attempts to solve hundreds of unrelated problems like running software without peoples consent.

As much as I don't like all the choices they've made, the choices have been the result of iterating on the problem space over time.

And... yeah the consent thing is messy. There's a kind of implicit consent in knowing that a user that does not consent can block scripts. But then it can quickly become coerced consent if there's some IRL reason you need to use the page and it absolutely does not work without JS.

That said, I'm a JS-webapp UI guy. Partly that's just what I've built my career on, largely because it was the new field emerging as I was coming up. I could learn things quickly and convert what I learned into a salary. But the second reason is that I'm disillusioned with HTML as the wire format for the web. If you choose to render HTML on your server, you're centralizing costs in a way that will eventually force you towards an extractive relationship with your users. Not only are you centralizing the cost of rendering and transmitting the HTML, but you're also centralizing the cost of building and maintaining the UI layer.

This is (partly) because HTML failed at being a semantic language. There was a brief flicker of hope with XML and XSLT -- for a hot second you could write a compact semantic document and send it over the wire. No longer...

Re: Emacs Is a Lispboard

#23
post #3

Something like Lem[1][2] could go even further because of the richer CommonLisp ecosystem compared to Elisp one. [1] https://lem-project.github.io/ [2] https://github.com/lem-project/lem

I chose the JS ecosystem. Why does the power of Emacs not belong in the browser? These days JS is a powerful enough FP language to do it.

Because you need Lisp. That's the actual "power of Emacs". Emacs is a Lisp-interpreter with a built-in text editor. Everything stems from that. Anyone challenging "the choice" of Lisp as the configuration language for an editor, saying things like: "Why? If X is better - faster, more modern, more popular...", etc., have misunderstanding of what makes Lisp so uniquely powerful.

A specific language is not the point - to implement anything similar to Emacs, you'd need a homoiconic language or at least a language that gives you live, reflective, late-bound image with code-as-data. Without that single aspect tons of things simply and inevitably (as history shows) will get complicated.

Why we have not seen such differentiator with VSCode? Because of their design choices - the extension language and the editor internals live in different worlds behind an API boundary. Emacs essentially has no such boundary. That's the power, and also a consequence of the image + homoiconicity combo.

Re: Emacs Is a Lispboard

#24

> Suppose I want to work in a single place for all my contexts, both personal and professional. This has always been my problem with adopting Emacs or Obsidian or any other app that purports to do this. Who are y'all working for that you can bring professional stuff onto the same system as personal stuff? I don't want my personal emails on my work computer, and my boss would be rather upset if I brought work emails o…

I think his secondary point is to show the potential. His primary point is likely that if you set this all up for home use, you can use mostly the same config to use it at work. This way, when you go home or go to work, you're dealing with the same environment and workflows.

Re: Emacs Is a Lispboard

#25

Earlier quoted context omitted.

I chose the JS ecosystem. Why does the power of Emacs not belong in the browser? These days JS is a powerful enough FP language to do it.

Because you need Lisp. That's the actual "power of Emacs". Emacs is a Lisp-interpreter with a built-in text editor. Everything stems from that. Anyone challenging "the choice" of Lisp as the configuration language for an editor, saying things like: "Why? If X is better - faster, more modern, more popular...", etc., have misunderstanding of what makes Lisp so uniquely powerful. A specific language is not the point - t…

> to implement anything similar to Emacs, you'd need a homoiconic language

I've got that. It took 6 years but I developed a comprehensive homoiconic layer for Javascript

Re: Emacs Is a Lispboard

#27
post #3

Something like Lem[1][2] could go even further because of the richer CommonLisp ecosystem compared to Elisp one. [1] https://lem-project.github.io/ [2] https://github.com/lem-project/lem

I chose the JS ecosystem. Why does the power of Emacs not belong in the browser? These days JS is a powerful enough FP language to do it.

Because to replicate the power of Emacs, you'd need to throw away a lot of privacy/security in the browser. You'd need to let one tab read the contents of another by default. A change to make your mail reading better may break your banking app (yes, that's a reality with Emacs).

Also, Emacs windows vs tabs. Think of having each tab be a non-overlapping window within the browser window.

Finally, most browsers don't let JS code modify the browser itself. If I suddenly decide I'd like Firefox's menu completely rearranged, I don't think JS will give it to me.

Re: Emacs Is a Lispboard

#28

> Suppose I want to work in a single place for all my contexts, both personal and professional. This has always been my problem with adopting Emacs or Obsidian or any other app that purports to do this. Who are y'all working for that you can bring professional stuff onto the same system as personal stuff? I don't want my personal emails on my work computer, and my boss would be rather upset if I brought work emails o…

Many people that do this are almost certainly freelance contractors in some facility?

Probably, though, many are just using personal as not strictly personal, but the kind of personal things you might do while at a desk job.

Re: Emacs Is a Lispboard

#29
post #6

Earlier quoted context omitted.

And building a consistent good experience from isolated tools is even harder. The problem is just hard and I think good criteria with the super app approach is the way to go. I really like Spacemacs. It's discoverable, extendable, quite consistent.

> And building a consistent good experience from isolated tools is even harder. Yes, I agree, which is why my tmux slowly devours my numerous small utility apps into itself! I haven't tried Spacemacs yet, too Vim-pilled at the moment..

> I haven't tried Spacemacs yet, too Vim-pilled at the moment..

You do know that Spacemacs defaults to Vim bindings, right?

Re: Emacs Is a Lispboard

#30
post #27

Earlier quoted context omitted.

I chose the JS ecosystem. Why does the power of Emacs not belong in the browser? These days JS is a powerful enough FP language to do it.

Because to replicate the power of Emacs, you'd need to throw away a lot of privacy/security in the browser. You'd need to let one tab read the contents of another by default . A change to make your mail reading better may break your banking app (yes, that's a reality with Emacs). Also, Emacs windows vs tabs. Think of having each tab be a non-overlapping window within the browser window. Finally, most browsers don't l…

If I have two editor tabs open as two browser tabs they should already be able to talk if they're from the same origin, which different editor tabs would be.

The JS code won't be able to modify the browser itself, but neither can ELisp modify the actual Emacs binary code. The customizability in both cases is really coming from an "OS" being implemented in user-controlled scriptspace. You'd have just as much ability to customize that HTML-and-JS OS if it was running in the browser as you have to customize Emacs I think...

Post reply on HN