[swift-evolution] [Discussion] Terms of Art Swiftification

[Shawn Erickson]

I also feel that Swift should be held "hostage" to a term of art especially
if the term is fairly badly named and/or unswifty. I feel the term of art
can incorporated in the API docs and possibly expressed by the alias
concept that has been discussed.

I strongly encourage going with a swiftly name for things first and only
then back peddling after considering the range of terms of art seen in
other languages.

-Shawn
On Tue, Jun 28, 2016 at 6:38 AM Sean Heber via swift-evolution <
swift-evolution at swift.org> wrote:

> The trouble with this line of reasoning, IMO, is that it is what led to
> the floppy disk becoming the “universal” save icon for years and years.
> Apple has spent considerable effort in macOS and iOS trying to show that
> you don’t really need a save button at all most of the time - it turns out
> that auto-save by default is what people expect. Flip the logic on it’s
> head!
>
> I fear that by adhering strongly to terms of art, we could be looking at a
> floppy-save-icon scenario over time. What if there are simply better ways
> of doing these things? What if the names themselves are blinding us to
> other alternatives?
>
> One of the purposes of my thought of having aliases for functions/methods
> is that it would give us an obvious primary location for a function -
> inside of the correct type or protocol - that feels Swifty. It would allow
> us to use “proper” Swift names that read fluently according to the
> guidelines even if they are perhaps more verbose or nontraditional or even
> unusual. Then by mapping those names to the existing common names, we can
> bring people along without too much initial pain while still allowing
> exploration of a new way to express things.
>
> Swift already has a rather unusual rule in that statements are meant to
> read like english phrases. It is meant to have a kind of human language
> flow when read because code is read more than it is written. Virtually all
> existing terms of art were NOT created with that kind of consideration. How
> can Swift come into its own if it isn’t allowed to have its own names for
> things that work with its own rules? I mean, sure, not *every* name needs
> to change and not every word needs to change, but it feels to me like we’re
> just coming up with our own dialect of a “standard” language that’s no
> different than American english vs. British english when what I think we
> should be exploring is more along the lines of the differences between
> english vs. greek.
>
> l8r
> Sean
>
>
> > On Jun 28, 2016, at 12:31 AM, Charlie Monroe via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> > Erica had a nice list of various term-of-art usages among languages - it
> included filter, map, etc. - I just can't seem to find it anywhere. This
> nicely showed that there is only a few languages that name things
> differently, mostly C# and C++.
> >
> > "filter" is nowadays quite a universal word that is in many languages -
> and I'm talking both about programming and a natural language. And I don't
> think that it goes against what one might be expecting - when you open a
> filter in the UI, you don't tick things that you don't want to see, but
> items that you *do* want to see.
> >
> > I don't think that changing those names will add any additional value to
> the Swift language. I've personally had more issues with the naming of
> flatMap - it could have been called filterMap to stay in line of filtering
> by returning nil (flattening an array is in my head associated with
> flattening of an array of arrays). But it's a term of art and I got my head
> around it.
> >
> >> On Jun 27, 2016, at 9:31 PM, Erica Sadun via swift-evolution <
> swift-evolution at swift.org> wrote:
> >>
> >> Under consideration is the resolution that  "some terms of art while
> appropriate to many FP languages, may be better served by using Swift
> names."
> >>
> >> Consider, for example, `filter(_:)`. Sean Heber writes,
> >>
> >>> Just tossing my vote in the hat for renaming .filter() to something
> like .select() since that better matches what it does, IMO. “Filter” is
> almost like the opposite word from what it should be since the closure
> returning true is what decides what is included in the results, not what is
> filtered *from* the results. I mean, yeah, I can kind of understand the
> logic either way, but it’s always been one of those strange mental
> gymnastics things."
> >>
> >> When asked "Shouldn't there be a term of art exemption for
> `filter(_:)`. Otherwise why not use `select(where:)`," Dave Abrahams
> replies:
> >>
> >>> Because `where(...)` is better.
> >>
> >> Have at it.
> >>
> >> -- E
> >>
> >> _______________________________________________
> >> swift-evolution mailing list
> >> swift-evolution at swift.org
> >> https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160628/20da01fe/attachment.html>