I said, at the very beginning of this discussion, that language features can most certainly help with security. I pointed to automatic memory management as making buffer overflows a thing of the past.

The point I'm attempting to make is that you seem to be touting language features as the next step. That isn't the next step. We have language features in Perl for nearly every security hole out there. SQL Injection? DBI placeholders. XSS? Taint. And on and on. The problem is that they go unused.

Do you know the easiest way to break into a computer system? Just ask the person you want to break in as for their password. It's a 50-50 chance that they'll just give it to you if you pose as someone from the helpdesk. This goes for every single person in a company, CEO and CTO down. (Yes, CTO's have been caught by this, too.)

Do you know the most common source of corporate breakins? Disgruntled ex-employees.

Do you know the most common source of security holes in Perl CGI scripts? SQL injection and XSS, both of which have been solved by language features for years.

Except, you cannot force people to use placeholders for all variable substitution because of:

my $sql = <<"__END_SQL__";
SELECT $obj->{name_col} AS name
      ,$obj->{val_col} AS value
  FROM $obj->{table_name}
 WHERE $obj->{id_col} = ?
__END_SQL__
[download]

Did I expose myself to a SQL injection? Can you prove either side? I couldn't, yet that kind of SQL is correctly all the time.