Wolfgang Jeltsch <g9ks157k(a)acme.softbase.org> wrote:
> The Yampa people and I (the Grapefruit maintainer) already agreed to
> introduce a top-level FRP namespace instead of putting FRP under
> Control or whatever.
The problem with a top-level namespace like FRP is that it is a cryptic
acronym: it means nothing to a novice, and may be easily confused with
other acronyms by an expert. I believe top-level names should _at_the_
_very_least_ be minimally descriptive of the category of things that
live in it.
So, I'd be fine with Control.Reactive.FRP, Control.Reactive.Yampa, etc,
or even just Reactive.Yampa etc.
I do understand that hierarchical classification is inherently
problematic, and will never quite fit the ways we think of our modules.
But the alternative being proposed here is neither more descriptive, nor
more logical. In fact, it is an abandonment of description, in favour
of arbitrary naming. A package called foo-1.0 containing a module
hierarchy rooted at "Foo." tells me precisely nothing about its
contents. It it were rooted at Military.Secret.Foo, at least I would
have some clue about what it does, even if the category is inadequate or
slightly misleading in certain circumstances.
You may argue that only novices are disadvantaged by arbitrary names -
once you learn the referent of the name, it is no longer confusing.
However, I strongly believe that even experienced users are helped by
the continuous re-inforcement of visual links between name and concept.
After all, if you are collaboratively building a software artifact that
depends on large numbers of library packages, it may not be so easy to
keep your internal dictionary of the mapping between names and
functionality up-to-date, and in sync with your colleagues. Being just
a little bit more explicit in the hierarchy is a one-time cost at time
of writing, that reaps perceptual benefits long into the future for
yourself, and those maintainers who will follow you.
Regards,
Malcolm
