Perhaps this post should be sub-titled: Say a Lie Often Enough and You’ll Start Believing it Yourself
Apparently some product called ERPLY (yeah, me neither) now has a “great new FireMonkey native UI”. FireMonkey ? Native UI ? Unless there has been a radical rewrite of FireMonkey in XE3 and the people behind ERPLY have early access to an unfeasibly stable build of XE3 to have created their product using it, this claim is just errant nonsense.
RemObjects have a much easier time convincing people – albeit somewhat disingenuously in my view – that “native” these days does not necessarily mean “machine code” any more, especially when the host/target runtime is a managed, JIT compiled framework. To an extent they have a point, but the motivation behind making this point seems to me in some cases to be coming from a place of insecurity, because some of the claims they subsequently make for the advantages of managed environment are highly dubious (and sometime flat-out wrong), and in making these claims they undermine their own argument imho.
But at least they are just going a bit too far in their enthusiasm. Embarcadero on the other hand have stretched credibility beyond breaking point and entered the realm of pure fantasy.
To conflate FireMonkey with “native”, especially in conjunction with a tight coupling to the term “UI”, is quite simply nonsensical and smells to me like a desperate directive issued by the marketing department. Certainly the claim has no technical justification whatsoever, not even one as contrived but at least arguably technically correct as that being deployed by RemObjects w.r.t “native” sometimes meaning “managed”.
FireMonkey on the other hand can never be a “native” UI on any platform that it “supports” (“can be made to run on” would be nearer the mark) any more than I, having been born and raised in the UK, could ever be or legitimately claim to be a “native Russian”.
To see such ridiculous claims being made, for me, is a worrying sign of just how desperate Embarcadero are in this area.
If the technology needs propping up with such blatant and obvious bullshit the problem is that the smell just makes things worse and draws attention to itself.
Perhaps this post should be sub-titled: Say a Lie Often Enough and You’ll Start Believing it Yourself
Pretty much (:
Unless there has been a radical rewrite of FireMonkey in XE3…
A radical rewrite is a must if the monkey is ever to succeed… which I highly doubt, but hopping to be wrong.
To see such ridiculous claims being made, for me, is a worrying sign of just how desperate Embarcadero are in this area.
They still need to learn that they are selling to developers not consumers and that their best marketing can come only from developers that know what the hell they are talking about, their marketing department(s) needs a clean sweep IMHO.
I thought they meant “Implemented in firemonkey”, “firemonkey native” being the most silly and awkward way you could say “implemented in pure firemonkey”.
Anyways I laughed out loud when I saw RemObjects claim that “managed is the new native”. Take away mono and all their products melt away, so there is a built in “defensiveness” at RemObjects about .net. It’s cool. remObjects makes great products, but they obviously feel that they’ve put almost all their eggs in the .net basket, and so they’re a bit touchy about that.
Frankly, I don’t care if Firemonkey is native or not, that’s not it’s purpose. I just want a way to make a great looking app that looks modern and cool, on both Windows and Mac, and IOS. Frankly, even that goal seems a release or two away, but I’m not panicking and not calling it a failure. It’s just early days for Firemonkey as yet.
Warren
@Warren, that could be what they mean, but it’s not what they wrote. A UI implemented in FireMonkey is just a “FireMonkey UI” – there’s no such thing as a FireMonkey UI that is not, well, FireMonkey, so the term “native” in there is entirely redundant as a qualification of a type of FireMonkey UI. So why include it ?
I guess the old saying about not attributing to malice that which can be explained by incompetence might apply, but then neither explanation is particularly comforting.
“managed is the new native”
…and “native” is actually *un-managed* 🙂
RemObjects is simply protecting their land of what is an unavoidable collision of their products with EMB, it is clear that DataSnap is growing on their realm and it is being ported to all the environments EMB is attempting to support.
The single code experience may definitely hurt (it depends on how many developers come from the Delphi realm are their customers, which i think must be many) RO efforts on supporting so many platforms on their “native” environment argument that doesnt fly considering their Mono approach to most of them.
The series of articles showing the preferred choices to develop on a specific platform, the constant commenting on how FireMonkey should not be used for the “real” Mac development and many others just shows that there is concern on their lines.
Now, EMB marketing yeah, it looks like marketing people doing what they do, without much of a technical review of their comments. In my personal opinion, I dont care, its technical people the one buying the tools right? so we pretty much can read through it. Now if you feel that they are deceiving you on making a decision to buy their product based on those technically false statements, then yes, be angry! and dont buy their product, dont fall for it!
Otherwise, the simple fact there is marketing, it is not only great news but something I applaud. FireMonkey is great and will improve greatly on the future, there is only so much you can ask for a first version. We can argue the quality before release bla bla bla thing, but at the same time if you want to catch up on supporting the latest and greatest of the technologies you cant wait until things are perfect, you need to launch with a certain standard and fix on the go.
“you need to launch with a certain standard and fix on the go”
Is that so?
Did Apple release the first iPhone “with a certain standard” and then fix on the go?
I’d say they made it 99% perfect, and then released it.
As for FireMonkey in it’s present state, I’d say that it’s about 20% perfect. In my opinion, it should never have been released or marketed as a finished product.
At best, it resembles an early alpha in it’s present state…
I am using Win32/Win64 (VCL). What are you talking about…?
I do agree with you.
This is marketing stuff.
Do PC hardware manufacturers or Microsoft lie when they say that the new “Model 1234” or “Office 3000” will definitively help your children pass their exam, because they will produce nice looking presentations?
I can understand that lying to the masses to sell high-tech products like some “magic powder” and do not need in fact. This has been done since Abel.
But I did not understand at first when some low-level technology vendors like RO or EMB are lying in their web sites. (I dislike the fact that RO says that their products are unique in the market – there are other solutions around for Delphi, including Open Source, and some are worth looking at)
Microsoft does force most software architecture to embrace their .Net ecosystem, and pay for it, whereas there are good alternative around.
Then I did remember that in most companies, those making decisions do not know a clue about technology.
I’ve seen managers and HR specialist hiring people to be technical leader on Java applications because they did have JavaScript in their résume (sic).
So if Delphi is to be widely used because of some marketing half-truth, what else?
Obviously, everyone is heartily invited to disagree with views portrayed by either myself or RemObjects Software, and with our philosophies and recommendations on software development practices. But i’d love to see some backing up of the claim that we are *lying* on our website. Please elaborate.
I’m no native English, so I apologize if the word is certainly too strong to your juridic background.
A) I was indeed at first confused by the http://www.remobjects.com/da/features.aspx page 🙂
But in all cases, the page this link comes from states:
“EVERY” here is stated in bold.
And this is a false statement.
See all ORMs available in Delphi, some even over a Client-Server layer.
Of course, since I wrote some Open Source project featuring this (and more), without earning a cent on it, I was hurt by such a not fair statement.
From wikipedia:
To lie is to hold something which one knows is not the whole truth to be the whole truth, intentionally.
Since I’m pretty sure that you know about ORMs and remote access in Delphi, since the word “every” is bolded on purpose in the text and since it is an official web site, sounded like a lie to me. Or certainly a marketing emphasis (is it not a pleonasm?).
B) In the “official” page about “native” is
http://www.remobjects.com/products/native.aspx the purpose is more elaborated, and has a less trolling/confusing approach than in the initial blog entry.
I still do not understand how you can sustain that a WPF design is more “native” than any other UI on Windows. WPF is so expressive that you can do whatever button layout or application behavior you want to. The whole #1 argument is IMHO voided when you put WPF in terms of “native user experience”.
The VCL itself was a big abstraction layer over the WinAPI – and a welcome one! Since Delphi XE2, it features skins. It is by no way “developer native” to the Win32/Win64 plartform.
So no lies in this case, of course, but marketing stuff for non technical people. Nice for the managers. But for programmers, at least confusing material for some people how wants facts and not blabla.
Sorry if my poor wording did hurt you.
It is in all cases nice to have you react here!
i’ll have a look at the part about the component dropping. at the time of writing, it was certainly written with the best of intentions, and to the best of our knowledge, all comparable frameworks we were aware of (such as, but not only) DataSnap did (still do?) require dropping lots of components.
ORMs are quite different in approach to how DA (and DataSnap & Co) work, and this comparison was not specifically targeted at them.
I’d appreciate pointers to any ORM (or other data access layers) you are aware of that share DA’s unique approach of defining data access in a centralized schema, instead of “lots” of components (or manual code), which DA has provided since it’s inception in 2003.
Regarding WPF: i don’t think i would argue (or have argued) that WPF is *more* native in UI than VCL, WinForms or RAW Win32, just that it is one way to create native WIndows UIs. (it can also create bastard UIs — but then so can VCL and straight-up Win32, just think of those odd almost-square buttons of the Borland Pascal 7 days ;).
I’d also agree that Delphi is not “developer-native” for Win32, but (as i think i point out in my Native text) Win32/Win64 is/was a much lower-level API that most modern OS vendor APIs (such as Apple’s Cocoa, Android’s Java-based APIs, and .NET and WinRT), so a certain amount of abstraction was needed and welcomed — you don’t want to code high-level application straight to the Win32 API, trust me, i’ve done it. With more modern OS APIs, the API is already high level enough so it no longer needs abstraction to be usable, and *thus* the “extra” abstraction gets in the way.
does that make sense?
@Marc
About something comparable to DA, see our little http://mormot.net
You do not drop any component, just create some classes, and the framework will securely access to it from any DB. The DB layers are even included – the Delphi starter edition is enough to connect very efficiently to Oracle or MSSQL.
The DA’s schema is called a “Model” within mORMot, and contains the ORM classes. A SQLite3 engine is included (and can be by-passed), and provide nice transversal features via Virtual Tables (ORM can e.g. define a class which will create a SQL query JOINing several DB backends). That is, a mORMot model/schema can access multiple DBs – I’m not sure DA can do that.
Very fast communication layer is included – like RO layer. But it does not rely on Indy, but on IOCP provided by Windows (using kernel-mode http.sys API).
And this is also a SOA framework: you define services contracts as Delphi interface, then access to them locally or remotely, via factories. Just like WCF. But lighter and faster.
Other features are available (like UI auto generation, reporting, security, logging, caching).
It has all the bricks to build not only a MultiTier architecture, but a modern Domain-Driven Design. You can write a simple stand-alone executable up to the most demanding SOA product.
I’m speaking of what I know.
But I’m quite sure that ORMs can provide the same level of abstractions to the DB, with no RAD/component approach. When associated to a communication layer, e.g. DataSnap services, it will handle the DA features.
thanx, that looks interesting, i’ll make sure to check that out.
The whole problem is that I don’t care about *anything* that is related to the apple world, period.
I think that on this Earth there are enough “ghettos” and that anything that tries to act as liberator for those who are the victims of a life in a ghetto is simply *EVIL*. I think that everything trying to act as a duct-tape for helping developer to talk with the apple world is even more insane than the whole apple philosophy.
Last year I received an iPad as a gift: from the beginning I’ve used it as a tray to serve her a cup of coffee each morning. And the more the coffee spills, the more I like it. It must be said: I’ve never found a better designed coffee tray!
Beyond being a coffee tray I cannot see any better possible use for it. I’m glad that the friend of mine that offered me that iPad as a gift never get hurted by my decision of using it as a coffee tray.
May be I can improve the “user experience” putting a photo of its inventor on it but then it would become the first coffee tray that is wasting energy.
Do we *really* need to develop for the apple world?
This is not your problem, it’s your freedom to do so. Honestly the iPad seems to be such a good coffee tray so that millions of people buy and use it. It is not unlikely that tablet apps will be required. Of course no one will ask someone with no experience on a platform to develop an application for. From this perspective everyone who has not been asked to develop for iOS or Android should not take this as an argument for missing demands or the absence of needs. The more it is a result from Delphi’s being years to late – Delphi is a late adopter approach. From this perspective – the one who is trying to build a bridge is maybe doing no one a favor except for those who walk on it for years after the years of the opening. A FMX on Windows would make Delphi complete enough … I think your view is realistic, … for Windows people.
Great post, Jolyon.
with regard to RemObjects, i hope it was obvious that Jim’s post was meant to be a mit polemic. It was a follow-up to my earlier post which can be found here and i think gives a more well-rounded view of how we see thing WRT “native”, here at RemObjects Software. Of course “managed” is not the new native, (any more than x86 is the new native, in our view). Native, IMHO, is whatever is native for the platform. on Windows, that can be x86 or x75 code in many cases. It can also be .NET. On Mac and iPhone, native is Cocoa. On Android, native is Java/Dalvik.
The software industry has gotten a bit more complex in the pastb 20 or so years, for one thing single technology or tool to be considered perfect, and native, everywhere.
In any case, i recommend checking out my original post before anyone assumes that RemObjects’s agenda is to push .NET (and Mono). That’s very far from the truth, and i think out growing across-the-platforms product portfolio goes to prove that we’re invested in all kinds of great development platforms (of which .NET certainly is one, yes — but n my truly personal opinion, it’s not even the best of those we do support).
Thanx!
marc
Hi Marc, thanks for the contribution. I tried responding to your and Jim’s posts on your blogs but my comments seemed to get swallowed up by the cloud and never made it on to your site.
I was going to respond here, but my reply-comment became so substantial – and likely to provoke further comments/responses – that I decided to make it a follow-up post instead. 🙂
That’s strange. i don’t see any unapproved comments — i’d appreciate if you try again.
Well, I just tried posting a fresh, test comment to Jim’s post and saw the same behaviour. The page submits, the page refreshes, but no comment appears and no error message or other indication that anything went wrong.
hm. i see it now, it was pre-flagged as spam (so wordpress doesn’t even notify us to approve it). very weird. i’be unflagged em, hopefully that should also whitelist you for the future.
my apologies for that.
Native @ EMBerror is used as marketing term. Honestly talking about native is an academic discussion, it’s controversial one hand and on the other cannot lead to a result because of the frist. I think the hidden agenda is simple to have people talk about … native is a cultural term, whatever grows on a plat-form.
RO follow a pragmatic path … isolate cross platform issues via a protocol but provide ways to make use of in different development environments (native) in a RAD fashion. From this perspective they are very unique.
Delphi from this perspective is a solution for a group of Indigenous Australians who crossed the big lake, incidentally arrived at silicon valley and found out that the augury is fulfilling but a different way – if you don’t mind the comparison – just from the picture. Sometimes the only thing that survives in new world is the language – the old world is big enough. The whole MS world can be seen this way, when we talk about mobile devices of any kind – the new world – different devices, different thinking, different culture and different parts of the world, but the first time in IT history a big market that remained almost untouched in the western world.
What we face is the fact that the vendors future markets are no longer in the western world – the focus is somewhere else. Of course this will impact the way the new solutions found will become implemented.
@dorin
Perhaps this post should be sub-titled: Say a Lie Often Enough and You’ll Start Believing it Yourself
🙂 Marketing technologies – http://www.youtube.co/watch?v=VA8b4YFXlhA
The only relevant point is – does the technology fit and work. Anything else is almost irrelevant. A matter of the Zeitgeist, but few people really do follow. I see this ‘native’ this time from the perspective Microsoft’s pushing their C/C++ compiler …
This rather confusing post has some points to make about the use of the term “native” in relation to generated code and is therefore relevant to the position taken by RO.
But when discussing UI technology, native is far less easily confused.
On OS X / iOS a Cocoa TextBox class is native to the platform. An OpenGL rendered widget that simulates the appearance and behaviour of a Cocoa TextBox is not native.
On Win32 an EDIT control is native. A DirectX rendered custom control that simulates the appearance and behaviour of a Windows EDIT control is not native.
The fact that the OpenGL/DirectX widgets are themselves implemented in “native code” (definition ambiguous) is not relevant to whether or not they implement “native UI” (definition UNambiguous) elements.
That’s bullshit. Machine code is native – regardless of which API is targeted.
They didn’t say “Native Code” or “Native application”, they said “Native UI”. That’s the part that’s bullshit if referring to a FireMonkey app which doesn’t produce a native UI on any of the currently supported platforms.
Emphasizing on Native Firemonkey is good imo beacuse a lot of people have bad experiences with WPF performance. And it is managed code.
FM is cool but as an excuse for FM slowness EMB are saying FM is not intended for game development.
I think they should have designed and optimized FM like a game engine because people expect their apps to be as fluent as the games they are playing on that very same machine.
“Native UI” is not the same as “UI written in unmanaged code”.
The most appropriate and relevant meaning of “Native UI” is that the UI is comprised of the UI elements that are native to the OS/platform. FireMonkey is not, and by design cannot be that, so to describe a FireMonkey UI as “native” is an oxymoron.
The more I read about Firemonkey (which I have so far not used at all) the more I get reminded of CLX, which was also touted to be the successor of the VCL, and we all know how that ended.
So far, nobody has asked me for an Apple-device application, so I don’t really see the point of spending much time with Firemonkey. (As for buying an IPhone or IPad myself: Just too expensive for me.) There are so many other possible interesting side projects, like Smart Mobile Studio for which I also still have to find a use, that Firemonkey is very far down my list of stuff to look at.
Now, if I get my hands on a decent IDE for developing (and debugging) Linux applications again (I *bought* Kylix, *twice*), that would be something very different.
(Yes, I know about Lazarus and I will have a look at it again in the near future.)
Embarcadero is ourusing again the mistake to scare its own customers. AS they did with .NET. They are pushing FM in the wrong way, as if they didn’t have an excellent Windows GUI library called VCL, and if FM is in beta stage at best.
If they keep on this way, they just scare a lot of actual customers (many of them writing Windows application using VCL and probably many 3rd party VCL- based libraries) as if Embarcadero is willingly to kill VCL ASAP leaving them in the mud. What they still don’t understand is if customers have to rewrite a lot of code, it doesn’t meant they will rewrite it in Delphi + FM. Maybe they will ditch Delphi altogether and rewrite it using other tools.
Embarcadero marketing should be careful in what they push and how, because they could obtain the exactly opposite effect they’re looking for.
I think you meant that the VCL was an excellent GUI library. It is now old and crufty. The code smells of the 90’s. It doesn’t support many of the modern UI paradigms easily. It is not cross platform. Remember that the VCL was release 18 years ago. It was revolutionary at the time, a simpler time with no internet (not strictly true but in a practical sense), no smart phones, no tablet PC, no iPods.
“Embarcadero marketing should be careful in what they push and how”
Indeed, and it’s not like it’s a mistake they haven’t made a couple of times already…
“if FM is in beta stage at best.”
Indeed. And besides having still unsolved architectural and performance issues, they also don’t have a cleanly working basic building block for cross-platform text rendering & editing (which is a hard problem, I agree, but one you can’t really make the economy off in a business-oriented UI…)
Before the community criticized Borland for not being so aggressive about marketing Delphi. Now that Embarcadero is trying its best to promote the use of Delphi, a lot of people are still complaining.
Of course Emb might just be using the term ‘native’ because Delphi/C++ Builder is a native compiler. Can you run FM without compiling it to a native compiler of a particular platform?
Ineffective/incompetent marketing is what was complained about, of which a basic lack of ANY marketing is only on facet.
Equally ineffective – and possibly more damaging than no marketing is marketing that treats it’s audience like idiots. When target audience is technical minded, very savvy software developers, treating them like idiots is NOT going to appeal to the dollar in their pocket. you don’t buy technical products from companies that flaunt their ignorance (or willingess to ignore) important technical details.
if they meant “native code UI” then they could have said “native code UI” and SHOULD have said that, because anyone likely to be attracted by such a thing is only going to be positively put off by the deliberate OR accidental use of the term “native UI’ in a context that is clearly nonsense.
They either don’t know what they or doing or think that we can e easily fooled. Neither of which is likely to encourage discerning, technical knowledgeable customers to part with their $$$’s with such a company.
I think they mean the executable/application is native, not the UI.
Of course the FireMonkey UI is not native, but isn’t the app/executable Delphi Xe2 creates native on the platform you compile it for?
Maybe, except that they very carefully put the word “native” right next to the word “FireMonkey”. Or maybe they weren’t being careful at all.
i.e. either they were sloppy or deliberately misleading. Neither is a good look.
They could have used Lazarus to to do the same thing, and Lazarus is way closer to VCL than FM.