July 3, 2008
Delphi .NET Plans (by Michael Swindell)
In a comment left on my blog yesterday, the head of Embarcadero product management provides relevant insights on the future of Delphi .NET. This is great news!
blog yesterday
re RIA & Mono, I should probably let the Delphi team address .NET directly and specifically as soon as they are ready, but in a general sense over the last year we've taken a "time out", stepped back and talked to many customers about their future .NET development plans, compatibility, frameworks, platforms, priorities, etc. In the beginning with .NET we put most of our energy into compatibility and replicating the Delphi language and VCL intact in a first class way for CLR, with the goal to make moving to .NET seamless for those applications that would be well suited on .NET - this was balanced against keeping up with the latest frameworks and lavors from MS, latest CLS and CLR feature support etc - which often lost out to compatiblity. Years have passed, and something that has been clear for some time is that most of the migration that was destined to happen, has passed.
Today things like supporting more of the .NET framework flavors (Silverlight, WPF, etc) and keeping up with the latest language and framework releases is of much higher importance. So we have been working on a more aggressive .NET approach that focuses less on being a .NET clone of the native Delphi implementation and more of an open approach that will make more frameworks, platforms, and features available and in a more timely manner. At the same time we have been significantly increasing our efforts and focus on native compiled Delphi and C++, and this adjustment to the strategy should pay off for both native developers and .NET developers. So in a nutshell expect less focus on compatibility between native and .NET and more support for performance and rich UI oriented packaged/desktop/workstation features (ie GUI, DB and CPU) in the native tools, and more support for other .NET frameworks beyond just Winforms and ASP.NET ie WPF, Silverlight, Open source and others - in the .NET tools.
As we finalize plans expect to see a .NET roadmap coming from the Delphi team in the near future.
excellent newsEmbarcadero openness27 Comments
Delphi .NET Plans by Michael Swindell
They should concentrate on a working F1 Help file. I miss that beyond Delphi 7.Comment by Peter on July 3, 14:11
Delphi .NET Plans by Michael Swindell
Because I always keep an eye on RemObjects' Chrome/Oxygen, I am worried about this news if CodeGear/Embarcadero wants to clone (may be RO clones Delphi at first) that in the near future. I wish both RO and CG can cooperate to promote Object Pascal for .NET some day.Comment by Lex Y. Li [http://lextm.cn] on July 3, 15:23
Delphi .NET Plans by Michael Swindell
Yeah! Goood News! .NET rocks!Comment by Ralf Grenzing on July 3, 16:10
Delphi .NET Plans by Michael Swindell
Now, I love Embarcadero (^^)Comment by HardOrc on July 3, 16:53
Delphi .NET Plans by Michael Swindell
What about Turbo Delphi line?Comment by Student on July 3, 16:55
Delphi .NET Plans by Michael Swindell
oh no! the delphi.net resurface again!!! if not mistaken, this is on of the main reason why all of delphi loyal users have turned away to the different product.Comment by ahmoy on July 3, 19:27
Delphi .NET Plans by Michael Swindell
Cogegear is starting to lose focus again. Thay what to put everything into Delphi. This is IMPOSSIBLE !!! Well, some people have Delphi .NET projects. I do not think that those are big projects. They should better migrate them to C# and .NET I am working on a BIG native Delphi project. We still using Delphi 6. We are earning a pile of cash with that project so we can pay for better Delphi. BUT I do not like Delphi .NET and bloated Delphi 2007. The best technologies comes from third party Delphi components. We do not use DBExpress and we do not use ECO. We use third party components for database conectivity based on TDataset and third party components for data visualisation because TDBGrid in Delphi is not good enough. I think that CodeGear should focus on improving on their base technologies instead of traing to win new markets like Delphi for PHP or Delphi for AS400 or Delphi .NETComment by Simon on July 4, 11:33
Delphi .NET Plans by Michael Swindell
"So we have been working on a more aggressive .NET approach that focuses less on being a .NET clone of the native Delphi implementation and more of an open approach that will make more frameworks, platforms, and features available and in a more timely manner." Wonderful news for me! Individual priorities may vary, but my personal ones are looking for WPF support in Delphi. And, generally, there should be a more open approach for using different .NET frameworks in our Delphi applications. Perhaps based on reflection etc.?Comment by mikeg on July 4, 11:48
Delphi .NET Plans by Michael Swindell
And Win32 I hope will not throw?Comment by Win32 user on July 4, 13:46
Delphi .NET Plans by Michael Swindell
I'm with Student... will the Turbo Explorer or Turbo Delphi lines be kept or are all of us hobbyists stuck with the 2006 version for the next (checks his license) 35941 days (or forced to pay hundreds of dollars for the "PRO" version of Delphi)?Comment by Concerned hobbyist on July 4, 18:30
Delphi .NET Plans by Michael Swindell
Hi Marco, thanks to add this article. this bring up new hope to the .net roadmap. you know i love the asp.net stuff and work a lot of with delphi 2007 and asp.net projects. so we can hope for new big steps. GREAT NEWS! GREAT EMBARCADERO! ;-) Daniel (Magin)Comment by Daniel Magin [http://www.danielmagin.de] on July 4, 22:52
Delphi .NET Plans by Michael Swindell
@Concerned hobbyst: what do you need so badly that's in D2007 but not in D2006? I know real hobbyists (and not only) who deliver wonderful applications with much older versions. Is it just the "I need the last release" syndrome? Or something "worse"? Well, IMHO Swindell plans has some good points (forget compatibility, focus .NET efforts where .NET plays well) and some still bad ones (.NET is not a multiplatform solution, forget Mono - is just dust in the eyes, instead focus on Java, PHP, etc. which are *real* multiplatform solutions with strong support). Good to know that native compilers are going to deserve those attentions they need. Just one suggestion for Mr. Swindell: servers are not only "web servers" <g>. There are people that write native applications that run on the server side. Don't think only about "packaged/desktop/workstation" applications - they often today commumicate with some kind of server - thereby don't forget the needs of server native applications and the communication layer, please.Comment by Luigi D. Sandon on July 5, 00:43
Delphi .NET Plans by Michael Swindell
This is the best news that i have heard in a long time. I bought D8 mainly for ECO & delphi & was throughly disappointed. How ever the qulaity improved considerably & my knowlegde of ECO also went up considerably. I consider ECO + asp.net+Delphi .net cutting edge. Now i am able to make Delphi eco asp.net projects in a matter of hours (i am a single developer).I was worried what would happen with the new entity(though RS 2007 is more than adequate for my needs) Now I can rest easy that i can stick with Delphi. The aim should be to get back all those C# guys back into Delphi fold.Comment by VT Venkatesh on July 5, 10:10
Delphi .NET Plans by Michael Swindell
Hi Marco can we expect some Delphi .net (& ECO ) books from you now?Comment by VT Venkatesh on July 5, 10:20
Delphi .NET Plans by Michael Swindell
Dear Concerned Hobbyist, you have as much as admitted that you have no intention of paying any money to Codegear for the next 30,000+ days. And yet you have concerns that Codegear is not looking after you properly. Get real!Comment by moi! on July 6, 23:38
Delphi .NET Plans by Michael Swindell
Who cares about .NET? If I wanted to develop software for the .NET Framework, I would just switch to VB.NET or C#. Delphi is the best option on the market for the development of native software. .NET belongs to MS and no other software house can compare to them in that field. I'm not sure .NET is the way to go. The most important innovation .NET can offer is the use of byte code instead of (COM) native code. Nevertheless, byte code has its pros and cons. One of the advantages is that it allows you to develop desktop and Web-based software using more or less the same code. One of the disadvantages is that byte code is tremendously easy to crack or even reverse-engineer. Consequently, if you develop desktop programs for the general public, .NET may not be the ideal tool to use. Most Delphi developers couldn't care less about byte code, otherwise they would have switched to Java a long time ago. The second important issue is the "Framework hell" that makes application deployment an enormous headache. I have installed the Express Edition of VB 2008 on my computer and played around with it. The IDE is just great, the tools you have at your disposal are so many that they make you feel strong. I would love to develop my new commercial software in .NET. Unfortunately, I have conducted a personal survey among my customers (a few hundred users) and found that the majority of them do not have the Framework on their machines. So, I have decided to put off the idea of embracing the .NET technology to a better future. The size of the latest version of the .NET Framework has increased to 197 MB. Needless to say, considering that no version of Windows (Vista included) is shipped with .NET Framework 3.5, it would be suicidal for me to produce my shareware in .NET. There's still a huge need for native software in the world and that's what Delphi should aim at.Comment by Pasquale Esposito [http://www.espositosoftware.it] on July 7, 00:11
Delphi .NET Plans by Michael Swindell
The mere fact that .Net has a differently structured library means you end up approaching the same problem in different ways. Even garbage collection changes the way I structure code! Code compatibility between Delphi Win32 and .Net is the least of the problems. MS recognized this problem with Visual Basic years ago. At every conference I went to, I asked about VB6 and VB.Net compatibility, and we were shocked when every time, the Microsoftie up front would say, "Rewrite the lot." If you want to use .Net, use C#. Even on parallel developments (and how big is the market for those?)Comment by delfi phan on July 7, 11:31
Delphi .NET Plans by Michael Swindell
Perhaps it's time to stand back and think about what used to make Delphi unique, and translate that to the .Net world. It's true that backwards compatibility and forward migration paths are important, but I believe it's time to realize that .Net isn't just a new version of Win32. It's a completely different platform, almost as different from Win32 as PHP or Java. So, Delphi for .Net shouldn't be considered a new version of Delphi for Win32, but a completely different product, just like Delphi for PHP and JBuilder. As things stand right now, I will be using ECO + VS/C# for those applications where .Net is good/OK, and probably Delphi for Win32 for stuff where .Net isn't suitable. I just wish I could use ECO or an *updated* Bold for Delphi with Delphi for Win32.Comment by Kjell Rilbe [] on July 8, 00:20
Delphi .NET Plans by Michael Swindell
.NET, .NET, .NET, I understand that the blog I'm posting commenting about is about .NET and not about native Delphi. I've been with Delphi since almost the beginning (1995). And I must say that I've always loved and stood up for the language. If I weren't stuck in Minneapolis, i'd probably work for you guys, because I've done plenty of cheerleading for you over the years. I've built massive web apps in Delphi that to this day still dish out 2-3 million hits every day. I also sell one of the scalable multithreaded memory managers for Delphi. The simple fact that you can hook into and replace GetMem, FreeMem, and ReallocMem makes Delphi stand out among its peers even today, and makes me trust it for mission critical applications. It is hands-down the BEST for native code, particularly when the coe has to be fast and scalable. But I can say is that there is no way on earth I could ever possibly convince the higherups to favor writing .NET code in Delphi as opposed to C#. They would go for Mono before they'd go for Delphi. When you guys lose focus on catering to your core customer base by building incomplete, wildly experimental products, your core customer base starts to lose faith and eventually even the most die-hard delphi fan has to concede that there's no future for Delphi. Microsoft is pushing .NET 3.5 and if you plan to compete with them, you need Delphi for .NET 3.5 right NOW. You also need compact framework support and to integrate the Delphi language with Mono. If you can't decicate enough resources to making that happen, then you need to focus on your core niche which has been neglected over the years: Native Delphi. But since you've lost focus, even Native Delphi is missing quite a few things right now: 1. Still no support for Parameterized types. This should have happened at least 3 years ago. 2. Still no 64-bit support. 3. Optional garbage collection for objects would streamline the development process. After working in C# for a year, I realized how much time I spend in Delphi typing TRY ... FINALLY over and over and over. Look at Managed C++ and how they did it, classes can be garbage collected or not... your choice. You're really almost there. You can make something act like a GCed class if you just access it by its Interface, but then you've got duplicate headers all over the place, ugly. 3.5. It would be nice to be able to access an object by its interface without having to worry so much about interface reference counting. I made a mess a while back trying to reliably manage the lifetimes of persistent interfaced objects. Ever try to add an interface to a TButton? Have fun with that one! 4. C# is less restrictive with regard to circular references, maybe Delphi should be too. 5. A more complete implementation of operator overloading. 6. A naughty word: Macros. They make a mess of things, but sometimes, they get it done. 7. Delphi's Code insight doesn't quite stand up to microsoft's Intellisense. Intellisense can reduce the number keystrokes I need to build a class down to 1/4th it seems. Programming in delphi feels repetitive, especially when the lack of parameterized types and garbage collection make basic coding tasks more long-winded than C#. 8. Lack of Vista support, I know you said you implemented it, but you really didn't. I have a blog post that rips it to shreds. Practically none of the VCL controls work on a glass enabled form. A full GDI+ forms conversion is needed. 9. Networking features have been neglected. Indy just doesn't stack up to System.Net.Sockets. I have to use a 3rd party library for basic necessities such as cryptology, MD5 Hashing, etc. These things come for free in PHP and everywhere else. I wish the best for you, and I hope you can get it all together. I'm rooting for you over here. But I need to see new language features more than anything.Comment by Jason Nelson [http://blog.digitaltundra.com] on July 8, 20:08
Delphi .NET Plans by Michael Swindell
I have to be careful what I say because I'm not in Jason Nelson's league, but: > 3. Optional garbage collection for objects would streamline the development process. Having read and heard from many places that garbage collection is NOT trivial to implement, I am terrified of a buggy implementation in Delphi Win32. I can live with try..finally. I can see where things get removed. The "optimization" switch is bad enough. > After working in C# for a year, C# does many detailed things more elegantly than Delphi (2007). What is important is not the esoteric stuff, to me it's the day-to-day tools that make my programmer's life easy. > 4. C# is less restrictive with regard to circular references, maybe Delphi should be too. Just as Delphi's interface/implementation concept was an improvement on separate .h/.c (.cpp) files, I find the way C# requires no declaration section at all is one of those small things that makes a programmer's life really much easier. > 5. A more complete implementation of operator overloading. OPERATOR overloading? Do I understand you right; as in "*" does something else, depending on classes? This would be an example of esoterics that I'd use rarely. I'd sooner write MyMatrix.Multiply(MyOtherMatrix). > 6. A naughty word: Macros. They make a mess of things, but sometimes, they get it done. Indeed. Absolutely agree, after I had to move some well-written C code some years ago, my eyes were opened. Difficult to explain to people that have never been there. > 7. Delphi's Code insight doesn't quite stand up to microsoft's Intellisense. Intellisense can reduce the number keystrokes... Right. Again, it's the elegant, unintrusive tools that make programming faster. The equivalents in Delphi are not as smooth in practice. Two things I'd like to add: A) I cannot understand how the documentation for D2007 became so poor. In D5, the paper docs were also available in .pdf format, so why can these not be simply updated? Even with the latest Help update, I could not find even simple things, like how to use "mod" and "div". What happened to the Language Reference? Surely it's easy just to update it? The poor quality of the documentation is the main reason I cannot honestly recommend D2007 to friends and colleagues. I would be inundated with trivial questions on it's most basic use. B) The only reason I still use Delphi is because there is no realistic alternative for Win32 projects. For this reason alone, I really, really hope and pray we get a Tiburon that's solid and industrial grade.Comment by delfi phan on July 9, 18:59
Delphi .NET Plans <> Less Win32
I think it's very important to note that this next step in .NET strategy will not have a negative impact on Win32 Delphi. In fact exactly the opposite, native Delphi will go forward faster and very much in the core spirit of Delphi - with a greater focus on native speed, language, VCL/GUI, and database.Comment by Michael Swindell on July 10, 11:17
server <> web servers
Great point Luigi. Keep an eye out for the upcoming Datasnap in Tiburon. Building native server based apps and middleware (not just db middletiers) in Delphi is going to get very powerful and very flexible and very easy.Comment by Michael Swindell on July 10, 11:22
Delphi .NET Plans by Michael Swindell
Hope this step in .NET strategy will not have a negative impact on Win32 Delphi.Comment by mailer@trial.com on July 16, 07:53
Delphi .NET Plans by Michael Swindell
@ moi! - You read waaaay to much into my post that really wasn't there. Yes, I'm using the freebie version, why? It does what I need it to do. The PRO version would be massive over-kill for me. Would I buy the Turbo Delphi line if they released a new version of it? You bet I would... provided it wasn't too expensive (say $150-$250). My concern is that there will not be a cheaper version to purchase than PRO.Comment by Concerned hobbyist on July 18, 03:46
Delphi .NET Plans by Michael Swindell
Seems like Delphi RAD already lost the battle with Microsoft. VS2008 Pro+MSDN Premium cost around 2500$. With cutting edge technologies support, proper documentation etc. With army of coders and millions of forums and blogs, with huge collection of free and commercial components etc. What we getting in CG RAd Studio 2007 Box? For about 4000$ you'll get obsolete IDE, buggy debugger and incomplete documentation. Don't even dream about documentation - really few books and tiny amount of blogs and forums. Guys give us a break! CG Rad Studio should cost no more that few hundreds for all the "features". P.S. I use to like Delphi and still using for Win32 projects, because its simple straightforward and quick. And after years of coding in Delphi have to move to VS2008(C# mostly). P.P.S. ECO is good addon but its available for VS too.Comment by LEX on August 10, 22:07
Delphi .NET Plans by Michael Swindell
Embarcadero will cut loose ECO (Nick Hodges quote) Where does that leave us poor buggers who use it with Delphi?Comment by aussie on September 5, 07:25
Post Your Comment
Click here for posting your feedback to this blog.
There are currently 0 pending (unapproved) messages.
Delphi .NET Plans by Michael Swindell
Comment by Roland [http://beensoft.blogspot.com] on July 3, 13:08