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