Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine
 
PerlMonks  

What Perl CAN'T do?

by sanPerl (Friar)
on Dec 14, 2005 at 08:48 UTC ( [id://516556]=perlmeditation: print w/replies, xml ) Need Help??

Gurus,
My question here seems somewhat negative. But really speaking I would like to check if Perl can challenge any language in the world. Personally I am convinced that everything can be done in Perl. for .e.g.
In case of Pattern Matching Perl is better than Omnimark
In case of Front-Ends on Windows, Perl Tk is as good as VB
Perl CGI is as good as ASP
In case of any other application which C /Java do, Perl can also do it as well (You can use C code in Perl, which improves it's strength)

May be is some other PL is taking less Loc to code, Perl would take more Loc, but I think Perl can do all kinds of jobs. So can someone tell what Perl Can't Do, which any other PL is doing right Now?
All kinds of Criticism is welcome

Update:
I agree with serf and lot of people that, it is Not advisible to do Lot of things in Perl, but my question is (it may sound crzay)
if you are given only 'Perl' and told to work on any assignment, irrespective of loc/complicated designs then what are the things which you (or rather Perl) would Not be able to do at all.

Replies are listed 'Best First'.
Re: What Perl CAN'T do?
by serf (Chaplain) on Dec 14, 2005 at 08:58 UTC
    It's not very likely that people are going to one day choose to write boot loaders in Perl...

    And it would have to be some desperate and twisted evil foo hackery that would code an entire operating system kernel in perl (that could run stand-alone). Perl device drivers do not sound like a Good IdeaTM.

    There are some jobs that are always going to be better written in assembler (or perhaps C)

    What is your perl binary written in, and why?

      AFAIK it's possible to write linux kernel modules in Perl. It's probably a blessing for prototyping...

      Another interesting thing I just discovered today : http://www.genezzo.com/. An "enterprise strength" RDBMS, with clustering and other high-end features, entirely written in Perl.

      And then there's that CAD application prototype written in perl, Puzzle Bobble, and some others... Well, actually it seems anything can be done in Perl after all :)

        It could be written, but I'm not so sure a real kernel module could be run in Perl. Kernel modules run in one of the processor's privileged modes, which are the sole possession of the kernel. Perl-as-she-is runs in user mode and I don't know how to make the kernel do it any differently.

        A "user-level driver" is a different story. Perl has ioctl for that, and it works well. I once wrote pieces of one and I'm very proud of it, even though it's still incomplete (ran into integer width trouble). It's the only time I ever wrote anything with ioctl.

        After Compline,
        Zaxo

      And it would have to be some desperate and twisted evil foo hackery that would code an entire operating system kernel in perl (that could run stand-alone). Perl device drivers do not sound like a Good Idea.

      I did once moot the idea of turning Parrot into an operating system. But Parrot ne Perl after all.

      --

      Oh Lord, won’t you burn me a Knoppix CD ?
      My friends all rate Windows, I must disagree.
      Your powers of persuasion will set them all free,
      So oh Lord, won’t you burn me a Knoppix CD ?
      (Missquoting Janis Joplin)

Re: What Perl CAN'T do?
by strat (Canon) on Dec 14, 2005 at 09:13 UTC

    I think perl (especially in combination with XS) can do nearly everything. But some things don't make sense because there exist faster solutions, e.g. 3D programming (Corion showed me at the last frankfurt-pm-meeting that it can be done, but it isn't very fast; a 3D shooter like quake wouldn't give enough frames per second to be comfortable enough on a common PC) or system drivers.

    Btw: Perl/CGI usually seems to be a little bit slower than ASP, but you can probably use mod_perl. And comparing Perl/Tk to VB is a bit like comparing oranges and plumns, since AFAIK in VB you can only use objects, whereas in Perl you can create your own ones (may have changed with .NET, I don't know). And often, the VB-GUI looks more like a windows application than Tk where some widgets look ugly, e.g. Tk::Notebook or Tk::Combobox. But if that is essential, you can as well use wxPerl instead of Perl/Tk)

    Best regards,
    perl -e "s>>*F>e=>y)\*martinF)stronat)=>print,print v8.8.8.32.11.32"

      a 3D shooter like quake wouldn't give enough frames per second to be comfortable enough on a common PC

      If it was limited to using the CPU only, the recent Quake games couldn't work in C/ASM, either. You have to offload operations to dedicated 3D hardware to get Quake-level graphics. You need underlieing library support to take advantage of GPUs, which Perl has.

      In the game I've been writing in Perl (2d sprites, not 3d), the biggest CPU-hog is collision detection. I'm using a rather naive algorithim (every object tested against every other object), so it does a lot more work than it needs to. With offloading some of the calculations into C code, the game is playable on my 2.2 GHz Celeron laptop (but only just so in some spots). In pure Perl, it's easily playable on my Athlon64 3200+ (2.0 GHz) desktop.

      Fortunately, collision detection shouldn't be difficult to paralleize (at least from what I've seen so far), so this is an area that can take advantage of multicore processors. Also, there has been some research on using GPUs for collisions.

      "There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

        One very simple way to optimize collision detection is to sort the objects by pos.x (or y) first. Now you know a lot more about which objects are in proximity.

        I'm sure there are really clever rocket science grade algorithms for this too :)

        /J

        Well, then it should run as good as under perl, shouldn't it?

        Best regards,
        perl -e "s>>*F>e=>y)\*martinF)stronat)=>print,print v8.8.8.32.11.32"

Re: What Perl CAN'T do?
by GrandFather (Saint) on Dec 14, 2005 at 10:34 UTC

    It's not so much what Perl can't do, as what can be done better other ways. Other replies have pointed out that Perl doesn't play so well close to the metal.

    Actually Perl doesn't play so well at the other end of the programming spectrum either - 1,000,000 line applications would be somewhat difficult to manage in Perl. And there are real applications that are 1,000,000 lines long because they have to be, not because they are so poorly written that in a realTM language like Perl they would be only 10,000 lines, but because that is a fair representation of their required complexity. Even 10,000 lines of Perl would take a bit of taming. :)

    The answer to your updated question is: almost anything dealing directly with the computer hardware without assistance from the operating system. Things like kernel code and device drivers. Bear in mind too that a lot of the "good stuff" in Perl is provided by modules and much of the really fast good stuff is XS code - that is written in C, so isn't really Perl at all in some sense.


    DWIM is Perl's answer to Gödel
      Actually Perl doesn't play so well at the other end of the programming spectrum either - 1,000,000 line applications would be somewhat difficult to manage in Perl. And there are real applications that are 1,000,000 lines long because they have to be, not because they are so poorly written that in a realTM language like Perl they would be only 10,000 lines, but because that is a fair representation of their required complexity. Even 10,000 lines of Perl would take a bit of taming. :)

      This is completely contrary to my experience. A million lines of code in ANY language takes quite a bit of process to do successfully. I should know - I've written and managed 2.2M lines of code by myself. As for 10k lines of code (in any language) - that's quite easily handled by 1-4 programmers.

      As for complexity of Perl applications - 90% of every Perl application you, personally, will ever really want to write is either already on CPAN or will be in the next year. So, really, you're only writing 10% of what you would have to write in any other language. Couple this with the 10-1 LOC difference between Perl and most other languages and my 10KLOC is your 1MLOC. All of a sudden, it's not so hard to manage 1MLOC.


      My criteria for good software:
      1. Does it work?
      2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
        90% of every Perl application you, personally, will ever really want to write is either already on CPAN or will be in the next year.
        Yeah, and 95% of every C application I will ever write is already in the standard libraries.

        The availability of handy libraries doing all kinds of work for you isn't something that's unique to Perl. It predates the existance of Perl. What sets CPAN apart is its role as a central repository.

        Perl --((8:>*
        dragonchild,

        Have you actually written a 2.2MLOC application ? Sounds like terribly lot... What does it do ?

        Or did you include the used CPAN modules' code in your count :-) ?

        90% of every Perl application you, personally, will ever really want to write is either already on CPAN or will be in the next year.

        This is true, but only because I rarely find myself writing Perl applications because I really want to write them. Were it not for that caveat, that hasn't been true in any of my years of writing Perl, and I doubt that it will be true this year, either.

        Perhaps I am just unlucky, or don't know where to look on CPAN for what I need, but I doubt that's it. Instead I think that it is because I wind up writing a lot of programs that are very specific to my local environment, and are solving problems that nobody else is interested in. Which is why I get paid, because I am doing stuff that I wouldn't do if I wasn't getting paid, and nobody else would do either.

        For instance no matter how long I wait, I doubt that anyone will put on CPAN any of the reports that I need to write next week, all of which are very company specific.

        Also I would like to point out that the 10 to 1 productivity differences with Perl are relative to very low-level languages, like C. Even a language like Java closes a significant fraction of that gap. Plus I don't believe that Perl is significantly more productive than, say, Python or Ruby. (In fact I believe that Ruby is actually more productive than Perl!) However I'll also admit that it is hard to find many real-world examples of really long programs written in highly productive languages.

Re: What Perl CAN'T do?
by tirwhan (Abbot) on Dec 14, 2005 at 09:09 UTC

    perl cannot be written in Perl (this statement will automatically self-destruct when Perl6 comes out. Your mission, should you choose to accept it, is to assist in bringing about this event as soon as possible.)

    See this thread for more answers to your question.


    Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian W. Kernighan
      perl cannot be written in Perl
      If your statement is true, Perl is a less powerful language than say, BASIC or Cobol. See, perl is written in C, a Turing complete language. BASIC, Cobol, and almost any serious language (with the exception of some very domain specific languages) is Turing complete, which means that anything that can be done in one language, can be done in the other.

      perl is written in C. Hence, perl can be written in BASIC and Cobol.

      Luckely, your statement is false. Perl is a Turing complete language, and hence, perl can be written in Perl.

      Perl --((8:>*

        The OP's question does not make much sense when viewing it from a theoretical point of view (as anyone who understands Turing completeness knows and your post explains). I can as much write perl in Perl as I can carve my name onto the face of the moon with a toothpick or tattoo "I blow goats" onto the forehead of my least-favourite head of state. Both of these things would be possible if I dedicated my life to them and managed to obtain the support of a large enough community of people. I would however consider them to be practical impossibilities. Rewriting perl in Perl has pretty much the same prerequisites and is just as impossible. Do feel free to prove me wrong though :-)


        Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian W. Kernighan
        That is an interesting point there Perl Mouse...I honestly had no idea that perl can be written in perl. Funny thing is I was pondering that fact just the other day. Thanks for the statement. This being said, what other languages besides C and Perl are able to be written with their own syntax?

        "Es gibt mehr zu Leben als Bücher, kennen Sie. Aber nicht viel mehr " -(Der Smiths)
      perl cannot be written in Perl

      Yes it can. There is nothing from stopping you writing a bootstrap parser and eventually creating a self-compiling Perl parser+runtime written in Perl. But, and this is the 2**16 dollar question.... why would you want to do a thing like that?

      (For those following along at home who can make no sense of this dialog, the language is Perl, and the interpreter that interprets said language is perl).

      One thing I do know... Perl should not be used when speed is of the essence. I'm currently stress testing Regexp::Assemble. I started the run last Friday afternoon on a hexaprocessor box. The run has performed about 147 million combinations as of right now (more than 4.6 billion unit tests), a grand 7% of the problem space...

      On the plus side, the run hasn't turned up any bugs.

      • another intruder with the mooring in the heart of the Perl

        There is nothing from stopping you...

        Here are a few things that would hold me back:

        1. It would be hard to find others who also want to work on such a project (cause, as you say, 'why?')
        2. With a minuscule team of programmers my development speed will likely be slower than that of the mainstream C perl, therefore I'm writing towards a target that's moving further away all the time.
        3. Even if I try to write towards a fixed and existing version of perl5 I'll likely not be finished in my lifetime (and if I do nothing but hack on Perlperl all day my lifetime will be even more finite that it is anyway)

        You're right, there's nothing in the design of Perl that makes this task impossible in theory, but I'd be willing to bet all the money I own that it is impossible in practice. (Note to prospective punters: it's not very much money :-)


        Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian W. Kernighan

        Thats an interesting comment. Why are you running 4.6 billion unit tests? What behaviour are you testing that requires so many tests? (Note that you are doing about 4.6 billion more tests than perl itself does when testing the regex engine during a build.)

        ---
        $world=~s/war/peace/g

      It depends. Are you allowed to use eval? ;-)
      Python could be written on python, but perl can not be written in perl?

      I disagree - those are languages with approximately same capabilities and general ideas.

      However, your following discussion makes me agree with you on other points, so ++ to you.

      Best regards,
      Courage, the Cowardly Dog

Re: What Perl CAN'T do?
by mattr (Curate) on Dec 14, 2005 at 14:03 UTC
    I am about to test this myself but it sounds like you cannot do a massively threaded perl app on windows. On the other hand this is not a Perl problem. :)

    XEmacs still runs in lisp for me and I am not sure if it could be converted into perl before the universe ends but theoretically it can be done.

    Time constrained problems sound like the biggest issue, for example Van Eck Phreaking or high quality real time audio synthesis would be challenging but on the other hand with a suitable C library and interesting hardware both might be within arm's reach. I am pretty sure though that I will not ride a rocket with an engine written in perl though.

    I like wxPerl but I think it needs another layer of laziness proofing on top of it to be "insanely great", i.e. you still have to tell the pesky computer what to do. I tend to agree with you but perl would be closer to the insanely great end of the spectrum if it included some AI, natural language directed automatic code generation, whiz bang graphics, and free hardware. But it is still pretty great anyway.

    Anyway don't let anyone tell you there is anything Perl can't do, it is probably just a matter of them not using strict.

Re: What Perl CAN'T do?
by dws (Chancellor) on Dec 14, 2005 at 17:28 UTC

    if you are given only 'Perl' ... what are the things which you (or rather Perl) would Not be able to do at all.

    I would think (and experiment) for a long time before I'd even consider tackling hard realtime problems with Perl (or Ruby, or Python, or even Java).

Re: What Perl CAN'T do?
by Anonymous Monk on Dec 14, 2005 at 16:09 UTC
    Perl can't be as buzzword compliant and politically correct as Java and .NET, unfortunately :) It also can't NOT be open source. Both of these things are wrong, but these are why other things are used sometimes.
Re: What Perl CAN'T do?
by SolidState (Scribe) on Dec 15, 2005 at 06:41 UTC

    Here are the 3 things which I think you can't do in Perl:

    1. OS kernel - A complete OS kernel can't even be written in pure C, you have to have assembler code for the really low-level/device-specific stuff. So certainly I would say a higher level language like Perl cannot be used by itself to write a kernel.
    2. Real-Time - Perl is slow, because it isn't C. In most apps, you could argue that "maybe you wouldn't want to do it in Perl, but you could, if you wanted to". However, in real-time apps, there is no such option - if the app can't work fast enough, it isn't real-time...
    3. Embedded - Perl will never be the laguage of choice for writing embedded apps. I'm not talking about WinCE apps, I'm talking embedded - those really really tiny apps, where every byte counts. Nowhere to cram perl, or accomodate the overhead of a high-level language...

    Now, it could be argued that with XS and/or inlined code you could do the first 2 of the above (I see no way to get past the space limitations of embedded apps), but at what point does that code stop being Perl and start being C/Assembler?

    Last but not least - I don't care that Perl can't do those things. I love Perl for what it can do, not inspite of what it cannot do :)

      your 2nd and 3rd points are very questionable.

      Very often Perl is more real-time than C.
      Agree with me or not, but I saw several times a discussion when it appears that GCC is incapable to compile some large autogenerated programs, because it uses O(N*N) in many places. Therefore people bother splitting such sources to chunks.
      Ideal programmer will create faster programs in C, but real-world programmers often write

      for (i=0; i<strlen(s); i++) { // and never notice that counting lentgth is on every iteration }
      It is unrealistic to use advanced techniques on C everywhere,
      in perl it is often hard to write bad: you often save precalculated values in hash, and so on.

      As for 3rd item - embedding perl into different application is very common practice (well, cases when bytes count are exclusion, but those are rare, IMHO).

      These aren't faults of the language, these are faults of the implementation. There is nothing impossible about writing a compiler for Perl to machine code, or constructing a chip that natively executes (!!) Perl.

      Assembly (of all kinds) and Perl are both Turing complete, so anything written in one can be written in the other, theoretically.

Re: What Perl CAN'T do?
by runrig (Abbot) on Dec 15, 2005 at 01:39 UTC
Re: What Perl CAN'T do?
by chanio (Priest) on Dec 15, 2005 at 04:46 UTC
    Let's see...

    Perl is like painting a masterpiece with a thick brush. Everything can be done! And if you are skillful you could get extraordinary results.

    What is most important in perl is what brother Merlyn always mentions: the luck of counting with universal readymade-experience that you can always achieve just by downloading one of CPAN's modules. Thanks to this, you don't need to be an expert in networks (for example) to program about such subject. You only need to trust that the modules work as expected.

    Years ago, when programing in Assembler, I used to build my own libraries to simplify the job. Then I thought that giving those libraries the same names as perl commands, I would have had my own perl version. Now, if you have such assembly libraries managed by perl, you would be able to program in assembly with perl. So, you would be able to do anything with perl!

    I mean, how close to the machine do you need to be to program certain job? That is the real question.

Re: What Perl CAN'T do?
by Perl Mouse (Chaplain) on Dec 14, 2005 at 10:59 UTC
    Perl is a Turing complete language, so anything that is computable can be computed in Perl as well.

    About the only thing that's problematic are the cases where you need to run native machine code, like boot loaders. But that's more due to the lack of a compiler - not so much the lack of certain language features.

    Perl --((8:>*
      Perl is a Turing complete language, so anything that is computable can be computed in Perl as well.

      If you are willing to wait an infinite amount of time, expend an infinite amount of memory, and restrict your I/O needs to nothing more complex than an infinitely erasable paper tape, then, yes, Perl can "compute anything". That's a rather limited view of "anything", in my opinion. :-)

      In the real world, we have real-time applications; Turing-completeness cannot speak to such requirements. Similarly, when trying to access memory mapped I/O, Perl has no native facility that I know of to write to specific memory locations; whereas other languages do. (Even BASIC has it's PEEK and POKE statements!) In Perl, we fall back to using C via XS instead; there is no native "POKE" statement, though unpack with pointers can be used to emulate a "PEEK".

      Unless I'm mistaken, this is something that native Perl can't do.

        I think you've missed the point of the original question, which was really about choice of language environment, i.e. how to choose between Perl, Java, C#, etc. I would argue that Perl is a stronger choice, as a language environment, than Java at least, because it is so easy to drop down to the metal (using XS) when the need arises.

        We're building the house of the future together.
Re: What Perl CAN'T do?
by spiritway (Vicar) on Dec 15, 2005 at 06:23 UTC
    if you are given only 'Perl' and told to work on any assignment, irrespective of loc/complicated designs then what are the things which you (or rather Perl) would Not be able to do at all.

    Quick answer: yes, but in that case, you wouldn't be able to do it in other languages, either. This ignores the time required to do the job. As several others have pointed out, Perl could well be too slow for certain time-critical applications.

Re: What Perl CAN'T do?
by Qiang (Friar) on Dec 15, 2005 at 17:09 UTC
Re: What Perl CAN'T do?
by adrianh (Chancellor) on Dec 20, 2005 at 10:57 UTC

    So can someone tell what Perl Can't Do, which any other PL is doing right Now?

    See Re: [OT?] Other Languages for my reasons for not using Perl.

Re: What Perl CAN'T do?
by kulls (Hermit) on Dec 15, 2005 at 05:59 UTC
    perl can't die. May be it failed here!. Realistically all computational genomic process done through perl.so it's living with us.
    -kulls
Re: What Perl CAN'T do?
by Anonymous Monk on Dec 15, 2005 at 18:47 UTC
    I think it's impossible to write an operating system in Perl because Perl does not contain any syntax to manage privilege levels. If the applications of this hypothetical operating system would be written in Perl too it could be possible to dispense with privilege by using lexicals. But there are no constructs in the language to deal with interrupts. And that is fatal even to a pure Perl operating system. BTW I think someone had (for a laugh) compiled perl as a linux kernel module. Has anyone URLs?
Re: What Perl CAN'T do?
by Anonymous Monk on Dec 14, 2005 at 21:57 UTC

    Stupid question. Most of the modern languages can deliver the same stuffs.

Can Perl (without XS) write to a specific machine address?
by Anonymous Monk on Dec 19, 2005 at 17:13 UTC
    If I have a bit of memory mapped hardware, how do I get Perl to access that hardware, without resorting to XS, or otherwise stepping outside the language features described iin the perlfunc and perlop man pages?

    I can't think of a way -- even a bad one. Is there one?

    Ytrew

      The question is not fair.

      In any language, unless you are programming in the kernel, you will require the mmap system call in order to access memory mapped hardware. By restricting to what's described in the perlfunc and perlop manpage, you are forbidding use of mmap.

      So notwithstanding your restriction, it's actually just as easy to do in Perl as in C: In C, use mmap(), in Perl use Sys::Mmap.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://516556]
Approved by Corion
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others avoiding work at the Monastery: (4)
As of 2024-12-12 16:36 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Which IDE have you been most impressed by?













    Results (65 votes). Check out past polls.