> 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 !.

Good point. Fortunately this fixit was improved over the summer: https://forums.swift.org/t/resolved-insert-is-a-bad-fixit/10... I believe it made its way into Swift 4.2/Xcode 10.

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 ?

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.

If Apple's own developers are just slapping '!'s on optionals to make errors go away, I would be seriously concerned.

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.

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?

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.

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.

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.

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.

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.

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.

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?

My point isn’t to say Swift is bad. I personally don’t like it, but that isn’t the point. In my original comment, I wanted to say that rewriting software just because of a new language is probably a bad idea.

Apple could have continued using the existing software, rather than just throw away stable code for the sake of new devs to use a new language.

Agree completely - I'm not convinced that Swift is so much better than Objective-C that it makes sense to throw out mature production code.

Mandatory link to Spolsky's blog post on exactly this:

https://www.joelonsoftware.com/2000/04/06/things-you-should-...