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/)
Smashing Swift
111–120 of 150 posts
Re: Smashing Swift
#112Earlier quoted context omitted.
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.
> The language is not "innovative" as they claim Not innovative compared to what? Haskell? Unfinished betas like Rust? Some language 100 people use (plus 1-2 banks and a couple of universities)? This is a language that will jump in the top ten of most used languages in a year or so, just because it's used in a hugely popular development platform. And it had to fulfil several things to achieve that. > They could've hi…
>It is somewhat unfair to dismiss Rust as an unfinished beta in comments on an article that demonstrates how the Swift compiler isn't even up to beta standards.
I agree, didn't intent to dismiss Rust per se -- I like Rust.
Just wanted to give a perspective. Swift is in beta (and buggy), but Rust (if the OP compared it to that), isn't even syntactically stable.
Based on what we know, Swift will be in a (pretty much) stable condition come Fall, for the OS X release.
Re: Smashing Swift
#113Earlier 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?
In this case, I think this means it's not deterministic within the context of a single thread of execution.
Re: Smashing Swift
#114Earlier quoted context omitted.
In Java we would call it "Mappable". A Mappable interface would have one method: map(). It hasn't been all that useful until recently due to lack of closures, but perhaps it would make sense in Java 8? "Functor" is a terrible name that only a mathematician could like.
Remind me: can you declare a Java interface with a method signature that returns the same type as the class that eventually implements the interface? You wouldn't want the map method on mappable to simply return another Mappable, because that could be any other Mappable (i.e. a CustomList could implement map to return a CustomTree, when the functor concept requires it to return another CustomList).
You can do that partially. Because of the sub-classing and covariant return-types, I think you cannot prevent a CustomCollection from returning a CustomList. The definition would be:
public interface Mappable> {
T map();
}Re: Smashing Swift
#115Earlier quoted context omitted.
Yes, good point. I suppose replaceEach() would be a more descriptive name, so the interface might be HasReplaceEach. It's not as easy to talk about, though. Still better than "functor". (The function being passed in to map() is an alternate way to represent a very large map, in a mathematical sense.)
Exactly. We'd only call the interface 'Mappable' if the method was called 'map', and that's something that's come from mathematical terminology. (I'd probably have called the 'Map' class 'Dictionary', if that hadn't already been taken!) I'd avoid 'replaceEach', because it sounds like it mutates the receiver. Maybe 'withEachReplaced'? Way clunky. In Smalltalk, this method is called 'collect', which is better than 'map…
The Smalltalk version of foreach() is called #do:. #inject: is like reduce().
That blog post inspired a fun discussion in the Smalltalk community on what the semantics of #infect: and #neglect: should be!
Re: Smashing Swift
#116Earlier quoted context omitted.
I see the source of your confusion now. To me innovation means something absolutely new, not re-applying/combining prior art. Wikipedia agrees: "Innovation differs from improvement in that innovation refers to the notion of doing something different rather than doing the same thing better."
Apple is doing something different and new, comparing all available languages capable to produce fast non-stuttering GUI based applications that work smoothly even on the smartphones and demand minimal resources. And it's not a small feat by any comparison. It's like you'd read about the first usable jet-powered car and then claim "but it's not innovative, there were jet powered planes already."
[deleted]
Re: Smashing Swift
#117Earlier quoted context omitted.
I see the source of your confusion now. To me innovation means something absolutely new, not re-applying/combining prior art. Wikipedia agrees: "Innovation differs from improvement in that innovation refers to the notion of doing something different rather than doing the same thing better."
Apple is doing something different and new, comparing all available languages capable to produce fast non-stuttering GUI based applications that work smoothly even on the smartphones and demand minimal resources. And it's not a small feat by any comparison. It's like you'd read about the first usable jet-powered car and then claim "but it's not innovative, there were jet powered planes already."
You're talking incredible nonsense. I can create fast non-stuttering GUI applications on phones with minimal resources (talking Don't pretend iOS' fluidness is some merit of Objective-C or Swift, because it is a merit of the operating system.
Re: Smashing Swift
#118Earlier 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.
Thanks! The linked article is absolutely a must-read for discussing the real limitations.
Re: Smashing Swift
#119Earlier quoted context omitted.
Apple is doing something different and new, comparing all available languages capable to produce fast non-stuttering GUI based applications that work smoothly even on the smartphones and demand minimal resources. And it's not a small feat by any comparison. It's like you'd read about the first usable jet-powered car and then claim "but it's not innovative, there were jet powered planes already."
You're talking incredible nonsense. I can create fast non-stuttering GUI applications on phones with minimal resources (talking Don't pretend iOS' fluidness is some merit of Objective-C or Swift, because it is a merit of the operating system.
Do read the article here linked by aidanhs:
https://news.ycombinator.com/item?id=7898305
then complain to all the authors that measured all that they measured (a lot of links and diagrams there) instead of complaining to me. It will still be an attempt to confront all the real measurements with your anecdotal evidence of one, your, particular case, unless you manage to disprove all the claims listed there.
Especially if you manage to disprove this:
http://sealedabstract.com/wp-content/uploads/2013/05/Screen-...
You'll be celebrated as the biggest genius of our times.
Re: Smashing Swift
#120Earlier 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. :)
What if it's because the claims in the mentioned comments were actually unsubstantiated? Read the article linked by aidanhs:
https://news.ycombinator.com/item?id=7898305
From the article:
"no, your experience with server-side programming does not adequately prepare you to “think small” and correctly reason about mobile performance."