OT: on IDEs and code writing on steroids

[dsimcha]

== Quote from Jarrett Billingsley (jarrett.billingsley at gmail.com)'s article
> On Sun, May 17, 2009 at 7:15 PM, BCS <none at anon.com> wrote:
> >> second, D needs to update its stone age compilation model copied from
> >> C++. I'm not saying we need to copy the C# or Java models exactly, but
> >> we need to throw away the current legacy model.
> >> Java has convenient Jar files: you can package everything into nice
> >> modular packages with optional source code and documentation.
> >> similar stuff is done in .net.
> >
> > NO ABSOLUTELY NOT! (and I will /not/ apologies for yelling) I will fight
> > that tooth and nail!
> >
> > One of the best thing about D IMNSHO is that a D program is "just a
> > collection of text files". I can, without any special tools, dive in an view
> > or edit any file I want. I can build with nothing but dmd and a command
> > line. I can use the the source control system of my choice. And very
> > importantly, the normal build model produces a stand alone OS native
> > executable.
> I don't think changing from a decades-old 'one object file per source
> file' compilation model will make you sacrifice any of that.  He's
> proposing something else, like a custom object format.  It has nothing
> to do with the way source is stored, or with how you invoke the
> compiler.  Java hasn't destroyed any of that by using .class files,
> has it?
> We already have a proof-of-concept of this sort of thing for D: LDC.
> The LLVM intermediate form is far more amenable to cross-module and
> link-time optimization.

And how about certain metaprogramming things that are otherwise infeasible?  To
me, the lack of ability to use templates to add virtual functions to classes seems
like a pretty severe leak of D's compilation model into higher levels of
abstraction.  The same can be said for the lack of ability to get information
about classes that inherit from a given class via compile time reflection.  Change
the compilation model to something that is modern and designed with these things
in mind and the problem goes away.

As an example use case, a few months back, I wrote a deep copy template that would
generate functions to deep copy anything you threw at it using only compile time
reflection and a little bit of RTTI.  The only problem is that, because I could
not get information about derived classes at compile time, I couldn't make it work
with classes whose runtime type was a subtype of the compile time type of the
reference.