On Thu, Jul 10, 2014 at 12:59 PM, Jonathan S. Shapiro <[email protected]> wrote:
> For the most part, the big advantage of Python/Perl/etc. for prototyping > is brevity: there's lots of stuff you don't have to write or think about. > Type inference spans most of that gap, and I think it will be important to > acceptance that BitC gives some of that prototyping feel. > I'm half with you here. The half that's a problem is that programs of non-trivial size quickly start to benefit from some form of type-documentation to be intelligible. I stopped enjoying python as much as I used to when I felt the need to start putting in Java/C# esq generic type specifics in comments because I would forget the structure of my own maps maps. There was something really wrong with writing all those type specifications into comments that the language just ignored. I've come to appreciate local inference (like C# var), but I'm pretty unsold on global inference that just silently works in the background. When I look at a method, I want to know what types validly fit there. Fully inference based systems can turn out pages of type-constraints about what fits there, but I've yet to see one with a succinct way of naming those things. In static typed languages, creating that finite set of names (aka types) does constrain the flexibility of the code, but it also raises the intelligibility. I believe there might be an ideal point closer to flexibility, but for me it isn't the point with zero names and 100% flexibility. > But the more important issue is that humans *can't* write static types > correctly. In today's systems, the types involved are complex enough that > when humans are asked to state them they come up with typings that are not > complete. > I'm interested to know what kind of examples come to mind for you when you say this. Certainly there is no language or type system which can solve human software modeling failures -- and this is what first comes to mind when I read your statement above. A less ambitious opportunity presenting itself is the battle between between "isa" and "implements". In the world of static compilation, we needed to use "isa" type constraints to get fast static dispatch. However, in the world of JITs like Hotspot, there is very little difference between depending on a type and depending on an interface. It seems sub-optimal that programmers must manually manage the separateness of interfaces. For example, why not allow every Java class to implicitly be an interface one can implement? AFAIK, Sather is one of the few static systems that ventured down this road. However, Apple Obj-C has made interface (protocol) only conformance much more popular recently.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
