3 ms·

It's a solution for a different time: a time when the code was distributed, where it could theoretically run anywhere, and be installed from anywhere. In that

It's a solution for a different time: a time when the code was distributed, where it could theoretically run anywhere, and be installed from anywhere. In that world, distributing one "intermediate-VM blob" which was then compiled to native on the client made a lot of sense. Today, in the world of centralized app stores, there's an argument to be made for directly distributing compiled binaries as an optimization. It still makes sense to use an intermediate format as it allows the most compatibility (i.e. new hardware), but the app store itself could distribute binaries for known/supported handsets as an optimization (it wouldn't surprise me if it didn't already do this).

personZ 12y ago
By what possible perspective is that from "a different time"? Because Microsoft decided to distribute compiled .NET apps to Windows Phone? Is there some great advantage that Windows Phone gains from this? It certainly doesn't seem so. It's quite remarkable to read people talking about how insane this is, how it's a solution for a different time, etc, when it is working remarkably well (number of people complaining about on phone AOT/JIT time -- about 0. Number of people sure it must be some great issue -- too many). It seems to be a solution for this time.
- radicalbyte 12y ago
  > By what possible perspective is that from > "a different time"? Because Microsoft decided > to distribute compiled .NET apps to Windows Phone? When Dalvik would have been designed, there wouldn't have been an App Store. The model for mobile development wasn't clear like it is today. I agree that it's a great solution: the AOT cost is, in practice, tiny. The flexibility (and, I expect, reliability) provided is with the cost.