Perl 5 now uses Git for version control | Hacker News Reader

Perl 5 now uses Git for version control

use.perl.org

35 pointsarthurk16 comments

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?

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.

Where is Perl on the decline?

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

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.

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.

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.

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.)

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.

Be offended all you want. I do most of my programming in Perl. I could be wrong, but I'm just sharing my observations.

How does your codebase look? Neatly organized and with tests? Does it use much modern best-practice, or are there a lot of not-so-nice pieces?

Also, it may just be difficult in general to find really good people to help maintain an already mature and large codebase.

No, in terms of new adoption: http://journal.dedasys.com/2008/12/07/python-surpasses-perl etc.

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).

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...

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.

> 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.

Ruby speaks .git : http://github.com/github/grit/tree/master

Go ruby glue, go!

Reply on news.ycombinator.com