in reply to What Perl CAN'T do?

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 :)

Replies are listed 'Best First'.
Re^2: What Perl CAN'T do?
by Courage (Parson) on Dec 15, 2005 at 09:37 UTC
    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
}

    [download]
    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).

[reply]
[d/l]
Re^2: What Perl CAN'T do?
by eweaver (Sexton) on Dec 16, 2005 at 19:27 UTC
    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.

[reply]

In Section Meditations