www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - .NET not

reply Mark T <Mark_member pathlink.com> writes:
* 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.
Mar 04 2005
next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
Mar 04 2005
prev sibling next sibling parent reply jicman <jicman_member pathlink.com> writes:
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é
Mar 04 2005
parent "Charlie Patterson" <charliep1 excite.com> writes:
"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.



 Mar 04 2005



prev sibling next sibling parent reply Dave <Dave_member pathlink.com>  writes:


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



 Mar 04 2005



 next sibling parent  "Pablo Aguilar" <paguilarg hotmail.com>  writes:


 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 



 Mar 04 2005



prev sibling  parent reply "Andrew Fedoniouk" <news terrainformatica.com>  writes:


 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.



 Mar 04 2005



  parent  Dave <Dave_member pathlink.com>  writes:


In article <d0balg$2msf$1 digitaldaemon.com>, Andrew Fedoniouk says...

 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.


I should rephrase that - "using .Net" should have been "running CLR assemblies"
(VS 2005 looks to still be 'native' binaries).

You're right - VS 2005 Beta is quite large ;)

- Dave



 Mar 07 2005



prev sibling next sibling parent reply "Andrew Fedoniouk" <news terrainformatica.com>  writes:


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.

 





 Mar 04 2005



 next sibling parent reply pragma <pragma_member pathlink.com>  writes:


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



 Mar 05 2005



  parent reply "Andrew Fedoniouk" <news terrainformatica.com>  writes:


 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



 Mar 05 2005



 next sibling parent reply "Dave" <Dave_member pathlink.com>  writes:


"Andrew Fedoniouk" <news terrainformatica.com> wrote in message 
news:d0dtq7$21d9$1 digitaldaemon.com...

 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


It has constantly amazed me how much (and fast!) history repeats itself, 
especially in the IT world.

Thin clients (terminals) -> Fat Clients (GUI) -> Thin Clients (HTML and 
browsers on a chip) -> Now the latest is thin code on top of fat runtimes 
(eg: Flash), which really brings us back to Fat Clients because a PC is 
needed to host the runtimes.

Centralized (Time Sharing Mainframes) -> De-centralized (PC's) -> 
Centralized (Web servers, multi-tier and 'virualized' Mainframes) -> 
De-centralized (Messaging frameworks, peer-to-peer, etc.).

And on and on it goes, with application design, development methodologies, 
patent issues, open source/closed source (this latest SCO/IBM thing really 
reminds me of the original Berkeley/AT & T suit, at least on the face of 
it). In-sourcing/out-sourcing and even off-shoring has been visited before. 
Offshoring is an interesting one - the premise even back 20 or so years ago 
(at that time it was Japan and Europe who were the "threat" to US 
developers) was that better and cheaper collaberation technology and "follow 
the sun" methodologies would enable that. Sound familiar? It turned out that 
Japan and Europe ended up needing all the developers they could turn out for 
work inside their own countries, which raised the cost for US companies, 
etc., etc... The good news for us all (developers living in a "developed" 
country or not) is that the expanding economies of places like India and 
China will likely produce the same result, and we all end-up in greater 
demand than before ;) Hey, programmers are an odd bunch - not everyone wants 
to do this type of work. Most of my buddies think I'm nuts (sitting inside 
staring at a friggen screen all day).

Have you ever heard that this-or-that technology will rend the job of a 
programmer obsolete? That piece of history has probably made the rounds more 
than the rest.. First it was COBOL (actually promoted as "so easy an office 
mgr. can create their own reports") that was going to put all of the 
assembly programmers out of work, but it turned out that those people were 
the best suited to write the COBOL applications anyhow. So since it was much 
more cost effective to build software, more progammers were needed, etc., 
etc... Then it was MS Access, OOP, HTML, etc.,etc.. My first major job was 
writing DiBoL on a DEC Ultrix system. Everything I've done since has gotten 
more and more compilcated as the improved technology has allowed us to "herd 
chickens" more and more effectively.

Interesting stuff all this.

- Dave



 Mar 06 2005



  parent  "Andrew Fedoniouk" <news terrainformatica.com>  writes:


 Interesting stuff all this.


Oh, yeh! :)



 Mar 06 2005



prev sibling  parent  Georg Wrede <georg.wrede nospam.org>  writes:


Andrew Fedoniouk wrote:


 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.


The Rule of Ever Diminishing Coupling.  ;-)

I just stumbled on ImageMagic, which I hadn't noticed on my new FC3 
linux. Nothing in the "start menu" about it. Well, there was a bug for a 
while in the dscript thing (see other post today), the debugging of 
which led to unexpected coupling with ImageMagic. (Don't ask!)

Anyhow, seems there are millions of these command line components, and 
you can do the most amazing, or actually unbelievable things to your 
pictures. Just a few words on the command line.

The world will have to come back to the command line. It's  like with 
calculators. Had we never got computers so nobody needs a calculator, 
then by this time the RPN ones would have taken over.

Some things just are harder at the outset. But hey, climb over the 
ridge, and its wide fields from then on.



 Mar 07 2005



prev sibling  parent  "Charlie Patterson" <charliep1 excite.com>  writes:


"Andrew Fedoniouk" <news terrainformatica.com> wrote in message 
news:d0bbs7$2nsr$1 digitaldaemon.com...

 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


Wouldn't we all like a little stability, but MS will see that never happens. 
My point was that MS will sell .Net as the next great thing that will solve 
all desktop, IT, and security problems and a large mass of programmers will 
accept it and even evangelize it.  So not being compatible with this 
"movement" will make D seem suspect, foreign, uncool, etc.



 Mar 08 2005



prev sibling  parent reply Niko Korhonen <niktheblak hotmail.com>  writes:


An /additional/ D.NET compiler would be wonderful. It would make quick 
GUI development a breeze, and it would also give D developers huge 
amount of security. At that point it wouldn't matter if Digital Mars D 
compiler suddenly disappeared from the face of the earth; the existing D 


Also a "Managed extensions for D" where one could use .NET libraries and 
call native D code would be pretty sweet. That would solve the current 
GUI library issues nicely.

Making it work with Mono -- *DROOL*!

BTW, does anyone know whether Deja Augustine has dumped the D.NET 
project altogether?



 Mar 07 2005



  parent  J C Calvarese <jcc7 cox.net>  writes:


In article <d0hdv2$275o$1 digitaldaemon.com>, Niko Korhonen says...


BTW, does anyone know whether Deja Augustine has dumped the D.NET 
project altogether?


I don't know the status of the project. I added a question about it at
http://www.prowiki.org/wiki4d/wiki.cgi?DDotNet since the website listed there is
invalid and I found an out-of-date website by playing with the URL. I hope he's
just taking a break from the project since it sounded very interesting to me.


jcc7



 Mar 08 2005