
Perl 5 now uses Git for version control - arthurk
http://use.perl.org/articles/08/12/22/0830205.shtml
======
jm4
Half the time there is a Perl article on here everyone is ripping it. How is
it that so many people are interested in what _version control_ software Perl
5 uses? I'm genuinely curious. It's odd that this thing got so many votes but
my comment is the first one. Besides the developers and a few people that
checkout and build from source, does this really impact anyone? I know Git is
a cool buzzword now. Are a bunch of people voting this up without even looking
at it?

~~~
dreish
I think people are happy to see a project dump Perforce for git. Perl may be
on the decline, but it is still a pretty significant free-software project.

~~~
jrockway
Where is Perl on the decline?

Oh, in terms of brightly-colored blogs... I get it.

~~~
dreish
I've been trying to hire a perl programmer for about a year now. It's just not
where the smart people want to go with their careers, but we have a huge
codebase built up in it, so we're stuck.

~~~
jrockway
We don't have any trouble hiring Perl programmers. Maybe it's less about Perl
and more about other aspects of the job, in your case?

And oh yeah, I think I am offended by the "it's just not where the smart
people want to go" comment.

~~~
jbjohns
I interpreted his comment to mean new programmers. Maybe smart people have
_gone_ there in the past, and some of them may not even have left yet, but I
would think that someone just getting into scripting is very unlikely to start
with Perl.

There really isn't a reason to; the script languages that have come since then
have fixed Perl's problems without losing any power. The only argument Perl
has left is CPAN [1], but given the amount of duplication and bad code there,
CPAN isn't as big as it's made out to be. I don't know about Ruby, but I used
Python not so long ago and I noticed that not only did it have libraries for
everything I needed to do, aside from DB access (which I had to download) they
were all included with python itself. This is very nice in big organizations
where downloading _anything_ is a huge pain.

[1] Well, ok, it also has the COBOL argument of "there is a large code base
out there to be supported" but I would expect this argument to only be
compelling to the same people that were attracted when COBOL used it.

~~~
jrockway
I don't think the CPAN is as important to people that haven't used it as it is
to people who have. Many programmers are used to reinventing the wheel poorly,
either due to the "it's fun" factor, or the "we can't use external code"
factor. In that case, the CPAN isn't much of a compelling feature, since they
aren't going to be using its libraries anyway. ("I have to install a library
to get a function that reads a file into a string? Fuck it, I'll write it
myself.")

Try doing your next project in Perl, using the CPAN where appropriate, and
you'll see that the standard libraries of Python, Java, Haskell, whatever are
simply inadequate.

(In the end, it really depends on what you are doing. J2EE is probably fine
for an web page that extracts some rows from a database. Most programming
tasks are not that trivial, however, even if they should be.)

~~~
jbjohns
I'm sorry, I have to (strongly) disagree. I used Perl professionally for 5+
years. I was the one that always added bindings to C and C++ libraries. I
wrote a massive OO network management system that used all kinds of meta-magic
(keep in mind this was long before Moose, etc.) to deal with new kinds of
computers coming into the system automatically that is, afaik, still running.

And I'll never use Perl again for anything on purpose. I'm not a Python
fanboy, but I don't find your library comment right at all. In fact, the time
I used Python was because I had to add functionality to an older Perl project.
Rather then write in Perl I rewrote the entire thing in Python (that is; I
chose to use a language I didn't know at the time, rather then write Perl
again). The resulting source code was one third the size (I counted) and much
much clearer with more features added. I didn't have to download anything for
Python while the old Perl code was using 4 or 5 CPAN modules.

As for Java/Haskell, this is obviously not a fair comparison: Perl+CPAN vs.
Java/Haskell _standard_ libraries. If you include third party libraries for
Java it should have far more code then any other language by now.

------
bestes
I upvoted it (and read it, but the title actually did convey all the
information that I cared about). Why? Because I really like git and I think
that for Perl development to move to git (and to have done such a
careful/fantastic job of it) is impressive. I also like Perl, and it makes me
happy to see it continue to develop and take advantage of the latest
technology. Not becase it is cool, but because it is better (specifically
referring to git).

------
CUViper
This feels a bit symbiotic, given that a big chunk of git is written in Perl.

Should we now watch to see whether Python chooses Mercurial or Bazaar? Seems
they're already leaning towards the latter:
<http://www.python.org/dev/bazaar/>

Sorry Ruby fans, I don't know of any Ruby DVCS for you to pair up with. Even
as popular as git is with ruby-devs, I can't see git ever using ruby itself...

~~~
frenchtoast
Bazaar and Python are a natural fit. Besides being written in Python, Bazaar
provides nice integration with Launchpad -- and Ubuntu makes heavy use of
Python in general.

Anyhow, Bazaar has very nice documentation, is easy to use, and certainly has
a helpful and friendly community behind it. It's also now officially a GNU
project, so it's not going anywhere any time soon.

~~~
asjo
> It's also now officially a GNU project, so it's not going anywhere any time
> soon.

I first read that in _exactly_ the opposite way it was, surely, meant. Heehee.

