Re: [PATCH] Eliminate Scalar::Util usage from private-Error.pm

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



--- Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote:
> Hi,
> 
> [please do not remove me from the Cc: when replying to my mail]
> 
> On Wed, 26 Jul 2006, Jakub Narebski wrote:
> 
> > Johannes Schindelin wrote:
> > 
> > > Seriously, I still believe that proof-of-concepts in Bash or Perl or even 
> > > Python are fine. But they are not for real work, so one of my long-term 
> > > goals for git is to get rid of them.
> > 
> > I don't think that we would want to rewrite gitweb in C, for example.
> > And Perl for porcelanish commands is all right, IMVVHO.

I agree with Jakub.  Both on the deployment side and on the maintenance
and upkeeping side.  Small and fast engine in C and porcelain in whatever
makes sense: Perl, Python, Bash, or even C, etc.

> This is true as long as you do not have problems with Perl. As soon as you 
> start having too many problems with Perl, you want to get rid of it as 
> soon as possible.

The normal thing to do is to post an email to the mailing list describing
the problems you see with Perl, and describing your solution to them, possibly
accompanied with a patch.  But to just post a "convert-to-C" patch is hardly
constructive (to the actual problem you had).

> Think missing modules. Think ActiveState. Think corporate environment. 
> Think other platforms. Think having to mix compilers. Or to support 
> another one, because you cannot mix. Etc. etc.

Yep, exactly _those_ reasons you outlined, tell me that some things are
_better_ off staying in Perl/Python/etc.

    Luben

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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]