Re: [Administrivia] On ruby and contrib/

[Barry Fishman <barry_fishman@acm.org>]

On 2013-06-06 03:46:59 EDT, Felipe Contreras wrote:
> On Thu, Jun 6, 2013 at 2:26 AM, demerphq <demerphq@gmail.com> wrote:
>> Good thing you are being objective and leaving out the Python 3.0
>> mess, the long legacy of backwards compatibility in the Perl
>> community, the active community behind it, its extensive portability
>> support, and fail to mention the lack of an equivalent to CPAN. We
>> wouldn't want facts to get in the way of a personal bias would we?
>
> None of that has anything to do with Perl's popularity.
>
>> Just thought I'd push back on the FUD. People have been saying Perl is
>> going away for decades...
>
> Perl has been going away for the last decade [1], and will continue to
> go away. Perl is going away, and that an undeniable fact, and if you
> are not interested in discussing on the basis of reality, I'm not
> interested in discussing with you.
>
> [1] http://www.tiobe.com/content/paperinfo/tpci/images/tpci_trends.png

I don't think the usefulness of a language should be judged by hits on a
web site.

Personally I would like the Git client to be packaged with as few
dependencies as possible.  Right now that seems to require Shell, Sed,
Awk and Perl.  The documentation has other requirements, but a prebuild
tar file is available.

I would have the rest of the distribution be bundled as something
like "git-utils" which could have a subdirectory for each support
language.  Then one could even make available alternative
implementations of higher level utilities and people could decide if
support of a specific language was useful to them.

Most such extension code is simple, although more complex than suitable
for just Shell/Sed/Awk.  People in each language community could provide
code which meets the needs of their community, and the Git project
itself would not need to make (Solomon like) decisions about what
extension languages to support.

--
Barry Fishman