This kind of attitude is dangerous. Then why even have community reviews? It's obviously to get feedback from the community...
Sent from my iPad > On Jun 9, 2016, at 11:07 AM, L Mihalkovic <[email protected]> > wrote: > >> 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]> >>> 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]> 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]> wrote: >>>>> >>>>> >>>>>> On 9 Jun 2016, at 02:47, Joe Groff via swift-evolution >>>>>> <[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] >>>>> 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
