And hence, what then happens (in other programming languages) is that we make the users specify exactly when and how to cache the translation from the programming language to the intermediate language. And that would make Perl distinctly less "human friendly" for me. I'd hate having to develop a "makefile" for every Perl program I write. Those systems typically also separate the "compilation" environment from the "execution" enviroment, losing some of the meta information (like the names of all methods in this class), and losing the ability to "compile" while "executing" for some neat tricks.
No, I like the current system. When I don't need caching of the translation (which is what your "compilation" seeks to do), I can use Perl by simply saying "go". When I've decided that caching helps, I can do that explicitly using the mechanisms I gave earlier.
To force caching on all users is a premature optimization, which is an evil step.
For example, I'm developing a few applications for clients right now in CGI::Prototype. The eventual application will likely be executed in a mod_perl environment, but I'm running it as CGI because I don't want any caching to interfere with my clean-slate testing, especially as I tweak various parts that will eventually be cached. The fact that Perl lets me do this makes my development time shorter, not longer. (And in fact, some parts of CGI::Prototype are possible only because I can blur the lines between "compilation" and "execution", so I have a richer framework to do my work, even if I use those features only indirectly.)
-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.
In reply to Re^2: Perl: friend or foe ?
by merlyn
in thread Perl: friend or foe ?
by MonkPaul
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |