On Sun, Jul 13, 2014 at 1:46 PM, Matt Oliveri <[email protected]> wrote:
> On Sun, Jul 13, 2014 at 12:49 PM, Jonathan S. Shapiro <[email protected]> > wrote: > > One of the challenges I'm facing is that BitC isn't a project in > isolation. > > There's other stuff riding on it, so it needs to be done, and there's a > > limit to how much energy I can put into options that don't serve needs > that > > are immediately clear here. Dependent types may not make the cut given > the > > urgency of the need. > > I forgot about that. Or rather, I thought the scope of BitC expanded > at some point. The scope of BitC has not expanded. > What is the urgent need BitC is addressing, and how are > you ensuring that it actually addresses it? Not something I am discussing publicly, but it's been said that we need an operating system done in a safe language. > Does it need to be more than a stopgap? Yes. We anticipate committing millions of lines of code to BitC in relatively short order. Once that's done we'll be living in BitC for a long time. > If BitC is deliberately a stopgap, then I suddenly > understand where you're coming from better. No, you don't. Once again, be careful about the difference between what you assume and what you know. It isn't about whether BitC is a stopgap. It's about how many thousand dollars are being lost for every day that BitC being unavailable is delaying other things. Matt: BitC isn't a research effort. It's a tool we desperately need for some things we need to build. It's an explicit goal to *minimize* research in BitC, except where research is required to solve an immediate problem. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
