From: Eli Zaretskii <eliz@gnu.org>
To: Emanuel Berg <incal@dataswamp.org>
Cc: emacs-devel@gnu.org
Subject: Re: 10 problems with Elisp, part 10 (was: Re: Emacs website, Lisp, and other)
Date: Mon, 05 Aug 2024 19:38:36 +0300 [thread overview]
Message-ID: <86wmkuq60j.fsf@gnu.org> (raw)
In-Reply-To: <87frrjoryg.fsf_-_@dataswamp.org> (message from Emanuel Berg on Mon, 05 Aug 2024 18:27:35 +0200)
> From: Emanuel Berg <incal@dataswamp.org>
> Date: Mon, 05 Aug 2024 18:27:35 +0200
>
> Eli Zaretskii wrote:
>
> > Please, everybody, take the Lisp vs Python argument off this
> > list, it is off-topic here. If you must discuss this, please
> > use the emacs-tangents@gnu.org mailing list instead.
>
> Sure, but we are allowed to discuss how to make Elisp better?
Yopu could try, although it is usually not a useful discussion.
> Since Python has had enormous success, and Lisp hasn't - or if
> it had, it lost it - it might be a good ide to analyze what
> they (Python) did good.
>
> You might think this is some bängalow discussion just because
> certain people are in it. But it doesn't have to be like
> that, it can be very hands-on.
>
> Ten things that are annoying with Emacs Lisp from the holster,
> and what to do about them:
>
> 10. Moving point around all the time. Whatever program, what
> you do is, it feels like, not solving your problem
> algorithmicly, you are just doing endless
>
> (goto (point-min))
> (prong (end-of-paragraph) (current-column))
> (pos-eol -1)
>
> (setq exists-after-point (unless (re-search-forward re nil t) (point)))
>
> Frustration: What has this to do with my problem and
> proposed solution? I understand Emacs grew around its
> function as a text editor, but "everything is in the
> buffer" and "the buffer is the data structure of Emacs",
> that has goon too far and we see a lot of code being
> virtually a very, very long traversal of buffers moving
> around point. So what ought to have been a tolerable
> exception, has become the norm and hailed model to the
> point, as I said earlier, interfaces toward programming
> are so weak it is considered normal that ispell can't even
> to (spell "word") without first outputting it somewhere
> and to the operation on that surface.
There's nothing more natural than an editor analyzing text in a
buffer. Why it frustrates you is beyond me.
Emacs Lisp is not a general-purpose programming language. It is a
language for implementing Emacs and Emacs extensions. Thus, comparing
it with Python is, in general, simply wrong. We can compare a few
specific aspects, but not the languages as a whole, and definitely not
their success rate: the scope of Emacs Lisp is limited to Emacs, which
is orders of magnitude more narrow than the scope of Python (or any
other general-purpose programming language).
next prev parent reply other threads:[~2024-08-05 16:38 UTC|newest]
Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-04 22:27 Emacs website, Lisp, and other Jeremy Bryant
2024-08-04 22:55 ` Emanuel Berg
2024-08-05 4:29 ` Emanuel Berg
2024-08-05 9:23 ` Christopher Dimech
2024-08-05 10:43 ` Emanuel Berg
2024-08-05 11:37 ` divya
2024-08-05 11:56 ` Christopher Dimech
2024-08-05 12:33 ` Eli Zaretskii
2024-08-05 11:45 ` Christopher Dimech
2024-08-05 12:56 ` Dr. Arne Babenhauserheide
2024-08-05 13:16 ` Dr. Arne Babenhauserheide
2024-08-05 14:46 ` Christopher Dimech
2024-08-05 21:28 ` Dr. Arne Babenhauserheide
2024-08-05 14:55 ` Eli Zaretskii
2024-08-05 12:28 ` Eli Zaretskii
2024-08-05 16:27 ` 10 problems with Elisp, part 10 (was: Re: Emacs website, Lisp, and other) Emanuel Berg
2024-08-05 16:38 ` Eli Zaretskii [this message]
2024-08-05 17:03 ` Emanuel Berg
2024-08-05 18:32 ` 10 problems with Elisp, part 10 Dr. Arne Babenhauserheide
2024-08-05 20:20 ` Emanuel Berg
2024-08-06 7:14 ` Dr. Arne Babenhauserheide
2024-08-06 7:21 ` Org mode API (was: 10 problems with Elisp, part 10) Ihor Radchenko
2024-08-06 8:23 ` Org mode API Dr. Arne Babenhauserheide
2024-08-10 16:55 ` Ihor Radchenko
2024-08-06 11:54 ` 10 problems with Elisp, part 10 Eli Zaretskii
2024-08-08 2:01 ` Richard Stallman
2024-08-09 22:39 ` Emanuel Berg
2024-08-13 1:28 ` Richard Stallman
2024-08-09 22:46 ` Emanuel Berg
2024-08-10 5:41 ` Emanuel Berg
2024-08-10 6:09 ` Eli Zaretskii
2024-08-13 1:28 ` Richard Stallman
2024-08-05 18:58 ` 10 problems with Elisp, part 10 (was: Re: Emacs website, Lisp, and other) Christopher Dimech
2024-08-05 19:30 ` 10 problems with Elisp, part 10 Dr. Arne Babenhauserheide
2024-08-05 20:02 ` Christopher Dimech
2024-08-08 2:01 ` Richard Stallman
2024-08-06 2:28 ` Eli Zaretskii
2024-08-05 17:13 ` 10 problems with Elisp, part 10 (was: Re: Emacs website, Lisp, and other) Yuri Khan
2024-08-06 6:39 ` Emanuel Berg
2024-08-06 11:16 ` Richard Stallman
2024-08-06 22:08 ` Emanuel Berg
2024-08-05 11:56 ` Emacs website, Lisp, and other Eli Zaretskii
2024-08-06 19:09 ` Jeremy Bryant
2024-08-06 19:50 ` Christopher Dimech
2024-08-06 20:35 ` [External] : " Drew Adams
2024-08-06 22:10 ` Dr. Arne Babenhauserheide
2024-08-06 22:48 ` Christopher Dimech
2024-08-06 23:09 ` Drew Adams
2024-08-06 23:21 ` Christopher Dimech
2024-08-07 1:09 ` Dr. Arne Babenhauserheide
2024-08-06 22:26 ` Christopher Dimech
2024-08-07 5:45 ` Emanuel Berg
2024-08-15 3:53 ` Madhu
2024-08-15 5:50 ` Emanuel Berg
2024-08-15 9:17 ` Madhu
2024-08-15 9:57 ` Emanuel Berg
2024-08-15 6:17 ` Emanuel Berg
2024-08-15 7:10 ` Eli Zaretskii
2024-08-15 8:06 ` Emanuel Berg
2024-08-15 9:27 ` Emanuel Berg
2024-08-15 16:03 ` Emanuel Berg
2024-08-07 11:13 ` Eli Zaretskii
2024-08-07 12:03 ` Andrea Corallo
2024-08-07 12:16 ` Christopher Dimech
2024-08-08 2:01 ` Richard Stallman
2024-08-08 6:51 ` Joel Reicher
2024-08-07 12:31 ` Christopher Dimech
[not found] <mailman.47.1722960050.16997.emacs-devel@gnu.org>
2024-08-06 16:59 ` 10 problems with Elisp, part 10 (was: Re: Emacs website, Lisp, and other) Abraham S.A.H. via Emacs development discussions.
2024-08-07 7:34 ` Emanuel Berg
2024-08-07 11:26 ` Christopher Dimech
-- strict thread matches above, loose matches on Subject: below --
2024-08-06 17:05 Abraham S.A.H. via Emacs development discussions.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86wmkuq60j.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=incal@dataswamp.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).