Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation
 
PerlMonks  

perl not omnipotent? let's see!

by Moron (Curate)
on Oct 12, 2005 at 15:56 UTC ( #499558=perlquestion: print w/ replies, xml ) Need Help??
Moron has asked for the wisdom of the Perl Monks concerning the following question:

this prompted me to issue the challenge: those who agree with the statement could produce a piece of functionality in another language they think cannot be done in perl. Those of us who think anything can be done in perl can then in return take up the challenge to prove it can indeed be done in perl.

-M

Free your mind

Comment on perl not omnipotent? let's see!
Re: perl not omnipotent? let's see!
by xdg (Monsignor) on Oct 12, 2005 at 16:06 UTC

    It's a fine challenge. Of course, given the original claim, it's important to recognize that these are not equivalent (replacing "Perl" with "A" to make the point):

    A is the only language that can do everything any other language can d +o. Everything that can be done in another language can be done in A.

    -xdg

    Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

Re: perl not omnipotent? let's see!
by Perl Mouse (Chaplain) on Oct 12, 2005 at 16:09 UTC
    This thing could go either way (but I disagree with your claim both ways).

    Either you mean Perl is the only language that has all constructs/techniques that any other language has. That isn't true - for instance, Perl doesn't have continuations or co-routines. Or even POSIX regular expressions (always prefer to find the longest match instead of the first match).

    Or you mean that Perl is the only language that can simulate or mimic constructs/techniques that any other language has. That isn't true either, because if it can be simulated in Perl, in can in C, as C is driving perl.

    Perl --((8:>*
Re: perl not omnipotent? let's see!
by Dominus (Parson) on Oct 12, 2005 at 16:10 UTC
    Said Moron:
    those who agree with the statement could produce a piece of functionality in another language they think cannot be done in perl.

    But that's not enough. You said that "(Perl) really is the only language that can do everything any other language can do.". To prove that, you need to prove that no other language can do everything any other language can do. So for each other language l, other than Perl, you need to find something that l cannot do.

    That's the part of your statement that I thought was most mistaken, anyway.

      I have updated it to include the idea of feasibility.

      -M

      Free your mind

Re: perl not omnipotent? let's see!
by itub (Priest) on Oct 12, 2005 at 16:11 UTC

    Sorry, I'm too lazy to provide code samples.

    The question is ambiguous. Of course, everything you can do in Perl, you can do in C, because perl is implemented in C. And everything you can do in C, you can do in assembler.

    The real question, IMO, is whether you can express things in a "natural" and efficient way in a language. I think any declarative language such as Prolog or SQL is full of examples of things that are trivial to do in those languages, but awkward and inefficient in Perl. Of course, you can use SQL and Prolog from Perl if you want...

    Another case is when you need speed and memory efficiency. Can you multiply large matrices in Perl efficiently? Not really, unless you use PDL or some other numeric extension, which happens to be implemented in C (there might be some in Fortran as well).

Re: perl not omnipotent? let's see!
by rnahi (Curate) on Oct 12, 2005 at 16:16 UTC

    Your claim is pointless. If you are smart and knowledgeable, you may do almost everything in every language.

    Somebody even solved The N-queens problem using pure regexes. So Perl could do mostly everything, provided that you know how to. But the real question is "it is really worth doing everything in Perl?

    See What is Perl *NOT* good at? for a more reasonable take of this issue.

      It would hardly be either to attempt to write a compiler in say visual basic. I think the N-Queens case is just done for fun - it certainly amused me!

      -M

      Free your mind

Re: perl not omnipotent? let's see!
by Skeeve (Vicar) on Oct 12, 2005 at 16:40 UTC

    If we limit ourselves to algorithms, Perl Mouse is right with her/his statement.

    If I recall my computatenol lectures correct, it's a prooven fact that a turing machine can compute any algorithm. So it's a fact that for any algorithm you can express in any computer language, there is a turing machine that is an implemantation for this algorithm.

    If that statement is correct, and please correct me everyone who knows better, it's a fact that a perl program can compute any algorithm. It's simply a matter of implementing a turing machine in perl.

    Agreed: It's very theoreticaly ;-)


    s$$([},&%#}/&/]+}%&{})*;#$&&s&&$^X.($'^"%]=\&(|?*{%.+=%;.#_}\&"^"-+%*) +.}%:##%}={~=~:.")&e&&s""`$''`"e
Re: perl not omnipotent? let's see!
by steelrose (Scribe) on Oct 12, 2005 at 16:58 UTC
    The question shouldn't be 'CAN it be done in Perl' but 'how EFFICIENT is the Perl solution'.

    That, as most of you are aware, becomes the dreaded 'How good is/are your benchmark test(s)?' scenario.

    So, that being said, there will never be a solution that will fit everyone's criteria. Those that believe in the power of perl will continue to do so, and those that do not, will not... IMO of course.

    If you give a man a fish he will eat for a day.
    If you teach a man to fish he will buy an ugly hat.
    If you talk about fish to a starving man, you're a consultant.
Re: perl not omnipotent? let's see!
by TedPride (Priest) on Oct 12, 2005 at 17:01 UTC
    Data structures tend to take up a lot more space in Perl than they do in C++. Therefore, given a large structure and limited memory, a program could work in C++ but not in Perl.
      Actually it is possible to reduce the perl datastructure to a tiny overhead using a single hash and use of the pack() function to control how it is stored in memory. The real overhead is the interpreter itself, although the C++ libraries are going to offset that in a comparison. But the more common language than either for such situations is embedded C which is specially designed for small units such as mobile telephones. Despite that, downsizing advances suggest that this will be a temporary circumstance - as bigger systems get delivered on smaller handheld units, the near future is looking far from written.

      -M

      Free your mind

        Your datastructure is a lot bigger than you think, the values of the hash are SVs, and SVs are pretty big.

        I'll also note that it is possible to reduce the Perl datastructure even more by building a small interpreter that decodes and encodes all of your data in a single string. But the result won't feel very Perlish. (Nor will your solution.)

Re: perl not omnipotent? let's see!
by tirwhan (Abbot) on Oct 12, 2005 at 17:08 UTC
    OK, please try to do this in perl.

      You are E-ville. I like it.

      print substr("Just another Perl hacker", 0, -2);
      - apotheon
      CopyWrite Chad Perrin

      I can't even do that in C, how the heck would I be able to do that in perl? :-)

      Aw come on it's a simple one liner, surely... ;)
      perl -e 'system $_ while(<>);'

      -M

      Free your mind

Re: perl not omnipotent? let's see!
by tilly (Archbishop) on Oct 12, 2005 at 17:48 UTC
    For a number of years the International Conference on Functional Programming has held an annual competition. In this competition teams are asked in a very short period of time to build a the best piece of software that they can under tight time deadlines. An example was this years task to build a program that would play a variant of cops and robbers.

    Any team may use any language.

    Most (all?) years, some teams attempt to use Perl for this. As far as I know, Perl has never managed to place in the top 3.

    That strongly suggests to me that there are some kinds of tasks which Perl is not ideal for.

      For a number of years the International Conference on Functional Programming has held an annual competition. In this competition teams are asked in a very short period of time to build a the best piece of software that they can under tight time deadlines.
      A link: ICFP 2005 Contest. To quote from it:
      • The judges' prize goes to Dylan Hackers. The judges are happy to proclaim that the Dylan Hackers are an extremely cool bunch of re-hackers.
      • First prize goes to KiebererAndXiaoTou. The judges are happy to proclaim that Haskell is the programming tool of choice for discriminating hackers.
      • Second prize goes to Dylan Hackers. The judges are happy to proclaim that Dylan is a fine programming tool for many applications.
      • Third prize goes to Combat-Tanteidan. The judges are happy to proclaim that Haskell is also not too shabby.

      Seems like O'Caml, winner for many years of 1st/2nd/3rd prize is now nothing but a distant memory. (Thanks, g.!!)

      Game software is indeed highly specialised - usually needs special hardware as well. But the fact remains it would probably still be easier or mor likely to be possible for perl to call up functionality in a specialised gaming language than the other way round.

      -M

      Free your mind

        You have this almost exactly backwards. You're thinking of the wrong kind of game.

        Don't think of this as a game like Doom. Think of it more as a game like chess. It isn't about being able to draw lots of frames really quickly. It is about coming up with the best choice you can find in a definite time. The best piece of hardware to use for this on a normal PC is the main CPU.

        In general the contest is set up to favour languages that are good for rapidly developing complex software which has decent performance. Compared to the languages that regularly place well in that competition, Perl loses on all of these criteria. Development in Perl is slower, it is harder to manage complexity in Perl, and the final program tends to perform more slowly. Furthermore (contrary to what you claim), Perl's basic extension mechanism is a mess, I would not be surprised if it is easier to extend those other languages to call up functionality in a specialized language than it is in Perl.

        Take, for instance, the language that won first and third prizes in the ICFP contest this year. It is the language that Atrijus Tang chose to implement his version of Perl 6. Everyone who has even a passing familiarity with this project has been astounded at how quickly that project was developed. And its extension mechanism is a lot easier than Perl's XS.

        So why don't those languages take the world by storm and wipe out Perl? (If you're familiar with Worse Is Better, then you know the punchline that is coming.)

        Well because Perl is better at being popular.

        First of all, if you're serious about finding the absolute best language for development, you form strong opinions. And your opinions probably don't match the opinions of someone else who wants a perfect language. So you both write your own languages. This leads to a lot of very good languages with very small user bases. And no matter how good the language may be, without users you're not going to build up good libraries. Without libraries you'd better be good at rapid development, because you're going to have a lot of development in front of you!

        Compare to Perl and CPAN. If your style of rapid development is building software from scratch (as the problems in that contest force it to be), Perl loses. If your style of rapid development is finding big working pieces that you can plug together, Perl wins big for many practical problems. For instance if you want to call out to some weird library or language, it may be easier to write that binding for Dylan, but you're more likely to find it already written for Perl.

        A large enough user base brings all sorts of other advantages as well. You can find programmers when you want to grow your team. You can find people who can help you with problems. You can find people who have tried to do what you're trying to do. Publishers are willing to write books about your language. And so on. Accumulate more reaasons to use Perl.

        So you want to be popular? One of the first things that you'll want to do is make it easy to get started. For instance make it easy to program in "baby talk". That is, let people who know very little Perl easily write useful programs. You might also deliberately make your language look a lot like a lot of languages that your target audience is familiar with. In Perl's case some languages to resemble are C, awk, sed, and shell. That lets people leverage existing knowledge.

        By contrast "ideal programming languages" often have a big learning curve as they push you to work in a specific way that is alien to both novices and many experienced programmers. For instance any imperative programmer who wants to learn Haskell has to re-think everything they think they know about how to organize programs. (What do you mean that a print statement there would be a compile error?) Any programmer in an ALGOL-descended language (eg Pascal, C, Java, Perl...) who wants to learn LISP has some syntactic sticker-shock to get over. (Perhaps I should say "non-syntactic sticker-shock"...) Those techniques often are big improvements in how to program (at least for some kinds of problems), but a lot of people are going to fail to get there.

        That is not to say that better techniques don't make their way into mainstream languages from time to time. For instance it was once claimed to be easier for non-programmers to learn Smalltalk than programmers because they had less to unlearn. That isn't true today (if it ever was) because people learn object-oriented techniques in many other languages. But, for instance, Perl doesn't push you to use OO like Smalltalk does, nor can Perl express a pure OO design as cleanly as Smalltalk. OO in Smalltalk was a Big Idea. Telling people that they should organize their programs that way was a Big Change.

        Perl's improvements are far less intrusive. A big one was a series of improvements in regular expression support. But you can learn Perl without learning regular expressions. Real programs aren't typically organized about the idea of regular expressions. It was never all that hard to do text matching and substituting in any case. In short, having some improvements in regular expressions isn't a big change in how we program.

        But improved regular expression support is an easy improvement to evaluate. After a short learning curve, a lot of somewhat annoying tasks become easier. Contrast how hard it is to benefit from OO. Or functional techniques. Or monads. So Perl's improvement might not have been very important. But it was popular.

        In short, on a lot of criteria that you might think should be important, Perl is worse. But Perl is worse in a Worse Is Better kind of way that leads to success.

        As I've commented many times, I think that Larry Wall is better at hacking communities than he is languages. (That's not to say that he is bad at languages...) And the community that he has created is Perl's single biggest strength.

Re: perl not omnipotent? let's see!
by Anonymous Monk on Oct 12, 2005 at 18:23 UTC

    I have to admit it. Excellent choice of nick.

    As for the rest, try doing your advocacy at comp.lang.c. Perhaps you would get more challenging answers.

      I suggest you or someone else register and publish on that URL before you advocate it ;)

      -M

      Free your mind

Re: perl not omnipotent? let's see!
by Anonymous Monk on Oct 12, 2005 at 21:53 UTC
    hey moron, its Perl not perl!
      I suggest you take it up with the trademark owners if you disagree - it has nothing to do with me that it was registered in lower case.

      -M

      Free your mind

        what trademark? what was registered in lower case?

        Now it's clear. No need to go to name space to explain your nickname. It's rather obvious why it suits you.

        What's the difference between "perl" and "Perl"?

        Also note that I'm not aware of any trademark on Perl or perl. There is a trademark held by O'Reilly on the camel as a symbol of Perl. There are trademarks held by The Perl Foundation on a number of logos for Perl with an onion on them. (In those trademarks the name is capitalized.) But to the best of my knowledge, the actual name of the language is not trademarked.

Re: perl not omnipotent? let's see!
by GrandFather (Cardinal) on Oct 13, 2005 at 03:54 UTC

    If it is computable then any Turing complete language can compute it. Ook! is Turing Complete (appart from issues of memory size) and I can write an Ook! interpreter in Perl thus Perl (by using the Ook! interpreter) can compute anything computable.


    Perl is Huffman encoded by design.
      If it is computable then any Turing complete language can compute it.

      ++ to you, GrandFather - when all is said and done, they can all do essentially the same thing. The choice is a matter of practical considerations.

        ...which is what the 'p' in Perl stands for.

        -M

        Free your mind

Re: perl not omnipotent? let's see!
by Moron (Curate) on Oct 13, 2005 at 12:27 UTC
    Well sorry monks, but most of who responded clearly failed to even try to meet this challenge. What I was hoping for, amongst other opportunities to show your abilities outside of being able jumping to conclusions, was more understanding of the fact that Perl does not exist as an island entire of itself but can be used to control foreign functionality to get results more effectively than other languages can which don't lend themselves to such easy communication between functional layers. A good example of this principle in action where you might expect instead to see assembler or C instead is how the CPAN module dvd::rip was written.

    -M

    Free your mind

      So, what is it that DVD::rip is using that can't be done in C, Python, Java or Ruby?
      Perl --((8:>*
        Not a question I am begging an answer to, but what I will say is that everything can be done in assembler, but that doesn't mean it should be.

        -M

        Free your mind

      Well, as GrandFather pointed out, there isn't anything that one language can do, that another can't. The exercise reduces to proving Turing's Halting Problem, which Turing already proved. So yes, your original idea is OK - Perl can do whatever any other language can do. We've known this for something like seventy years (except, of course, Perl hasn't exited all that time).

      UPDATE: As Tilly has pointed out, this has nothing to do with Turing's Halting Problem. It has to do with Church's Thesis (thank you, Tilly, for correcting me).

        Some of the replies have already cited examples which suffice to show that just because something is computable doesn't mean it's feasible, for a given Turing-complete language.

        -M

        Free your mind

        Um, no.

        Turing's Halting Problem is about the impossibility of writing a program that can figure out whether another program will or will not halt on given input.

        The result that you're referring to is variously known as Church's thesis, the Church-Turing thesis, Turing's thesis and Church's conjecture. There are many minor variations, but they all boil down to, "Anything that can be computed, can be computed on a Turing machine." This statement is unproveable because "can be computed" is undefined. However it is generally accepted, and holds true for every reasonable definition of "computed" that anyone has been able to come up with.

Re: perl not omnipotent? let's see!
by Anonymous Monk on Oct 16, 2005 at 17:21 UTC
      I have read this reply but see no further comment as being necessary.

      -M

      Free your mind

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://499558]
Approved by thor
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chanting in the Monastery: (8)
As of 2014-12-28 23:28 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (183 votes), past polls