On Sat, 16 Oct 2010 18:20:37 -0400, Walter Bright
<[email protected]> 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
