2011/1/20 Jonathan S. Shapiro <[email protected]>: > I want to pose another question. I truly don't know the "right" answer! > > When we started the BitC work, we were strongly focused on verification. > This led to a bias: given that we were dealing with stateful codes, we > nonetheless wanted to "exploit" the capacity for pure sub-programs as a way > to reduce the analysis load. Eventually, we came to the conclusion that > verification has bounded utility, and that for broad purposes type-safety is > more important than verifiability. > > At the moment, the problem of mixing pure and stateful sub-programs is > standing out as a deep problem. I find that I am caught between conflicting > goals: > > 1. Get an ([artial) advance in the state of the art/practice into the field. > 2. Solve the big problem. > > Of the two, my personal bias is in favor of [1]. > > So here is a (value laden) way of stating the question: > > If BitC, in it's v1 form, gave up on "pure" programming, but leaves the door > open to integration of pure [sub]programming in v2, how many of you would no > longer be interested?
I think that the libraries written in v1 will probably shape the overall aspect of the language, how it feels. Writing portions of 'pure' code in middle of a stateful program helps one to reason about it, but it would be less useful if it wasn't a first-class feature, properly supported both by code and by people. I want that libraries use it properly too, and the more it is deferred, the less likely is that. Overall, the important isn't to pack a lot of useful features, but to draw a coherent, usable language. The language has to be intuitive for whoever will use it; in order to be used effectively, this separation of pure and impure code must not only be obvious, but widely expected by the programmers themselves. Language design is more like the craft of Python folks, not C++ folks, if you understand me :P in the sense that adding proper support for pureness isn't just features at the code, but mostly setting up standards for programmers to follow. So don't expect to add a lot of cool features in v2 (and still have an usable language), but maybe to remove the ones that didn't work.. (The other side is that if pureness is going to be half-baked, it shouldn't be there at all) I'm saying that because I think the same thing happened with OCaml. The "o" at OCaml comes from its object model, that is both powerful and easy to use - but it isn't really used by practically every program! All libraries that use it needs to provide an alternative interface, because it is so foreign for the majority of OCaml code. OO was an afterthought, maybe added after Caml Light already had a community - nobody really picked it up. OCaml objects could solve a lot little problems - if only they were used.. I contrast this with Haskell type classes: I don't know if Haskell was there for a while without it, but most people (and most code) was written after it was established. So it helped to set out some standard way of doing things, and all Haskell code will follow that. (This is seems to not be the case for Applicative, Functor and Arrow, but at least the typeclass mindset is already established) But well, if it will untie the Gordian knot, so do it :P > I personally believe that there is real value in a stateful, strongly-typed > programming language with high performance. It's considerably less than I > initially sought. While I believe the dichotomies can be solved, time is > money, and I'm trying to prioritize attention. If it can really deliver what C can deliver, you may need no more, it would be very useful as is. But I confess that most BitC issues (such as possibility of running with no GC, and the whole discussion about boxing) are a bit foreign to me. Properly separating pure code from impure code draw my attention; I would be satisfied with an overly conservative approach, of just not letting pure code call any impure code. The idea of having pure code that can call impure code as its inner working seemed very neat, and useful to have. I couldn't really understand how that would work, though _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
