WWDC

[B01L]

My guess: the “partially in-person” thing is so some people can try on their AR goggles.

"Though the event will be digital, Apple also plans to host a special day for developers and students at Apple Park on June 6 to watch the keynote and State of the Union videos together. Space will be limited, and Apple will take applications."

Nah, if they were gonna show off their AR/VR headset the in-person attendees would be tech press folk...?

What if they are just hosting some live bodies so they can mix their reaction audio into the event stream...?

 

[Cmaier]

"Though the event will be digital, Apple also plans to host a special day for developers and students at Apple Park on June 6 to watch the keynote and State of the Union videos together. Space will be limited, and Apple will take applications."

Nah, if they were gonna show off their AR/VR headset the in-person attendees would be tech press folk...?

What if they are just hosting some live bodies so they can mix their reaction audio into the event stream...?

Guess we’ll see. (I think press will be there in any case)

 

[B01L]

Guess we’ll see. (I think press will be there in any case)

NO...!

The Internet DEMANDS we start a pointless two week argument over this...!

;^p

 

[Yoused]

The Internet DEMANDS we start a pointless two week argument over this...!

dataflow quotas must be maintained

 

[Nycturne]

I think most people do if let foo = foo { ... } now. I haven't seen any codebase where unwrapping optionals doesn't use variable shadowing by default. You get used to it, and it becomes perfectly natural... but it's still a terrible choice of syntax for any newcomer IMHO. Zero readability. I used to hate it.

Speaking of this, it looks like soon “if let foo {}” as shorthand for the shadowing unwrap will be part of the language:

swift-evolution/proposals/0345-if-let-shorthand.md at main · apple/swift-evolution

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. - apple/swift-evolution

github.com

 

[Cmaier]

Speaking of this, it looks like soon “if let foo {}” as shorthand for the shadowing unwrap will be part of the language:

swift-evolution/proposals/0345-if-let-shorthand.md at main · apple/swift-evolution

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. - apple/swift-evolution

github.com

Yep. Better syntactically, but you still are creating a shadow variable, and what the hell is “if let foo”? - if you don’t already know swift, it’s pretty illegible. I don’t mind typing code, so long as it’s readable. But Swift goes the other way.

 

[Nycturne]

Yep. Better syntactically, but you still are creating a shadow variable, and what the hell is “if let foo”? - if you don’t already know swift, it’s pretty illegible. I don’t mind typing code, so long as it’s readable. But Swift goes the other way.

You aren’t the only one. In the review thread, this exact argument is brought up and I don’t disagree. I more thought this was interesting that the community does seemingly do this often enough that syntactic sugar was added for it…

 

[MEJHarrison]

Yep. Better syntactically, but you still are creating a shadow variable, and what the hell is “if let foo”? - if you don’t already know swift, it’s pretty illegible. I don’t mind typing code, so long as it’s readable. But Swift goes the other way.

I'm not too bothered. I do know Swift, and I find it considerably easier to read. I like it. And it looks like it's been implemented in 5.7.

 

[Andropov]

Speaking of this, it looks like soon “if let foo {}” as shorthand for the shadowing unwrap will be part of the language:

swift-evolution/proposals/0345-if-let-shorthand.md at main · apple/swift-evolution

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. - apple/swift-evolution

github.com

Hehe, I saw that last week too. It's somewhat better than if let foo = foo { ... } but not by a huge margin. I don't love it, but I have no idea of what a succinct syntax for what the unwrapping via shadow variable creation would be. I can't think of anything better myself.

It is shorter to write, and I sincerely hope that hasn't played a role in approving that evolution proposal. Nothing I would hate more than seeing the language pivot towards being optimized to having to write less characters of code at the cost of readability.

 

[Cmaier]

Hehe, I saw that last week too. It's somewhat better than if let foo = foo { ... } but not by a huge margin. I don't love it, but I have no idea of what a succinct syntax for what the unwrapping via shadow variable creation would be. I can't think of anything better myself.

It is shorter to write, and I sincerely hope that hasn't played a role in approving that evolution proposal. Nothing I would hate more than seeing the language pivot towards being optimized to having to write less characters of code at the cost of readability.

But it seems they do that at every turn. Swift is heavily biased toward succinctness at the expense of clarity.

 

[Nycturne]

Hehe, I saw that last week too. It's somewhat better than if let foo = foo { ... } but not by a huge margin. I don't love it, but I have no idea of what a succinct syntax for what the unwrapping via shadow variable creation would be. I can't think of anything better myself.

It is shorter to write, and I sincerely hope that hasn't played a role in approving that evolution proposal. Nothing I would hate more than seeing the language pivot towards being optimized to having to write less characters of code at the cost of readability.

I think it’s more that this sort of proposal kept coming up, despite it being on the “frequently rejected list”. i.e. the community kept demanding something for this one, despite the controversial nature. There seems to be a lot of passionate folks on both sides of this particular argument.

But it seems they do that at every turn. Swift is heavily biased toward succinctness at the expense of clarity.

I’m curious of some examples. My most common typo is the kind where “the compiler can absolutely infer X should be here, but we’re going to make you be explicit.” Especially around the use of try and await. So I might be missing something.

 

[Cmaier]

I think it’s more that this sort of proposal kept coming up, despite it being on the “frequently rejected list”. i.e. the community kept demanding something for this one, despite the controversial nature. There seems to be a lot of passionate folks on both sides of this particular argument.



I’m curious of some examples. My most common typo is the kind where “the compiler can absolutely infer X should be here, but we’re going to make you be explicit.” Especially around the use of try and await. So I might be missing something.

Things like implicit returns come to mind.

 

[Yoused]

Things like implicit returns come to mind.

My quirk arises from learning on HP2000 BASIC, which was very strict. Every line had to be numbered, and you had to use those numbers for branching. I mean, AL/ML can be entertaining/rewarding for a while, but when you get to a high-level language, flow control should be as abstracted as possible, IMO. I have a deep and abiding distaste for goto, break, continue and my subroutines/methods have no more than one return. If I cannot manage flow control with { … { { … } … } } I feel like I must be doing it wrong.

 

[Nycturne]

Things like implicit returns come to mind.

I guess that one doesn’t bother me as much, because I use it. Partly because most of the ugly cases are blocked by the compiler. I also only use it for one-liner computed properties and ViewBuilders where the intent is clearer.

 

[Cmaier]

I guess that one doesn’t bother me as much, because I use it. Partly because most of the ugly cases are blocked by the compiler. I also only use it for one-liner computed properties and ViewBuilders where the intent is clearer.

I guess im picky. I don’t even like leaving off class names when accessing static properties (e.g. UIColor.blue)

 

[Andropov]

But it seems they do that at every turn. Swift is heavily biased toward succinctness at the expense of clarity.

Hmm. Could be. But it's still a very readable language for the most part, or at least the part of it that is used regularly in iOS/iPadOS/macOS development. And some features, like the async stuff, have improved clarity by orders of magnitude, while also being shorter to write.

I know there's more to the language, and that you can absolutely write undecipherable code using some of the most abstract Swift features, but I've found that it's rarely done in practice.

Things like implicit returns come to mind.

I hate that. It's in my top 3 of most hated Swift features, along with ternary operators and closures with $0. All three features seem nice on small examples and used with caution. They never are.

(I know ternary operators are a weird hill to die on )

 

[Citysnaps]

Yep. Better syntactically, but you still are creating a shadow variable, and what the hell is “if let foo”? - if you don’t already know swift, it’s pretty illegible. I don’t mind typing code, so long as it’s readable. But Swift goes the other way.

Not as bad (or as good) as APL.

 

[Cmaier]

Not as bad (or as good) as APL.

Back when I took my doctoral qualifier exam, I opted for the written computer science portion. For that, they ask you, among other things, to write code (on paper) in a randomly-selected language. They picked APL. Bastards.

 

[Citysnaps]

Back when I took my doctoral qualifier exam, I opted for the written computer science portion. For that, they ask you, among other things, to write code (on paper) in a randomly-selected language. They picked APL. Bastards.

Back in the day I worked in a lab that focused on developing signal processing hardware systems for defense applications. One engineer was a whiz and did his algorithm development in APL for proof of concept purposes, while others used more conventional languages or Matlab. One time, as part of larger task, and to prove it could be done, he came up with an FFT algorithm coded in one line of APL. Apparently it worked, but nobody else could make sense of it.

 

[Roller]

Back in the day I worked in a lab that focused on developing signal processing hardware systems for defense applications. One engineer was a whiz and did his algorithm development in APL for proof of concept purposes, while others used more conventional languages or Matlab. One time, as part of larger task, and to prove it could be done, he came up with an FFT algorithm coded in one line of APL. Apparently it worked, but nobody else could make sense of it.

Ha! I was going to say something about APL. I took a class in it in the early 70s, and I remember it was a badge of honor to reduce an algorithm to as little code as possible. I did that a few times to the point where even I couldn't decipher what I'd done after some time had passed. That was true to some extent with assembly language too, but mostly because of the somewhat arcane steps needed to move bits and bytes around.

Back when I did most of my programming in FORTRAN, I learned to comment my programs heavily, such that I had almost as many comment lines as code. But it sure paid off when debugging or adding features. I have some printouts of programs that I wrote almost 40 years ago that I can still follow.

I never learned C, C++, or any other follow-ons, though I've been tempted to try Swift. But I'm a bit apprehensive about finding that I won't be able to get anywhere with it...