12 ms·
I actually prefer Objective-C to Swift.
by _diyu 8y ago
I actually prefer Objective-C to Swift.
- aplummer 8y agoWhat got me over the line was optionals and protocols + generics, the safety and expressiveness combined will eventually (hopefully!) win you over!
- LeoNatan25 8y agoI prefer to keep the dynamism over unreadable fp "expressiveness" or safety that was not needed in the first place.
- aplummer 8y agoI’m surprised you downvoted this, we should be able to discuss pros / cons without downvoting people.
- saagarjha 8y agoThere's nothing stopping you from writing dynamic Swift code or functional programming in Objective-C.
- LeoNatan25 8y agoYes, but it’s not officially “condoned”, so it feels “out of place”. This is very individual, of course, but I don’t like bending the system to get patterns that are not “natively” supported. In Swift, you cannot currently create classes in code, enhance and swizzle, implement proper proxies. You couldn’t even load a nib without the ObjC runtime. Not even reflection. It’s telling what their priorities were with that language. What good is the language when you cannot implement most of the system frameworks (Cocoa, Core Data, etc.) without nasty hacks?
- aplummer 8y agoYou’ve made some good points though I’ve found the reflection in swift since v2 to be sufficient for my day to day. I think the nib thing is a problem but in reverse, nibs needs to be swift so we can instantiate them with generics, this would be a game changer!
- LeoNatan25 8y agoWithout reflection, you cannot create a nib system (or any general purpose archiving solution). For Encodable, they used hacks that were tantamount to macros in C, but that requires compile-time knowledge of the class/struct structure. That's not how nibs work.
- aplummer 8y agoAlso I agree you can tell safety was the number one priority. However the positive is basically never getting runtime errors, except when interfacing with IB or obj-c even when people are programming in a hurry, which is nice for me.
- saagarjha 8y ago> However the positive is basically never getting runtime errors I don't quite think this is the "safety" that Swift aims for: rather, it prefers safety in the sense of failing fast and failing reliably if something goes wrong. Unwrapping nil and out of bounds array subscripting fall into this category of behavior.
- mpweiher 8y agoHmm...like making every arithmetic operation a potential crash site?
- LeoNatan25 8y ago"Never getting runtime errors" is as far fetched as it can be. Consider Xcode suggesting developers use force unwrap ("!"), that leads to many more crashes with unexperienced developers than the ObjC message to nil paradigm. Subjectively, I have seen much more crashes in third-party software written in Swift than in ObjC (usually unwrapping or casting incorrectly), including in Apple's software. I cannot say if this is down to more inexperienced developers, less time allotted to experienced developers or a worse development model. I'd say a combination of the three.
- coldtea 8y agoOr building a house with toothpaste. But this was more about what's more common/supported by the language/approved by the community rather than what's possible.
- tzahola 8y agoYea, but you lose C++ interop, your binary will be inflated with those Swift proxy libs and your compilation times will increase 2-3-fold.
- LeoNatan25 8y agoThose are actually temporary problems. Once ABI stability is implemented, those DLLs will not be needed. The compiler is obviously a WIP and will take years to become more mature and optimized. Likewise for C++ interop. There are fundamental issues with Swift, but those are not them.
- saagarjha 8y agoI'm much more hopeful for ABI stability than C++ interoperatability. I think will take a long time before we'll be able to seamlessly work with C++ code as we do currently with say Objective-C or C.
- LeoNatan25 8y agoWeren’t some steps taken to start working on preliminary support, or at least building blocks? I might be mistaken.
- saagarjha 8y agoI've been mostly away from the Swift Forums for the last couple weeks, so if they've done something recently I probably missed it. Otherwise, though, AFAIK there's very few user-facing features that we can take advantage of right now. I do know that this is something that is on the roadmap, but so far the only changes related to this feature would be confined to the internals of the compiler, if at all. Here's a relatively recent thread by Doug Gregor where he outlines some of the challenges necessary to surmount if this feature is to ever land: https://forums.swift.org/t/c-objective-c-interop/9989 https://forums.swift.org/t/c-objective-c-interop/9989
- 8y ago
- apple4ever 8y agoThat in fact is all the things I don't like about Swift. I actually fine its way less expressive than Objective-C.
- adamnemecek 8y agoGive swift a week, you'll love it.
- checker659 8y agoSwift is a solution to a non existent problem.
- saagarjha 8y agoHow so? I personally feel that most of the changes Swift made to the language really do solve real problems that Apple and third party developers have had with Objective-C (and other languages, as well).
- gurkendoktor 8y agoIf I had to implement a compiler or a database, I'd definitely pick a language with a powerful and strict type system like Swift. It's fantastic when the compiler can prevent large classes of errors. I mean, even trivial concepts like an Array<Point2D> are frustrating to express in Objective-C (wrapping C structs with NSValue? Ugh). But that's not how iOS development works in my experience (YMMV). Most of the logic lives either in the backend or in C/C++ libraries, and Objective-C is just the glue between that and UI frameworks. When this glue layer gets complicated, it's usually because of animations, AutoLayout, UIKit bugs, or workarounds around performance issues. But all of these are issues with the frameworks, not with the programming language. Objective-C is effectively a domain-specific language for Cocoa. Swift aims to be the next big general-purpose programming language, but it's still only being used for Cocoa. I think this is fundamentally the wrong direction.
- apple4ever 8y agoCouldn't have summed it up better
- cageface 8y agoMy apps almost never crash since I switched to Swift. That alone gives it the edge over ObjC for me.
- checker659 8y agoHow do you do DSP work in Swift?
- cageface 8y agoMy synth app is still a C++/ObjC app. Integrating with C++ code is one area where ObjC still wins.
- saagarjha 8y agovDSP is exposed to Swift: https://developer.apple.com/documentation/accelerate/vdsp https://developer.apple.com/documentation/accelerate/vdsp
- mpweiher 8y agoThe same way you'd do in Ruby: call an optimized C library.
- cageface 8y agoThere are some legitimate criticisms to be made of Swift, particularly in regards to tooling. But if you feel obliged to downvote somebody for making a factual, if anecdotal, claim about their experience using it, you might want to question how much of your reaction is just resistance to change.
- jmpt 8y agoGood! Have you faced difficulty in the market by stating this to your employer and or in a job interview?
- coldtea 8y agoAs a professional, they work with what is asked, not with what they prefer -- especially when dealing with a platform that might totally stop supporting Obj-C down the line. So what they prefer would be irrelevant job wise.
- gurkendoktor 8y agoThey're professionals, not slaves. They might have a say in the choice of tools, and they can turn down jobs otherwise. There's still plenty of Objective-C work around.
- barbs 8y agoYou're not the only one https://www.hackingwithswift.com/articles/27/why-many-developers-still-prefer-objective-c-to-swift https://www.hackingwithswift.com/articles/27/why-many-develo...
- apple4ever 8y agoDefinitely not. I can't stand the Swift syntax or how it behaves.