Comments bellow. First see the roadmap here.
My first impression is “Nothing new”. This roadmap was presented in general lines at Delphi Live! and outlined in different blog posts like this one, for example.
2nd impression was… a somewhat negative stance: “Slideshows for a roadmap?” …but ok, we must minimize the costs (including time) and it seems that Mike posted the slides from CodeRage 4. (I don’t know exactly, I didn’t attend). For the ones like me who cannot attend, the replays are here.
3rd impression was “hmmm… Project Weaver. – on the roadmap”. The roadmap is dated 9/11. Hmmm… Mike (as Delphi Product Manager) doesn’t know that Weaver was released? hmmm…. Fortunately Delphi 2010, while not perfect, is much more polished than Mike’s slides (hey, Mike we do love you, and you have all our respects, but perhaps is better to remove that ‘Project Weaver’ here – it looks a little bit outdated – also perhaps someone which will read more carefully will be tempted to compare the ‘roadmap’ with what was delivered… …or perhaps you’ll plan to include new features in updates? 🙂 )
4th impression: skip 🙂 – I’ll leave this the last one… about the what version is when
5th impression: Let’s look at the following slide…
Wowza!! SONS! You screwed it up here!
From Embarcadero: To help customers understand and plan for where RAD Studio is going in the future.
No, sons, it is in the other way around in my very humble opinion:
From customers: To help Embarcadero understand and plan where RAD Studio is going in the future. One Kylix isn’t enough? One Delphi 8 isn’t enough? One VCL.NET isn’t enough?
Ok, blame me, it wasn’t one VCL.NET. There were… how many? Nevermind… let us remain focused.
…And, of course, related to this is:
To customers: Understand the direction of the product in the future
Sons, it is:
To Embarcadero: Understand the direction of the product in the future. Understand the needs of the community.
Also, another pearl (but not so big compared with the above one):
To customers: Be able to interact with Embarcadero to make the best products possible.
Here we agree. But it must be written also…
To Embarcadero: Be able to interact with the customers to make the best products possible. As EARLY as it gets!!
Ok, I don’t say to interact with all your customers, but you must do it, you know…
In order to be sincere, I must clarify some things here. Generally speaking, as you perhaps know, Nick is quite present in the forums. Also a part of team (enough people I’d say) were available in the Field Test. While, of course, the things can always improve, I’d say that the things get better. But it seems that there’s a demarcation line between the upper management and the in-the-field soldiers, demarcation which became bigger with Nick’s new position. And it seems that sometimes the upper management doesn’t “get it” – and this NOT because they’re dumb, just because they doesn’t have seamless contact with what is really happening “in the real world”. I don’t want to give examples here, but the problem is real in my humble opinion. If someone thinks that the things are different, I’m open for discussion.
And the last point, (the 4th above) is about the chronology: Well, what I could say? Good one. But I can say only one thing: Embarcadero’s worst enemy is the time. No doubt, that some from us would want Commodore before Chromium (before Project X isn’t possible – this one is already in the works). But I’m afraid of the quality of the Project X…
And this depends on you. If you give high quality feedback, then you’ll receive a good quality product. Already Nick posted a poll here – be sure to fill it in, or at least, if you don’t use GExperts, comment on his blog post. Perhaps I’ll do a similar one for CnPack. Another very interesting poll, this time by Tim DelChiaro, is here. Be sure to fill them out!
I do think that if we got a good Project X out of the door, then the release date(s) for Chromium and/or Commodore can be closer or even swapped because they’re working at more projects in parallel. I do think that we must stop having endless debates about cross-platform vs 64 bit. Anyway it won’t help. Also, let us not remind them (yet 🙂 ) how “horrible they are” ™ . I think now is the moment of constructive feedback (criticism or not). What do you think?
Wings of Wind Software 
Some random thoughts:
– I assume this ‘roadmap’, pathetic as it is, is Nick Hodges’ doing, which I mean in a good way – i.e., it looks like upper management had no intention of publishing any sort of roadmap whatsoever.
– The small polls you mention at the end are rather different in character IMO – while Nick’s appears to be with the thought of getting certain GExperts features into the default product, Tim DelChiaro’s seems to be a poll for marketing purposes (which of course, is not a bad thing in itself).
– ‘ Wowza!! SONS! You screwed it up here!’ – um, not got much sleep recently? By definition, a ‘roadmap’ will be stating where the product is going, not asking for where the destination should be.
– Moreover, while finding out what existing customers hope will be the product’s direction is plainly a good idea, I disagree with your insination that this should be the ‘be all and end all’. E.g., the nature of the old Kylix product was in a large part due precisely to the aim of meeting existing user expectations, particularly in the idea that the product should be ‘complete’ in the way Delphi was (and is) — so, a focus upon desktop rather than just server apps, and having as an ideal ‘just recompiling’ to target another platform. This then led the agreement with QT half way through Kylix 1’s development and the disaster that was CLX (‘help! we need to re-implement a high-level, yet highly Windows-centric visual component framework on a non-Windows platform!’), and moreover, helped contribute to the overstretch of resources caused by trying to maintain a ‘full’ Linux version alongside the original Windows product.
– As for the 64 bit compiler – I’m guessing Embarcadero management (and maybe even parts of the development team) want to push this back as far as possible so that when it does come, the 32 bit compiler and VCL will have to be maintained for as short a period as possible, minimising the impact upon resources. Cf. the unicode switch – if a unicode VCL had been released back when people were originally calling for it, there would have had to have been yet another ‘VCL’ to maintain during the dark years. Just imagine it: a D2005 or D2006 even buggier than they actually were!
Of course, this needn’t be a convincing argument for delaying a 64 bit compiler – personally, I think an approach that pushed one out with RTL but no VCL support would have been fine, but I can just imagine the whining in the forums if that had happened or were to happen…
– I don’t know what’s going ‘inside’. But yes, I do know that Nick pushed for it.
– Yes, the polls are quite different – and I didn’t meant to have the same nature. My apologies if I wasn’t clear.
– 🙂 Yes, I need some sleep. But as it was till now in some degree, and in other communities is in a greater degree, the roadmap is a living document IMHO. So, putting it like “this is it. Accept it. You must help us to accomplish it. Any resistance is futile. You will be assimilated” it’s a little bit harsh imho. FTR, I don’t think that (as I said) the Team thinks like this but some Borland thinking here and there…
– “I disagree with your insination that this should be the ‘be all and end all’.” – yes, sure. The point is that any company has a natural tendency to turn to itself and forget about it’s user base. The problem with Kylix was that they stopped to communicate. Yes, initially the situation was as you described, but when they realized that the things became ‘sensible’ they should ask for feedback: “This is what you really wanted?” But this doesn’t happened. And the result is known: while in that famous poll an overwhelming percentage said ‘Yes’ to the (theoretical) Kylix there were very few who actually supported the concrete deliverable.
– About 64bit: interesting position, but time will tell. We’ll see 🙂
“32 bit compiler and VCL will have to be maintained for as short a period as possible”
It doesn’t work that way. If an app doesn’t have to be 64-bit, it’s probably better off as 32-bit. Pointer sizes are half as large, therefore your data is smaller and you can fit more in the CPU cache, therefore your app is faster. (You do want a 64-bit *OS*, but you probably don’t want 64-bit *apps*.)
Here’s a much more detailed explanation: http://blogs.msdn.com/ricom/archive/2009/06/10/visual-studio-why-is-there-no-64-bit-version.aspx
Which means, the 32-bit compiler and VCL will need to be supported for a long time yet.
+1
My impression is this:
2011 = Cross Platform
2012 = Reliability (needed after releasing a brand new 1.0 awesome compiler)
2013 = 64-bit
Now my predictions:
I predict (and hope) that the Linux binaries produced by Delphi 2011 run better on Linux than Delphi 2010 binaries under Linux+WINE. Note how much WINE improves every 2 weeks and extrapolate 12 months. This might not be easy, but I’m rooting for Embarcadero.
I predict 64-bit Windows will have greater market share than Linux desktops and Mac OS X combined within 12 – 18 months.
Delphi developers who assumed they don’t need 64-bit will upgrade their PCs and suddenly discover that their 32-bit Delphi DLL won’t load into the same process as a 64-bit MSVC programs on their new PCs.
Next they’ll blame Embarcadero for not shipping 64-bit first, and will conveniently forget it was their votes & insistence that helped shape Embarcadero’s roadmap.
At that moment, it is critical for Delphi 2011 to produce apps that run better on Linux than Delphi 2010 apps on Linux + WINE 2.x. Otherwise, multiply the whining by 10x.
I admit I was wrong about insisting on Cross Platform first as recent as this summer. After all, I didn’t write shell extensions or drivers or needed > 4GB in my programs so I thought I was safe until the 32-bit DLL compatibility issue hit me in the face. I hope the percentage of Delphi developers that encounter this is small.
FWIW, I applaud Embarcadero’s fine 2010 release (I would have been scared if they shipped 64-bit or cross platform this year because such a huge task SHOULD take longer to do properly).
@Rich:
If you are correct, and 64 bit support is ~3-4 years away, then we are in big trouble. I might as well wind up the Delphi -> C# CODEDOM and move to Dev Studio/TFS with the rest of the herd.
@Embarcadero: Publish a road map you are going to follow, and put some dates on it (even M$ does that). Do it soon please, we have decisions to make.
Raymond.
While I cannot speak in their name, I know that they work in parallel on all these projects. For ex. Code Formatter was for Chromium but is delivered in Delphi 2010. Also, see the poll which Nick made about GExperts. This is rather included in the Chromium theme and not in Project X, isn’t?
OTOH, while I do think that perhaps they will want to push 64-bit as late as possible (don’t think at evil intentions) I also do think that they will not afford it. Just give the right feedback. Also a good organization / workflow is needed.
Where’s the roadmap? I just saw the same Santa Claus letters. Also it’s not cleat what will happen to the VCL. Will there be a VCL (ported to 64 bit) and a XCL (let’s forget CLX…), or the XCL will become the only available component library?
That’s not a secondary issue, and Embarcadero should be clear about the direction they take. As far as I can see Windows will stay our main platform, and we need to offer the best GUI we can on that platform. We can think about targeting other platforms, especially our server applications, but not at the expense of losing our powerful and well integrated Windows GUI.
It will also have a deep impact over any third party controls, the bigger the effort to migrate them the more probable they could be abandoned if Delphi market is not large enough to justify it. And adapting the controls to even more platforms means a bigger effort too. Less powerful controls will make Delphi far less appealing for client applications development.
And the question is: should we wait until it is too late and Embarcadero delivers a tool we don’t need because they are still chasing butterflies, or should we jump out of the boat ASAP?
Hello all.
Mike Rozlog here, the feedback on the list is excellent, and please keep it coming. I want to set the record straight, this roadmap was produced by me, it is not Nick’s and so if there is any criticisms for the layout or what the roadmap states, the blame comes to me, not Nick. I’m just excited to finally get the roadmap published, finally, and I’m hoping and working to make sure it stays published and up to date.
I want to make sure the RAD Studio community, which is made up of Delphi, C++Builder, and Prism products has an idea of where the product is going. I want to make sure you as a community have a direct line to me, if you have watched any of my webinars or CodeRage presentations I always ask for feedback. Again, my email address is michael.rozlog@embarcadero.com, I would much rather hear your concerns with the product direction, features, and functionality now than after we release a product and everybody is disappointed.
My desire is to update the roadmap often, or around every 6 months or so… sometimes it may be sooner and sometimes it may be a little longer, but I believe that communication is the key to getting the community excited about the things we are working on to help the developers using our products build better software in a shorter amount of time and deliver real value.
So again, we finally go a roadmap published, I’m working hard to keep it up to date, so expect after a little while that the Weaver slides will go away and more details will come with the other projects, and keep, and I can’t repeat this enough, keep sending me your complaints, your desires for the products, and your thoughts on how we as Embarcadero can communicate better and continue to build the best development environment in the world.
Mike
All,
Sorry I just notice a small typo on the last paragraph (got instead of go). It should state:
So again, we finally got a roadmap published, I’m working hard to keep it up to date, so expect after a little while that the Weaver slides will go away and more details will come with the other projects and keep and I can’t repeat this enough, keep sending me your complaints, your desires for the products, and your thoughts on how we as Embarcadero can communicate better and continue to build the best development environment in the world.
Mike
To Mike… I don’t know how much more feedback you need Mike. During your CodeRage presentation you managed to obfuscate answers to both my questions relating to delivery timelines. Noone expects a specific date, or a fully defined feature set. In relation to new projects that have never arisen before, I think you can justifiably leave them hanging with no mention of a delivery window. Contrast that with projects that have appeared on numerous past roadmaps with slated release windows. It may well be a non commercial view on my part, but I think there is a question of integrity here. Let me clarify; I am talking specifically about “Commodore” as it became know some time back.
From a suppliers point of view, I can understand your position with regard to this, but as you keep telling us – “it’s about the customer”. We’re a small ISV who happens to deal with customers of very varying sizes. Our Delphi requirements are simple in many areas and yet very demanding in others. For years now we’ve been waiting for the much vaunted 64bit solution that appears and then vanishes like a wilo-the-wisp. Your delays become our delays, only being a far smaller enitity we have much greater difficulty absorbing the shocks that your changes of direction cause.
To be honest, I think this latest round of non information is about all we can take. I don’t say that with any malice or hope of this changing the super tankers direction. I say it with a sense of resignation and sorrow that I can no longer put up any defense of Delphi as our long term solution.
At the end of this month we have yet another meeting with one of our long term partners who have been pushing for the last 18 months for us to make our next generation of product part of their stable. This is a C# solution. Whether this actually gets traction or not, I can’t say, but what I can say is that your roadmaps and hopes of a bright future can no longer play a part in our planning. We will be a 100% Delphi house for the next 12-18 months, implementing some AWE memory mapping techniques. As that runs out of steam, which I already know it will do,we need another solution. Whether our paths will cross at that point, I can’t tell you.
Caveat emptor; at all times….
Paul,
I’m sorry that I did not answer your timing questions. It is not my intention to obfuscate information from you. We are currently working on multiple projects and we want to get the technology out to you as soon as we can. I can’t give you any specific dates, however, as it has been stated in the press and during the Delphi Live event the next big feature we are working on is cross-platform for both Mac and Linux.
Please also let me know if there are other features you are looking for beyond or besides 64 bit or is 64 bit the only thing your business needs to be successful?
Please let me know,
Mike
It makes me angry to see this roadmap. I need 64 bit. Now! Due to memory demand > 3 GB. I can’t understand, why MS offers a VC with 64 bit.
I read that Barry Kelly is rewriting the compiler (from C to C++). I have a very bad feeling about that.
In recent times, things get worse after such “actions”. Delphi 7 IDE –> BDS 1.0. Delphi 7 hlp –> Delphi 2005 MsDocExplorer. InstallAware installer issues…etc…etc…
I hope, Emba will go back to “working mode”…not wasting their time and money with “IDE improvments” like Formatter and other cosmetics!
Surely 64bit is a niche need?
But I do agree, if you need it and you need it now, you have a difficult decision to make.
Embri is cleaning up Delphi after a long period of neglect and is simultaneously releasing versions that, whilst clearly playing catchup, are doing so fast.
The Formatter in VS saves me a lot of time during refactoring. I welcome this kind of IDE assistance in Delphi.
All,
I’m working on survey for the RAD Studio community, I would be very interested in knowing what other features, functions, or characteristics you believe would make the product more usable.
Things like more refactoring, more/easier unit testing, easier database access and usage, etc… you name the ‘thing’ you would like to see, I want to hear about it.
Mike
Hello Mike!
OK here is one more meaning: do you know DOA components from allroundautomations.nl? The integration of SQL developing tools with Database components is marvelous (from inside of delphi you can start SQL developing tool having loaded the SQL code from Delphi).
When I had to switch to developing for MS SQL Server I felt going back to stone age. It took me months to check out tools with which I could work nearly comfortable as before for Oracle.
So me beg is: create this kind of integration between SQL developing tools and database components for delphi!
Thx,
Fritz
Ok, son, preparing… Also the other comment was heard. 🙂
Releasing this roadmap is so clear that Embarcadero admits it can’t support its customers. The need for 64bit native programming is not now, it was 3 years ago, not in 3 years from now. I can’t understand them. Who cares about Code Formatter, IDE Enhancements and these kind of crap. Cross Platform Programming is useless for 90% of their customers. If i had to go .Net, I would have already chosen C# and Visual Studio, not Delphi Prism. Let’s face it, Embarcadero can’t implement a serious improvement in their Delphi product line (we keep asking 64bit for 4 years now). They keep releasing versions every year without introducing something truly new, just minor enhancements and stuff like that. The only viable solution at this moment is .Net Platform. I keep pushing my company to wait for the next version of Delphi (Delphi 2011, I believed it would support 64bit), I can’t tell them now they have to wait for another 3 years.
Freepascal/Lazarus offers a 64-bit solution since years. The compiler core team consists of 2 or 3 peopble! They work for free. I don’t understand why Emba ist not able to do that? Only for the Windows platform first….it’s horrible!
Many do care about features which you mentioned. OTOH, your concern is quite understood. Perhaps that you don’t know that they work from quite time now on the new compiler. Btw, why do you want 64 bit?
Isn’t it true that even now, most motherboards have 4-6 slots?
I can only find a few Intel boards that support 64-128GB, and they are expensive items.
why I want 64 bit?
We all the know Delphi is the best language for building n-tier database applications. From day one, programmers (Embarcadero Cstomers) loved this language for RAD Programming DB Applications. I work in a Software House which builds n-tier apps for 1000 companies n Greece. Our customers purchased expensive servers and databases (multi processor systems, with Oracle 64Bit, alternative SQL Server 64 Bit). I can’t tell them that our Application Server (and other server applications) doesn’t support 64Bit processing or large memory management.
There are over 100 clients in every application server in a distributed environment.
I assume that many of you want multi platform. I have the same problem too. Many of our clients purchased Oracle for Unix, I would like to portion our server applications to this new environment (performance reasons). But this is a nice to have in future. 64Bit processing (even after the introduction of Windows 7), is a must now.
“Oracle 64Bit, alternative SQL Server 64 Bit”
Sounds like you are still in the evaluation stage?
I which case, I imagine you are answering broader questions than just “Shall we use Delphi or not”. Could be there are off-the-shelf tools and products already suited to the system you are considering.
“Oracle 64Bit, alternative SQL Server 64 Bit”
Sounds like you are still in the evaluation stage?
I am not in the evaluation stage. We offer 2 alternatives
for the database system, depending the number of users e.t.c
(if the customer has already installed Oracle, he may use the current
installation. Small – medium organizations usually purchase SQL Server,
large companies already using or purchase Oracle).There is no line of code in the DB System, businness rules are in application server, so we may use both DBs.
We have also implemented a number of applications supporting our main application (ERP Application), such as WebServer connecting to A.S for Web Access, tools for export/import data, customization tools etc. And guys believe me, I am writing Delphi Code for 13 years after 7 years of C++, It saved me. I love the simplicity and power of this language, I was never disappointed whatever I was implementing. Delphi 7 was the best Development Tool ever. After 10 years or so from Delphi 7, ask yourself a question. Is there something I can’t do with Delphi 7 and I can implement it with Delphi 2010? Is there any big difference between these 2 versions(except perhaps UNICODE)? We are talking about 10 years.
Check other frameworks, languages, IDE tools in that time of period.
Agreed. We are pretty much in a similar, but smaller, boat. Coincidentally we are also in a similar application space. Delphi has such a lot going for it, but I think as a company Embarcadero pay somewhat too much attention to the latest fads. They do like to build something of everything new into the product. So we’ve had .NET, Kylix, the new IDE et al.. Lots of good stuff in there as well over the last few years, but I do despair at the eye candy that keeps getting loaded into the product, especially when it’s at the expense of the blindingly obvious.
64bit for us is about the address space. We need memory resident data structures that can handle more than 4Gb of data. AWE in one form or another looks the one and only option for this and I’m currently looking around to see what if any options exist in this space. NexusDB has an AWE enabled external server, but apart from that it seems there is noone offering something like TAWEList (AWE enabled TList) for example. Anyone want to offer a solution here? If Emabarcadero aren’t delivering 64bit Delphi anytime soon, there has to be a niche for such a component set (TAWEBinaryTrees / TAWEHashTables / TAWEStringList etc).
“Is there any big difference between these 2 versions(except perhaps UNICODE)?” – Delphi 7 and Delphi 2010 (n.n.)
Oh, yes! Even if this cannot be seen in the first 5 minutes. IMHO, the biggest differences are in the programmer productivity.
Generics, anonymous methods (from D2009), the new RTTI (D2010), a collection of classes which use these new features which are shipping with Delphi – all these make a great difference. I was impressed few days ago when I wanted to port a D2010 piece of code in an earlier version. I felt it very hard to do it.
I can’t see more productivity. The IDE is much slower than the Delphi 7 IDE. Due to .net functionality. The the IDE os overloaded with feature I never use. During work, on the left and right side windows and texts are flickering. The compile process is much slower than in D7 (I guess there is also .net on board).
“The IDE is much slower than the Delphi 7 IDE.” – You mean Delphi 2010? What is your hardware spec?
“During work, on the left and right side windows and texts are flickering.” – Cannot reproduce. Which windows?
The compiling process doesn’t have to do with .NET – if is slower (cannot compare – for me is quite fast) is due of language enhancements. But the main point is not if we wait 1-2 seconds more on compile phase but if we have language enhancements and tooling which will help us to be much more productive overall. But, I agree, a learning curve is needed.
All,
First off, for IDE Insight alone, the upgrade is worth it. Click either f6 or ctrl-. to activate the feature. For those who don’t know, the IDE can now look and act just like Delphi 7 if that is what you want, from a look and feel point of view. There was a good amount of work done to make 2010 work/display like Delphi 7 and below.
Demo of how to do that: remember F6 = IDE Insight
9. Now lets move to the designer outside the MDI look and feel
a. F6-Embedded Designer (takes you to the options)
i. Unselect designer
ii. Close IDE
iii. Restart IDE
iv. Show Designer
v. Set layout to classic
b. F6-Embedded Designer (repeat but embed the designer again)
I actually find that I like the MDI (the 2010 normal view) with a disconnected Form designer, especially using a multi-monitor setup. I still work with both environments and I do not see the massive difference in startup time, when I use D7 on a P4 (hardware available at the time of D7’s release) and 2010 on Quad, the times are almost identical. If I put D7 on the Quad it does load faster on base (clean install) but I notice when I add my 3rd party components to both d7 and 2010 the startup time is around the same on my quad. Working inside the IDE I do not notice a difference in response.
Does the environment have tools written in .NET, yes, but the difference in speed is very hard to notice… usually there are other factors, accessing the database remotely, network, etc. Plus, many features are loaded only when activated. As many of you know I use UML, Audits, and Metrics all the time and on my machine, I very happy with the performance and memory consumption.
Flickering on both sides, could you give a little more example of that, I don’t see it on my work machine or my Quad. Maybe you are doing something that I’m not, if you can tell me how you have your 2010 configured maybe I can figure it out.
Compilation times are very comparable, the output size is a little different but the actual time it takes to compile is not much different. Again, keep in mind that there is NO .NET being compiled during a compile. I would say the size difference is do the the new RTTI features, but speed is still there.
If anybody can get reproduce-able steps to show slow down or have issues where slow down is a problem, don’t hesitate to email me and I will put it on the list for prioritization. Also, don’t forget about QC.
Talk to you soon,
Mike
Atta boy! 🙂
These posts we need from you son!
Aha! Got it. So your main concern is memory barrier imposed by 32bit addressing, right?
In a nutshell, that is it. We need to get at more memory (preferably without jumping through too many hoops (AWE etc), or unnecessarily restricting the OSes that may be used (Windows Server etc)).
With the current Win64 implementation, we can get at up to 8TB of memory which should keep us going for a while 😉
Anyway, we can’t use Delphi 2010. .net is locked by our admins in our company net due to security reasons. So the majority is working with Delphi 7.
???
Boy, you have very interesting sysadmins. 🙂
OTOH, see this – also see the next page there (link in the bottom). The info is for D2005 but is should give you the idea how to fix it for D2010 – the IDE is more or less the same in these parts.