Embarcadero’s Newest Dog Food

I’ve been a developer now for 19 years….wow!  A lot has changed over that time, but one constant has always been  that software companies who use their own products internally produce better software.  It’s called DogFooding in the industry.

When .NET first came out, a lot of developers were opposed to writing .NET code for performance reasons including load time, as well as the size of the executables, and the speed of the code.  One of the arguments against using .NET was that none of Microsoft’s own products were written in .NET.  Of course a lot of this had to do with the fact that their products were large legacy codebases and .NET gradually crept into the mix.

When WPF first came out a lot of developers thought it was interesting technology, but no one was using it, and the GPU overhead required newer video cards.  WPF usage gradually increased as Microsoft frameworks leveraged it, and then Expression Blend, and Visual Studio 2010 shipped showing that Microsoft was dogfooding their own technology.

The thought occurred to me today, that having to use FPC with XCode for the Mac can’t be a long term solution.  EMB has said they will be shipping their own compiler for the Mac, but what about the IDE?  Any conditional compilation will eventually require code editing in XCode which doesn’t have code completion for Pascal and all the other features of the Delphi IDE.  In addition, at some point requiring two machines (or a VM) when you’re targeting one platform will just become a pain.

I wonder if EMB will follow Microsoft’s example, and use their own UI framework that would have the added advantage of enabling EMB to make the IDE X platform.  That would be the ultimate showcase for their compiler and FireMonkey.

8 Responses to “Embarcadero’s Newest Dog Food”

  1. Chris Says:

    Ahhhhh!!!! Sorry, but when yet another person conflates iOS and OS X… Embarcadero *have* ’shipped their own compiler for the Mac’, and it works fine (as well it should do, given its basically the old Kylix compiler merged into the current DCC32 codebase): it’s for *iOS* that XE2 uses FPC and a bit of Xcode for, due to the combination of iOS running on ARM not x86/x64 (-> FPC) and its added monopolistic licensing conditions that requiring special workarounds (-> Xcode). For OS X, you write a FMX application as normal, ideally cross compiling with Win32 and Win64, then use the Delphi remote debugger (renamed ‘Platform Assistant’) to debug - no FPC or Xcode in sight.

    WRT your dogfooding point, which I agree in very general terms, I’m sceptical about the need for a Delphi IDE on the Mac specifically - the remote debugger works pretty well, and the troubles of the Kylix IDE didn’t set a very good precedent. OTOH, and off the top of my head, RadPHP might be a more suitable candidate for canine reinvention - presumably a relatively small product in terms of both codebase and revenue, it would therefore be a much less risky project to do. And, like you say, I’m sure doing such a rewrite would help FireMonkey tremendously.

  2. Larry Hengen Says:

    @Chris,

    You’re definitely right about EMB shipping a compiler. I should have said a compiler that produces 64 bit OS/X targets as well as iOS. Thanks for correcting me. When I wrote the article I was thinking about an iOS target as currently that is what I am most interested in.

    WRT my dogfooding point, I still think the Delphi IDE would be a better choice than RadPHP since more people will benefit from the port. With great risk comes great rewards. In one move EMB could have arguably the most desirable native language and IDE across 3 different platforms (OS/X,Linux and Windows), and if anyone should have enough confidence and abilities to pull it off, EMB should.

  3. Chris Says:

    @Larry - I wouldn’t have thought 64 bit OS X should be a problem, as and when there’s a need for it (the reasons Win64 support was needed don’t really apply on OS X). One of the benefits of Delphi targeting the Mac now rather than (say) 10 years ago is that there’s been no faffing about with APIs Apple subsequently deprecated - FMX uses Cocoa not Carbon, the RTL hasn’t had to work around the change in file path syntax between OS 9 and OS X, etc. As I’ve recently blogged about, I’ve only come across one area where a now-legacy API has been used, and even that seems to have been a case of wanting to use something else but couldn’t. If only FireMonkey itself wasn’t quite so half arsed at present…

  4. Ciprian Mustiata Says:

    I think that is very hard to do it: Embt seem to have 1 year iteration, but to replace from scratch an API to another API, and doing so, it will use a different technology at all (I think only FMX is a possible way to make it cross platform), and this with all crashes and such, is really hard to achieve. Also, it seem to me that FMX cannot be mixed with VCL, when WPF can be mixed with Windows Forms, with C++ code, COM and such.
    At the end maybe they will start replacing tools that come with Delphi, later the Options, the next iteration they will integrate views that use FMX, and after 3-4 years they may get a working IDE that have this.
    At the end I’m pondering: can a complex control as the code editing window to be migrated in 6 months to FireMonkey? What about other code components that are coming with? Will all break? If FireMonkey will become the host window, how can be embeded the VCL designer for “legacy” VCL applications?

  5. LDS Says:

    Read how happy were MS developers about the new VS IDE….

  6. Anthony Frazier Says:

    @Chris: Wouldn’t a new Delphi IDE — written in FireMonkey, and available for Windows & OS X — do quite a bit to increase your confidence in FireMonkey itself? It would me, and I think that’s the real point that Larry’s trying to drive at. I’m not saying they should do it for XE3, and maybe it’s something they’re already exploring.

    Of course, EMBT does do it, and the new IDE is as awesome as Delphi 8 was, well… :-)

  7. Chris Says:

    @Anthony - it would be a waste of time IMO, with much of that spent on non-UI things. FireMonkey is just a visual UI framework - it’s not a debugger, build system, refactoring engine, etc. etc. To me, Lazarus on OS X demonstrates the pointlessness of retargeting an IDE for retargeting’s sake - despite being a ‘native’ application, I struggle to see the Lazarus experience as superior to the XE2 cross-compiling+remote debugger one. In fact, it’s been much, much worse for me when I’ve tried it.

  8. Larry Hengen Says:

    @Ciprian,

    FMX can indeed be mixed with VCL. RemObjects has done so, and there are other articles & videos on the web detailing how this can be done.

    I don’t know where you got your 6 month time frame from. I certainly wouldn’t expect it in that period, although the quicker the better form a marketing standpoint.

Leave a Reply