My point of view is from the flexibility and power offered by the eval feature: how much does it add to the power of the language. I agree, there are other costs (including Security). But I am focusing on the power offered. My thinking there is: in the future we will all be friends and the aim will be to max out the power of computing and not to protect from script-kids. If we don't manage that (i.e. all friends) we will waste 99% of resources in security and anything else will be second. Fastest way back to the Cave.

Eval is a very strong feature. It's a qualitative factor weighting for the interpreted languages which I, C being my alma-mater, thought are inferior and sloppy and just glue. I stress again my previous point: eval can share and modify "parent" program's state. Although I know eval for many years, pondering about its internals happened to me only lately while I am attempting an android app. Typical "taking for granted". In android universe, there are "activities", screens of the same app basically, which have no way by default to share state with other activities, part of the same App. You have to resort to serialising objects back-and-forth manually and with stupidly lame putString(), putBoolean() methods (I am at the beginning still, so I may find something more productive). But AFAIK primitive and insane.

With eval, a script can run all the scripts in the world and pass state to them forming a huge single-memory-space super-program. Sure you can shell out and pass state via command-line params or serialise it into files. Restrictions though apply. But with eval you can extend your program on-the-fly, as already pointed out, but with preserving its state still! Code improvement with Genetic Programming and eval for example. Although, again AFAIK (which is not much), is not happening with a (edit: compiled) program which already is running and tries to improve itself by modifying parts of it, as it runs. Sure, in a compiled language you can emulate eval by dumping state to disk, appending eval code to the original source code, recompile, run, load state from disk. With a HUGE caveat: hope that new executable and past state are compatible.

Nope, the future is interpreted.

bw, bliako

In reply to Re^8: Performance penalties of in-Perl docn vs compiled CGIs. by bliako
in thread Performance penalties of in-Perl docn vs compiled CGIs. by phirun

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.