Live data from Hacker News

Smashing Swift

nomothetis.svbtle.com

81–90 of 150 posts

Re: Smashing Swift

#81
post #69
post #38

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 { var newDict:Dictionary = [:] for (key, value) in self { newDict[key] = mappingFunction(value) } return newDict } }

Some folks are working on a library for this already: https://github.com/maxpow4h/swiftz

yup. we have a "Functor" https://github.com/maxpow4h/swiftz/blob/master/swiftz/Unsoun... It requires constructing a "Functor" value manually, otherwise it works fine. You can still write functions over an A in Functor. The Result enum bug presented you can work around by boxing the type, such as in https://github.com/maxpow4h/swiftz/blob/master/swiftz/List.s...

The third problem a work around exists for: remove the default argument. If you want an empty init, provide one.

Sure it is buggy, but you can express these programs.

Re: Smashing Swift

#82
post #61

Earlier quoted context omitted.

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.

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

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

Re: Smashing Swift

#83
post #19

Earlier quoted context omitted.

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

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.

Re: Smashing Swift

#84
post #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…

As a fairly inexperienced programmer, can someone please explain why everyone is so happy there is no garbage collection going on?

Shouldn't that be something we would want?

(Is it because control over this allows us to do extra things?)

Re: Smashing Swift

#85
post #69

Earlier quoted context omitted.

Some folks are working on a library for this already: https://github.com/maxpow4h/swiftz

yup. we have a "Functor" https://github.com/maxpow4h/swiftz/blob/master/swiftz/Unsoun... It requires constructing a "Functor" value manually, otherwise it works fine. You can still write functions over an A in Functor. The Result enum bug presented you can work around by boxing the type, such as in https://github.com/maxpow4h/swiftz/blob/master/swiftz/List.s... The third problem a work around exists for: remove the d…

Thanks for the Box suggestion; I'll try it and see how it works for me. I wouldn't have thought of that workaround.

Re: Smashing Swift

#86
post #84
post #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…

As a fairly inexperienced programmer, can someone please explain why everyone is so happy there is no garbage collection going on? Shouldn't that be something we would want? (Is it because control over this allows us to do extra things?)

Reference counting has an incremental performance burden because of predictable object freeing, while garbage collection has a periodic pause. On mobile devices you often must worry about response-times; it is a lot more easy to reason 'we need to ease up on such and such at this time', and be sure you solved the problem. Garbage collection pauses can be less straight-forward to tackle.

Re: Smashing Swift

#87

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

You can expect a reasonable behaviour on HN unless it has something to do with Apple..

Re: Smashing Swift

#88
post #60

Earlier quoted context omitted.

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

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

[deleted]

Re: Smashing Swift

#89
post #60

Earlier quoted context omitted.

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

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

[deleted]

Re: Smashing Swift

#90
post #60

Earlier quoted context omitted.

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

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

LLVM was a tiny project compared to what it became with Apple's investment. What LLVM is today is thanks to Apple's support of Chris Lattner.
Post reply on HN