emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 10 problems with Elisp, part 10 (was: Re: Emacs website, Lisp, and o


From: Eli Zaretskii
Subject: Re: 10 problems with Elisp, part 10 (was: Re: Emacs website, Lisp, and other)
Date: Mon, 05 Aug 2024 19:38:36 +0300

> 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).



reply via email to

[Prev in Thread] Current Thread [Next in Thread]