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

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

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

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

"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 JVM, named them C# and CLR, and gave us .NET.  Wow - what amazing
innovators
> 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...

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

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.

.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
> 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
> > JVM, named them C# and CLR, and gave us .NET.  Wow - what amazing
> innovators
> > 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...
>
>

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

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

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

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

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!