T O P

Why did Apple "create" Swift and did not simply integrate the updates into Objective-C?

Why did Apple "create" Swift and did not simply integrate the updates into Objective-C?

Nerdlinger

> I still cannot understand what is fundamentally different between Swift and Objective-C You mean besides the strict, static type system with type inference, the functional programming capabilities, the generics, and the (comparative) memory safety?


chriswaco

ObjC could never be a safe language while maintaining backward compatibility with existing code, especially C code. Its syntax is a bit weird to some - lots of nested brackets. There are times I miss features of ObjC, but syntax-wise Swift is much cleaner.


tied_laces

“Obj-C, make me a sandwich” Obj-c : “ you’re a sandwich…maybe”


ReallyFastTyper

I laughed unreasonably hard at this.


tied_laces

Only old iOS devs know...


Darmok-Jilad-Ocean

Can you explain?


tied_laces

Many of us joined iOS and went of the pain of writing code in Obj-C not realizing we were setting off ticking time bombs in the type flexibility. You could force a type on an object but that object could be null and connected in a reference cycle ...this is a called more commonly a **zombie**. It was empty but taking up resources and it wouldn't die. And if you didn't know better, you would use the same pattern...many times. Over time all the poor code smells in obj-c can make the app unusable but you couldn't put your finger on it because it wouldn't always crash. **Swift will never let you do that**. The worst you can do is make a force unwrap (!) and for me and my teams, we had a script to filter code using that out...unless you know the object exists. But using optionals aids in the better code design and preparing error corner cases...its a more professional method of coding Maybe someone with more skill can explain further


Darmok-Jilad-Ocean

Thanks for the detail. Do you understand the sandwich reference?


tied_laces

Yes…I made the joke.


maxxfrazer

there would be compromises that Apple would rather not take by doing this, creating a new language that somewhat plays nicely with objective c was the better choice


thecocoexe

Try write some application in Swift then write the same application in Objective-C. If you don’t feel difference between Objective-C and Swift so you’re not familiar with Swift.


bersmu

Strict null safety, immediately and enums with associated values make a huge difference for me. It's all possible in obj c. Annotations are part of the language but it's not strict. And remodel like libraries https://github.com/facebook/remodel can cover immutabilty and enums but it's so much boilerplate. It seems the effort to modernize objc c more than to start a new language and deal with compatibility.


icjeremy

it's “Objective-C without the C”


kawag

Also with fewer “objects” and more “values”


Catfish_Man

Swift is mostly unlike ObjC under the hood. The compatibility with ObjC code is the result of huge amounts of bridging code in the compiler, runtime, and standard library, not any significant underlying similarity. Even something as seemingly similar as String and NSString are radically different (character encoding, memory layout, developer-facing behavior, method dispatch, all different), and Swift’s String is >50,000 lines of unrelated-to-ObjC code.


dawmster

New kids, I guess. New syntax was an improvement, yes very nice. But they should go with Objective-C runtime and call it a day. We would have runtime coding years ago (what Swift/SwiftUI promised but it never worked). Swift kids at Apple went C++ way and had to rewrite everything to have it all "their way". Open sourcing did nothing to Apple and Swift role in iOS. In Swift-era everybody beats syntax/patterns/type safety/type inference like a dead horse instead of real problem and real solutions. Plus Swift-first API are the worst - Drag&Drop, window api on iOS, configurations in TableViewCells. Counter-productive. Strict types in application/UI-language ? Useless. Counterproductive. There are some scenarios that additional speed is necessary - so Apple should mark those files as Swift-Strict and let clang compile it with loops/memory structures/etc like a C++ does it - almost no one will use it either way. Generics ? Like Swift invented it, bah. ObjC has them. Memory safety - this is just fricking ridiculous, ARC was true revolution, ObjC did this better seamlessly without type-masturbation. Optionals should be optional and moved to Code Editor/Compiler checks. Either way you can mark nullable/nonnull in ObjC. But syntax is better - true dat.


SparklingOctopus3754

> Generics ? Like Swift invented it, bah. ObjC has them. “How dare Apple include an industry-standard language feature in their new programming language?” > Optionals should be optional and moved to Code Editor/Compiler checks. You understand that the point of Swift optionals is to make nullability a compiler check right? I guess I can’t expect much from someone who would advocate for doing important safety checks in an editor, or who uses the phrase “type masturbation” unironically. I’m just in awe of how, rather than answering this question with useful knowledge about how Swift and Objective-C are fundamentally incompatible languages in a lot of ways, you instead decided to show the Internet that you know nothing about programming languages.


dawmster

>point of Swift optionals is to make nullability a compiler check right So why do you have to write this line of code - and worse your variable gets renamed??? >you instead decided to show the Internet that you know nothing about programming languages I know everything about programming languages. To a point I can judge stupid things that brings nothing to application quality. NOTHING. At huge expense at Apple's part that should be used to push APPS, not 'programming language theory'. I bet dollars over peanuts I could write faster an app with Objective-C than you with "so-safe-my-ass" Swift . Swift enthusiast love to masturbate over syntax and types (C++ did that for decades) than solve how apps should work. This stupid graphics led by Johny Ive only survive thanks to Scotts Forestall UI design i.e. UIViews, Navigation Bar and Back Button. Federighi is a Yes Man B\*\*\*h.


SparklingOctopus3754

> So why do you have to write this line of code - and worse your variable gets renamed??? I think we fundamentally disagree on the role of safety in programming, and that’s fine. It’s not worth either of our time for me to try to convince you one way or the other. Although, I will say that worrying about a variable getting renamed is the smallest, most worthless implementation detail to worry about (and, in my experience, is rarely if ever an issue). > I know everything about programming languages. Dunning & Kruger would like to have a word with you. > I bet dollars over peanuts I could write faster an app with Objective-C than you with your “so-safe-my-ass” Swift . Even if that was true, that’s not necessarily the right metric to judge language quality. Fast code and safe (ie bug free) code are two different things, and I’d counter that I’d rather write safer code at a slower pace than churn out really shitty code really fast; I think Swift enables the former and Obj-C enables the latter more easily. But if you really think speed is the only important thing here, so be it. Again, it’s not my job to change your mind. > This stupid graphics led by Johny Ive … Finally some consensus — I completely agree that Apple graphics suck; that’s been a pet peeve of mine for a while. But, that’s still a very separate issue from the quality of Swift as a language. Also, I’m far from a Swift enthusiast; I just think you don’t know what you’re talking about. There’s a difference.


dawmster

My point is that rediscovering C++ or Rust in different skin is a waste of time and resources that should be put into dev tools. Qt used static C++ for UI and ended up with JavaScript (QML). And we still don’t have reliable code completion, and retarded C/C++ coop. Heck parts of SwiftUI are C++ under the hood.


SoftEngin33r

Because they want to tie us (the developers) to their platform, Objective-C can be mixed with C++ seamlessly and it is much better for reusing code across different operating systems and hardware platforms while also giving the ability to use high quality open source libraries, Even at Apple itself they look more for C++/Objective-C jobs rather than Swift ones, They know what is better.


vanvoorden

> Objective-C can be mixed with C++ seamlessly and it is much better for reusing code across different operating systems and hardware platforms while also giving the ability to use high quality open source libraries There is truth to this. A company like Apple worries (for the most part) about shipping code only on the Apple ecosystem. I suppose Apple Music is one of the few examples of a first party Apple app that exists on both Apple and Android. It is probably fair to assume there is a lot of Xplat C++ libraries in the Apple Music app (that deploy to both ecosystems) with UI code in Java and ObjC. It is possible for data model logic to live in C++ and UI logic to live in SwiftUI, but my understanding here is the amount of tedious ObjC infra you would need to write (by hand) to interop just makes the process annoying.


BedtimeWithTheBear

They look for Objective-C developers because they have a lot of legacy code that is not economically feasible to migrate to Swift, not because it’s better than Swift.


kanduvisla

But the Swift language is open source and you're also able to write Linux and Windows applications with it. There's also a compiler for Raspberry pi. Although it's true that 99% of the software that is written with Swift will be for the Apple eco-system, I don't think it's that much of a vendor lock-in for us developers. And isn't it still true that you can combine C / C++ libraries with Swift? Not sure about this one, since I'm only working with Swift a couple of months, but I do have 10+ years experience in software development in other languages.