From: Trans Date: 2007-04-30T22:42:48+09:00 Subject: Re: DHH vs. WHY style On Apr 29, 12:00 am, Sammy Larbi wrote: > Peter Cooper wrote: > > On 4/26/07, Ari Brown wrote: > > >> 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. > > > Unlike, say, Google? > > I'm not sure that name came from nowhere.... > (http://en.wikipedia.org/wiki/Googol) Of course, I assume most probably > knew that... > > > The opposing view doesn't seem to have hurt the > > popularity of Hpricot, Mongrel, Hoe, or, heck, even "Rails" itself, and > > they're some of the biggest Ruby related projects out there ;-) > > > That said, I must admit I partly agree with you when it comes down to > > tools, > > rather than brand names. Rails is certainly a brand, and has almost > > certainly been intended to be one from very early on. Same for Hpricot > > and > > Mongrel, I'd say. Some small library with a niche function though..? > > I'd say > > your advice would be right for that. > > I was never sure if this thread was talking about naming > classes/packages or a product. In my view, you should name products > distinctly, and its quite ok to give them cute names. But giving > code-related things names that are nonsensical /is/ nonsensical. It may > seem cute, but its often quite useless. > > After reading this one, I'm still no closer to knowing if we are talking > about products or code. =) But I'm leaning ever closer to knowing I > just don't know. =) Well, at heart, we're dealing will about 100 or so libraries (ie. files). The vast majority of which can stand on there own. I'd have to be crazy to give each and every one a colorful name, but some of them do admit of clear relationships, like the libs pertaining to CLI and AOP. Presently Facets is one monolithic library collection. That's good for brand recognition around "Facets", but it also seems to hurt uptake b/c programmers tend to look for more focused solutions. Per the original query. I could subdivide the libs into taxonomic categories, eg. cliFacets, aopFacets, and what have you. That would help, but I worry it would still not be enough to spur this focused uptake. And I also wonder if it would still stifle development since they remain part a larger collective. T.