Live data from Hacker News

Emacs Users Are Like Terry Pratchett’s Igors (2013)

chrisdone.com

21–30 of 58 posts

Re: Emacs Users Are Like Terry Pratchett’s Igors (2013)

#21
To digress a bit, on the Lisp curse, and freedom more generally:

In the HyperCard thread on the front page right now (https://news.ycombinator.com/item?id=20550189), someone linked a talk (https://www.youtube.com/watch?v=9nd9DwCdQR0&feature=youtu.be...) on the history of educational software, and one of the presenters said something like, "Some technologies we are simply not mature enough for."

I think this is not a bad description of "the Lisp Curse." I definitely wasn't mature enough for Lisp when I first learned it---high on my knowledge of what was possible, surrounded by myopic fools, as I thought.

But that was years ago. I'm mature enough now. It is possible.

In my consulting work my partner and I have marveled at how managing technology projects is a skill --- learnable, but only with some effort and practice, and carrying relatively heavy requirements of being technically competent and having a context of the business.

That's the skill that's needed, IMO, to make Lisp "work." Lisp itself---and Clojure---are really not complicated languages. My boss teaches them to undergrads and they can be productive fairly quickly. They are complicated when someone has built a crappy, leaky tower of abstractions on them. Recognizing when you're in danger of doing so, and when it's not worth it given other factors (business value, maintainability, etc) is the key.

So I wonder, idly, if metaprogramming---no, really, the meta of programming, like "Don't Call Yourself A Programmer" (https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pr... ) and "Developer Hegemony" (https://www.amazon.com/Developer-Hegemony-Erik-Dietrich/dp/0... )---might develop some more, esp. among the Lisp communities. When the language is no longer the barrier, you start to realize that other things are.

Re: Emacs Users Are Like Terry Pratchett’s Igors (2013)

#22
post #17

Can anyone recommend an editor like Emacs that doesn’t use LISP? I find the syntax to be an abomination.

It is arguable that no such editor exists. Take away the Lisp and you are already very unlike Emacs.

It's possible to write a language that is arguably a lisp, but without sexprs.

Elixir is one that comes to mind (It has the "big" Lisp things, like hygienic macros).

Actually, Erlangs concurrency model might well work very well for emacs, since you can spawn off hundreds of independent tasks with close to zero overhead, and use all available cores to run them on.

Re: Emacs Users Are Like Terry Pratchett’s Igors (2013)

#24
post #18
post #10

People who don't know how to program emacs don't get how easy it is to write some code in it to make your life easier. Some say Atom and VSCode also have plugins. That's true, but can you write code to extend some VSCode functionality in a minute? You just go to the scratch buffer, write some code, evalute it and it instantly becomes part of the editor. I don't know if there are other editors which can replicate this…

Can you recommend a good starting-point for learning emacs internals?

Not OP, but the Emacs manual is excellent[0] and there's Mastering Emacs[1] and Sacha Chua's blog[2].

Because it's lisp you can inspect just about everything. See an unfamiliar symbol? Put your cursor on it and press M-.

0: launch help from within Emacs

1: https://www.masteringemacs.org/

2: https://sachachua.com/blog/emacs/

Re: Emacs Users Are Like Terry Pratchett’s Igors (2013)

#25
post #11

The big issue with elisp is how alien it is to read code in it with so many parens and the tendency by elisp programmers to inline huge gobs of code in function calls.

> the tendency by elisp programmers to inline huge gobs of code in function calls

Observation on point, and ironically it limits the ability for developers to tweak third-party software (what if you want to change some aspect _in the middle_ of the large code gob?)

Re: Emacs Users Are Like Terry Pratchett’s Igors (2013)

#26
post #16
post #12

Emacs is 43 years old. When it was written, the kernel had to be written in C. Elisp is slow. It’s probably possible today to write an Emacs in a high-performance Lisp. Elisp has no support for concurrency, for example. “Some 359,000 lines of C code comprise its kernel, and 1,637,000 lines of Emacs Lisp take the rest of it.1”

Whenever I open a file of code that is ~2000 lines or more, emacs slows to a crawl. It takes 5 seconds to redraw the visible text after hitting "page up" or "page down". I don't think emacs should be made any slower than it already is.

> Whenever I open a file of code that is ~2000 lines or more, emacs slows to a crawl.

Then there is something wrong with your environment. Emacs has no problems with big files. It can have problems with very long lines, but big files shouldn't slow it down.

Re: Emacs Users Are Like Terry Pratchett’s Igors (2013)

#29
post #26
post #16

Earlier quoted context omitted.

Whenever I open a file of code that is ~2000 lines or more, emacs slows to a crawl. It takes 5 seconds to redraw the visible text after hitting "page up" or "page down". I don't think emacs should be made any slower than it already is.

> Whenever I open a file of code that is ~2000 lines or more, emacs slows to a crawl. Then there is something wrong with your environment. Emacs has no problems with big files. It can have problems with very long lines, but big files shouldn't slow it down.

I can reproduce this with emacs obtained from the repo on a newly installed Ubuntu 18.04 virtual machine.

Re: Emacs Users Are Like Terry Pratchett’s Igors (2013)

#30

I lack even a reference for the sorts of things that can be done. How have Emacs users here customized their workflow?

A huge amount is taking preweitten plugins—someone upthread said you should just learn your editor’s existing feature set, and this is true.

But I use Emacs as a mail client—message mode is awesome—and extended it with a procedure to create text/html parts and all the necessary MIME headers. I especially like using that for tables that are readable in monospaces text/plain or as HTML tables. Compare that to a GUI mail editor, which surely defaults to HTML but which probably isn’t going to offer you tabular support.

Let’s see. I have some fine control over white space in here, to meet different collaborator’s guidelines. And that integrates with the magit git front end.

I have a bunch of macros driven by the abbrev autocorrect scheme.

But in reflecting on this, the big important category is “Other”. I write 5-50 line programs, sometimes starting from a macro recording of one run of the core loop, weekly.

Imagine a world where general spreadsheets didn’t exist; you had accounting software but it was all like TurboTax or quickbooks, very hard wired for a purpose. And imagine asking how users of Excel customized their workflows, as they tried to explain that the point was the total flexibility. Emacs is like that for text files.

Post reply on HN