4 ms·

I'm still learning Swift (forever) and looking at the source code I wonder if Swift is getting too complicated to read now. I'm having a hard time reading simpl

by msie 4y ago

I'm still learning Swift (forever) and looking at the source code I wonder if Swift is getting too complicated to read now. I'm having a hard time reading simple snippets of Swift but the Lisa source code seems so comforting to read in comparison. Anyways, I'll soldier on.

JKCalhoun 4y ago
I know what you mean regarding Swift. In recent decades different languages have introduced interesting patterns, interesting notations. Swift seems to have adopted about all of them. I have been told by teammates that I don't write "Swifty" Swift code, instead writing something more like an "Objective-Swift" style. Oh, and they say that like it's a bad thing.
- kitsunesoba 4y ago
  > I have been told by teammates that I don't write "Swifty" Swift code, instead writing something more like an "Objective-Swift" style. Oh, and they say that like it's a bad thing Depending on what they mean by this, I agree that it can be a bad thing. Years ago, in the days when Swift was still pretty green (around 2.x or 3.x) I knew someone who liked to try to write "Objective-C in Swift" — that is, they'd try to ignore the type system and optionality entirely, with lots of forced casts, forced unwraps, shipping data around in [String:Any] dictionaries, etc… constant fighting with the compiler that made SourceKit very unhappy and crashy and the app we were working on more crash-prone than it would've been had it been written in Objective-C. On the other hand, if it's just a more verbose style that favors clarity and avoids e.g. unnamed closure arguments and breaks more out into well named variables and functions, I don't see anything wrong with that at all and in fact have been leaning further in that direction as time goes on.
  - JKCalhoun 4y ago
    Ha ha, yeah no I would never force a cast, I always unwrap optionals... As an example, I was slow to adopt guard statements generally, preferring to strictly use them only for parameter checking (thus only at the top of functions). Then there are crazy ways that case statements can be used in a switch that I still don't understand.
deleted 4y ago
[deleted]

by msie 4y ago

JKCalhoun 4y ago

I know what you mean regarding Swift. In recent decades different languages have introduced interesting patterns, interesting notations. Swift seems to have adopted about all of them. I have been told by teammates that I don't write "Swifty" Swift code, instead writing something more like an "Objective-Swift" style. Oh, and they say that like it's a bad thing.

kitsunesoba 4y ago
> I have been told by teammates that I don't write "Swifty" Swift code, instead writing something more like an "Objective-Swift" style. Oh, and they say that like it's a bad thing Depending on what they mean by this, I agree that it can be a bad thing. Years ago, in the days when Swift was still pretty green (around 2.x or 3.x) I knew someone who liked to try to write "Objective-C in Swift" — that is, they'd try to ignore the type system and optionality entirely, with lots of forced casts, forced unwraps, shipping data around in [String:Any] dictionaries, etc… constant fighting with the compiler that made SourceKit very unhappy and crashy and the app we were working on more crash-prone than it would've been had it been written in Objective-C. On the other hand, if it's just a more verbose style that favors clarity and avoids e.g. unnamed closure arguments and breaks more out into well named variables and functions, I don't see anything wrong with that at all and in fact have been leaning further in that direction as time goes on.
- JKCalhoun 4y ago
  Ha ha, yeah no I would never force a cast, I always unwrap optionals... As an example, I was slow to adopt guard statements generally, preferring to strictly use them only for parameter checking (thus only at the top of functions). Then there are crazy ways that case statements can be used in a switch that I still don't understand.

deleted 4y ago

[deleted]