in reply to Re: no more perl in BSD core
in thread no more perl in BSD core

*sigh* (double *sigh*, I had a reply done and my machine croaked). Perl is the language, the binary. Not the modules, they are but a library to save you time. Does that mean they can be removed willy-nilly? Well, that's moot, I'd say yes, but you shouldn't. anyways, you've said more interesting things I'd like to address.

Re: your whole second paragraph, Larry himself has said that one should only be required to know what is necessary to get the job done. Neither you, nor me, nor anybody else is expected to know every last detail about Perl. There wouldn't be much fun, learning, or interaction if we all knew all of it. Besides, one of the most wonderful things is coming across an as of yet undiscovered (by you) gem. Be it in man pages, the default libraries, or a module on CPAN. To quote Bill Waterson, "There's treasure everywhere".

--
perl -pew "s/\b;([mnst])/'$1/g"

Replies are listed 'Best First'.
Rex3: no more perl in BSD core
by stefp (Vicar) on May 12, 2002 at 00:09 UTC
    I know the slogans about "baby perl" and "getting the job done". They were true when I started using perl in 1989. They are not true as far newcomers are concerned. You are confusing the slogan with the reality. One of the problem is that perl5 is now a senescent language. But that's ok. it has done its time, paved the way for the next generation, and perl6 is around the corner. And the experience we got with perl5 will give us a head start on perl6

    perl5 has become a cave with a lot of twisty passages and like you said, "treasure everywhare" if you got time to spare. My point was that most people don't have that time, and don't want to put up with the junk for the sake of the jewels.

    An example to support my point: suppose you are a Unix guru but a perl beginner and you want to build a server of some sort. You know this will be based on sockets and you will find the documentation about the socket() function but you won't easily find doc about the Socket module, or higher level modules to build server or even the POE module.

    perl5 is dying of entropy. There are many jewels around but hidden in so much crap that has no sense but historical.

    Some language like Python or Ruby are cleant up perl5 but they are only that. Hopefully, with perl6, we will be able to start again with experience without the uneeded baggage and with the vision of Larry and Damian.

    If we don't have the courage to admit what perl5 is and to wait for perl6, the relevant slogan is John's ones: "We are fucked...". Don't trade on the glorious past but prepare for the future.

    -- stefp -- check out TeXmacs wiki

[reply]
      Do you mean the language or the libraries? Granted, one of the things that most distinguishes Perl from a lot of other languages is its huge tracts of libraries, but there's a big difference between saying that Perl is chaos and that its libraries are. I think you can make a case for either, but I believe you're referring mostly to the libraries.

      Also, if Perl 5 is sick and bloated, why do we have to leave it to die? Imagine that the people who are off creating Perl 6 now were instead putting all their effort into organizing and cleaning up the standard Perl 5 modules, deprecating old language features, etc. Imagine that Perl's leadership were dull and plodding, like a FORTRAN or C standards committee. One year from now they could decide on a new, leaner set of core libraries. Perl 5.10 could deprecate the old libraries and interfaces, and 5.12 could remove them. Change on an evolutionary timescale may seem boring and slow, but it can be remarkably effective. We humans are a software engineer's nightmare, loaded with evolutionary baggage, but software engineers haven't been able to create better.

      /s

[reply]

In Section Meditations