3 ms·

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 compil

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#.
    - dmitriid 6y ago
      I spent no effort learning C#. I just sat down and started writing it. Even though C# is a larger language than Swift and is getting larger. I tried to write a small project in Swift and I really have no intention on ever going back to Swift. It's not a designed language. It literally is a kitchen sink of quite poorly thought out features and "we couldn't be bothered to design a solution, let's just throw in this patch".
      - skohan 6y ago
        What specifically gives you that impression? I'm only asking because I find that Swift is more conceptually coherent than most other languages I have worked with. The impression I get of Swift is that it takes a bit more effort to get over the learning curve since it introduces some novel concepts (null handling, affine types, the protocol system) but mostly it makes a lot of sense and becomes very nice to work with after getting over the hump. C# seems easy to pick up by comparison because it's basically like a Java dialect and you just need to map the keywords etc.
        dmitriid 6y ago
        > What specifically gives you that impression? https://news.ycombinator.com/item?id=23520626 https://news.ycombinator.com/item?id=23520626 > since it introduces some novel concepts They are not terribly novel

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#.
  - dmitriid 6y ago
    I spent no effort learning C#. I just sat down and started writing it. Even though C# is a larger language than Swift and is getting larger. I tried to write a small project in Swift and I really have no intention on ever going back to Swift. It's not a designed language. It literally is a kitchen sink of quite poorly thought out features and "we couldn't be bothered to design a solution, let's just throw in this patch".
    - skohan 6y ago
      What specifically gives you that impression? I'm only asking because I find that Swift is more conceptually coherent than most other languages I have worked with. The impression I get of Swift is that it takes a bit more effort to get over the learning curve since it introduces some novel concepts (null handling, affine types, the protocol system) but mostly it makes a lot of sense and becomes very nice to work with after getting over the hump. C# seems easy to pick up by comparison because it's basically like a Java dialect and you just need to map the keywords etc.
      - dmitriid 6y ago
        > What specifically gives you that impression? https://news.ycombinator.com/item?id=23520626 https://news.ycombinator.com/item?id=23520626 > since it introduces some novel concepts They are not terribly novel