Tom Christiansen wrote:
>
> >I don't understand this desire to not want anything to change.
>
> You misread.
>
> >This is an
> >opportunity to clean up the language, make it more useable, and more fun.
> >I would have a lot more fun if perl were a better performer and if it was
> >easy for me to expand it, contract it, reshape it, improve it, etc.
>
> Bah. You start from false premises, and go on to fantasize
> bucolically about motherhood and apple pie.
>
> You will *not* improve the performance of the inner interpreter
> loop by having fewer opcodes to switch on. Whether the number is
> 20 or 200, it's the same thing--*think* aboutit. Furthermore, It's
> been demonstrated that this supposed "gain", including in size, is
> negligible. I have yet to see one iota of justification for denuding
> perl of its math functions. If math functions should be removed,
> then so too string functions. And that binmode silliness is in
> line before any of them, since it's absolutely useless because I
> never use it.
>
> See what I mean?
>
> Perl is *not* fun when it supplies nothing by default, the way C does(n't).
>
> If you want a language that can do nothing by itself, fine, but don't
> call it Perl. Given these:
>
> * Scalar manipulation
> * Regular expressions and pattern matching
> * Numeric functions
> * Array processing
> * List processing
> * Hash processing
> * Input and output
> * Fixed-length data and records
> * Filehandles, files, and directories
> * Flow of program control
> * Scoping
> * Miscellaneous
> * Processes and process groups
> * Library modules
> * Classes and objects
> * Low-level socket access
> * System V interprocess communication
> * Fetching user and group information
> * Fetching network information
> * Time
>
> Your brain-damaged Perl would likely end up having nothing in it but these:
>
> * Flow of program control
> * Scoping
>
> Anything else would be fobbed off into back-of-the-bus modules.
>
> But I tell you this: your whole language will get fobbed off as
> a pain in the royal ass.
>
> Since day 1, perl has been useful because it's had so much in it.
> You don't want a language with a whole bunch of the commonly needed
> functions *already* in it, fine -- but it's not going to be perl,
> and it's not going to be useful.
>
> --tom
I would like to see a set of "requirements" that make Perl what it is.
I think we all have a vague idea of what makes Perl great, but I'm also
sure there's a lot of variation. With a SHORT list of requirements, it
becomes much easier to address some of these issues that are radical
changes to the language.
Here are some possibilities for inclusion in such a list:
native pattern matching;
list manipulation
aweswome text processing.
It's application glue (thanks Tim)
Is this an reasonable idea? and a reasonable start?
--
David Corbin
Mach Turtle Technologies, Inc.
http://www.machturtle.com
[EMAIL PROTECTED]
