>
>Another reason that has not been stated is that C# is a interpreted language, which can be more portable than D, but due to it, C# can't be used for systems work, whereas D can, as it's compiled directly into machine code, with the obvious speed advantage it implies.
>
>
Yeah, C# is interpreted, but yet I haven't seen Microsoft make .NET for Macs, have they? Or Linux? They use that portability crap as marketing, when really almost everyone who uses .NET/C# are only worried about Windows developement.

And, so what if D isn't interpreted? It's faster when it's compiled, and if D is ever ported to other OSes, all you would have to do is recompile it on that new system.

Nick wrote:

> In article <cf00i1$bov$1@digitaldaemon.com>, Niko Korhonen says...
> 
>>A quick example:
>>
>># int x = 5;
>># func(x);
>>
>>Does func() change the value of x? You can't be sure. It's very unlikely, since POD types are passed by value and not reference. A programmer with a C or Java background will think it's very unlikely that x will change. But when it *does* change (the function was declared as void func(out int x)), you're in for a mighty surprise.
> 
> 
> I think it should be safe to assume that the programmer knows the definition of
> the function he/she is calling. When giving pointers in C you also "never know"
> whether the function is just reading the data (can't pass strings or large data
> structures without using pointers) or if it's altering it. Unless you actually
> RTFM ;-)

Even then, you never *really* know until you read the source code....

Lord Syl wrote:

> 
> Another reason that has not been stated is that C# is a interpreted language,
> which can be more portable than D, but due to it, C# can't be used for systems
> work, whereas D can, as it's compiled directly into machine code, with the
> obvious speed advantage it implies.


Actually, that's a misnomer.  The way the .NET stuff runs is that the
bytecode is delay-compiled.  IOW, it is fully compiled by the time the
user actually uses the code--but it is stored and distributed in a
platform neutral bytecode format.

Contrast this with Java hot spot which will compile hot spots based on
what is actually executed for a method.  That means that certain code
can actually get optimized out.  Same idea as above, but different
effect.

kinghajj wrote:

>>Another reason that has not been stated is that C# is a interpreted language,
>>which can be more portable than D, but due to it, C# can't be used for systems
>>work, whereas D can, as it's compiled directly into machine code, with the
>>obvious speed advantage it implies.
>>
>>
> 
> Yeah, C# is interpreted, but yet I haven't seen Microsoft make .NET for Macs,
> have they? Or Linux? They use that portability crap as marketing, when really
> almost everyone who uses .NET/C# are only worried about Windows developement.

The marketing machine for MS never leaves MS systems.  What they claim
is the "big win" is that VB programmers can use and extend classes
developed in C++, C#, F or some other .NET compatible language.  So it
is not necessarily cross-platform but cross-language.  I guess it is
how you define platform that matters. :/

> 
> And, so what if D isn't interpreted? It's faster when it's compiled, and if D is
> ever ported to other OSes, all you would have to do is recompile it on that new
> system.
> 
> 

In article <cf0a88$k98$1@digitaldaemon.com>, Lord Syl says...
>
>Another reason that has not been stated is that C# is a interpreted language, which can be more portable than D, but due to it, C# can't be used for systems work, whereas D can, as it's compiled directly into machine code, with the obvious speed advantage it implies.

C# isn't actually interpreted.  It's just that .NET applications typically live as CLI bytecode until needed.  Herb Sutter has been writing some interesting articles recently on the advantages and disadvantages of different execution methods.  All in all .NET is one of the better things MS has ever done.


Sean

Sean Kelly wrote:

> In article <cf0a88$k98$1@digitaldaemon.com>, Lord Syl says...
> 
>>Another reason that has not been stated is that C# is a interpreted language,
>>which can be more portable than D, but due to it, C# can't be used for systems
>>work, whereas D can, as it's compiled directly into machine code, with the
>>obvious speed advantage it implies.
> 
> 
> C# isn't actually interpreted.  It's just that .NET applications typically live
> as CLI bytecode until needed.  Herb Sutter has been writing some interesting
> articles recently on the advantages and disadvantages of different execution
> methods.  All in all .NET is one of the better things MS has ever done.

The really ironic thing is that a company with less influence could have never pulled it off.

Microsoft is abusing their monopoly to make software development better. :)

(and not just better on Windows, either.  Mono wouldn't have appeared if not for .NET.  Shame on you, Microsoft!!)

 -- andy

In article <cf0c4t$ldl$1@digitaldaemon.com>, kinghajj says...
>
>Yeah, C# is interpreted, but yet I haven't seen Microsoft make .NET for Macs, have they? Or Linux? They use that portability crap as marketing, when really almost everyone who uses .NET/C# are only worried about Windows developement.

By the way, last I heard MS *was* working on .NET for Linux.  But the popular consensus seems to be that it will be incomplete and inteded to allow folks to use web services and such.  As for the Mac... that will probably be up to Apple to take care of.

>And, so what if D isn't interpreted? It's faster when it's compiled, and if D is ever ported to other OSes, all you would have to do is recompile it on that new system.

There are really only a few advantages to .NET.  The greatest advantage for MS folks is that it replaces COM, MFC, and a host of other badly designed technologies.  Beyond that its only real advantage over compiled code is that it can be used for web services and the like, just like Java applets.  ie. stuff can run quite easily in a sandbox.  But the CLI is on its way to standardization so there's no reason that someone can't create a D/CLI compiler.  In fact it looks like someone's already working on that :)


Sean

"Sean Kelly" <sean@f4.ca> wrote in message news:cf0k9v$pt8$1@digitaldaemon.com...
> In article <cf0c4t$ldl$1@digitaldaemon.com>, kinghajj says...
> >
> >Yeah, C# is interpreted, but yet I haven't seen Microsoft make .NET for Macs, have they? Or Linux? They use that portability crap as marketing, when really almost everyone who uses .NET/C# are only worried about Windows developement.
>
> By the way, last I heard MS *was* working on .NET for Linux.  But the popular consensus seems to be that it will be incomplete and inteded to allow folks to use web services and such.  As for the Mac... that will probably be up to Apple to take care of.
>
> >And, so what if D isn't interpreted? It's faster when it's compiled, and if D is ever ported to other OSes, all you would have to do is recompile it on that new system.
>
> There are really only a few advantages to .NET.  The greatest advantage for MS folks is that it replaces COM, MFC, and a host of other badly designed technologies.  Beyond that its only real advantage over compiled code is that it can be used for web services and the like, just like Java applets.  ie. stuff can run quite easily in a sandbox.  But the CLI is on its way to standardization so there's no reason that someone can't create a D/CLI compiler.  In fact it looks like someone's already working on that :)

Just out of interest, what're your criticisms of COM?

In article <cf2f70$1pjs$1@digitaldaemon.com>, Matthew says...
>
>Just out of interest, what're your criticisms of COM?

Frankly, I haven't used it enough to offer a truly informed answer.  COM has just always seemed a terribly complex solution to the problems it was attempting to solve.  I'll admit, however, that a lot of my complaints about MS APIs stem from the fact that their use in C++ has always been a hundred times more complicated than in any other supported language, and usually expects the use of macros and such that really should not have been necessary (though I grant that getting rid of them may have resulted in slower code).  .NET may have a more complex back-end than MS' previous ideas, but its design is the cleanest they've produced.


Sean

Lord Syl wrote:
> Another reason that has not been stated is that C# is a interpreted language, which can be more portable than D, but due to it, C# can't be used for systems work, whereas D can, as it's compiled directly into machine code, with the obvious speed advantage it implies.

That's oversimplifying .NET a little too much.

C# is not an interpreted language, because every implementation of it I can think of _compiles_ it into CL.  VB.NET also compiles into CL.  J# also, Managed C++ also, etc.

CL (Common Language?) is somewhat "interpreted," but in the same way Java bytecode is "interpreted."  That is to say, at some point, it ends up running as native code.  This is a big contrast to true interpreted languages such as shell scripts, where each line is interpreted every time through.  (You can modify a shell script on the fly as long as you're careful about it, and the changes will take effect immediately.)

But nothing really says people couldn't make a C# compiler to 100% native code.  Just like there exist several compilers for compiling Java to 100% native code, the existence of the very same for C# or CL is almost a certainty as people will gradually get paranoid about the performance issues, just like they did with Java (and wrongly so.  GJC compiled Java code ends up running slower than the JVM could run it.  It only starts up much faster. :-))

A C# program compiled to native code would work for system programming just as well as any D program could.

Likewise, there also seem to be efforts to make an interpreted, or a .NET semi-interpreted version of D, so I'm not sure one can make a language comparison based on differences in two specific runtime implementations.

TX

-- 
             Email: Trejkaz Xaoza <trejkaz@xaoza.net>
          Web site: http://xaoza.net/trejkaz/
         Jabber ID: trejkaz@jabber.xaoza.net
   GPG Fingerprint: 9EEB 97D7 8F7B 7977 F39F  A62C B8C7 BC8B 037E EA73