[phobos] next release (module useability)

[SHOO]

(2010/09/11 11:48), Jonathan M Davis wrote:
> On Friday 10 September 2010 02:10:52 Jonathan M Davis wrote:
>> On Friday 10 September 2010 01:40:45 SHOO wrote:
>>> (2010/09/09 23:08), Andrei Alexandrescu wrote:
>>>> On 9/9/10 8:20 CDT, Lars Tandle Kyllingstad wrote:
>>>>
>>>> 2. Define std.datetime, paste std.stopwatch in it, and have it import
>>>> std.date for now
>>>
>>> Is there the clear reason to adopt std.datetime?
>>> I think that std.time is better. Because name is short, and I think
>>> "time" include concept of the "date".
>>
>> I think that datetime is more descriptive, and I have no problem with
>> longer module names, so I think that I'd prefer it, but I don't really
>> care all that much. The functionality is what's important, and if all date
>> and time functionality is together, then it's not like it's going to be
>> all that hard to find whether it's std.date, std.datetime, or std.time.
>> Now, if we named it something like std.temporaltoolshed,
>> std.temporalkitchensink, or
>> std.temporalmishmash, then that would likely be a problem, but somehow I
>> don't think that anyone is going for that sort of name. Any of the
>> seriously suggested names thus far would likely work just fine.
>>
>> - Jonathan M Davis
>
> You know, those ludicrous names that I came up with make me wonder about how
> good your module or library has to be in order for people to put up with its bad
> name. I mean, if you have a module that's useable with a reasonable name, it
> will get used. But if you have a really nasty module name, people will be less
> inclined to use it. If they have an alternative which is good enough and has a
> better name, they're more likely to use that. The worse the name, the less
> they're inclined to use your module.
>
> However, the better that your module/library is in comparison to others, the
> more incentive there is to use it, bad name or no. So, you get this ratio of
> usefulness to useability (I'm just talk module naming useability at this point,
> but it could be expanded to general useability). The higher the usefulness, the
> greater the chance someone will use it; the lower the useability, the lower the
> chance that someone will use it. So, if you had an insanely useful module, you
> could give it a pretty bad name and it would still be used, but if you had a
> horrible module, it wouldn't matter how good the name was, it wouldn't be used.
> This begs the question of the threshold between a module being used do to its
> usefulness and being unused because of its bad name.
>
> I bet that we could name std.stdio something pretty bad, and have it used all
> the time because people need it. e.g.
> std.inputoutputstuffthatyoudreallyliketodoandisdownrightuseful would still be
> used. People would complain bitterly (and with good reason), but it would get
> used because you pretty much need the functionality that it has. On the other
> hand, if you name std.algorithm
> std.reallycoolstuffthatyoudprefernottohavetodoyourself, I bet that a _lot_ fewer
> people would use it. Yes std.algorithm is highly useful, but I know enough
> programmers who would shy away from it already. If you give it a name like that,
> only its most ardent supporters will use it. Renaming something like
> std.functional or std.getopt would likely be even worse, since they're likely to
> be in even less demand than std.algorithm.
>
> Now, I think that the reality of the matter is that the principle of useability
> relates far more to the contents of the module - how its functions are named,
> how they're used, etc. - matters far more than the name of the module, but I do
> think that it could be fairly interesting to see what the threshold of usage
> would be on a particular module with regards to its ration of usefulness to
> useability (be it its name or its contents). My guess is that, in general, low
> useability will kill a module far faster than its usefulness will get it used,
> which would just underline the importance of useability. I get the impression
> that programmers have tendency to reinvent the wheel very quickly if it looks
> like it's going to be too much trouble to use the wheel that they already have,
> or if they don't like it for whatever reason.
>
> In any case. I suppose that I'm rambling on, but the thought occurred to me
> after thinking about my ridiculous module name suggestions, and I had to share.
> It would almost be challenging to see how good a module you had to write to get
> people to use a module with an atrocious module name like std.temporalmishmash.
>
> - Jonathan M Davis

My question is simpler.

I want to know the reason.

time is a concept including date.
stopwatch/benchmark is a part of time, but it is not a part of date.
date is redundant if so.
Nonetheless what will the reason to add date to a module name be?

/* The reason of this question is because there was the doubt why naming 
it is WAG for of the module of Phobos before in Japanese community. (The 
subject at that time was "Why are std.file and std.path separated?") */