OT: on IDEs and code writing on steroids

[BCS]

Reply to Yigal,

> BCS wrote:
> 
>> minor point; I said you have to give the compiler all the source
>> files. You might not actually nned to compile them all, but without
>> some external meta data, it still needs to be handled the full
>> because it can't find them on it's own. And at that point you might
>> as well compile them anyway.
>> 

(BTW: that is only referring to c#)

> you are only considering small hobby projects. that's not true for big
> projects where you do not want to build all at once. Think of DWT for
> instance. besides, you do NOT need to provide all sources, not even
> just for partially processing them to find the symbols.
> there is no difference between C#'s /r <someAssembly> and GCC's -l<lib>
> I don't think you fully understand the C# compilation model -
>
> in C# you almost never compile each source file separately, rather you
> compile a bunch of sources into an assembly all at once and you provide
> the list of other assemblies your code depends on. so the dependency is
> on the package level rather than on the file level. this make so much
> more sense since each assembly is a self contained unit of
> functionality.

That is more or less what I thought it was. Also, that indicates that the 
design of c# assumes a build model that I think is a bad idea; the "big dumb 
all or nothing build" where a sub part of a program is either up to date, 
or rebuilt by recompiling everything in it.

>>> >>> where in all of that, do you see any contradiction to what I said?
>>> again, I said the D compilation model is ancient legacy and should
>>> be replaced and that has nothing to do with the format you prefer
>>> for your build scripts.
>>> 
>> I think that you think I'm saying something other than what I'm
>> trying to say. I'm struggling to make my argument clear but can't
>> seem to put it in words. My thesis is that, in effect, C# is married
>> to VS and that D is married only to the compiler.
>> 
> I understand your thesis and disagree with it. what i'm saying is that
> not only C# is NOT married to VS but also that VS isn't even the best
> IDE for C#.

Maybe I should have said it's married to having *an IDE*, it's just VS by 
default and design.

> VS is just a fancy text-editor with lots of bells and
> whistles. if you want a real IDE for C# you'd probably use Re-Sharper
> or a similar offering.

Last I heard Re-Sharper is a VS plugin, not an IDE in it's own right, and 
even if that has changed, it's still an IDE. Even so, my point is Any IDE 
vs. No IDE, so it dosn't address my point.

>> My argument is that a D project can be done as nothing but a
>> collection of .d files with no extra project files of any kind. In c#
>> this is theoretically possible, but from any practical standpoint
>> it's not going to be done. There is going to be some extra files that
>> list, in some form, extra information the compiler needs to resolve
>> symbols and figure out where to look for stuff. In any practical
>> environment this extra bit that c# more or less forces you to have
>> (and the D doesn't) will be maintain by some sort of IDE.
>> 
> this is wrong. you cannot have a big project based solely on .d files.
> look at DWT as an example. no matter what tool you use, let's say DSSS,
> it still has a config file of some sort which contains that additional
> meta-data.

So DWT depends on DSSS's meta data. That's a design choice of DWT not D. 
What I'm asserting that that C# projects depending on meta data is a design 
choice of C# not the project. D project can (even if some don't) be practically 
designed so that they don't need that meta data where as, I will assert, 
C# projects, for practical purposes, can't do away with it.

--------------

I'm fine with any build system you want to have implemented as long as a 
tool stack can still be built that works like the current one. That is that 
it can practically:

- support projects that need no external meta data
- produce monolithic OS native binary executables
- work with the only language aware tool being the compiler

I don't expect it to requiter that projects be done that way and I wouldn't 
take any issue if a tool stack were built that didn't fit that list. What 
I /would/ take issue with is the the language (okay, or DMD in particular) 
were altered to the point that one or more of those *couldn't* be done.