Boost logo

Boost :

Subject: Re: [boost] [Hana] Informal review request
From: Edward Diener (eldiener_at_[hidden])
Date: 2015-03-21 21:52:01


On 3/21/2015 9:06 PM, Louis Dionne wrote:
> Edward Diener <eldiener <at> tropicsoft.com> writes:
>
>>
>> On 3/21/2015 12:11 PM, Louis Dionne wrote:
>>
>>> [...]
>> >
>>> If you have specific examples of places where I use names that seem
>>> cryptic, please point them out. I will be happy to discuss the reasons
>>> behind those names and to change them if those reasons are deemed
>>> insufficient after consideration.
>>
>> A name like 'foldl' and 'foldr' is what I mean.
>
> Quoting from my original reply to Steven:
>
> [...] So this opens the door for renaming foldl/foldr to
> fold/reverse_fold. I'll probably start by adding aliases
> and then consider removing foldl/foldr [...]
>
> It might not have been clear because I said "opens the door for [...]"
> and "probably start by [...]", but I actually meant that `fold` and
> `reverse_fold` __will__ be provided by Hana. The decision is already
> taken. I take it that the point of your intervention was to make sure
> this was the case.
>
> If you come across other functions that seem to be misnamed, please
> fill a GitHub issue so we can discuss the problem and resolve it.

The point of my comment was to encourage not to you names like
'foldl/foldr' at all in your programming endeavors. Shorthand names
rather than descriptive names always seems to me a bad way to program.
No doubt I am sometimes guilty of it myself but the use of short but
cryptic mnemonics always seems to me to be bad. Ages ago when memory was
scarce and disk space was scarce the micro-computer world may have had a
use for these short mnemonics, as in Unix/Linux etc., but nowadays I see
no use for it. C++ very smartly has not pursued the cryptic mnemonics of
C as a rule and I see little reason why good C++ programmers should ever
follow the cryptic menemonics path anymore. It only makes functionality
harder to understand and remember.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk