DHH vs. WHY style

ruby-talk
1

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.

2

Trans wrote:

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.

3

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

···

On Thu, 26 Apr 2007 03:16:52 +0900, Trans <transfire@gmail.com> wrote:

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

4

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?

Comrade, a CLI framework for building command-line tools, is an interesting
discussion. Now what does Facets add to the discussion?

Facets/CLI ties CLI to a meta-brand, but what does the meta-brand mean? Does
it strengthen the position of CLI (interoperability?, a common extensions
meta-programming model? ), or weaken it (a partial CLI, rather then a
full-fledged CLI framework).

ActiveRecord actually has a brand separate from Rails because of the name,
and the high-level of publicity regarding it's model for ORM. The separate
name helped- people talked at length about ActiveRecord, separate of
considerations of Rails. This helped strengthen the Rails brand (full-stack
+ ActiveRecord= fast development).

Then there are the use-cases regarding library usage. Do the components work
together? Is this valuable? Is this their purpose? Are the components
supposed to be best-in-class, or convenience items by virtue of bundling.

I don't know much about Facets, but my question is what value Facets adds to
CLI and AOP in the users mind.

On comprehensive libraries in general, what makes it worthwhile? What kind
of thematic or practical bundling adds value?

To me, comparing Rails to Why's packages seems to be the wrong approach. You
want to look across broader vistas for similar packaging of disparate
features. What Unix equivalents are there, and what drove the bundling?

Cheers,
Nick

···

On 4/25/07, Trans <transfire@gmail.com> wrote:

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.

5

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

···

On Thu, 26 Apr 2007, Trans wrote:

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

--
-----------------------------------------------------------
   Tomas Pospisek
   http://sourcepole.com - Linux & Open Source Solutions
-----------------------------------------------------------

6

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

···

On Thu, 26 Apr 2007, Trans wrote:

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

7

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

···

On 4/25/07, Trans <transfire@gmail.com> wrote:

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

8

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.)

···

On Apr 25, 12:16 pm, Trans <transf...@gmail.com> wrote:

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

9

Trans wrote:

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...

···

--
       vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407

10

Nicholas Van Weerdenburg wrote:

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

11

Tomas Pospisek's Mailing Lists wrote:

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

+1.

···

On Thu, 26 Apr 2007, Trans wrote:

--
-----------------------------------------------------------
  Tomas Pospisek
  http://sourcepole.com - Linux & Open Source Solutions
-----------------------------------------------------------

--
Jack

12

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

···

On Thu, 26 Apr 2007, Trans wrote:

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.

+1

13

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

···

On Apr 26, 2007, at 8:12 AM, Bob Showalter wrote:

On 4/25/07, Trans <transfire@gmail.com> wrote:

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.

14

-1. I'd prefer the distinguished libraries to have their own brands, so
that they can be more easily discussed in isolation. Standard libraries,
on the other hand, ought to have descriptive names.

Cheers,
Daniel

···

On Thu, 2007-04-26 at 06:39 +0900, Tomas Pospisek's Mailing Lists wrote:

On Thu, 26 Apr 2007, Trans wrote:

> 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

15

That goes without saying.

···

On Thu, 2007-04-26 at 22:12 +0900, Bob Showalter wrote:

_why is cool.

16

Joel VanderWerf wrote:

What about putting your colorful names inside of generic namespaces?
  aop/tapestry
  cli/comrade
  file/fileside
  text/annote (?)

+1. In fact I have a whole taxonomy of infrastructure
terms I've used, and being able to locate a "body of
work" is much easier if such a taxonomy is used.

17

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.

···

On Apr 25, 2007, at 6:47 PM, James Britt wrote:

Nicholas Van Weerdenburg wrote:

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?)

18

There you go! Trans- it doesn't matter, just make sure you have a PURPLE
COW!

Or go more old school- WWRATD? (What would Ries and Trout do)

Trans- it doesn't matter, just make sure you invent or segment a category
and own a word in the customers mind! It's all about positioning-
Differentiate or die!

Or WWYD (what would Yoda do)?
The words you chose, important they will become. Power, words have.

Cheers,
Nick

···

On 4/25/07, James Britt <james.britt@gmail.com> wrote:

Nicholas Van Weerdenburg wrote:
> 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

19

James Edward Gray II wrote:

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

20

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

···

On Thu, Apr 26, 2007 at 10:26:54PM +0900, James Edward Gray II wrote:

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.