4 ms·
> > and made the calling syntax much more complicated. > How is this true? Swift is very straightforward, and similar to other languages Swift is objectively
by mpweiher 5y ago
> > 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.
[1] https://www.quora.com/Which-features-overcomplicate-Swift-What-should-be-removed/answer/Rob-Rix https://www.quora.com/Which-features-overcomplicate-Swift-Wh...
[2] https://blog.metaobject.com/2020/06/the-curious-case-of-swift-adoption-of.html https://blog.metaobject.com/2020/06/the-curious-case-of-swif...
[3] https://blog.metaobject.com/2020/04/swift-initialization-swiftui-and.html https://blog.metaobject.com/2020/04/swift-initialization-swi...
[4] https://blog.metaobject.com/2014/09/no-virginia-swift-is-not-10x-faster.html https://blog.metaobject.com/2014/09/no-virginia-swift-is-not...
[5] https://www.amazon.com/gp/product/0321842847/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=0321842847&linkCode=as2&tag=metaobject-20&linkId=4f7c355096938fece9d7c880e6916ce8 https://www.amazon.com/gp/product/0321842847/ref=as_li_tl?ie...
[6] https://blog.metaobject.com/2020/04/faster-json-support-for-iosmacos-part-8.html https://blog.metaobject.com/2020/04/faster-json-support-for-...
[7] https://blog.metaobject.com/2014/05/the-spidy-subset-or-avoiding-copeland.html https://blog.metaobject.com/2014/05/the-spidy-subset-or-avoi...
- pjmlp 5y ago> 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.
- gurkendoktor 5y agoI 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.
- pjmlp 5y agoWhat can I say, lucky you. Now try the same with a couple of offshored projects from some famous consulting companies.
- gurkendoktor 5y agoFair 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.
- pjmlp 5y agoI agree in principle, but that doesn't change the fact that such kind of code might land on an application I depend on for some reason. Hence why I always advocate for better industry regulation, as I get to see how the sausage is made, and would like everyone gets more healthier. Most managements don't care about diligent programmers, only delivery.