> On Jun 9, 2016, at 4:59 PM, Brandon Knope <[email protected]> wrote: > > I never said design by consensus. What I said is that we did not have a > broader representation during this review. > > What we got was a few "top" developers sharing their opinion. To me this is > not healthy. We needed more opinions from the top skilled developers to > hobbyists. > > Maybe this wouldn't have changed the outcome, but it could have guided the > discussion more and perhaps differently. > > The core team *is* taking feedback from the community. This feedback however > is from a few very technically skilled developers and not necessarily > representative of the more common developer (of which there is more). > > The fact that this proposal and review went through so quickly makes me > suspect whether all of the ramifications were thought through thoroughly. > > The core team is wonderful, so I am sure they awesome discussions on > this...but the fact that it happened so quickly is worrisome to me. > > I hope developers like me have somewhat of an advocate on the core team as I > am sure everyone on that team is in the very highly skilled category :P > > Brandon >
it took a single A. Einstein playing with nonexistent elevators to figure something as complicated as a workable approximation of Gravity (see I even leave room for the fact that like Newton’s work before, his may also just be an approximation of something else). I don’t think it takes a crowd of developers (me included) to SEE certain things. > > > > Sent from my iPad > > On Jun 9, 2016, at 10:51 AM, L. Mihalkovic <[email protected] > <mailto:[email protected]>> wrote: > >> I don't know what your professional experience in the software industry is, >> but mine is that design by conscensus rarely leads to the best outcome, >> especially in the presence of strong egos. Swift is advertised as >> Opinionated, but (fortunately) nowhere does it say your or my opinion. I >> would even go so far as to say that most people can't design a language to >> save their lives (me included). At some point, a small number of benevolent >> dictators have to make a decision they believe in. >> >> IMO the job of the community is to shake ideas in front of these dictators >> with the hope that it will give perspectives they may not have already seen, >> or challenge their ideas in ways they might not have anticipated. But >> nowhere does it say (and I will immediately drop any further interest in >> Swift if someone tells me it should be that way) that their role is to >> dutifully record what the plebe wants and deliver it as best as they can. >> Taken together, some of the most individually popular suggestions would >> undoubtedly lead to some sort of franken-swift that not even the people >> pushing these ideas forward would end up using. >> >> On Jun 9, 2016, at 4:34 PM, Brandon Knope via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >>> I have just one last thing to say on this topic as it is clear it is going >>> into the language and no accepted proposal has been overturned that I am >>> aware of. >>> >>> I believe with this cycle, the swift evolution process didn't work. >>> >>> And here is why I think this: >>> - This proposal began as a discussion on May 20th and lasted 4 days with >>> minimal discussion outside of a few people >>> - The review period was then fast tracked and began 3 days after discussion >>> ended (May 27th) >>> - The review period technically ended on June 3rd >>> - Approved with revision on June 8th >>> >>> From May 20th to June 8th (and probably before because it was clear this >>> was getting approved earlier) we have proposed, revised, and accepted a far >>> reaching syntactic change. Presumably we will be stuck with this behavior >>> for a long time or forever. This effects more than just the few that >>> participated in the discussion: it effects every swift user. >>> >>> I think this happened too fast. I do not believe we got an adequate pulse >>> of the broader swift community. >>> >>> What we got was very technical and proficient user feedback. When phrases >>> like "making the language more consistent", why wouldn't these developers >>> want to approve it? This is the kind of stuff people deeply involved in the >>> language care about. I am not sure that reflects the entire community. >>> >>> What about the more common developer who isn't as technically skilled yet? >>> This has huge changes for them too and I barely heard any of their >>> voices...at least publicly. This has big usability changes for them. >>> >>> On top of this, we have a new revised syntax that somewhat meets in the >>> middle of both sides. However, does meeting in the middle make this all >>> better just for the sake of consistency? Should we have an extended review >>> period for this proposed change or do we just accept it? >>> >>> My TLDR overview: >>> - Discussion and proposal moved extremely fast. We only heard feedback from >>> the more proficient developers and not necessarily the "common" >>> developer...which this arguably effects more. The technically skilled can >>> always adapt and of course always prefers a more consistent language...but >>> do most developers feel this way? They just want a usable and expressive >>> language >>> - WWDC is in a few days. We will get a flood of people from all different >>> backgrounds: newbies to the very skilled. My prediction: there will be >>> backlash from this proposal once more people know about it. >>> >>> I believe large syntax changes should have more discussion from more >>> developers and not a very small subset of them. The review announcement >>> needs to be broader: the swift blog needs to announce it so more people >>> know. Not everyone is on the mailing list...because frankly it can be >>> daunting for us who aren't as skilled as the others on here. >>> >>> Do I believe that the smartest people can design a great language on their >>> own? No. >>> >>> It is generally understood that most developers don't fully understand UX >>> or the end users using their stuff. I feel this is what has happened with >>> this proposal. It sounded good because it was all for the sake of >>> "consistency". However, I believe the end user will ultimately be >>> disappointed with the loss of expressivity. >>> >>> Maybe I am wrong. I hope I am wrong...but I feel we will not here the end >>> of this after WWDC begins. >>> >>> And because of that, this is why I feel the swift evolution process did not >>> work properly in this case. (And really I have this same with other fast >>> tracked proposals now). >>> >>> Really TLDR: I believe these large syntax proposals need broader feedback >>> from the community and not a small subset of the top swift developers. >>> >>> How do we pull more people in for these discussions? I don't know, but more >>> announcements on the blog and from Swift on Twitter >>> >>> Sorry for the long post, but I just wanted to express my concerns for a >>> language I was growing to really love! >>> Brandon >>> >>> >>> Sent from my iPad >>> >>> On Jun 9, 2016, at 3:53 AM, Haravikk via swift-evolution >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>>> >>>>> On 9 Jun 2016, at 02:47, Joe Groff via swift-evolution >>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>> >>>>> comma should remain the condition separator, and the 'where' keyword can >>>>> be retired from its purpose as a boolean condition introducer. >>>> >>>> Can we get some clarification as to why ‘where’ is being chosen to be >>>> retired here? I’m deeply disappointed by that decision as enabling the >>>> consistent use of comma as a separator does not preclude the use of where >>>> for simple cases that don’t require it. I’m all for having a more usable >>>> separator for complex conditionals, but I rarely need it, meanwhile in >>>> common, simple conditional bindings and patterns I find the ‘where’ >>>> keyword a lot more readable, i.e: >>>> >>>> if let value = foo where foo > 5 { … } >>>> if let value = foo, foo > 5 { … } >>>> >>>> The latter just doesn’t read as cleanly to me, and these are the kinds of >>>> simple conditionals that I use a lot of. As such as I’d still prefer to >>>> have ‘where’ be usable in the simple case, and I feel it was a mistake for >>>> the SE-0099 to have it tied to changes to the separator as the two changes >>>> aren’t mutually exclusive. >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] <mailto:[email protected]> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
