[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: For text processing, which is more powerful, emacs or perl?
From: |
Marcin Borkowski |
Subject: |
Re: For text processing, which is more powerful, emacs or perl? |
Date: |
Fri, 08 Oct 2021 18:52:54 +0200 |
User-agent: |
mu4e 1.1.0; emacs 28.0.50 |
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 (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