6 ms·

While the assumption that you can make changes to swift’s stl is not that far-fetched, doing so to cpp’s is completely mental. I’ve got a feeling that swift is

by 3jckd 6y ago

While the assumption that you can make changes to swift’s stl is not that far-fetched, doing so to cpp’s is completely mental. I’ve got a feeling that swift is becoming a very polluted mashup of features that come from parties with conflicting interests. AFAIK, internally at Apple, teams pull in different directions (e.g. to get SwiftUI), at the same time there’s this half-baked differentiable programming / swift4tf manifesto, then there’s the backend swift initiative with vapour. This reminds of a hotch-potch that Scala’s framework and feature landscape is. The overhead of getting into it is quite substantial and for some, definitely not worth the investment if not just downright scary.

jamil7 6y ago
> I’ve got a feeling that swift is becoming a very polluted mashup of features that come from parties with conflicting interests. There some truth to that I guess, but I'd also add that a lot of these modern multiparadigm languages feel like they're converging feature-wise (with a few outliers). I feel like Swift still has a unique enough feel to it and I enjoy working with it a lot. I think Chris Lattner has also expressed some concern about the focus on features over everything else.
- skohan 6y ago
  Yeah also having worked more with Rust, it seems that a lot of the features added to Swift recently could be covered by decent meta-programming support. That said, automatic differentiation could be a game-changer and should absolutely be included in the core language.
  - layoutIfNeeded 6y ago
    AD in the core language? Why? Automatic differentiation would be prime candidate to be implemented as a metaprogramming library.
    - Someone 6y ago
      The choice may have been made because Swift doesn’t support meta programming well enough to do it well purely in a library. The plan they have/had (https://github.com/apple/swift/blob/main/docs/DifferentiableProgramming.md https://github.com/apple/swift/blob/main/docs/Differentiable...) claims “First-class language support for differentiation will enable convenient, extensible, and performant differentiable programming in Swift - more so than library-based approaches”.
      - pcr910303 6y ago
        I think OP is claiming that if Swift had better meta programming abilities that GP have suggested, differentiable programming would have been a prime example for a good use of the capability.
        breatheoften 6y ago
        If the language defines a way for you to ask the program for the computation graph in order to differentiate -- couldn't you add meta programming functions on top of that computation graph? Seems to me like there's at least an argument that it should be possible grow diff programming into a general purpose meta programming system rather than use general purpose meta programming as implementation mechanism for differentiable programming ...
The_rationalist 6y ago
Name some swift features that add too much complexity / conflict with existing features. Then your reasoning could become more than a mere heuristic
- tl 6y ago
  I think for a lot of us, the addition of view builders and function builders that ignored the process of adding features to the language just so the SwiftUI team could use less punctutation was a jumping the shark moment for Swift. On top of that SwiftUI has been a disaster compared to Apple's existing UI toolkits because it's less featured than UIKit, less reliable and unlike UIKit, there's no new hardware forcing its adoption. None of this is new per se; weird Apple specific edges like @UIApplicationMain and @NSManaged have always polluted the language. But, it's hard to buy in on "Swift world domination" when server-side Swift is stillborn, Rust is more appealing as a better bare metal language, Catalyst and SwiftUI are weaker than AppKit and UIKit, the last time Swift got a useful language feature was guard let in Swift 2.
  - coldcode 6y ago
    So far I've not found SwiftUI usable for my work at my (large well known) employer. I like some of the concepts, but it's insufficient to actually use for our apps. Instead my team built a component system on top of UIKit that gives us the benefits of easier to build UI, without the "holy" and incomplete design of SwiftUI. Having Swift has allowed this work to be easy to construct and extremely type safe, and gives us the benefits of being able to do more work with fewer people, which was sort of the goal of SwiftUI, but in a more compatible way.
  - skohan 6y ago
    I totally agree with your point about SwiftUI: that also was a moment where I started looking to other languages in terms of what I should invest my energy in for the next few years due to the problems in governance with the language. On the point of "swift world domination", I still think this is largely a PR problem. I think Swift's identity as "compiled python" could make it a very good fit for many use cases where scripting languages are currently being used, due to it's clean, high level syntax and powerful type system. It still suffers a chicken-and-egg problem with respect to broader tooling and library support since it's viewed overwhelmingly as a language for making iOS apps.
oscargrouch 6y ago
> I’ve got a feeling that swift is becoming a very polluted mashup of features that come from parties with conflicting interests. AFAIK, internally at Apple, teams pull in different directions (e.g. to get SwiftUI), at the same time there’s this half-baked differentiable programming / swift4tf manifesto, then there’s the backend swift initiative with vapour. Cathedral and the Bazar.. You are basically complaining about how messy the bazar model is, and yet the bazar gave us Linux and in the end it won the race against all the others working over the Cathedral model and with millions of dollars invested in them. Its fine to work at the bazar model, and it seems messy at first, but as long theres a 'cathedralization' phase from time to time it will work as a living entity, with constant organic evolution.
travisgriggs 6y ago
This. The part about polluted mashup. I've developed and maintain 3 or so swift apps in the last 4 years. I also assist a colleague who ports and maintains them in Kotlin. At first I liked Swift. As a dynamic OO languages guy, I didn't like C++, and felt that Swift was a fresh approach to the non dynamic OO language. Over time, my enthusiasm has waned. For a while, I drank the value /struct programming koolaid. Too much. It turns out, that references are really really handy when your modeling real world things. Time and time again I've pushed myself to go the protocol route with structs, only to pull it out and just use simple single inheritance with real class based objects. The real trap I keep falling into is this. The Swift memory management story for objects is a fricking joke. First you have to constantly stress about ownership relationships, so that you don't get burned by cycles. And then you get to discover the various behind the scenes implicit refcointing rules around closures or passing methods directly in lieu of closures. And having to put [weak self] everywhere. So you react by using structs more. Because you believe it will be more efficient, etc. But structs come with their own problems. You put ids in your structs, because you need to assert identity of a given thing. Abstraction is more difficult. You get to dance with generics more. I've played with SwiftUI, I get the basic dream. It demos well. I could use it for simple CRUD style apps (which is what all the tutorials seem to be for). I'm just not sure how well it will scale to more complicated user interactions. As much as I don't like Android development and loathe Java, I'm forced to often just wish I could use Kotlin in iOS. It has its warts. And often there are too many ways to do one thing so that they can streamline a tiny amount of boilerplate away at the expense of consistency. But I fight it less.

by 3jckd 6y ago

jamil7 6y ago

> I’ve got a feeling that swift is becoming a very polluted mashup of features that come from parties with conflicting interests. There some truth to that I guess, but I'd also add that a lot of these modern multiparadigm languages feel like they're converging feature-wise (with a few outliers). I feel like Swift still has a unique enough feel to it and I enjoy working with it a lot. I think Chris Lattner has also expressed some concern about the focus on features over everything else.

skohan 6y ago
Yeah also having worked more with Rust, it seems that a lot of the features added to Swift recently could be covered by decent meta-programming support. That said, automatic differentiation could be a game-changer and should absolutely be included in the core language.
- layoutIfNeeded 6y ago
  AD in the core language? Why? Automatic differentiation would be prime candidate to be implemented as a metaprogramming library.
  - Someone 6y ago
    The choice may have been made because Swift doesn’t support meta programming well enough to do it well purely in a library. The plan they have/had (https://github.com/apple/swift/blob/main/docs/DifferentiableProgramming.md https://github.com/apple/swift/blob/main/docs/Differentiable...) claims “First-class language support for differentiation will enable convenient, extensible, and performant differentiable programming in Swift - more so than library-based approaches”.
    - pcr910303 6y ago
      I think OP is claiming that if Swift had better meta programming abilities that GP have suggested, differentiable programming would have been a prime example for a good use of the capability.
      - breatheoften 6y ago
        If the language defines a way for you to ask the program for the computation graph in order to differentiate -- couldn't you add meta programming functions on top of that computation graph? Seems to me like there's at least an argument that it should be possible grow diff programming into a general purpose meta programming system rather than use general purpose meta programming as implementation mechanism for differentiable programming ...

The_rationalist 6y ago

Name some swift features that add too much complexity / conflict with existing features. Then your reasoning could become more than a mere heuristic

tl 6y ago
I think for a lot of us, the addition of view builders and function builders that ignored the process of adding features to the language just so the SwiftUI team could use less punctutation was a jumping the shark moment for Swift. On top of that SwiftUI has been a disaster compared to Apple's existing UI toolkits because it's less featured than UIKit, less reliable and unlike UIKit, there's no new hardware forcing its adoption. None of this is new per se; weird Apple specific edges like @UIApplicationMain and @NSManaged have always polluted the language. But, it's hard to buy in on "Swift world domination" when server-side Swift is stillborn, Rust is more appealing as a better bare metal language, Catalyst and SwiftUI are weaker than AppKit and UIKit, the last time Swift got a useful language feature was guard let in Swift 2.
- coldcode 6y ago
  So far I've not found SwiftUI usable for my work at my (large well known) employer. I like some of the concepts, but it's insufficient to actually use for our apps. Instead my team built a component system on top of UIKit that gives us the benefits of easier to build UI, without the "holy" and incomplete design of SwiftUI. Having Swift has allowed this work to be easy to construct and extremely type safe, and gives us the benefits of being able to do more work with fewer people, which was sort of the goal of SwiftUI, but in a more compatible way.
- skohan 6y ago
  I totally agree with your point about SwiftUI: that also was a moment where I started looking to other languages in terms of what I should invest my energy in for the next few years due to the problems in governance with the language. On the point of "swift world domination", I still think this is largely a PR problem. I think Swift's identity as "compiled python" could make it a very good fit for many use cases where scripting languages are currently being used, due to it's clean, high level syntax and powerful type system. It still suffers a chicken-and-egg problem with respect to broader tooling and library support since it's viewed overwhelmingly as a language for making iOS apps.

oscargrouch 6y ago

> I’ve got a feeling that swift is becoming a very polluted mashup of features that come from parties with conflicting interests. AFAIK, internally at Apple, teams pull in different directions (e.g. to get SwiftUI), at the same time there’s this half-baked differentiable programming / swift4tf manifesto, then there’s the backend swift initiative with vapour. Cathedral and the Bazar.. You are basically complaining about how messy the bazar model is, and yet the bazar gave us Linux and in the end it won the race against all the others working over the Cathedral model and with millions of dollars invested in them. Its fine to work at the bazar model, and it seems messy at first, but as long theres a 'cathedralization' phase from time to time it will work as a living entity, with constant organic evolution.

travisgriggs 6y ago

This. The part about polluted mashup. I've developed and maintain 3 or so swift apps in the last 4 years. I also assist a colleague who ports and maintains them in Kotlin. At first I liked Swift. As a dynamic OO languages guy, I didn't like C++, and felt that Swift was a fresh approach to the non dynamic OO language. Over time, my enthusiasm has waned. For a while, I drank the value /struct programming koolaid. Too much. It turns out, that references are really really handy when your modeling real world things. Time and time again I've pushed myself to go the protocol route with structs, only to pull it out and just use simple single inheritance with real class based objects. The real trap I keep falling into is this. The Swift memory management story for objects is a fricking joke. First you have to constantly stress about ownership relationships, so that you don't get burned by cycles. And then you get to discover the various behind the scenes implicit refcointing rules around closures or passing methods directly in lieu of closures. And having to put [weak self] everywhere. So you react by using structs more. Because you believe it will be more efficient, etc. But structs come with their own problems. You put ids in your structs, because you need to assert identity of a given thing. Abstraction is more difficult. You get to dance with generics more. I've played with SwiftUI, I get the basic dream. It demos well. I could use it for simple CRUD style apps (which is what all the tutorials seem to be for). I'm just not sure how well it will scale to more complicated user interactions. As much as I don't like Android development and loathe Java, I'm forced to often just wish I could use Kotlin in iOS. It has its warts. And often there are too many ways to do one thing so that they can streamline a tiny amount of boilerplate away at the expense of consistency. But I fight it less.