You're welcome. Some more specific responses below. On Mon, Apr 16, 2012 at 7:33 AM, David Jeske <[email protected]> wrote: > Matt - Thanks for the very well-worded and clear response. Of course we > can't speak for Shap, but I can see those two well-reasoned perspectives > well in your explanation. I don't know if you anticipated this or not, but I > have one objection.. > > On Sun, Apr 15, 2012 at 10:56 PM, Matt Oliveri <[email protected]> wrote: >> >> If you want a typesafe runtime to replace C, then you are essentially >> saying we should write all programs on top of some fixed runtime. > > > Yes. That runtime would evolve over time, but yes. > >> >> In other words, as I see it, you are asking for compromise. >> But you have argued yourself that essentially people turn to C (live >> dangerously) when they find the compromise option to be unacceptable, >> currently because of GC pauses. > > > I object to this. I do not believe people turn to C to avoid compromise. If > so they would always turn to assembler. I believe they turn to C because it > offers an improvement in programmer productivity in exchange for a > linear-performance degregation.
Hmm, yeah I guess I overstated the point you argued. Sorry. > The problem with GC pausing is not that it is a compromise, that problem is > that it's non-linear. IMO, by eliminating this non-linearity, we would > provide a runtime which was strictly preferred in all but the most extreme > cases. (i.e. the same situations that turn to assembler today) I see. So it's specifically GC pauses you have a problem with. Yeah, I really don't think a typesafe, zero-pause GC'ed runtime would get rid of C by itself, but it sure would be nice. And if you're right about how it's the GC pauses holding back typesafe runtimes, then I wouldn't be at all surprised if almost all programs end up being written for a runtime like that. At any rate, I'm personally more interested in technologies that let programmers avoid performance compromises, so I don't know what else I can say. I'm glad my points were helpful. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
