* On Wed, Jul 02 2008, Aristotle Pagaltzis wrote:
> On this, I disagree.
>
> Here’s litmus test: would you ever use the opposite adjective in
> a description? If not, it’s not useful. I think you’ll agree that
> no one would call a module Exception::Complicated except as a
> joke. That means “easy” provides no useful differentiation in
> practice.
I don't think this tests what you think it tests. People don't name
their module Foo::Complicated because they don't want to admit the
interface is complicated. People *do* call modules Foo::Easy because
they're proud that they made Foo easy. So the module naming here
reflects the author's personal or societal hangups, not the validity of
any naming scheme.
> In fact, the “simplified” in “simplified interface” is largely
> redundant. Using an interface by definition means you are looking
> for simplification in doing or accessing the thing that the
> interface provides.
Easy means "less features to learn". Ever use XML::LibXML? It's big.
It's hard to get started with it. If you just wanted to XPath some XML
string, you might like a module like XML::LibXML::Easy to exists.
Instead of creating a parser, parsing a "balanced chunk" into a
"document fragment", initializing the XPath engine, adding some
namespace, running the query, and then printing the returned nodes; you
might just want to say 'xml("<foo>")->xpath("//foo")->stringify'.
That's not nearly as complex as XML::LibXML, so why not call it "Easy"?
Of course, you lose a lot of power with that API. Tradeoffs.
> Similar words that say something without communicating anything
> are “fast” and “flexible.” No one would say that they are trying
> to achieve slowness or inflexibility.
Usually the slow/inflexible version comes first, so it gets the base
namespace. If history could be rewritten, then the slow version would
be replaced with the fast one... but that's not always possible,
especially with how CPAN.pm works.
Basically, the names of CPAN modules are hacks around CPAN itself.
> I see a trend here… you are the person who argued loudly that in
> the end, anyone who wants to know how Catalyst works needs to
> read the code, regardless of the state of the docs…
I'm not sure why this upsets so many people. If you want a complete
understanding of every detail of a codebase, you have to read it.
You're not going to get any better at programming if you never read
code. This is what I believe and I'm going to stand by it. (If you
don't want to be good at programming, that's fine with me. Give me some
money and I can solve your programming problems for you :P)
Anyway... if you don't want to read the code, I hear there's a whole
book about Catalyst.
> Then again, you are the author of a Catalyst-based weblog app
> called Angerwhale, which makes me wonder if you haven’t long
> forfeited your right to take part in *any* discussion about
> naming. :-P
Modules and applications have different naming standards. I think most
of my modules have names that make sense.
I can't think of any applications I use that have names that make sense,
however. "emacs" for editing text? "amarok" for playing music?
"urxvt" for emulating terminals? "irssi" for chat? None of those names
make any sense at all.
So I don't feel like I'm alone in coming up with weird-ass names for
things :)
Names for modules need to be somewhat related to what they do, but you
probably shouldn't devote too much mental energy to coming up with a
name. It's just not *that* important. (Opaque identifiers)++
Regards,
Jonathan Rockway
--
print just => another => perl => hacker => if $,=$"
