DHH vs. WHY style

[Trans]

Like to know others general opinions on having a comprehensive library
vs. independent libraries.

In my quest to make Facets' functionality available in some smaller
parts, I am left with hard choice. I think of it as the DHH vs. WHY
style question, b/c these two well known developers most clearly
reflect the approaches in their work. For DHH (ie. Rails) we have a
number of libs with closely labeled packages: ActionPack,
ActionMailer, ActiveSupport, ActiveRecord, etc. While _why's libs all
have highly independent packaging with clever names: Markaby, Hpricot,
Syck, etc. Now, I realize that different circumstances have certainly
led to this, eg. Rails is meant as a single comprehensive web-
framework, while Why's packages are more unique and reflect his
exceptional creatively, but either could have taken the other approach
if they so wished. And in my case (and surely some other large
projects as well), the distinction is not as straight forward.

So my question is, which is preferable? What criteria should one base
this decision on?

To clarify here is my specific scenario. I've narrowed it down, more-
or-less, to these Whyish vs. DHHish possibilities:

Aces Facets/CORE
Jacks Facets/BASE
Tapestry Facets/AOP
Comrade Facets/CLI
Fileside Facets/FS
Annote Facets/ANN

A couple of the names I'm not 100% sure about yet, but you get the
idea. I've been thinking about this a long time and haven't been able
to decide what direction to take for future development. It's most
significant impact, I suppose, is to the require namespaces ('facets/
aop/' vs. 'tapestry/' for example). The only other solid difference I
have found between them is that some libs don't mesh well with the DHH
style so those need to be completely separate anyway (for instance, my
modified redistribution of HTTPAccess2).

Thanks for any insights,
T.

 

[Phillip Gawlowski]

To clarify here is my specific scenario. I've narrowed it down, more-
or-less, to these Whyish vs. DHHish possibilities:

Aces Facets/CORE
Jacks Facets/BASE
Tapestry Facets/AOP
Comrade Facets/CLI
Fileside Facets/FS
Annote Facets/ANN

FacetsCore
FacetsBase
FacetsAOP #(if that is an acronym)
FactesFileside
FacetsAnnote

or turn that around:
CoreFacets
BaseFacets
AOPFacets
FilesideFacets
AnnotateFacets

This seems to be the most pronounceable to me, and leaves room for
others. You should go with the Rails way, as you have a common framework
already (facets) in use, and keeping the name facets makes transition
easier for the existing user base.

My 0.02EUR

--
Phillip "CynicalRyan" Gawlowski
http://cynicalryan.110mb.com/
http://clothred.rubyforge.org

Rule of Open-Source Programming #5:

A project is never finished.

 

[MenTaLguY]

So my question is, which is preferable? What criteria should one base
this decision on?

For me, the main criteria when deciding whether to give packages related names is the level of interdependence between them. If they're mostly all usable in isolation, there's no reason to give them related names.

-mental

 

[Tomas Pospisek's Mailing Lists]

Like to know others general opinions on having a comprehensive library
vs. independent libraries.

In my quest to make Facets' functionality available in some smaller
parts, I am left with hard choice. I think of it as the DHH vs. WHY
style question, b/c these two well known developers most clearly
reflect the approaches in their work. For DHH (ie. Rails) we have a
number of libs with closely labeled packages: ActionPack,
ActionMailer, ActiveSupport, ActiveRecord, etc. While _why's libs all
have highly independent packaging with clever names: Markaby, Hpricot,
Syck, etc. Now, I realize that different circumstances have certainly
led to this, eg. Rails is meant as a single comprehensive web-
framework, while Why's packages are more unique and reflect his
exceptional creatively, but either could have taken the other approach
if they so wished. And in my case (and surely some other large
projects as well), the distinction is not as straight forward.

So my question is, which is preferable? What criteria should one base
this decision on?

To clarify here is my specific scenario. I've narrowed it down, more-
or-less, to these Whyish vs. DHHish possibilities:

Aces Facets/CORE
Jacks Facets/BASE
Tapestry Facets/AOP
Comrade Facets/CLI
Fileside Facets/FS
Annote Facets/ANN

Well, the names first column are library names that don't have any
imediate meaning to me and moreover overlap with other libraries' names
(Aces (distributed programming c-lib), Jacks (sound system), Tapestry
(java-lib?)), so they might be funny and clever but not helpful.

The second column pretty clearly says what a library is about.

So I'd prefer use/helpful to funny/clever.
*t

 

[khaines]

To clarify here is my specific scenario. I've narrowed it down, more-
or-less, to these Whyish vs. DHHish possibilities:

Aces Facets/CORE
Jacks Facets/BASE
Tapestry Facets/AOP
Comrade Facets/CLI
Fileside Facets/FS
Annote Facets/ANN

For Facets, something out of the second column. If I see a discussion
about Jacks, I may not know what in the heck it is, but if I see
Facets/BASE, I'll have some useful information.


Kirk Haines

 

[James Britt]

What are people "buying" so to speak?

Do I want a "Facets", or an AOP framework? If I want AOP and CLI, do I want
them bundled, or separate? What do I get for them being together? What does
Facets add to them?

Also, consider branding/marketing considerations. Publicity requires
naming
that enables discussion and clarity of what you are discussing. What is
Facets? What kind of publicity (market discussion and understanding)
does it
generate? What is Facets/CLI? Can a name like that generate publicity?

WWSGD?

(What would Seth Godin do?)





--
James Britt

"The use of anthropomorphic terminology when dealing with
computing systems is a symptom of professional immaturity."
- Edsger W. Dijkstra

 

[Ari Brown]

WWSGD?

(What would Seth Godin do?)

EWHWDO

(Exactly What He Would Do Otherwise)

Don't pick a weird name like Amerthrall (I just made that up). A good
bet is always something simple. For instance, CitiBank doesn't
really generate conversations like OOTS generates laughs, but it
sticks with people and is easy to remember.

JMT
~ Ari
English is like a pseudo-random number generator - there are a
bajillion rules to it, but nobody cares.

 

[Jack Christensen]

Well, the names first column are library names that don't have any
imediate meaning to me and moreover overlap with other libraries'
names (Aces (distributed programming c-lib), Jacks (sound system),
Tapestry (java-lib?)), so they might be funny and clever but not helpful.

The second column pretty clearly says what a library is about.

So I'd prefer use/helpful to funny/clever.
*t +1.

--

 

[Sammy Larbi]

Tomas Pospisek's Mailing Lists wrote, On 4/25/2007 4:39 PM:

Well, the names first column are library names that don't have any
imediate meaning to me and moreover overlap with other libraries'
names (Aces (distributed programming c-lib), Jacks (sound system),
Tapestry (java-lib?)), so they might be funny and clever but not helpful.

The second column pretty clearly says what a library is about.

So I'd prefer use/helpful to funny/clever.

+1

 

[Bob Showalter]

To clarify here is my specific scenario. I've narrowed it down, more-
or-less, to these Whyish vs. DHHish possibilities:

Aces Facets/CORE
Jacks Facets/BASE
Tapestry Facets/AOP
Comrade Facets/CLI
Fileside Facets/FS
Annote Facets/ANN

After thinking about this for about 3 seconds, I like the whimsical
names. _why is cool.

 

[James Edward Gray II]

After thinking about this for about 3 seconds, I like the whimsical
names. _why is cool.

It has been interesting hearing everyone say that the right side is
so much more helpful. I have heard Facets is a collection of
extensions and I'll assume CORE means extensions to Ruby's core, so
maybe I get the first one. The second one means nothing to me though.

I also don't think whimsical names have to be unhelpful. When I
ported File::ReadBackwards from Perl, I named my version Elif. I
guess you have to "get that" before it helps, but I had to know what
Facets was to even make guesses about the more helpful names. Seems
pretty comparable to me.

So, I guess I'm a rebel: I like cool names.

James Edward Gray II

 

[James Britt]

I also don't think whimsical names have to be unhelpful. When I ported
File::ReadBackwards from Perl, I named my version Elif. I guess you
have to "get that" before it helps, but I had to know what Facets was to
even make guesses about the more helpful names. Seems pretty comparable
to me.

So, I guess I'm a rebel: I like cool names.

I stand with you! Raise the black flag!

My main concern with purely descriptive names are that they may not pass
the Google test. That is, if someone mentions it in a post and I want
to learn more, a reasonable search (e.g., ruby+code-name on Google)
should bring it up in the top 10.

I'm not advocating the use of stereotypical Web 2.0 -style names, but
they need not be dry and lifeless.


--
James Britt

"In physics the truth is rarely perfectly clear, and that is certainly
universally the case in human affairs. Hence, what is not surrounded by
uncertainty cannot be the truth."
- R. Feynman

 

[Phrogz]

Like to know others general opinions on having a comprehensive library
vs. independent libraries.

I'm confused as to what you're asking about - using a common naming
scheme, or having monolithic libraries versus smaller ones?

(The above bit I quoted would make the answer seem clear, but the rest
of the message seems to be about names.)

 

[Jamey Cribbs]

I stand with you! Raise the black flag!

My main concern with purely descriptive names are that they may not
pass the Google test. That is, if someone mentions it in a post and I
want to learn more, a reasonable search (e.g., ruby+code-name on
Google) should bring it up in the top 10.

I'm not advocating the use of stereotypical Web 2.0 -style names, but
they need not be dry and lifeless.

+1 for whimsical names.


For the past few years I have participated in a charity volleyball
tournament. Being that my vertical jump can only be measured by an
electron microscope, my chief contribution to our volleyball team has
been coming up with colorful team names. So, in the past few years, we
have proudly battled as:

* The Ruptured Spleens

* The Irritable Bowels

and the ever popular

* The Loose Stools


Now, aren't those name much more fun than the more descriptive:

* Six Old Farts Who Can Barely Walk, Much Less Jump And Therefore Should
Not Be Out Here Playing Volleyball


Jamey

 

[Sammy Larbi]

Jamey Cribbs wrote, On 4/26/2007 10:32 AM:

For the past few years I have participated in a charity volleyball
tournament. Being that my vertical jump can only be measured by an
electron microscope, my chief contribution to our volleyball team has
been coming up with colorful team names. So, in the past few years,
we have proudly battled as:

...
* The Loose Stools

On the whole, were you all a pretty crappy team?

 

[Jamey Cribbs]

Jamey Cribbs wrote, On 4/26/2007 10:32 AM:

On the whole, were you all a pretty crappy team?

Well, we didn't have a lot of time to practice together, so I guess you
could say we lacked consistency. ;-)

Jamey

 

[Joel VanderWerf]

Like to know others general opinions on having a comprehensive library
vs. independent libraries.

In my quest to make Facets' functionality available in some smaller
parts, I am left with hard choice. I think of it as the DHH vs. WHY
style question, b/c these two well known developers most clearly
reflect the approaches in their work. For DHH (ie. Rails) we have a
number of libs with closely labeled packages: ActionPack,
ActionMailer, ActiveSupport, ActiveRecord, etc. While _why's libs all
have highly independent packaging with clever names: Markaby, Hpricot,
Syck, etc. Now, I realize that different circumstances have certainly
led to this, eg. Rails is meant as a single comprehensive web-
framework, while Why's packages are more unique and reflect his
exceptional creatively, but either could have taken the other approach
if they so wished. And in my case (and surely some other large
projects as well), the distinction is not as straight forward.

So my question is, which is preferable? What criteria should one base
this decision on?

To clarify here is my specific scenario. I've narrowed it down, more-
or-less, to these Whyish vs. DHHish possibilities:

Aces Facets/CORE
Jacks Facets/BASE
Tapestry Facets/AOP
Comrade Facets/CLI
Fileside Facets/FS
Annote Facets/ANN

A couple of the names I'm not 100% sure about yet, but you get the
idea. I've been thinking about this a long time and haven't been able
to decide what direction to take for future development. It's most
significant impact, I suppose, is to the require namespaces ('facets/
aop/' vs. 'tapestry/' for example). The only other solid difference I
have found between them is that some libs don't mesh well with the DHH
style so those need to be completely separate anyway (for instance, my
modified redistribution of HTTPAccess2).

Thanks for any insights,
T.

What about putting your colorful names inside of generic namespaces?

aop/tapestry
cli/comrade
file/fileside
text/annote (?)

This scheme retains distinctiveness, but also communicates the general
purpose of a library: when we see "require 'cli/comrade'" at least we
know it has something to do with command line processing, and not
proletarian uprising. Or, if you really want the facets brand:
"cli/comrade-facet".

But these longer names hardly roll of the tongue...

 

[khaines]

My main concern with purely descriptive names are that they may not pass the
Google test. That is, if someone mentions it in a post and I want to learn
more, a reasonable search (e.g., ruby+code-name on Google) should bring it up
in the top 10.

I'm not advocating the use of stereotypical Web 2.0 -style names, but they
need not be dry and lifeless.

The thing here is that he already does have a recognizeable brand with
facets, and 'ruby facets' is the first thing to come up on a google
search. So, Facets/BASE will certainly do just fine on the Google test,
and it preserves an already well known brand name.


Kirk Haines

 

[Chad Perrin]

I stand with you! Raise the black flag!

H.L. Mencken once said: "Every normal man must be tempted, at times, to
spit on his hands, hoist the black flag, and begin slitting throats." I
just thought I'd share. It's one of my favorite quotes.

My main concern with purely descriptive names are that they may not pass
the Google test. That is, if someone mentions it in a post and I want
to learn more, a reasonable search (e.g., ruby+code-name on Google)
should bring it up in the top 10.

Thus, combine the two. Instead of Facets/File_reverse or Elif, you
might consider using Facets/Elif. Voila. Brand recognition, fun, *and*
brand recognition, all rolled up in one convenient package.

 

[Paul Brannan]

I also don't think whimsical names have to be unhelpful. When I
ported File::ReadBackwards from Perl, I named my version Elif. I
guess you have to "get that" before it helps, but I had to know what
Facets was to even make guesses about the more helpful names. Seems
pretty comparable to me.

Unhelpful names are the prevailing trend, though. It's true about
software and it's true about many automobile manufacturers. Some do it
because inventing names is fun, and some do it because less generic
names are better for marketing. I'm convinced, though, that there is a
group out there of nonzero size that comes up with these names just to
make life difficult for me.

Paul