8 ms·

What are the advantages, if any, in a nutshell?

by kensai 6y ago

akmarinov 6y ago
Of Swift and SwiftUI?
ratww 6y ago
Advantages of Swift and SwiftUI? Nevermind, I'll try to answer both: For Swift it's a modern language that doesn't need to have backward compatibility with C that Objective-C had. It has a very expressive syntax and uses modern idioms you see in JS, Kotlin, Rust, Scala, C#, etc. It has a modern type system with type inference, string templating, Option type, tuples and simpler closures. It's pretty nice actually. SwiftUI is just a way of writing UIs using Swift and a reactive paradigm. It looks and feels like React but instead of the embedded HTML of React it only uses plain Swift. The previous recommended method used XML (in XIB files) and needed special tooling (Interface Builder), which was nice but not perfect. Also doing git merges in the XML files are much harder.
- _qulr 6y ago
  > For Swift it's a modern language that doesn't need to have backward compatibility with C that Objective-C had. That doesn't seem accurate. Interoperability with C and Objective-C was a fundamental design requirement of Swift. C interoperability is not particularly pleasant in Swift, but it's certainly there. It has to be there. Apple has been creating some easier to use Swift wrappers around old UNIX C API. For example, their Network framework, and the just-announced Swift System.
  - Jtsummers 6y ago
    I think GP meant syntactic compatibility. Objective-C is an embedding within C and C++ code and has to be (mostly) compatible with them for the free mingling of each language. Swift is freed from that need, but that doesn't mean it isn't designed for interop (calling between each language).
  - ratww 6y ago
    No, it is accurate. Notice I didn't say interoperability, I said backwards compatibility. Objective-C is a superset of C, so any valid C code is also valid Objective-C code, including all the pitfalls and footguns. This is similar to the relationship between C and C++, however C++ isn't strictly a superset of C.
    - _qulr 6y ago
      > I said backwards compatibility This phrase isn't entirely clear. > Objective-C is a superset of C This phrase is clearer. In any case, I'm not fully convinced which language has the advantage and which the disadvantage in this case. You still have to call C API in Swift, and it's rather painful.
      - _qulr 6y ago
        I would also say that Swift by design is very much constrained, you might say held back, by the needs of Cocoa compatibility. For example, Swift takes features that are mere conventions in Objective-C, such as initializer patterns (which can be ignored when they're inconvenient), and makes them into built-in language requirements. This becomes very awkward at times. Perhaps the worst, "ugliest" feature of Swift is optionals. Why would you even add optionals to a new language if not for the necessity of Cocoa/ObjC compatibility. The language would be so much nicer without them.
        ratww 6y ago
        Optionals doesn't exist because of ObjC compatibility. They are a hallmark feature in functional languages like Haskell and Scala, and in other modern languages like Rust and Kotlin. Even C++17 introduced std::optional. And I completely disagree, they are one of the best features of any language and are able to remove a whole class of very annoying bugs. And sorry, but I didn't understand the part about the initializer pattern... are you talking about constructor overloading? This has also been a traditional feature of OOP languages for decades.
        6y ago
  - deleted 6y ago
    [deleted]
- machello13 6y ago
  > The previous method used XML (in XIB files) and needed special tooling (Interface Builder) This isn't really true. Interface Builder was an alternative to writing UI code, but programmatic UI is still allowed and is well-supported. Many developers prefer it to IB.
  - ratww 6y ago
    That's true, thanks. I amended my answer to say "previous recommended method".
  - pavlov 6y ago
    Mix & match was always the best way, IMO. Use IB to build small components and highest-level layouts. Use code for everything in between, as well as individual views.
- aidos 6y ago
  There was an interesting discussion about reactive UIs yesterday (https://news.ycombinator.com/item?id=24599560 https://news.ycombinator.com/item?id=24599560). Sounds like Swift have it fairly sorted. Is there anything like React Native for Swift rendering to html? A sort of “Swift Non Native”?
  - ratww 6y ago
    I remember seeing this project here in HN (or was it Reddit?), but it's more of a proof of concept: https://github.com/zhuowei/marina https://github.com/zhuowei/marina The code itself is pretty easy to understand: https://github.com/zhuowei/marina/blob/master/marina_html.swift https://github.com/zhuowei/marina/blob/master/marina_html.sw... I think SwiftUI is still settling, so I expect to see more movement in this are in the short-term future. But I don't see Apple releasing an HTML-emitting-SwiftUI by themselves.
  - extra88 6y ago
    SwiftWebUI [0], "write SwiftUI Views which display in a web browser." HN discussion [1] from last year of SwiftWebUI. [0] https://www.alwaysrightinstitute.com/swiftwebui/ https://www.alwaysrightinstitute.com/swiftwebui/ [1] https://news.ycombinator.com/item?id=20320820 https://news.ycombinator.com/item?id=20320820
- grishka 6y ago
  > It has a very expressive syntax and uses modern idioms you see in JS, Kotlin, Rust, Scala, C#, etc. Yeah and that's exactly what I would call a disadvantage. I prefer dumb programming languages like Java, C++11 without the auto keyword, and Objective-C. They're much easier to understand because there are fewer ways to achieve the same thing and they don't require keeping as much context in your head while reading the code. IRL example with Swift: I wanted to fix a logic bug in someone else's code and spent an hour trying to get a field from an object. I could see it in the debugger but every way to get it I could think of produced an uninformative syntax error. There was nothing to google because there were no keywords around it, even. Then the author of the code in question came online and explained that it's an "enum with associated value" (wtf?!) and you have to use this `if let` or `case let` abomination to extract the fields into local variables. Another IRL example with Swift is that this whole immutability-by-default thing was just driving me insane because I'm too used to the fact that I can overwrite function/method arguments but Swift won't ever let me.
  - saagarjha 6y ago
    > C++11 without the auto keyword That's still a massive language; the part you removed makes it basically be C++03 but even worse :/
    - grishka 6y ago
      How worse? How would you even begin to understand this line without an IDE? auto something = someObject->someFunction(); // and then 10 lines of various operations on "something" // also imagine that someObject is also auto and returned from somewhere I've had to deal with code like this. It wasn't pleasant, even with an IDE. There are very few cases where type inference is good and doesn't make your code an unreadable mess.
      - vips7L 6y ago
        You just need to use auto properly. auto/var/val etc are best used when you can tell the type from the rvalue. var m = new HashMap<String, List<Pair<X, Y>>>(); var m: Map<String, List<Pair<X, Y>>> = obj->someFunc(); All of the examples you have should be caught in linting or code review.
biztos 6y ago
I'll try to answer as a relative Swift newbie: 1. Modern language with conventions that will feel "normal" to ambitious younger programmers. 2. Lots of special language features to support the specific use-cases of iOS apps. As Go is to writing for server farms at Google, so is Swift to writing for Apple devices. 3. Very simple UI programming paradigm, at some point, maybe now? SwiftUI is or isn't production-ready depending whom you ask, but if we treat this as the future for iOS then it means any kind of data-centric or CRUD app will be trivial to bootstrap. 4. Sooner or later you will have no choice. Granted, #4 is not an advantage to the language, but maybe to learning it?
- ratww 6y ago
  > 4. Sooner or later you will have no choice. Consider it's also possible to use other languages like JS/TS (via React Native, Phonegap, etc), Dart (via Flutter), C# (via Xamarin) or even Delphi (via Embarcadero RadStudio), among others, so even in the unlikely event of Apple deprecating Objective-C, choice is not really going away.

What are the advantages, if any, in a nutshell?

by kensai 6y ago

What are the advantages, if any, in a nutshell?

akmarinov 6y ago

Of Swift and SwiftUI?

ratww 6y ago

Advantages of Swift and SwiftUI? Nevermind, I'll try to answer both: For Swift it's a modern language that doesn't need to have backward compatibility with C that Objective-C had. It has a very expressive syntax and uses modern idioms you see in JS, Kotlin, Rust, Scala, C#, etc. It has a modern type system with type inference, string templating, Option type, tuples and simpler closures. It's pretty nice actually. SwiftUI is just a way of writing UIs using Swift and a reactive paradigm. It looks and feels like React but instead of the embedded HTML of React it only uses plain Swift. The previous recommended method used XML (in XIB files) and needed special tooling (Interface Builder), which was nice but not perfect. Also doing git merges in the XML files are much harder.

_qulr 6y ago
> For Swift it's a modern language that doesn't need to have backward compatibility with C that Objective-C had. That doesn't seem accurate. Interoperability with C and Objective-C was a fundamental design requirement of Swift. C interoperability is not particularly pleasant in Swift, but it's certainly there. It has to be there. Apple has been creating some easier to use Swift wrappers around old UNIX C API. For example, their Network framework, and the just-announced Swift System.
- Jtsummers 6y ago
  I think GP meant syntactic compatibility. Objective-C is an embedding within C and C++ code and has to be (mostly) compatible with them for the free mingling of each language. Swift is freed from that need, but that doesn't mean it isn't designed for interop (calling between each language).
- ratww 6y ago
  No, it is accurate. Notice I didn't say interoperability, I said backwards compatibility. Objective-C is a superset of C, so any valid C code is also valid Objective-C code, including all the pitfalls and footguns. This is similar to the relationship between C and C++, however C++ isn't strictly a superset of C.
  - _qulr 6y ago
    > I said backwards compatibility This phrase isn't entirely clear. > Objective-C is a superset of C This phrase is clearer. In any case, I'm not fully convinced which language has the advantage and which the disadvantage in this case. You still have to call C API in Swift, and it's rather painful.
    - _qulr 6y ago
      I would also say that Swift by design is very much constrained, you might say held back, by the needs of Cocoa compatibility. For example, Swift takes features that are mere conventions in Objective-C, such as initializer patterns (which can be ignored when they're inconvenient), and makes them into built-in language requirements. This becomes very awkward at times. Perhaps the worst, "ugliest" feature of Swift is optionals. Why would you even add optionals to a new language if not for the necessity of Cocoa/ObjC compatibility. The language would be so much nicer without them.
      - ratww 6y ago
        Optionals doesn't exist because of ObjC compatibility. They are a hallmark feature in functional languages like Haskell and Scala, and in other modern languages like Rust and Kotlin. Even C++17 introduced std::optional. And I completely disagree, they are one of the best features of any language and are able to remove a whole class of very annoying bugs. And sorry, but I didn't understand the part about the initializer pattern... are you talking about constructor overloading? This has also been a traditional feature of OOP languages for decades.
        6y ago
- deleted 6y ago
  [deleted]
machello13 6y ago
> The previous method used XML (in XIB files) and needed special tooling (Interface Builder) This isn't really true. Interface Builder was an alternative to writing UI code, but programmatic UI is still allowed and is well-supported. Many developers prefer it to IB.
- ratww 6y ago
  That's true, thanks. I amended my answer to say "previous recommended method".
- pavlov 6y ago
  Mix & match was always the best way, IMO. Use IB to build small components and highest-level layouts. Use code for everything in between, as well as individual views.
aidos 6y ago
There was an interesting discussion about reactive UIs yesterday (https://news.ycombinator.com/item?id=24599560 https://news.ycombinator.com/item?id=24599560). Sounds like Swift have it fairly sorted. Is there anything like React Native for Swift rendering to html? A sort of “Swift Non Native”?
- ratww 6y ago
  I remember seeing this project here in HN (or was it Reddit?), but it's more of a proof of concept: https://github.com/zhuowei/marina https://github.com/zhuowei/marina The code itself is pretty easy to understand: https://github.com/zhuowei/marina/blob/master/marina_html.swift https://github.com/zhuowei/marina/blob/master/marina_html.sw... I think SwiftUI is still settling, so I expect to see more movement in this are in the short-term future. But I don't see Apple releasing an HTML-emitting-SwiftUI by themselves.
- extra88 6y ago
  SwiftWebUI [0], "write SwiftUI Views which display in a web browser." HN discussion [1] from last year of SwiftWebUI. [0] https://www.alwaysrightinstitute.com/swiftwebui/ https://www.alwaysrightinstitute.com/swiftwebui/ [1] https://news.ycombinator.com/item?id=20320820 https://news.ycombinator.com/item?id=20320820
grishka 6y ago
> It has a very expressive syntax and uses modern idioms you see in JS, Kotlin, Rust, Scala, C#, etc. Yeah and that's exactly what I would call a disadvantage. I prefer dumb programming languages like Java, C++11 without the auto keyword, and Objective-C. They're much easier to understand because there are fewer ways to achieve the same thing and they don't require keeping as much context in your head while reading the code. IRL example with Swift: I wanted to fix a logic bug in someone else's code and spent an hour trying to get a field from an object. I could see it in the debugger but every way to get it I could think of produced an uninformative syntax error. There was nothing to google because there were no keywords around it, even. Then the author of the code in question came online and explained that it's an "enum with associated value" (wtf?!) and you have to use this `if let` or `case let` abomination to extract the fields into local variables. Another IRL example with Swift is that this whole immutability-by-default thing was just driving me insane because I'm too used to the fact that I can overwrite function/method arguments but Swift won't ever let me.
- saagarjha 6y ago
  > C++11 without the auto keyword That's still a massive language; the part you removed makes it basically be C++03 but even worse :/
  - grishka 6y ago
    How worse? How would you even begin to understand this line without an IDE? auto something = someObject->someFunction(); // and then 10 lines of various operations on "something" // also imagine that someObject is also auto and returned from somewhere I've had to deal with code like this. It wasn't pleasant, even with an IDE. There are very few cases where type inference is good and doesn't make your code an unreadable mess.
    - vips7L 6y ago
      You just need to use auto properly. auto/var/val etc are best used when you can tell the type from the rvalue. var m = new HashMap<String, List<Pair<X, Y>>>(); var m: Map<String, List<Pair<X, Y>>> = obj->someFunc(); All of the examples you have should be caught in linting or code review.

biztos 6y ago

I'll try to answer as a relative Swift newbie: 1. Modern language with conventions that will feel "normal" to ambitious younger programmers. 2. Lots of special language features to support the specific use-cases of iOS apps. As Go is to writing for server farms at Google, so is Swift to writing for Apple devices. 3. Very simple UI programming paradigm, at some point, maybe now? SwiftUI is or isn't production-ready depending whom you ask, but if we treat this as the future for iOS then it means any kind of data-centric or CRUD app will be trivial to bootstrap. 4. Sooner or later you will have no choice. Granted, #4 is not an advantage to the language, but maybe to learning it?

ratww 6y ago
> 4. Sooner or later you will have no choice. Consider it's also possible to use other languages like JS/TS (via React Native, Phonegap, etc), Dart (via Flutter), C# (via Xamarin) or even Delphi (via Embarcadero RadStudio), among others, so even in the unlikely event of Apple deprecating Objective-C, choice is not really going away.