Comment by momentoftop | Hacker News Reader

Comment by momentoftop | Hacker News Reader

Parent Full thread

I don't like REPL driven development. REPLs are celebrated as some sort of achievement in interactivity, but they're hopelessly puny, barely imitating a UNIX shell.

When I write Emacs Lisp, I don't have a REPL. I just put point at the end of a random s-expression in a random Emacs-mode buffer, hit C-x C-e, and it gets evaluated. Or I do "eval-print-last-sexpression" to get the output on the next line. If I put my emacs in an org-mode code block, I'll get the output nicely formatted by org-mode. I can get close to this in Common Lisp with SLIME, but I've never found it as tight as Emacs Lisp.

But Emacs lisp is still puny. Common Lisps had much higher aspirations than SLIME and a crappy UNIX-based Lisp executable. Allegro and Lispwerks still run on the philosophy that your IDE is just some live code in your lisp image, and you extend that image via the GUI. The same philosophy pervades (non-GNU) Smalltalk implementations.

This is the sort of thing that still makes Lisp (and Smalltalk) absolutely stand out among programming languages, and it will be a crime when it is inevitably forgotten and we are left dumbfounded by the banality of REPL driven development.

> When I write Emacs Lisp, I don't have a REPL. I just put point at the end of a random s-expression in a random Emacs-mode buffer, hit C-x C-e, and it gets evaluated.

That actually is repl driven development. It does not mean that you type everything in on a repl prompt. It means you interactively and incrementally work on a program.

Yup I was going to comment basically the same: in this case Emacs itself is the REPL environment (Emacs user here).

Also, unless their configuration has changed things, C-x C-e will print out the results in the mini buffer at the bottom. So it retains each of the read, eval, and print parts of the read, eval, print loop. And since the program doesn't terminate (unless the expression you provided causes that), you're still in the loop part until you close emacs.

Allegro CL and LispWorks have very capable REPL experiences. They provide a mostly object-oriented implementation of Common Lisp with excellent support for the Condition system to interactively deal with errors, including hierarchical debug break loops and source level interpreters.

Emacs does have a REPL (`M-x ielm'), and it works well.

Didn't know about that, although I have been using Emacs for over ten years! Tried `M-x ielm`, `(help) RET`, wow! Will explore it. Been only using the scratch buffer and `C-x C-e` to evaluate sexpressions.

I wrote about all the way of doing this here:

https://www.masteringemacs.org/article/evaluating-elisp-emac...

Ah, it's you Mickey! Got your book. Excellent! Thank you for writing it, and thank you for all the valuable stuff you put out there re learning Emacs.

I wish GNU Emacs had better introspection, It's probably because it values user experience more but it saddens me when I see "You shouldn't use this from a lisp program, it's intended for users" or something like it. I understand the reasoning but having seen the power of introspection in Symbolics Genera makes me long for an Emacs that makes Elisp as much a feature as "Text-editing/browsing/etc".

I should look into contributing I guess

I wonder how difficult it would be to port elisp to Common Lisp and then get GNU Emacs running hosted in SBCL or whatever. I really like the idea of my editor running in the image.

It's been done in the form of an Emacs clone called Hemlock. Lispworks uses it for their IDE although they don't make enough of the source available to fully customize it. Clozure Common Lisp also uses Hemlock for their IDE on the Mac and its source is all in the box.

I don't think that's exactly what you asked, however, and I agree that a true Emacs running entirely on CL would be preferable.

Source code of LW editor is mostly available. I’ve done some extensive modifications to it (implemented VIM mode), but these days I’ve moved back to Emacs- just something I prefer more

So have I but that "mostly" is my problem. Eventually I hit a wall beyond which I could not modify the editor's behavior.

I believe the Nyxt project is interested in adding editing at some point. There’s also Lem which is a terminal based Emacs.

GNU Emacs has by far the strongest community and ecosystem though.

You might be interested in: https://github.com/cxxxr/lem

For a terminal editor, it’s impressively usable.

In principle not too hard, in practice the topic comes up every few months and nobody has done it yet

Depends on what you mean.

If you just mean writing an implementation of Emacs (or something Emacs-like) in Common Lisp, that's not very hard, and it's been done a few times. See, for example, Lem[1] and Hemlock[2].

Heck, I wrote one for MacOSX in about 2001 or 2002.

If you mean a drop-in replacement for GNU Emacs, that's a lot harder. Besides the UI and the editing infrastructure, you need to write a bug-compatible implementation of GNU's elisp, or you lose the whole GNU Emacs ecosystem. That ecosystem is most of its practical appeal. That's a whole bunch of work.

[1] https://github.com/40ants/lem-pareto/blob/master/lem-pareto-...

[2] https://en.wikipedia.org/wiki/Hemlock_(text_editor)

Reply on news.ycombinator.com