On Sun, Sep 7, 2014 at 3:00 AM, Ben Kloosterman <[email protected]> wrote:
> Sorry to be contrarian .. but you did invite this with this subject line > :-) > Funny, I thought of it as a status report rather than an invitation. You're always welcome to move to greater Seattle and help. :-) I hadn't intended to invite criticism, but it's perfectly okay that you did. In fact, it's better to get things in the open (see below), so I'm actually glad you did. > On Sun, Sep 7, 2014 at 4:21 AM, Jonathan S. Shapiro <[email protected]> > wrote: > >> How would you go about that? Remember that we've already done a >> C++-hosted version of this compiler using YACC. >> > > That is very out of date version compared to some of the things that have > been discussed. > You might think so, but not so much. We validated a whole lot of stuff with that compiler. Most of what's being done now is a direct response to what we learned. > I was thinking get it self hosting first use yacc . Get yacc to create > bitc code instead of C IF it proves problematic and then keep improving. > Getting YACC (or more realistically Bison) to produce BitC code is a seriously non-trivial undertaking. Bison is fine for bringup if we are willing to do bringup in C or C++, but not really viable for anything else. Experience shows that bringup in C++ is an ugly business, partly because of non-translatable idioms and partly because we can't use GC. Regardless, we will *eventually* need a parser generator that produces BitC. > "*ad hoc* parse rules and/or parse ambiguities." are common in nearly > all languages - with good reason they have taken short cuts to get > something out the door. > >> >> For many languages that is so. *None* of those languages are languages >> that anyone has attempted to do regular formal reasoning about >> successfully. >> > > I can turn that around too :-) Are there any successful languages that > have done formal reasoning ? > Yes. But it doesn't matter. The desire to eventually do formal reasoning is one of the goals for BitC, so any development process that fails to support that is a non-starter. And incidentally, a lot of the algorithm work that I'm doing will eventually get picked up in our standard library. It's not wasted effort. > >> >>> Javascript and Linux are a great examples -our world is filled with >>> second rate products because the better ones never get finished. >>> >> >> Agreed. And if their approach had led to sufficiently survivable systems, >> we wouldn't be attempting to do BitC at all. But it didn't, did it? >> > > Javascript continues to grow and improve. C# and Java are very survivable > they just haven't done the lower level stuff - C# could have replaced a > lot of C if they had gone just a bit further in that direction. There are > other languages like Rust which may close the window ( though i think rust > is too hard to use for the average dev) ,and new ones are coming. > > C# ( like most) has had massive overhauls and safe set based operations > on LINQ have probably doubled the productivity of devs in the last few > years. > Show me how to write systems programs in any of these that we can reason about formally and I'll be happy to stop work on BitC and migrate. Remember that I have some experience trying to write systems code in C#... > >> It has left us with systems that are not just insecure, but *not >> securable in principal*. BitC is a step on the path to changing that. >> It's goals can't be met by making it up as we go along. >> > > I dont think the development approach has anything to do with security... > Then, respectfully, you don't know very much about how to develop secure software. Process *really* matters. > Perhaps you have the impression that the parser generator is what has been >> slowing me down. Actually, that's not true. There are a lot of other things >> going on here, and I'm not getting to spend a whole lot of time on BitC. I >> make progress as I can. >> > > > Yes i did have that impression.. I know you want a great design and you > have that .. I just want to see it in reality. > That's a valid concern, but just so it's out in the open, let me articulate the sources of delay: The main reason for lack of progress over the last three years has been a contested divorce followed by a very difficult custody battle. For reasons I won't go into publicly, a custody outcome that was even *marginally* worse than what I sought was not acceptable. Officially, the custody battle ended in April 2014, though a few lingering bits remain. Each time I have tried to sit down and work, I've gotten another legal document that needed my undivided attention. With all respect to the BitC hopefuls (including myself), my son's safety is more important. On the bright side, that's mostly over now. During that same time I transitioned from a diet-managed to an insulin-dependent diabetic. Transitioning to insulin is a slow, trial-and-error process because each patient is different. It's a slow process of discovery. Right now, there are a lot of days when I *could* work but my blood sugars make it very hard to focus. I expect that will cease to be an issue over the next two or three months, but until things stabilize it's hard to predict how much of my time is practically useful time. And over the last four to five months or so I've also been distracted by raising financial support for this effort and some others. If I can get some funding behind this, it will move a lot faster. There's a lot of this that I could hand off if there were someone to catch the pieces. So: your frustration is noted (and shared), but there has been a lot going on. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
