7 ms·

> 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 cal

by zionic 5y ago

> 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 vulnerabilities lately have been from parts of the OS that still use ObjC, the sooner they get rid of that garbage the better.

protomyth 5y ago
How is this true? Swift is very straightforward, and similar to other languages That's the argument, most people want to program in JavaScript or C++, learning is such a bother. The Swift syntax is more characters than ObjC's syntax.
- jbluepolarbear 5y ago
  No it’s not. If you have multiple parameters Obj-C is much longer and ugly.
  - iainmerrick 5y ago
    Where are you getting this from? Swift’s mandatory named parameters come from Objective-C. For the most part only the bracket placement is different.
    - jbluepolarbear 5y ago
      Swift supports default and objc doesn’t. This makes calls smaller. Swift also has argument hiding with the underscore before the parameter. Swift also ask variable arguments. Hiding named parameters and variable arguments make calls much smaller. My point stands.
      - Apocryphon 5y ago
        That's not really "much" longer. And in some cases the brevity saved could really increase obfuscation and confusion.
        jbluepolarbear 5y ago
        Yes it is; especially, if there’s long parameter names. And I disagree with the obfuscation and confusion, but that’s a discussion on Swifts goal of self documentation not code length.
      - stefanfisk 5y ago
        you can define ObjC method parameters with empty selector names if you want. This for example is perfectly legal ObjC, callable as [foo gimmeAString:10 :"hey "]. - (NSString*)gimmeAString:(NSUInteger)count :(NSString*)piece { return [@"" stringByPaddingToLength:count withString:piece startingAtIndex:0]; }
    - zionic 5y ago
      Mandatory names parameters? You have been able to provide anonymous arguments since I first started playing with Swift in 2.0. The function just has to define it that way.
- zozbot234 5y ago
  C++ is of course a vastly more complex language than Swift. I don't think anyone would want to code in C++ these days if they can avoid it.
  - gumby 5y ago
    Actually plenty of people do want to and do so.
    - jlarcombe 5y ago
      ...and of course it was simple to interoperate with Objective-C in C++, in a way that it isn't for Swift, sadly
      - gumby 5y ago
        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.
        BorisRasin 5y ago
        You can use Scapix Language Bridge to automatically generate bindings for various languages directly from C++ headers: https://github.com/scapix-com/scapix https://github.com/scapix-com/scapix Disclaimer: I am the author of Scapix Language Bridge.
  - germandiago 5y ago
    I want. I do it. It gives me a level of control and a number of libs that no other language can give me, including all the C libs available as well. Yes, it is not pretty sometimes, but if you take a look at well-written C++ code you would be very surprised at how clean it can look. With its quirks from time to time, but very clean: - mark virtual overrides with override - use move semantics to increase performance - take advantage of RVO - write GUIs, CLIs, or servers - use lambdas and ranges - use smart pointers to get rid of most memory management - tune your server to allocate and deallocate in the desired patterns via polymorphic allocators or just plain allocators - take advantage of SIMD and parallelism (via parallel algorithms library, among many examples) - create generic infrastructure in algorithms with zero overhead penalty that is not even possible in other languages - keep things working for the next 2 or 3 decades without touching the code - Program in HPC environments C++ is much better than what most people that do not use it all the time think. It is not as bad as they put it, and, more important, it is very high performance. I admit this is one of the big reasons why people use it, but C++ for application programming does not look to me like crazy either.
- jshier 5y ago
  > The Swift syntax is more characters than ObjC's syntax. How so?
  - protomyth 5y ago
    well, no - Swift's call syntax actually results in the same or more characters: somePoint.moveBy(x: 2.0, y: 3.0) [somePoint moveByX: 2.0 y: 3.0]; somePoint.moveBy(x: 2.0, y: 3.0, z: 4.0) [somePoint moveByX: 2.0 y: 3.0 z: 4.0];
    - fingerlocks 5y ago
      Now do a string format example
saagarjha 5y ago
> 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.
- iainmerrick 5y ago
  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?
  - ace2358 5y ago
    Because the original iPhone was so stripped down that it could run on that thinly little slow cpu. It took Apple years and years to add features back into iOS frameworks. Every one very considered and every attempt to not destroy the battery of the iPhone. Multi tasking only around in iOS 4 right? Like on iPhoneOS 1 every app was closed when you hit that home button. That it worked so smoothly was the result of extremely focused UX.
  - Someone 5y ago
    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.
    - ajconway 5y ago
      Animations were slick (compared to other mobile platforms) because they were hardware accelerated.
    - mpweiher 5y ago
      > 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.
Apocryphon 5y ago
> I mean that's the vast majority of people Maybe... https://news.ycombinator.com/item?id=15421073 https://news.ycombinator.com/item?id=15421073 It's an old article by now, but check out the responders- Marco Arment, Steve Troughton-Smith, Marcel Weiher- pretty eminent iOS devs among them.
- rsfinn 5y ago
  Yes, that article is nearly four years old. Since then, Swift has evolved considerably. Steve Troughton-Smith has tweeted recently about his work in converting all of his apps to Swift over the last year [1]. "I will remember ObjC and the times we had together fondly, but after a year of being Swift-only I prefer making apps with it" [2]. "I also wouldn’t change the timeline in which I adopted Swift ... I don’t feel I lost out on anything positive by waiting" [3]. [1] https://twitter.com/stroughtonsmith/status/1439234176163663874 https://twitter.com/stroughtonsmith/status/14392341761636638... [2] https://twitter.com/stroughtonsmith/status/1421615798209110021 https://twitter.com/stroughtonsmith/status/14216157982091100... [3] https://twitter.com/stroughtonsmith/status/1421619378026582018 https://twitter.com/stroughtonsmith/status/14216193780265820... Marco Arment has talked about using Swift in new development for Overcast, although I don't believe he's rewriting existing code. He seems more open to Swift these days than when that article was written. (Can't find a quotable source at present) Marcel Weiher has continued working on a language now called Objective-S, which sounds like the "more Smalltalk-y" language that other commenters have wished for: "Objective-S includes an Objective-C compatible runtime model, but using a much simpler and consistent Smalltalk-based syntax." [4] [4] http://objective.st/About http://objective.st/About
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

by zionic 5y ago

protomyth 5y ago

How is this true? Swift is very straightforward, and similar to other languages That's the argument, most people want to program in JavaScript or C++, learning is such a bother. The Swift syntax is more characters than ObjC's syntax.

jbluepolarbear 5y ago
No it’s not. If you have multiple parameters Obj-C is much longer and ugly.
- iainmerrick 5y ago
  Where are you getting this from? Swift’s mandatory named parameters come from Objective-C. For the most part only the bracket placement is different.
  - jbluepolarbear 5y ago
    Swift supports default and objc doesn’t. This makes calls smaller. Swift also has argument hiding with the underscore before the parameter. Swift also ask variable arguments. Hiding named parameters and variable arguments make calls much smaller. My point stands.
    - Apocryphon 5y ago
      That's not really "much" longer. And in some cases the brevity saved could really increase obfuscation and confusion.
      - jbluepolarbear 5y ago
        Yes it is; especially, if there’s long parameter names. And I disagree with the obfuscation and confusion, but that’s a discussion on Swifts goal of self documentation not code length.
    - stefanfisk 5y ago
      you can define ObjC method parameters with empty selector names if you want. This for example is perfectly legal ObjC, callable as [foo gimmeAString:10 :"hey "]. - (NSString*)gimmeAString:(NSUInteger)count :(NSString*)piece { return [@"" stringByPaddingToLength:count withString:piece startingAtIndex:0]; }
  - zionic 5y ago
    Mandatory names parameters? You have been able to provide anonymous arguments since I first started playing with Swift in 2.0. The function just has to define it that way.
zozbot234 5y ago
C++ is of course a vastly more complex language than Swift. I don't think anyone would want to code in C++ these days if they can avoid it.
- gumby 5y ago
  Actually plenty of people do want to and do so.
  - jlarcombe 5y ago
    ...and of course it was simple to interoperate with Objective-C in C++, in a way that it isn't for Swift, sadly
    - gumby 5y ago
      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.
      - BorisRasin 5y ago
        You can use Scapix Language Bridge to automatically generate bindings for various languages directly from C++ headers: https://github.com/scapix-com/scapix https://github.com/scapix-com/scapix Disclaimer: I am the author of Scapix Language Bridge.
- germandiago 5y ago
  I want. I do it. It gives me a level of control and a number of libs that no other language can give me, including all the C libs available as well. Yes, it is not pretty sometimes, but if you take a look at well-written C++ code you would be very surprised at how clean it can look. With its quirks from time to time, but very clean: - mark virtual overrides with override - use move semantics to increase performance - take advantage of RVO - write GUIs, CLIs, or servers - use lambdas and ranges - use smart pointers to get rid of most memory management - tune your server to allocate and deallocate in the desired patterns via polymorphic allocators or just plain allocators - take advantage of SIMD and parallelism (via parallel algorithms library, among many examples) - create generic infrastructure in algorithms with zero overhead penalty that is not even possible in other languages - keep things working for the next 2 or 3 decades without touching the code - Program in HPC environments C++ is much better than what most people that do not use it all the time think. It is not as bad as they put it, and, more important, it is very high performance. I admit this is one of the big reasons why people use it, but C++ for application programming does not look to me like crazy either.
jshier 5y ago
> The Swift syntax is more characters than ObjC's syntax. How so?
- protomyth 5y ago
  well, no - Swift's call syntax actually results in the same or more characters: somePoint.moveBy(x: 2.0, y: 3.0) [somePoint moveByX: 2.0 y: 3.0]; somePoint.moveBy(x: 2.0, y: 3.0, z: 4.0) [somePoint moveByX: 2.0 y: 3.0 z: 4.0];
  - fingerlocks 5y ago
    Now do a string format example

saagarjha 5y ago

> 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.

iainmerrick 5y ago
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?
- ace2358 5y ago
  Because the original iPhone was so stripped down that it could run on that thinly little slow cpu. It took Apple years and years to add features back into iOS frameworks. Every one very considered and every attempt to not destroy the battery of the iPhone. Multi tasking only around in iOS 4 right? Like on iPhoneOS 1 every app was closed when you hit that home button. That it worked so smoothly was the result of extremely focused UX.
- Someone 5y ago
  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.
  - ajconway 5y ago
    Animations were slick (compared to other mobile platforms) because they were hardware accelerated.
  - mpweiher 5y ago
    > 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.

Apocryphon 5y ago

> I mean that's the vast majority of people Maybe... https://news.ycombinator.com/item?id=15421073 https://news.ycombinator.com/item?id=15421073 It's an old article by now, but check out the responders- Marco Arment, Steve Troughton-Smith, Marcel Weiher- pretty eminent iOS devs among them.

rsfinn 5y ago
Yes, that article is nearly four years old. Since then, Swift has evolved considerably. Steve Troughton-Smith has tweeted recently about his work in converting all of his apps to Swift over the last year [1]. "I will remember ObjC and the times we had together fondly, but after a year of being Swift-only I prefer making apps with it" [2]. "I also wouldn’t change the timeline in which I adopted Swift ... I don’t feel I lost out on anything positive by waiting" [3]. [1] https://twitter.com/stroughtonsmith/status/1439234176163663874 https://twitter.com/stroughtonsmith/status/14392341761636638... [2] https://twitter.com/stroughtonsmith/status/1421615798209110021 https://twitter.com/stroughtonsmith/status/14216157982091100... [3] https://twitter.com/stroughtonsmith/status/1421619378026582018 https://twitter.com/stroughtonsmith/status/14216193780265820... Marco Arment has talked about using Swift in new development for Overcast, although I don't believe he's rewriting existing code. He seems more open to Swift these days than when that article was written. (Can't find a quotable source at present) Marcel Weiher has continued working on a language now called Objective-S, which sounds like the "more Smalltalk-y" language that other commenters have wished for: "Objective-S includes an Objective-C compatible runtime model, but using a much simpler and consistent Smalltalk-based syntax." [4] [4] http://objective.st/About http://objective.st/About

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