4 ms·

It seems like every Swift-related discussion here eventually devolves into a debate about the design and evolution of the language. Okay, I'll weigh in. Compar

It seems like every Swift-related discussion here eventually devolves into a debate about the design and evolution of the language. Okay, I'll weigh in. Comparing Swift with other important languages I have used such as C and SML, I think what's missing in Swift is a philosophy that inspires, motivates, and guides its development. I think Chris Lattner described Swift as a modern, practical language. Those are general characteristics but not the basis for a real philosophy. Others have described Swift as a "car crash" or "kitchen sink" language and I think those metaphors are apt. Swift seems to be trying to be imperative, functional, OO, and reactive all at the same time, with Obj-C compatibility thrown in for good measure. Complexity and intractability will inevitably follow.

skohan 6y ago
I actually like the kitchen-sink nature of Swift. If I could articulate a philosophy of Swift, it would be that the language prioritizes expressive, ergonomics and safety (in the single threaded case) over everything else. The fact that you have a kitchen sink of language features lets you carve out the language of your choice and write code according to whichever paradigm suits you as a developer. In spite of that, it might be a matter of opinion but I generally find Swift code among the most readable given the nature of the type system, and decisions around named arguments and when and how type inference may be applied.
- hu3 6y ago
  The issue is we don't work alone. There are different people, teams and third-party code we have to deal with. And their preferred subset of a kitchen sink language can vary wildly. > The fact that you have a kitchen sink of language features lets you carve out the language of your choice and write code according to whichever paradigm suits you as a developer.
  - chmaynard 6y ago
    Agreed. My only experience with someone else's Swift project was discouraging, to say the least. I thought I understood the basic language syntax and semantics, but the source code I reviewed was almost incomprehensible.
  - skohan 6y ago
    Well then the responsibility would be on the team to agree on a subset of the language and a set of design patterns to use. This is a process which happens in every language (with the exception of Go to some extent since it's so small and strict) but with Swift you have a bit more freedom over where you will end up. With regard to 3rd party code, you're also free to chose libraries where you agree with the interface paradigm they've chosen. I find this concern to be a bit overblown. In practice I've never really run into a case where somebody is doing something really exotic and inscrutable in Swift, and it's generally easier to understand than, for instance, a really esoteric Scala code base or a Rust project making heavy use of metaprogramming.
    - hu3 6y ago
      Let's agree to disagree because in my practice: - Teams: Less experienced developers will use fancy features trying to be smart. Every subset of the language finds it way on Pull Requests I review. - People change teams - People change companies - Third party code: It's not realistic to filter out libraries based on their use of the language. Who even has time to review that? Not to mention that high quality libraries are scarce enough that if you start to filtering out libraries you often end up with none. And the code doesn't have to be "exotic or inscrutable" to be a negative. It just needs to be unnecessarily of high cognitive load for it to impact use of the language. I've seen Swift developers squint at Pull Requests trying to gasp what certain part of the code was doing. It ended up being needless sugar and in turn a bit of everyone's time was wasted. That mindset of "just pick whatever part of the language suits you" is why C++ is what it is.
- dmitriid 6y ago
  The issue is that it's not even a good kitchen sink. Every single one if it's features is paper-thin, harmful or useless. You don't need `guard` if your compiler disambiguates nils and assigns vars in if statements. You don't need hundreds of hardcoded If<T1>, If<T1, T2> etc. types to support SwiftUI if your type system is actually designed to handle this. And you have proper expressions. And proper functions. You don't need an awkward `some` keyword if your type system is designed properly. You don't need callAsFunction because that's the compiler's job, not the programmer's. And can be replaced with any number of things, including (but not limited to) currying. And the list just goes on.
  - saagarjha 6y ago
    > You don't need `guard` if your compiler disambiguates nils and assigns vars in if statements. guard solves exactly one problem, and that's the one where if you have an if-let it makes your code indented. The compiler has support for the things you mentioned. > You don't need an awkward `some` keyword if your type system is designed properly. Swift's type system did handle it "properly", the issue was that with the type system you'd have this horrible monstrosity of a nested type when you really only cared about some very minimal erased part of it. > You don't need callAsFunction because that's the compiler's job, not the programmer's. And can be replaced with any number of things, including (but not limited to) currying. callAsFunction solves the problem of a closure having associated state that you can query, making them more object-like.
    - dmitriid 6y ago
      > guard solves exactly one problem > Swift's type system did handle it "properly", the issue was > callAsFunction solves the problem of a From the article : Swift is a crescendo of special cases stopping just short of the general; the result is complexity in the semantics, complexity in the behaviour (i.e. bugs), and complexity in use (i.e. workarounds).
      - skohan 6y ago
        I tend to disagree with this premise. Swift, like any language, has some questionable features, but in general I find it extremely consistent and easy to work with. I think mostly what people point to as "extra complexity" comes down to right-sized tools for handling nulls in a correct way, and syntactic sugar which makes it possible for write interfaces which make it possible to write code very close to the level of intent. When I read complaints like this I wonder if the author has spent almost no effort trying to learn the language and just wants to be able to sit down and write Go or C#.

skohan 6y ago

I actually like the kitchen-sink nature of Swift. If I could articulate a philosophy of Swift, it would be that the language prioritizes expressive, ergonomics and safety (in the single threaded case) over everything else. The fact that you have a kitchen sink of language features lets you carve out the language of your choice and write code according to whichever paradigm suits you as a developer. In spite of that, it might be a matter of opinion but I generally find Swift code among the most readable given the nature of the type system, and decisions around named arguments and when and how type inference may be applied.

hu3 6y ago
The issue is we don't work alone. There are different people, teams and third-party code we have to deal with. And their preferred subset of a kitchen sink language can vary wildly. > The fact that you have a kitchen sink of language features lets you carve out the language of your choice and write code according to whichever paradigm suits you as a developer.
- chmaynard 6y ago
  Agreed. My only experience with someone else's Swift project was discouraging, to say the least. I thought I understood the basic language syntax and semantics, but the source code I reviewed was almost incomprehensible.
- skohan 6y ago
  Well then the responsibility would be on the team to agree on a subset of the language and a set of design patterns to use. This is a process which happens in every language (with the exception of Go to some extent since it's so small and strict) but with Swift you have a bit more freedom over where you will end up. With regard to 3rd party code, you're also free to chose libraries where you agree with the interface paradigm they've chosen. I find this concern to be a bit overblown. In practice I've never really run into a case where somebody is doing something really exotic and inscrutable in Swift, and it's generally easier to understand than, for instance, a really esoteric Scala code base or a Rust project making heavy use of metaprogramming.
  - hu3 6y ago
    Let's agree to disagree because in my practice: - Teams: Less experienced developers will use fancy features trying to be smart. Every subset of the language finds it way on Pull Requests I review. - People change teams - People change companies - Third party code: It's not realistic to filter out libraries based on their use of the language. Who even has time to review that? Not to mention that high quality libraries are scarce enough that if you start to filtering out libraries you often end up with none. And the code doesn't have to be "exotic or inscrutable" to be a negative. It just needs to be unnecessarily of high cognitive load for it to impact use of the language. I've seen Swift developers squint at Pull Requests trying to gasp what certain part of the code was doing. It ended up being needless sugar and in turn a bit of everyone's time was wasted. That mindset of "just pick whatever part of the language suits you" is why C++ is what it is.
dmitriid 6y ago
The issue is that it's not even a good kitchen sink. Every single one if it's features is paper-thin, harmful or useless. You don't need `guard` if your compiler disambiguates nils and assigns vars in if statements. You don't need hundreds of hardcoded If<T1>, If<T1, T2> etc. types to support SwiftUI if your type system is actually designed to handle this. And you have proper expressions. And proper functions. You don't need an awkward `some` keyword if your type system is designed properly. You don't need callAsFunction because that's the compiler's job, not the programmer's. And can be replaced with any number of things, including (but not limited to) currying. And the list just goes on.
- saagarjha 6y ago
  > You don't need `guard` if your compiler disambiguates nils and assigns vars in if statements. guard solves exactly one problem, and that's the one where if you have an if-let it makes your code indented. The compiler has support for the things you mentioned. > You don't need an awkward `some` keyword if your type system is designed properly. Swift's type system did handle it "properly", the issue was that with the type system you'd have this horrible monstrosity of a nested type when you really only cared about some very minimal erased part of it. > You don't need callAsFunction because that's the compiler's job, not the programmer's. And can be replaced with any number of things, including (but not limited to) currying. callAsFunction solves the problem of a closure having associated state that you can query, making them more object-like.
  - dmitriid 6y ago
    > guard solves exactly one problem > Swift's type system did handle it "properly", the issue was > callAsFunction solves the problem of a From the article : Swift is a crescendo of special cases stopping just short of the general; the result is complexity in the semantics, complexity in the behaviour (i.e. bugs), and complexity in use (i.e. workarounds).
    - skohan 6y ago
      I tend to disagree with this premise. Swift, like any language, has some questionable features, but in general I find it extremely consistent and easy to work with. I think mostly what people point to as "extra complexity" comes down to right-sized tools for handling nulls in a correct way, and syntactic sugar which makes it possible for write interfaces which make it possible to write code very close to the level of intent. When I read complaints like this I wonder if the author has spent almost no effort trying to learn the language and just wants to be able to sit down and write Go or C#.