duck!

[Steven Schveighoffer]

On Sat, 16 Oct 2010 18:20:37 -0400, Walter Bright  
<newshound2 at digitalmars.com> wrote:

> Steven Schveighoffer wrote:
>> I'm just saying that marketability of D does not change no matter what  
>> appropriate term you choose.
>
> And this is our fundamental disagreement. I think the choices of names  
> matters a lot.
>
> If names don't matter, why not name your son "Sue" ? :-)

Notice I said *appropriate* term :)  And he prefers Susan.

>
>> But were there functions named zoomTechnology() and smartLink()?  Were  
>> their tools named zoom or smartl or something?  Is that what pushed  
>> them over the edge, or was it the bullet on the packaging that said:
>>  * Includes zoom technology!
>
> I don't believe that there is any fundamental difference between the  
> name of a function and the name of the technology.

The name of the technology can be inventive, super-descriptive, slightly  
exaggerated, a marketing term.  The name of a function can be that, but  
doesn't have to be.  Preferrably it should be succinct and related to the  
technology.  'duck' is a fine term, but as a function name is not going to  
score any marketing points.

>> But people don't search google for "duck typing programming languages"  
>> and pick the language they're going to use from this list!
>
> They may very well search "duck typing in the D programming language".  
> Heck, that's what I do when I'm investigating whether language X  
> supports feature Y. I do it a lot.

Most people will look at something like  
http://en.wikipedia.org/wiki/Duck_typing and find D precariously missing  
because as Michel Fortin pointed out, adaptTo is not duck typing.

>> I think you are really going cuckoo over this feature like it's the  
>> best thing since ranges, and I don't see it being that.
>
> I am happy with the name ranges for what it does, I think it's exactly  
> right. Am I going cuckoo over this one? Perhaps. But I also believe that  
> even getting the small details right is important.

As do I.  To suggest that not liking the term 'duck' the best means a lack  
of attention to detail is a little argumentative, don't you think?

>
> It reminds me of when a friend visited my house. After a very brief  
> interval, he announced could tell it was a quality house, not a cheap  
> facade. Intrigued, I asked him how. He said that the screw slots holding  
> the wall plates on were all aligned the same way. It's a wholly  
> irrelevant detail, added absolutely nothing to the function, but he said  
> such attention to detail indicated the contractor cared about getting  
> the details right.

Really?  That's like saying a car is very well maintained because the  
headlights are properly aligned.  I'd highly advise against using the  
"screw alignment test" for buying a house ;)

>> Invariant vs. immutable is not the same as adaptTo vs. duck.  Invariant  
>> already had a meaning in D1, and when choosing a new name, it was  
>> logical to use immutable.  Is immutable an 'exciting marketing term'?   
>> No, it's as boring as they come.  But it's definitely the best term for  
>> the job.  Let's focus on choosing the best term for what 'adaptTo'  
>> does, and when we market that D does duck typing in an article or a  
>> list of features (that shows up on google), we can include all the  
>> features of D that do duck typing.
>
> With invariant I *always* had to explain it (even to people with no  
> knowledge of the D1 meaning), and people would looked puzzled even after  
> the explanation. With immutable, I stopped having to explain it. The  
> name change was a big win.

Yes, because using invariant to mean immutable is somewhat of a misnomer.   
The CS meaning of invariant is:  
http://en.wikipedia.org/wiki/Invariant_%28computer_science%29.  I think  
you'd agree that as!X and adaptTo!X are not obscure terms that don't  
describe the function properly.  Heck, the pattern being implemented here  
is the adapter pattern, so adaptTo seems like a pretty correct term.

-Steve