[bitc-dev] Retrospective Thoughts on BitC
Matt Oliveri
atmacen at gmail.com
Mon Apr 16 05:35:30 PDT 2012
You're welcome. Some more specific responses below.
On Mon, Apr 16, 2012 at 7:33 AM, David Jeske <davidj at gmail.com> 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 <atmacen at gmail.com> 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.
More information about the bitc-dev
mailing list