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.
How is memory usage relevant to creating fluid/responsive applications? How is JavaScript DOM management even comparable to native UIs where the UI thread runs with realtime priority in native unmanaged code? And when did we stop talking about programming languages and talking about runtime and operating systems?
You were talking about a language's capabilities of creating fast responsive UIs on limited hardware. There are no language features that contribute to that, it is the operating system and runtime that does that. Are these things well done on Apple systems? Yes, absolutely. But that has no relation whatsoever to the discussion whether Swift is an innovative language or not. Apple could have bolted Common Lisp, Fortran or Rust onto that runtime, and that would have no relevance at all to the discussion about the innovativity of those languages.
Windows Phone also has a good runtime despite that it runs various garbage collected languages. Fluid apps are created for it all the time for low memory systems in various languages. But that doesn't make Visual Basic an innovative language.
> How is memory usage relevant to creating fluid/responsive applications?
Mobile phones are generally memory constrained as compared to desktop computers, because memory takes space and power. In addition, their memory bandwidth is usually _extremely_ constrained as compared to desktop computers, making big copies, etc, expensive.
You're showing some incredible arrogance here by not addressing my other points. You fail to address the point how specifically the Swift language (not the Swift runtime) is so innovative that it enables fast apps on resource constrained devices. Because I can name dozens more languages that could do the same with native access to the Apple runtime.
> I can name dozens more languages that could do the same
How about naming one that actually now does the same with the native access to any GUI resource constrained platform? F# certainly can't avoid the graph quoted. The y axis is the slowdown as soon as there isn't enough memory. The point you yourself claim that you don't understand, so how can we discuss anything further? I actually wrote my comments assuming that the people who'd discuss would understand the issues I assumed to be well-known and thoroughly documented among other places in the Drew Crawford's article.
> @acqq
Don't hang me up on a figure of speech. It's frustratingly rude. I do understand how memory management relates to fluid applications. I don't understand how that point relates to Swift's innovativity, and you give the impression that you don't either. Please at least have the courtesy to show how the Swift language has an innovation that allows for responsive UIs. There are dozens of languages that are or can be reference counted.
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.