On Thu, Aug 22, 2013 at 4:37 AM, Matt Rice <[email protected]> wrote:
> except it's more like you can start from scratch, and you can start > from an existing system in order to delay starting from scratch into > the future to reduce the initial overhead. I don't understand how this > jumps to continuing to evolve common language runtimes, when that adds > overhead onto a system that will be replaced, and where any non bitc > component in the system self defeats, unless we are talking about reducing > the amount of shoehorn overhead... > IMO, this perspective is over-weighting code-execution-shoehorn overhead vs developer productivity-shoehorn-overhead. Really there are three choices here: 1) Own an operating system like Microsoft, Google, or Apple. Create your own runtime. Enjoy thriving developer support that comes from developers trying to reach the audience. 2) Build an independent language and either live-on or tightly couple with one or all of the existing systems runtimes. 3) Make an independent runtime, score top-benchmarks in some irrelevant programming language shootout. Have too little system library support to use for anything except generating streams of strings (aka server side web programming), or embedded use with very constrained libraries. Personally I think there is more room for finding a better optimization of execution-and-productivity shoehorn down path #2. IMO, the JVM world has already shown it's much easier to adopt languages based on JVM, and superset JVM runtimes, than it is to adopt independent systems. CLR just happens to have more features conducive to systems programming. However, this is all academic at this point. Today these comments can be interpreted as support for Shap's decision to use CLR as a temporary target. When bitc-the-second is usable on CLR, it can be interpreted as encouragement to attempt a CLR-superset, rather than abandon the CLR community ecosystem entirely.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
