Where do you want to go Tomorrow? Cross-platform? Native code?

CrossroadsAs you requested, here we have the cross-platform poll. As perhaps you already know, the Team is in works at the “Project X”, the Embarcadero’s cross-platform solution, which most probably Mike Rozlog will mention in his talk at CodeRage 4. Also, they’re working at a new cross-compiler which is a major overhaul of the old one.

The poll bellow is designed in a somewhat different way in order to grab your exact order of preferences as much as possible. So, please go and fill it. πŸ™‚ I do think that your input will help a lot. …and don’t worry: We’ll publish the results. πŸ˜‰

Now sit back, relax and forget about Embarcadero or any other company. Think, that everything is possible if you’ll express unbiased your opinion. So please do: …and beware once again: the questions are DIFFERENT. And will shape the future.

Vote now! πŸ™‚

37 thoughts on “Where do you want to go Tomorrow? Cross-platform? Native code?

  1. Where do you want to go Tomorrow? Cross-platform? Native code?

    Cross-platform native code development!

    For me, native code clearly has an edge on cross-plat.

    These are my other wishes:

    1) Not the one like .Net which is cross-plat but not native.
    2) Cross-plat with least code changes as possible. ( A compiler that produces Win, Mac and Linux binary, all at once, at the press of a button is a myth. I know that. )
    3) Smallest binary size as possible. ( Delphi for win does a good job at here, at least when easy of use is taken into consideration. But I’m aware of KOL too! πŸ˜‰ )

    • πŸ™‚

      Yes, sure. But many drank the kool-aid of “native code is dead”. Well, I don’t say that the “other” code is dead, but there was clearly a hype in promoting any extreme position.

  2. Depends very much on what this XPlatform thing will do.

    Delphi is intimately wrapped around Windows and all it’s idiosyncrasies.

    An XPlat Delphi will need compete head-on against mature development tools on other platforms which presumably have already solved the idiosyncrasies of those platforms long ago.

    Delphi XPlat will need to have a compelling selling point. Merely providing a Pascal compiler or forcing the VCL on another OS is not enough.

    • Yes, it depends on what actually will do.
      “mature development tolls” – perhaps languages. But tools? Hmmm… except Eclipse and IntelliJ there’s no mature environment out there. Also there’s no head-to-head competitor to Delphi / Pascal.

      • Delphi has no head-to-head competitors?!?

        Apple, Linux, Symbian, and all devices with software have development tools specifically tailored to that platform, and at different levels of granularity.

        Those are the competitors.

        Consider this: what compelling advantage must a Delphi PlatformX tool need to offer, say, the Apple DEV community, to convince them to move to Delphi? Remember how the introduction of Unicode in D2009 was a huge problem for the Delphi community?

        Or what, other than a familiar syntax, would PlatformX offer me to convince me to use it on Linux? (and I already have Kylix with it’s CLX library. And no, I don’t use it anymore.)

        • There is to consider Delphi uses Pascal, and nowadays most developers think about it as “the language to avoid”. That’s why there is no head-to-head competition, but FPC… Selling a Pascal based tool to developer used to C/C++/Objective-C is not easy at all – regardless of its power.
          Also on platforms like Linux there are established compilers like GCC, offering another C/C++ compiler (bound to the Intel x86 platform only) will surely raise eyebrows, especially if it can’t outperform GCC under almost every aspect.
          RAD tools maybe didn’t reach the maturity they have under Windows, but there are plenty of development tools under other OSes too.

          • Precisely my point.

            If, for example, Delphi PlatformX targets Linux, then it better have something to make the GCC guys go HOLY COW! WE NEED THIS!

            If not, then it will just be something for us Delphi people to target Linux in a language syntax we feel comfortable with.

            And believe me, when shifting to another OS, the syntax of the language tool you are using is a minor issue compared to all the other changes. Easier in the long run to get into GCC.

            • Embarcadero has two choices: 1) Sell xplat Delphi to actual Delphi users to allow them target other platforms 2) Sell xplat Delphi to developers already working on the new platforms with other tools.

              Choice 1) is easier, but when faced to choose between Win64 and other platforms, what will be Delphi developers priority? Porting applications to Win64 is *much* easier than targeting a totally different platform. I guess many may dream it, but writing a Linux or MacOS application may be very different than writing a Windows one – and some dreams may turn into nightmares πŸ™‚ Kylix didn’t go far because I never saw Windows developers migrating to Linux like flocks of birds.
              And if your Windows applications have their market, does it exist for Linux or MacOS versions?

              Choice 2) It’s much more difficult – you may have not fancy designers, but there are a lot of good tools and libraries out there. Why should they move to and pay for an Embarcadero tool?

              If the only reasong is to develop DB admin tools for the DBA using Linux or MacOS, well, that’s not fair towards actual Delphi customers at all – we would end up paying for Embarcadero own advantages, not ours.

  3. This might be odd, but I think the largest thing Delphi is missing is cross-platform Game Development Kit. Something like XNA, but better.

  4. There are two possible approaches for cross platform:
    1. Kylix like with hopefully one sourcecode including the form layout. This will be very convenient for those who want to create a PlatformX version of their existing program without having to rewrite most of the UI.
    2. Delphi Prism like with a different UI design where you can only re-use part of your existing code and have to completely rewrite the UI.

    I for one want the first approach. I don’t care whether the die hard Linux/Mac OS/whatever programmers complain that this forcing the VCL onto their super duper widget library. They won’t use Delphi anyway because they already have got their programming tools (and in the case of Linux programmers it is against their religion to use a commercial tool). I am a Delphi programmer and I want to re-use as much of my existing work as possible. I am willing to pay for it (I bought Kylix, twice, but I thought the price was outrageous).

    • Yes, AFAIK, there will be a cross-compiling product having as IDE the present incarnation (ie. Galileo IDE). But imho the problem isn’t IDE neither the compiler. The problem will be exactly this: the legacy vs advancement. Skills & existing code-base vs. how far they will go with this.

  5. Having sat through the “RAD Studio Product Address” today, I must say I’m disappointed in the miniscule amount of time and the total lack of clarity over what and when will be delivered in terms of cross platform and 64bit.

    Michael ducked my two questions on delivery estimates for these products, merely giving the stock answers – “as soon as we can” etc… Not good enough.

    Having failed to deliver “Commodore” and 64 bit specifically against previous roadmaps, I’m sure they don’t want to give hostages to fortune again. So, yet again we are left to make our own assumptions. D2011 we have to assume is cross platform. D2012 64bit. Anyone want to bet against that ?

    • No.
      I cannot speak in their name but AFAIK they are aware that the cross-platform is much more important for them than 64bit.

      • If xplat is more important for them than 64 bit one day they will awake with a nasty surprise. I may understand Embcarcadero could like to move its db products to other platforms, but delaying 64 bit more could damage Delphi a lot.
        Anybody noticed Office 2010 64 bit?

  6. iPhone, android and other Mobile platforms is going to be thefat client space of the next decade not counting server apps. Delphi should address both these areas with it’s unique snap architecture, etc. There’s just no reason to use Delphi if it does not.

    • Who became rich selling iPhone applications? Where’s the Android phones? I see more WinMO and Blackberries around than anything else πŸ™‚ The only one making money on iPhones is Apple. Period.

  7. .NET is not the only competing platform besides Windows. Java currently seems to be the dominant development language. According to the Tiobe index (http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html) it is almost five times more popular than C#. The NetBeans and Eclipse IDE are free and open source, and so are most Java Enterprise software development technologies and toolkits, even enterprise servers like Geronimo or GlassFish.

      • None. First the Java license may not allow it. Second, it would hit the same issue it had with .NET. Why should someone use another language but Java to code Java applications?
        Despite all the hype, VMs running managed code do not rule the world yet – they have their own issues as well. Thereby why let them level the field? Eventually, every line of code must become processor opcodes to be run – what changes is how an application gets there, and how good that code is.
        What Delphi really needs is a far better compiler and improved RTL libraries. It’s a bit funny that D2010 TThread implementation does not allow for setting the thread stack size yet, for example.

      • #1 cross-platform Delphi compiled for the Java platform (like Delphi Prism does it already for the .Net “niche”). #2 the compiler does not have to target all possible processors, only the JVM. #3 many technologies like JIT and AOP (aspect oriented programming using bytecode modification) or “hot” code modification (recompiling code parts into the bytecode of an running application during debugging) are there already.

        • Cool! And who would use it instead of Java? Who’s buying Prims instead of C#? Why should someone use a niche language without any advantage while the main language has books, extensive documentation, examples, a working help… and better employment availability?
          Why should someone buy an expensive Pascal to Java compiler when Eclipse is free? Look at what happened to JBuilder… please, build a business case for a JDelphi compiler.

  8. What I am waiting for is

    1) 64BIT ASAP. I was hopping to have it on D2010 but no joy.
    2) Server side linux development. EE CGI/ DataSnap servers/ SOAP/ APACHE SO etc.
    3) Mobile thin client development. Not required though it can be safely ignored I just like to have it nothing more.

    I do not care about MACOS development, Linux Clients, or any other OS I certainly will not support IPhone in any incarnation as long as I’ll have to go through the Apple store only, as for other mobile I have focused on embedded windows mostly or devices that can run a full windows OS with basic functionality not even a network is required for the type of application I want to use them.

    So I am mostly covered at this point and I will not invest in anything else, I will not invest in mobile either if the price is too high for me I’ll just as well go with the native platform tools which are in most cases free.

  9. The main difficulty is a cross VCL. And there is only Qt at the moment. They have the expertise! Very hard for Emba. They lost their time and money with CBuilderX, Delphi 8, CSharp IDEs, useless BDS IDEs etc. etc. etc. … very hard for them now!!!

    • The bigger mistake they could do in xplat is trying to build a cross-platform GUI library. 1) They usually look so-so on any system they run on. Right now Delphi available controls are much more advanced and stylish 2) They don’t give access to the more advanced controls available on each platform (Windows 7 comes with built-in ribbons, for example) 3) They make integration with the underlying operating system harder.
      4) The more layers you add, the slower your UI becomes. Losing one advantage of native code. 5) If using Qt or something alike, your tool depends on another layer not under its control, not designed to integrate with its architecture.
      5) Each operating systems has different standard for menus, shortcuts, buttons position, dialogs and so on. Writing really native applications needs different native GUIs on each system – unless you like applications that looks born elsewhere and just adapted to run.

  10. 64bit support ASAP.

    Absolutely NO INTEREST in Mac or Linux for the forseeable future.

    Developing engineering analysis (FEM) and virtual reality software using Delphi, and we deal with very large amounts of data.

    • Agreed – 64 bit ASAP.

      We develop (among other things) back office database client/server software that will shortly be dealing with billions of records and which performs significant processing over that data.

      We need the memory space and speed improvements Win64 offers.

      We have no plans to target cross-platform systems in any time horizon.

      We also do .NET compilation from existing code, but this is currently jeopardised by Delphi Prism which cannot compile Object Pascal. This also needs to be fixed before [other] cross platform support is provided in Delphi.

  11. Going Cross-Platform as the most viable business case for Embarcadero seems clear. However to go for a new market without having stabilized the existing Delphi market doesn’t seem very smart.
    Just when they are getting trust and momentum back in the Delphi community they seem to want to alienate them again by giving lower priorities to native windows development like win64.
    Fighting from a solid base in the direction of a new market seems the way to go for me.

  12. Our application is a server side Application Server, so what we need :

    1. 64 bits to address more than 4Go
    2. Linux server side because it’s a market trend
    3. better multi-core supports (fastmm4 is not good enough on multi-core) and something like DPL library

  13. Cross platform is for future but if they can solve 64bit issue, they can solve the platform but not the otherway around. For me, here is list from top to bottom

    1. 64 bits
    2. Thread and Memory contention
    3. Thread with stack size. We have application with a lot of threads or hosted on terminal that requires resource. Less resource requirement, more instants can be ran on terminal
    4. More realiable tcp (client server) frame work with compression and encryption hook. Forget about Indy at current state
    5. all vcl controls must have the same look and feel


  14. … and just to rub salt into the wound, I did a little Googling and found that the Lazarus + FPC system already supports compilation to x86_64/Win64!

    • hehe. While Borland was busy with the .net hype (now almost death), Lazarus’es improved their cross ability on both targets 32 bit and 64 bit, Linux, Mac and Windows.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s