7 ms·

I have wasted many, many hours tracking down reference cycles, so in some sense, I welcome this change. However, the scope creep of Swift is becoming nightmari

I have wasted many, many hours tracking down reference cycles, so in some sense, I welcome this change. However, the scope creep of Swift is becoming nightmarish - nothing just makes sense anymore. My hopes for Swift are that it teaches a whole generation how to program really compelling applications, full stack, in a profitable ecosystem (though open source, Swift is a 'gateway drug' to get people into the ecosystem). We will see if these decisions advance or detract from that.

deleted 4y ago
[deleted]
pixelrevision 4y ago
I had been feeling that way until I worked on a project that uses modern React and realized that a lot of other stuff is becoming this way. At least with Swift the compiler helps you along a lot and you can lookup most language concepts easily without them being so out of date. That said I really wish the tooling would keep up. Debugging stuff like SwiftUI and async/await code is really painful right now. It feels like they keep adding this stuff without updating the tools we need to have available to really support it. This is in stark contrast to what was/is available for Objective-C and UIKit with the debugger and instruments. I'm not sure it's a good tradeoff... The high level code becomes a lot easier to read and write but keeping a mental model of what's happening is a lot harder and it becomes very thorny when things go sideways.
- marcellus23 4y ago
  This is my biggest problem with the state of Apple's developer ecosystem right now. The tooling is just pathetic — I love writing in Swift, UIKit, AppKit and SwiftUI, but it can really feel like the tools are fighting you. They're just not dumping nearly enough effort into making their tooling top-notch. There's an extremely stark contrast between Xcode and Android Studio any time you need to do refactoring, for example. Xcode's refactoring tools are both limited and very very finnicky (to the point of being basically useless).
  - ChrisMarshallNY 4y ago
    Xcode is a bug farm. A HUGE bug farm. Whenever it gets an update, I might as well just go out and catch a show. When I switched to an M1-based computer, the debugging became much finickier. I suspect that this is an OS problem, as opposed to an Xcode problem (because it happens with other System-calling apps), but sometimes, spun processes seem to hang, and I can bang away on "Force Quit," until I'm blue in the face. Nothing but a hardware restart (I can't do a soft one) fixes it. But Xcode brings the beast out on that one. It hangs and stutters quite frequently.
scarface_74 4y ago
I live in the Apple ecosystem as a user. But as a developer, I could not imagine tying myself to it. It would put my career too much at the whims of Apple.
- ChrisMarshallNY 4y ago
  Well, I have had my career pinned to it since 1986. It has not always been fun. Lots of atomic wedgies, in the recess yard, but things have worked out OK, in the long run.
ChrisMarshallNY 4y ago
I have encountered very few of these, with Swift. The reference counter seems good. I tend to declare many of my object references as weak, anyway; even if not necessary. Of course, I'm old-fashioned (and I primarily work with UIKit), so I use classes a lot. If I am doing it the "current" way, most of the program uses value semantics, so it should not be an issue (in theory, anyway).
- anonymouse008 4y ago
  Aye - same here. Was once just a novice who had no idea how an application could hog up 62Gb of ram - and have weird changes to objects that shouldn't. Then I learned about references, and what a biological messaging system really means (thanks, Alan and NotificationCenter!).
- saagarjha 4y ago
  > I tend to declare many of my object references as weak, anyway; even if not necessary. Why?
  - ChrisMarshallNY 4y ago
    Because they don't need to be strong. I like to establish basic Quality habits. This is one. I declare object references as weak (or, sometimes -quite rarely, unowned) by default. If they need to be strong, either the compiler will let me know, when I try assigning to it, or the runtime will let me know with a bad access crash. Much quicker debugging than chasing reference loops. Crashes are actually good. I find the cause fairly quickly. I usually don't declare local scope variables weak; only ones that escape the scope. I have found that I seldom need to switch to strong. I also do other "useless" things, like setting the constant before the variable, in comparisons: "Good Grief" == whatCharlieSays I also tend to "in-name" incoming arguments, like so: func compare(thisValue inThisValue: Int, toThisValue inThatValue: Int) -> Int I also write @IBOutlets as explicit optionals, like so: @IBOutlet weak var someLabel: UILabel? as opposed to the default: @IBOutlet weak var someLabel: UILabel! This forces me to unwrap everywhere. I avoid implicit optionals like the plague. I use a lot of guards. I will unwrap implicit optionals in system-provided resources, even though it isn't necessary. I don't really care whether or not they are "necessary," or what others think of me. Every little bit helps. I'm very conscientious about the code I write. I write it very quickly, too. Once something becomes habit, it moves rapidly. "We are what we repeatedly do. Excellence then, is not an act, but a habit" - Incorrectly attributed to Aristotle
hota_mazi 4y ago
Rust and Kotlin are much more advanced than Swift when it comes to writing full stack, deployable, multi platform, and performant applications...

deleted 4y ago

[deleted]

pixelrevision 4y ago

I had been feeling that way until I worked on a project that uses modern React and realized that a lot of other stuff is becoming this way. At least with Swift the compiler helps you along a lot and you can lookup most language concepts easily without them being so out of date. That said I really wish the tooling would keep up. Debugging stuff like SwiftUI and async/await code is really painful right now. It feels like they keep adding this stuff without updating the tools we need to have available to really support it. This is in stark contrast to what was/is available for Objective-C and UIKit with the debugger and instruments. I'm not sure it's a good tradeoff... The high level code becomes a lot easier to read and write but keeping a mental model of what's happening is a lot harder and it becomes very thorny when things go sideways.

marcellus23 4y ago
This is my biggest problem with the state of Apple's developer ecosystem right now. The tooling is just pathetic — I love writing in Swift, UIKit, AppKit and SwiftUI, but it can really feel like the tools are fighting you. They're just not dumping nearly enough effort into making their tooling top-notch. There's an extremely stark contrast between Xcode and Android Studio any time you need to do refactoring, for example. Xcode's refactoring tools are both limited and very very finnicky (to the point of being basically useless).
- ChrisMarshallNY 4y ago
  Xcode is a bug farm. A HUGE bug farm. Whenever it gets an update, I might as well just go out and catch a show. When I switched to an M1-based computer, the debugging became much finickier. I suspect that this is an OS problem, as opposed to an Xcode problem (because it happens with other System-calling apps), but sometimes, spun processes seem to hang, and I can bang away on "Force Quit," until I'm blue in the face. Nothing but a hardware restart (I can't do a soft one) fixes it. But Xcode brings the beast out on that one. It hangs and stutters quite frequently.

scarface_74 4y ago

I live in the Apple ecosystem as a user. But as a developer, I could not imagine tying myself to it. It would put my career too much at the whims of Apple.

ChrisMarshallNY 4y ago
Well, I have had my career pinned to it since 1986. It has not always been fun. Lots of atomic wedgies, in the recess yard, but things have worked out OK, in the long run.

ChrisMarshallNY 4y ago

I have encountered very few of these, with Swift. The reference counter seems good. I tend to declare many of my object references as weak, anyway; even if not necessary. Of course, I'm old-fashioned (and I primarily work with UIKit), so I use classes a lot. If I am doing it the "current" way, most of the program uses value semantics, so it should not be an issue (in theory, anyway).

anonymouse008 4y ago
Aye - same here. Was once just a novice who had no idea how an application could hog up 62Gb of ram - and have weird changes to objects that shouldn't. Then I learned about references, and what a biological messaging system really means (thanks, Alan and NotificationCenter!).
saagarjha 4y ago
> I tend to declare many of my object references as weak, anyway; even if not necessary. Why?
- ChrisMarshallNY 4y ago
  Because they don't need to be strong. I like to establish basic Quality habits. This is one. I declare object references as weak (or, sometimes -quite rarely, unowned) by default. If they need to be strong, either the compiler will let me know, when I try assigning to it, or the runtime will let me know with a bad access crash. Much quicker debugging than chasing reference loops. Crashes are actually good. I find the cause fairly quickly. I usually don't declare local scope variables weak; only ones that escape the scope. I have found that I seldom need to switch to strong. I also do other "useless" things, like setting the constant before the variable, in comparisons: "Good Grief" == whatCharlieSays I also tend to "in-name" incoming arguments, like so: func compare(thisValue inThisValue: Int, toThisValue inThatValue: Int) -> Int I also write @IBOutlets as explicit optionals, like so: @IBOutlet weak var someLabel: UILabel? as opposed to the default: @IBOutlet weak var someLabel: UILabel! This forces me to unwrap everywhere. I avoid implicit optionals like the plague. I use a lot of guards. I will unwrap implicit optionals in system-provided resources, even though it isn't necessary. I don't really care whether or not they are "necessary," or what others think of me. Every little bit helps. I'm very conscientious about the code I write. I write it very quickly, too. Once something becomes habit, it moves rapidly. "We are what we repeatedly do. Excellence then, is not an act, but a habit" - Incorrectly attributed to Aristotle

hota_mazi 4y ago

Rust and Kotlin are much more advanced than Swift when it comes to writing full stack, deployable, multi platform, and performant applications...