[swift-evolution] [Accepted with Revision] SE-0099 Restructuring Condition Clauses

[L. Mihalkovic]

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 <swift-evolution at swift.org> 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 <swift-evolution at swift.org> wrote:
>> 
>> 
>>> On 9 Jun 2016, at 02:47, Joe Groff via swift-evolution <swift-evolution at swift.org> 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
>> 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/20160609/eb863809/attachment.html>