Wow! What an input! There was also a bunch of posts in forums, of course. I tried to let the information flow to be free as much as possible (even if I was tempted to response in several times) in order to gather a general idea on what’s happening:…
First of all, I do think that Embarcadero’s decision to go cross-platform instead 64-bt first is / was the right one. Yes, I know that there are certain kinds of applications which require a 64-bit compiler (like the applications which need more than 32-bit memory addressing and the ones which interact with an 64-bit OS (shell extensions etc.) – tell me if there are other kinds) but the community’s voice was / is more to cross-platform than 64-bit – see here where the cross-platform issue gained a substantial lead vs 64bit and here where the 64bit compiler and the cross-platform are (almost) head-to-head. But if you want, we can do a poll here (thanks to your interest, we have a greater traffic 🙂 ) – if someone is interested please drop a comment, even if it’s a little bit late now – they already are in the works with the ‘Project X’ and revamping the compiler. Perhaps a less known bit of information is Barry Kelly’s question on Stack Overflow – see it here.
In the other courtyards, there are also a much stronger focus on cross-platform than on 64-bit computing. For example, while in the last years Adobe had the same revenue from Macintosh products compared with the ones for PC, Scott Byer, Photoshop’s software architect is quite reserved in his blog when it comes to jump in 64-bit bandwagon. In fact this is, generally, the position at Adobe. Strong commitment for cross-platform, slow advancement on 64 bit.
Same for Microsoft. Office 2010 will be the first version for 64-bit whereas the first Excel was for Mac. (since… how many years?) And since then there were constant versions of Office for Mac. Also there were separate versions for Word and Excel. (ok, you can flame me: Microsoft didn’t produce anything for Linux…) So in my humble opinion, not here is the problem.
The main problem is to meet the user expectations.
Many said that with Kylix the problem was the price, the bugs / instability, CLX, lack of market culture to adopt a commercial product for Linux etc. etc. etc.
But I think that the main problem was that they failed to find in first place what the user expectations where and after this to fulfill them. If they’d keep asking early ‘We’re doing the things right?’ and had the humbleness and flexibility to listen, then they weren’t Kylixed. The same, of course, happened with .NET strategy (CppBuilderX anyone?)
Fast-forward today. It seems that, by far, the main problem is VCL (correct me if I’m wrong). IDE will stay the same, RTL isn’t such a big problem, the compiler… oh, the compiler – ok, it will be a new one. But the bugs will be ironed out. In a ‘few days’… 😉
And from what I saw, nobody from us has a ‘right’ global view on what it should be done. (sorry guys 🙂 – me included – I didn’t say that I know how it should be done). The thing is so complex that only by an incremental approach it can be perfected. That’s why I think that the only chance for the new ‘baby’ to be born is to find a common vision on what should be delivered. Ok, perhaps some of us are biased speaking from the point of view of their applications, but please try to see the community as a whole and be more neutral. From materials which I gathered there are some points to discuss (some of them are contradictory, as you’ll see):
- it should be one core VCL 2.0 with ‘painters’ (look-and-feel controllers) for each OS
- no, it shouldn’t have ‘painters’ – it’s enough to look ‘acceptable’ on each OS
- no, isn’t enough to look ‘acceptable’ – it must look exactly the same
- the above VCL 2.0 will have platform-specific extensions – classes, units etc. (eg. TRichEdit, TNSBrowser etc.)
- the VCL 2.0 will try to keep a (limited) compatibility with the present one
- no, it must be a totally different library (most probably a Pascal layer over an already existent one like Qt, wxWidgets etc.)
- no, each platform must have its own libraries VCLWIN, VCLOSX, VCLLINUX
- some mix of the above
- something else? 🙂