On Sun, Jul 13, 2014 at 2:21 PM, Matt Oliveri <[email protected]> wrote:
> I am frustrated. > > I feel bad for the future BitC programmer who will write 90% of a > strongly-typed program, only to discover that the remaining 10% is > inexpressible... Do you have a concrete example, or is this an exercise in fantasy? In any case, I think you're using the wrong term. You mean "advanced", not "strong". Advanced type systems don't render programs less expressible. They render programs *more* expressible. At the cost of more complex types. Strong type systems cannot be worked around by weakening the types. If that were possible, they wouldn't be strong type systems. Please give an example of something that you think cannot be expressed, and explain what you imagine is missing in BitC to address it. I think you are engaged once again in unfounded assumptions that need to be turned into questions we can look at. > My fear is you are either going to get terrifically lucky, or you are > going to make another strongly-typed toy that provides no practical > benefit because no one can hope to predict whether a program will > exist with a strong type. > I guess we'll just have to see. > I'm sorry for venting my philosophy on your nice list again. Maybe I > should disappear for another two years. Good luck engineering the > right system for your urgent need, even if it does end up being a crap > shoot for anything else. Matt, I don't mind you expressing your concerns or your philosophy, though you really do need to learn how to differentiate assumptions from facts. I *do* mind when you characterize something I've been looking at for over a decade, vetted against real-world, carefully worked examples of real code, as a "crap shoot" because it doesn't meet your unspecified objectives for a single feature. You are insinuating that I'm going completely on guesswork, and that I haven't done the homework to know what BitC needs. I find this especially inappropriate when you bring out hypothetical objections without examples that might allow us to evaluate, examine, and discuss your concerns. Perhaps you forget that BitC and Coyotos were co-designed exactly so that we could match the language to the real-world need. I know *exactly* where strong typing breaks down. Do you? You may not realize that this isn't my first compiler or even my first language design. Or that having written the very first book on reusable programming in C++ back in the day I may have spent some time looking at language usability. Or that I've built world-class debuggers (the DWARF 1.0 and 2.0 specifications were done in my groups). Or that the reason we're looking at BitC v2 is that *experience* revealed flaws in v1. I don't claim anything remotely like perfect knowledge. That's why this list exists, and I learn a *lot* here every day. What I *do* claim is that I have experience that lets me look at this from a lot of relevant perspectives and try to balance them. Others here do too, and I listen. BitC *is* a "crap shoot". But the crap shoot concerns uptake, not type systems. The type system that we have *right now* is a huge advance over what is being used in the systems space. In order to succeed, BitC has to thread a lot of needles at the same time. Type systems are just one of them. I hope you'll stick around. But it would really be helpful if you might work a little harder to turn your concerns into concrete examples that we can look at and talk about constructively. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
