* does it work with .NET?
Some may have ideological reasons against it, but this would be huge,
also.  It is the big "silver bullet" right now.  .Net has figured out that
it is all about libraries nowadays and you can use any lang to connect to
their libs.  So you both leverage all that programmer knowledge and you fit
in with the latest direction.  (I don't know .NET myself.)

This is the last thing D needs. The whole idea of D is that some of us still what optimized compiled code not another VM.

Mark T wrote:

> * does it work with .NET?
> Some may have ideological reasons against it, but this would be huge, also.  It is the big "silver bullet" right now.  .Net has figured out that it is all about libraries nowadays and you can use any lang to connect to their libs.  So you both leverage all that programmer knowledge and you fit in with the latest direction.  (I don't know .NET myself.)

Somebody was working on it:
http://www.prowiki.org/wiki4d/wiki.cgi?DDotNet
But I'm not sure it actually compiled anything...

And it'll be a lot more fun if it worked with Mono.
http://www.mono-project.com/

--anders

Mark T says...
>
>* does it work with .NET?
>Some may have ideological reasons against it, but this would be huge,
>also.  It is the big "silver bullet" right now.  .Net has figured out that
>it is all about libraries nowadays and you can use any lang to connect to
>their libs.  So you both leverage all that programmer knowledge and you fit
>in with the latest direction.  (I don't know .NET myself.)
>
>This is the last thing D needs. The whole idea of D is that some of us still what optimized compiled code not another VM.

The probelm with .net is that is ssssslllllllooooooooowwwwwwwww!  Why would I use a library that is going to slow me down?  I'd rather write my own libraries than to use anything with .net.  Can you tell that I have a little grudge against .net? :-)  We had an OCR java application that ran on a 512Mhz/256MB Mem. and we were told to move it into .net.  Now, we need a 1.5 Dual CPU/ 1.0 GB memory and it's still slower than the same application in java on the same 512Mhz/256MB machine.  So, I have a little problem with it.  Also, I don't like that one needs to install .net runtime environment to run it.  (I also don't like that about java, but...)  Oops!  I think my hour is up, Doc.  Anyway, thanks for listening.  How much do I owe?

josé

In article <d09v2b$1cof$1@digitaldaemon.com>, Mark T says...
>
>* does it work with .NET?
>Some may have ideological reasons against it, but this would be huge,
>also.  It is the big "silver bullet" right now.  .Net has figured out that
>it is all about libraries nowadays and you can use any lang to connect to
>their libs.  So you both leverage all that programmer knowledge and you fit
>in with the latest direction.  (I don't know .NET myself.)
>
>This is the last thing D needs. The whole idea of D is that some of us still what optimized compiled code not another VM.
>

Heck, *ALOT* of us want optimized compiled code (sans VM), even in the MS world.


They (MS) keep making major improvements to native VC++ compiler and tools and keep making sure the interop stuff works Ok, etc. so it appears there is still a lot of demand for that, and I don't think MS is really going to stop building large time-critical parts of their products with native compilers anytime soon either.

Allowing D to be hosted by the .Net runtime could be a boon, but, like it or not, good integration with even the .Net tools also couldn't hurt.

If you have >= VS.Net 2003 available, are comfortable with it (and don't mind installing something brand-new and potentially buggy into it), help this guy out: http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/18102

That plugin installed easily on my system and I was able to punch in some D code, set breakpoints, run it and watch some vars. with the debugger in 5 minutes, so at the least he has a good start.

Speaking of .Net acceptance, does anyone know of any major commercial/shrink-wrapped products that have been released using .Net (not including web-apps.)?

- Dave

"jicman" <jicman_member@pathlink.com> wrote in message news:d0a20p$1giq$1@digitaldaemon.com...
> Mark T says...
>>
> The probelm with .net is that is ssssslllllllooooooooowwwwwwwww!
>...
>  So, I have a little problem with it.  Also, I don't like
> that one needs to install .net runtime environment to run it.  (I also
> don't
> like that about java, but...)  Oops!  I think my hour is up, Doc.  Anyway,
> thanks for listening.  How much do I owe?

I didn't want .Net as a requirement!  Just as an option for uptake.  I figured it might be a reasonably "simple" thing to compile to, but I don't know.  Anyway, I don't even like Java, though I am trying to get used to it, so I just think of D as a cleaned-up C++, whose Java-like decisions I can live with.  (OpEqual, blah!)

But if it were to run in .Net you'd get the new Microsoft GUI tools as well as all the new-fangled threads, files, etc in that library.

> Speaking of .Net acceptance, does anyone know of any major commercial/shrink-wrapped products that have been released using .Net (not including web-apps.)?
>
> - Dave

StruCAD (latest version)'s front end is done with .NET although all of it's core components are built using Fortran. StruCAD is a steel detailing system, one of the 4 or 5 top known detailing systems (at least in the US).

ATI's Catalyst (I think it's the front end to their driver) is also done in .NET

That's all I know about..


Pablo Aguilar

> Speaking of .Net acceptance, does anyone know of any major commercial/shrink-wrapped products that have been released using .Net (not including web-apps.)?
>

Visual Studio 2005 Beta.

But time it first time started up is 7 times bigger than compilation of all my projects in C++ on working machine.

Hmmm,
Are you sure about "silver bullet"? Probably "golden egg"? No?

And about the Framework, I think Joel is right here: http://www.joelonsoftware.com/articles/PleaseLinker.html

With the full respect to Microsoft (stability and richness of Win32 API is
worth to monument, honestly) but for me evolutions of Microsoft's attempts
to invent "silver bullets" looks like a sequence of "hells"
transforming one into another, see:

DLL hell,
Component hell,
Assembly hell,
and now we are entering the era of Framework hells.

Perfect. But I just tired, want to rest "lilebit" on something solid :)

Andrew Fedoniouk.
http://terrainformatica.com





"Mark T" <Mark_member@pathlink.com> wrote in message news:d09v2b$1cof$1@digitaldaemon.com...
>* does it work with .NET?
> Some may have ideological reasons against it, but this would be huge,
> also.  It is the big "silver bullet" right now.  .Net has figured out that
> it is all about libraries nowadays and you can use any lang to connect to
> their libs.  So you both leverage all that programmer knowledge and you
> fit
> in with the latest direction.  (I don't know .NET myself.)
>
> This is the last thing D needs. The whole idea of D is that some of us
> still
> what optimized compiled code not another VM.
>
> 

In article <d0bbs7$2nsr$1@digitaldaemon.com>, Andrew Fedoniouk says...
>
>With the full respect to Microsoft (stability and richness of Win32 API is
>worth to monument, honestly) but for me evolutions of Microsoft's attempts
>to invent "silver bullets" looks like a sequence of "hells"
>transforming one into another, see:
>
>DLL hell,
>Component hell,
>Assembly hell,

Agreed.  Even though there is much to be learned, and used, from Microsoft's foray into these areas, the overall solution provided usually has stiff drawbacks.

I, for one, find that human behavior is the overriding reason for failure for these technologies. All of the above can be made managable if everyone agreed on the same "best practicies" and played by the book.  Sadly, file name collisions, overlapping namespaces, misbehaving components, bad code, et al. cannot be completely avoided... :(

>
>and now we are entering the era of Framework hells.
>

*I hope nobody minds me taking a philosophical, and mildly humorous bent with this.

Andrew's simile of likening software solutions to hell reminds me of a software-engineering version of the Divine Comedy (Emphasis on comedy).

http://en.wikipedia.org/wiki/The_Divine_Comedy

Which would identify Microsoft wtih Inferno.  In which case, there's another 5 circles outside of DLL, COM, Assembly and .NET.  VB has to be one of those.  Any takers on what the rest might be?

I also find it funny that Mars is also mentioned as a portion of Paradise, for those who fought for their faith.  it reminds me of what we're trying to do here.

- EricAnderton at yahoo

> I, for one, find that human behavior is the overriding reason for failure
> for
> these technologies. All of the above can be made managable if everyone
> agreed on
> the same "best practicies" and played by the book.  Sadly, file name
> collisions,
> overlapping namespaces, misbehaving components, bad code, et al. cannot be
> completely avoided... :(

Hi. Eric,

I don't think that lack of followers of "best practicies" is the main source
of the problem.
Problem is a way deeper. Complex systems (of components) at some
point start behave as the Deterministic Chaos
http://www.exploratorium.edu/complexity/CompLexicon/chaos.html
with full set of implications from Catastrophe Theory
http://www.exploratorium.edu/complexity/CompLexicon/catastrophe.html
And "human factor" plays here not the main role I guess.

See, bright idea of COM and its foundation - reference counting - just
reached its limits.
Cyclic references is one huge and unsolvable problem.

Garbage collector based systems are more stable in this terms - they allow
to use
more complex conglomerates.  But complexity (power of the set) of framework
classes
will be a problem for sure (at least management and I would say logistic
problems).
Number of already published classes/interfaces is close to the meaning of
the chaos.

BTW: Microsoft Indigo (COM+ of nowadays) uses new motto
"Loosely coupled systems rules!" :)

I guess on the next level we will see "Extremely non-coupled systems" - systems consisting from our old friends - command line alike components with stdin/stdout probably with XML as "lingua franca" instead of plain text.

And we will get UNIX again :)
Evolution is a spiral as you know.

Andrew Fedoniouk.
http://terrainformatica.com