Re: For text processing, which is more powerful, emacs or perl?

[Hongyi Zhao]

On Sat, Oct 9, 2021 at 12:53 AM Marcin Borkowski <mbork@mbork.pl> wrote:
>
>
> On 2020-12-19, at 08:43, Hongyi Zhao <hongyi.zhao@gmail.com> wrote:
>
> > It's well known that perl's regexp is very powerful for its capability
> > of text processing. So, which is more powerful, emacs or perl, in this
> > scenario?
>
> While others offered free jokes and musings about performance (which is
> usually irrelevant unless you process multi-gigabyte files, craft
> malicious regexen or do something extremely complicated), let me mention
> something that wasn't mentioned in this thread (or so I think).
>
> Perl (or Python, or whatever "mainstream" language you take) usually
> processes texts in a traditional way, using strings and regexen.  Emacs,
> OTOH, is a text editor, with all its concepts, so you may process texts
> using buffers, which differ from strings in one important respect: the
> notion of /point/.  (There are other differences, too, e.g., buffers are
> usually more performant.)  This means that you can write code that
> processes text like a human editor would do, in terms of "moving the
> point a word forward, transposing two sentences, deleting from point to
> the end of line" etc.
>
> It's much like the difference between classical graphical operations
> (draw a point, a line segment between two points, a circle with given
> center and radius etc.) and turtle graphics known from LOGO.
>
> I'm not saying that the Emacs way is definitely better - that probably
> depends on the context and the nature of your text processing - but you
> might find it quite intuitive and easier, both in implementing and in
> studying existing code

But lisp - any lisp dialects - is much more obscure than python to
some extent. Of course, perl regexp and syntax is also known for being
difficult to understand.

> (when you e.g. need to improve something you
> wrote 6 months earlier and you remember nothing about the
> implementation).  What is the point of having unreadable code running in
> 2 milliseconds instead of clear and easy to understand code running in
> even 200 milliseconds when you don't want to run it a million times, but
> you need to modify it from time to time?
>
> Hth,
>
> --
> Marcin Borkowski
> http://mbork.pl