WWDC

B01L

SlackMaster
Posts
161
Reaction score
117
Location
Diagonally parked in a parallel universe...
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

Site Master
Staff Member
Site Donor
Posts
5,216
Reaction score
8,264
"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)
 

Nycturne

Elite Member
Posts
1,111
Reaction score
1,426
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:

 

Cmaier

Site Master
Staff Member
Site Donor
Posts
5,216
Reaction score
8,264
Speaking of this, it looks like soon “if let foo {}” as shorthand for the shadowing unwrap will be part of the language:


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

Elite Member
Posts
1,111
Reaction score
1,426
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

Site Champ
Posts
873
Reaction score
1,710
Location
Beaverton, OR
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

Site Champ
Posts
605
Reaction score
756
Location
Spain
Speaking of this, it looks like soon “if let foo {}” as shorthand for the shadowing unwrap will be part of the language:

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

Site Master
Staff Member
Site Donor
Posts
5,216
Reaction score
8,264
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

Elite Member
Posts
1,111
Reaction score
1,426
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

Site Master
Staff Member
Site Donor
Posts
5,216
Reaction score
8,264
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

up
Posts
5,512
Reaction score
8,687
Location
knee deep in the road apples of the 4 horsemen
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

Elite Member
Posts
1,111
Reaction score
1,426
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

Site Master
Staff Member
Site Donor
Posts
5,216
Reaction score
8,264
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

Site Champ
Posts
605
Reaction score
756
Location
Spain
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 :p)
 

Citysnaps

Elite Member
Staff Member
Site Donor
Posts
3,603
Reaction score
8,826
Main Camera
iPhone
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. :)
 

Citysnaps

Elite Member
Staff Member
Site Donor
Posts
3,603
Reaction score
8,826
Main Camera
iPhone
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

Elite Member
Posts
1,392
Reaction score
2,698
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...
 
Top Bottom
1 2