D vs. C#

[Vladimir Panteleev]

On Tue, 23 Oct 2007 00:56:28 +0300, Walter Bright <newshound1 at digitalmars.com> wrote:

> Vladimir Panteleev wrote:
>> On Mon, 22 Oct 2007 21:19:30 +0300, Walter Bright
>> <newshound1 at digitalmars.com> wrote:
>>
>>> 3) gigantic runtimes needed
>>
>> IMO it's better to have one copy of a gigantic runtime than having
>> parts of it statically linked in every EXE, causing lots of repeating
>> code in a product with lots of binaries (such as an operating
>> system). .NET executables are much smaller compared to most native
>> executables (where the runtime is statically linked) - so, knowing
>> that .NET will only gain more popularity in the future, I find a
>> one-time 20MB download preferred to re-downloading the same
>> components with every new program. Now that Microsoft is including it
>> in their new operating systems, Vista users will just benefit from a
>> smaller download size.
>
> This problem is addressed by DLLs (Windows) and shared libraries (Linux).

Except, they're not really as easy to use.

With .NET, you can derive from a class in a compiled assembly without having access to the source. You just add the assembly in the project's dependencies and import the namespace with "using". In C, you must use the included .h files (and .h files are a pain to maintain anyway since you must maintain the declaration and implementation separately, but that's not news to you). You must still use .lib and .di files with D and such - although they can be automated in the build process, it's still a hassle. 

Besides that, statically linking in the runtime seems to be a too common practice, as "DLL hell" has been a discouragement for dynamically-linked libraries in the past (side-by-side assemblies is supposed to remedy that though). I guess the fault is not in the DLLs themselves, it's how people and Microsoft used them... 

-- 
Best regards,
 Vladimir                          mailto:thecybershadow at gmail.com