I always felt that swift was introduced to allow the development ecosystem to grow and intended to be a language that eliminated some of the squishiness of Objective-C. My opinion is that this was intended to make Apple’s job of code review and approval easier and more concrete (business case?).
I like what Swift promised, but it comes with a ton of syntactic baggage. Objective-C is simple, there is a low bar to pick it up and run. But you need to adhere to mutually agreed ‘contracts’. This takes an investment of time. And what is time? $$$ and still there’s no guarantee. Swift is complicated and enforces all the contracts itself, syntactically. This was intended to yield good code without the need for ‘seasoning’ the developer. As was aptly put, you need to get on board and learn everything upfront. To me, the difference is philosophical… oohm If Swift solves your problems the high bar to learn and the oppressive syntactical nature becomes a small price to pay. It will be less philosophical when Apple stops releasing new feature support in Obj-C to force everyone over to Swift. In my opinion this is the direction, we’ll see if we get there. Apple loves the soft roll out. Think about the recent Carbon/Cocoa discussion. Obj-C represents the freedom for me to write bad code if I need to… this never happens, right? But honestly, I don’t have enough Swift experience to know if you can write bad Swift code. Anyways, I still prefer Obj-C. Sandor > On Oct 15, 2019, at 04:59, Alex Zavatone via Cocoa-dev > <cocoa-dev@lists.apple.com> wrote: > > >> On Oct 15, 2019, at 1:37 AM, Quincey Morris via Cocoa-dev >> <cocoa-dev@lists.apple.com <mailto:cocoa-dev@lists.apple.com>> wrote: >> >> The really important thing about using Swift is that you *have to* learn to >> change the way you think about dealing with nil values. > > And it’s a fucking cumbersome pain in the ass. Simply converting between > floats and integers that might be nil is an unwieldy pain in the ass. > > It’s a cumbersome and time wasting pain in the ass. And I’ve been doing this > for well over a year too. > > Here’s the dangerous area. What I have seen is that Swift lets you do stupid > shit in new and more complicated ways so that you need your most expensive > people to spend an extraordinary time debugging the problems created by your > most junior people. Why? Because they are doing things the new Swifty way, > that’s why?! And because someone wrote an article and published it on the > Internet, so it must be a good idea! > > Like my problems with VIPER. Our team has (against my direction) protocol > backed every class within our implementation of the VIPER pattern creating > monstrous retain cycles so that EVERY one of our 120+ screens NEVER gets > released. And with protocols and their strong variables backing every object > that confirms to them, it’s murder figuring which variables to turn weak in > the conforming classes and god forbid that the protocols are not class backed > or you’ll get yet another bizarre compile error. > > Also, if everything is a class extension, then nothing is. But at least it > makes nice little separator lines in the menus just like pragma mark - used > to in Objective-C. > > Swift is one big steaming pile of suck. It lets those who don’t know any > better think that they do and then with that hubris, go on and create very > Swifty nightmares. Our iOS feature tests still rebooted the Mac or crashed > the user session back to login as of mid last week. > > You really need to feel the joy of debugging 3,410 retain cycles - in VIPER, > with many interdependent classes conforming to multiple protocols that all > have strong vars, sometimes with vars directly assigned to a protocol. > > Yes, you read that right, 3,410 retain cycles. I have freaking 24 node > cycles and enough chained multi node retain loops that they are organic > chemistry moledules. Thankfully, I’m down to our last 300 > > Rant off. > > Lovely pics of retain cycles for you all to enjoy. These are the easy ones. > > https://imgur.com/a/pC3p9A5 > _______________________________________________ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/admin.szatmari.net%40gmail.com > > This email sent to admin.szatmari....@gmail.com _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
