2000-08-08-04:42:00 Leon Brocard:
> Martyn J. Pearce sent the following bits through the ether:
> > I use this in one-liners, and it's _dead_ handy
> 
> May I suggest that Perl6 will be a different language?

If perl6 substantially fails to fill the important roles that perl5
fills, we should stop screwing everybody up by calling it "perl",
and call it something else.

The project name "perl6" carries a presumption in most folks' mind
that this language is intended to _replace_ perl5; that after it
goes live with a stable production release, there probably won't be
much further active development of perl5, and after a few more years
at most will die off. If we intend to abandon that goal, then let's
also abandon the name perl6. I'm sure there are plenty of other
semiprecious gemstones left that haven't been claimed by languages.
Or we could use a snake, or a comedy troupe.

> I've seen the "I use it, don't change it" argument a couple of
> times now and it's not a strong enough argument.

Alone, it's not. That's why it should be accompanied by a
description of _how_ the arguer uses the feature, with the intent of
indicating how valuable it is. That lets the readers make their own
judgement about whether the feature merits removal.

The poster you are replying to said "I use this in one-liners, and
it's _dead_ handy."; that conjures up the idioms like

        perl -nle 'print if 1.. ?^$?' [filename]

which barfs out only the header; replace "if" with "unless" and it
chops the head off.

And don't forget that the poster, who you were responding to,
finished up by saying:

> > Of course, if it's modularized as Dan suggests, which has no
> > effect at language level, I wouldn't be unhappy.

I.e. while it's useful, the use doesn't carry performance demands
sufficient to make a demand that it remain in the core; the poster
would be content if it were factored out into a loadable extension
module.

> The whole point is to clean up the language.

There are many intents and points to this project. As _I_ see them,
they include, in no particular order:

- cleaning up the language definition, where practical without
  losing the distinctive appeal of perl to happy perl programmers;

- cleaning up the implementation, to better support further growth,
  and possibly allow perl to better penetrate other areas (e.g.
  embedded applications);

- cleaning up the development process, to allow people who wish to
  focus on specific aspects of perl development to more easily
  concentrate their attentions; and

- adding fundamental new features to allow perl to better support
  new and different ways of programming, and new application
  domains.

-Bennett

PGP signature

Reply via email to