develooper Front page | perl.perl6.language | Postings from June 2007

Pod 6: ease of implementation vs easy of use

Thread Next
From:
Damian Conway
Date:
June 16, 2007 16:21
Subject:
Pod 6: ease of implementation vs easy of use
Message ID:
46747071.9020407@conway.org
I'm not going to argue about the design of Pod 6 any more. As both Mark
and brian have pointed out, this really comes down to philosophical
differences that no amount of discussion is going to resolve. In any
case, I'm sure that Larry now has plenty of "grist" from which to mill a
final specification of how the Perl 6 documentation mechanism will work.

I will, however, take a moment to answer the accusation that I appear to
have redesigned Pod the way I did in order to make implementation
easier...and at the expense of making life harder for programmers and
educators.


It's hard to believe anyone could think I would ever do that. It's
almost as if the they don't know me at all.

 From the very first day I became part of the Perl community (August 18,
1998, when I presented Getopt::Declare and Lingua::EN::Inflect at the
Second Perl Conference), my entire philosophy and purpose has been to
make things *easier* for users of Perl, no matter what that did to the
complexity of the implementation.

Every serious module I've ever written over the subsequent decade has
had that same characteristic and intended function: Attribute::Handlers,
Class::Contract, Class::Multimethods, Class::Std, Config::Std,
Contextual::Return, Filter::Simple, Getopt::Euclid, IO::Prompt,
Module::Starter, NEXT, Parse::RecDescent, Regexp::Common,
Smart::Comments, Switch, Text::Autoformat...etc., etc.

Indeed the term "a Damian module" is now widely used to mean "software
that makes your life easier...until you actually try to read the source
or understand the implementation". :-)

I've always been quite proud of that...since that description is pretty
much the definition of the perl interpreter itself. I always felt that
meant I was doing my job right.

I've also lectured and taught academic and professional classes on
interface design for several decades now, and always with that same
basic message: make life easier for the user, no matter how much that
complicates the implementor's job.

Certainly, anyone who has sat in on a Perl 6 design meeting will tell
you that I've consistently argued that way; frequently to the point of
aggravating those courageous souls who are charged with the task of
implementing Perl 6.


So it actually *hurts* me that people might think I would ever
compromise on usability, just to facilitate implementability. Please
read what I wrote again. I *did* claim that "easier to implement" was a
nice side-benefit of my design...but only because I was directly
responding to brian's question about Pod 6's adaptability to other
programming languages.

I *never* said ease-of-implementation was a major consideration, of a
motivation for, or even a significant argument in favour of, the
original design. My entire argument for separated Pod is based on
promoting the prominence and readability of Pod documentation by
distinguishing it lexically, rather than syntactically.


Enough. I will now get back to designing the new A<> formatting code
('A' for *A*lias to *A*mbient *A*rtifact), which I'll preview early
next week. Though I'm sure people won't like that new feature either,
since it's going to be designed using the same "separated model"
philosophy. ;-)

Damian

Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About