Marc Hoffman kindly took the time to respond to my previous post and prompted me to re-formulate and expand my observations on Jim McKeeths post (which never made it to the comments thread on the RO blog for reasons best known to The Cloud).
The biggest issue I had with Jim’s post in particular was that he conflated JIT technology with managed runtimes.
Whilst it may be true that JIT is something that is currently only found together with managed runtimes, there is no technical reason why JIT should and could not be incorporated into un-managed frameworks if there were genuine benefits to be gained. It would however complicate the distribution of applications produced by with unmanaged code.
Managed frameworks simplify the distribution of code that incorporates JIT in the bootstrap because the requirement to have the managed runtime environment pre-installed (or distributed with the app) comes as a necessary and unavoidable overhead (some might say “complication” – a significant, recurring support issue for a .NET application that I am familiar with comes from variations in the .NET framework environment on which it relies at the various sites on which it is used).
With an unmanaged application it would be an additional runtime/distribution complication, regarded by and large as a negative quality.
I’ve said it before, and I’ll say it again now: .NET is basically the 21st Century VBRUNx00.DLL (on steroids and huge amounts of growth hormone). 😉
But if a managed runtime is not a pre-requisite for JIT, an obvious question is why is it that only managed runtimes incorporate it (apart from the runtime/distribution wrinkle mentioned above) ?
It’s almost as if managed runtimes are trying to compensate for something… 😉
Also, the benefits of JIT are largely – afaik – theoretical. Yes, Microsoft (to take .NET as an example) could invest the time and effort to create the JIT compilers necessary to target every new evolution of the latest and greatest Intel and AMD silicon, but in practice I don’t believe they do.
And why should they ?
As Jim himself points out in his response to some comments, if you need performance, managed frameworks would not be your first choice (an observation somewhat at odds with the position taken in his post itself). He (or perhaps the comment he responded to – I don’t recall) isolates games as an example of where managed frameworks are not the best fit, but “game” is simple a very specific example of “demanding application”, not the ONLY example.
The real point is that not all applications need that best performance and that there is therefore a trade-off to be struck with productivity and that is the true advantage of frameworks in general, but again, not an exclusive advantage of managed frameworks.
Delphi’s biggest selling point is the VCL and the way that it makes developing native code Windows applications massively productive compared to other native code development tools.
With FireMonkey you still get the native code but you lose the competitive edge against the other native code tool set for the platform(s) it targets because you are no longer comparing like with like. Those other native code tools produce truly native applications.
Delphi with FireMonkey delivers native code, but not native applications.
I should also stress that this distinction is not confined to the UI toolkits but the wider native capabilities of the platforms, much of which – in the case of OS X / iOS are difficult if not impossible to access.
Which is why I am currently teaching myself Xcode, Objective-C and Cocoa, for it is increasingly obvious to me that that is easiest and most reliable path to creating native applications for OS X and iOS.