OT: on IDEs and code writing on steroids

[Nick Sabalausky]

"Bill Baxter" <wbaxter at gmail.com> wrote in message 
news:mailman.151.1242855932.13405.digitalmars-d at puremagic.com...
> On Wed, May 20, 2009 at 1:09 PM, Andrei Alexandrescu
> <SeeWebsiteForEmail at erdani.org> wrote:
>> Yigal Chripun wrote:
>>>
>>> I think you miss the point here.
>>> Generics and code generation are two separate and orthogonal features 
>>> that
>>> where conflated together by C++.
>>
>> It's kind of odd, then, that for example the Generative Programming book
>> (http://www.generative-programming.org) chose to treat the two notions in
>> conjunction.
>
> Yeh, there's definitely a overlap.  Orthogonal isn't quite the right word 
> there.
>
> I'm reading a bit on C++/CLI right now, which is C++ extended to
> inter-operate with CLR.
> C++/CLI has *both* classic C++ templates and CLR generics:
>
>  template<typename T> ...    // all code specializations generated at
> compile-time (if at all)
>  generic<typename T> ... // code generated at compiletime
> unconditionally, specialized at run-time.
>
> I'm not clear on exactly what happens at runtime in the generic<>
> case.  I had been thinking it was simply that the compiler does some
> type checking at compile time and the VM code then just manipulates
> pointers to Object from there.  That may be what happens in Java
> generics, but in CLR generics at least you can specialize on
> non-Object value types and that apparently does not result in
> everything getting boxed.  So it seems like there's a little something
> extra going on.
>
> I think the main reason for having Generics is that they're the best
> anyone currently knows how to do at the IL bytecode level.  Generics
> give you a way to define generic parameterized types that work across
> all the languages that target a given VM's bytecode.  But that doesn't
> preclude any language that targets that VM from *also* implementing
> compile-time templates, or code generators, or AST macros at the
> source code level.
>
> But the problem with source-level code generation is that you then
> need the source code in order to use the library.  I think they were
> trying to avoid that with C#.   If you have a compiled C# assembly,
> then you have everything you need to use it.   Period.   (I think.)
> At any rate, a tech that requires inclusion of source code is not very
> interesting to Microsoft, because Microsoft doesn't generally like to
> let people see their source code in the first place, and they know
> that many of their biggest customers don't like to either.  They're
> nervous enough about just putting de-compileable bytecode out there.
>

Maybe this is naive, but what about an AST-level template/generic? Couldn't 
that provide for the best of both worlds?

For instance, suppose (purely hypothetically) that the .NET assembly system 
were changed to allow the source for a D/C++ style of source-level template 
to be embedded into the assembly. Then they'd be able to do D/C++ style 
source-level template/code-generation. Right? Now obviously the big problem 
with that is it would only be usable in the same language it was originally 
written in. So, instead of getting that cross-language support by going all 
the way down to the IL bytecode level to implement generics (which, as you 
said, would somehow prevent the flexibility that the D/C++ style enjoys) 
suppose it only went down as far as a language-agnostic AST?

I suppose that might make reverse-engineering easier which MS might not 
like, but I'm not suggesting this as something that MS should like or should 
even do, but rather suggesting it as (business issues completely aside) 
something that would possibly gain the benefits of both styles.