OT: on IDEs and code writing on steroids

[Yigal Chripun]

BCS wrote:
> 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
> 
it's as much an implementation detail in D as it is in C#. nothing 
prevents you to create your own compiler for C# as well.

> [*] 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.

sounds like an interesting idea - basically your compiler will generate 
the meta data just as an IDE does for C#.
> 
>> 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).

you miss a critical issue here: DSSS/rebuild/etc can mostly be used 
without a config file _because_ they embed the DMDFE which generates 
that information (dependencies) for them. There is no conceptual 
difference between that and using an IDE. you just moved some 
functionality from the IDE to the build tool.
both need to parse the code to get the dependencies.

> 
>>> 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.
> 
> 
you're right that we will not converge on this. you only concentrate on 
the monolithic executable case and ignore the fact that in real life 
projects the common case is to have sub-components, be it Java jars, C# 
assemblies, C/C++ dll/so/a or D DDLs.
in any of those cases you sstill need to manage the sub components and 
their dependencies.
one of the reasons for "dll hell" is because c/c++ do not handle this 
properly and that's what Java and .net and DDL try to solve. the 
dependency is already there for external tools to manage this complexity.