http://qs1969.pair.com?node_id=11127951


in reply to Re^3: Performance penalties of in-Perl docn vs compiled CGIs.
in thread Performance penalties of in-Perl docn vs compiled CGIs.

I like one of the comments below your linked post which points out what's really important in this distinction: interpreted language can be extended ad-hoc, eg. eval. That's a lot of flexibility.

  • Comment on Re^4: Performance penalties of in-Perl docn vs compiled CGIs.

Replies are listed 'Best First'.
Re^5: Performance penalties of in-Perl docn vs compiled CGIs.
by LanX (Saint) on Feb 05, 2021 at 21:57 UTC
    What if we bundled the executable of a "compiler language" like C or Go with a compiler?

    Why shouldn't it be possible to do that?

    And "eval"-ing would mean to run a make process leading to dynamically linked and executed code?

    According to you this would define an "interpreter", right? :)

    Cheers Rolf
    (addicted to the Perl Programming Language :)
    Wikisyntax for the Monastery

      no, that would amount to shelling out, like with system(). eval'ing shares (edit: parent) program state, variables and can also influence/modify these.

        > that would amount to shelling out,

        If you realized it today, yes.

        You could implement it as internal feature.

        Nobody does, because the benefits of eval wouldn't justify the costs of a much larger binary.

        Cheers Rolf
        (addicted to the Perl Programming Language :)
        Wikisyntax for the Monastery