14 ms·

Smashing Swift

281 points by afthonos 12y ago

eridius 12y ago
FWIW. map() already exists. It's a global function, rather than being a protocol method, and it uses overloading. So you can still define functions merely by defining a new overload for map() that operates on your type.
- eridius 12y ago
  Sigh, I typed "functors", not "functions", which should make a bit more sense. Autocorrect changed that without me noticing.
gfosco 12y ago
Since Bolts/BFTask was mentioned, I'd like to point out that you can use the Bolts-iOS library in Swift. I added a pull request with the code examples in Swift here: https://github.com/BoltsFramework/Bolts-iOS/pull/37/files https://github.com/BoltsFramework/Bolts-iOS/pull/37/files
noobermin 12y ago
Just to point out, the last two sound like it's due to the current implementation (compiler) being new, so it isn't so upsetting at all. Now, not supporting functors is odd, though.
- afthonos 12y ago
  Yeah, that's why I said the crashes gave me hope. It seems they are trying to support those use cases, but haven't worked out the kinks. I'm totally fine with that.
- pohl 12y ago
  Why is it odd? Is there a historical precedent for some other language exposing higher kinded types this early in the lifecycle? (Prior to 1.0, that is?) Ωmega, maybe? Is that what we're expecting of the new "normal" already?
  - sparkie 12y ago
    It's not odd that Haskell didn't have them in 1.0, because they were not conceptualized until '93[1] after the Haskell report has been published in '90. They made it into the Haskell report 1.3 ('96)[2]. We should not be comparing the development of languages now to 20 years ago - there is an enormous amount we have learned, and these insights should be fundamental considerations when designing a new language. You can't just "tack" things onto an existing language and expect it to be elegant - tacking on leads to huge languages like C++. And yes, we should expect it as "normal" for new languages, because it is what people have come to expect to have available - although some implementations leave a lot to be desired. If we consider how C# implements Functors for example, we see that it requires special language support, where the compiler essentially pattern matches over your code, looking for a method named "Select", with a specific signature taking a generic type and a func. This implementation completely misses the point that Functors themselves, while useful, are not special - they are a specialization of a more general concept we have - typeclasses and higher-kinded polymorphism. C# also adds the ability to create Monads, Foldable, Comonads etc, using similar patterns - but you can't create your own typeclasses, and are left to the language designers to add a desired feature. The decision to add them onto C# like this was made not without knowledge of this, but out of consideration of working with the existing language, which was designed without their consideration, hence, why they're a pretty ugly design compared to the simplicity of Haskell's implementation. [1]:http://www.cs.tufts.edu/comp/150GIT/archive/mark-jones/fpca93.pdf http://www.cs.tufts.edu/comp/150GIT/archive/mark-jones/fpca9... [2]:http://research.microsoft.com/en-us/um/people/simonpj/papers/history-of-haskell/history.pdf http://research.microsoft.com/en-us/um/people/simonpj/papers...
    - pohl 12y ago
      Haskell and Scala both seem to have survived adding it later. Rust won't have it by 1.0 either, and this never seems to come up in threads about Rust. I agree it will be a nice feature, if/when it comes. I just think Swift is being held to a higher standard because, well, Apple. By the way, thank you for the timeline for Haskell. That's exactly what I was wanting to know.
      - 12y ago
stefantalpalaru 12y ago
> I love what the compiler crashes let me hope it will do These rose-colored glasses are getting ridiculous.
- deleted 12y ago
  [deleted]
- andybak 12y ago
  By my reading the author made that statement, not naively, but with full awareness of it's slightly ridiculous nature. I think that whooshing sound was their joke going right over your head.
  - afthonos 12y ago
    Author here. To be fully honest, it's somewhere between the two. Yes, I'm aware of the irony of the statement. But what I failed to make clear in the post is that the code in the last two examples passes the type checker. Where it fails is at the intermediate representation stage. So the grammar of the language supports the constructs but the backend hasn't caught up yet. It's possible, of course, that Apple will modify the grammar to make these use cases impossible. But I would be very surprised. I can't blame anyone for accusing me of rose-tinted glasses until we know for sure, though.
- rsynnott 12y ago
  An early beta compiler crashes! Oh, noes, Apple is doomed! I think the point here is that if the compiler crashes, that implies that it is trying to do the thing, as opposed to saying "No, filthy programmer, I will not permit you to do that thing."
dirtyaura 12y ago
I've had very similar experience: I try to port non-trivial, but still rather simple functional code, for example containing a couple of nested closures, and the compiler crashes. And it seems that the Xcode playground, the command line compiler and REPL all behave a bit differently. In one case playground works, but REPL crashes, in another, compiler works, REPL has trouble of figuring out types. I have absolutely no experience on implementing compilers, but for a layman these inconsistencies seems very odd.
- danabramov 12y ago
  Microsoft's work on C# compiler (Roslyn) is amazing: they offer compiler-as-a-library so the IDE, plugins and debugger use the same backend as the compiler itself. I wish at some point Apple could adopt a similar approach.
  - pohl 12y ago
    That's basically what drove the design of clang. No doubt the approach with swift will be similar.
  - deleted 12y ago
    [deleted]
  - coldtea 12y ago
    Hmm, Apple went there before Roslyn with Clang/LLVM (whose creator is the designer of Swift and works for Apple). The idea behind LLVM was to have the various compiler stages and tooling be re-usable and plugin like, unlike the monolithic design GCC had. And Apple already uses the came "compiler-as-a-library" approach, even for Objective-C, to implement: the compiler, the syntax highlight, AST-based auto-completion, debugging and error fix suggestions and other stuff. I'm pretty sure that the case with Swift is the same. It's just that it's not stable yet, so you can get crashes at various stages of all those pipelines.
    - 0x09 12y ago
      >The idea behind LLVM was to have the various compiler stages and tooling be re-usable and plugin like, unlike the monolithic design GCC had. More specifically, the idea behind LLVM was "life-long program compilation and optimization" in stages at translation time, link time, install time, and runtime. The natural way to realize this was modular components at different levels working around a good serializable IR. If your goal is a traditional once-and-done AOT compiler, you might be forgiven for architecting something more heavily coupled and interdependent like GCC, whose IR was an afterthought (by 15 years.) LLVM's focus has shifted somewhat, but those original designs created a kind of serendipitous foundation.
leorocky 12y ago
I don't understand what a functor is or why an array is a functor. Can anyone please explain? I did the wikipedia article for category theory and I read some stack overflow questions and I'm not sure I understand why an array is a functor. It seems some languages have their own meaning for what a "functor" is, confusing the issue. My initial guess is that a functor is just sort of like a function that casts or does something like return an interface type from a type that implements the interface or a base class. Is that right? I still don't understand why an array is a functor though, I'd imagine it would at least have to be a function? Edit: Actually I think he's talking about Haskell's version of an iterable, and it would then make sense to call an array a functor. https://en.wikibooks.org/wiki/Haskell/The_Functor_class https://en.wikibooks.org/wiki/Haskell/The_Functor_class Why is that called a functor instead of an iterable or enumerable though?
- JoshTriplett 12y ago
  The name "Functor" can be confusing; it's a thing you apply a function to, not a function itself. A Functor is a type t parameterized by some other type a, such that if you have a function from type a to type b, you can apply that function to a t of a and get a t of b. Most commonly, a functor will be a container of values of type a, and the mapping consists of applying the function to each value, resulting in a container of values of type b. Other common functors include a computation that returns type a (use composition to apply the function to the result to get a computation that returns type b), or a possibly null pointer to type a (map null to null, map pointer to a to pointer to b).
  - twic 12y ago
    In an alternate universe where functional programming was invented by programmers rather than mathematicians, map would probably be called something like convertWith and a functor would probably be called something like a convertible. If you think of a function as being a way of converting from one kind of thing to another, then a functor is an object which has a number of things which you can convert to some other kind (a number which may be one or zero), using a method of your choice, and map is the name of the method you use to do that.
archgrove 12y ago
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...
blahber 12y ago
/annoyed I Agree with what Chris Granger said in https://twitter.com/ibdknox/status/473912605350719488 https://twitter.com/ibdknox/status/473912605350719488. I think Rust is a good example of developing a language in the open. That said it's great to see Bret's ideas see more implementations.
- gress 12y ago
  If you 'agree' with Chris Granger, perhaps you can name one of the mistakes. Also - what good is Rust being developed in the open if it can't be used for production apps yet?
  - dignati 12y ago
    Because it's not expected to be developed in the open ever and will therefore never be useful for production apps?
tkubacki 12y ago
Swift seems like a nice lang, but I'm surprised that proprietary, single platform language is getting so much traction on HN. Is it because ObjectiveC is as shitty as it seems at first sight (for C like langs dev) ?
- rimantas 12y ago
  Objective-C is far from being shitty. Your comment, on the other hand, is.
  - tkubacki 12y ago
    You are overreacting. I'm not saying it's shitty - but it SEEMS to be at least for most Java/C# devs (I know) AT FIRST SIGHT. My hypothesis was: Objective-C is "not nice" (sorry, I'm not familiar with HN political correctness) therefore Swift feels like a true relief for iOS devs and thus this much traction.
    - asveikau 12y ago
      It seems these days there are a lot of Java and C# focused people who are unfamiliar with what came earlier. They have a hard time making these sorts of comparisons. To me the comparison that makes more sense is going from C to objc. Or alternatively, comparing objc and C++ (especially C++ as practiced in the 1990s, not the RAII or template patterns that emerged later). Say you're looking at the landscape as it existed a while back, and you've decided to make language changes to C in order to add objects. On the one hand you have C++ as it existed then: a language that can't seem to figure itself out, that has a very complex syntax and lots of troubling situations you can walk into. Then along comes objc. In contrast to C++, the language delta from C is tiny and easy to keep in your head. Especially before Apple started doing all this compiler-fu of recent years, it felt like just a few keywords bolted on, and most of the important additions seemed to be in the runtime library. When I first saw objc it kind of clicked for me as the anti-C++, in a way that is truer to C and doesn't add a lot of complexity. At the time that seemed refreshing, though I think I see more good in C++ now that RAII and templates are more of a thing. (If only there existed a set of 2 people who could agree on what C++ features to use.)
acqq 12y ago
Still, I look at the Swift with a low-level colored glasses: I don't care if this or that category theory aspect is covered or not. I don't care if you can imagine some nicer syntax for something (everybody can). I really care how good and how often Swift can be used instead of C, not being slower and not using more resources. I know, <your-favorite-language-almost-nobody-uses> is nicer. But for me, if it has GC, it's a no go. I see Swift as something where I win when I can use it instead of writing C, not as something where I lose since the most of problems I solve by writing software I can't solve by writing in <some other language>. Swift is impressive language for v0.1, very pragmatic in aspects I care about. So you see that there's chance it will probably be even more expressive in some other version. Nice. Even as it is, it's much nicer than any other options for the purposes for which it was designed.
- _random_ 12y ago
 The language is not "innovative" as they claim, so people are expecting at least some learning from mistakes of prior languages. They could've hired some smart people from more software-oriented companies or something.
 - acqq 12y ago
 Given the constraints, it's certainly very innovative.
 - _random_ 12y ago
 Just to be clear: innovative for Apple development community or innovative generally? Please list some/all innovations, I would be happy to reconsider.
 - acqq 12y ago
 Apple GUI development is obviously a major constraint. Another is: no GC in order to avoid the collections happening when they want and thus making the smoothness of the UI impossible. I still claim there isn't at this moment any more innovative language that can provide that what Swift provides, observing any GUI platform you want to observe: meaning that level of support for the platform's native GUI with that performance and elegance.
pohl 12y ago
After reading this, I tried to find out which versions of Haskell and Scala introduced higher kinded types. I'm sure it wasn't among the first features. Does anybody know the history of either? AFAIK you can't do Functor in Rust yet either, and for the same reason.
jmah 12y ago
I successfully got the Functor example to work like this: protocol Functor { typealias T typealias FunctorResult func map(mappingFunction: T -> P) -> FunctorResult } extension Dictionary : Functor { func map(mappingFunction: ValueType -> P) -> Dictionary<KeyType, P> { var newDict:Dictionary<KeyType, P> = [:] for (key, value) in self { newDict[key] = mappingFunction(value) } return newDict } }
- afthonos 12y ago
 That doesn't actually work, because you're limiting the return type of the method in the implementation of the functor. So by implementing that protocol, you could have one mapping from Int to String (say), but not another from Int to Double. Put another way, you need to specify FunctorResult at implementation time, and the whole point is to only have to specify it at call time.
 - jmah 12y ago
 This code works: let d = [1: 1, 2: 2, 3: 3] let intToInt = d.map { $0 + 1 } var IntToString = d.map { String($0) }
 - afthonos 12y ago
 The code works, but the type of the generic is not guaranteed at compile time. FunctorResult could be anything at all. There is no compile-time obligation for the code to return a Dictionary<KeyType, P>. The more canonical example of a Functor is really the Optional. The mapping method for an optional looks like this: func fmap(f: A -> B) -> Optional { switch self { case Some(let a): return Some(f(A)) case None: return None } } However, with your protocol, I can define the mapping function for the Optional as: func fmap(f: A -> B) -> B[] { switch self { case Some(let a): return [f(A)] case None: return B[]() } } This would pass the type-checker, but is not what a Functor does.
- barrkel 12y ago
stcredzero 12y ago
To me, the things I tried weren’t insane; they seemed like the obvious things to try. These are obvious things to try, from the POV of environments like Scala. That's the wrong context from which to evaluate this language. Swift is a more modern language for iOS and is most usefully evaluated in that context. (Though it is also important to also know what Swift is not in language terms.)
hit8run 12y ago
"She" the programmer. Seriously this sounds ridiculous and is the outcome of the shameful male "betafication" women try to establish these days. I say "he" the programmer. Okay enugh bullshit and to the point: Swift is preview. It will get better and better fromday to day. It isn't there to mimic scala or lisp paradigms. It is there to get the job done and it will get the job done.
- rsynnott 12y ago
  > I say "he" the programmer. Well, aren't you wonderful? Why, you'll probably win the Nobel Prize for Protecting the Poor Oppressed Men! Alternating he and she for an abstract person is quite common amongst people who don't use singular they.
  - wpietri 12y ago
    Exactly. How will wee poor, oppressed male programmers survive as only 80 or 90% of the field? For those wondering about the weird "betafication" thing, I recommend reading this fine blog: http://wehuntedthemammoth.com/ http://wehuntedthemammoth.com/ It's a trope of the self-anointed "men's rights" crowd, from people who are in a continual hysteria about how society is stopping them from being proper alpha males. Never quite getting that passive-aggressive anonymous-coward Internet message board comments are not how chimpanzee males work out their dominance issues.
- CmonDev 12y ago
  That's just unnecessary political correctness. It's very hip amongst a very special crowd of people. Using multiple genders somehow fixes the gender dis-balance in the craft.
ksk 12y ago
Its amusing to see Apple cheerleaders defend Swift as being good enough for version 0.1 when supposedly Apple is this company that only releases products when they're complete/polished/etc. Apple themselves proclaim its "Ready Today" on their marketing page as well. (https://developer.apple.com/swift/ https://developer.apple.com/swift/)
- rsynnott 12y ago
  Apple does that with _consumer_ products (well, usually; please ignore Siri). They've historically been much more willing to ship developer stuff that's very rough around the edges; the iPhone OS 2.0 SDK shipped in a barely usable state, for instance, and Xcode 4 was a similar story.
  - ksk 12y ago
    Fair enough. :)

281 points by afthonos 12y ago

FWIW. map() already exists. It's a global function, rather than being a protocol method, and it uses overloading. So you can still define functions merely by defining a new overload for map() that operates on your type.

eridius 12y ago
Sigh, I typed "functors", not "functions", which should make a bit more sense. Autocorrect changed that without me noticing.

gfosco 12y ago

Since Bolts/BFTask was mentioned, I'd like to point out that you can use the Bolts-iOS library in Swift. I added a pull request with the code examples in Swift here: https://github.com/BoltsFramework/Bolts-iOS/pull/37/files https://github.com/BoltsFramework/Bolts-iOS/pull/37/files

noobermin 12y ago

Just to point out, the last two sound like it's due to the current implementation (compiler) being new, so it isn't so upsetting at all. Now, not supporting functors is odd, though.

afthonos 12y ago
Yeah, that's why I said the crashes gave me hope. It seems they are trying to support those use cases, but haven't worked out the kinks. I'm totally fine with that.
pohl 12y ago
Why is it odd? Is there a historical precedent for some other language exposing higher kinded types this early in the lifecycle? (Prior to 1.0, that is?) Ωmega, maybe? Is that what we're expecting of the new "normal" already?
- sparkie 12y ago
  It's not odd that Haskell didn't have them in 1.0, because they were not conceptualized until '93[1] after the Haskell report has been published in '90. They made it into the Haskell report 1.3 ('96)[2]. We should not be comparing the development of languages now to 20 years ago - there is an enormous amount we have learned, and these insights should be fundamental considerations when designing a new language. You can't just "tack" things onto an existing language and expect it to be elegant - tacking on leads to huge languages like C++. And yes, we should expect it as "normal" for new languages, because it is what people have come to expect to have available - although some implementations leave a lot to be desired. If we consider how C# implements Functors for example, we see that it requires special language support, where the compiler essentially pattern matches over your code, looking for a method named "Select", with a specific signature taking a generic type and a func. This implementation completely misses the point that Functors themselves, while useful, are not special - they are a specialization of a more general concept we have - typeclasses and higher-kinded polymorphism. C# also adds the ability to create Monads, Foldable, Comonads etc, using similar patterns - but you can't create your own typeclasses, and are left to the language designers to add a desired feature. The decision to add them onto C# like this was made not without knowledge of this, but out of consideration of working with the existing language, which was designed without their consideration, hence, why they're a pretty ugly design compared to the simplicity of Haskell's implementation. [1]:http://www.cs.tufts.edu/comp/150GIT/archive/mark-jones/fpca93.pdf http://www.cs.tufts.edu/comp/150GIT/archive/mark-jones/fpca9... [2]:http://research.microsoft.com/en-us/um/people/simonpj/papers/history-of-haskell/history.pdf http://research.microsoft.com/en-us/um/people/simonpj/papers...
  - pohl 12y ago
    Haskell and Scala both seem to have survived adding it later. Rust won't have it by 1.0 either, and this never seems to come up in threads about Rust. I agree it will be a nice feature, if/when it comes. I just think Swift is being held to a higher standard because, well, Apple. By the way, thank you for the timeline for Haskell. That's exactly what I was wanting to know.
    - 12y ago

stefantalpalaru 12y ago

> I love what the compiler crashes let me hope it will do These rose-colored glasses are getting ridiculous.

deleted 12y ago
[deleted]
andybak 12y ago
By my reading the author made that statement, not naively, but with full awareness of it's slightly ridiculous nature. I think that whooshing sound was their joke going right over your head.
- afthonos 12y ago
  Author here. To be fully honest, it's somewhere between the two. Yes, I'm aware of the irony of the statement. But what I failed to make clear in the post is that the code in the last two examples passes the type checker. Where it fails is at the intermediate representation stage. So the grammar of the language supports the constructs but the backend hasn't caught up yet. It's possible, of course, that Apple will modify the grammar to make these use cases impossible. But I would be very surprised. I can't blame anyone for accusing me of rose-tinted glasses until we know for sure, though.
rsynnott 12y ago
An early beta compiler crashes! Oh, noes, Apple is doomed! I think the point here is that if the compiler crashes, that implies that it is trying to do the thing, as opposed to saying "No, filthy programmer, I will not permit you to do that thing."

dirtyaura 12y ago

I've had very similar experience: I try to port non-trivial, but still rather simple functional code, for example containing a couple of nested closures, and the compiler crashes. And it seems that the Xcode playground, the command line compiler and REPL all behave a bit differently. In one case playground works, but REPL crashes, in another, compiler works, REPL has trouble of figuring out types. I have absolutely no experience on implementing compilers, but for a layman these inconsistencies seems very odd.

danabramov 12y ago
Microsoft's work on C# compiler (Roslyn) is amazing: they offer compiler-as-a-library so the IDE, plugins and debugger use the same backend as the compiler itself. I wish at some point Apple could adopt a similar approach.
- pohl 12y ago
  That's basically what drove the design of clang. No doubt the approach with swift will be similar.
- deleted 12y ago
  [deleted]
- coldtea 12y ago
  Hmm, Apple went there before Roslyn with Clang/LLVM (whose creator is the designer of Swift and works for Apple). The idea behind LLVM was to have the various compiler stages and tooling be re-usable and plugin like, unlike the monolithic design GCC had. And Apple already uses the came "compiler-as-a-library" approach, even for Objective-C, to implement: the compiler, the syntax highlight, AST-based auto-completion, debugging and error fix suggestions and other stuff. I'm pretty sure that the case with Swift is the same. It's just that it's not stable yet, so you can get crashes at various stages of all those pipelines.
  - 0x09 12y ago
    >The idea behind LLVM was to have the various compiler stages and tooling be re-usable and plugin like, unlike the monolithic design GCC had. More specifically, the idea behind LLVM was "life-long program compilation and optimization" in stages at translation time, link time, install time, and runtime. The natural way to realize this was modular components at different levels working around a good serializable IR. If your goal is a traditional once-and-done AOT compiler, you might be forgiven for architecting something more heavily coupled and interdependent like GCC, whose IR was an afterthought (by 15 years.) LLVM's focus has shifted somewhat, but those original designs created a kind of serendipitous foundation.

leorocky 12y ago

I don't understand what a functor is or why an array is a functor. Can anyone please explain? I did the wikipedia article for category theory and I read some stack overflow questions and I'm not sure I understand why an array is a functor. It seems some languages have their own meaning for what a "functor" is, confusing the issue. My initial guess is that a functor is just sort of like a function that casts or does something like return an interface type from a type that implements the interface or a base class. Is that right? I still don't understand why an array is a functor though, I'd imagine it would at least have to be a function? Edit: Actually I think he's talking about Haskell's version of an iterable, and it would then make sense to call an array a functor. https://en.wikibooks.org/wiki/Haskell/The_Functor_class https://en.wikibooks.org/wiki/Haskell/The_Functor_class Why is that called a functor instead of an iterable or enumerable though?

JoshTriplett 12y ago
The name "Functor" can be confusing; it's a thing you apply a function to, not a function itself. A Functor is a type t parameterized by some other type a, such that if you have a function from type a to type b, you can apply that function to a t of a and get a t of b. Most commonly, a functor will be a container of values of type a, and the mapping consists of applying the function to each value, resulting in a container of values of type b. Other common functors include a computation that returns type a (use composition to apply the function to the result to get a computation that returns type b), or a possibly null pointer to type a (map null to null, map pointer to a to pointer to b).
- twic 12y ago
  In an alternate universe where functional programming was invented by programmers rather than mathematicians, map would probably be called something like convertWith and a functor would probably be called something like a convertible. If you think of a function as being a way of converting from one kind of thing to another, then a functor is an object which has a number of things which you can convert to some other kind (a number which may be one or zero), using a method of your choice, and map is the name of the method you use to do that.

archgrove 12y ago

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...

blahber 12y ago

/annoyed I Agree with what Chris Granger said in https://twitter.com/ibdknox/status/473912605350719488 https://twitter.com/ibdknox/status/473912605350719488. I think Rust is a good example of developing a language in the open. That said it's great to see Bret's ideas see more implementations.

gress 12y ago
If you 'agree' with Chris Granger, perhaps you can name one of the mistakes. Also - what good is Rust being developed in the open if it can't be used for production apps yet?
- dignati 12y ago
  Because it's not expected to be developed in the open ever and will therefore never be useful for production apps?

tkubacki 12y ago

Swift seems like a nice lang, but I'm surprised that proprietary, single platform language is getting so much traction on HN. Is it because ObjectiveC is as shitty as it seems at first sight (for C like langs dev) ?

rimantas 12y ago
Objective-C is far from being shitty. Your comment, on the other hand, is.
- tkubacki 12y ago
  You are overreacting. I'm not saying it's shitty - but it SEEMS to be at least for most Java/C# devs (I know) AT FIRST SIGHT. My hypothesis was: Objective-C is "not nice" (sorry, I'm not familiar with HN political correctness) therefore Swift feels like a true relief for iOS devs and thus this much traction.
  - asveikau 12y ago
    It seems these days there are a lot of Java and C# focused people who are unfamiliar with what came earlier. They have a hard time making these sorts of comparisons. To me the comparison that makes more sense is going from C to objc. Or alternatively, comparing objc and C++ (especially C++ as practiced in the 1990s, not the RAII or template patterns that emerged later). Say you're looking at the landscape as it existed a while back, and you've decided to make language changes to C in order to add objects. On the one hand you have C++ as it existed then: a language that can't seem to figure itself out, that has a very complex syntax and lots of troubling situations you can walk into. Then along comes objc. In contrast to C++, the language delta from C is tiny and easy to keep in your head. Especially before Apple started doing all this compiler-fu of recent years, it felt like just a few keywords bolted on, and most of the important additions seemed to be in the runtime library. When I first saw objc it kind of clicked for me as the anti-C++, in a way that is truer to C and doesn't add a lot of complexity. At the time that seemed refreshing, though I think I see more good in C++ now that RAII and templates are more of a thing. (If only there existed a set of 2 people who could agree on what C++ features to use.)

acqq 12y ago

Still, I look at the Swift with a low-level colored glasses: I don't care if this or that category theory aspect is covered or not. I don't care if you can imagine some nicer syntax for something (everybody can). I really care how good and how often Swift can be used instead of C, not being slower and not using more resources. I know, <your-favorite-language-almost-nobody-uses> is nicer. But for me, if it has GC, it's a no go. I see Swift as something where I win when I can use it instead of writing C, not as something where I lose since the most of problems I solve by writing software I can't solve by writing in <some other language>. Swift is impressive language for v0.1, very pragmatic in aspects I care about. So you see that there's chance it will probably be even more expressive in some other version. Nice. Even as it is, it's much nicer than any other options for the purposes for which it was designed.

_random_ 12y ago
The language is not "innovative" as they claim, so people are expecting at least some learning from mistakes of prior languages. They could've hired some smart people from more software-oriented companies or something.
- acqq 12y ago
  Given the constraints, it's certainly very innovative.
  - _random_ 12y ago
    Just to be clear: innovative for Apple development community or innovative generally? Please list some/all innovations, I would be happy to reconsider.
    - acqq 12y ago
      Apple GUI development is obviously a major constraint. Another is: no GC in order to avoid the collections happening when they want and thus making the smoothness of the UI impossible. I still claim there isn't at this moment any more innovative language that can provide that what Swift provides, observing any GUI platform you want to observe: meaning that level of support for the platform's native GUI with that performance and elegance.

pohl 12y ago

After reading this, I tried to find out which versions of Haskell and Scala introduced higher kinded types. I'm sure it wasn't among the first features. Does anybody know the history of either? AFAIK you can't do Functor in Rust yet either, and for the same reason.

jmah 12y ago

I successfully got the Functor example to work like this: protocol Functor { typealias T typealias FunctorResult func map(mappingFunction: T -> P) -> FunctorResult } extension Dictionary : Functor { func map(mappingFunction: ValueType -> P) -> Dictionary<KeyType, P> { var newDict:Dictionary<KeyType, P> = [:] for (key, value) in self { newDict[key] = mappingFunction(value) } return newDict } }

afthonos 12y ago
That doesn't actually work, because you're limiting the return type of the method in the implementation of the functor. So by implementing that protocol, you could have one mapping from Int to String (say), but not another from Int to Double. Put another way, you need to specify FunctorResult at implementation time, and the whole point is to only have to specify it at call time.
- jmah 12y ago
 This code works: let d = [1: 1, 2: 2, 3: 3] let intToInt = d.map { $0 + 1 } var IntToString = d.map { String($0) }
 - afthonos 12y ago
 The code works, but the type of the generic is not guaranteed at compile time. FunctorResult could be anything at all. There is no compile-time obligation for the code to return a Dictionary<KeyType, P>. The more canonical example of a Functor is really the Optional. The mapping method for an optional looks like this: func fmap(f: A -> B) -> Optional { switch self { case Some(let a): return Some(f(A)) case None: return None } } However, with your protocol, I can define the mapping function for the Optional as: func fmap(f: A -> B) -> B[] { switch self { case Some(let a): return [f(A)] case None: return B[]() } } This would pass the type-checker, but is not what a Functor does.
barrkel 12y ago

stcredzero 12y ago

To me, the things I tried weren’t insane; they seemed like the obvious things to try. These are obvious things to try, from the POV of environments like Scala. That's the wrong context from which to evaluate this language. Swift is a more modern language for iOS and is most usefully evaluated in that context. (Though it is also important to also know what Swift is not in language terms.)

hit8run 12y ago

"She" the programmer. Seriously this sounds ridiculous and is the outcome of the shameful male "betafication" women try to establish these days. I say "he" the programmer. Okay enugh bullshit and to the point: Swift is preview. It will get better and better fromday to day. It isn't there to mimic scala or lisp paradigms. It is there to get the job done and it will get the job done.

rsynnott 12y ago
> I say "he" the programmer. Well, aren't you wonderful? Why, you'll probably win the Nobel Prize for Protecting the Poor Oppressed Men! Alternating he and she for an abstract person is quite common amongst people who don't use singular they.
- wpietri 12y ago
  Exactly. How will wee poor, oppressed male programmers survive as only 80 or 90% of the field? For those wondering about the weird "betafication" thing, I recommend reading this fine blog: http://wehuntedthemammoth.com/ http://wehuntedthemammoth.com/ It's a trope of the self-anointed "men's rights" crowd, from people who are in a continual hysteria about how society is stopping them from being proper alpha males. Never quite getting that passive-aggressive anonymous-coward Internet message board comments are not how chimpanzee males work out their dominance issues.
CmonDev 12y ago
That's just unnecessary political correctness. It's very hip amongst a very special crowd of people. Using multiple genders somehow fixes the gender dis-balance in the craft.

ksk 12y ago

Its amusing to see Apple cheerleaders defend Swift as being good enough for version 0.1 when supposedly Apple is this company that only releases products when they're complete/polished/etc. Apple themselves proclaim its "Ready Today" on their marketing page as well. (https://developer.apple.com/swift/ https://developer.apple.com/swift/)

rsynnott 12y ago
Apple does that with _consumer_ products (well, usually; please ignore Siri). They've historically been much more willing to ship developer stuff that's very rough around the edges; the iPhone OS 2.0 SDK shipped in a barely usable state, for instance, and Xcode 4 was a similar story.
- ksk 12y ago
  Fair enough. :)