Re: [Administrivia] On ruby and contrib/

2013-06-06 Thread Barry Fishman 
On 2013-06-06 10:09:21 EDT, Felipe Contreras wrote:
> I don't know what you are saying, but it clearly has nothing to do
> with the point.
>
> Perl is declining, and it would be wise to use another language
> instead of it.

You want a simple statement.  I don't particulary like Perl, but it has
worked well for the project.

If you have a better solution, then write all the code to replace it,
and demonstrate with a significant number of active users that your
solution works out better in practice.

Wasn't that how Git started?

-- 
Barry Fishman

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Administrivia] On ruby and contrib/

2013-06-06 Thread Barry Fishman 

On 2013-06-06 09:01:48 EDT, Felipe Contreras wrote:
> On Thu, Jun 6, 2013 at 7:24 AM, Barry Fishman  wrote:
>>
>> On 2013-06-06 03:46:59 EDT, Felipe Contreras wrote:
>>> On Thu, Jun 6, 2013 at 2:26 AM, demerphq  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

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Administrivia] On ruby and contrib/

2013-06-06 Thread Barry Fishman 

On 2013-06-06 03:46:59 EDT, Felipe Contreras wrote:
> On Thu, Jun 6, 2013 at 2:26 AM, demerphq  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

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html