OT: on IDEs and code writing on steroids

[Yigal Chripun]

BCS wrote:
>> 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.

C# has a different compilation model which is what I was saying all 
along. However I disagree with your assertion that this model is bad.
It makes much more sense than the C++/D model. the idea here is that 
each self contained sub-component is compiled by itself. this self 
contained component might as well be a single file, nothing in the above 
prevents this.
consider a project with 100 files where you have one specific feature 
implemented by 4 tightly coupled classes which you put in separate 
files. each of the files depends on the rest. what's the best compiling 
strategy here?
if you compile each file separately than you parse all 4 files for each 
object file which is completely redundant and makes little sense since 
you'll need to recompile all of them anyway because of their dependencies.


> 
> 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 use of the term IDE here is a loose one. let me rephrase:
yes, Re-sharper is a plugin for VS. without it VS provides just 
text-editing features and I don't consider it an IDE like eclipse is.
Re-sharper provides all the features of a real IDE for VS. so, while 
it's "just" a plugin, it's more important than VS itself.

> 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.
> 
> --------------

What I was saying was not specific for DWT but rather that _any_ 
reasonably big project will use such a system and it's simply not 
practical to do otherwise. how would you handle a project with a hundred 
  files that takes 30 min. to compile without any tool whatsoever except 
the compiler itself?

> 
> 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.
> 
> 
your points are skewed IMO.
 > - support projects that need no external meta data
this is only practical for small projects and that works the same way in 
both languages.

 > - produce monolithic OS native binary executables
that is unrelated to our topic. Yes .Net uses byte-code and not native 
executables. I never said I want this aspect to be brought to D.
 > - work with the only language aware tool being the compiler
again, only practical for small-mid projects in both languages.


just to clarify: you _can_ compile C# files one at a time just like you 
would with C or D, and the is an output format for that that is not an 
assembly.