It’s tempting (not to mention completely understandable) to selectively choose the positive comments and not at all surprising that there are no negative comments to be found among the list quoted. But you should be careful to avoid potentially embarrassing credibility gaps.
First up and top of the list:
I’m very excited about the integrated SVN support, since I rely very much on SVN in my own projects. Having SVN accessible directly in the IDE certainly gives a whole new meaning to the RAD concept.
Don’t get me wrong, SubVersioN (yuck) is great, especially for the price – I use it myself!
I’d even go so far as to say I rely on it. Which is why I, similar to many people who rely on such things I should think, have been very happy with the IDE integration already possible with SVN technology from numerous sources. In my case, an entirely free one – the open source JCL project.
Anyone that is similarly reliant on SVN is I think going to wonder at how someone who claims to be reliant on it hasn’t been making the most of what was already available.
Then there is this:
The Unicode support introduced in version 2010 is a huge benefit, and has already been put to a very good use. The migration was almost effortless, making Delphi the only product we have ever used that allowed switching from non-Unicode to Unicode version in matter of only few days.
Whoops. “Introduced in version 2010”? I am guessing that whoever made this comment isn’t actually doing much REAL Unicode, otherwise they would have been painfully aware that Unicode support was of course introduced in version 2009.
And finally from the “Mind the Credibility Gap” desk:
We are using Delphi for Win32 since 16 bit version, and we can confirm that, Delphi 2011 has the strongest feature set from the history.
A 16-bit version of Delphi for Win32? Neat (presumably we are all currently using a 32-bit version of Delphi for Win64 and just quit complaining about the lack and continued further delays of Win64 support).
In all seriousness, I imagine that English was not the first language of some of the contributors to this list, and I don’t mean to poke fun at them. I merely raise a figurative eyebrow at the people in such a hurry to compile this list that they don’t apply a slightly more rigorous credibility filter to the exercise.
What’s the rush?
What’s the panic?
Feeling a little sensitive and vulnerable perhaps?
We now know that any faint hope that the cross-platform ambitions for this release were being held back for a big reveal after teasing us with a slew of underwhelming feature previews were in vain.
Project Fulcrum has seemingly been re-designated a productivity release to fit in with it’s timeframe at the cost of it’s content.
What was previously in Fulcrum is now designated Pulsar. And we have a new project: Wheelhouse (but is anyone at the wheel?).
Commodore remains unchanged in headline ambition but is unsurprisingly pushed out yet another release, but I have to say that the whole cross-platform/64-bit message is a bit of a mess with mentions in Fulcrum (now referring to cross-platform web), Pulsar AND the new Wheelhouse AND Commodore.
I have to say that after reviewing the new roadmap I wasn’t left with a clear sense of direction and planning, rather my head was spinning.
I checked out the JCL SVN integration. It appears to be a rehash of another SVN integration attempt I have seen (and discarded).
The new SVN integration shown in the video looks superior to the JCL effort as far as functionality goes. The JCL version has all the bells and whistles, no question – but it really doesn’t really seem to add much to the process aside from nesting most of the common fuctions into menu based macros. Usability itself seems to, well, second class.
I will reserve final judgement until I get my hands on XE to compare.
AS for the rest of it, it does all seem to be up in the air marked as “Eventually and or never” – which isn’t really helpful in a road map.
And just what the heck does modernization of the VCL mean anyways? Terms that vauge might as well be something like “orangify the call stack loopback adapter” – it could mean ANYTHING, or more likely nothing to fill a bulett point they never actually have to deliver on.
I wonder if the codegear team uses the same roadmapping internally for the embarcadero big wigs.
One thing I am hopeful about – it looks like 64bit is winning out again over cross platform as the next big feature to get implemented. Maybe we have Gates’ draconian developer abuse vis a vis the iPhone SDK to thank for that.
@Xepol: The JCL SVN integration works well for me, and there are others of course. ymmv (and clearly does – or did when you last looked). 🙂
Now, what they have incorporated in the built-in integration may go further, but my point in this case wasn’t the feature set itself, but rather to question the wisdom of referencing glowing testimonial from someone praising not a specific aspect or feature of the IDE integration but (seemingly at least) merely the very idea of it.
To me it gives the impression that the people using Delphi don’t have much of a clue about where IDE technology has been for the past few years.
And LOL at the “orangify the .. etc” … 😀
Using Team Foundation Server …
@Adam: You have my deepest sympathies. 🙂
Can I now read the roadmap as saying that Pulsar will give us a full 64bit Delphi for windows ?
That is the one and only question that is of relevance to me.
As some others have pointed out, despite the lack of timelines, the only logical order for release would be as listed in the roadmap. So… Pulsar in 12 months time i.e. Delphi XE2 ?
If the preview command line compiler does make it out the door within the next 6 months or so, it would seem reasonable that a full product might follow this time next year?
All things are subject to change (and the law of sod says they will be yet again), but are we finally within spitting distance of 64bit Delphi for windows ?
If anyone is looking for me, I long ago left hope and expectation behind, I now live in desperation….
@Paul: Yes and also no.
Pulsar mentions a 64-bit implementation but isn’t entirely clear what this means. A cross-platform VCL is mentioned only as being “under consideration” for Pulsar.
The preview compiler for 64-bit Windows is slated for “1st Half of 2011”, and I would be surprised if that means the first 3 months (otherwise why not “1st QUARTER 2011”?) so you are unlikely to get your wish for a preview in the next 6 months.
Commodore (XE3 eta 2012 presumably) remains the full implementation of a 64-bit Windows compiler, debugger etc for Delphi, and even then, key features of what most people would consider a “full implementation” are expressed only as being “under consideration” even for that release.
If you consider 2 years “spitting distance” then you are in luck.
Some people may be spitting, but I don’t think it is in order to perform any sort of distance measurement.
I worked for Borland partners in Argentina and Spain. As a certified Delphi trainer and beta tester I was asked many times for sharing my opinions about new upcoming releases, always with “suggestions” similar to the ones published this time.
It’s always good to start the day with a laugh, but when it’s about your main development tool you start to be worried. It’s clear they didn’t even take the time to edit those post properly, and just slapped them in in a silly attempt to justify this strange release.
They look more and more like the former USSR, they use anything, even silly stratements, trying to justify a falling system unable to cope with the actual world.
@Jolyon. Agreed. The description on “Pulsar” is quite ambiguous, especially considering it looks like is “must” be the next release.
As you say “Delphi windows 64 bit implemention”, I would normally read that as saying, “yes guys, you are getting a 64 bit IDE and compiler for Delphi on a windows platform”. Given the next bullet point talks about Native 32 bit cross compilation for windows and Mac, I’m sceptical as to just what the 64bit ness is ?!
When you then go on to Wheelhouse, you can imply that actually Pulsar must have given you a delphi 64 bit compiler as they are extending the implementation to C++. Again, that could mean that you just get whatever 64bit ness the produced in Pulsar for Delphi transplanted into C++.
All quite unclear…
My position is that we are way past desperate for 64 bit and our business has had to wilfully neglect the customers (big ones of course) that need a 64 bit address space. We have moved in slightly different directions since the compiler rewrite was announced, but we still need Delphi… Actually we are about to need Unicode for the first time, so ironically it looks like we will be an XE customer after all.
I’ve asked the questions of Emb and specifically Mike Rozlog in the past about helping those people that need 64 bit address space, but with no success. It is far from easy, but what we need is a memory resident container (think TList) that can be used as if it had 64 bit address space. Sounds possible, but I know it is far from it… However, I would have thought that since this is one, not the only, but one of the main reasons for going 64 bit, that Emb could invest some time in writing some functionality that would help the community while we wait and wait for 64 bit…
On the positive side, there seems to be more emphasis on 64-bit now. I’d say that is a Good Thing.
I’m not sure I understand the roadmap. Are they working on TWO 64-bit compilers? (native win and xplat MacOSX/Linux?
And a cross-platform VCL – isn’t that Kylix CLX?
…oh, sorry, just read Paul’s comment. I’m evidently not alone.
@Jolyon,
It sounds like you think only a partial implementation of native 64 bit Windows support will be available in Pulsar, and won’t actually be ready until Commodore, possibly 2 releases later.
This isn’t how I read it. The native 64 bit mentioned in Commodore seems to be extending the Mac and Linux support.
The biggest changes from what I previously thought was being delivered are:
– Mac support didn’t make it in to this release and is pushed to the next one.
– Native 64 bit on Windows has been pushed ahead of Linux support.
@Bruce: It’s not me that think that, it’s Embarcadero – I’m just relaying what they put in their own road map:
“Pulsar” – a very vague reference to a “64-bit implementation”. This could mean [and I think it does] a 64-bit IDE implementation with a compiler that targets only Win32, plus Mac.
As Paul pointed out, “Wheelhouse” then extends “Fulcrum” level 64-bit “implementation” to C++ Builder.
The phrase: “Full support for 64-bit *COMPILERS* for Windows/Mac ..” etc does not appear until the “Commodore” slide, and it is also only in the Commodore slide that mention is made of targeting optionally Win32 or Win64 (what? Is Pulsar 64-bit only? or will Pulsar toss a virtual coin and choose 32/64 for you every time you compile? ;)).
@Jolyon,
I guess it depends on how you interpret this line under Pulsar:
“Delphi windows 64-bit implementation”
Sounds like 64 bit support to me. If I had to guess, I would say that this will be in the form of a cross compiler, just like they planned for the Mac support. It’s kind of a stretch to say that it’s a 64-bit only IDE that cross compiles to 32 bit Mac.
The comments in Commodore read like they’re extending that to Mac and Linux. And I’m sure there will be some refinement for the Windows compiler along the way. Even the option you mention is to compile 32 or 64 bit to all platforms, not just Windows.
Do you think they’re being sneaky and not really delivering native 64 bit support for another 3 releases after XE?
Tell you what. If either the IDE or compiler in Pulsar is 64 bit (no Win32), I’ll march on the Embarcadero offices with you.
@Bruce: No, it depends on whether you ignore the line under Pulsar:
“Cross-platform Native 32-bit Windows and Mac OS X compiler”
I really don’t see how there needs to be any interpretation here… “64-bit” is paired with the vague and ambiguous term “implementation”. The term “compiler” is only used in conjunction with 32-bit and Mac OS. Further more this fits perfectly with the original plans for Fulcrum (Win32, Mac and Linux and THEN Win64), which is precisely what you would expect if what had happened was slippage rather than chaotic re-shuffling of project objectives (the idea of which frankly I would find even less comforting).
Note that a Linux compiler still get’s mentioned before a Win64 compiler tho (Wheelhouse vs Commodore). Maybe I’m putting too much into the distinction between “implementation” and “compiler”, but why beat about the bush? If you mean “64-bit compiler” why not say “64-bit compiler” if you are happy to say “32-bit compiler”? And why call it an implementation in one slide (Pulsar) and a compiler in another (Commodore)?
I don’t think they are being “sneaky”, I think they are being politic.
They have made a huge mess of the whole thing, had no idea how difficult it was going to be, have allowed the folly of pursuing new users in a market served by predominantly free tools to get in the way of delivering things to their existing, paying customers working on a platform where Tools for $$’s is part of the landscape. And they know they have made a mess of it.
They are in a big hole that they dug for themselves and the corporate mind set in such situations is NOT typically “front up, be open and honest and tell people what is going on and ask for forgiveness and patience” it is “keep digging and toss a smoke grenade and a few flash bangs to distract people while we hopefully dig our way out of this”.
The corporate mindset is painfully evident at Borcaderoprise, not just in this roadmap but in recent events.
I can’t take your bet tho, cos I believe we will see a 64-bit IDE in Pulsar with a Win32 and Mac compiler, but no 64-bit compiler (beyond perhaps an update to the preview compiler they have said will be shipped in H1, just a few weeks/months before Pulsar).
The Preview .NET compiler in Delphi 7 came a whole year (or more?) before Delphi 8, didn’t it?
I think:
Pulsar – 64bit compiler for Windows, 32bit for crossplatform for Windows and Mac
Whellhouse – 64bit for C++ (with new backend as abauer mentioned in non-technical) + crossplatform Linux server
Commodore – every in 64bit
cite abauer about 64bit:
We’ve been working on Delphi 64bit for quite a while and it is looking
like the 2011 milestone target is still on target. In nearly everything
we work on for the nearer term projects, the 64bit apsects of the
design are always taken into account. There is still a lot of work to
do, but we do continue to consider any implications it may have. We
have been making on going progress toward the goal of shipping no later
than 2011 for Delphi and 2012 for C++.
C++ 64bit is being built on our next generation compiler architecture
and will take longer to finish than Delphi 64bit. For this reason we’ve
decided that this target has become important enough that decoupling
the Delphi and C++ releases allow us to get the Delphi release out
sooner. The benefit of the new architecture will pay significant
dividends for C++ customers over the next decade and will also benefit
Delphi users as well.
@Radek: Nowhere in that quote does Allen say what the “milestone target” is or what precisely it is they are hoping/expecting to ship in 2011. For that we have to refer to the roadmap. On the roadmap the only 2011 deliverable explicitly mentioned is the preview compiler, in H1 2011. If you think that there would only then be 3 months work left to do to get the fully finished 64-bit product out the door for a Q3 Pulsar release then … well, I question that sort of time-frame.
I say 3 months because that preview compiler is going to be out at the back-end of H1 (May/June), otherwise they would be saying Q1, and September is the opening of the release window for XE2 where you believe they will be delivering the full 64-bit compiler (despite the fact that the word “full” only appears in the “Commodore” slide and the Pulsar slide specifically says: Cross-Platform Win32 and Mac compiler.
@Jolyon
Great posts !
Especially agree with this observation :
“The corporate mindset is painfully evident at Borcaderoprise, not just in this roadmap but in recent events.” 😉
Anyone that thinks they will get production standard Win64 compilation and VCL any earlier than late 2012 is IMO seriously Deluded.
In my Above post I was referring to Delphi of course before one of the usual apologists for them on blogs say something along the lines of ‘Oh that follows revised ‘roadmap’ and what they are saying in newsgroups’ 😀
I think you’re splitting hairs too finely. Probably better to ask specifically rather than continue speculating on things like the meaning of “speculation”.
p.s.
Paul is dead…
@Bruce: Asking specifically only appears to yield more words, not greater clarity. You only have to look at the responses in the forums an indeed the words of Allen Bauer quoted by Radek.
e.g.
“the 2011 milestone target is still on target. … We
have been making on going progress toward the goal of shipping no later
than 2011 for Delphi and 2012 for C++.”
Lots more words and fits precisely with the roadmap, but doesn’t clarify to ANY extent what the referred to “milestone” or “goal” IS. For that, the roadmap is as specific as they seem prepared to get.
Every “more specific answer” jives precisely with the roadmap when you remove the meaningless verbiage and boil it down to actual meaning, rather than being impressed by the greater volume of words.
*I* am not the one splitting hairs.
One thing that is frustratingly evident at the moment is that Borcaderoprise are choosing their words *very* carefully. If they are choosing to split hairs in distinguishing between an “implementation” and a “compiler” on the SAME SLIDE, and to specifically mention a 32-bit Windows compiler on one slide and a 64-bit Windows compiler only on a later slide, then there is good reason to believe that there IS a distinction in their minds.
Apart from anything else, why is a 64-bit Windows compiler a feature of Commodore if it is already delivered in Pulsar?
And I take back my comment about perhaps putting too much in the distinction. The distinction is there. You don’t need to put anything into it.
What you DO have to do, to reach your conclusion, is IGNORE the use of words and accept that the roadmap has been put together very carelessly.
I’m not sure – even if true – that that is a much better situation, imho.
“*I* am not the one splitting hairs.”
I beg to differ.
@Bruce: As is your right.
I would simply say that a red hair and a blonde hair are two different hairs that should be treated separately.
Q: Do you wash your whites separate from your colours, or is it all just “laundry” to you? 🙂
As I get older, my whites are mixing in with all of the other hairs.
@Bruce: Touché 🙂
Ken, Jolyon, Bruce:
There is not statement about a 64bit IDE and imho the current Delphi compiler will be replaced by another one doing cross plattform compilation. Maybe in this current release they already ship the Win32 aspect of the new compiler who knows;-), we will see. They can always fall back to the existing compiler.
Delphi Windows 64bit implementation –> I think this is VCL 64bit. The IDE itself will not be ported so fast … VS does not have it.
Assuming that the new compiler works smooth and a VCL 64bit is on the way guys 2012 end is a realistic point in time.
See it realistic. Pascal and VCL are their USP and their customers are on Windows.
Unicode – somehow true under Windows they are really the only native. The horror the Windows ANSI – at the moment on Lazarus every component set providing support for LCL must react on a define and provide the appropiate UTF8 string or Ansistring or you recompile like me the LCL with AnsiString. In the C does not knwo strings, technically – it is more a way to see a byte buffer in a different way which has nothing to do with “real” Unicode in the fashion of UTF8 used on the web …
Honestly the whole communication looks for me like Garfield tactics – If you cannot confuse them, puzzle them:-).
@Michael,
I haven’t heard plans to make the IDE 64 bit.
What does “USP” mean?
@Bruce: USP to me, and in this context, most likely means “Unique Selling Point”
How could they actually build a 64 bit IDE before they have a 64 bit compiler?
@Rob: In the same way that they could build a .NET IDE before they had a .NET compiler. The .NET compiler preview was released with Delphi 7. It was 13 months later that Delphi.NET appeared.
Now in that case of course they could have been using other .NET compilers, and any vestigial 32-bit Delphi parts in the IDE could still be produced with the Delphi Win32 compiler.
In this case it is slightly different unless they use the FPC 64-bit compiler to compile the IDE. But my guess is that the 64-bit compiler will be sufficiently functional to allow building of the IDE even if not fully integrated into/with that IDE, and of course there is nothing to say that the IDE has to be built with a cross-platform set of VCL controls or that any control library used has to be complete.
Simply put, the level of functionality required in a compiler/VCL to build one specific product (the IDE itself) is quite different from that required in order to be a releasable feature set for general purpose use.
Bruce –> 64-bit IDE … was mentioned above not by you, sry. I did not want to blow the threads response count. My experience with 64-bit IDEs is not the best, but they have impoved.
USP – yes – unique selling point. VCL and Pascal – this is why is is shows up very often. Delphi as simplified C++ can also be a simplified C++ – it is a matter of priorities. I think the idea of having on code base for non visual purposes count.
FPC 64, Lazarus FPC64. Works – but the concept they follow on the LCL – I have my doubt. I see lot more responsibilty in the runtime for crossplattform – FPC + LCL is portable. Here we will see what the better concept is in the end. To many definies and also the runtimes even Java or .net follow compromises.