5 ms·

Compiler bugs really don't worry me - despite the name, this is is really an alpha release. However, I ran up against the lack of generic protocols myself today

Compiler bugs really don't worry me - despite the name, this is is really an alpha release. However, I ran up against the lack of generic protocols myself today (for those with access, there's an interesting debate at https://devforums.apple.com/thread/230611?tstart=0 https://devforums.apple.com/thread/230611?tstart=0). It seems like a deliberate design choice, but one I'm not really sure about. The primary vibe I'm getting from Swift is pragmatism. They had various red lines to follow: must be as fast as Objective C; must have a minimal to non-existent runtime (so AOT compilation all the way); mustn't have garbage collection, must interoperate with Objective C/normal C with ease; etc. This had led to a language which, despite being at version 0.1, has a fair few oddities and warts already. For example, the "almost but not quite immutable" arrays seem to be an artefact of absolutely wanting array performance to be equal to standard C. Typealiases vs parametric protocols seem to be a desire to have as much type information fixed as soon as possible. It seems that rather than design a language where they might not have solutions for their red lines up front, they've designed a language where they can provide them. Rather than make theoretically "better" choices the compiler can't deliver perfectly in V1, but can in V4 or 5, they've gone for "yeah, we can almost certainly ship that". Given that this is essentially Apple's private language, I assume they'll be quite aggressive about deprecating features and moving people onto the "better" solutions (high-kinded types, richer immutability etc) when they can deliver them whilst meeting the core goals. It's an interesting approach - most other languages are happy to take a few years to get going, whereas Swift seems to want to go from 0 to 60 in 4 months. It reminds me most of C# 1.0, but with harder restrictions on what they've been told to deliver. At the moment, it's interesting, and a big leap from Objective C. By V3, it might be "excellent".

danabramov 12y ago
>However, I ran up against the lack of generic protocols myself today (for those with access, there's an interesting debate at https://devforums.apple.com/thread/230611?tstart=0 https://devforums.apple.com/thread/230611?tstart=0). It seems like a deliberate design choice, but one I'm not really sure about. So did I! A few more related links if you're interested in this question: http://schani.wordpress.com/2014/06/11/associated-types-considered-weird/ http://schani.wordpress.com/2014/06/11/associated-types-cons... http://www.artima.com/weblogs/viewpost.jsp?thread=270195 http://www.artima.com/weblogs/viewpost.jsp?thread=270195 (this is about Scala, but Swift somewhat follows Scala with this design) https://groups.google.com/forum/#!topic/swift-language/3PtydRXR0ao https://groups.google.com/forum/#!topic/swift-language/3Ptyd...
- archgrove 12y ago
  Very interesting, thanks. I also ran up against another annoying bug/oversight/v0.1ism : You can't inherit from a generic class without becoming generic yourself. So, even if you fully instantiate your parent's type information, you have to be generic as well! For example: class Foo<T> { ... } class Bar : Foo<String> { ... } You'd expect Bar to be a non-generic type, but this throws a compiler error. You have to declare: class Foo<T> { ... } class Bar<String> : Foo<String> { ... } Which seems just odd. The best workaround I've found thus far is class Foo<T> { ... } class BarClass<String> : Foo<String> { ... } typealias Bar = BarClass<String> Bleh. I've filed a radar against this one - it seems like an annoying oversight, even for this early version.
  - jkrems 12y ago
    Well, derived classes are meant to be drop-in replacement for the base class. In that sense it totally makes sense that you can't have a non-generic child class of a generic base class. Otherwise it encourages design where classes are treated as method dumps.
    - bjeanes 12y ago
      Exactly what I was going to say. This seems like a good design decision, especially because the typealias hack offers a work around if you really need to.
    - barrkel 12y ago
      Don't mix up your polymorphism. The fact that an instance of A is assignment compatible with a location of type B does not imply that a class of type A is assignment compatible with a location of type class of B. This is not the case for languages like C#, Java, C++ etc. (despite those languages not having class types); if a subclass does not define all the constructors of its ancestor class, the subclass is not a "drop-in replacement". Delphi does have class value polymorphism that mirrors instance polymorphism, and it can be a source of confusion, not to mention type holes. For A inheriting from B, you can construct a value of type A using a constructor of B if you assign A to a location of type class of B; A's constructor won't run, and its assumptions and invariants won't necessarily hold. It's one of several problems that makes designing robust classes in Delphi awkward.
japhyr 12y ago
I have only a passing familiarity with Objective C. Why is one of the "red lines" having no garbage collection?
- CodeWithCoffee 12y ago
  Objective-C uses Automatic Reference Counting (Garbage Collection has been deprecated - and ARC works a lot better than the GC implementation), and as Swift had to uses Objective-C's memory model it must also use ARC.
- archgrove 12y ago
  Apple did add garbage collection to Objective C, but it only lasted a few years before being pulled. Two less important reasons are that it's hard to integrate with the otherwise trivial C(++) interop, and the frameworks just weren't designed for it. To me, the more important answers are deterministic destruction, and no GC pauses. All of Objective C is reference counted these days, with retain/releases inserted by the compiler (so all you have to do as a programmer is resolve cyclic references with weakness). Thus, you know exactly when an object will die, and have its dealloc method called. You're also sure you'll never end up in a situation where memory pressure causes system hitching due to GC. Given that a key platform for Objective C is iOS (low memory, "low" CPU), and that Apple's trademark tends to be fluid UI, avoiding these problems is really helpful.
  - mikeash 12y ago
    To be fair, reference counting isn't strictly deterministic either. The moment you mix in multithreading or call out to code you don't control and whose refcounting behavior could change over time, you can no longer know when an object will die. As for memory pressure, reference counting does generally behave better, but in some situations you can end up doing much worse. If you manage to generate a lot of autoreleased objects (harder to do these days with ARC, but still possible) then you can end up getting your process terminated due to the memory pressure of should-be-dead-but-not-yet-freed objects. I think that the C interop problems are the real killer. The other problems with garbage collection can potentially be solved, but as long as C is in the picture, you're doomed to a sort of halfway land where none of the good GC techniques are available to you.
drivingmenuts 12y ago
This makes sense - Apple's philosophy is "Everything Apple" and so they have a vested interest in designing a language that gets things moving on their platform, rather than being the best language it can be right now. If, and this is a big if, Apple is actually interested in Swift in the long term, then they will open up the language to community development so that these sorts of things can be added by the community. My suspicion is, though, that Swift will be improved by Apple alone and that it will be pragmatically discarded when the time is appropriate. Which doesn't mean it won't have a long life, just an undignified exit.
- lxcid 12y ago
  This is kinda misunderstanding Apple approach to introducing technology. Apple seldom introduce a technology as intermediary solution or discard them soon after. (the last time this happen that I could remember was GC in Objective-C which is replaced by ARC) They could double down on it even if it has its algorithmic flaws, and they will attempts to fix those flaws. One of recent technologies that fall into this category is auto layout. (The performance of auto layout in iOS 7 for slightly more complex table view cells is pretty bad) Apple main interests is always Apple, which makes sense because they are a for profit company. Just as Rails is always Basecamp. Apple technology have a fast paced development because Apple dog food their technology. WebKit in Safari, LLVM in Xcode. They invested huge in these area. That doesn't mean that they don't open up. both technologies I mentioned are open source and have huge impact to the community as a whole. E.g. RubyMotion make use of LLVM to allows ruby to be compiled to both iOS and Android. People like to think Apple is a closed company (as marketed by its competitors) but people who know the company well know that is far from true. They might not be the most open of company but they had open source technologies that are awesome in their own right. LLVM is just one of them. Open sourced and won the ACM award. That by itself is a achievement hard to beat.
  - terminus 12y ago
    > They might not be the most open of company but they had open source technologies that are awesome in their own right. LLVM is just one of them. Open sourced and won the ACM award. That by itself is a achievement hard to beat. I don't understand how a community project became "Apple's achievement." Apple did not open source LLVM. LLVM was an open source project (since 2000), which Apple used and open sourced their contributions to on the way.
nnq 12y ago
> must be as fast as Objective C; must have a minimal to non-existent runtime (so AOT compilation all the way); mustn't have garbage collection, must interoperate with Objective C/normal C with ease; etc. This sounds and awful lot like what C++11/14 would bring, with a few platform specific extensions... but then again, no vendor, and especially not Apple, likes the thought of working with a language that's really trying to be cross-platform and a language that "rewards smart programmers" ( http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Keynote http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Key... ), as opposed to being easy-to-teach or idiot-proof...

danabramov 12y ago

>However, I ran up against the lack of generic protocols myself today (for those with access, there's an interesting debate at https://devforums.apple.com/thread/230611?tstart=0 https://devforums.apple.com/thread/230611?tstart=0). It seems like a deliberate design choice, but one I'm not really sure about. So did I! A few more related links if you're interested in this question: http://schani.wordpress.com/2014/06/11/associated-types-considered-weird/ http://schani.wordpress.com/2014/06/11/associated-types-cons... http://www.artima.com/weblogs/viewpost.jsp?thread=270195 http://www.artima.com/weblogs/viewpost.jsp?thread=270195 (this is about Scala, but Swift somewhat follows Scala with this design) https://groups.google.com/forum/#!topic/swift-language/3PtydRXR0ao https://groups.google.com/forum/#!topic/swift-language/3Ptyd...

archgrove 12y ago
Very interesting, thanks. I also ran up against another annoying bug/oversight/v0.1ism : You can't inherit from a generic class without becoming generic yourself. So, even if you fully instantiate your parent's type information, you have to be generic as well! For example: class Foo<T> { ... } class Bar : Foo<String> { ... } You'd expect Bar to be a non-generic type, but this throws a compiler error. You have to declare: class Foo<T> { ... } class Bar<String> : Foo<String> { ... } Which seems just odd. The best workaround I've found thus far is class Foo<T> { ... } class BarClass<String> : Foo<String> { ... } typealias Bar = BarClass<String> Bleh. I've filed a radar against this one - it seems like an annoying oversight, even for this early version.
- jkrems 12y ago
  Well, derived classes are meant to be drop-in replacement for the base class. In that sense it totally makes sense that you can't have a non-generic child class of a generic base class. Otherwise it encourages design where classes are treated as method dumps.
  - bjeanes 12y ago
    Exactly what I was going to say. This seems like a good design decision, especially because the typealias hack offers a work around if you really need to.
  - barrkel 12y ago
    Don't mix up your polymorphism. The fact that an instance of A is assignment compatible with a location of type B does not imply that a class of type A is assignment compatible with a location of type class of B. This is not the case for languages like C#, Java, C++ etc. (despite those languages not having class types); if a subclass does not define all the constructors of its ancestor class, the subclass is not a "drop-in replacement". Delphi does have class value polymorphism that mirrors instance polymorphism, and it can be a source of confusion, not to mention type holes. For A inheriting from B, you can construct a value of type A using a constructor of B if you assign A to a location of type class of B; A's constructor won't run, and its assumptions and invariants won't necessarily hold. It's one of several problems that makes designing robust classes in Delphi awkward.

japhyr 12y ago

I have only a passing familiarity with Objective C. Why is one of the "red lines" having no garbage collection?

CodeWithCoffee 12y ago
Objective-C uses Automatic Reference Counting (Garbage Collection has been deprecated - and ARC works a lot better than the GC implementation), and as Swift had to uses Objective-C's memory model it must also use ARC.
archgrove 12y ago
Apple did add garbage collection to Objective C, but it only lasted a few years before being pulled. Two less important reasons are that it's hard to integrate with the otherwise trivial C(++) interop, and the frameworks just weren't designed for it. To me, the more important answers are deterministic destruction, and no GC pauses. All of Objective C is reference counted these days, with retain/releases inserted by the compiler (so all you have to do as a programmer is resolve cyclic references with weakness). Thus, you know exactly when an object will die, and have its dealloc method called. You're also sure you'll never end up in a situation where memory pressure causes system hitching due to GC. Given that a key platform for Objective C is iOS (low memory, "low" CPU), and that Apple's trademark tends to be fluid UI, avoiding these problems is really helpful.
- mikeash 12y ago
  To be fair, reference counting isn't strictly deterministic either. The moment you mix in multithreading or call out to code you don't control and whose refcounting behavior could change over time, you can no longer know when an object will die. As for memory pressure, reference counting does generally behave better, but in some situations you can end up doing much worse. If you manage to generate a lot of autoreleased objects (harder to do these days with ARC, but still possible) then you can end up getting your process terminated due to the memory pressure of should-be-dead-but-not-yet-freed objects. I think that the C interop problems are the real killer. The other problems with garbage collection can potentially be solved, but as long as C is in the picture, you're doomed to a sort of halfway land where none of the good GC techniques are available to you.

drivingmenuts 12y ago

This makes sense - Apple's philosophy is "Everything Apple" and so they have a vested interest in designing a language that gets things moving on their platform, rather than being the best language it can be right now. If, and this is a big if, Apple is actually interested in Swift in the long term, then they will open up the language to community development so that these sorts of things can be added by the community. My suspicion is, though, that Swift will be improved by Apple alone and that it will be pragmatically discarded when the time is appropriate. Which doesn't mean it won't have a long life, just an undignified exit.

lxcid 12y ago
This is kinda misunderstanding Apple approach to introducing technology. Apple seldom introduce a technology as intermediary solution or discard them soon after. (the last time this happen that I could remember was GC in Objective-C which is replaced by ARC) They could double down on it even if it has its algorithmic flaws, and they will attempts to fix those flaws. One of recent technologies that fall into this category is auto layout. (The performance of auto layout in iOS 7 for slightly more complex table view cells is pretty bad) Apple main interests is always Apple, which makes sense because they are a for profit company. Just as Rails is always Basecamp. Apple technology have a fast paced development because Apple dog food their technology. WebKit in Safari, LLVM in Xcode. They invested huge in these area. That doesn't mean that they don't open up. both technologies I mentioned are open source and have huge impact to the community as a whole. E.g. RubyMotion make use of LLVM to allows ruby to be compiled to both iOS and Android. People like to think Apple is a closed company (as marketed by its competitors) but people who know the company well know that is far from true. They might not be the most open of company but they had open source technologies that are awesome in their own right. LLVM is just one of them. Open sourced and won the ACM award. That by itself is a achievement hard to beat.
- terminus 12y ago
  > They might not be the most open of company but they had open source technologies that are awesome in their own right. LLVM is just one of them. Open sourced and won the ACM award. That by itself is a achievement hard to beat. I don't understand how a community project became "Apple's achievement." Apple did not open source LLVM. LLVM was an open source project (since 2000), which Apple used and open sourced their contributions to on the way.

nnq 12y ago

> must be as fast as Objective C; must have a minimal to non-existent runtime (so AOT compilation all the way); mustn't have garbage collection, must interoperate with Objective C/normal C with ease; etc. This sounds and awful lot like what C++11/14 would bring, with a few platform specific extensions... but then again, no vendor, and especially not Apple, likes the thought of working with a language that's really trying to be cross-platform and a language that "rewards smart programmers" ( http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Keynote http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Key... ), as opposed to being easy-to-teach or idiot-proof...