On 02/12/2011 04:52 PM, Jonathan M Davis wrote:
> On Saturday 12 February 2011 06:21:15 bearophile wrote:
>> Jonathan M Davis:
>>> On Saturday 12 February 2011 03:25:29 Andrei Alexandrescu wrote:
>>>> And that's part of what makes it best.
>>>
>>> Agreed.
>>
>> If you agree on that, then you can't be a designer for a public API.
>
> I'm not saying that you should typically pick function names that way. But given
> that we already have iota, have already had iota for some time, and that there
> is already a C++ function by the same name that does the same thing, I see no
> reason to change it. It's nice and memorable, and it doesn't create confusion
> based on misunderstanding its name. Sure, a name that clearly says what it does
> would be nice, but I don't really like any of the names that have been
> suggested, and iota has worked just fine thus far.

Andrei's minion in me is feeling the urge to add that "iota" is also used in Go (for generating consecutive integers at compile-time, http://golang.org/doc/go_spec.html#Iota), and since Go is supposed to grow popular, "iota" will gain more popularity as well.

>
> I'm not suggesting that we go and name functions sigma and gamma or xyzzy or
> whatnot just because they mean nothing and are memorable. I'm saying that
> because we already have a function name which is memorable, I see no reason to
> exchange for one less memorable just because the name is nonsensical. It's
> useful in well-used functions to have short, memorable names, and iota fits that
> to a t.
>
> - Jonathan M Davis

On Saturday 12 February 2011 07:53:34 Jérôme M. Berger wrote:
> Jonathan M Davis wrote:
> > On Saturday 12 February 2011 02:33:12 Jeff Nowakowski wrote:
> >> On 02/11/2011 11:14 PM, Jonathan M Davis wrote:
> >>> If anyone tried to use iota to actually mean something as a variable or function name, I'd be suggesting that they pick a better nam.
> >> 
> >> So you're saying you don't like Andrei's chosen name? ;)
> > 
> > No. Andrei isn't trying to use the word based on its actual meaning. As it stands, the name is essentially nonsensical. That means that it's a vey poor name from the standpoint of figuring out what the function does based on its name.
> > 
> > _However_, precisely because it's such a short and nonsensical name, it's really easy to remember. I'm fine with keeping it as is. If someone could come up with a perfect replacement, then that woludn't be too bad, but honestly, I think that most of the names suggested actually increase the confusion.
> > 
> > With iota, you don't have a clue what it does based on its name, so you look it up. Then you remember it, because it's very memborable. With something like walk or interval, the name gives you a better idea of what it does, but it's _still_ not good enough for you to know based on the name and, since they mean something closer to what the function actually does but not quite, they risk misleading you as to what the function does. At least with iota, you know that you're going to have to look it up.
> > 
> > There's already precedent for iota as Andrei has stated, and it's been in std.algorithm for a while, so I'm fine with leaving it as is. It's a highly memborable name, and it's nice and short to boot.
> 
> 	The problem is that “iota” *does* make sense, but it is used in a
> way quite different from its meaning. So when you see it you do not
> look it up, but instead assume that you know what it means and do
> not understand how the code you are looking at works.

And how on earth does iota make sense in this context? I don't see how you could
possibly look at iota(0, 10) or iota(2, 21, 3); and think that it _anything_ to
do with its dictionary definiton (per: http://www.merriam-
webster.com/dictionary/iota )

1: the 9th letter of the Greek alphabet — see alphabet table

2: an infinitesimal amount : jot <did not show an iota of interest>

Honestly, I'd be quicker to think that it was some math term that I wasn't aware of than to think that it had _anything_ to do with its English meaning.

- Jonathan M Davis

On 02/12/2011 02:05 PM, Andrei Alexandrescu wrote:
> On 2/12/11 6:52 AM, spir wrote:
>> On 02/12/2011 12:25 PM, Andrei Alexandrescu wrote:
>>> On 2/12/11 5:02 AM, bearophile wrote:
>>>> Jonathan M Davis:
>>>>
>>>>> interval is slightly better, but as you mention, the step value
>>>>> muddles that
>>>>> abstraction.
>>>>
>>>> It's not muddled enough to make it worse than iota(). "iota" has
>>>> nearly no
>>>> relation with its purpose in Phobos.
>>>
>>> And that's part of what makes it best.
>>
>> What about a random name generator to define a language.stdlib's
>> lexicon? Then run a post-filter fed by user complaints about given names
>> actually suggesting some relation to any [part|aspect] of their sense.
>>
>> denis
>
> What I meant was that "iota" is not confusable with other concepts in Phobos,
> while at the same time being evocative for the task at hand. Another evocative
> term would be "quanta", but somehow I suspect that will enjoy little traction. :o)

Sorry for the somewhat humourous (?) reply above. Your statement shocked me a bit (quite the opposite of what i think is good in design --for public use).
Now, I very much agree that <"iota" is not confusable with other concepts in Phobos> is a very good property.
And to clore my participation to this debate: I would not mind "iota" to remain, anyway not everyday use feature. But I think it's good we have discussed this point at length, for other features, present & future. "On the importance of proper naming." (for others' benefit)

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

On 2011-02-12 02:25, bearophile wrote:
> Michel Fortin:
>
>> No one noticed yet that the a..b:c syntax causes ambiguity? Tell me,
>> how do you rewrite this using the new proposed syntax:
>>
>> 	auto aa = [iota(a, b, c): 1, iota(d, e): 2];
>
> Right, that's why in another post I have said that syntax replaces most iota usages. There are some situations where you can't use it well. This is another situation I've shown in the enhancement request:
> iota(10.,20.)
> Writing it like this is not sane:
>   10...20.

Why can't we just get rid of that floating point literal syntax, it just causes problem.

>> Interval is clear only as long as there's no step value mentioned.
>> Having a step value is quite a stretch from the usual notion of an
>> interval.
>
> Right, but I think it's acceptable still, and better than iota.
>
>
>> I like a lot so's suggestion "walk". I'm not sure it's much clearer
>> than iota though.
>
> It's better than iota, but not by much.
>
> Bye,
> bearophile


-- 
/Jacob Carlborg

Sat, 12 Feb 2011 17:54:24 +0200, Max Samukha wrote:

> On 02/12/2011 04:52 PM, Jonathan M Davis wrote:
>> On Saturday 12 February 2011 06:21:15 bearophile wrote:
>>> Jonathan M Davis:
>>>> On Saturday 12 February 2011 03:25:29 Andrei Alexandrescu wrote:
>>>>> And that's part of what makes it best.
>>>>
>>>> Agreed.
>>>
>>> If you agree on that, then you can't be a designer for a public API.
>>
>> I'm not saying that you should typically pick function names that way. But given that we already have iota, have already had iota for some time, and that there is already a C++ function by the same name that does the same thing, I see no reason to change it. It's nice and memorable, and it doesn't create confusion based on misunderstanding its name. Sure, a name that clearly says what it does would be nice, but I don't really like any of the names that have been suggested, and iota has worked just fine thus far.
> 
> Andrei's minion in me is feeling the urge to add that "iota" is also used in Go (for generating consecutive integers at compile-time, http://golang.org/doc/go_spec.html#Iota), and since Go is supposed to grow popular, "iota" will gain more popularity as well.

You're just arguing against his principles:

"..besides arguments ad populum are fallacious"

http://www.digitalmars.com/webnews/newsgroups.php? art_group=digitalmars.D&article_id=129453

Jacob Carlborg:

> Why can't we just get rid of that floating point literal syntax, it just causes problem.

I agree, the interval syntax (with or without optional stride) may be allowed for integral values only.

(Elsewhere I have even suggested to disallow number literals like 1. or .1 :-) )

Bye,
bearophile

Jonathan M Davis wrote:
> you're not going to misunderstand what it [iota] means based on its name.
> 
	Again, people *will* and actually, people *have* misunderstood it
based on its name.

		Jerome
-- 
mailto:jeberger@free.fr
http://jeberger.free.fr
Jabber: jeberger@jabber.fr

On 02/12/2011 07:12 PM, retard wrote:
>
> You're just arguing against his principles:
>
> "..besides arguments ad populum are fallacious"
>
> http://www.digitalmars.com/webnews/newsgroups.php?
> art_group=digitalmars.D&article_id=129453
>

Yes, I use ad populum all the time for its effectiveness.

I'll try to wriggle out by saying it was not an argument for "iota" but rather counterargument to the ad populum argument that "iota" is bad since it exists only in the long-forgotten APL and an unknown C++ extension.

Jonathan M Davis wrote:
> And how on earth does iota make sense in this context? I don't see how you could
> possibly look at iota(0, 10) or iota(2, 21, 3); and think that it _anything_ to
> do with its dictionary definiton (per: http://www.merriam-
> webster.com/dictionary/iota )
> 
> 1: the 9th letter of the Greek alphabet — see alphabet table
> 
> 2: an infinitesimal amount : jot <did not show an iota of interest>
> 
> Honestly, I'd be quicker to think that it was some math term that I wasn't aware of than to think that it had _anything_ to do with its English meaning.
> 
	And what about “iota (10)” which will probably be the most common
form? Like I already said in another post, people will understand
(and have understood) this as meaning “a range with a single
element, that element being 10”.

		Jerome
-- 
mailto:jeberger@free.fr
http://jeberger.free.fr
Jabber: jeberger@jabber.fr

On 2011-02-12 18:18, bearophile wrote:
> Jacob Carlborg:
>
>> Why can't we just get rid of that floating point literal syntax, it just
>> causes problem.
>
> I agree, the interval syntax (with or without optional stride) may be allowed for integral values only.
>
> (Elsewhere I have even suggested to disallow number literals like 1. or .1 :-) )

I was actually referring to this.

> Bye,
> bearophile


-- 
/Jacob Carlborg