7 ms·

Swift impressions

78 points by gmac 12y ago

gmac 12y ago
I'm with him on the arcane rules about Array copying — IIRC, when you modify them such as to change the length but not otherwise.
- Someone 12y ago
  I do not understand that, either. Also, I find it weird that dictionaries are value types. If I started programming in Swift, I think I would soon have a generic class named 'Dict' that has a single field storing a Dictionary and the same interface as the Dictionary struct. Does anybody know what is the reason they chose those non-standard behavior for the standard containers?
  - lohankin 12y ago
    My guess is that they want you to declare map/array arguments as "inout" to be able to add/change things so that the changes are visible by caller. It might not be a bad idea after all.
    - Someone 12y ago
      That makes some, but not much sense to me. Firstly, that is not what I read in the book "The Swift Programming Language": "Whenever you assign a Dictionary instance to a constant or variable, or pass a Dictionary instance as an argument to a function or method call, the dictionary is copied at the point that the assignment or call takes place." Even if I assume that that is an error (they didn't think of inout arguments when writing that), the behavior still doesn't make much sense to me. Say that I want to do a few things with someObject.someField.someDict. In most languages, I would introduce a helper variable: var items = someObject.someField.someDict and do items[42] = 346; items[423] = 356; etc. That won't work, as it clones the dictionary (shallowly). I find it is just too easy to accidentally clone arrays or dictionaries in Swift.
      - wooster 12y ago
        The idea is you shouldn't be modifying someObject.someField.someDict in the first place since you don't own the dict, someField does.
        Someone 12y ago
        That's true in the majority of cases. However, the code could be written as it is for performance reasons. If someObject is a field in the current object, that isn't that bad, especially if it also is an instance of a nested class. Also, weirdly, that isn't something the language forbids. It doesn't even make it possible for library writers to prevent it. I still think we will see some language changes before the official release here in this area because naive users will run into too many weird issues with the current behavior. For example, if the goal is to have normal function arguments immutable, I think it would be more natural to forbid functions from calling mutating methods on their arguments, unless they are specified as inout. On the other hand, good compiler warnings might be enough for preventing programmers from accidentally copying containers.
  - m_mueller 12y ago
    Isn't that such that you can declare a dictionary or array as constant by using 'let' in the declaration? I think the designers wanted to avoid complicated annotations for constant the way it works in C++. Being able to use 'let' also seems to make collections available for matching in case statements. I recommend watching this[1] tutorial - the way switch/case works in Swift was really impressive to me. [1] http://fitacular.com/blog/swift/2014/06/08/apple-ios-tutorial-swift/ http://fitacular.com/blog/swift/2014/06/08/apple-ios-tutoria...
- josephlord 12y ago
  Note also the fact that constant arrays (declared with let) are only constant in length. I've made some speculation and a suggestion here: http://blog.human-friendly.com/swift-arrays-too-swift-and-flexible-for-our-good http://blog.human-friendly.com/swift-arrays-too-swift-and-fl...
mercurial 12y ago
I'd be curious to get a summary of what Swift has that is not a mix of traditional OO and ML-family features.
- tomp 12y ago
  Well, the problem with C++/Java and the ML language families is that they are quite incompatible, so it's not really trivial to mix them. Many languages have tried, most recent languages really. Rust is C with ADTs or ML without garbage collection (not yet sure how closures will turn out), Scala is Java with first-class functions and ADTs, Java and C# are absorbing more and more features from ML, ... Swift is just another attempt to mix the two, quite a successful one IMO. They kept some warts, probably to maintain binary compatibility with Obj-C, but otherwise I think it's a huge improvement over Java-style languages. One particular pain point between Java-style and ML-style languages are generics; Java and C# have a common object protocol and thus allow a top type, Object, and run-time type information. So, they must decide whether generics/type parameters are only relevant at compile-time (Java) or are kept at run-time (C#). ML avoids this issue by not having any runtime type information (and no type-testing construct). I haven't yet found where Swift stands, but it's a hard problem to solve.
  - austinz 12y ago
    Swift doesn't have a designated base class like Java, C#, or Objective-C's NSObject. It seems, though, that there are a bunch of interop considerations which means that you might need your Swift classes to inherit from NSObject for them to work properly with Cocoa code. Swift also doesn't perform type erasure. You can do something like the following, as I believe is possible in C#: struct SquareMatrix<T> { let dimension: Int var backingArray: Array<T> init(dimension d: Int, initialValue: T) { dimension = d backingArray = T[](count:d*d, repeatedValue:initialValue) } subscript(row: Int, col: Int) -> T { get { return backingArray[row*dimension + col] } set { backingArray[row*dimension + col] = newValue } } }
    - mercurial 12y ago
spicyj 12y ago
> Override functions must use the `override` keyword. Now when you rename the superclass's function, all the subclass functions fail to compile because they're not overriding anything. Why did no one think of this before? As I understand it, Java has a similar `@Override` annotation: http://stackoverflow.com/q/94361/49485 http://stackoverflow.com/q/94361/49485
- derekerdmann 12y ago
  C# also includes compiler checks to make sure you're explicitly overriding methods correctly: http://msdn.microsoft.com/en-us/library/ebca9ah3.aspx http://msdn.microsoft.com/en-us/library/ebca9ah3.aspx
  - skwirl 12y ago
    C# takes it even further by not allowing you to override methods unless they were marked as overridable in the base class with the "virtual" keyword.
- deleted 12y ago
  [deleted]
- evmar 12y ago
  C++ also, though you need to wrap it in a macro to work on older compilers. https://code.google.com/p/chromium/codesearch#chromium/src/base/compiler_specific.h&l=136 https://code.google.com/p/chromium/codesearch#chromium/src/b...
  - deleted 12y ago
    [deleted]
- pjmlp 12y ago
  Eiffel, Object Pascal, Modula-3, Component Pascal and many others do as well. I guess the author is not well versed in programming languages history.
  - 12y ago
cromwellian 12y ago
First of all, "no garbage collection" Technically, referencing counting is garbage collection, it's automatic memory management by definition. Is ARC really a win over non-refcounted GC + escape analysis? Full manual control over stack vs heap allocations and lifetime, I get, especially for games. But reference counting is not deterministic, and can also generate pauses. @Override has been in Java since Java 5.
- lxcid 12y ago
  ARC are less likely to get paused as memory release are amortised rather than gather and swept. Also, LLVM static analyze is so good at figuring out your code path that it could effectively retain and release your memory for you. Cyclic reference is its only flaw but its something that can easily solved through programmer awareness.
  - rayiner 12y ago
    Maybe not so much: https://news.ycombinator.com/item?id=7849631 https://news.ycombinator.com/item?id=7849631
  - deleted 12y ago
    [deleted]
  - tormeh 12y ago
    Can't cyclic reference be fixed by a garbage compiler occasionally cleaning up those things? I think that's how Python does it, not that Python is a beacon of performance, but it's possible.
  - cromwellian 12y ago
    What LLVM static analysis can be done to figure out the lifecycle of objects also applies to other GC algorithms. ARC may be less likely to get memory paused on release, but ARC doesn't compact free memory, and therefore fragmentation can cause object allocations (malloc) to become more expensive, possibly leading to pauses. If you use non-copying GC that doesn't compact (ARC doesn't compact), then there are low pause GC algorithms out there that give pretty good bounds (e.g. 5ms pause). I'd like to see actual benchmarks of both ARC and say, mark-and-sweep on a mobile device rather than speculation and opinion, and both benchmarks must get the same static compilation treatment. That is, if escape analysis tells you that the lifetime of the object is bounded by the current stack frame, then allocate it on the stack, and don't penalize the non-reference-counted GC by allocating 100% of everything on the heap.
lxcid 12y ago
Swift seems to be a very pragmatic language. It borrow and learn heavily from other languages, but it doesn't try to be promise anything big. It just introduce opinionated defaults which is safe and tends to be at least 80% of the implementor's intend, while providing alternative for the 20%. An example is the switch case fall through behaviour of C. In Swift, by default, switch case no longer fall through, but if you need that behaviour, you can always add fallthrough keyword at the end. When you think about the above behaviour, it seems so much more natural, and wonder why we have been keeping ourselves bitten by this C language construct and developing muscle memory to prevent it by having break, sometimes with a scope (All cases in a switch scare the same scope within C switch, if I don't remember wrongly). Part of the switch example is solved in other languages (default intends and scoping), of course. But the subtlety of the fallthrough keyword gave me a strong impression. It felt that it should always be a opt-in all these while, rather than an opt-out as it have always been. With my limited command of english, I feels that I would do it little justice to the language trying to explains some of its concepts like optionals & mutability hints. Some of these concepts only modify the existing solution only so slightly, but meaningful enough to be impactful. It also doesn't take a stance in the OO and functional debates. It is both OO and functional. Staying as pragmatic as possible. Finally, Swift is like a wolf hiding under the sheep's skin. Its a very very strongly typed language. It is very specific about it type. But half the time, you can ignore the type and write it like python or ruby. The magic was type inference, its kinda weird but I like that. You can almost feel that Chris Lattner might have felt he is reaching the point of diminishing return while optimising LLVM for Objective-C. after all, this is a very old language. He done a great job all these while with LLVM but sometimes, the problem is something deeper. Swift is kinda like Objective-C 3.0 without the backward compatibility. (P.S. Objective-C is my favourite language before Swift) If programming language is a sword, Swift is just another sword, albeit one that's very sharp.
- xkarga00 12y ago
  Go already has the same switch behavior (plus the fallthrough keyword) and is very specific about its types while having type inference.
  - 12y ago
seiji 12y ago
Anybody interested in an ebook about using all of Swift's strict typing features for better app development? I may be in the process of writing one of those. It may be up to 100 pages so far with only a chapter or two remaining. It may be available for release in a day or two.
- uptown 12y ago
  I may be. Maybe.
- Twisol 12y ago
  Definitely. I think that would be fantastic.
deleted 12y ago
[deleted]
- altyus 12y ago
  That is completely irrelevant to this articles point of illustrating Objective-C bugs that are fixed by Swift. Nowhere did it claim that no other language had solutions for @Override
foobarraboof 12y ago
wow! almost like C# from, what, 10 years ago?
- sitharus 12y ago
  Except with pattern matching, built-in immutability, extensible classes, curried function and tagged unions. More like F# 2.0 in feature set.
flym4n 12y ago
> At its core, the language is designed to eliminate bugs, but not in the academic way that, say, Haskell eliminates bugs by preventing normal people from writing code in it Shots fired
klickverbot 12y ago
D (http://dlang.org http://dlang.org) has had mandatory override for a long time.
- deleted 12y ago
  [deleted]
  - danellis 12y ago
    The author is clearly claiming that feature is unique to Swift: "Why did no one think of this before?"
    - lostmsu 12y ago
      The author is short-sighted. He doesn't know any descent modern OO language, but tries to review Swift. Except ARC and syntax differences, it is more like a subset of F# or Scala
      - danellis 12y ago
        I don't know F#, but Scala certainly addresses all three of his issues: 1) override (also in C#, IIRC) 2) The Option type (which, being a monad, also has compositional ability null/nil doesn't have) 3) Case classes
        lostmsu 12y ago
        That's what I said. Swift is a subset of F#/Scala.

78 points by gmac 12y ago

gmac 12y ago

I'm with him on the arcane rules about Array copying — IIRC, when you modify them such as to change the length but not otherwise.

Someone 12y ago
I do not understand that, either. Also, I find it weird that dictionaries are value types. If I started programming in Swift, I think I would soon have a generic class named 'Dict' that has a single field storing a Dictionary and the same interface as the Dictionary struct. Does anybody know what is the reason they chose those non-standard behavior for the standard containers?
- lohankin 12y ago
  My guess is that they want you to declare map/array arguments as "inout" to be able to add/change things so that the changes are visible by caller. It might not be a bad idea after all.
  - Someone 12y ago
    That makes some, but not much sense to me. Firstly, that is not what I read in the book "The Swift Programming Language": "Whenever you assign a Dictionary instance to a constant or variable, or pass a Dictionary instance as an argument to a function or method call, the dictionary is copied at the point that the assignment or call takes place." Even if I assume that that is an error (they didn't think of inout arguments when writing that), the behavior still doesn't make much sense to me. Say that I want to do a few things with someObject.someField.someDict. In most languages, I would introduce a helper variable: var items = someObject.someField.someDict and do items[42] = 346; items[423] = 356; etc. That won't work, as it clones the dictionary (shallowly). I find it is just too easy to accidentally clone arrays or dictionaries in Swift.
    - wooster 12y ago
      The idea is you shouldn't be modifying someObject.someField.someDict in the first place since you don't own the dict, someField does.
      - Someone 12y ago
        That's true in the majority of cases. However, the code could be written as it is for performance reasons. If someObject is a field in the current object, that isn't that bad, especially if it also is an instance of a nested class. Also, weirdly, that isn't something the language forbids. It doesn't even make it possible for library writers to prevent it. I still think we will see some language changes before the official release here in this area because naive users will run into too many weird issues with the current behavior. For example, if the goal is to have normal function arguments immutable, I think it would be more natural to forbid functions from calling mutating methods on their arguments, unless they are specified as inout. On the other hand, good compiler warnings might be enough for preventing programmers from accidentally copying containers.
- m_mueller 12y ago
  Isn't that such that you can declare a dictionary or array as constant by using 'let' in the declaration? I think the designers wanted to avoid complicated annotations for constant the way it works in C++. Being able to use 'let' also seems to make collections available for matching in case statements. I recommend watching this[1] tutorial - the way switch/case works in Swift was really impressive to me. [1] http://fitacular.com/blog/swift/2014/06/08/apple-ios-tutorial-swift/ http://fitacular.com/blog/swift/2014/06/08/apple-ios-tutoria...
josephlord 12y ago
Note also the fact that constant arrays (declared with let) are only constant in length. I've made some speculation and a suggestion here: http://blog.human-friendly.com/swift-arrays-too-swift-and-flexible-for-our-good http://blog.human-friendly.com/swift-arrays-too-swift-and-fl...

mercurial 12y ago

I'd be curious to get a summary of what Swift has that is not a mix of traditional OO and ML-family features.

tomp 12y ago
Well, the problem with C++/Java and the ML language families is that they are quite incompatible, so it's not really trivial to mix them. Many languages have tried, most recent languages really. Rust is C with ADTs or ML without garbage collection (not yet sure how closures will turn out), Scala is Java with first-class functions and ADTs, Java and C# are absorbing more and more features from ML, ... Swift is just another attempt to mix the two, quite a successful one IMO. They kept some warts, probably to maintain binary compatibility with Obj-C, but otherwise I think it's a huge improvement over Java-style languages. One particular pain point between Java-style and ML-style languages are generics; Java and C# have a common object protocol and thus allow a top type, Object, and run-time type information. So, they must decide whether generics/type parameters are only relevant at compile-time (Java) or are kept at run-time (C#). ML avoids this issue by not having any runtime type information (and no type-testing construct). I haven't yet found where Swift stands, but it's a hard problem to solve.
- austinz 12y ago
  Swift doesn't have a designated base class like Java, C#, or Objective-C's NSObject. It seems, though, that there are a bunch of interop considerations which means that you might need your Swift classes to inherit from NSObject for them to work properly with Cocoa code. Swift also doesn't perform type erasure. You can do something like the following, as I believe is possible in C#: struct SquareMatrix<T> { let dimension: Int var backingArray: Array<T> init(dimension d: Int, initialValue: T) { dimension = d backingArray = T[](count:d*d, repeatedValue:initialValue) } subscript(row: Int, col: Int) -> T { get { return backingArray[row*dimension + col] } set { backingArray[row*dimension + col] = newValue } } }
  - mercurial 12y ago

spicyj 12y ago

> Override functions must use the `override` keyword. Now when you rename the superclass's function, all the subclass functions fail to compile because they're not overriding anything. Why did no one think of this before? As I understand it, Java has a similar `@Override` annotation: http://stackoverflow.com/q/94361/49485 http://stackoverflow.com/q/94361/49485

derekerdmann 12y ago
C# also includes compiler checks to make sure you're explicitly overriding methods correctly: http://msdn.microsoft.com/en-us/library/ebca9ah3.aspx http://msdn.microsoft.com/en-us/library/ebca9ah3.aspx
- skwirl 12y ago
  C# takes it even further by not allowing you to override methods unless they were marked as overridable in the base class with the "virtual" keyword.
deleted 12y ago
[deleted]
evmar 12y ago
C++ also, though you need to wrap it in a macro to work on older compilers. https://code.google.com/p/chromium/codesearch#chromium/src/base/compiler_specific.h&l=136 https://code.google.com/p/chromium/codesearch#chromium/src/b...
- deleted 12y ago
  [deleted]
pjmlp 12y ago
Eiffel, Object Pascal, Modula-3, Component Pascal and many others do as well. I guess the author is not well versed in programming languages history.
- 12y ago

cromwellian 12y ago

First of all, "no garbage collection" Technically, referencing counting is garbage collection, it's automatic memory management by definition. Is ARC really a win over non-refcounted GC + escape analysis? Full manual control over stack vs heap allocations and lifetime, I get, especially for games. But reference counting is not deterministic, and can also generate pauses. @Override has been in Java since Java 5.

lxcid 12y ago
ARC are less likely to get paused as memory release are amortised rather than gather and swept. Also, LLVM static analyze is so good at figuring out your code path that it could effectively retain and release your memory for you. Cyclic reference is its only flaw but its something that can easily solved through programmer awareness.
- rayiner 12y ago
  Maybe not so much: https://news.ycombinator.com/item?id=7849631 https://news.ycombinator.com/item?id=7849631
- deleted 12y ago
  [deleted]
- tormeh 12y ago
  Can't cyclic reference be fixed by a garbage compiler occasionally cleaning up those things? I think that's how Python does it, not that Python is a beacon of performance, but it's possible.
- cromwellian 12y ago
  What LLVM static analysis can be done to figure out the lifecycle of objects also applies to other GC algorithms. ARC may be less likely to get memory paused on release, but ARC doesn't compact free memory, and therefore fragmentation can cause object allocations (malloc) to become more expensive, possibly leading to pauses. If you use non-copying GC that doesn't compact (ARC doesn't compact), then there are low pause GC algorithms out there that give pretty good bounds (e.g. 5ms pause). I'd like to see actual benchmarks of both ARC and say, mark-and-sweep on a mobile device rather than speculation and opinion, and both benchmarks must get the same static compilation treatment. That is, if escape analysis tells you that the lifetime of the object is bounded by the current stack frame, then allocate it on the stack, and don't penalize the non-reference-counted GC by allocating 100% of everything on the heap.

lxcid 12y ago

Swift seems to be a very pragmatic language. It borrow and learn heavily from other languages, but it doesn't try to be promise anything big. It just introduce opinionated defaults which is safe and tends to be at least 80% of the implementor's intend, while providing alternative for the 20%. An example is the switch case fall through behaviour of C. In Swift, by default, switch case no longer fall through, but if you need that behaviour, you can always add fallthrough keyword at the end. When you think about the above behaviour, it seems so much more natural, and wonder why we have been keeping ourselves bitten by this C language construct and developing muscle memory to prevent it by having break, sometimes with a scope (All cases in a switch scare the same scope within C switch, if I don't remember wrongly). Part of the switch example is solved in other languages (default intends and scoping), of course. But the subtlety of the fallthrough keyword gave me a strong impression. It felt that it should always be a opt-in all these while, rather than an opt-out as it have always been. With my limited command of english, I feels that I would do it little justice to the language trying to explains some of its concepts like optionals & mutability hints. Some of these concepts only modify the existing solution only so slightly, but meaningful enough to be impactful. It also doesn't take a stance in the OO and functional debates. It is both OO and functional. Staying as pragmatic as possible. Finally, Swift is like a wolf hiding under the sheep's skin. Its a very very strongly typed language. It is very specific about it type. But half the time, you can ignore the type and write it like python or ruby. The magic was type inference, its kinda weird but I like that. You can almost feel that Chris Lattner might have felt he is reaching the point of diminishing return while optimising LLVM for Objective-C. after all, this is a very old language. He done a great job all these while with LLVM but sometimes, the problem is something deeper. Swift is kinda like Objective-C 3.0 without the backward compatibility. (P.S. Objective-C is my favourite language before Swift) If programming language is a sword, Swift is just another sword, albeit one that's very sharp.

xkarga00 12y ago
Go already has the same switch behavior (plus the fallthrough keyword) and is very specific about its types while having type inference.
- 12y ago

seiji 12y ago

Anybody interested in an ebook about using all of Swift's strict typing features for better app development? I may be in the process of writing one of those. It may be up to 100 pages so far with only a chapter or two remaining. It may be available for release in a day or two.

uptown 12y ago
I may be. Maybe.
Twisol 12y ago
Definitely. I think that would be fantastic.

deleted 12y ago

[deleted]

altyus 12y ago
That is completely irrelevant to this articles point of illustrating Objective-C bugs that are fixed by Swift. Nowhere did it claim that no other language had solutions for @Override

foobarraboof 12y ago

wow! almost like C# from, what, 10 years ago?

sitharus 12y ago
Except with pattern matching, built-in immutability, extensible classes, curried function and tagged unions. More like F# 2.0 in feature set.

flym4n 12y ago

> At its core, the language is designed to eliminate bugs, but not in the academic way that, say, Haskell eliminates bugs by preventing normal people from writing code in it Shots fired

klickverbot 12y ago

D (http://dlang.org http://dlang.org) has had mandatory override for a long time.

deleted 12y ago
[deleted]
- danellis 12y ago
  The author is clearly claiming that feature is unique to Swift: "Why did no one think of this before?"
  - lostmsu 12y ago
    The author is short-sighted. He doesn't know any descent modern OO language, but tries to review Swift. Except ARC and syntax differences, it is more like a subset of F# or Scala
    - danellis 12y ago
      I don't know F#, but Scala certainly addresses all three of his issues: 1) override (also in C#, IIRC) 2) The Option type (which, being a monad, also has compositional ability null/nil doesn't have) 3) Case classes
      - lostmsu 12y ago
        That's what I said. Swift is a subset of F#/Scala.