On Wed, Oct 19, 2005 at 03:58:17PM -0700, Nate Wiger wrote:
: Larry Wall wrote:
: >This is one of those accomodations to the real world, like everyone
: >agreeing on a standard URI format. We're really trying to keep
: >these module names close to what you'd see as the name of, say,
: >the corresponding .rpm file. These modules have to have names that
: >work outside of Perl as well as inside, and {...} isn't going to fly
: >in general.
:
: My concern is that we're solving problems that don't really exist in
: real-world Perl usage. Are there really two competing authors of DBI?
: Or, for any product, do two people really try to market "SuperWidget"?
: No, one person just changes to "SuperGadget". And with URI's, one person
: gets "amazon.com". Sorry, name taken.
:
: I think we're actually *encouraging* problems by allowing long, clashing
: names. Pretty soon all DBI modules will have to start with
:
: use DBI:TIMB;
:
: Because "JEFFSTER" decided to upload his DBI (Derivative Binary Index)
: module.
:
: I think it will have the opposite effect of what we're trying to avoid.
I think there can be some kind of community metainformation that sets
defaults appropriately. And if not, the site/project can certainly
establish defaults. On the other hand, a lot of projects do simply
want to specify the version and author explicitly eveyr time,
and they'd rather tweak it by hand (or by script) if they want to
change it, since then at least they know when they need to rerun the
regression tests.
But we put the author last partly because we want to encourage people
not to use that if they don't need to. And the community may choose
to just stick with version numbers and names, and then "author" gets
retargeted as any kind of differentiator you need for occasional but
not regular use.
: >: Not trying to rant (really), but one thing that is starting to bother me
: >: about Perl 6 is that there's lots of changes that require special syntax
: >: for one specific instance. It's making it really really difficult to
: >: remember or generalize, two things that I thought we were trying to
: >improve.
: >
: >Well, you're painting with kind of a broad brush here. If you can
: >point to other areas where we could usefully generalize without
: >getting too abstract for newbies, I'd be delighted to hear them.
:
: The method syntax is starting to make my head spin, for one.
You mean the "pattern matching" characters on the dispatcher? Or the
method declaration syntax? Which part is making your head spin?
: Many things, as a longtime Perl 4/5 programmer and CPAN goon, are
: problematic because we're reusing established operators for completely
: different ideas. From a design standpoint, I feel it's going to hamper
: adoption of the language. People don't have the time (or interest) to
: re-learn that much language, when Perl 5 works fantastic for 95% of
: the cases.
But now you're changing your complaint. If we apply your previous
complaint to this, in many cases we're doing that redesign *precisely*
to fix the thing you're complaining about--too many special cases for
one instance...only it's Perl 5 that's the culprit here, not Perl 6.
In Perl 6 we've greatly regularized the special cases and reserved
most of the special syntax for common cases. Or more precisely, for
what we *suspect* will be common cases in the future, not necessarily
the common cases in the past.
Larry
