Arbitrary abbreviations in phobos considered ridiculous

Jacob Carlborg doob at me.com
Thu Mar 8 06:21:27 PST 2012


On 2012-03-08 03:14, Ary Manzana wrote:
> On 3/6/12 9:25 PM, Jonathan M Davis wrote:
>> On Tuesday, March 06, 2012 20:58:52 Ary Manzana wrote:
>>> On 3/6/12 8:43 PM, Jonathan M Davis wrote:
>>>> On Tuesday, March 06, 2012 17:38:09 Adam D. Ruppe wrote:
>>>>> writeln(time.toISOExtendedString()); // bzzt, wrong, but this
>>>>> used to work!
>>>>
>>>> Yes, and it was quickly changed to toISOExtString, because
>>>> toISOExtendedString is painfully long. toISOExtString is bad enough,
>>>> but
>>>> you can't really make it any shorter without making the name
>>>> uninformative.
>>>>
>>>>> Nope, apparently, I meant "dur". Ridiculous.
>>>>
>>>> A Duration needs to be constructed with a template, and
>>>> duration!"hours"(13), duration!"seconds"(44), etc. is painfully long
>>>> when
>>>> used in expressions. So, it was shortened to dur. I don't know of any
>>>> other abbreviation which would make sense.
>>>
>>> Painfully long?
>>>
>>> How much time does it take you to type 5 more chars? How much time does
>>> it take you to understand "dur" when you read it instead of "duration"?
>>>
>>>> I agree with H.S. Teoh in that abbreviations should be meaniful and
>>>> consistent but that they _should_ be used where applicable. Code
>>>> becomes
>>>> painfully long otherwise - especially when chaining function calls and
>>>> the like.
>>>
>>> Code becomes painfully long when you write lots of lines, not when you
>>> write long lines. Specially when you write lots of boilerplate lines.
>>
>> You don't write much code in functional style, do you?
>
> Here's something I wrote today:
>
> parent_ids = results.map{|x|
> x['_source']['parent_ids']}.flatten.uniq.compact
> Hash[Site.find(parent_ids).map{|x| [x.id, x]}]
>
> Or I could have written:
>
> Hash[
> Site.find(
> results.map{|x| x['_source']['parent_ids']}.flatten.uniq.compact
> ).map{|x| [x.id, x]}
> ]
>
> No abbreviation at all, many function calls, functional style in the
> middle (the couple of "map").
>
> In Ruby it's not such a big problem to have descriptive names.
>
> I guess in D it would be longer because of all the template invocation,
> the argument types, etc. I just guess it, I'm not sure.

With the new labmda syntax and the new UFCS it would be:

Site.find(
results.map!(x => x['_source']['parent_ids']).flatten.uniq.compact
).map!(x => [x.id, x]);

Don't know the corresponding D functions for "flatten" and "compact", 
you might not need them.

> If you chain functions
>> much, then long names very quickly result in long lines, which makes
>> the code
>> harder to read, and can quickly lead to expressions having to be multiple
>> lines, simply because the symbol names involved were overly verbose.
>>
>> While, I grant you that duration!"minutes"(5) might be more
>> immediately clear
>> than dur!"minutes"(5) is, I don't buy that it makes all that much of a
>> differences. You're not going to mistake dur for anything else even if it
>> doesn't immediately occur to you that it's an abbreviation for
>> duration, and
>> the units make it very clear that it's related to time. And since dur is
>> something that's likely to be commonly used, it will very quick and
>> easy to
>> remember what it is.
>
> The problem is not mistaking it with something else. The problem is when
> you want to write it. In Ruby my mind works like this:
>
> Mind: "How would I get a span for 5 seconds?"
> Mind: "Let's try 5.seconds"
> Mind: "Wow, it works!"
>
> I'm trying to remember cases when I just wrote what my mind thought it
> was correct and I was *so* surprised it worked out of the box in Ruby.
> Like writing array.last, and get it to work, instead of
> array[array.length - 1]. But in D, from the docs
> (http://dlang.org/arrays.html )
>
> bar[$-1] // retrieves last element of the array
>
> I read: bar dollar minus one wait what??
>
> Now, in D I try:
>
> 5.seconds
>
> and it doesn't work. I have to write this very unintuitive:
>
> dur!"minutes"(5)
>
> Was it really necessary to implement it that way?
>
> Again, the problem is not understanding the meaning, the problem is
> guessing what you have to write and get it right the first time.

I completely agree.

-- 
/Jacob Carlborg


More information about the Digitalmars-d mailing list