I guess I was in the minority who loved Objective-C and it's selector syntax. I think my main objection to Swift is that it seems to be written by people who hate Objective-C and made the calling syntax much more complicated. I dearly wish a more mature F-Script had been the next Apple language.
A lot of the other problems is Apple not providing good documentation and making sure sample programs continue to compile. Bringing a new language into the world requires massive amounts of high quality documentation.
Despite the verbosity of the NS/Cocoa/etc APIs, Objective-C is a small, flexible, and unambiguous language. It performs very well at runtime, and is amazingly quick to compile. With version 2.0 and ARC, it became productive in addition to everything else.
I get it, it was long in the tooth, and the C legacy was both a blessing and a heavy weight holding the language back, but we lost a lot of the simplicity in the move to Swift.
> Bringing a new language into the world requires massive amounts of high quality documentation.
Very much agree. Not just a new language. Any complex endeavor requires this. I have written a server-based framework, including spending a great deal of time developing API documentation, and was relatively recently introduced to Postman. I have been using Postman to communicate the API to another engineer that is not RTFM (I've come to learn that folks don't like reading stuff, these days. I am looking at ways of communicating information in formats other than longform text).
I like Postman. The main issue with using it as a documentation source, is that it can easily become "cluttered"; especially as I use it in "back-and-forths," over particular commands.
I would have been lost, in my Swift education, without StackOverflow, although I hardly ever consult it anymore (mostly because it's rapidly becoming less useful; not because I don't need the help).
SwiftUI has some of the worst documentation I've ever encountered. Obviously, it was headerdoc-style, and no one was writing header docs, so I was constantly encountering empty pages. It was so bad, a generous individual developed this site and companion app[0]. I understand that the SwiftUI documentation is being rapidly improved. I haven't really started into a big learning drive on SwiftUI, yet, so I hope it is in better shape, by the time I get to it.
I was there with you too. Objective-C may have been verbose, but it was readable and easily modifiable.
It definitely seemed like the people who wrote Swift hated Objective-C. The "let", "func", etc syntax is ugly and unnecessary, along with the question marks.
I know I'm swimming against the tide, but I'll be writing Objective-C for as long as I can.
Absolutely this. Having accidental null values floating around a program should not be a thing in the year 2021. And that’s exactly what some languages are fixing, like Swift. This problem is also one of the reasons why I got so frustrated using clojure.
I disagree. Knowing if something could be nil is a very different thing than something unexpectedly becoming nil. If you have values that are guaranteed by the compiler to never be nil, that removes the burden completely.
In practice this gives you improperly constructed objects with bad state, returned from code some random person wrote in a hurry. Yes, it is bad code but so is most code in existence you have to interface with.
> I think my main objection to Swift is that it seems to be written by people who hate Objective-C
I mean that's the vast majority of people
>and made the calling syntax much more complicated.
How is this true? Swift is very straightforward, and similar to other languages
Meanwhile Objective-C is slow, unsafe by default, with super ugly syntax only a mother could love. More than half of Apple's CVE/iOS vulnerabilities lately have been from parts of the OS that still use ObjC, the sooner they get rid of that garbage the better.
> Meanwhile Objective-C is slow, unsafe by default, with super ugly syntax only a mother could love. More than half of Apple's CVE/iOS vulnerabilities lately have been from parts of the OS that still use ObjC,
Objective-C is quite fast–in many cases faster than Swift–and as (memory) safe as Swift for the most part. Most of Apple's CVEs come from code written in C or C++, not Objective-C.
If you look at the original review videos (or even the keynote), you may notice that the first iPhone lags quite a bit. Of course, it's not Objective-C that causes it, but rather the limited hardware of the time.
Their failure was due to management failures, stupid decisions like the "burning platforms" memo, or introducing new WP versions without backwards compatibility.
Nothing to do with the greatness of iOS that has created revisionists of the mobile computing platforms history.
For the same reason python is fast for machine learning: because the performant parts were written in C.
Ignoring slick animations (which were written in C, if not in hand-tuned assembly) typical UIs of apps on the original iPhone could have run (a bit slowly and in monochrome) on an original Mac, that is in 128kB RAM on a 8MHz CPU.
Yep -- and more than that, I’d say that animation orchestration worked well because of the very elegant design that leaned on Objective-C’s strengths (like dynamic key-value observation to track animatable properties).
And using reference-counting rather than garbage collection helped to minimise jankiness even on low-memory systems.
I think Android in particular had a very hard time matching iOS here because Java just didn’t lend itself to that dynamic programming style, and because the GC was just inherently janky. (It’s a lot better now that hardware is vastly faster.)
Because the original iPhone was so stripped down that it could run on that thinly little slow cpu. It took Apple years and years to add features back into iOS frameworks. Every one very considered and every attempt to not destroy the battery of the iPhone. Multi tasking only around in iOS 4 right? Like on iPhoneOS 1 every app was closed when you hit that home button.
That it worked so smoothly was the result of extremely focused UX.
> Objective-C is quite fast–in many cases faster than Swift–and as (memory) safe as Swift for the most part.
Ehhhh. If you write Swift the same way you write Obj-C, it will generally be as fast or faster. You only fall off the happy performance path when you use Swift features that don't even exist in Obj-C. That's not Swift being slower, that's Swift letting you use abstractions that aren't possible in Obj-C. But you don't _have_ to use them.
And given that Obj-C is a superset of C, you can't reasonably claim both that "most CVEs come from code written in C or C++" and also that Obj-C is as memory safe as Swift.
You can use the existing Obj-C libraries instead, which by definition do not use them.
I find it hilarious that Obj-C devotees object to this, since it precisely mirrors their argument for decades in the face of bogus performance complaints: “you can just use normal C functions”. They were right then, and you can just use Obj-C libraries today.
I think it’s a fair comparison to look at the idiomatic way to do something in a language and use that as the reference. Doing things on arrays in Swift often means people will call filter and reduce and map a bunch, while an Objective-C programmer might write a loop. It just so happens that LLVM can sometimes optimize the latter better. I mean, I could make the exact same argument you’re making about Objective-C being “as fast as C”: it literally is C. But when people use it they write methods and create objects, which are not things they can do in C. So I think it’s fair to call it “slower” if it needs to go through dynamic dispatch to enable the code that a normal developer would write.
This shouldn’t be true, ObjC’s only innate advantage is compile time, because the compiler is simply doing less and is capable of producing far worse (unsafe) code.
At runtime Swift can utilize static dispatch, where objective C is mostly dynamic. Good swift code should generally be faster.
Performance isn't about what you believe should be true, but about what actually is true. Kinda like science. (versus religion)
> ObjC’s only innate advantage is compile time
Objective-C has a bunch of advantages. Compile time isn't really one of them, except when compared to Swift, which is ridiculously slow to compile.
And there are languages with very comparable feature sets to Swift that are way faster to compile.
> At runtime Swift can utilize static dispatch
"can"
> where objective C is mostly dynamic.
Not true. The C part of Objective-C (it is most of the actual language) is very static.
Also, Swift has some pretty amazing dynamic performance pitfalls. For example protocols. You see, protocols in Swift can be adopted by both structs and classes. Meaning that when you call a function via a protocol, the compiler doesn't even know the size of the arguments or how to access them or copy them into the function's scope. So even that has to be handled by a small vtable, and you haven't actually done anything with that argument yet!
As this is one of the many places where Swift can lose a cool few orders of magnitude of performance, you obviously need the optimiser to specialise the function for specific callers. Which it can do, sometimes, at some cost, as long as it can actually see the caller and callee at the same time, in the same compilation unit.
IIRC, Uber had an OOPSLA paper describing the extra compiler pass they had to write to get their app's performance to at least somewhat acceptable levels, because the existing optimiser wasn't good enough.
And when you want to do separate compilation, you're sort of hosed, because you don't have access to the caller when you compile the callee.
Agree with most of your comment, but Uber’s thing was probably just as likely to be a team unable to say “no” to new code rather than one that “needed” people to anneal compiler passes
Yes, that article is nearly four years old. Since then, Swift has evolved considerably.
Steve Troughton-Smith has tweeted recently about his work in converting all of his apps to Swift over the last year [1]. "I will remember ObjC and the times we had together fondly, but after a year of being Swift-only I prefer making apps with it" [2]. "I also wouldn’t change the timeline in which I adopted Swift ... I don’t feel I lost out on anything positive by waiting" [3].
Marco Arment has talked about using Swift in new development for Overcast, although I don't believe he's rewriting existing code. He seems more open to Swift these days than when that article was written. (Can't find a quotable source at present)
Marcel Weiher has continued working on a language now called Objective-S, which sounds like the "more Smalltalk-y" language that other commenters have wished for: "Objective-S includes an Objective-C compatible runtime model, but using a much simpler and consistent Smalltalk-based syntax." [4]
> > and made the calling syntax much more complicated.
> How is this true? Swift is very straightforward, and similar to other languages
Swift is objectively one of the most complex languages out there[1]. Just recently, they adopted basically the entirety of Smalltalk syntax as an edge case of an edge case[2].
Just the rules for initialisers are more complex than many languages and still don't cover all the cases[3].
> Meanwhile Objective-C is slow,
The only people who believe this are those who have never measured (and have uncritically accepted Apple propaganda on this topic)[4]. Objective-C is a language you can easily write very fast code in (languages by themselves aren't fast or slow)[5]. Objective-C code is almost invariably faster than Swift code, and often by quite a lot.[6]
> unsafe by default,
Also not true. The id subset is quite safe[7] (and pretty fast), as are primitives. The parts that make C dangerous, particularly strings and other raw pointer accesses are abstracted away behind safe NSString, NSArray, NSData and friends.
> ugly syntax
Keyword syntax is actually highly elegant (Smalltalk's fits on a postcard) and extremely functional. So functional that Swift just recently added pretty much all of it as an edge case of an edge case of its closure syntax. Oh, did I already mention that?
> More than half of Apple's CVE/iOS vulnerabilities lately have been from parts of the OS that still use ObjC
Citation needed. Also: way more than half of the OS is still written in Objective-C, so you'd expect that.
> The parts that make C dangerous, particularly strings and other raw pointer accesses are abstracted away behind safe NSString, NSArray, NSData and friends.
True, and just like in C++, the C tribe that came into the language just ends up using char * most of the time, instead of the safe variants.
I have jumped into several badly written ObjC projects and I skimmed the source code of every CocoaPod that I've used, and I have never seen ObjC code that used C string/memory handling "most of the time". Not even when ObjC required manual reference counting.
Except for a couple of malloc'd C arrays (as an optimization over using NSArray<NSValue>), most of it was for interop with C libraries, the same code where in Swift you'd have to use UnsafeMutablePointer.
Fair enough, but I also don't see why we should judge languages based on the absolute worst projects written in them.
For example, the offshore Swift programmers I've encountered will add "?? 0", "?? []" etc. into expressions involving optionals until they compile. That doesn't mean that Swift's nullability is pointless, it's still a great tool for diligent programmers.
How is this true? Swift is very straightforward, and similar to other languages
That's the argument, most people want to program in JavaScript or C++, learning is such a bother. The Swift syntax is more characters than ObjC's syntax.
I want. I do it. It gives me a level of control and a number of libs that no other language can give me, including all the C libs available as well.
Yes, it is not pretty sometimes, but if you take a look at well-written C++ code you would be very surprised at how clean it can look. With its quirks from time to time, but very clean:
- mark virtual overrides with override
- use move semantics to increase performance
- take advantage of RVO
- write GUIs, CLIs, or servers
- use lambdas and ranges
- use smart pointers to get rid of most memory management
- tune your server to allocate and deallocate in the desired patterns via polymorphic allocators or just plain allocators
- take advantage of SIMD and parallelism (via parallel algorithms library, among many examples)
- create generic infrastructure in algorithms with zero overhead penalty that is not even possible in other languages
- keep things working for the next 2 or 3 decades without touching the code
- Program in HPC environments
C++ is much better than what most people that do not use it all the time think. It is not as bad as they put it, and, more important, it is very high performance. I admit this is one of the big reasons why people use it, but C++ for application programming does not look to me like crazy either.
If besides best possible performance you also value ergonomics, security, maturity and tooling then IMO nothing comes close to C++, especially C++17 and later. Not that there is much choice really, only C and Rust can realistically get you comparable performance, each with their own problems.
Swift supports default and objc doesn’t. This makes calls smaller. Swift also has argument hiding with the underscore before the parameter. Swift also ask variable arguments. Hiding named parameters and variable arguments make calls much smaller. My point stands.
Yes it is; especially, if there’s long parameter names. And I disagree with the obfuscation and confusion, but that’s a discussion on Swifts goal of self documentation not code length.
However I've come to appreciate Swift a lot more recently. What had taken pages of code can now be coded in just a page of Swift. That's nice.
I still like OBjC, nonetheless. But I'm liking Swift a bit more. The fact that it's stabilizing is a key feature to this. My objections to Swift have been how changes would pull the rug out from under what you'd already learned and coded before 5.0.
I agree with the documentation issue. A lot of features can't be found short of watching WWDC videos. And even then...
The other issues are "bad faith" and "bad intent" with privacy lately. I've actively removing and abandoning most of my use of iCloud because I can't really trust Apple even on that anymore.
I can't stand Objective-C, but I'm pretty apathetic towards Swift. As far as I can see, Swift simply swapped Obj-C's terrible syntax for its own, equally terrible syntax.
I probably would have been more enthusiastic about "Obj-C 2.0" than Swift.
I didn't mind Obj-C, it had its own elegance and logic, and Apple really made strides in making it more ergonomic with features like ARC and of course the excellent xcode editor. I still miss using my apple mouse's horizontal scroll to navigate between files.
The obj-c drivers from next/OpenStep were replaced with a restricted subset of C++ (not objective-C++) IOKit system. I'm not sure what system GP is referring to based off Obj-C++ but I assume it's not the drivers?
A lot of the other problems is Apple not providing good documentation and making sure sample programs continue to compile. Bringing a new language into the world requires massive amounts of high quality documentation.