Recommending Xcode for Mac I can understand. It’s the native language.
It’s actualy refreshingly honest.
But recommending Javascript over Oxygene .Net for Win 8 Metro Apps???
For me Javascript is a necessary evil for browser client side stuff.
I would never in a million years CHOOSE it for development of a Win 8 Metro app over Oxygene .Net
.Net is a first class language for Windows 8 Metro, admittedly Javascript is too, but what on earth could
be the reason that RemObjects recommend Javascript over Oygene.Net ?
Javascript is NOWHERE NEAR as powerful or feature rich as Oxygene.Net.
I’m really confused, It’s actually very worrying.
Please could someone explain the reasoning behind RemObjects recommending Javascript over their own product for Win 8 Metro development.
For one thing, because Metro is still in (pre-)beta, and Oxygene and RODA/.NET support for WinRT isn’t even shipping, yet, while JavaScript and RODA/JS do work for the current Metro preview. Nothing says that this recommendation can’t/won’t change, over time.
For one thing, because Metro is still in (pre-)beta, and Oxygene and RODA/.NET support for WinRT isn't even shipping, yet, while JavaScript and RODA/JS do work for the current Metro preview. Nothing says that this recommendation can't/won't change, over time.
Ok, that makes sense.
I am a staunch advocate & supporter of Oxygene, but can see that it’s not the right
solution for every platform.
However i cannot believe Oxygene will not be the preferred solution for WinRT when it supports it.
I’m surprised(and a little concerned) you didn’t explicitly say this.
Is there a timeline for Oxygene support for WinRT?
Greeny: we’re working hard on it and at planning to ship support in a beta drop shortly after the upcoming Windows 8 and VS11 beta is out. We have most of the basics implemented based in the current preview from last year, with a small open issues we’re working on solving with help from our friends at Microsoft. But reading between the lines, there might be some significant changes still coming in the upcoming beta…
Willian: good question. “support” is such an overloaded word in this contact. there’s the question whether RODA/Delphi “supports” FPC and Linux (as in, does it work with it) and the question of whether we “support” the product on FPC (as in, do we go and install some obscure Linux distro because a customer is having problems with FPC 2.5.7 or FooBarLinux 4.8 rev B).
we’re not planning to remove the first kind of support for FPC and Linux from the product. We’re gonna keep trying or best to keep the libraries compatible with FPC as it and they evolve.
but we have never really actively supported the product for FPC, to the degree that we do extensive testing (manual or automated) with all the various flavors of FPC and Linux out there. That’s a never-ending battle. (Just to give an example, the beta we shipped on friday has separate sets of changes for FPC 2.6 (which i understand is the latest and greatest right now) and FPC 2.5.1, which is the bastardization that Embarcadero uses for iOS support in Delphi XE2. Iirc (i’m not involved much with the Delphi side of the products, on this low a level, so forgive me if i’m wrong), the latest/current Lazarus uses an even different version of FPC again. Thats a support nightmare.
add to that that FPC and Lazarus themselves have a pretty steep learning curve and you pretty much “need to know what you’re doing” to get anywhere with FPC. We don’t want to (and can’t, really) give people the impression that FPC is the “easy way” to just get your Delphi server compiled for Linux. Unless you’re an FPC and Linux expect, it’s far from that.
so i guess what i’m saying is: if you’re an FPC expert and know what you’re doing, we’re gonna make sure as much as possible that you will be able to continue using RO/DA with FPC, and build servers (and clients) for Linux, and possibly any other OS that FPC supports. if you’re gonna find FPC 2.7 broke something (or we broke something), we’re happy to listen and to fix things and make sure everything keeps working. BUT, if you’re a Delphi developer asking us “how do i write a server so i can deploy it on Linux?”, then FPC is not going to be among our recommended solutions; we’re gonna recommend that you should use Mono and the .NET products.
(matter of fact, i’d strongly recommend that even if you’re just wanna deploy on Windows: use .NET and the .NET products, to write your RO/DA servers. By all means keep using Delphi for your Windows clients, but for servers, the .NET side is a much better solution, for many reasons)
Nice to hear that we can still count on “support” !
From my side I won’t expect detailed documentation specifically for FPC/Lazarus/Linux nor that the SDK integrates in the Lazarus IDE as nicely as in Delphi, but I expect at least the source code to compile correctly.
I agree the Lazarus IDE is a “beast” but the FPC compiler is solid, backward compatible and quiet compatible to delphi. Btw, if delphi decides one day to support Linux (hopefully in near future) this might be one option…
I think a win-win could be that RO would commit to FPC support (That at least the source code compiles and that the components work).
On the other hand RO would not commit to the interation in the Lazarus IDE.
How does this sound?
During the dev. cycle the RO guys anyway need to have in mind that there is FPC and Linux around and if, before your quarterly releases, you also try a compilation run on FPC, you will spend less time on upstream support!
rickie: exactly, yes we’ll definitely keep supporting compiling for FPC. i’ll also discuss with the QA team to see if we can make building with FPC part of the test suite, to catch incompatibilities early on (if we don’t already)
rickie: I agree with you about FPC and RO integration (keeping Lazarus apart )…
marc: thanks for your explanation, I am much more relieved now …
I also think that looking at server side, .NET (mono to deploy for Linux) is a better choice than Laz/FPC combo for new projects. But we have no other alternative because our software is based on Delphi and re-use “legacy business logic” in Linux is a necessary requirement. But , considering your sugestion, for new projects we can give RODA/.NET a try
Willian: of course. no recommendation can ever be made in a vacuum, and just because we say we recommend .NET/Mono for cross-platform servers, that doesn’t mean that’s gonna be the optimal (or even a feasible) choice for 100% of all scenarios. that’s why we have all the different options ;). having to (re)use a bunch of legacy code is often good reason to stay with an otherwise suboptimal solution.
if you're gonna find FPC 2.7 broke something (or we broke something), we're happy to listen and to fix things and make sure everything keeps working. BUT, if you're a Delphi developer asking us "how do i write a server so i can deploy it on Linux?", then FPC is not going to be among our recommended solutions; we're gonna recommend that you should use Mono and the .NET products.
I recommend you use this suite to test release for FPC and LAZARUS. telling the fpc user what to use is the best way to have less problems in a near future, i think.
…
)…