in reply to What could I do with just Perl?

Technically, you can do all of the same things with just pure Perl that you can do with all of the modules on CPAN installed. For that matter, technically, you could do all of the same stuff with C or assembly language, or anything else that's Turing-equivalent. (If you're not familiar with this concept, do a Google Groups search for Turing Equivalence.)

So, why do we have CPAN then? Because in practice there's often a big difference between technically can be done and what it is suitably convenient or worthwhile to do. It is *possible* to write an email client in pure Perl with no modules, but it will take you weeks just to get a very basic working start. With POP3Client, Net::DNS, and Net::SMTP, you can have the same amount done in hours. It is *possible* to write database stuff in pure Perl to interface with an RDBMS, but with DBI you can do it in a *lot* less time. It is *possible* to study up on PKWare's Zip archive file format and write your own Perl code to read and write zipfiles, but you'll spend days or weeks; with Archive::Zip you can do it in an afternoon and have time left over for testing.

In short, the value of CPAN is not in what it enables you to do, but in what it saves you from needing to do.


$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}} split//,".rekcah lreP rehtona tsuJ";$\=$ ;->();print$/

Replies are listed 'Best First'.
Re: Re: What could I do with just Perl?
by dref (Novice) on Nov 30, 2003 at 13:59 UTC
    No. Turing equivalence is not enough.

    Turing equivalence allows you to compute the same things, true, but it does not allow you to _do_ the same things. For instance if you take brainf*ck, well known to be turing complete, how do you get brainf*ck to do a syscall? You can't.

    Besides the computational power you also need the "functional" power. In Unix this means that you need syscalls. If you have syscalls then you have it all. (Since I/O for instance translates into syscalls).

    On a more theoretical note you might observe that the Turing machine has an "infinite tape". So any machine that is equivalent to a turing machine will have to have infinite storage capacity.

      Turing equivalence allows you to compute the same things, true, but it does not allow you to _do_ the same things.

      Besides computation, the only other thing there is to _do_ is I/O. Whether Perl has adequate I/O without modules is going to depend I suppose on what kind of I/O you need to do, but in general if you compare it to other existing languages it fares quite well in that regard. Syscalls are not, strictly speaking, needed for anything other than I/O.

      However, I certainly agree that Turing equivalence is in itself not enough to expect out of a good language. That was actually my point, though maybe I didn't state it very clearly. If that were enough, we could all just use assembly language, or, as far as that goes, program using hexadecimal numbers directly. Having a good language is about making things more efficient, easier, better, et cetera; for Perl, part of that is the CPAN; I personally do not consider any Perl installation to be complete or terribly useful in practice without a working CPAN.pm

      There happens to be at the moment more on this topic (Turing equivalence and its inadequacy as a criterion for determining the usefulness of a language) on my pad, as I am presently in the process of piecing together there a pending meditation which may or may not end up getting posted. (Feedback on it, including whether it is worth posting, is welcome.)


      $;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}} split//,".rekcah lreP rehtona tsuJ";$\=$ ;->();print$/
        This depends a bit on what you mean by "io". Do you think that the "kill" syscall represents io? What about "reboot"? Certainly all syscalls interact with the operating system, but not all syscalls interact with the user, a disk, a printer or the network. But yeah IO is sort of important. And since perl has a syscall builtin it is certainly powerful enough in this respect too.

        Yes. I certainly agree with the practical side of what you were saying. The structure of a programming language is extremely important. It shapes how we think. I mean, just think about 1986 and how they shape language to shape thought. Language designers get to do the very same things. And it is very exciting. I just pounced on the theoretical point (because I was dodging real work).

        As for Lazy evaluation. Don't go totally down that path. The functional language community has tried this in Haskell, and while it has theoretical beauty it has practical problems. Some of the practical problems have to do with side effects. In the presence of side effects you face problems with incoherency and such depending on reduction order and other estotheric things. (There are papers written on this of course, these people write more paper than code sometimes).

        That being said. Maybe partial laziness might be a good thing. Perhaps partial laziness could be implemented with a keyword and a source filter in Perl 5. Hmm. Yes. Lazy assignments.

        my $result =[l] calc(30,20,"FooBar"); my $result2 =[l] calc($result,20,"YoYo"); my $result3 = $result + $result2;
        We'd have to take care that it was never evaluated more than once though. Hmm. I think this might be doable. Yes a source filter and a hidden tied scalar is what we need. And some duct tape.

        Danged. Now I forgot what my post was about. Anyhow, the musing seem interesting.

        A quick edit.. A search on CPAN returned: http://search.cpan.org/~jenda/Data-Lazy-0.5/Lazy.pm

        I would still want it in the semantics though, so maybe just couple it with a source filter.