> > 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 <[email protected]> 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 > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
