OT: on IDEs and code writing on steroids

[BCS]

Reply to Yigal,

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

All of the above is (as far as D goes) an implementation detail[*]. What 
I'm railing on is that in c# 1) you have no option BUT to do it that way 
and 2) the only practical way to build is from a config file

[*] I am working very slowly on building a compiler and am thinking of building 
it so that along with object files, it generates "public export" (.pe) files 
that have a binary version of the public interface for the module. I'd set 
it up so that the compiler never parses more than one file per process. If 
you pass it more, it forks and when it runs into imports, it loads the .pe 
files after, if needed, forking off a process to generating it.

> without it VS provides just
> text-editing features and I don't consider it an IDE like eclipse is.

The IDE features I don't want the language to depend on are in VS so this 
whole side line is un-important.

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

I assert that the above is false because...

> 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 didn't say that the only tool you can use is the compiler. I'm fine with 
bud/DSSS/rebuild being used. What I don't want, is a language that effectively 
_requiters_ that some config file be maintained along with the code files. 
I suspect that the bulk of pure D projects (including large ones) /could/ 
have been written so that they didn't need a dsss.conf file and many of those 
that do have a dsss.conf, I'd almost bet can be handed without it. IIRC, 
all that DSSS really needs is what file to start with (where as c# needs 
to be handed the full file list at some point).

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

As I said, I think this is false.

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

Mostly I'm interested in the monolithic bit (no DLL hell!) but I was just 
pulling out my laundry list.

>> - work with the only language aware tool being the compiler
>> 
> again, only practical for small-mid projects in both languages.

ditto the point on 1

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

I think we won't converge on this.

I think I'm seeing a tools dependency issue that I don't like in the design 
of C# that I _known_ I'm not seeing in D. You think that D is already just 
as dependent on the tools and don't see that as an issue.

One of the major attractions for me to DMD is its build model so I tend to 
be very conservative and resistant to change on this point.