On Monday, July 14, 2014, Matt Oliveri <[email protected]> wrote: > On Mon, Jul 14, 2014 at 12:22 PM, Jonathan S. Shapiro <[email protected] > <javascript:;>> wrote: > >> 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. > > A whole operating system, or just the kernel? It may be that I thought > it used to just be intended for a kernel, which would be how I got > confused.
A whole operating system. > > >> 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. > > Sorry, stopgap is a loaded term. Almost every technology is eventually > replaced. Sure. So let me be clearer. BitC may be superseded or may evolve as the practical use of dependent type evolves, but my assumption is that it will have a 40+ year life if it succeeds. Inevitably there will emerge other languages during that time. If BitC is able to show things that come to be taken for granted, that's great. BitC isn't trying to be the last programming language ever, and it won't be. Right now, I personally have too many questions about dependent type to take a design risk on it. More precisely: the pressure to have something working to deal with other problems has become so urgent that I'm willing to defer dependent type as long as I can see a migration path for the future. Even as things stand right now, we're a year away (probably two) from a production-capable BitC compiler. That's longer than we can afford to wait, and there is no current safe language that can successfully do what we need. > > > 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. > > You are right. But a desperate need to avoid losing money is the kind > of thing I meant. It would explain why you are averse to design > possibilities that are not yet well understood. (That is, they require > too much research.) Matt: BitC isn't a research project and never really was. It's a response to a desperate and urgent production need. We (both the project and the nation) simply don't have the time to wait while we find a perfect solution. If we can get a substantially working system moved into BitC it should be relatively easy to migrate into future systems-capable languages. That is decidedly not true of code that is captive in C++ today. The world doesn't move in leaps. It moves in steps. Shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
