[Accepted with Revision] SE-0099 Restructuring Condition Clauses

[Brandon_Knope]

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

···

Sent from my iPad

On Jun 9, 2016, at 10:51 AM, L. Mihalkovic <laurent.mihalkovic@gmail.com> 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 <swift-evolution@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@swift.org> wrote:

On 9 Jun 2016, at 02:47, Joe Groff via swift-evolution <swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[Christopher_Kornher1 (Christopher Kornher)]

While I preferred a different solution, here, I think that the current “do not design by committee” process is a good one, and the accepted solution is definite improvement. A consistent vision is critical to a project as complex as this. It is certainly in Apple’s DNA, and has served it, and the world, well.

This proposal is one step in achieving overarching goal: "to preserve higher-level consistency throughout the language in how components of expressions and statements are separated”

Well, if you want consistency, why not work through all the cases before freezing on one point solution? Perhaps the process should be expanded to formalize the overarching goal and put proposals like this under it. The process could be something like:

1) Propose goal, and list of point solutions, e.g. “...condition clauses..."
2) Review, refine and accept the goal
3) Work through tentative point solutions
4) Review the entire set of solutions.
5) Accept the solution set.

There is distinct possibility that working though other tasks can foster a deeper understanding and uncover better, more consistent solutions. Of course, another proposal can be created to revisit this topic, but that creates more churn. Formally reviewing overarching goals and all the aspects of achieving them could, in the long run, create a better product more efficiently and better involve and align the community.

This might slow down the rate of change in the language and libraries, but that is not necessarily a bad thing in something as complex as attempting to create a new language for a wide spectrum of applications.

This goal may be the exception, but the current process may not be optimal for complex multi-faceted problems that are on the horizon, like creating a metadata system, macros, kernel and driver software (?), ...

···

On Jun 9, 2016, at 10:16 AM, Brandon Knope via swift-evolution <swift-evolution@swift.org> wrote:

Sent from my iPad

On Jun 9, 2016, at 11:55 AM, Brent Royal-Gordon <brent@architechies.com <mailto:brent@architechies.com>> wrote:

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.

No.

Grrrr

Firstly, for those who cannot follow the list—and I can't say I blame them—the -announce list already allows them to ignore everything except the beginnings of reviews. Anyone who wants to (and who speaks English) can be notified of any significant proposed change to the language and can submit their comments for the core team's consideration. That is enough.

I think your perspective is flawed here. You are precisely one of the "top developers" I have been referring to. Am I surprised this is your opinion? Not one bit.

Mailing lists are a rather old thing...and I think many will find them daunting or maybe somewhat annoying with all of the announcements. How many people are subscribed to announce? It does not seem like many because well...we don't always get a lot of feedback. We get feedback from the same people over and over. How is this enough? How is this enough variety?

Just because "announce" is more palatable does not mean that it is being used in the way you are describing.

Maybe there is another problem then: people afraid to share their opinions publicly. I wonder why this would be.

The purpose of reviews is not to cast ballots for or against a feature. It is to submit arguments, for and against, for the core team to consider as they decide whether and how to address the problem the proposal's "Motivation" section describes. For that purpose, there is no need to collect hundreds or thousands of reviews, and if we did, the review manager would be swamped anyway. It is enough to get a reasonable variety of eyes, from a reasonable variety of perspectives, on the problem.

Why do people keep saying I am asking for: "hundreds or thousands" of reviews? I am just asking for something like 20 - 25 unique people's feedback. We are not getting that. We get the same people over and over...which makes the feedback seem screwed to this small group's philosophies.

Getting feedback from the same ~10 people is not a "reasonable variety of eyes" in my opinion. That is a very small sample. And that sample is usually those who are very technically skilled...who I would say do not always design the best interfaces.

I think that has happened here. We have not heard from every perspective, but we have heard from enough of them that adding more will not help all that much. Feedback always has diminishing returns: going from one person to two is far more valuable than going from fifty-one to fifty-two.

I think you will be very surprised come WWDC when people learn of this change.

How is there value when the same people keep justifying changes for the sake of consistency? Is this in the user's best interest? Or is this in the swift engineer's best interest?

This is precisely why I think more feedback is important. We need more than just the same people propping up proposals that gives an illusion that it is representative of everyone using swift.

The bar should be high for changing syntax, so I don't buy the argument that 25 people sharing their feedback is somehow less valuable than 10 people sharing.

And in particular, I *don't* think the beginner perspective is an especially worrisome one for this particular proposal.

I don't think this was though through thoroughly enough. It just happened too fast

Though some of the syntaxes we considered might have been confusing for beginners (*cough*semicolon*cough*), the one the core team settled in is actually one of the simplest, and certainly much simpler than the status quo. If anything, the people most disadvantaged by this solution are the power users who are used to the "multiple if-let" shorthand and will now have to add extra keywords to their code.

Maybe you are right. Maybe I am vastly wrong. But I guess this will be clearer come WWDC.

And I already know how the people complaining about this change will be silenced: it was done for the consistency of the language and the grammar.

How can us simpletons argue against that?

Also, I want to make clear that my concern is not just for this review but for future reviews also. How different could the language look with more varied feedback?

Again, I hope I am wrong =/
Brandon

--
Brent Royal-Gordon
Architechies

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[Ethan_Eberle]

Hi Brandon –

I’ll try to speak for one of those ‘newer’ developers (I’ve only got ~1 year of experience in dev work and it’s all part time as a hobby), although my views obviously only reflect my own.

I also had a similar ‘gut’ reaction to the approval but after re-reading it several times the change is surprisingly minor. At its core, the proposal just involves adding extra ‘lets’ and ‘cases’ to the syntax. I think this is a great solution that avoids the need for semi-colons or some new delimiter (I first learned to code in Python and semicolons are anathema in my mind). It also removes the arbitrary use of “where” (I didn’t even know this was possible). I’d prefer we allow the use of “where” when the constraint applies only to the unwrapped item immediately preceding it, but such is life [1]. (Core Team – I’ll look forward to reading the revised accepted proposal, I’m still confused about a few of the details).

In terms of the broader review process, it’s predicated upon users providing timely feedback during the official review period – which went on for the proscribed time. The core team clearly put much thought into this since it took longer than usual, on balance, to announce their decision. I would add that the only time an accepted proposal should be ‘overturned’ is if the implementation turns out to be too complicated or if there were other downstream affects that weren’t previously discovered in the review process (we’ve already seen a bit of this). If everything is continually revisited, then there will be next to no forward progress.

That said, the one process improvement I have is that proposals should ideally only be “Accepted” by the core team as it is originally written (or with relatively minor changes) or completely “Rejected”. The “Accepted with Revision” approach can result in new ideas being approved but not being fully vetted by the community. This also eliminates needless "surprises", which is always good. Proposal are either accepted or rejected, nothing in between. I actually think this approach is win-win for the core team and the community – although the ultimate decision to reject or approve a proposal must rest with the Core Team.

I'm For this reason, I think in this case it *might* be tenable to “re-visit” this proposal (say, after WWDC) once Chris puts the accepted version's language on GitHub. It could also be evaluated within the broader context of removing (or retaining) 'where' elsewhere in the language (see Erica's proposal), though for scoping purposes the proposals should remain separate. If it is re-visited, I’m no compiler/language expert but it seems like you could unambiguously permit the use of ‘where’ in the specific cases I mentioned earlier. It’s purely syntactic sugar and “burns” a keyword but is a nice optional expressivity feature, and I remember seeing some Core Team members showing interest in it. Maybe this approach is the best of both worlds? :D

“I just wanted to express my concerns for a language I was growing to really love!”
      -> Hopefully you’ll continue to love it :)

Just my two cents,
Ethan

[1] Swift is indeed an opinionated language.

···

Sent from my iPhone.

On Jun 9, 2016, at 12:16 PM, Brandon Knope via swift-evolution <swift-evolution@swift.org> wrote:

Sent from my iPad

On Jun 9, 2016, at 11:55 AM, Brent Royal-Gordon <brent@architechies.com> wrote:

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.

No.

Grrrr

Firstly, for those who cannot follow the list—and I can't say I blame them—the -announce list already allows them to ignore everything except the beginnings of reviews. Anyone who wants to (and who speaks English) can be notified of any significant proposed change to the language and can submit their comments for the core team's consideration. That is enough.

I think your perspective is flawed here. You are precisely one of the "top developers" I have been referring to. Am I surprised this is your opinion? Not one bit.

Mailing lists are a rather old thing...and I think many will find them daunting or maybe somewhat annoying with all of the announcements. How many people are subscribed to announce? It does not seem like many because well...we don't always get a lot of feedback. We get feedback from the same people over and over. How is this enough? How is this enough variety?

Just because "announce" is more palatable does not mean that it is being used in the way you are describing.

Maybe there is another problem then: people afraid to share their opinions publicly. I wonder why this would be.

The purpose of reviews is not to cast ballots for or against a feature. It is to submit arguments, for and against, for the core team to consider as they decide whether and how to address the problem the proposal's "Motivation" section describes. For that purpose, there is no need to collect hundreds or thousands of reviews, and if we did, the review manager would be swamped anyway. It is enough to get a reasonable variety of eyes, from a reasonable variety of perspectives, on the problem.

Why do people keep saying I am asking for: "hundreds or thousands" of reviews? I am just asking for something like 20 - 25 unique people's feedback. We are not getting that. We get the same people over and over...which makes the feedback seem screwed to this small group's philosophies.

Getting feedback from the same ~10 people is not a "reasonable variety of eyes" in my opinion. That is a very small sample. And that sample is usually those who are very technically skilled...who I would say do not always design the best interfaces.

I think that has happened here. We have not heard from every perspective, but we have heard from enough of them that adding more will not help all that much. Feedback always has diminishing returns: going from one person to two is far more valuable than going from fifty-one to fifty-two.

I think you will be very surprised come WWDC when people learn of this change.

How is there value when the same people keep justifying changes for the sake of consistency? Is this in the user's best interest? Or is this in the swift engineer's best interest?

This is precisely why I think more feedback is important. We need more than just the same people propping up proposals that gives an illusion that it is representative of everyone using swift.

The bar should be high for changing syntax, so I don't buy the argument that 25 people sharing their feedback is somehow less valuable than 10 people sharing.

And in particular, I *don't* think the beginner perspective is an especially worrisome one for this particular proposal.

I don't think this was though through thoroughly enough. It just happened too fast

Though some of the syntaxes we considered might have been confusing for beginners (*cough*semicolon*cough*), the one the core team settled in is actually one of the simplest, and certainly much simpler than the status quo. If anything, the people most disadvantaged by this solution are the power users who are used to the "multiple if-let" shorthand and will now have to add extra keywords to their code.

Maybe you are right. Maybe I am vastly wrong. But I guess this will be clearer come WWDC.

And I already know how the people complaining about this change will be silenced: it was done for the consistency of the language and the grammar.

How can us simpletons argue against that?

Also, I want to make clear that my concern is not just for this review but for future reviews also. How different could the language look with more varied feedback?

Again, I hope I am wrong =/
Brandon

--
Brent Royal-Gordon
Architechies

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[Brandon_Knope]

While I preferred a different solution, here, I think that the current “do not design by committee” process is a good one, and the accepted solution is definite improvement. A consistent vision is critical to a project as complex as this. It is certainly in Apple’s DNA, and has served it, and the world, well.

I agree mostly…consistency is nice but a little character is also nice too:

new:
if let x = x, x > 5 {

}

old:
if let x = x where x > 5 {

}

To me the old way has more character and expressivity than the new way. This is where I think being 100% consistent can lead to a stale language void of character if taken too far.

This proposal is one step in achieving overarching goal: "to preserve higher-level consistency throughout the language in how components of expressions and statements are separated”

This is the one argument to end it all in my opinion. However, with the removal of where from conditionals, we are still *not* consistent:
- where in case conditions
- where in for loops
- where in while loops
- where used in constraints

Will we now move from:
func allItemsMatch<C1: Container, C2: Container where C1.ItemType == C2.ItemType, C1.ItemType: Equatable>
    (someContainer: C1, _ anotherContainer: C2) -> Bool

To:
func allItemsMatch<C1: Container, C2: Container, C1.ItemType == C2.ItemType, C1.ItemType: Equatable>
    (someContainer: C1, _ anotherContainer: C2) -> Bool

at some point? Or more accurately now:
func allItemsMatch<C1: Container, C2: Container>
    (someContainer: C1, _ anotherContainer: C2) -> Bool, C1.ItemType == C2.ItemType, C1.ItemType: Equatable

Where has been used to make constraints more expressive, but now that we have removed it from some places, are we even consistent now? where works in some places and not other places. That seems inconsistent to me now.

Well, if you want consistency, why not work through all the cases before freezing on one point solution? Perhaps the process should be expanded to formalize the overarching goal and put proposals like this under it. The process could be something like:

1) Propose goal, and list of point solutions, e.g. “...condition clauses..."
2) Review, refine and accept the goal
3) Work through tentative point solutions
4) Review the entire set of solutions.
5) Accept the solution set.

There is distinct possibility that working though other tasks can foster a deeper understanding and uncover better, more consistent solutions. Of course, another proposal can be created to revisit this topic, but that creates more churn. Formally reviewing overarching goals and all the aspects of achieving them could, in the long run, create a better product more efficiently and better involve and align the community.

I agree 100% and expresses some of my deep concern. Especially for syntax changes.

This might slow down the rate of change in the language and libraries, but that is not necessarily a bad thing in something as complex as attempting to create a new language for a wide spectrum of applications.

Agreed. Moving too fast? Maybe. The core team is so smart, I just hope they aren’t juggling too much.

This goal may be the exception, but the current process may not be optimal for complex multi-faceted problems that are on the horizon, like creating a metadata system, macros, kernel and driver software (?), …

It will sure be interesting what happens after Swift 3!

Brandon

···

On Jun 9, 2016, at 1:04 PM, Christopher Kornher <ckornher@me.com> wrote:

On Jun 9, 2016, at 10:16 AM, Brandon Knope via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Sent from my iPad

On Jun 9, 2016, at 11:55 AM, Brent Royal-Gordon <brent@architechies.com <mailto:brent@architechies.com>> wrote:

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.

No.

Grrrr

Firstly, for those who cannot follow the list—and I can't say I blame them—the -announce list already allows them to ignore everything except the beginnings of reviews. Anyone who wants to (and who speaks English) can be notified of any significant proposed change to the language and can submit their comments for the core team's consideration. That is enough.

I think your perspective is flawed here. You are precisely one of the "top developers" I have been referring to. Am I surprised this is your opinion? Not one bit.

Mailing lists are a rather old thing...and I think many will find them daunting or maybe somewhat annoying with all of the announcements. How many people are subscribed to announce? It does not seem like many because well...we don't always get a lot of feedback. We get feedback from the same people over and over. How is this enough? How is this enough variety?

Just because "announce" is more palatable does not mean that it is being used in the way you are describing.

Maybe there is another problem then: people afraid to share their opinions publicly. I wonder why this would be.

The purpose of reviews is not to cast ballots for or against a feature. It is to submit arguments, for and against, for the core team to consider as they decide whether and how to address the problem the proposal's "Motivation" section describes. For that purpose, there is no need to collect hundreds or thousands of reviews, and if we did, the review manager would be swamped anyway. It is enough to get a reasonable variety of eyes, from a reasonable variety of perspectives, on the problem.

Why do people keep saying I am asking for: "hundreds or thousands" of reviews? I am just asking for something like 20 - 25 unique people's feedback. We are not getting that. We get the same people over and over...which makes the feedback seem screwed to this small group's philosophies.

Getting feedback from the same ~10 people is not a "reasonable variety of eyes" in my opinion. That is a very small sample. And that sample is usually those who are very technically skilled...who I would say do not always design the best interfaces.

I think that has happened here. We have not heard from every perspective, but we have heard from enough of them that adding more will not help all that much. Feedback always has diminishing returns: going from one person to two is far more valuable than going from fifty-one to fifty-two.

I think you will be very surprised come WWDC when people learn of this change.

How is there value when the same people keep justifying changes for the sake of consistency? Is this in the user's best interest? Or is this in the swift engineer's best interest?

This is precisely why I think more feedback is important. We need more than just the same people propping up proposals that gives an illusion that it is representative of everyone using swift.

The bar should be high for changing syntax, so I don't buy the argument that 25 people sharing their feedback is somehow less valuable than 10 people sharing.

And in particular, I *don't* think the beginner perspective is an especially worrisome one for this particular proposal.

I don't think this was though through thoroughly enough. It just happened too fast

Though some of the syntaxes we considered might have been confusing for beginners (*cough*semicolon*cough*), the one the core team settled in is actually one of the simplest, and certainly much simpler than the status quo. If anything, the people most disadvantaged by this solution are the power users who are used to the "multiple if-let" shorthand and will now have to add extra keywords to their code.

Maybe you are right. Maybe I am vastly wrong. But I guess this will be clearer come WWDC.

And I already know how the people complaining about this change will be silenced: it was done for the consistency of the language and the grammar.

How can us simpletons argue against that?

Also, I want to make clear that my concern is not just for this review but for future reviews also. How different could the language look with more varied feedback?

Again, I hope I am wrong =/
Brandon

--
Brent Royal-Gordon
Architechies

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

[L_Mihalkovic]

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.

···

On Jun 9, 2016, at 4:59 PM, Brandon Knope <bknope@me.com> wrote:

Sent from my iPad

On Jun 9, 2016, at 10:51 AM, L. Mihalkovic <laurent.mihalkovic@gmail.com <mailto:laurent.mihalkovic@gmail.com>> 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 <swift-evolution@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>> wrote:

On 9 Jun 2016, at 02:47, Joe Groff via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

[L_Mihalkovic]

Sent from my iPad

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.

No.

Grrrr

Firstly, for those who cannot follow the list—and I can't say I blame them—the -announce list already allows them to ignore everything except the beginnings of reviews. Anyone who wants to (and who speaks English) can be notified of any significant proposed change to the language and can submit their comments for the core team's consideration. That is enough.

I think your perspective is flawed here. You are precisely one of the "top developers" I have been referring to. Am I surprised this is your opinion? Not one bit.

But if you followed the email trail you must have noticed that the final choice was not what brent supported. I would even say that it was not any of the solutions anyone proposed.. Proof that the process worked, the team made a change nobody anticipated, yet many people can (partially) identify with.

···

On Jun 9, 2016, at 6:16 PM, Brandon Knope via swift-evolution <swift-evolution@swift.org> wrote:
On Jun 9, 2016, at 11:55 AM, Brent Royal-Gordon <brent@architechies.com> wrote:

Mailing lists are a rather old thing...and I think many will find them daunting or maybe somewhat annoying with all of the announcements. How many people are subscribed to announce? It does not seem like many because well...we don't always get a lot of feedback. We get feedback from the same people over and over. How is this enough? How is this enough variety?

Just because "announce" is more palatable does not mean that it is being used in the way you are describing.

Maybe there is another problem then: people afraid to share their opinions publicly. I wonder why this would be.

The purpose of reviews is not to cast ballots for or against a feature. It is to submit arguments, for and against, for the core team to consider as they decide whether and how to address the problem the proposal's "Motivation" section describes. For that purpose, there is no need to collect hundreds or thousands of reviews, and if we did, the review manager would be swamped anyway. It is enough to get a reasonable variety of eyes, from a reasonable variety of perspectives, on the problem.

Why do people keep saying I am asking for: "hundreds or thousands" of reviews? I am just asking for something like 20 - 25 unique people's feedback. We are not getting that. We get the same people over and over...which makes the feedback seem screwed to this small group's philosophies.

Getting feedback from the same ~10 people is not a "reasonable variety of eyes" in my opinion. That is a very small sample. And that sample is usually those who are very technically skilled...who I would say do not always design the best interfaces.

I think that has happened here. We have not heard from every perspective, but we have heard from enough of them that adding more will not help all that much. Feedback always has diminishing returns: going from one person to two is far more valuable than going from fifty-one to fifty-two.

I think you will be very surprised come WWDC when people learn of this change.

How is there value when the same people keep justifying changes for the sake of consistency? Is this in the user's best interest? Or is this in the swift engineer's best interest?

This is precisely why I think more feedback is important. We need more than just the same people propping up proposals that gives an illusion that it is representative of everyone using swift.

The bar should be high for changing syntax, so I don't buy the argument that 25 people sharing their feedback is somehow less valuable than 10 people sharing.

And in particular, I *don't* think the beginner perspective is an especially worrisome one for this particular proposal.

I don't think this was though through thoroughly enough. It just happened too fast

Though some of the syntaxes we considered might have been confusing for beginners (*cough*semicolon*cough*), the one the core team settled in is actually one of the simplest, and certainly much simpler than the status quo. If anything, the people most disadvantaged by this solution are the power users who are used to the "multiple if-let" shorthand and will now have to add extra keywords to their code.

Maybe you are right. Maybe I am vastly wrong. But I guess this will be clearer come WWDC.

And I already know how the people complaining about this change will be silenced: it was done for the consistency of the language and the grammar.

How can us simpletons argue against that?

Also, I want to make clear that my concern is not just for this review but for future reviews also. How different could the language look with more varied feedback?

Again, I hope I am wrong =/
Brandon

--
Brent Royal-Gordon
Architechies

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[Brandon_Knope]

While I did not get a chance to review all the discussion in time to
respond to the proposal, I am happy with the revised version that was
approved (the semi-colons were a point of concern for me). In addition
to resolving ambiguity, this also resolved a pedigogical issue
surrounding the 'where' keyword I encountered when teaching Swift.

'where' keyword can be retired from its purpose as a boolean condition
introducer.

When teaching Swift, I did discover that the requirement of 'where' in
conditionals as expressed by this proposal was confusing and those I was
teaching assumed they would use commas (or &&).

I completely understand this, but isn’t this because they just didn’t know the syntax existed?

After they learned about it, did they understand it? Did they like it? Hate it? That’s what I am very interested in hearing about

I'll admit that at first the 'where' keyword surprised me as well, but I
grew to like it and will be a little sad to see it replaced by comma
instead of allowing 'where' or comma as I thought certain statements
were easier to read with 'where’.

Exactly :/

Brandon

···

On Jun 10, 2016, at 1:47 PM, Roth Michaels via swift-evolution <swift-evolution@swift.org> wrote:
On Wed, Jun 08 2016 at 09:47:55 PM, Joe Groff via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Thu, Jun 09 2016 at 06:30:17 AM, Haravikk via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

   On 9 Jun 2016, at 09:47, Brent Royal-Gordon >> <brent@architechies.com> wrote:

       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 { … }

   I think there may be a case for keeping the `where` keyword—but
   before, not after, the equals sign.

   if case .cartesian(let x, let y) where x != y = point { ... }
   if let value where value > 5 = foo { … }

That looks pretty strange visually though thanks to the assignment (it
kind of looks like x is being compared against y = point).

I had this feeling as well.

While my reasons for liking where are mainly aesthetic once the need to
use it to get around separator issues goes away, it’s still a nice tool
for grouping statements visually, for example:

This is the case for me as well, functionally I suppose I will not miss
'where', but for aesthetics I do think it made some statements cmore
clear to read.

--
Roth

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

[Brandon_Knope]

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 <laurent.mihalkovic@gmail.com> wrote:

On Jun 9, 2016, at 4:59 PM, Brandon Knope <bknope@me.com> 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 <laurent.mihalkovic@gmail.com> 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 <swift-evolution@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@swift.org> wrote:

On 9 Jun 2016, at 02:47, Joe Groff via swift-evolution <swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[Ethan_Eberle]

Hi Brandon –

I’ll try to speak for one of those ‘newer’ developers (I’ve only got ~1 year of experience in dev work and it’s all part time as a hobby), although my views obviously only reflect my own.

I also had a similar ‘gut’ reaction to the approval but after re-reading it several times the change is surprisingly minor. At its core, the proposal just involves adding extra ‘lets’ and ‘cases’ to the syntax. I think this is a great solution that avoids the need for semi-colons or some new delimiter (I first learned to code in Python and semicolons are anathema in my mind). It also removes the arbitrary use of “where” (I didn’t even know this was possible). I’d prefer we allow the use of “where” when the constraint applies only to the unwrapped item immediately preceding it, but such is life [1]. (Core Team – I’ll look forward to reading the revised accepted proposal, I’m still confused about a few of the details).

In terms of the broader review process, it’s predicated upon users providing timely feedback during the official review period – which went on for the proscribed time. The core team clearly put much thought into this since it took longer than usual, on balance, to announce their decision. I would add that the only time an accepted proposal should be ‘overturned’ is if the implementation turns out to be too complicated or if there were other downstream affects that weren’t previously discovered in the review process (we’ve already seen a bit of this). If everything is continually revisited, then there will be next to no forward progress.

That said, the one process improvement I have is that proposals should ideally only be “Accepted” by the core team as it is originally written (or with relatively minor changes) or completely “Rejected”. The “Accepted with Revision” approach can result in new ideas being approved but not being fully vetted by the community. This also eliminates needless "surprises", which is always good. Proposal are either accepted or rejected, nothing in between. I actually think this approach is win-win for the core team and the community – although the ultimate decision to reject or approve a proposal must rest with the Core Team. For this reason, I think in this case it *might* be tenable to “re-visit” this proposal (say, after WWDC) once Chris puts the accepted version's language on GitHub. It could also be evaluated within the broader context of removing (or retaining) 'where' elsewhere in the language (see Erica's proposal), though for scoping purposes the proposals should remain separate. If it is re-visited, I’m no compiler/language expert but it seems like you could unambiguously permit the use of ‘where’ in the specific cases I mentioned earlier. It’s purely syntactic sugar and “burns” a keyword but is a nice optional expressivity feature, and I remember seeing some Core Team members showing interest in it. Maybe this approach is the best of both worlds? :D

“I just wanted to express my concerns for a language I was growing to really love!”
      -> Hopefully you’ll continue to love it :)

Just my two cents,
Ethan

[1] Swift is indeed an opinionated language.

···

Sent from my iPhone.

On Jun 9, 2016, at 12:35 PM, L. Mihalkovic via swift-evolution <swift-evolution@swift.org> wrote:

On Jun 9, 2016, at 6:16 PM, Brandon Knope via swift-evolution <swift-evolution@swift.org> wrote:

Sent from my iPad

On Jun 9, 2016, at 11:55 AM, Brent Royal-Gordon <brent@architechies.com> wrote:

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.

No.

Grrrr

Firstly, for those who cannot follow the list—and I can't say I blame them—the -announce list already allows them to ignore everything except the beginnings of reviews. Anyone who wants to (and who speaks English) can be notified of any significant proposed change to the language and can submit their comments for the core team's consideration. That is enough.

I think your perspective is flawed here. You are precisely one of the "top developers" I have been referring to. Am I surprised this is your opinion? Not one bit.

But if you followed the email trail you must have noticed that the final choice was not what brent supported. I would even say that it was not any of the solutions anyone proposed.. Proof that the process worked, the team made a change nobody anticipated, yet many people can (partially) identify with.

Mailing lists are a rather old thing...and I think many will find them daunting or maybe somewhat annoying with all of the announcements. How many people are subscribed to announce? It does not seem like many because well...we don't always get a lot of feedback. We get feedback from the same people over and over. How is this enough? How is this enough variety?

Just because "announce" is more palatable does not mean that it is being used in the way you are describing.

Maybe there is another problem then: people afraid to share their opinions publicly. I wonder why this would be.

The purpose of reviews is not to cast ballots for or against a feature. It is to submit arguments, for and against, for the core team to consider as they decide whether and how to address the problem the proposal's "Motivation" section describes. For that purpose, there is no need to collect hundreds or thousands of reviews, and if we did, the review manager would be swamped anyway. It is enough to get a reasonable variety of eyes, from a reasonable variety of perspectives, on the problem.

Why do people keep saying I am asking for: "hundreds or thousands" of reviews? I am just asking for something like 20 - 25 unique people's feedback. We are not getting that. We get the same people over and over...which makes the feedback seem screwed to this small group's philosophies.

Getting feedback from the same ~10 people is not a "reasonable variety of eyes" in my opinion. That is a very small sample. And that sample is usually those who are very technically skilled...who I would say do not always design the best interfaces.

I think that has happened here. We have not heard from every perspective, but we have heard from enough of them that adding more will not help all that much. Feedback always has diminishing returns: going from one person to two is far more valuable than going from fifty-one to fifty-two.

I think you will be very surprised come WWDC when people learn of this change.

How is there value when the same people keep justifying changes for the sake of consistency? Is this in the user's best interest? Or is this in the swift engineer's best interest?

This is precisely why I think more feedback is important. We need more than just the same people propping up proposals that gives an illusion that it is representative of everyone using swift.

The bar should be high for changing syntax, so I don't buy the argument that 25 people sharing their feedback is somehow less valuable than 10 people sharing.

And in particular, I *don't* think the beginner perspective is an especially worrisome one for this particular proposal.

I don't think this was though through thoroughly enough. It just happened too fast

Though some of the syntaxes we considered might have been confusing for beginners (*cough*semicolon*cough*), the one the core team settled in is actually one of the simplest, and certainly much simpler than the status quo. If anything, the people most disadvantaged by this solution are the power users who are used to the "multiple if-let" shorthand and will now have to add extra keywords to their code.

Maybe you are right. Maybe I am vastly wrong. But I guess this will be clearer come WWDC.

And I already know how the people complaining about this change will be silenced: it was done for the consistency of the language and the grammar.

How can us simpletons argue against that?

Also, I want to make clear that my concern is not just for this review but for future reviews also. How different could the language look with more varied feedback?

Again, I hope I am wrong =/
Brandon

--
Brent Royal-Gordon
Architechies

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[Brandon_Knope]

Proof? That remains to be seen as I have said.

Also, I followed the email thread very closely. What I am saying is that I am not surprised that Brent supports this ultimate proposal not that this is what Brent supported originally.

Brandon

···

Sent from my iPad

On Jun 9, 2016, at 12:35 PM, L. Mihalkovic <laurent.mihalkovic@gmail.com> wrote:

On Jun 9, 2016, at 6:16 PM, Brandon Knope via swift-evolution <swift-evolution@swift.org> wrote:

Sent from my iPad

On Jun 9, 2016, at 11:55 AM, Brent Royal-Gordon <brent@architechies.com> wrote:

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.

No.

Grrrr

Firstly, for those who cannot follow the list—and I can't say I blame them—the -announce list already allows them to ignore everything except the beginnings of reviews. Anyone who wants to (and who speaks English) can be notified of any significant proposed change to the language and can submit their comments for the core team's consideration. That is enough.

I think your perspective is flawed here. You are precisely one of the "top developers" I have been referring to. Am I surprised this is your opinion? Not one bit.

But if you followed the email trail you must have noticed that the final choice was not what brent supported. I would even say that it was not any of the solutions anyone proposed.. Proof that the process worked, the team made a change nobody anticipated, yet many people can (partially) identify with.

Mailing lists are a rather old thing...and I think many will find them daunting or maybe somewhat annoying with all of the announcements. How many people are subscribed to announce? It does not seem like many because well...we don't always get a lot of feedback. We get feedback from the same people over and over. How is this enough? How is this enough variety?

Just because "announce" is more palatable does not mean that it is being used in the way you are describing.

Maybe there is another problem then: people afraid to share their opinions publicly. I wonder why this would be.

The purpose of reviews is not to cast ballots for or against a feature. It is to submit arguments, for and against, for the core team to consider as they decide whether and how to address the problem the proposal's "Motivation" section describes. For that purpose, there is no need to collect hundreds or thousands of reviews, and if we did, the review manager would be swamped anyway. It is enough to get a reasonable variety of eyes, from a reasonable variety of perspectives, on the problem.

Why do people keep saying I am asking for: "hundreds or thousands" of reviews? I am just asking for something like 20 - 25 unique people's feedback. We are not getting that. We get the same people over and over...which makes the feedback seem screwed to this small group's philosophies.

Getting feedback from the same ~10 people is not a "reasonable variety of eyes" in my opinion. That is a very small sample. And that sample is usually those who are very technically skilled...who I would say do not always design the best interfaces.

I think that has happened here. We have not heard from every perspective, but we have heard from enough of them that adding more will not help all that much. Feedback always has diminishing returns: going from one person to two is far more valuable than going from fifty-one to fifty-two.

I think you will be very surprised come WWDC when people learn of this change.

How is there value when the same people keep justifying changes for the sake of consistency? Is this in the user's best interest? Or is this in the swift engineer's best interest?

This is precisely why I think more feedback is important. We need more than just the same people propping up proposals that gives an illusion that it is representative of everyone using swift.

The bar should be high for changing syntax, so I don't buy the argument that 25 people sharing their feedback is somehow less valuable than 10 people sharing.

And in particular, I *don't* think the beginner perspective is an especially worrisome one for this particular proposal.

I don't think this was though through thoroughly enough. It just happened too fast

Though some of the syntaxes we considered might have been confusing for beginners (*cough*semicolon*cough*), the one the core team settled in is actually one of the simplest, and certainly much simpler than the status quo. If anything, the people most disadvantaged by this solution are the power users who are used to the "multiple if-let" shorthand and will now have to add extra keywords to their code.

Maybe you are right. Maybe I am vastly wrong. But I guess this will be clearer come WWDC.

And I already know how the people complaining about this change will be silenced: it was done for the consistency of the language and the grammar.

How can us simpletons argue against that?

Also, I want to make clear that my concern is not just for this review but for future reviews also. How different could the language look with more varied feedback?

Again, I hope I am wrong =/
Brandon

--
Brent Royal-Gordon
Architechies

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[Brandon_Knope]

Thanks for the thoughtful feedback :)

I partially agree with you on Accepted with Revision...however this could potentially slow down things significantly. I think syntax changes should work the way you describe however as they are more far reaching.

I still love Swift, I am just stung by the loss of some of its character for the sake of consistency. But it is not the end of the world. I just worry about the future if we don't get more varied feedback.

I would love for where to have a place with its expressivity, but I doubt it at this point. My concern has more to do with the little feedback we get from the community with some of these big changes

Brandon

···

Sent from my iPad

On Jun 9, 2016, at 12:53 PM, Ethan Eberle <ethandeberle@gmail.com> wrote:

Hi Brandon –

I’ll try to speak for one of those ‘newer’ developers (I’ve only got ~1 year of experience in dev work and it’s all part time as a hobby), although my views obviously only reflect my own.

I also had a similar ‘gut’ reaction to the approval but after re-reading it several times the change is surprisingly minor. At its core, the proposal just involves adding extra ‘lets’ and ‘cases’ to the syntax. I think this is a great solution that avoids the need for semi-colons or some new delimiter (I first learned to code in Python and semicolons are anathema in my mind). It also removes the arbitrary use of “where” (I didn’t even know this was possible). I’d prefer we allow the use of “where” when the constraint applies only to the unwrapped item immediately preceding it, but such is life [1]. (Core Team – I’ll look forward to reading the revised accepted proposal, I’m still confused about a few of the details).

In terms of the broader review process, it’s predicated upon users providing timely feedback during the official review period – which went on for the proscribed time. The core team clearly put much thought into this since it took longer than usual, on balance, to announce their decision. I would add that the only time an accepted proposal should be ‘overturned’ is if the implementation turns out to be too complicated or if there were other downstream affects that weren’t previously discovered in the review process (we’ve already seen a bit of this). If everything is continually revisited, then there will be next to no forward progress.

That said, the one process improvement I have is that proposals should ideally only be “Accepted” by the core team as it is originally written (or with relatively minor changes) or completely “Rejected”. The “Accepted with Revision” approach can result in new ideas being approved but not being fully vetted by the community. This also eliminates needless "surprises", which is always good. Proposal are either accepted or rejected, nothing in between. I actually think this approach is win-win for the core team and the community – although the ultimate decision to reject or approve a proposal must rest with the Core Team. For this reason, I think in this case it *might* be tenable to “re-visit” this proposal (say, after WWDC) once Chris puts the accepted version's language on GitHub. It could also be evaluated within the broader context of removing (or retaining) 'where' elsewhere in the language (see Erica's proposal), though for scoping purposes the proposals should remain separate. If it is re-visited, I’m no compiler/language expert but it seems like you could unambiguously permit the use of ‘where’ in the specific cases I mentioned earlier. It’s purely syntactic sugar and “burns” a keyword but is a nice optional expressivity feature, and I remember seeing some Core Team members showing interest in it. Maybe this approach is the best of both worlds? :D

“I just wanted to express my concerns for a language I was growing to really love!”
      -> Hopefully you’ll continue to love it :)

Just my two cents,
Ethan

[1] Swift is indeed an opinionated language.

Sent from my iPhone.

On Jun 9, 2016, at 12:35 PM, L. Mihalkovic via swift-evolution <swift-evolution@swift.org> wrote:

On Jun 9, 2016, at 6:16 PM, Brandon Knope via swift-evolution <swift-evolution@swift.org> wrote:

Sent from my iPad

On Jun 9, 2016, at 11:55 AM, Brent Royal-Gordon <brent@architechies.com> wrote:

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.

No.

Grrrr

Firstly, for those who cannot follow the list—and I can't say I blame them—the -announce list already allows them to ignore everything except the beginnings of reviews. Anyone who wants to (and who speaks English) can be notified of any significant proposed change to the language and can submit their comments for the core team's consideration. That is enough.

I think your perspective is flawed here. You are precisely one of the "top developers" I have been referring to. Am I surprised this is your opinion? Not one bit.

But if you followed the email trail you must have noticed that the final choice was not what brent supported. I would even say that it was not any of the solutions anyone proposed.. Proof that the process worked, the team made a change nobody anticipated, yet many people can (partially) identify with.

Mailing lists are a rather old thing...and I think many will find them daunting or maybe somewhat annoying with all of the announcements. How many people are subscribed to announce? It does not seem like many because well...we don't always get a lot of feedback. We get feedback from the same people over and over. How is this enough? How is this enough variety?

Just because "announce" is more palatable does not mean that it is being used in the way you are describing.

Maybe there is another problem then: people afraid to share their opinions publicly. I wonder why this would be.

The purpose of reviews is not to cast ballots for or against a feature. It is to submit arguments, for and against, for the core team to consider as they decide whether and how to address the problem the proposal's "Motivation" section describes. For that purpose, there is no need to collect hundreds or thousands of reviews, and if we did, the review manager would be swamped anyway. It is enough to get a reasonable variety of eyes, from a reasonable variety of perspectives, on the problem.

Why do people keep saying I am asking for: "hundreds or thousands" of reviews? I am just asking for something like 20 - 25 unique people's feedback. We are not getting that. We get the same people over and over...which makes the feedback seem screwed to this small group's philosophies.

Getting feedback from the same ~10 people is not a "reasonable variety of eyes" in my opinion. That is a very small sample. And that sample is usually those who are very technically skilled...who I would say do not always design the best interfaces.

I think that has happened here. We have not heard from every perspective, but we have heard from enough of them that adding more will not help all that much. Feedback always has diminishing returns: going from one person to two is far more valuable than going from fifty-one to fifty-two.

I think you will be very surprised come WWDC when people learn of this change.

How is there value when the same people keep justifying changes for the sake of consistency? Is this in the user's best interest? Or is this in the swift engineer's best interest?

This is precisely why I think more feedback is important. We need more than just the same people propping up proposals that gives an illusion that it is representative of everyone using swift.

The bar should be high for changing syntax, so I don't buy the argument that 25 people sharing their feedback is somehow less valuable than 10 people sharing.

And in particular, I *don't* think the beginner perspective is an especially worrisome one for this particular proposal.

I don't think this was though through thoroughly enough. It just happened too fast

Though some of the syntaxes we considered might have been confusing for beginners (*cough*semicolon*cough*), the one the core team settled in is actually one of the simplest, and certainly much simpler than the status quo. If anything, the people most disadvantaged by this solution are the power users who are used to the "multiple if-let" shorthand and will now have to add extra keywords to their code.

Maybe you are right. Maybe I am vastly wrong. But I guess this will be clearer come WWDC.

And I already know how the people complaining about this change will be silenced: it was done for the consistency of the language and the grammar.

How can us simpletons argue against that?

Also, I want to make clear that my concern is not just for this review but for future reviews also. How different could the language look with more varied feedback?

Again, I hope I am wrong =/
Brandon

--
Brent Royal-Gordon
Architechies

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[Taras_Zakharko1 (Taras Zakharko)]

That said, the one process improvement I have is that proposals should ideally only be “Accepted” by the core team as it is originally written (or with relatively minor changes) or completely “Rejected”. The “Accepted with Revision” approach can result in new ideas being approved but not being fully vetted by the community. This also eliminates needless "surprises", which is always good. Proposal are either accepted or rejected, nothing in between. I actually think this approach is win-win for the core team and the community – although the ultimate decision to reject or approve a proposal must rest with the Core Team.

I disagree, for practical reasons. There is only a limited time that the Swift team can spend looking at proposals. We already have the situation where a lot of important features (like the full-feature generics) are being postponed from Swift 3. While it is true that your suggestion would result in a more transparent review process, it would also vastly increase the amount of time until the decision is reached.

The core team has shown over and over again that it is able to make very sane and reasonable decisions, which wouldn’t be made if the community reviews would be the only source of input.

Best,

Taras

···

On 09 Jun 2016, at 18:53, Ethan Eberle via swift-evolution <swift-evolution@swift.org> wrote:

Sent from my iPhone.

On Jun 9, 2016, at 12:35 PM, L. Mihalkovic via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Jun 9, 2016, at 6:16 PM, Brandon Knope via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Sent from my iPad

On Jun 9, 2016, at 11:55 AM, Brent Royal-Gordon <brent@architechies.com <mailto:brent@architechies.com>> wrote:

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.

No.

Grrrr

Firstly, for those who cannot follow the list—and I can't say I blame them—the -announce list already allows them to ignore everything except the beginnings of reviews. Anyone who wants to (and who speaks English) can be notified of any significant proposed change to the language and can submit their comments for the core team's consideration. That is enough.

I think your perspective is flawed here. You are precisely one of the "top developers" I have been referring to. Am I surprised this is your opinion? Not one bit.

But if you followed the email trail you must have noticed that the final choice was not what brent supported. I would even say that it was not any of the solutions anyone proposed.. Proof that the process worked, the team made a change nobody anticipated, yet many people can (partially) identify with.

Mailing lists are a rather old thing...and I think many will find them daunting or maybe somewhat annoying with all of the announcements. How many people are subscribed to announce? It does not seem like many because well...we don't always get a lot of feedback. We get feedback from the same people over and over. How is this enough? How is this enough variety?

Just because "announce" is more palatable does not mean that it is being used in the way you are describing.

Maybe there is another problem then: people afraid to share their opinions publicly. I wonder why this would be.

The purpose of reviews is not to cast ballots for or against a feature. It is to submit arguments, for and against, for the core team to consider as they decide whether and how to address the problem the proposal's "Motivation" section describes. For that purpose, there is no need to collect hundreds or thousands of reviews, and if we did, the review manager would be swamped anyway. It is enough to get a reasonable variety of eyes, from a reasonable variety of perspectives, on the problem.

Why do people keep saying I am asking for: "hundreds or thousands" of reviews? I am just asking for something like 20 - 25 unique people's feedback. We are not getting that. We get the same people over and over...which makes the feedback seem screwed to this small group's philosophies.

Getting feedback from the same ~10 people is not a "reasonable variety of eyes" in my opinion. That is a very small sample. And that sample is usually those who are very technically skilled...who I would say do not always design the best interfaces.

I think that has happened here. We have not heard from every perspective, but we have heard from enough of them that adding more will not help all that much. Feedback always has diminishing returns: going from one person to two is far more valuable than going from fifty-one to fifty-two.

I think you will be very surprised come WWDC when people learn of this change.

How is there value when the same people keep justifying changes for the sake of consistency? Is this in the user's best interest? Or is this in the swift engineer's best interest?

This is precisely why I think more feedback is important. We need more than just the same people propping up proposals that gives an illusion that it is representative of everyone using swift.

The bar should be high for changing syntax, so I don't buy the argument that 25 people sharing their feedback is somehow less valuable than 10 people sharing.

And in particular, I *don't* think the beginner perspective is an especially worrisome one for this particular proposal.

I don't think this was though through thoroughly enough. It just happened too fast

Though some of the syntaxes we considered might have been confusing for beginners (*cough*semicolon*cough*), the one the core team settled in is actually one of the simplest, and certainly much simpler than the status quo. If anything, the people most disadvantaged by this solution are the power users who are used to the "multiple if-let" shorthand and will now have to add extra keywords to their code.

Maybe you are right. Maybe I am vastly wrong. But I guess this will be clearer come WWDC.

And I already know how the people complaining about this change will be silenced: it was done for the consistency of the language and the grammar.

How can us simpletons argue against that?

Also, I want to make clear that my concern is not just for this review but for future reviews also. How different could the language look with more varied feedback?

Again, I hope I am wrong =/
Brandon

--
Brent Royal-Gordon
Architechies

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[Roth_Michaels]

    When teaching Swift, I did discover that the requirement of 'where'
    in
    conditionals as expressed by this proposal was confusing and those I
    was
    teaching assumed they would use commas (or &&).
    
I completely understand this, but isn’t this because they just didn’t
know the syntax existed?

More or less; the particular developer I was thinking of did do a code
review of some of my code where he was exposed to `where` in a `switch
case` statement, but was anware of this construction in a `if|guard
let`.

After they learned about it, did they understand it?

Yes.

Did they like it? Hate it? That’s what I am very interested in hearing
about

First reaction was some sort of "hmm, that's weird, but okay"; after
pointing out the similar use with `switch` pattern matching and `case
let` bindings he saw the similarity. I think his overall opinion was
one of just accepting that is "the way it is" in Swift.

I'll try to point him to this thread to see if he has any opinions.

···

On Fri, Jun 10 2016 at 03:48:11 PM, Brandon Knope <bknope@me.com> wrote:

    On Jun 10, 2016, at 1:47 PM, Roth Michaels via swift-evolution > <swift-evolution@swift.org> wrote:

--
Roth