View mode: basic / threaded / horizontal-split · Log in · Help
March 04, 2005
.NET not
* 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.
March 04, 2005
Re: .NET not
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
March 04, 2005
Re: .NET not
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é
March 04, 2005
Re: .NET not
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
March 04, 2005
Re: .NET not
"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.
March 04, 2005
Re: .NET not
> 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
March 05, 2005
Re: .NET not
> 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.
March 05, 2005
Re: .NET not
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.
>
>
March 06, 2005
Re: .NET not
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
March 06, 2005
Re: .NET not
> 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
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home