Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Smashing Swift

nomothetis.svbtle.com

Post reply on HN
Print view View original

131–140 of 150 posts

Re: Smashing Swift

#131

Post by rsynnott »

ksk wrote: post #111

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

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.

Re: Smashing Swift

#132

Post by rsynnott »

stefantalpalaru wrote: post #4

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

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

Re: Smashing Swift

#133

Post by rsynnott »

hit8run wrote: post #98

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

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

Re: Smashing Swift

#134

Post by pohl »

baddox wrote: post #99
mikeash wrote: post #83

Earlier quoted context omitted.

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

I'm not very familiar with the implementation of programming languages, so maybe the terminology is subtly different, but how are either of those situations not deterministic?

It's still deterministic, strictly speaking. Maybe we need more subtle terminology here, like "fog of war" or "situational awareness" – as in "even with reference counting, the programmer may lose situational awareness of deallocation when calling into libraries beyond the fog of war."

Re: Smashing Swift

#135

Post by wpietri »

aidanhs wrote: post #110
bobbles wrote: post #84

Earlier quoted context omitted.

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

There's a helpful bit of writing about garbage collection on http://sealedabstract.com/rants/why-mobile-web-apps-are-slow... It boils down to there being a big performance penalty on garbage collection in memory-constrained environments.

Wow, that's a great article. I'm currently using mobile web stuff (Ionic, Angular, PhoneGap) to prototype some possible mobile apps. It's convenient, but I've been worrying about the long-range performance issues. This gives me a much more detailed way to think about it. That Apple got rid of garbage collection is especially telling.

Re: Smashing Swift

#136

Post by jmah »

afthonos wrote: post #45
jmah wrote: 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 } }

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.

This code works:

    let d = [1: 1, 2: 2, 3: 3]
    let intToInt = d.map { $0 + 1 }
    var IntToString = d.map { String($0) }

Re: Smashing Swift

#137

Post by vor_ »

Dewie wrote: post #107
Dewie wrote: post #55

Earlier quoted context omitted.

> meaning that level of support for the platform's native GUI with that performance and elegance. Seems like that criteria would bias the choice of most innovative language quite heavily towards languages developed for/by Apple, no?

Wow, when I went to bed this comment was at 2 karma. Now it is at a negative (-3) and so are all the comments in this chain of replies that was critical of Apple's product, when before they were not greyed out. Fancy that. :)

Suggesting anything "critical of Apple's product" automatically gets voted down just makes me roll my eyes.

Re: Smashing Swift

#138

Post by wpietri »

rsynnott wrote: post #133
hit8run wrote: post #98

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

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

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/

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.

Re: Smashing Swift

#139

Post by bmm6o »

baddox wrote: post #99
mikeash wrote: post #83

Earlier quoted context omitted.

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

I'm not very familiar with the implementation of programming languages, so maybe the terminology is subtly different, but how are either of those situations not deterministic?

As others have pointed out, it's deterministic in the sense that the memory is reclaimed when the ref count goes to zero, and the ref count is always well-defined. I would have used the word "predictable", in that `delete foo` will always release memory, but `foo.Decrement()` may or may not, and local reasoning may not suffice.

Re: Smashing Swift

#140

Post by gclaramunt »

acqq wrote: post #52
_random_ wrote: post #48

Earlier quoted context omitted.

Just to be clear: innovative for Apple development community or innovative generally? Please list some/all innovations, I would be happy to reconsider.

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

Filling a niche is not being innovative. Is totally fine, and it might be big deal, but if you take the language by itself it doesn't bring anything new to the table. But I might be wrong, so feel free to point to an innovative language feature.
Post reply on HN