Live data from Hacker News

Smashing Swift

nomothetis.svbtle.com

21–30 of 150 posts

Re: Smashing Swift

#21
post #19

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 ). 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 variou…

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

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.

Re: Smashing Swift

#23
post #8

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 s…

More precisely it is an endofunctor in the category whose objects are Swift types and morphisms are functions between Swift types. All this really means is that given a Swift type, say Int or String, there are Arrays of Int or String, and given a function like showInt(a : Int) : String, a functor gives you a function from an Array of Int to an Array of String (in this case it would just apply showInt to each element…

Thank you for this. I find explanations that eschew category theory bizarre, this really cleared things up for me (having spent a lot of time with functors mathematically, and almost no time with them in a programming context).

Re: Smashing Swift

#24

Earlier quoted context omitted.

More precisely it is an endofunctor in the category whose objects are Swift types and morphisms are functions between Swift types. All this really means is that given a Swift type, say Int or String, there are Arrays of Int or String, and given a function like showInt(a : Int) : String, a functor gives you a function from an Array of Int to an Array of String (in this case it would just apply showInt to each element…

Thank you for this. I find explanations that eschew category theory bizarre, this really cleared things up for me (having spent a lot of time with functors mathematically, and almost no time with them in a programming context).

I appreciate orbifold taking the time to reply but I couldn't understand his answer at all, even after perfectly understanding what others have said. There are 3 sentences in that paragraph the second of which is very large and difficult to parse and missing an end parenthesis somewhere.

Why do you get a composition of functions by applying a functor to individual functions? It seems like a functor is just something you can map over. When a functor is mapped over the end result is another functor. Not a function nor a composition of functions.

Re: Smashing Swift

#25
post #17
post #8

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 s…

A functor is a thing that can be mapped over. For example: map abs [-1, 2, 3] => [1, 2, 3] Arrays are the simplest example, but it looks like an iterable. However functors retain shape whereas iterables don't. For example if we had a tree (represented visually): oak = -1 / \ 2 3 If we used oak as an iterable, we would lose the structure of the tree: map abs iter(oak) => [1, 2, 3] However if tree belongs to the functo…

I get it now, thank you for this great explanation, and all the other explanations as well. I think it warrants its own wikipedia page.

Re: Smashing Swift

#26
post #17
post #8

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 s…

A functor is a thing that can be mapped over. For example: map abs [-1, 2, 3] => [1, 2, 3] Arrays are the simplest example, but it looks like an iterable. However functors retain shape whereas iterables don't. For example if we had a tree (represented visually): oak = -1 / \ 2 3 If we used oak as an iterable, we would lose the structure of the tree: map abs iter(oak) => [1, 2, 3] However if tree belongs to the functo…

>However functors retain shape whereas iterables don't.

Wow. Such a simple sentence yet this is the first time I have read it, and it makes the concept much more clear than hundreds of articles before did. Thank you!

I wish all FP features would be explained so simply.

Re: Smashing Swift

#27

Earlier quoted context omitted.

>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. So did I! A few more related links if you're interested in this question: http://schani.wordpress.com/2014/06/11/associated-types-cons... http://www.artima.com/we…

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 { ... } class Bar : Foo { ... } You'd expect Bar to be a non-generic type, but this throws a compiler error. You have to declare: class…

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.

Re: Smashing Swift

#28

Earlier quoted context omitted.

Thank you for this. I find explanations that eschew category theory bizarre, this really cleared things up for me (having spent a lot of time with functors mathematically, and almost no time with them in a programming context).

I appreciate orbifold taking the time to reply but I couldn't understand his answer at all, even after perfectly understanding what others have said. There are 3 sentences in that paragraph the second of which is very large and difficult to parse and missing an end parenthesis somewhere. Why do you get a composition of functions by applying a functor to individual functions? It seems like a functor is just something…

> Why do you get a composition of functions by applying a functor to individual functions? It seems like a functor is just something you can map over. When a functor is mapped over the end result is another functor. Not a function nor a composition of functions.

A function is a Functor. ;)

If you have a function f and a function g, fmap f g = h, and h is a function. A more common way to write this is function composition of f and g, which can be written: f . g. The dot (.) is function composition. Which means that fmap f g = f . g, which means that fmap = (.).

> When a functor is mapped over the end result is another functor. Not a function nor a composition of functions.

But they was describing the case when the Functor in question is a function.

Re: Smashing Swift

#29
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) ?

Re: Smashing Swift

#30
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, 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 .

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.

Post reply on HN