OT: on IDEs and code writing on steroids

[BCS]

Hello Yigal,

> BCS wrote:
> 
>> Hello Yigal,
>> 
>>> 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.
>> (Note: the above reasons applies to a pure D app, as for non pure D
>> apps, your toast anyway as D or the other language will have to fit in
>> the opposite language's model and something will always leak. The best
>> bet in that system is the simplest system possible and that to is "just
>> text files".
>
> hmm. that is *not* what I was suggesting.
> I was discussing the compilation model and the object file problems.
> D promises link-time compatibility with C but that's bullshit - you
> can't link on windows obj files for C and object files for D _unless_
> you use the same compiler vendor (DMD & DMC) or you use some
> conversion tool and that doesn't always work.

aside from the CGG stack I'm not sure anyone can in general. But this is 
getting to be a minor point as VS/GCC are the only compilers I've ever seen 
used on on windows.

> one other thing, this thread discusses also the VS project files. This
> is completely irrelevant. those XML files are VS specific and their
> complexity is MS' problem. Nothing prevents a developer from using
> different build tools like make, rake or scons with their C# sources
> since VS comes with a command line compiler. the issue is not the
> build tool but rather the compilation model itself.

I think you are in error here as the c# files don't contain enough information 
for the compiler to know where to resolve symbols. You might be able to get 
away with throwing every single .cs/.dll/whatever file in the project at 
the compiler all at once. (Now if you want to talk about archaic!) Aside 
from that, how can it find meta-data for your types?