5 ms·

No, and if you do, then I suggest you visit a doctor. Rant: Objective-C is a wonderful language, once you learn it properly. There's a lot of Swift fanboiism

by jmpt 8y ago

No, and if you do, then I suggest you visit a doctor. Rant: Objective-C is a wonderful language, once you learn it properly. There's a lot of Swift fanboiism (is that a word?) and a lot of Objective-C hate. I have an opinion on why. The vast majority of people that used Objective-C were drawn to the success of iOS. They were developers, used to languages like Javascript, Java or C++. Coming to Objective-C, their immediate reaction was "WUTT??? Brackets!" Instead of properly learning the idioms, they fought the language on a daily basis and cursed Apple for forcing them to use a language unlike the one they were used to, in order to jump on the iOS bandwagon. These people, once Swift was released, jumped boat immediately because they never really understood Objective-C and Swift is familiar. Another group of people: the seasoned Objective-C developers, with a clue, went: "hmmm... this doesn't solve any of my real problems," but they weren't stupid and Apple was quite clear that Swift was the future. They learned Swift, got used to the bad, learned how to like the good and went along their business. Another group of people actively dislike Swift, and really enjoy Objective-C. These are considered dinosaurs and have to either hide their opinion or face hiring difficulties, or even dismissal from companies where they are currently employed. Hiring managers, usually incompetent and non-technical in nature, ask: "Do you use Swift? Do you like it?" If you want a job, you must say yes. Disagree with me? Try a no. All new documentation is Swift oriented. All conferences and talks are in Swift. All new books are in Swift. You would have to be crazy to stick to Objective-C, but not for technical reasons. The Objective-C vs Swift debate is similar to vi vs emacs, except that vi and emacs would be built by the same company and that company explicitly said "emacs is the future." Nat, went like: screw this, and built https://www.mulle-kybernetik.com/weblog/2015/mulle_objc_a_new_objective_c_.html https://www.mulle-kybernetik.com/weblog/2015/mulle_objc_a_ne... Objective-C has warts. It is also fast. And stable. And quick to compile. Did I mention stable? It is also: stable. My code from 20 years ago still runs. Objective-C is a marriage of my two favorite programming languages: C and Smalltalk. Objective-C is message oriented, like Alan Kay envisioned, instead of object oriented. The focus should be messages and messaging to nil is a FEATURE. I actually quite like it. In Objective-C you can drop to C at any given time and have access to all the insanely fast libs. You can also write such insanely fast code yourself. Swift is immature, unstable, bloated, overengineering and extremely complex as a language. Complex as in C++ complex, but without the speed. Ever heard of Objective-C++? Yup. Everything I said, except exchange C for C++. Swift sacrifices LOTS of things and introduces new ideas that have yet to be proven efficient, and you get to rewrite your code all the time. Have something you wrote 2 years ago? Good luck with that. All productivity "supposedly" gained by Swift is lost to slow compiles, rewriting older code and migrating to the new version when it comes out. Swift is safe and everything. Right. Except developers with deadlines will just ! all the optionals when they get in the way. Prototype a new idea? Prepare to fight the compiler the entire time. Now, Swift does have some cool things, but so could a new version of Objective-C. In fact, ARC, which is pretty cool was born out of the development of Swift. In my opinion, Swift is not a great language. I would even say that it's not good. It's OK. Maybe one day it will be good, but this day is not today. All the love I hear is based on developers that resist learning something new (like Objective-C's way of doing things) and that's a good thing? I love Cocoa. There's an impedance mismatch between Swift and Cocoa. Objective-C + Cocoa is wonderful. Oh well. Objective-C is as good as dead and I'd rather write Go, Kotlin, C, Ruby, Erlang or even C++ than Swift.

checker659 8y ago
I still use manual reference counting :) In John Oliver’s voice : “Fuck you Apple, fuck you.”
- rimliu 8y ago
  This kind of bragging sound just like "I don't read books".
  - checker659 8y ago
    Does it? My bad.
  - mpweiher 8y ago
    To you, maybe. But that says more about you than the OP. The tangible benefits of ARC are at best marginal, and there are downsides, which some can reasonably find more significant, and thus ARC not worthwhile. First off, "manual" reference counting is misnamed. It is at the very least "semi-automatic" and highly automatable. So how does a property declaration look with "MRC" vs. ARC? @property (nonatomic,strong) NSString *str; vs. @property (nonatomic,strong) NSString *str; Can you tell which is which? So how about use? someObject.str = @"Hello World!"; vs. someObject.str = @"Hello World!"; Can you tell which is which? In use, ARC and MRC are mostly indistinguishable, as long as you use accessors/properties for all instance variable access. You do that, right? Right? OK, so there is automatic dealloc. That's a nice convenience, but actually not intrinsically tied to ARC. How do I know? I implemented automatic dealloc for a project once. Didn't use it much after because the small effort spent on dealloc just didn't seem worth it, especially as you also had other boilerplate to implement, the coders, isEqual and hash. The one biggie was weak, which was previously handled via non-retained references, so no automatic nilling. This could actually be a pain from time to time, but really not that huge a deal and it was also never really intrinsic to ARC, as shown by Apple recently adding weak for non-ARC code. So those are/were the upsides. Not really that much. Among the downsides is a performance penalty that could be both significant and somewhat unpredictable, on the order of 50%-100% slower in realistic scenarios (in extreme cases it can be an order of magnitude or more). You could also get unexpected crashes because of retain/releases added in unexpected places. We had a crash in a method that did nothing but return 0; http://blog.metaobject.com/2014/06/compiler-writers-gone-wild-arc-madness.html http://blog.metaobject.com/2014/06/compiler-writers-gone-wil... However, for me the biggest pain point was the semantic changes in ARCed-C: what used to be warnings about an unknown message are now hard compile errors, and that seriously cramps Objective-C's style as a quick-turnaround exploratory language. And yes, I have worked with/built both significant ARC and non-ARC codebases. What's really troubling about these things (GC, ARC, Swift) is the rabid fanboyism. When GC came out, you were complete idiot and a luddite if you didn't embrace it and all its numerous warts (which were beautiful) wholeheartedly, and buy into all the BS. Then when GC was dropped and replaced by ARC: same thing. Did anyone say GC? We meant beautiful shiny ARC, you ignorant luddite. And it quickly became an incontrovertible truth that ARC was faster than "MRC", despite the fact that this wasn't so. And when people asked about it, mentioning they had measured significant slowdowns, they were quickly attacked and everything questioned, because everybody "knew" the "truth". Until a nice gentleman from Apple chimed in an confirmed. Oops. So please ratchet down the fanboy setting. Technologies have upsides and downsides. Reasonable people can differ on how they weigh the upsides and the downsides. And of course we are seeing the same, just magnified by an extraordinary amount, with Swift.

by jmpt 8y ago

checker659 8y ago

I still use manual reference counting :) In John Oliver’s voice : “Fuck you Apple, fuck you.”

rimliu 8y ago
This kind of bragging sound just like "I don't read books".
- checker659 8y ago
  Does it? My bad.
- mpweiher 8y ago
  To you, maybe. But that says more about you than the OP. The tangible benefits of ARC are at best marginal, and there are downsides, which some can reasonably find more significant, and thus ARC not worthwhile. First off, "manual" reference counting is misnamed. It is at the very least "semi-automatic" and highly automatable. So how does a property declaration look with "MRC" vs. ARC? @property (nonatomic,strong) NSString *str; vs. @property (nonatomic,strong) NSString *str; Can you tell which is which? So how about use? someObject.str = @"Hello World!"; vs. someObject.str = @"Hello World!"; Can you tell which is which? In use, ARC and MRC are mostly indistinguishable, as long as you use accessors/properties for all instance variable access. You do that, right? Right? OK, so there is automatic dealloc. That's a nice convenience, but actually not intrinsically tied to ARC. How do I know? I implemented automatic dealloc for a project once. Didn't use it much after because the small effort spent on dealloc just didn't seem worth it, especially as you also had other boilerplate to implement, the coders, isEqual and hash. The one biggie was weak, which was previously handled via non-retained references, so no automatic nilling. This could actually be a pain from time to time, but really not that huge a deal and it was also never really intrinsic to ARC, as shown by Apple recently adding weak for non-ARC code. So those are/were the upsides. Not really that much. Among the downsides is a performance penalty that could be both significant and somewhat unpredictable, on the order of 50%-100% slower in realistic scenarios (in extreme cases it can be an order of magnitude or more). You could also get unexpected crashes because of retain/releases added in unexpected places. We had a crash in a method that did nothing but return 0; http://blog.metaobject.com/2014/06/compiler-writers-gone-wild-arc-madness.html http://blog.metaobject.com/2014/06/compiler-writers-gone-wil... However, for me the biggest pain point was the semantic changes in ARCed-C: what used to be warnings about an unknown message are now hard compile errors, and that seriously cramps Objective-C's style as a quick-turnaround exploratory language. And yes, I have worked with/built both significant ARC and non-ARC codebases. What's really troubling about these things (GC, ARC, Swift) is the rabid fanboyism. When GC came out, you were complete idiot and a luddite if you didn't embrace it and all its numerous warts (which were beautiful) wholeheartedly, and buy into all the BS. Then when GC was dropped and replaced by ARC: same thing. Did anyone say GC? We meant beautiful shiny ARC, you ignorant luddite. And it quickly became an incontrovertible truth that ARC was faster than "MRC", despite the fact that this wasn't so. And when people asked about it, mentioning they had measured significant slowdowns, they were quickly attacked and everything questioned, because everybody "knew" the "truth". Until a nice gentleman from Apple chimed in an confirmed. Oops. So please ratchet down the fanboy setting. Technologies have upsides and downsides. Reasonable people can differ on how they weigh the upsides and the downsides. And of course we are seeing the same, just magnified by an extraordinary amount, with Swift.