help-gnu-emacs
[Top][All Lists]
Advanced

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

Re: Too fine design granularity leads to numerous macro/function/command


From: Arthur Miller
Subject: Re: Too fine design granularity leads to numerous macro/function/command existed in Emacs.
Date: Fri, 13 Aug 2021 11:26:39 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Hongyi Zhao <hongyi.zhao@gmail.com> writes:

>  It's well known that Emacs has already implemented numerous
> macro/function/command in its current version. But it seems that this
> is caused by, to a certain degree, the too fine granularity, i.e.,
> there are many functionally similar macro/function/command are
> designed separately, for example, `directory-files' and
> `directory-files-recursively'. The traditional Unix tool, `find', can
I wouldn't say that these are "very" similar. Sure they both list files,
but a recursive lister vs. plain lister is a big difference. You can
implement recursive lister with directory-files, I have done it myself
sometime, but `directory-files-recursively' is much nicer and time
saving. I wouldn't say it is "fine granularity" there, rather very rough
granularity :).

>                                The traditional Unix tool, `find', can
> do all the jobs of the above two functions by adjusting its
> `-maxdepth' and `-mindepth' arguments.
Sure, so can others too. But nice thing wiht having it in elisp is that
is more straightforward to use. You have only one language to code in as
opposed to shell or whatever your tool needs etc. Also it is portable to
systems that don't have those tools installed. You also save some time
in process creation. Depending on complexity of your directory tree and
what you are trying to accomplish, it can be costly.

Compare to your shell script to give you longest string from the other
day. It involved several unix tools and thus several processes had to be
created, as opposed to none in the pure elisp case as you got from
Thomas or me.

In a case where you have big files with millions of lines, unix
toolchain would probably win performance wise; I don't know where the
cutoff is. But in the case of not so big file, I think the pure elisp
wins, resource and performance wisely. Not to mention, that writing lisp
is almost like writing pseudo-algorithm. If you reflect over the names
chosen in that function, you can almost see that it was codded on the
go, as I was thinking of it. Compare that to pipes and names like tr and
cut and what not in your original shell solution. So it is a kind of
simplicity, in my eyes, to use just one language, and I guess also a bit
of personal preferance of course.



reply via email to

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