Re: [PATCH] CodingGuidelines: remove suggestion to write commands in Perl/SH

From: Junio C Hamano <gitster@pobox.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] CodingGuidelines: remove suggestion to write commands in Perl/SH
Date: Sat, 17 Apr 2021 15:01:17 -0700	[thread overview]
Message-ID: <xmqqmttwbmfm.fsf@gitster.g> (raw)
In-Reply-To: <patch-1.1-83266f30b67-20210417T084346Z-avarab@gmail.com> (=?utf-8?B?IsOGdmFyCUFybmZqw7Zyw7A=?= Bjarmason"'s message of "Sat, 17 Apr 2021 10:43:54 +0200")

Ævar Arnfjörð Bjarmason  <avarab@gmail.com> writes:

> Remove a suggestion to write new commands in Perl or Shell to
> experiment. This advice was added in 6d0618a820a (Add
> Documentation/CodingGuidelines, 2007-11-08).

I think this needs to be rephrased to clarify that it is mainly to
allow easier prototyping.

> Since then the consensus changed to having no new such commands unless
> necessary, and existing ones have been actively migrated to C.

Well, "unless necessary" is quite an interesting word here.  There
are trade-offs, and some things are not worth spending cycles to
write in C than leaving quick hackability for developers.

Also existing ones getting migrated to C does nothing to support the
implicit claim the above sentence makes, which is "writing the first
version in C is recommended".

    If you are planning a new command, it may be easier to prototype
    by implementing it as a script, until you and others on the list
    can figure out what the semantics and end-user experience should
    be, instead of starting the initial version in C code.  Many Git
    commands started out as scripts and then later rewritten in C.

More importantly, we probably should stress that we've been very bad
at maintaining plumbing to allow such quick experimentation.  We
should encourage (or even require) developers to make the feature
they directly hacked into the Porcelain command available also to
the plumbing layer, so that those who script with plumbing commands
can also use it.

> - - If you are planning a new command, consider writing it in shell
> -   or perl first, so that changes in semantics can be easily
> -   changed and discussed.  Many Git commands started out like
> -   that, and a few are still scripts.
> -
>   - Avoid introducing a new dependency into Git. This means you
>     usually should stay away from scripting languages not already
>     used in the Git core command set (unless your command is clearly