Re: [Administrivia] On ruby and contrib/

[Barry Fishman <barry_fishman@acm.org>]

On 2013-06-06 09:01:48 EDT, Felipe Contreras wrote:
> On Thu, Jun 6, 2013 at 7:24 AM, Barry Fishman <barry_fishman@acm.org> wrote:
>>
>> 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.
>
> Nobody is judging the usefulness of a language, I have plenty of
> arguments for that, but this is about popularity.

I used "usefulness" in its general vague sense.  It is useful to be popular,
I don't make choices solely on that or I would be writing everything in
Java.

>> 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 be perfectly fine with replacing shell, sed, awk and perl with
> ruby. But that's not what you are arguing, is it?

I'm talking about porcelain code and not core functionality which should
be left in C.  I'm saying that you should be free to provide Ruby
implementations of all such superstructure.  And the same can be done by
(but not required by) the Perl, Python, Tcl and even C, Haskel, Guile
and whatever communities.  Most such higher level code is fairly
trivial, and if the file names are kept the same, the same test
procedures could be run.

I don't think the cost of duplication of code functionality is that
significant, since it would bring new people to the project.  After all
this is a free project and not a commerical venture.  It certainly helps
porting to new platforms.  Separate language communities would be
maintaining their own contributions, with their own experimental
directories.

Translating the same functionality to multiple languages requires
careful reading which can help identify some hidden bugs.

-- 
Barry Fishman