>Not true. Other companies have it too. When VS .NET was first launched there was great fanfare over a COBOL compiler.

Have a compiler or compiler plugin is a thing, have the LICENSED .NET is diferent. In this case, Borland is the first (but maybe other companies do that later)

>A .NET version of Delphi can only do what the CLR allows, just like any .NET language.

This is true, but is not equal that each language exploit the full options of CLR. I point to a example where only Delphi exploit a option of the CLR that is not available for C# or VB. In equal way C# or VB can do things not available in other languages. Also is not so exact say that is ONLY the CLR, because is possible that a compiler do a thing not possible or not available in CLR but available in language, because CLR is only a best (for say something, not so exact) assembler, and in this area exit a lot of posibilities that a language can exploit... No matter what, a language can implement things far away the standar..the only thing is build correct intermediate language ( not so diferent to build correct assembler)

>I don't understand what you're saying. VB and C# definately have a RAD way to code, design, and architect an application.

Yes and not. For server&logic&asp.net really yes. But for build a aplication for windows take more time in .NET than in VB and a lot more than Delphi, because a)The available toolset of visual components is very basic (and poor), not against VB 6 but against Delphi b)Requiere more code for task like data manipulation c) The binding is powerfull but is not RAD, i can do in Delphi a full data editing form with NO code, that is not available now in .NET (but is possible) d) .NET is huge..is good but meaning that is necesary build simplified things for do simply things. For that reason the roadmap for vb is more focused for rad than in C# (you can read this in ms site). Delphi have a strong reputation for build GUI because is far the best, mainly because the way that VCL is build, at diference to MFC of VB solutions or actual .NET is sooo good that is not necesary change in each version and is not hard to master: this is maybe the best proof of this: Good things not need change, poor things yes.. is for that that MS is changing for longhorm again the way for build windows app..


>Again, I don't understand what you're saying.

This meaning that Delphi have a very stable framework. A simply example is databinding: Each time than MS chane dataacces (rdo, ado, ado.net, odbc, bla, bla) the binding must change , the visual code must change, etc.. In Delphi you have a "virtual" dataset and only know how represent fields, rows and basic crud operations. When a new technology appear, is NOT necesary change the GUI, because the controls not talk to data components but to datasets..and in diference to VB 6, the binding in Delphi really work and not put problems to performance (and the coding is minimal). In the box you have in delphi at least 4 ways to connect to data and can chose the best for the job. This is something that can be found in each area of delphi: if a thing is good and work, is not changed (enchanced maybe). So a move to .net for us is very smooth, is not necesary recode all: Delphi is equal good (and the same) in and out...Binding in Delphi.NET work the same than binding in Delphi 3, can be enchanced for the support to use .NET binding but is not necesary lost velocity building. Also the win32 compiler in D7 warning for things that not run under .NET so is posible use a common code base for win32&.net, so is not a all or nothing position for us...

>I don't see either of those as a plus. In fact, I see the Linux arguement as a drawback. For the UI to be effective, you have to code to either a common standard or have several custom UIs, one for each Linux GUI you're going to support or just support one.

But in first place you missing server&logic: A good logic is very portable across plataforms, also if the GUI is web, the change is not hard. But obvious the visual thing is the hardest part, for this reason Borland ported the VCL to .NET and port a compatible VCL (called CLX) for Linux... Is still important take in account the diferences in plataforms but the diference is not like you are thinking...