5 ms·

This article is weird. It starts off with a strong premise -- we need more fact-based arguments when discussing technology choices. Yes, agree! There are a fai

This article is weird. It starts off with a strong premise -- we need more fact-based arguments when discussing technology choices. Yes, agree! There are a fair amount of good points here, particularly about ARM's potential but he's very dismissive of counter points and seems to believe having lots of quotes is a substitute to a good argument. The section about garbage collection is especially unconvincing and, again, dismissive of counter points. He never really addresses Android or Windows Phone (which, by the way, he repeatedly mistakenly calls Windows Mobile -- which is right in line with the extreme iOS focus the article has). He mentions them, but then seems to think that a few quotes that show that, under some extreme circumstances -- mostly games -- the GC can be a problem on those platforms. But which is it, are all Java and C# Android/Windows Phone apps unacceptably slow or are some types of apps not really doable in those GC languages? This is important because a large part of his argument centers on GCs not working on mobile. I'd conclude that the article is overly defensive. To the point that the author repeatedly poisons-the-well of anyone who might potentially disagree. > we need to have conversations that at least appear to have a plausible basis in facts of some kind–benchmarks, journals, quotes from compiler authors, whatever. This is where I think the article falls apart. Appearing to be based on facts is what this article is about, but appearance just gets you talked about. It doesn't really move the conversation forward at all.

rsynnott 13y ago
> But which is it, are all Java and C# Android/Windows Phone apps unacceptably slow or are some types of apps not really doable in those GC languages? He didn't really say either; he pointed out (correctly) that for certain applications in a memory managed language, you'll want to essentially avoid using the GC, and you'll certainly have to be very cautious of it. The extreme case was old J2ME games, which usually worked by allocating all the memory they'd use as a large array at startup, and doing manual memory management thereafter. In general, you can do just about anything in a memory managed language, but in some cases, especially games, it may actually end up a lot more work than in a non-managed language.
- spullara 13y ago
  There are two performance choices in GC languages: 1) don't allocate after initialization 2) only allocate per small time frame There is an issue that 2) is only really feasible in server settings and doesn't really work for clients. I buy his argument even though I don't wish to program under his restrictions.

rsynnott 13y ago

> But which is it, are all Java and C# Android/Windows Phone apps unacceptably slow or are some types of apps not really doable in those GC languages? He didn't really say either; he pointed out (correctly) that for certain applications in a memory managed language, you'll want to essentially avoid using the GC, and you'll certainly have to be very cautious of it. The extreme case was old J2ME games, which usually worked by allocating all the memory they'd use as a large array at startup, and doing manual memory management thereafter. In general, you can do just about anything in a memory managed language, but in some cases, especially games, it may actually end up a lot more work than in a non-managed language.

spullara 13y ago
There are two performance choices in GC languages: 1) don't allocate after initialization 2) only allocate per small time frame There is an issue that 2) is only really feasible in server settings and doesn't really work for clients. I buy his argument even though I don't wish to program under his restrictions.