3 ms·

Wouldn't most binaries not have UI anyways? Probably better to compare Swift UI to previous UI frameworks.

by kgc 5y ago

tambourine_man 5y ago
Swift was conceived and sold as an all purpose language. To an extreme degree, in fact. Lattner has said many times that it's intended from scripting to system programing[1]. Currently it's good at neither. I think a language that's simultaneously productive at this two extremes is impossible, but it was their goal. [1] https://developers.slashdot.org/story/17/01/23/085232/slashdots-interview-with-swift-creator-chris-lattner https://developers.slashdot.org/story/17/01/23/085232/slashd... “In short, I would NOT say that Swift is an extremely compelling systems programming or scripting language today, but it does aspire to be great for this in the years ahead.” Jan 2017
- urthor 5y ago
  I’ve had very few complaints with Swift as a backend language in all honesty. I can see it as a backend/systems language. It is not a scripting language. The issue is the stewardship of the ecosystem. The fact the Foundation library is closed source is a complete joke in this day and age. Apple’s lack of effort towards fostering a broader community for its language is a comedy of errors. A Swift developer will spend much time dealing with undocumented closed source packages. It’s almost comedic how retro it is. It’s like coding in the 1980s.
  - adamnemecek 5y ago
    > The fact the Foundation library is closed source is a complete joke in this day and age. Foundation is open source https://github.com/apple/swift-corelibs-foundation https://github.com/apple/swift-corelibs-foundation
  - andrewjl 5y ago
    The Foundation library on non-Apple platforms is open source: https://github.com/apple/swift-corelibs-foundation https://github.com/apple/swift-corelibs-foundation and intended to reach parity with the Apple version. > Our primary goal is to achieve implementation parity with Foundation on Apple platforms. This will help to enable the overall Swift goal of portability.
    - lolinder 5y ago
      But why are these even two separate libraries? Is it normal for different platforms to have different implementations of the standard library? I'd assumed that most of the library would have been written in Swift itself, which should theoretically make it be as platform-independent as Swift is.
      - olliej 5y ago
        This is assumption from first principles The Apple versions of foundation have to be compatible with the Foundation/CoreFoundation equivalents. They also have more than a decade of binary compat to maintain
      - andrewjl 5y ago
        Foundation is not the standard library of Swift. Swift has its own standard library that is bundled with the language on all platforms that are supported. And Foundation itself isn't written in Swift, a good portion is written in C. > A significant portion of the implementation of Foundation on Apple platforms is provided by another framework called CoreFoundation (a.k.a. CF). CF is written primarily in C and is very portable. Therefore we have chosen to use it for the internal implementation of Swift Foundation where possible. As CF is present on all platforms, we can use it to provide a common implementation everywhere. https://github.com/apple/swift-corelibs-foundation/blob/main/Docs/Design.md#portability https://github.com/apple/swift-corelibs-foundation/blob/main...
  - jollybean 5y ago
    If it were extremely well documented with a lot of nice examples the open/closed nature of the libs would be a secondary question.
- KerrAvon 5y ago
  It’s not impossible — Lisp exists and has been used in both contexts for decades. Swift needs some work to get there. There are a huge number of gaping holes, but these would be a start: - scripting: a native RegEx literal type - systems: replace Codable with something easier to use/more performant - systems: better logging interface Edit: formatting
  - tambourine_man 5y ago
    How successful are Lisp OSs?
- pjmlp 5y ago
  Sometimes I think an Objective-C 3.0, that would break with some of more problematic C flaws would have been better, even though I dislike @ and [] everywhere.
  - gurkendoktor 5y ago
    The question is, where does ObjC end and where does Swift start? When Apple announced an Objective-C without the C, I assumed they'd keep the Smalltalk object system and message passing. It still boggles my mind that they took a hard turn into the world of value semantics and extremely static types, with all the ABI problems that we know from C++, plus all the interop hacks to bridge both worlds. The syntax almost seems like a superficial detail compared to the new object model. On the other hand, the Smalltalk model would not have worked for SwiftUI. It really feels like Apple has bet the farm on the next generation of libraries/frameworks.
    - pjmlp 5y ago
      Not sure if they bet the farm as such, there are plenty of rants regarding how unsuitable SwiftUI is outside iOS for macOS workflows.

Wouldn't most binaries not have UI anyways? Probably better to compare Swift UI to previous UI frameworks.

by kgc 5y ago

Wouldn't most binaries not have UI anyways? Probably better to compare Swift UI to previous UI frameworks.

Swift was conceived and sold as an all purpose language. To an extreme degree, in fact. Lattner has said many times that it's intended from scripting to system programing[1]. Currently it's good at neither. I think a language that's simultaneously productive at this two extremes is impossible, but it was their goal. [1] https://developers.slashdot.org/story/17/01/23/085232/slashdots-interview-with-swift-creator-chris-lattner https://developers.slashdot.org/story/17/01/23/085232/slashd... “In short, I would NOT say that Swift is an extremely compelling systems programming or scripting language today, but it does aspire to be great for this in the years ahead.” Jan 2017

urthor 5y ago
I’ve had very few complaints with Swift as a backend language in all honesty. I can see it as a backend/systems language. It is not a scripting language. The issue is the stewardship of the ecosystem. The fact the Foundation library is closed source is a complete joke in this day and age. Apple’s lack of effort towards fostering a broader community for its language is a comedy of errors. A Swift developer will spend much time dealing with undocumented closed source packages. It’s almost comedic how retro it is. It’s like coding in the 1980s.
- adamnemecek 5y ago
  > The fact the Foundation library is closed source is a complete joke in this day and age. Foundation is open source https://github.com/apple/swift-corelibs-foundation https://github.com/apple/swift-corelibs-foundation
- andrewjl 5y ago
  The Foundation library on non-Apple platforms is open source: https://github.com/apple/swift-corelibs-foundation https://github.com/apple/swift-corelibs-foundation and intended to reach parity with the Apple version. > Our primary goal is to achieve implementation parity with Foundation on Apple platforms. This will help to enable the overall Swift goal of portability.
  - lolinder 5y ago
    But why are these even two separate libraries? Is it normal for different platforms to have different implementations of the standard library? I'd assumed that most of the library would have been written in Swift itself, which should theoretically make it be as platform-independent as Swift is.
    - olliej 5y ago
      This is assumption from first principles The Apple versions of foundation have to be compatible with the Foundation/CoreFoundation equivalents. They also have more than a decade of binary compat to maintain
    - andrewjl 5y ago
      Foundation is not the standard library of Swift. Swift has its own standard library that is bundled with the language on all platforms that are supported. And Foundation itself isn't written in Swift, a good portion is written in C. > A significant portion of the implementation of Foundation on Apple platforms is provided by another framework called CoreFoundation (a.k.a. CF). CF is written primarily in C and is very portable. Therefore we have chosen to use it for the internal implementation of Swift Foundation where possible. As CF is present on all platforms, we can use it to provide a common implementation everywhere. https://github.com/apple/swift-corelibs-foundation/blob/main/Docs/Design.md#portability https://github.com/apple/swift-corelibs-foundation/blob/main...
- jollybean 5y ago
  If it were extremely well documented with a lot of nice examples the open/closed nature of the libs would be a secondary question.
KerrAvon 5y ago
It’s not impossible — Lisp exists and has been used in both contexts for decades. Swift needs some work to get there. There are a huge number of gaping holes, but these would be a start: - scripting: a native RegEx literal type - systems: replace Codable with something easier to use/more performant - systems: better logging interface Edit: formatting
- tambourine_man 5y ago
  How successful are Lisp OSs?
pjmlp 5y ago
Sometimes I think an Objective-C 3.0, that would break with some of more problematic C flaws would have been better, even though I dislike @ and [] everywhere.
- gurkendoktor 5y ago
  The question is, where does ObjC end and where does Swift start? When Apple announced an Objective-C without the C, I assumed they'd keep the Smalltalk object system and message passing. It still boggles my mind that they took a hard turn into the world of value semantics and extremely static types, with all the ABI problems that we know from C++, plus all the interop hacks to bridge both worlds. The syntax almost seems like a superficial detail compared to the new object model. On the other hand, the Smalltalk model would not have worked for SwiftUI. It really feels like Apple has bet the farm on the next generation of libraries/frameworks.
  - pjmlp 5y ago
    Not sure if they bet the farm as such, there are plenty of rants regarding how unsuitable SwiftUI is outside iOS for macOS workflows.