19 ms·

If anything, since a lot of stuff is being rewritten from scratch, a lot of new bugs appear that were not there. At least that's my experience on the Mac with s

If anything, since a lot of stuff is being rewritten from scratch, a lot of new bugs appear that were not there. At least that's my experience on the Mac with software that has been rewritten in Swift. Obviously, it's not Swift's fault for that, but even if people at Apple make rookie mistakes such as using force unwrap operator, it tells something about the language.

the_clarence 8y ago
Can you explain force unwrap? Actually I was wondering with Swift had a lot of these things I don't see much in other languages. Optionals for example. Is it because it us focused on coding highly responsive UIs where different states might not yet be available?
- saagarjha 8y ago
  Force unwrapping is what it sounds like: you take an optional, and forcefully convert it to a nonoptional. Obviously there must be a valid value at this point in the program, or it will crash. Optionals are useful not only for UIs, but for handling any sort of state where it's possible for something to not have a valid value at any point in time. It just hoists such a state into the type system rather than checking this at runtime.
- jernfrost 8y ago
  It is not much in other languages because those languages are old. A lot of the Swift features have been in more academic functional languages for a long time. However it has taken time for the mainstream languages to adopt these ideas. The industry moves much slower than academic niche languages. But most new languages has some variant of this stuff: kotlin, scala, rust. I program a lot in Julia which is a script language and it does not have allow you to use null freely either. May seem odd for a language that does not type check at compile time. But it actually makes sense.
dep_b 8y ago
> Obviously, it's not Swift's fault for that, but even if people at Apple make rookie mistakes such as using force unwrap operator, it tells something about the language. It's still often suggested by Xcode if you use an optional which has not been unwrapped in any way. "Click here to make error go away" adds an !.
- wool_gather 8y ago
  Good point. Fortunately this fixit was improved over the summer: https://forums.swift.org/t/resolved-insert-is-a-bad-fixit/10764/102 https://forums.swift.org/t/resolved-insert-is-a-bad-fixit/10... I believe it made its way into Swift 4.2/Xcode 10.
  - dep_b 8y ago
    Good stuff. Now to fix my only other pet peeve which is declaring IBOutlets with a ! by default. In the ideal world IBOutlets would be checked compile time unless they're declared with a ?
    - wool_gather 8y ago
      Well, they have to be Optionals one way or another, because they can't get hooked up until after init[0], and Swift won't allow that. But yeah, I imagine this is on someone's todo list somewhere. IB already knows whether things are connected properly, and actually so does the source editor, since it shows the little circles in the gutter. -- [0] Unless you could invert the order of the unarchiving...not sure what difficulties that would cause.
- sgt 8y ago
  If Apple's own developers are just slapping '!'s on optionals to make errors go away, I would be seriously concerned.
  - dep_b 8y ago
    Well hiring practices in the US tend to be skewed toward people knowing a ton about data structures and algorithms versus people having years and years of practical knowledge programming things. I wouldn't be surprised. I've seen Swift code built by pretty smart people that was one big exclamationfest.
MaxBarraclough 8y ago
These bugs are likely to be of a lower average severity though, no? C-family languages let you take off your whole leg with the slightest mistake.
- LeoNatan25 8y ago
  No, clearly not. Take a look major components rewritten in recent years, such as Xcode code editor, new build system, Dock, those are crashing way more than their ObjC/C counterparts for whatever reason. A crash is a crash. You may claim that errors here are “less fundamental”, but the fact remains that the new software crashes more than the old.
  - wool_gather 8y ago
    Right. Users don't give a hoot what language the software is written in, what design patterns you're using, if you're functionally immutable. The code is there to serve a purpose. If it crashes, it fails; the root cause doesn't really matter to the user.
  - elcritch 8y ago
    This feeling that “man dock.app is crashing more” followed by a few otool queries showing more Swift libraries gives me a vague suspicion that Swift rewrites have been leading to more end user noticeable crashes. I’d find it interesting to see some actual statistics on it in the form of “x crashes per 1 hour of program usage”. Perhaps it’d actually be lower than Obj-C but it doesn’t feel that way. Is it due to Swift error handling or just to rewrites? This would be an ideal time to get such statistics ! As it’s not often a giant platform starts switching to a new language and offer the chance to gather real stats rather than bikesheading or doing undergrad cohort experiments would be very interesting.
  - MaxBarraclough 8y ago
    Sure, if it's a good old whole-program-crash either way, that means they're equivalent severity. It's not my intention to softball Swift with some nebulous idea of what counts as a proper 'fundamental' bug. In defence of Swift, it could still be that they spent less time bug-hunting than when they were developing in Objective-C, to reach the same, or inferior, level of program correctness. Also, we're comparing a new product to a mature one. Were the original Objective-C programs stable in their first release?

the_clarence 8y ago

Can you explain force unwrap? Actually I was wondering with Swift had a lot of these things I don't see much in other languages. Optionals for example. Is it because it us focused on coding highly responsive UIs where different states might not yet be available?

saagarjha 8y ago
Force unwrapping is what it sounds like: you take an optional, and forcefully convert it to a nonoptional. Obviously there must be a valid value at this point in the program, or it will crash. Optionals are useful not only for UIs, but for handling any sort of state where it's possible for something to not have a valid value at any point in time. It just hoists such a state into the type system rather than checking this at runtime.
jernfrost 8y ago
It is not much in other languages because those languages are old. A lot of the Swift features have been in more academic functional languages for a long time. However it has taken time for the mainstream languages to adopt these ideas. The industry moves much slower than academic niche languages. But most new languages has some variant of this stuff: kotlin, scala, rust. I program a lot in Julia which is a script language and it does not have allow you to use null freely either. May seem odd for a language that does not type check at compile time. But it actually makes sense.

dep_b 8y ago

> Obviously, it's not Swift's fault for that, but even if people at Apple make rookie mistakes such as using force unwrap operator, it tells something about the language. It's still often suggested by Xcode if you use an optional which has not been unwrapped in any way. "Click here to make error go away" adds an !.

wool_gather 8y ago
Good point. Fortunately this fixit was improved over the summer: https://forums.swift.org/t/resolved-insert-is-a-bad-fixit/10764/102 https://forums.swift.org/t/resolved-insert-is-a-bad-fixit/10... I believe it made its way into Swift 4.2/Xcode 10.
- dep_b 8y ago
  Good stuff. Now to fix my only other pet peeve which is declaring IBOutlets with a ! by default. In the ideal world IBOutlets would be checked compile time unless they're declared with a ?
  - wool_gather 8y ago
    Well, they have to be Optionals one way or another, because they can't get hooked up until after init[0], and Swift won't allow that. But yeah, I imagine this is on someone's todo list somewhere. IB already knows whether things are connected properly, and actually so does the source editor, since it shows the little circles in the gutter. -- [0] Unless you could invert the order of the unarchiving...not sure what difficulties that would cause.
sgt 8y ago
If Apple's own developers are just slapping '!'s on optionals to make errors go away, I would be seriously concerned.
- dep_b 8y ago
  Well hiring practices in the US tend to be skewed toward people knowing a ton about data structures and algorithms versus people having years and years of practical knowledge programming things. I wouldn't be surprised. I've seen Swift code built by pretty smart people that was one big exclamationfest.

MaxBarraclough 8y ago

These bugs are likely to be of a lower average severity though, no? C-family languages let you take off your whole leg with the slightest mistake.

LeoNatan25 8y ago
No, clearly not. Take a look major components rewritten in recent years, such as Xcode code editor, new build system, Dock, those are crashing way more than their ObjC/C counterparts for whatever reason. A crash is a crash. You may claim that errors here are “less fundamental”, but the fact remains that the new software crashes more than the old.
- wool_gather 8y ago
  Right. Users don't give a hoot what language the software is written in, what design patterns you're using, if you're functionally immutable. The code is there to serve a purpose. If it crashes, it fails; the root cause doesn't really matter to the user.
- elcritch 8y ago
  This feeling that “man dock.app is crashing more” followed by a few otool queries showing more Swift libraries gives me a vague suspicion that Swift rewrites have been leading to more end user noticeable crashes. I’d find it interesting to see some actual statistics on it in the form of “x crashes per 1 hour of program usage”. Perhaps it’d actually be lower than Obj-C but it doesn’t feel that way. Is it due to Swift error handling or just to rewrites? This would be an ideal time to get such statistics ! As it’s not often a giant platform starts switching to a new language and offer the chance to gather real stats rather than bikesheading or doing undergrad cohort experiments would be very interesting.
- MaxBarraclough 8y ago
  Sure, if it's a good old whole-program-crash either way, that means they're equivalent severity. It's not my intention to softball Swift with some nebulous idea of what counts as a proper 'fundamental' bug. In defence of Swift, it could still be that they spent less time bug-hunting than when they were developing in Objective-C, to reach the same, or inferior, level of program correctness. Also, we're comparing a new product to a mature one. Were the original Objective-C programs stable in their first release?