Re: Do shorthands break basic tooling (tags, grep, etc)? (was Re: Shorthands have landed on master)

[Alan Mackenzie]

Hello, André.

On Thu, Sep 30, 2021 at 14:30:11 +0300, André A. Gomes wrote:
> Alan Mackenzie <acm@muc.de> writes:


> > On Thu, Sep 30, 2021 at 13:31:34 +0300, André A. Gomes wrote:
> >> Gregory Heytings <gregory@heytings.org> writes:

> >> > A simple example: suppose you want to check which ELPA package
> >> > activates tab-bar-mode.  That's easy to do with "grep -R tab-bar-mode"
> >> > in a clone of the ELPA repository.  With symbol prefix renaming, a
> >> > package author might decide to add ("tb-" . "tab-bar-") in the
> >> > shorthands of the package, and "grep -R tab-bar-mode" will not show
> >> > anything.  Likewise for tag systems, the symbols that are recorded
> >> > will possibly be different in each package, and a search for
> >> > tab-bar-mode will not return occurrences of tb-mode.

> >> I don't think this is a problem.  Grep comes the world of Unix and its
> >> mantras.  But Lisp REPLs come from another world.

> >> Using grep and tag systems to reason about a Lisp program is like eating
> >> soup with a fork.  You can do it, but it's the wrong tool.

> > That is a very negative and unhelpful thing to say.  Do you have the
> > requisite background to say it?  What precisely would you use in place
> > of grep, which is a powerful, easily learnt, fast, universal tool?

> > My experience is that grep is an essential tool for Emacs maintenance.

> I'm sorry that my words had a negative impact towards you or others.  I
> acknowledge and value the efforts of any member of this community.

Thanks for saying that!

> My words were misinterpreted perhaps.  Firstly, I also eat soup with a
> fork, i.e. I also grep Lisp source code.  But I must be honest with
> myself, and admit it's not the right tool.  Indeed, grep is a universal
> tool that can be used to inspect any textual data.  But powerful Lisp
> environments (think Slime) are "aware of themselves" and do better than
> grep does.

For some jobs, I'm sure they will.  Possibly even for most jobs.  But
they have their disadvantages.  They're difficult to combine with other
tools.  They don't run on the command line.  They tend to need your code
to be instrumented in some fashion first, which is slow.  They're
difficult and time-consuming to learn, particularly for a
special-purpose tool.

The environment I have to use in my day job has such tools built in to
it, and they're well implemented.  But I dislike their constraints.  I
dislike the precise format (unchangeable) chosen for the output.  Now
and then, I'd kill to be able to use 'find' and 'grep' on the source
files.  I don't like integrated development environments.

Also, grep is fast.  On my 4 year old machine today it took 0.27 seconds
to grep through our entire set of Lisp source files, from a cold start.
With those files in cache, it took a mere 0.05 seconds.  This is
effectively instantaneous.

> My point is thus simple and far from being original.  A culture shock
> between "Unix" and Lisp exists, and it has been discussed to death (for
> instance in the "UNIX Haters Handbook").

I know that book.  :-)  Most of the people on this list do both "Unix"
and Lisp, and some are experts at both.  There's no need to have to
chose one or the other, we can use both.

> I think shorthands is a good idea.  While the grep claim is true, I find
> it orthogonal in the sense that we're judging the adoption of a new idea
> by the wrong standards.

If it is going to cause problems in Emacs development, we should surely
discuss those problems in advance and evaluate them, rather than just
saying "should be OK, why worry?".  We're likely talking about an
irreversible change taking place here.  It'd better be right.

> Again, I apologize.

No problems!

> -- 
> André A. Gomes
> "Free Thought, Free World"

-- 
Alan Mackenzie (Nuremberg, Germany).