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

... 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: 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 
code could be compiled to .NET and used with C# or any other .NET language.

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