OT: on IDEs and code writing on steroids

[grauzone]

Yigal Chripun wrote:
> 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.

Just because it doesn't work on your shitty (SCNR) platform, it doesn't 
mean it's wrong. On Unix, there's a single ABI for C, and linking Just 
Works (TM).

But I kind of agree. The most useful thing about compiling each module 
to an object file is to enable separate compilation. But this is 
useless: it doesn't work because of bugs, it doesn't "scale" (because a 
single module is likely to have way too many transitive dependencies).

> I'm not suggesting coping Java's model letter for letter or using a VM 
> either, but rather using a better representation.

Ew, that's even worse. Java's model is right out retarded.

I'd just compile a D project to a single (classic) object file. That 
would preserve C compatibility. Because the compiler knows _all_ D 
modules at compilation, we could enable some spiffy stuff, like virtual 
template functions or inter-procedural optimization.