On Fri, Jun 10, 2016 at 2:06 PM, Goffredo Marocchi <[email protected]> wrote:
> I was not advocating the lack of constraints, programmers like all other > artists (and engineers, which are artists too ;)), but that the beauty is > the moderation of the two extremes :). ... and that architects leave the > problems you are talking about to the structural engineer :P. > > Gravity is a constrain, but a different one than having to use only a > certain pencil to do your sketches with and only being able to use Windows > 95 OSR 3 to work on or even weirder limitations. > The question is, does removing `where` feel to you like going from OS X 10.11 to Windows 95, or is it more like going from OS X 10.11.4 to OS X 10.11.3? > > On Fri, Jun 10, 2016 at 7:59 PM, Xiaodi Wu <[email protected]> wrote: > >> On Fri, Jun 10, 2016 at 1:11 PM, Goffredo Marocchi <[email protected]> >> wrote: >> >>> I think sometimes the community in this mailing list loses sight on the >>> fact that coding is a creative endeavour much similar to architectural >>> design or painting. There may be math and well researched and structured >>> ideas in place, but it requires creativity too. >>> >> >> Architects are constrained to craft buildings that will stand in the face >> of gravity, and even painters don't have pigments for every color visible >> to the human eye. There's a wonderful novel, _Gadsby_, written without the >> letter 'e'; I haven't read it but I understand it's truly an >> accomplishment. This is not so drastic here. In this case, the apt analogy >> would be that we find the letter 'a with circle on top' to be posing some >> pesky problems; do you think you could write a novel in English without >> using 'a with circle on top'? I wager that your creativity will not suffer >> (unless your novel describes a trip to IKEA, in which case I'm sorry). >> >> >>> >>> Trying to force a strict one size fits all The One True standard usually >>> ends up fragmenting the standard further, by adding yet another take on >>> what is the most orthodox implementation and who are the heretics... >>> >>> I do not think dismissing the idea of having more than one way of >>> skinning the proverbial cat as an anti-goal is doing a good service to the >>> community or the language as it completely disregards context, people >>> differing idea of the subjective best coding style and patterns (which >>> pattern do I use? Which algorithm do I use to sort this data set with? A >>> good engineer will give you a direct and concise answer, but a better one >>> will say "it depends... What's the context? What is the problem I need to >>> solve, what are the constraints and the data set I am working on?"). >>> >>> The way some users seem to want Swift to follow sounds like protecting >>> users from mistakes by sometimes removing the ability which could lead to >>> mistakes in the first place, but that removes all the good things you could >>> do if you were to trust developers with the extra responsibility. >>> >>> Sent from my iPhone >>> >>> On 10 Jun 2016, at 18:30, let var go via swift-evolution < >>> [email protected]> wrote: >>> >>> I respect that anti-goal, but I think being over-rigid about limiting >>> developers' choice of expression is also an anti-goal. >>> >>> To me, it is like guard statements vs. if-let statements. Some people >>> find one to be more clear than the other. Often times the best choice >>> depends on the context. Sometimes a guard statement can be re-written as an >>> if-let statement in a way that makes the code more clear, and vice versa. >>> And different people will inevitably have different personal preferences - >>> their own "style", if you will - and will favor one over the other. But it >>> would be a mistake to force everyone into one box in order to prevent the >>> fracturing of the Swift community into "dialects." >>> >>> But most importantly (and this is really the kicker for me) there are >>> times when the "where" syntax provides the maximum amount of clarity in the >>> context of my code, and I don't want to lose that expressive power. >>> >>> On Fri, Jun 10, 2016 at 10:17 AM Xiaodi Wu <[email protected]> wrote: >>> >>>> I think this idea--if you don't like it, then you don't have to use >>>> it--is indicative of a key worry here: it's inessential to the language and >>>> promotes dialects wherein certain people use it and others wherein they >>>> don't. This is an anti-goal. >>>> >>>> On Fri, Jun 10, 2016 at 12:10 let var go <[email protected]> wrote: >>>> >>>>> Leave it in! >>>>> >>>>> It's a great little tool. I don't use it very often, but when I do it >>>>> is because I've decided that in the context of that piece of code it does >>>>> exactly what I want it to do with the maximum amount of clarity. >>>>> >>>>> If you don't like it, then don't use it, but I can't see how it >>>>> detracts from the language at all. >>>>> >>>>> The *only* argument that I have heard for removing it is that some >>>>> people don't immediately intuit how to use it. I didn't have any trouble >>>>> with it at all. It follows one of the most basic programming patterns >>>>> ever: >>>>> "For all x in X, if predicate P is true, do something." The use of the >>>>> keyword "where" makes perfect sense in that context, and when I read it >>>>> out >>>>> loud, it sounds natural: "For all x in X where P, do something." That is >>>>> an >>>>> elegant, succinct, and clear way of stating exactly what I want my program >>>>> to do. >>>>> >>>>> I don't doubt that it has caused some confusion for some people, but >>>>> I'm not sold that that is a good enough reason to get rid of it. It seems >>>>> strange to get rid of a tool because not everyone understands how to use >>>>> it >>>>> immediately, without ever having to ask a single question. As long as its >>>>> not a dangerous tool (and it isn't), then keep it in the workshop for >>>>> those >>>>> times when it comes in handy. And even if there is some initial confusion, >>>>> it doesn't sound like it lasted that long. It's more like, "Does this work >>>>> like X, or does this work like Y? Let's see...oh, it works like X. Ok." >>>>> That's the entire learning curve...about 5 seconds of curiosity followed >>>>> by >>>>> the blissful feeling of resolution. >>>>> >>>>> On Fri, Jun 10, 2016 at 9:32 AM Xiaodi Wu via swift-evolution < >>>>> [email protected]> wrote: >>>>> >>>>>> On Fri, Jun 10, 2016 at 11:23 AM, Sean Heber via swift-evolution < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> > And to follow-up to myself once again, I went to my "Cool 3rd >>>>>>> Party Swift Repos" folder and did the same search. Among the 15 repos in >>>>>>> that folder, a joint search returned about 650 hits on for-in (again >>>>>>> with >>>>>>> some false positives) and not a single for-in-while use. >>>>>>> >>>>>>> Weird. My own Swift projects (not on Github :P) use “where” all the >>>>>>> time with for loops. I really like it and think it reads *and* writes >>>>>>> far >>>>>>> better as well as makes for nicer one-liners. In one project, by rough >>>>>>> count, I have about 20 that use “where” vs. 40 in that same project not >>>>>>> using “where”. >>>>>>> >>>>>>> In another smaller test project, there are only 10 for loops, but >>>>>>> even so one still managed to use where. >>>>>>> >>>>>>> Not a lot of data without looking at even more projects, I admit, >>>>>>> but this seems to suggest that the usage of “where” is going to be very >>>>>>> developer-dependent. Perhaps there’s some factor of prior background at >>>>>>> work here? (I’ve done a lot of SQL in another life, for example.) >>>>>>> >>>>>> >>>>>> That is worrying if true, because it suggests that it's enabling >>>>>> 'dialects' of Swift, an explicit anti-goal of the language. >>>>>> >>>>>> >>>>>>> >>>>>>> I feel like “where” is a more declarative construct and that we >>>>>>> should be encouraging that way of thinking in general. When using it, it >>>>>>> feels like “magic” for some reason - even though there’s nothing special >>>>>>> about it. It feels like I’ve made the language work *for me* a little >>>>>>> bit >>>>>>> rather than me having to contort my solution to the will of the >>>>>>> language. >>>>>>> This may be highly subjective. >>>>>>> >>>>>>> l8r >>>>>>> Sean >>>>>>> >>>>>>> _______________________________________________ >>>>>>> swift-evolution mailing list >>>>>>> [email protected] >>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>>> >>>>>> _______________________________________________ >>>>>> swift-evolution mailing list >>>>>> [email protected] >>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>> >>>>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >>> >> >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
