According to Flach, Robert: > Could some one explain to me in what way perl is "too complex?" "Using a simple tool to solve a complex problem does not result in a simple solution." -- Chairman Larry Ironically, the parts of Perl that are perceived as "too complex" are sometimes those that are simplest linguistically, which are therefore inadequate to the jobs that people are using them for. Consider modules. Every module author needs to deal with $VERSION, either @ISA/C<use base> or Exporter (and all of its *EXPORT* vars), possibly AutoLoader, etc. The _language_ features involved are all relatively simple. But module creation and management is a complex task. And the result of using simple tools for a complex task is complexity that _every_ module author has to deal with. The same idioms ... or, worse, subtly different idioms ... are being invented and re-invented and re-re-invented, all to no substantial benefit. Therefore, one way I would suggest to simplify the *use* of Perl is to move (most of) the functionality of Exporter into the language. Similarly, piggybacking object attributes onto the existing data structures (arrays and hashes) was a _stellar_ example of cleverly upward-compatible language enhancement. I remain in awe of Larry's ability to put OO support into an already-mature language by adding only a few new features (bless, ref, "->", @ISA, DESTROY), only one of which ("->") required new syntax. However! The objects-are-just-blessed-data hack isn't comfortable for most of the current population of Perl users, who started with OO of some kind and only came to Perl later. The very simplicity of Perl's OO makes it harder to use for complex jobs than it would be if it were a little more elaborate. And C<use fields> just papers over a small part of the issue. In conclusion: Extending Perl may make it much simpler to use. -- Chip Salzenberg - a.k.a. - <chip@valinux.com> "I wanted to play hopscotch with the impenetrable mystery of existence, but he stepped in a wormhole and had to go in early." // MST3K