[swift-evolution] [Draft] Apply -ed/-ing rule to core functional methods (e.g. filter => filtered)

Sat Jun 18 01:47:27 CDT 2016

>
> Sure, but `mappingAndFlattening(to:)` would have brevity issues as well.

My point was that if you want to transform sin() -> sine() you'd be pretty
much forced to also do atanh() -> hyperbolicArcTangent(). However the
proposed transformation is for flatMap() to flatMapped(), which doesn't
have any brevity issues and is still very close to the exact term of art.

Higher-order functions are not a specialized feature that only the
> functional eggheads use. Outside of a few small pockets—one of which is
> native Apple apps—they are a pervasive feature of modern programming
> environments. They are the rule, not the exception.

They do have significant usage, but the term of art will not be an
"ingrained term" for any of the following:
– Users new to programming.
– Users from languages that do not have these functions, or include them
under a different name.
– Users from languages that do have these functions under these names, but
haven't used them so regularly as to become an ingrained term. Which I'd
estimate is a large group: Personally I've used most of the mainstream
languages on your list, some for a very long time, without using these
functions very much at all.

Nevertheless I'm also definitely in favor of keeping *the terms of art as
stems (*i.e. not moving to different words altogether) so we retain 90% of
the benefits, but just slightly modifying them.

On Sat, Jun 18, 2016 at 4:13 AM, Brent Royal-Gordon <brent at architechies.com>
wrote:

> > – What sin(x) should do is unambiguous, unlike array.filter { ... }.
>
> A decent argument label, like `including` or even `to`, would fix the name
> `filter`. And as I said, if we feel `filter` is unsalvageable, the
> alternate Smalltalk-lineage `select` is clearer.
>
> > – There's very significant brevity issues here, e.g.
> hyperbolicArcTangent() vs atanh().
>
> Sure, but `mappingAndFlattening(to:)` would have brevity issues as well.
> (You didn't think the API Guidelines merely meant "add -ed or -ing to
> everything", did you?)
>
> > – The relevant metric of the strength of a term of art would be for how
> many users it already is a very much ingrained term (i.e. not how long it
> has been around). For sin() this is the case for pretty much anyone who has
> done high-school math. Conversely, map/filter/reduce will only be
> significantly ingrained for experienced users of languages that are
> functionally-centered enough to regularly use these, which is a much
> smaller percentage (though not insignificant).
>
> I think "languages that are functionally-centered enough to regularly use
> these" makes this set of languages sound rather smaller than it really is.
> The languages with C in their names—C, C++, Objective-C, and C#—are almost
> the only ones in modern use which *don't* include higher-order functions.
> Few people would regard Perl, Javascript, Java, Python, or Ruby as
> "functional" languages, but all of them support `map`. If you look at
> RedMonk's list of 21 popular languages <
> http://fossbytes.com/21-top-programming-languages-on-github-and-stack-overflowjanuary-2016/
> >:
>
> * 1 (CSS) has no real concept of lists or list operations.
> * 2 (shell and C) do not have closures.
> * 1 (Go) could support `map`, but K&R still think it's 1973.
> * 1 (Objective-C) could support `map`, but...well, if the Foundation guys
> want to tell us why they don't, they know where to find us.
> * 16 have a version of `map`:
>         * 1 (Matlab) has vectorization features which act like an implicit
> `map`.
>         * 2 (C# and Visual Basic) have a `select` operation from LINQ
>         * 3 (C++, R, and Groovy) have other names for `map`
>         * 10 (Javascript, Java, PHP, Python, Ruby, Perl, Scala, Go,
> Haskell, Swift, and Clojure) call it `map`.
>
> Of 16 languages with `map`, Scala, Haskell, Clojure, and maybe R and
> Matlab would typically be considered functional, and all of those are in
> the bottom half of the list. The other 11 languages with a version of `map`
> are all mainstream multi-paradigm languages of the sort people coming to
> Swift might be familiar with.
>
> In short: Higher-order functions are not a specialized feature that only
> the functional eggheads use. Outside of a few small pockets—one of which is
> native Apple apps—they are a pervasive feature of modern programming
> environments. They are the rule, not the exception.
>
> >> Let me turn your question around: What concrete benefits do we gain
> from modifying terms which are extremely widely recognized? It is not
> consistent, but is there any reason to believe that causes actual
> confusion? If not, then why fix what isn't broken?
> >
> > The benefits of renaming:
> > – It makes learning easier as it establishes a consistent way to read
> Swift methods right from the start.
> > – It would help users in intuitively learning consistent naming for
> their own methods, even if they haven't read the API guidelines.
>
> These are basically two ways of stating the same point, which again, is
> not considered strong enough to overcome strong terms-of-art in other areas.
>
> > – It allows defining e.g. an in-place filter variant.
>
> Several people have mentioned this could be done, but has anyone actually
> *asked* for it? And if it did exist, wouldn't it be better to offer this
> functionality as a `remove(where:)` function, matching existing methods
> like `first(where:)` and `index(where:)`?
>
> (Actually, if we're going to rename `filter`, `where` might not be a
> terrible name. It's valid after a dot, but not without one.)
>
> Even if we *do* want to offer it for `filter`, the others are not good
> candidates for mutating variants. Mutating `map` could only be offered on
> certain sub-protocols of `Collection`, could not be guaranteed to be
> in-place (and probably wouldn't be for most collection types), and would
> have a severely restricted set of use cases compared to its nonmutating
> equivalent. Mutating `flatMap` would suffer even more from these
> limitations, making it desperately tricky to implement. And `reduce` simply
> couldn't be offered at all.
>
> > I agree with your points on the problems with dropFirst/dropLast btw.
>
> Incidentally, I just noticed that `removeFirst(_:)`/`removeLast(_:)` ought
> to get this treatment too.
>
> I'll see if I can write up at least a sketch of what I'd like to do to
> these methods in the next few days, but I'm busy today preparing for the
> local (Orange County, CA) Apple community's post-WWDC event. Need to come
> up with something to talk about. :^)
>
> --
> Brent Royal-Gordon
> Architechies
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160618/27f54255/attachment.html>