On Mon, Apr 16, 2012 at 4:33 AM, David Jeske <[email protected]> wrote:
> Of course we can't speak for Shap... > Why not? You are entirely welcome to take my name in vain, just so long as you shall have no other gods before me. :-) Okay. I admit it. I'm punchy this morning. No idea why. > 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. > I more or less agree. One thing I would like to see is a successor to CIL that provides for regions and parametric types, and maybe for "shape types" (which I need to explain). > 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. > But you yourself note that C is essentially asm with human syntax. I think there are a bunch of reasons people turn to C: - Maybe I'm writing something that is dependent on an existing library in C (e.g. OpenSSL) - Maybe I need decent I/O performance, and safety is pushing me into data copies that I can't afford to do. Biagioni's work on TCP in ML is instructive here. Foxnet is painted as a success, but actually it's pretty depressing. - Maybe my app warm-up time matters (so JIT gets in the way). This was the main issue for in-transaction database servlets - Maybe pause times worry me - Maybe the problem of debugging inadvertently retained storage was too hard - Maybe I just don't know any better - Maybe I care about performance, therefore about memory placement, and therefore need a rich system for unboxed types - Maybe Brian, Dennis, and Bjarne are/were my colleagues (okay, that one applies to fewer and fewer of us, but still) - Maybe I'm a tea drinker - Maybe the *physical* heap footprint of my app matters. Either I can't afford 10x the memory initially, or I'm operating at a scale where I can't afford to *cool* 10x the memory. That's why Google can't use some of this stuff. - Maybe I care about security and modularity, and I've worked out that taming the Java standard library is utterly hopeless. All I'm saying here is that GC is just one of *several* issues that are getting in the way of safety adoption shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
