Hi Jolyon
You have more details here than I can get my head around as I do not or have not used some technology you mention. Why waste you insights? Would you mind if I forwarded these to Marco Cantu? I do not know him but as he is inside Embarcadero and I have an interest in them succeeding as I use their technology, your comments might give them beneficial insights. Anyone know his email address? Best regards, Russell From: Jolyon Smith [mailto:[email protected]] Sent: Monday, 5 May 2014 2:41 p.m. To: [email protected]; NZ Borland Developers Group - Delphi List Subject: Re: [DUG] Auckland Event Details @David: Your prescription that the approach must support single source is arbitrary. Heck, not even Embarcadero achieved this goal completely satisfactorily, so by that criteria FireMonkey itself is a failure. RemObjects approach is the more robust one. Rather than trying to pretend that platform differences can be abstracted away or reduced to lowest common denominator (as if the various user communities of the various platforms were not themselves making their choices precisely because of those differences, in many cases), those differences should be embraced and the developers empowered to take full advantage of them in order to provide the best solutions possible for each platform, not limited to providing a solution that can be deployed on all platforms. What should Embarcadero have done ? Simple. Instead of tossing Prism into the long grass, they should have brought Elements into the fold. Kept Delphi + VCL as their Win32 solution with Elements as their .NET and mobile platforms offering. But, frankly, as an Elements user who has previously experienced Borland/Inprise/Codegear/Embarcadero's product management, development, marketing and pricing at first hand, I am actually very relieved that they didn't (and suspect that RemObjects themselves might have resisted any attempt to do so). ;) The very fact that an outfit such as RemObjects have both the technical nouse and capacity to deliver something like Elements whilst Embarcadero, with far more resources at their disposal, are left buying up other people's technologies and trying to create a marketing message around them whilst rushing out poor quality releases (XE6 Hotfix 1 was out before the ink had dried on the XE6 release EULA!) to keep the money mill churning, should tell you everything you need to know about Delphi's future. If RemObjects can do it, and if Embarcadero are everything that their supporters crack them up to be, then Embarcadero should have been able to deliver their own "Elements", especially given that they would have been able to focus exclusively on a Pascal solution, if they so chose, without the added distraction of a C# front end. @Leigh.... Yes, Oxygene/Hydrogene (hereafter: Elements) when targetting Java, produces Java byte code. Just like the vast majority of Android code out there (with the exception of games - the one type of app that the NativeActivity support in Android was only ever intended for). Oh, and the FireMonkey apps. One thing this means is that unlike FireMonkey, your target platform is not confined only to Android and the Java environment provided there. For example, if you really wanted to, you could use Elements to create an Eclipse plug-in. Elements can produce Java code, hence Elements supports all Java based platforms using all of the capabilities that those Java platforms supports because - to all intents and purposes - when compiling for Java, Elements is Java. Just with a different language front-end. As such, yes, it runs at Java speed, just like all the other Java code on those Java based devices, Android or otherwise. But it does so without having to drag in a bloated runtime and a custom UI rendering engine (and that's incorporated into EVERY FireMonkey app, btw). Your apps take full advantage of the device capabilities. That includes, for example, ART, which is the Android technology that allows Java based Android apps to be installed as pre-compiled, native code binaries. Just like FireMonkey apps, but without the embedded bloatware, and with the ability to run on any Android device (that support ART, or indeed of course all the ones that don''t). But equally, when compiling for Cocoa, Elements is an LLVM compiler. All of the same advantages apply - you have complete, platform native access to the platform with all of the benefits that accrue. Whether that is Cocoa (OS X) or CocoaTouch (iOS). Similarly, Elements for .NET... any .NET based platform is available to you, be that Windows.NET, Windows RT or Windows Phone. How is the .NET support in FireMonkey these days, by the way ? ;) On 5 May 2014 12:59, russell <[email protected]> wrote: Always interesting to read strong opinions … even when presented as facts and focusing on a few topics. The analysis looks plausible. I cannot assess it well as I write for a niche community and RAD Studio serves me fairly well. Russell From: [email protected] [mailto:[email protected]] On Behalf Of Jolyon Smith Sent: Monday, 5 May 2014 11:13 a.m. To: NZ Borland Developers Group - Delphi List Subject: Re: [DUG] Auckland Event Details What makes less sense is the way that they added support for those platforms. You are right to highlight the manner in which they have managed to tick boxes. Unfortunately it is purely an exercise in ticking boxes. Far less useful as a solid basis for continuing to be able to keep those boxes ticked. Delphi was always a niche product. Despite the marketing, their cross-platform solution is not Delphi for "iOS/OS X/Android" (and it painfully clearly is not Delphi for .NET, let alone WinRT or WinPhone). It is "Delphi for FireMonkey", with the ability to deploy to any platform that FireMonkey manages to cajole a semblance of support for within the constraints of what the approach allows. i.e. you cannot build true Android solutions using FireMonkey because the way that FireMonkey works rules out certain capabilities of that platform. Similarly your FireMonkey Android apps will not benefit from ART. Sure, your FireMonkey app is "native code", but is also bogged down by the non-platform native frameworks required to make even "Hello World"possible, so whilst true platform native apps gain all the benefits that that platform delivers, FireMonkey remains stuck in it's own world. i.e. FireMonkey created a niche within a niche. Having attracted the interest of Delphi developers to the platforms that FireMonkey ticks the boxes for, many of those developers will quickly realise the limits and look instead at the alternatives, at which point they realise just how far behind Delphi has fallen over the years while Embarcadero wasted their time on the Smoking Chimp. As for the renewed interest in developing the VCL, this can be seen as a return to core value, or it could be seen as a belated recognition that FireMonkey is not in fact the secure future for Delphi/Embarcadero that it was supposed to be, and worst of all, without any viable strategy for supporting the platform on which that core value rests - i.e. the latest and future versions of Windows - even that core value is now at risk. For myself, I now use a combination of RemObjects Elements and Xcode for most of my work. Delphi is now very much a legacy platform. On 5 May 2014 10:46, David Brennan <[email protected]> wrote: It was a good seminar IMO. I understand why Embarcadero have decided to spend so much time adding support for OS-X, iOS and Android, at some point we may even take advantage of it. More importantly though I’m glad they seem to have realised that now they have ticked those boxes they need to return to address quality across the product. I just hope that XE7 will continue that trend so that the Delphi IDE and executables continue to improve in speed and robustness. I’m also hoping that XE7 will see a big push to make Code Insight bulletproof (or as bullet proof as such a thing can be, given that if you screw your syntax up completely midway through a big change it is always going to struggle, but it would be nice if it returned to fully operational once you tidy things up a bit!). Cheers, David. From: [email protected] [mailto:[email protected]] On Behalf Of Jeremy Coulter Sent: Monday, 5 May 2014 10:10 a.m. To: NZ Borland Developers Group - Delphi List Subject: Re: [DUG] Auckland Event Details Yeah let us know hen its done. We didnt attend the presentation for various reasons, although it would have be good, so am looking forward to hearing what Marco had to say. Jeremy On Mon, May 5, 2014 at 9:51 AM, Alister Christie <[email protected]> wrote: I managed to spend a number of hours with Marco after the presentation, and have about an hour and a quarter recorded, which I will make available after Marco has reviewed it. It was great talking with him, it seems that Embarcadero made a good choice appointing him Product Manager for Rad Studio. Alister Alister Christie Computers for People Ph: 04 471 1849 Fax: 04 471 1266 http://www.salespartner.co.nz Follow us on Twitter http://twitter.com/salespartner PO Box 13085 Johnsonville Wellington On Wed, Apr 30, 2014 at 8:43 AM, Gary Benner <[email protected]> wrote: HI All, Sorry this is a little late but just got back from a trip overseas. To endorse Alister's comment, great opportunity to meet Marco. cheers Gary Please see below details for the RAD XE6 Launch. Please will you forward this email invitation to members of the NZDUD to register/attend the event. Date and Venue: Friday, 02 May: Auckland Venue: Rydges Auckland - 59 Federal Street Cnr Kingston Street, Auckland 1010, New Zealand Time: 8.30am Registrations, 9:00am – 12:00pm http://forms.embarcadero.com/AP14Q2NZDeveloperDirectLIVE The event will be hosted by Damien Bootsma with special guest-speaker, Marco Cantu, RAD Studio Product Manager, global luminary & author of over a dozen books on Delphi. This event is not to be missed, so register NOW, as spaces are limited! Be amongst the first to see live previews of RAD Studio XE6 and all of the great new technology, with the latest enhancements to the VCL and more. Here's a glimpse of what is in store: Empowering your VCL codebase and developer productivity • Give Your VCL apps a new look-and-feel with improved VCL Styling • Introducing Win 7/8 taskbar buttons Database, integration and scalable services with RAD Studio XE6 • Core Database Features Improvements • New FireDAC Database Explorer and more • Working with JSON and XML • Building scalable and secure DataSnap services Embrace and Extend Your Mobile and VCL applications • App Tethering • Not reinventing the wheel with new BAAS Client components "Turning on" to mobile and The FM Application Platform • Introducing Android support in C++Builder XE6 • App Monetization with Advertising and In-App Purchases Evolution within a revolution: Summary and Q&A If you are an application developer, technologist or development team leader and interested in modernising your VCL apps & extending your applications to mobile devices for your customers, then this event is for you! Kind regards, Mike _______________________________________________ NZ Borland Developers Group - Delphi mailing list Post: [email protected] Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [email protected] with Subject: unsubscribe _______________________________________________ NZ Borland Developers Group - Delphi mailing list Post: [email protected] Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [email protected] with Subject: unsubscribe _______________________________________________ NZ Borland Developers Group - Delphi mailing list Post: [email protected] Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [email protected] with Subject: unsubscribe _______________________________________________ NZ Borland Developers Group - Delphi mailing list Post: [email protected] Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [email protected] with Subject: unsubscribe
_______________________________________________ NZ Borland Developers Group - Delphi mailing list Post: [email protected] Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [email protected] with Subject: unsubscribe
