On Mon, Jul 14, 2014 at 11:33 PM, Jonathan S. Shapiro <[email protected]> wrote:
> BitC isn't trying to be the last
> programming language ever,
That has always been clear, thanks.
> Right now, I personally have too many questions about dependent type to take
> a design risk on it. More precisely: the pressure to have something working
> to deal with other problems has become so urgent that I'm willing to defer
> dependent type as long as I can see a migration path for the future.
Honestly? A lot of things people are doing with dependent types seems
like a fad. Dependent types are not a fad, but the way they're being
half-assedly applied to programming probably is. Or worse, a
historical accident. It really feels like I somehow got a "dependent
types fan" sign stuck on my back. Dependent types were an important
theoretical advance that deepens our understanding of type systems.
It's too early to say how they'll become practical, or if they will.
Remember, I was the "don't bother" guy about future-proofing for
dependent type systems.
The thing I think you'll end up migrating to is more like what I have
in mind, where BitC would be a library for an extensible language.
Luckily you don't have to plan for that at all. ("Luckily" is kind of
joking. The ease of accommodating extensions would be deliberate.) (No
I'm not saying BitC should be that system. I never was. Geoffrey and I
started a thread about it because you asked us to.)
>> On Mon, Jul 14, 2014 at 12:22 PM, Jonathan S. Shapiro <[email protected]>
>> wrote:
>> > Matt: BitC isn't a research effort. It's a tool we desperately need for
>> > some
>> > things we need to build. It's an explicit goal to minimize research in
>> > BitC,
>> > except where research is required to solve an immediate problem.
>>
>> You are right. But a desperate need to avoid losing money is the kind
>> of thing I meant. It would explain why you are averse to design
>> possibilities that are not yet well understood. (That is, they require
>> too much research.)
>
> Matt: BitC isn't a research project and never really was. It's a response to
> a desperate and urgent production need. We (both the project and the nation)
> simply don't have the time to wait while we find a perfect solution.
Yes, you said something very similar to that just earlier. I was
acknowledging that you answered the question I should've asked, where
I wouldn't have said "stopgap".
> If we
> can get a substantially working system moved into BitC it should be
> relatively easy to migrate into future systems-capable languages. That is
> decidedly not true of code that is captive in C++ today.
OK. This is something that I _can_ trust your experience on. But
that's a big "if". It's the "if" that I'm questioning because I'm
concerned about incompleteness.
> The world doesn't move in leaps. It moves in steps.
I wish you hadn't said that. I disagree with the general statement
that there are no leaps forward, but it isn't really relevant because
that doesn't preclude smaller steps forward. (Oops, I assumed you
meant forward. :))
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
