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

121–130 of 150 posts

Re: Smashing Swift

#121

Post by DCKing »

acqq wrote: post #119
DCKing wrote: post #117

Earlier quoted context omitted.

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…

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.

Re: Smashing Swift

#122

Post by acqq »

DCKing wrote: post #121
acqq wrote: post #119

Earlier quoted context omitted.

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…

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

> How is memory usage relevant to creating fluid/responsive applications?

Unless there is an understanding of that there's no point in arguing further. The whole mentioned article explains, among other topics, exactly that.

Re: Smashing Swift

#123

Post by Dewie »

acqq wrote: post #120
Dewie wrote: post #107

Earlier quoted context omitted.

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

> 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

Red herring. aidanhs' reply was to someone who genuinely asked why garbage collection is problematic. The comments I'm talking about have not mentioned garbage collection, just questioning what innovative really is. I guess you then tried to infer that they thought that garbage collection vs. reference counting doesn't matter, i.e. isn't innovative? I find that to be an unfair inference. They might as well think that something like that has already been done/is being done, i.e. with Rust and how it relegates any automatic memory management to opt-in libraries.

So it seems to be a disagreement about what is really worthy of being called innovative, not any technical merit, as the comments that I'm talking about has not questioned that.

> From the article:

> "no, your experience with server-side programming does not adequately prepare you to “think small” and correctly reason about mobile performance."

Straw man, unless you somehow know that all of these people only have experience with server-side programming.

Re: Smashing Swift

#124

Post by mikeash »

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?

When calling out to other code you don't control, you lose determinism in the sense of being able to exactly predict when objects get destroyed when you write the code. The refcount semantics of the code you're calling can change while still maintaining correctness, and this can cause your objects to be destroyed differently. Accidentally relying on this has been the cause of many OS-version compatibility problems on the Mac over the years.

For multithreading, I thought that would be fairly obvious. Once two or more threads hold ownership over a single object, you can no longer be sure which thread will perform the final decrement (at least in the general case) and so you don't know exactly when the object will be destroyed, or even which thread it will be destroyed on.

Re: Smashing Swift

#125

Post by DCKing »

acqq wrote: post #122
DCKing wrote: post #121

Earlier quoted context omitted.

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

> How is memory usage relevant to creating fluid/responsive applications? Unless there is an understanding of that there's no point in arguing further. The whole mentioned article explains, among other topics, exactly that.

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.

Re: Smashing Swift

#126

Post by acqq »

DCKing wrote: post #125
acqq wrote: post #122

Earlier quoted context omitted.

> How is memory usage relevant to creating fluid/responsive applications? Unless there is an understanding of that there's no point in arguing further. The whole mentioned article explains, among other topics, exactly that.

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.

Re: Smashing Swift

#127

Post by DCKing »

DCKing wrote: post #125
acqq wrote: post #122

Earlier quoted context omitted.

> How is memory usage relevant to creating fluid/responsive applications? Unless there is an understanding of that there's no point in arguing further. The whole mentioned article explains, among other topics, exactly that.

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.

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

Re: Smashing Swift

#128

Post by rsynnott »

_random_ wrote: post #63
acqq wrote: post #52

Earlier quoted context omitted.

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…

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

> To me innovation means something absolutely new, not re-applying/combining prior art.

You may have considerable difficulty finding a language that anyone uses that is innovative, in that case. Most new programming language concepts are explored in research projects, and _then_ incorporated into languages.

Re: Smashing Swift

#129

Post by rsynnott »

DCKing wrote: post #121
acqq wrote: post #119

Earlier quoted context omitted.

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…

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

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

Re: Smashing Swift

#130

Post by orbifold »

leorocky wrote: post #24
muaddirac wrote: post #23

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…

I was unsure what notation to use, so I used english instead. In Haskell a Functor f is characterized by a higher order function fmap :: (a -> b) -> (f a -> f b), which is required to satisfy the laws

fmap (g . f) = (fmap g) . (fmap f)

and

fmap id = id

where (.) :: (b -> c) -> (a -> b) -> (a -> c) is the function composition operator and id :: a -> a the identity function. Those are the laws the last two sentences try to phrase in english. In mathematics a functor F between categories C and D maps objects in C to objects in D and any morphism f: X -> Y in C to a morphism F f : F X -> F Y in D, in such a way that for morphisms f : X -> Y and g : Y -> Z in C one has F (g . f) = F g . F f and F id_X = id_{F X}. So you see Haskell and math notation are almost identical, although you can express the laws only as compiler rules in Haskell.

Post reply on HN