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


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

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


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

 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

 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
don't
 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
need
 to be "blessed" by Microsoft?  I'm sure making it work in Visual Studio
.NET 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 version of the Java JVM).
 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...
.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 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
includes
 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
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

innovators
 MS are.)
D is for usual everyday routine coding. It can be fit into the .NET paradigm, 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...

development.
 D is for usual everyday routine coding. It can be fit into the .NET
 paradigm,

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

development.
 D is for usual everyday routine coding. It can be fit into the .NET
 paradigm,

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

development.
 D is for usual everyday routine coding. It can be fit into the .NET
 paradigm,

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
prev sibling next sibling parent "Pavel Minayev" <evilone omen.ru> writes:
"Walter" <walter digitalmars.com> wrote in message
news:a4ejru$2ler$1 digitaldaemon.com...


 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 ^^^^^^^^^^^^ 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.
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
(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.
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
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!
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




"web-related development" language (although it does make doing things like
WebServices easy).  The new versions C++ and VB from Microsoft have been

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"

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.


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

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

innovators
 MS are.)
development.
 D is for usual everyday routine coding. It can be fit into the .NET
 paradigm,



 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
("unmanged"

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.
We shall see... I personally doubt everything will be like this. about C ones...

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

 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

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.
Being
 the "power language", C++ developers can choose to avoid the CLR
("unmanged"

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.
We shall see... I personally doubt everything will be like this. about C ones...

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

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 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.
Being
 the "power language", C++ developers can choose to avoid the CLR
("unmanged"

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.
We shall see... I personally doubt everything will be like this. about C ones...

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

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 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
need
 to be "blessed" by Microsoft?  I'm sure making it work in Visual Studio
.NET 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
 be

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

 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
don't
 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