4 ms·
Sane APIs (with exception of course, SwiftUI looked beyond Apple's ecosystem for inspiration). If you've been putting up with the [lack of] iOS API ergonomics
by zamalek 6y ago
Sane APIs (with exception of course, SwiftUI looked beyond Apple's ecosystem for inspiration).
If you've been putting up with the [lack of] iOS API ergonomics for years, by all means, Swift will look like a substantial step forward. If you're used to thoughtful and quality APIs, the marriage between Swift and NSDrunkApiDesign is an incredibly unattractive proposition.
I really just refuse to tolerate those APIs on platforms (.Net) and languages (Rust stdlib) where more sensible APIs are available. If there were an alternative stdlib for Swift that lacked/wrapped the iOS quirks, I'd probably be all for it.
- saagarjha 6y agoSwift ships with an extremely polished, well designed standard library out-of-the-box. You can use it with a simple "import Swift"…wait, you don't even need to do that, because it's available by default.
- zamalek 6y agoWhy do I then see NSGarbage all over the place in Swift code? Swift is a language facade over Objective C.
- saagarjha 6y agoBecause Swift allows interoperatability with Objective-C frameworks, such as the ones that ship with Apple's platforms. It's easy to see that Swift is not a language façade over Objective-C because you can write a type that cannot be represented in Objective-C almost trivially.
- zamalek 6y agoBut you still have to use the awful ObjectiveC idioms. That's the problem. I did not refer to the limited Swift wrappers, I in-fact explicitly excluded it.
- saagarjha 6y agoYou have to use Objective-C idioms because Apple wrote that code in Objective-C, not Swift. If your complaint is "why can't Swift take my Objective-C code and not only provide a fairly decent interface to it, completely change the API so that it fits perfectly into Swift regardless of issues like ownership and interface design" that's just an impossible bar to set for it.
- zamalek 6y agoRust has done that, with multiple platforms. .Net has done that, with multiple platforms. Dart has done that, with multiple platforms. Apple doesn't care for anything except iOS. That is why Swift won't be taken seriously on anything except iOS.
- saagarjha 6y agoAs far as I am aware, all of those require someone to explicitly go in and create a wrapper, which is worse than what Swift gives you out of the box. So how are they better?
- zamalek 6y agoBecause they all have 1st-party wrappers.
- saagarjha 6y agoSwift is adding their own as you can see, they’ve been using Foundation until now because it’s really not that bad of an interface. Also, I disagree with the claim that Rust has first-party wrappers, it barely has first-party anything to be honest.
- andrewjl 6y agoIn newer versions of Swift the need for almost all prefixing has been removed. You can still say it's a facade when using things like UIKit, but as we've seen in the past few years w/ SwiftUI that is changing. It's already no longer the case if you're doing anything related to heavy duty computation [Accelerate, Metal & others have Swift-specific APIs now] or networking [SwiftNIO].
- dmitriid 6y agoTruly an exceptionally beautiful and polished stdlib: https://twitter.com/dmitriid/status/1201441652507844608 https://twitter.com/dmitriid/status/1201441652507844608 I especially like that you have file operations defined on String type.
- saagarjha 6y agoThe first two lines of your example interact with the standard library.
- dmitriid 6y agoThe first two lines of which version? Also, how is it that a "well-designed and polished" standard library doesn't have a means to write to a file?
- saagarjha 6y agoEither version. And, FWIW, a standard library that is well-designed and polished can be spartan; Swift's has been on the operating system interface side because Foundation exists.
- pjmlp 6y agoThat is why the Linux examples are full of import Glibc.