www.digitalmars.com         C & C++   DMDScript  

D - D and .NET

reply "J. Daniel Smith" <j_daniel_smith deja.com> writes:
As of today, .NET is no longer vaporware (actually, the gold bits have been
available to MSDN subscribers for a few weeks).

I don't know a lot about .NET or C# - just what I've read (or been
brainwashed with) in the various forums over the past several months.  But
it seems that - like it or not - .NET is the future on the Windows platform,
which is also the single largest platform for software development.
Currently, the D compiler itself is only available on Windows.  And there
are various projects underway to port .NET and the CLR to non-Windows
platforms (I'm sure Microsoft will eventually have to do it for at least the
Mac since it is a supported platform for the Office suite).

With that bit of lead-in, what about D and .NET?  There are some obvious
features provided by the CLR such as garbage collection that could be used
by the D compiler.  Making D a .NET language would also make it much easier
to interoperate with other .NET languages (and to a lesser extent COM)
leveraging things such as the new Windows Forms classes (the next generation
MFC/ATL) - obviating the need to do things like "port" the Win32 API to D.
I also see enough difference between D and C# to have both: D is much more
in the C/C++ tradition, while C# seems to be Microsoft's version of Java.

I don't know what it takes to write a .NET language - does the effort need
to be "blessed" by Microsoft?  I'm sure making it work in Visual Studio .NET
is a lot more effort than just a command-line version; but even being able
to use the various .NET development tools seems beneficial.  It also seems
like now is the time to move D in the .NET direction so that features can be
added/modified so that it works better in that environment; like C# there
are no legacy issues with D.

As a practical matter, I don't think D has much of a chance of becoming
mainstream unless it is a .NET language.  As a new language (on the Windows
platform), it is competing in some sense with C#, which, because of
Microsoft's backing already has a lot of mindshare (just look at all the C#
books that are available).  D has a lot of interesting features, but I don't
anticipate finding any books on D in the near future.

   Dan
Feb 13 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"J. Daniel Smith" <j_daniel_smith deja.com> wrote in message
news:a4e1ab$2c84$1 digitaldaemon.com...


 I don't know what it takes to write a .NET language - does the effort need
 to be "blessed" by Microsoft?  I'm sure making it work in Visual Studio




I believe you have to write a compiler for that new MS bytecode format...
is it an opened standard?


 is a lot more effort than just a command-line version; but even being able
 to use the various .NET development tools seems beneficial.  It also seems
 like now is the time to move D in the .NET direction so that features can




 added/modified so that it works better in that environment; like C# there
 are no legacy issues with D.

 As a practical matter, I don't think D has much of a chance of becoming
 mainstream unless it is a .NET language.  As a new language (on the




 platform), it is competing in some sense with C#, which, because of
 Microsoft's backing already has a lot of mindshare (just look at all the




 books that are available).  D has a lot of interesting features, but I




 anticipate finding any books on D in the near future.



I - personally - don't like the idea behind the .NET. I want my code to get
straight, compiled executables, able to run on any Win32 box. This new JIT
thingie is something that I definitely don't like. WinForms is better, but
it's COM - which is not the best solution to work with multiple compilers...
I'd prefer a C interface as well...
Feb 13 2002
next sibling parent reply "Richard Krehbiel" <rich kastle.com> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:a4eeia$2j25$1 digitaldaemon.com...

 "J. Daniel Smith" <j_daniel_smith deja.com> wrote in message
 news:a4e1ab$2c84$1 digitaldaemon.com...


 I don't know what it takes to write a .NET language - does the effort







 to be "blessed" by Microsoft?  I'm sure making it work in Visual Studio




 I believe you have to write a compiler for that new MS bytecode format...
 is it an opened standard?



Mostly.

For kicks, I keep an eye on the Mono project (http://www.go-mono.com), which
is bulding a clone of C# and the CLR (Common Language Runtime - .NET's
version of the Java JVM).


 I - personally - don't like the idea behind the .NET. I want my code to




 straight, compiled executables, able to run on any Win32 box. This new JIT
 thingie is something that I definitely don't like. WinForms is better, but
 it's COM - which is not the best solution to work with multiple




 I'd prefer a C interface as well...



.NET is *not* for every kind of program.  (Visual Studio .NET still includes
plain old C and C++ compilers, you know.)  .NET is for web-based computing
(but Java was there first).

(Web-based computing is client-server computing, with client code downloaded
just-in-time to the client box, over the Internet, from a server you may not
trust.  Shudder - everybody knows you don't run code from untrusted sources;
that's how viruses spread.  So the Java JVM and .NET CLR provide a
"sandboxed" virtual-machine, so that downloaded code can only do certain
safe things.  Microsoft found out that customers are too smart to download
machine code ActiveX objects, even if signed; so they copied Java and the
JVM, named them C# and CLR, and gave us .NET.  Wow - what amazing innovators
MS are.)

--
Richard Krehbiel, Arlington, VA, USA
rich kastle.com (work) or krehbiel3 comcast.net  (personal)
Feb 13 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Richard Krehbiel" <rich kastle.com> wrote in message
news:a4eh5h$2k7g$1 digitaldaemon.com...


 .NET is *not* for every kind of program.  (Visual Studio .NET still




 plain old C and C++ compilers, you know.)  .NET is for web-based computing
 (but Java was there first).



Yes, sure.


 (Web-based computing is client-server computing, with client code




 just-in-time to the client box, over the Internet, from a server you may




 trust.  Shudder - everybody knows you don't run code from untrusted




 that's how viruses spread.  So the Java JVM and .NET CLR provide a
 "sandboxed" virtual-machine, so that downloaded code can only do certain
 safe things.  Microsoft found out that customers are too smart to download
 machine code ActiveX objects, even if signed; so they copied Java and the
 JVM, named them C# and CLR, and gave us .NET.  Wow - what amazing




 MS are.)



That's why C# is not a competitor for D. C# is for web-related development.
D is for usual everyday routine coding. It can be fit into the .NET
paradigm,
yes, but does it worth the thing? C# is just enough...

On other hand, some ideas could be stolen from C# and used in D. For
example,
packaging types into objects, or delegates, or checked/unchecked blocks...
Feb 13 2002
next sibling parent reply "Walter" <walter digitalmars.com> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:a4eihn$2kpr$1 digitaldaemon.com...

 That's why C# is not a competitor for D. C# is for web-related




 D is for usual everyday routine coding. It can be fit into the .NET
 paradigm,
 yes, but does it worth the thing? C# is just enough...



D is meant for systems programming, C# is not. For example, D gives you
direct access to the Windows APIs. No need for wrappers and kludge dll's. D
even has inline assembler (coming soon!). D can build native executables. No
need to depend on Microsoft's CLR (or clones) and random changes in it.

Is it possible to write a .net version of D? I don't know. I suspect it
might be forced into being a D subset.

Back in the old days (!) I had no linker, and relied on the Microsoft
linker. Unfortunately, Microsoft produced version after version of the
linker, scores of them. Some of them worked, some didn't, some sort of
worked, etc. It was a nightmare. The solution was to do our own linker and
gain control over the process. I see the same problem with byte code VM's -
you're vulnerable to arbitrary changes/bugs in a VM over which you have no
control. An awful lot of development time can be sunk into
investigating/writing workarounds for bugs in VM version X.YY from company
Z.

You could argue that aren't I relying analogously to Intel keeping their
chips working? Sure. But Intel has a great track record of backwards
compatibility, the only speedbump there was the infamous Pentium FDIV bug,
for which a kludge workaround still lives in the compiler. Software VMs just
don't have that track record of reliability.

A great advantage Digital Mars has for a new language is a great optimizer
and code generator already existing for the Win32 platform, along with a
complete set of tools like linker, librarian, debugger, etc., ready to plug
in and go. There's nothing a CLR adds to that.

Is there a .net future for D? Probably yes. But not now. First thing is a
Win32 system. Then comes dfront. *Then* comes a CLR.
Feb 13 2002
next sibling parent reply "J. Daniel Smith" <j_daniel_smith deja.com> writes:
I'm glad to hear that you don't have anything against a .NET implementation
of D.  I can also appreciate the frustration of having to deal with changes
from Microsoft (I used to work for a company that had an implementation of
Win32 on various UNIX platforms - talk about dealing with lots of things
changing all the time).

I don't know what your goals are for D...but I think it would be nice if it
became a wide-spread language, it has some really neat things to offer the
ENTIRE programming community (at least ANY C/C++ developer).  However, I
don't think that's going to happen unless porting to the CLR becomes a
higher priority than dfront (and maybe even a Win32 system).  Personally, I
find things like real typedefs and support for design-by-contract a whole
lot more interesting than in-line assembly; it would be a shame if a
"systems programming" focus limited D's adoption.

   Dan

"Walter" <walter digitalmars.com> wrote in message
news:a4ejru$2ler$1 digitaldaemon.com...

 "Pavel Minayev" <evilone omen.ru> wrote in message
 news:a4eihn$2kpr$1 digitaldaemon.com...

 That's why C# is not a competitor for D. C# is for web-related




 D is for usual everyday routine coding. It can be fit into the .NET
 paradigm,
 yes, but does it worth the thing? C# is just enough...



 D is meant for systems programming, C# is not. For example, D gives you
 direct access to the Windows APIs. No need for wrappers and kludge dll's.




 even has inline assembler (coming soon!). D can build native executables.




 need to depend on Microsoft's CLR (or clones) and random changes in it.

 Is it possible to write a .net version of D? I don't know. I suspect it
 might be forced into being a D subset.

 Back in the old days (!) I had no linker, and relied on the Microsoft
 linker. Unfortunately, Microsoft produced version after version of the
 linker, scores of them. Some of them worked, some didn't, some sort of
 worked, etc. It was a nightmare. The solution was to do our own linker and
 gain control over the process. I see the same problem with byte code




 you're vulnerable to arbitrary changes/bugs in a VM over which you have no
 control. An awful lot of development time can be sunk into
 investigating/writing workarounds for bugs in VM version X.YY from company
 Z.

 You could argue that aren't I relying analogously to Intel keeping their
 chips working? Sure. But Intel has a great track record of backwards
 compatibility, the only speedbump there was the infamous Pentium FDIV bug,
 for which a kludge workaround still lives in the compiler. Software VMs




 don't have that track record of reliability.

 A great advantage Digital Mars has for a new language is a great optimizer
 and code generator already existing for the Win32 platform, along with a
 complete set of tools like linker, librarian, debugger, etc., ready to




 in and go. There's nothing a CLR adds to that.

 Is there a .net future for D? Probably yes. But not now. First thing is a
 Win32 system. Then comes dfront. *Then* comes a CLR.
Feb 13 2002
parent "Walter" <walter digitalmars.com> writes:
The inline assembly sounds obscure, but it is necessary to implement the
runtime library. Without inline assembly, then you're reduced to using an
external assembler (ugh) or using C modules. D is meant to replace C, not
supplement it. D's interface to C is meant to support old C code, not to
write new C code with! (The problem with an external assembler is that there
are many incompatible ones with varying syntax and bugs. The Microsoft 32
bit assemblers also vary in syntax and quality, causing considerable support
grief.)

I disagree with the idea that CLR compatibility is necessary to appeal to
any C/C++ developer. CLR only supports a subset of C/C++. CLR only exists on
Windows at the moment. Sure, a port to linux is in the works. But a dfront
will get D onto ANY platform that supports C, and that is a very broad array
of platforms indeed, 99% of which will never support the CLR simply because
they are too niche market to justify the engineering costs of CLR port.

I am only one person, and I have to be ruthless about priorities, or I will
never get anything done. Focussing on delivering a full D implementation of
Win32 is the most practical for now.

"J. Daniel Smith" <j_daniel_smith deja.com> wrote in message
news:a4eo88$2nrc$1 digitaldaemon.com...

 I'm glad to hear that you don't have anything against a .NET




 of D.  I can also appreciate the frustration of having to deal with




 from Microsoft (I used to work for a company that had an implementation of
 Win32 on various UNIX platforms - talk about dealing with lots of things
 changing all the time).

 I don't know what your goals are for D...but I think it would be nice if




 became a wide-spread language, it has some really neat things to offer the
 ENTIRE programming community (at least ANY C/C++ developer).  However, I
 don't think that's going to happen unless porting to the CLR becomes a
 higher priority than dfront (and maybe even a Win32 system).  Personally,




 find things like real typedefs and support for design-by-contract a whole
 lot more interesting than in-line assembly; it would be a shame if a
 "systems programming" focus limited D's adoption.

    Dan

 "Walter" <walter digitalmars.com> wrote in message
 news:a4ejru$2ler$1 digitaldaemon.com...

 "Pavel Minayev" <evilone omen.ru> wrote in message
 news:a4eihn$2kpr$1 digitaldaemon.com...

 That's why C# is not a competitor for D. C# is for web-related




 D is for usual everyday routine coding. It can be fit into the .NET
 paradigm,
 yes, but does it worth the thing? C# is just enough...



 D is meant for systems programming, C# is not. For example, D gives you
 direct access to the Windows APIs. No need for wrappers and kludge







 D

 even has inline assembler (coming soon!). D can build native







 No

 need to depend on Microsoft's CLR (or clones) and random changes in it.

 Is it possible to write a .net version of D? I don't know. I suspect it
 might be forced into being a D subset.

 Back in the old days (!) I had no linker, and relied on the Microsoft
 linker. Unfortunately, Microsoft produced version after version of the
 linker, scores of them. Some of them worked, some didn't, some sort of
 worked, etc. It was a nightmare. The solution was to do our own linker







 gain control over the process. I see the same problem with byte code




 you're vulnerable to arbitrary changes/bugs in a VM over which you have







 control. An awful lot of development time can be sunk into
 investigating/writing workarounds for bugs in VM version X.YY from







 Z.

 You could argue that aren't I relying analogously to Intel keeping their
 chips working? Sure. But Intel has a great track record of backwards
 compatibility, the only speedbump there was the infamous Pentium FDIV







 for which a kludge workaround still lives in the compiler. Software VMs




 don't have that track record of reliability.

 A great advantage Digital Mars has for a new language is a great







 and code generator already existing for the Win32 platform, along with a
 complete set of tools like linker, librarian, debugger, etc., ready to




 in and go. There's nothing a CLR adds to that.

 Is there a .net future for D? Probably yes. But not now. First thing is







 Win32 system. Then comes dfront. *Then* comes a CLR.
Feb 13 2002
prev sibling next sibling parent "Pavel Minayev" <evilone omen.ru> writes:
"Walter" <walter digitalmars.com> wrote in message
news:a4ejru$2ler$1 digitaldaemon.com...


 D is meant for systems programming, C# is not. For example, D gives you
 direct access to the Windows APIs. No need for wrappers and kludge dll's.




 even has inline assembler (coming soon!). D can build native executables.



                             ^^^^^^^^^^^^

Waiting for it! =)


 need to depend on Microsoft's CLR (or clones) and random changes in it.

 Is it possible to write a .net version of D? I don't know. I suspect it
 might be forced into being a D subset.



I don't think so. After all C# has the mechanisms of calling API
functions, they just can be blocked... so I believe D could be
ported to .NET as is.


 Is there a .net future for D? Probably yes. But not now. First thing is a
 Win32 system. Then comes dfront. *Then* comes a CLR.



GREAT!
Feb 13 2002
prev sibling parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Walter wrote:


 Is there a .net future for D? Probably yes. But not now. First thing is a
 Win32 system. Then comes dfront. *Then* comes a CLR.



I agree with the priorities here.  Frankly, while CLR sounds really cool (and
some people may be using it), it's not yet a proven technology...and if ActiveX
and OLE are any examples, just because MS pushes something (and the editorials
like it) doesn't mean it is going to become a cross-platform standard.

For now, the biggest target market is Win32.  Whether CLR becomes widely used or
not, Win32 is a safe bet.  Later, as dfront comes out, if you want to use CLR,
then use dfront and then use Microsoft's latest and greatest compiler to build
CLR.

Now, I personally would prefer dfront over the Win32 version, so that I can
start cross-platform UNIX/Windows development, but I know I'm in the minority,
and am thus happy to wait. :)

Keep it up, Walter.  Hey, if the languages becomes very big, we won't need to
write a D->CLR compiler; MS will do it for us!

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]
Feb 14 2002
next sibling parent "Walter" <walter digitalmars.com> writes:
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3C6C1C4D.AB3A04BA deming-os.org...

 I agree with the priorities here.  Frankly, while CLR sounds really cool




 some people may be using it), it's not yet a proven technology...and if




 and OLE are any examples, just because MS pushes something (and the




 like it) doesn't mean it is going to become a cross-platform standard.



I found out today that if a Win32 user does not have CLR installed, getting
it is a 20+Mb download. For the time being, that makes it impractical for a
D application developer to distribute his D executable over the web.
Feb 14 2002
prev sibling parent "OddesE" <OddesE_XYZ hotmail.com> writes:
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3C6C1C4D.AB3A04BA deming-os.org...

 Walter wrote:


 Is there a .net future for D? Probably yes. But not now. First thing is







 Win32 system. Then comes dfront. *Then* comes a CLR.



 I agree with the priorities here.  Frankly, while CLR sounds really cool




 some people may be using it), it's not yet a proven technology...and if




 and OLE are any examples, just because MS pushes something (and the




 like it) doesn't mean it is going to become a cross-platform standard.

 For now, the biggest target market is Win32.  Whether CLR becomes widely




 not, Win32 is a safe bet.  Later, as dfront comes out, if you want to use




 then use dfront and then use Microsoft's latest and greatest compiler to




 CLR.

 Now, I personally would prefer dfront over the Win32 version, so that I




 start cross-platform UNIX/Windows development, but I know I'm in the




 and am thus happy to wait. :)

 Keep it up, Walter.  Hey, if the languages becomes very big, we won't need




 write a D->CLR compiler; MS will do it for us!



ROTFL!  :)


--
Stijn
OddesE_XYZ hotmail.com
http://OddesE.cjb.net
__________________________________________
Remove _XYZ from my address when replying by mail
Feb 17 2002
prev sibling parent reply "J. Daniel Smith" <j_daniel_smith deja.com> writes:
.NET encompasses a whole bunch of things from Microsoft, what I think is
interesting to D is the new C# language and the CLR which supports it.

C# is (or soon will be) for just about any kind of Windows development, just
like C++ and VB have been; there is nothing about C# that makes it a
"web-related development" language (although it does make doing things like
WebServices easy).  The new versions C++ and VB from Microsoft have been
modified to work with the CLR, whereas C# was designed from the beginning
with the CLR in mind so there aren't a bunch of __keywords like there are in
C++.  Of course if you really need raw horsepower, unmanaged C++ is going to
deliver that.  But most of the time, on today's 1GHz boxes, speed isn't an
issue.  Besides, Microsoft supposedly has learned from their experience JVM
performance issues and has tried to address these in the CLR.

In the not too distant future, most "usual everyday routine coding" on a
Windows platform will be done using a CLR-based (or .NET) language.  Being
the "power language", C++ developers can choose to avoid the CLR ("unmanged"
code), but VB developers (and there are a whole bunch of them) and C# coders
will both be using the CLR (and pretty much without even knowing about it).
And Microsoft claims there are lot more languages that are being ported by
3rd parties to the CLR.

Given the competition C# (another new language on the Windows platform) I
think the only way D has a chance for widespread acceptance (again, books on
D) is if it is build on top of the CLR.  C# seems to bring along a bit too
much Java (Main() having to be a static function for example), and D has
some really neat features; so I think there is a place for both - but D
needs to be on the CLR.

   Dan

"Pavel Minayev" <evilone omen.ru> wrote in message
news:a4eihn$2kpr$1 digitaldaemon.com...

 "Richard Krehbiel" <rich kastle.com> wrote in message
 news:a4eh5h$2k7g$1 digitaldaemon.com...


 .NET is *not* for every kind of program.  (Visual Studio .NET still




 plain old C and C++ compilers, you know.)  .NET is for web-based







 (but Java was there first).



 Yes, sure.


 (Web-based computing is client-server computing, with client code




 just-in-time to the client box, over the Internet, from a server you may




 trust.  Shudder - everybody knows you don't run code from untrusted




 that's how viruses spread.  So the Java JVM and .NET CLR provide a
 "sandboxed" virtual-machine, so that downloaded code can only do certain
 safe things.  Microsoft found out that customers are too smart to







 machine code ActiveX objects, even if signed; so they copied Java and







 JVM, named them C# and CLR, and gave us .NET.  Wow - what amazing




 MS are.)



 That's why C# is not a competitor for D. C# is for web-related




 D is for usual everyday routine coding. It can be fit into the .NET
 paradigm,
 yes, but does it worth the thing? C# is just enough...

 On other hand, some ideas could be stolen from C# and used in D. For
 example,
 packaging types into objects, or delegates, or checked/unchecked blocks...
Feb 13 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"J. Daniel Smith" <j_daniel_smith deja.com> wrote in message
news:a4ekba$2lo1$1 digitaldaemon.com...


 In the not too distant future, most "usual everyday routine coding" on a
 Windows platform will be done using a CLR-based (or .NET) language.  Being
 the "power language", C++ developers can choose to avoid the CLR




 code), but VB developers (and there are a whole bunch of them) and C#




 will both be using the CLR (and pretty much without even knowing about




 And Microsoft claims there are lot more languages that are being ported by
 3rd parties to the CLR.



We shall see... I personally doubt everything will be like this.
I know that many, MANY C++ programmers hate C#, not even speaking
about C ones...


 Given the competition C# (another new language on the Windows platform) I
 think the only way D has a chance for widespread acceptance (again, books




 D) is if it is build on top of the CLR.  C# seems to bring along a bit too
 much Java (Main() having to be a static function for example), and D has
 some really neat features; so I think there is a place for both - but D
 needs to be on the CLR.



I think this is only needed in distant future. VS.NET has just been released
officially, it's not wide-spread... and the .NET framework is also a new
thing. For now, it's just _safer_ to cover the entire set of Windows version
with usual compiler, than making something for CLR. So Win32 port goes
first.
Then, for D to beat C/C++, it must be portable as well, so a compiler for
*NIXes and such is needed. So Dfront... I believe Walter's priorities are
absolutely right!
Feb 13 2002
next sibling parent "J. Daniel Smith" <j_daniel_smith deja.com> writes:
Now is the time to think about D and the CLR; otherwise there is a good
possibility that when the time comes D will have to make changes/additions
to support the CLR - witness all the new __keywords in C++.NET.  Changes can
be readily made to D now to support the CLR in a transparent manner like C#
and VB, waiting makes that more difficult because at that point there will
be legacy code issues, dfront compatibility, etc.



Like it or not, the "sweet spot" in software development is Windows
programmers using VB or C++.  Sure, there are lots of people writing lots of
code in many other environments, but as far as lines-of-code and/or number
of developers, Windows/VB/C++ is clearly in the majority.  I don't think
that focusing on running under various flavors of UNIX or Palm developers is
the way to foster widespread adoption of D.



   Dan

"Pavel Minayev" <evilone omen.ru> wrote in message
news:a4gk2d$gqu$1 digitaldaemon.com...

 "J. Daniel Smith" <j_daniel_smith deja.com> wrote in message
 news:a4ekba$2lo1$1 digitaldaemon.com...


 In the not too distant future, most "usual everyday routine coding" on a
 Windows platform will be done using a CLR-based (or .NET) language.







 the "power language", C++ developers can choose to avoid the CLR




 code), but VB developers (and there are a whole bunch of them) and C#




 will both be using the CLR (and pretty much without even knowing about




 And Microsoft claims there are lot more languages that are being ported







 3rd parties to the CLR.



 We shall see... I personally doubt everything will be like this.
 I know that many, MANY C++ programmers hate C#, not even speaking
 about C ones...


 Given the competition C# (another new language on the Windows platform)







 think the only way D has a chance for widespread acceptance (again,







 on

 D) is if it is build on top of the CLR.  C# seems to bring along a bit







 much Java (Main() having to be a static function for example), and D has
 some really neat features; so I think there is a place for both - but D
 needs to be on the CLR.



 I think this is only needed in distant future. VS.NET has just been




 officially, it's not wide-spread... and the .NET framework is also a new
 thing. For now, it's just _safer_ to cover the entire set of Windows




 with usual compiler, than making something for CLR. So Win32 port goes
 first.
 Then, for D to beat C/C++, it must be portable as well, so a compiler for
 *NIXes and such is needed. So Dfront... I believe Walter's priorities are
 absolutely right!
Feb 14 2002
prev sibling parent reply "Sean L. Palmer" <spalmer iname.com> writes:
Eiffel has already been ported to CLR.  I agree with Walter's current
priority goals though.

Sean

"Pavel Minayev" <evilone omen.ru> wrote in message
news:a4gk2d$gqu$1 digitaldaemon.com...

 "J. Daniel Smith" <j_daniel_smith deja.com> wrote in message
 news:a4ekba$2lo1$1 digitaldaemon.com...


 In the not too distant future, most "usual everyday routine coding" on a
 Windows platform will be done using a CLR-based (or .NET) language.







 the "power language", C++ developers can choose to avoid the CLR




 code), but VB developers (and there are a whole bunch of them) and C#




 will both be using the CLR (and pretty much without even knowing about




 And Microsoft claims there are lot more languages that are being ported







 3rd parties to the CLR.



 We shall see... I personally doubt everything will be like this.
 I know that many, MANY C++ programmers hate C#, not even speaking
 about C ones...


 Given the competition C# (another new language on the Windows platform)







 think the only way D has a chance for widespread acceptance (again,







 on

 D) is if it is build on top of the CLR.  C# seems to bring along a bit







 much Java (Main() having to be a static function for example), and D has
 some really neat features; so I think there is a place for both - but D
 needs to be on the CLR.



 I think this is only needed in distant future. VS.NET has just been




 officially, it's not wide-spread... and the .NET framework is also a new
 thing. For now, it's just _safer_ to cover the entire set of Windows




 with usual compiler, than making something for CLR. So Win32 port goes
 first.
 Then, for D to beat C/C++, it must be portable as well, so a compiler for
 *NIXes and such is needed. So Dfront... I believe Walter's priorities are
 absolutely right!
Feb 14 2002
parent "Walter" <walter digitalmars.com> writes:
"Sean L. Palmer" <spalmer iname.com> wrote in message
news:a4gvug$mj8$1 digitaldaemon.com...

 Eiffel has already been ported to CLR.  I agree with Walter's current
 priority goals though.



I read (have not verified it myself) that Eiffel had to be subsetted to work
with CLR.
Feb 14 2002
prev sibling parent "J. Daniel Smith" <j_daniel_smith deja.com> writes:
"straight, complied executables" lead to "DLL hell", one of the things
(hopefully) .NET fixes.

   Dan

"Pavel Minayev" <evilone omen.ru> wrote in message
news:a4eeia$2j25$1 digitaldaemon.com...

 "J. Daniel Smith" <j_daniel_smith deja.com> wrote in message
 news:a4e1ab$2c84$1 digitaldaemon.com...


 I don't know what it takes to write a .NET language - does the effort







 to be "blessed" by Microsoft?  I'm sure making it work in Visual Studio




 I believe you have to write a compiler for that new MS bytecode format...
 is it an opened standard?


 is a lot more effort than just a command-line version; but even being







 to use the various .NET development tools seems beneficial.  It also







 like now is the time to move D in the .NET direction so that features







 be

 added/modified so that it works better in that environment; like C#







 are no legacy issues with D.

 As a practical matter, I don't think D has much of a chance of becoming
 mainstream unless it is a .NET language.  As a new language (on the




 platform), it is competing in some sense with C#, which, because of
 Microsoft's backing already has a lot of mindshare (just look at all the




 books that are available).  D has a lot of interesting features, but I




 anticipate finding any books on D in the near future.



 I - personally - don't like the idea behind the .NET. I want my code to




 straight, compiled executables, able to run on any Win32 box. This new JIT
 thingie is something that I definitely don't like. WinForms is better, but
 it's COM - which is not the best solution to work with multiple




 I'd prefer a C interface as well...
Feb 13 2002