[ardit33]

I hate how pendantic and useless some of the features of swift being pushed down by academics that don't write apps or services themselves.

Simple example:

Objective-C

if myObject {

}

in swift if myObject != nil {

}

Also opitionals in swift could have totally be avoided if they adopted a prototype based langue (basically object are never nil). Lua did this, and it is very elegant

But meanwhile, we got a half backed optional system, which is backwards (similiar to Java), and didn't help with the practicality of the language at all, and meanwhile you still can crash an app doing myArray[1]

[nielsbot]

I love Obj-C, but the Swift version isn't as bad as you say:

    if let myObject {
        // myObject is non-nil in here
    }

The Swift version is also usingfirst-class optionals. In Obj-C there is very small chance you'll confuse `NULL` with `nil` or `0`. Or that you'll message `nil` resulting in `nil`.. and in well-built software you have to guard against that.

Aside: Obj-C is narrowly focused on adding objects (in the Smalltalk sense) to C whereas Swift is trying to deliver a compiler and language with memory safety _guarantees_... Turns out that means you need a lot more language. Not to mention the `async` syntax/feature explosion.

Obj-C is "hippie" and Swift is "corporate suit" + "we're doing serious work here!"

Finally I want to say: I believe Obj-C was a huge competitive advantage and secret weapon that let Apple deliver an OS with so much more built-in functionality than any competitor for years and years. (Obj-C is great for system APIs) That's under-appreciated.

[andrekandre]

  > you still can crash an app doing myArray[1]

the first thing i do when starting a new project:

  extension Array {
      subscript(safe: Int) -> Element? { ... }
  }

there was talk in the swift forms about adding that as standard that but it seems to have died off...

[0] https://forums.swift.org/t/draft-adding-safe-indexing-to-arr...

[umpalumpaaa]

Even with that there is nothing from you accidentally using [i]. Also there are just a ton of Swift APIS and bridge API that take an index and then crash… for full coverage you would need hundreds of safe wrappers… (doing what you propose though at least gives you. Some peace of mind..

Also Swift has a lot of other areas where it just lacks any safeguards… Memory issues are still a thing. It’s using ARC under the hood after all.

Infinite recursion is still a thing (not sure if this would even detectable - probably not).

Misuse of APIs.

And it introduces new issues: which methods are being called depends on your imports.

In my experience Swift lulls you into a false sense of safety while adding more potential safety issues and “only” solving some of the less important ones. objc has null ability as well. Which can warn u if used appropriately. objc also has lightweight generics. In practice this is all you need.

[andrekandre]

  > And it introduces new issues: which methods are being called depends on your imports.

also depending on how you casted it, it will call the method of the cast, not the actual one in the instance (which completely caught be off-guard when i started swift)

  > objc also has lightweight generics. In practice this is all you need.

i feel this too sometimes; sometimes simple really is best... tho i think some of these decisions around complexity is to allow for more optimization so c++ can be chucked away at some point...