On Thu, Jul 10, 2014 at 1:55 PM, Matt Oliveri <[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. > > You're right, I didn't realize BitC was aiming to be any good for > prototyping. > Prototyping isn't a primary goal, but reducing the number of applications that end up in (e.g.) Perl because statically typed languages are a pain in the ass would be a good thing. > > 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. > > Are you saying _no one_ will understand the type system well enough to > write good types? I don't think so. It sounds like you want BitC to be > useful to people who don't know how to use it. > I'm saying that the empirical evidence is that humans aren't very good at writing complex types. I'm sure there are three people in the world who have total mastery of that. Those people are smart enough to design a language to suit themselves. The rest of us need one that works for *normal* folks. > > These two things become especially important when we start implementing > DSLs > > using mixfix, which should be wildly popular if we can get that right. > > That sort of thing has always seemed kludgy to me. I had a bad > experience trying to do a DSL with Java... Because Java doesn't have extensible syntax, you *can't* do a DSL in Java. But it's striking that the LINQ extensions to C# could almost entirely be handled by the mixfix engine in BitC v0. In fact, and somewhat disturbingly, it looks like most of the COBOL statement syntax can be embedded in BitC mixfix if you have a strong enough stomach. > But BitC already has a lot more annotation than, say, Haskell. It could > well > > turn out that our termination conditions are different as a result. > > Then it doesn't actually sound much good for prototyping. I don't think I agree. The main place where you have to annotate in BitC is structure and union type definitions, where you have to relate the field types to the constructor arguments. I *think* that if the field was generic, you still had to write the 'a on it in order to say which of the type constructor arguments went with which fields. It shouldn't be *that* hard to relax that requirement if needed. The main issue will then be that you still need to attach those 'a types when you need the types of two different fields to agree. Anonymous types, like tuples, also go a long way. The absence of these in Java, C++, C# is a hassle. I don't know. I've programmed fairly substantial things in *all* of these languages. Personally, I don't find the prototyping argument for dynamic typing to be very convincing. The more reasonable the generics syntax is, the less convincing it seems to become. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
