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