http://qs321.pair.com?node_id=640002


in reply to Re: perl and linux (was Re^3: Tired of "Perl is dead" FUD ?)
in thread Tired of "Perl is dead" FUD ?

You raise a number of good points here... a few comments, in no particular order:
I'm not sure if Debian, Ubuntu, Mandriva, PCLinuxOS, T2, Gentoo, Slackware, LFS, or what would be the best starting point without some fresh looks.
My inclination is to go with Debian/Ubuntu as a starting point because I think it's got some serious momentum, and yet because Debian has a strong volunteer base, it's not going to disappear because of the vagaries of the marketplace. In general, Debian seems very well put together (e.g. everyone else has had to play catch-up with it's package management system).

Debian also, not incidentally, has an official Perl Policy.

Myself, I would prioritize writing a new perl-based package manager relatively low: the idea is a "perl-centric" distro, not one written solely in perl. Though on the other hand, a perl-based front-end to the existing APT tools might make some sense though... perhaps something that merges together apt-get and CPANPLUS in an intelligent way (e.g. you might want to be able to install the latest from CPAN, and create a "deb" for it automatically, so the database of installed packages stays up-to-date).

It's worth noting that if flexibility and familiarity for Perl developers is favored over performance, we could eventually go so far as ditching Apache, postfix (or other SMTP system), syslog, sshd, ssh, text editors, and more with pure-Perl solutions
Well, any of those things might be looked at on a case-by-case basis, but I'm a little skeptical that it would make sense to go quite that far. The idea is to cater to perl-culture, not necessarily to re-write everything in perl. One of the features of perl culture is it's pragmatism: there's a willingness to work with other code (and to steal ideas from anything that wanders by...). Just to take one example, arguably, familiarity with Apache is already pretty strong among perl programmers: you're not going to talk many of them into trashing their web-server performance for the sake of ideological purity.

There's a reason I mentioned the init system, by the way: it's a mess of shell scripts that burn a lot of processes, and it really is noticeably slow. It's definitely ripe for replacement, and someone is going to get to it at some point. (And to tell you the truth, the main virtue of writing one in perl is likely to be inspiring competition from the kernel-hacker C-programmers).

Am I advocating a Parrot-centric OS distro with tools written in Perl 6 and used for developing in Perl 6 given special attention? Yes, I think I am. Before Parrot and Perl 6 are at final release might be the best time to start such a project, but I'm not sure how much before.
What I would suggest is start with perl5 and keep an eye on including perl6/parrot components as they become available. Myself, I wouldn't assume that either perl6 or parrot is really the wave of the future, and having a perl5 focus at the outset gives you a wider base of people who might be interested in what you're doing.

In general, if I were writing the manifesto, I'd focus on being useful to perl programmers, and accomodating to perl-culture (which includes apache, databases, and so on, as well as multiple different developer environments -- emacs, eclipse, etc). A secondary goal would be to move toward making everything customizeable in perl, if at all possible...

Replies are listed 'Best First'.
Re^3: perl and linux (was Re^3: Tired of "Perl is dead" FUD ?)
by mr_mischief (Monsignor) on Sep 20, 2007 at 02:19 UTC
    It's all really a matter of scope I think. Of course, the friendlier a package is to Perl and the harder it would be to replace, the more likely it'd stay around anyway. Apache, postfix, Exim (although I prefer Postfix), emacs (although I prefer vim), vim, the GIMP, and several others already are pretty Perl-friendly.

    Startup and shutdown scripts would definitely be the place to start. The reason I'd like also to see many command-line tools done in Perl is threefold. It encourages more tinkering than the current BSD or GNU tools. It also, if they are licensed under Perl's terms, deals with quite a few licensing issues where BSD and GNU tools fall on opposite sides of the fence. I could take my Perl-based, Perl-licensed tools anywhere on any system where they'll work, and not get hassled by others about the license. It's also a bit easier to have portable Perl-based programs for the command line than to write similarly portable ones from scratch in C. Most of the portable C programs that exist got that way over a long period of time.

Re^3: perl and linux (was Re^3: Tired of "Perl is dead" FUD ?)
by wolfger (Deacon) on Sep 20, 2007 at 13:30 UTC
    The idea is to cater to perl-culture, not necessarily to re-write everything in perl. One of the features of perl culture is it's pragmatism: there's a willingness to work with other code (and to steal ideas from anything that wanders by...). Just to take one example, arguably, familiarity with Apache is already pretty strong among perl programmers: you're not going to talk many of them into trashing their web-server performance for the sake of ideological purity.

    I agree. Especially where Apache is concerned. I don't know a Perl guy who doesn't like Apache mod_perl...

      It depends on focus, of course. A serious installation for getting real work done would probably use Apache. A tech demo to show off what one can do with Perl might include Jellybean instead.

      Given the right package selection tools, I guess one could do either. It could even be a high-level choice in the installer. "Real Work Pragmatism" vs. "Even More Perl-centric". Then, individual packages could be selected and deselected.