So is Objective-C kinda going away after all?
If I did a greenfield iOS or OSX app would it be malpractice to do it in Objective-C?
Because I actually adore that language. Haven’t used it lately, but I do love it.
Swift Regrets
111–120 of 207 posts
Re: Swift Regrets
#112Honestly, I can't get my head around how anyone could prefer Objc over Swift. I suppose it's just years of writing Objc and not wanting the change?
Like Swift is not a perfect language and Apple's developer docs lack useful examples a lot of times, but Objective-C has to be the least approachable language in all of app development.
Re: Swift Regrets
#113Earlier quoted context omitted.
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.
> because the performant parts were written in C Objective-C is C. More specifically a strict superset of C. > Ignoring slick animations (which were written in C, if not in hand-tuned assembly) Nope. The reason the animations were smooth (not necessarily fast) is that they were processed by the GPU and orchestrated by a separate process.
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.)
Re: Swift Regrets
#114Earlier quoted context omitted.
Hypothetical designs are bandied about all the time https://medium.com/@mattmass/the-alternative-reality-of-obje... https://twitter.com/tolmasky/status/1401972686037913601 https://mjtsai.com/blog/2014/10/14/hypothetical-objective-c-... https://web.archive.org/web/20141224114850/https://swiftopin...
“Hypothetical” being the key word here, though. These proposals are all thin on details, and if it was so easy someone would’ve made such a language by now.
That's a bit bad faith, making a language is never easy and takes a ton of resources.
Swift is the bandwagon at Apple due to how Chris Latner started the project and his clout and I think it would be politically untenable to make ObjectiveSwift going against that, especially now at Apple.
Nobody else but apple would make ObjectiveSwift too, because for better or worst ObjC & Swift are languages that are for the apple platform and nothing else. If you don't need to make something for apple, and you're going to do it without major tech company sponsorship, then you have freedom and you go make things like Rust, Nim or Elm instead.
With all of Swift's problems, I would never recommend it for a server side platform, and it's adoption shows that reality.
Because of all of the above, you'll only see hypothetical proposals, no implementations.
Re: Swift Regrets
#115Earlier quoted context omitted.
Right! If it’s so slow, how did the original iPhone work so slickly, when all the apps and most of the frameworks were written in 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.
It raised the bar a lot, at least. The lag was nothing compared to what you got on the typical Java-enabled flip phone, or the original Android G1!
Re: Swift Regrets
#116Earlier quoted context omitted.
Hypothetical designs are bandied about all the time https://medium.com/@mattmass/the-alternative-reality-of-obje... https://twitter.com/tolmasky/status/1401972686037913601 https://mjtsai.com/blog/2014/10/14/hypothetical-objective-c-... https://web.archive.org/web/20141224114850/https://swiftopin...
“Hypothetical” being the key word here, though. These proposals are all thin on details, and if it was so easy someone would’ve made such a language by now.
No one is going to write a detailed estimate to paint your house if you've made it public knowledge you're not interested in your house being painted.
Re: Swift Regrets
#117Earlier quoted context omitted.
Actually plenty of people do want to and do so.
...and of course it was simple to interoperate with Objective-C in C++, in a way that it isn't for Swift, sadly
Which is super annoying when you have an engine written in C++, perhaps that runs on multiple platforms, and want to run it with a GUI under macOS.
Re: Swift Regrets
#118Earlier quoted context omitted.
If you develop for iOS|macOS professionally, you may be interested in Jetbrains' AppCode [0]. Note: I'm not connected in any way to Jetbrains, and I have not used AppCode myself, but I used other tools from them, and they're quite competent, I'd say. [0]: https://www.jetbrains.com/objc/
Apple professionals use Xcode. Using different tools than the ones Apple uses leads to a lot of problems that Apple are not interested in fixing. The days when a company like Metrowerks or Symantec could be a viable third party IDE supplier are long gone.
I don't do Apple development as much anymore, but I used to write in AppCode a lot and used Xcode only to build.
Re: Swift Regrets
#119Swift has way too many shorthand syntaxes. It feels nice from a language design perspective but when teaching Swift, you can see how confusing it is for the students. In larger codebases a lot of shorthands are forbidden by the organizations for consistency. So I'm not sure who's the real beneficiary for all those shorthands?
> So I'm not sure who's the real beneficiary for all those shorthands? Coffee shop and college project app developers who are chasing the cool (be it tricks or frameworks). That’s not a knock, but that’s who I see using these things. We were hiring a guy for a Flutter app that had no previous experience in Dart, but turned us down because Dart lacked some whiz bang feature he had too grown accustomed to. I did not se…
Could I ask what feature they were looking for? I haven't used Flutter in a while, but it left a good impression. I remember being far less annoyed using Flutter than I am using other declarative frameworks like SwiftUI.
Re: Swift Regrets
#120Earlier quoted context omitted.
> 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 vulnerabilitie…
> 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.
> 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.