Smashing Swift
nomothetis.svbtle.com
Smashing Swift
1–10 of 150 posts
Re: Smashing Swift
#2Just 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.
Re: Smashing Swift
#3Just 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.
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.
Re: Smashing Swift
#4> I love what the compiler crashes let me hope it will do
These rose-colored glasses are getting ridiculous.
Re: Smashing Swift
#5> I love what the compiler crashes let me hope it will do These rose-colored glasses are getting ridiculous.
[deleted]
Re: Smashing Swift
#6I'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.
Re: Smashing Swift
#7> I love what the compiler crashes let me hope it will do These rose-colored glasses are getting ridiculous.
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.
Re: Smashing Swift
#8I 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
Why is that called a functor instead of an iterable or enumerable though?
Re: Smashing Swift
#9Compiler 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). 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".
Re: Smashing Swift
#10> I love what the compiler crashes let me hope it will do These rose-colored glasses are getting ridiculous.
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.
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.