[Estimated Reading Time: 3 minutes]

In a comment on my previous post, David Michael made some observations about the cost of Oxygene being comparable to Delphi. This surprised me, so I did some checking. The results surprised even me.


I should mention that I took advantage of an upgrade pricing offer when I purchased Oxygene so I am in the rather odd position of having obtained my Oxygene license for significantly less than the current new user price, and my renewal will be more expensive than that initial cost. Whether any such upgrade offer is still on the table for Delphi users is something you will have to take up with RemObjects. Despite what some people seem to think, I am no closer to RemObects than any other user or potential user and have no inside track on such things. 🙂

But, back to the point. Let us consider the proposition for a potential new user of either/both Delphi Professional and/or Oxygene. For convenience I am not bothering with “$99” pricing but rounding up to the nearest $10, so $699 becomes $700, $1499 becomes $1500 and so on.

I am also ignoring any sales taxes that may or may not apply. As such I don’t suggest you present these numbers to your accounts department as a solid cost analysis, but they might prompt you to revisit just such an exercise as relevant to your particular circumstances.

Finally, the title of this post – “Cost of Ownership” – is not of course strictly accurate. Real “Cost of Ownership” involves more than just basic license and support and maintenance costs, which is all that is being considered here.


The first thing to mention is that with Delphi you are charged for your first year of SA from day one, not after 12 months so the up-front cost for Delphi consists of:

Component Cost
Delphi Pro $1000
Mobile Add-On $500
Pro SA $300
Mobile SA $150
Total $1950

For Oxygene the initial price is just that. The initial price. Presenting us with the following proposition:

Initial Cost Renewal/SA
Delphi Pro $1950 $450
Oxygene $700 $500

So, ignoring the impact on up-front cost, Oxygene renewals are ~10% more expensive, but When I took out SA with Embarcadero they put my renewal up 4% after the first year (or rather they tried – they had to back down when I referred them to their own contract) even though the upgrade price itself hadn’t increased.

Yes, Oxygene renewals could increase as well.

One way or another, that difference is unlikely to remain at 10% / $50 forever.

But whatever the future holds for renewal/SA pricing, the upfront cost is significantly more expensive with Delphi, and it made me wonder how long it would take for the ostensibly higher renewal costs to erode that advantage.

So just for fun I did some calculations, assuming that SA and Oxygene renewals remain fixed at current prices (yes, unrealistically perhaps, but without a crystal ball I don’t see that any other assumptions is any more “realistic”):

  • It would be 4 years before your total spend on Oxygene is more than the up-front cost of Delphi
  • It would be 26 years before the total spend on each is the same


But it gets even more interesting. Those “particular circumstances” that might apply to individual cases have thrown up a big difference here, where we are served by Embarcadero’s Australasian online store.

Up until a few days ago when I last checked in response to a different enquiry, the Embarcadero online store was presenting me with prices in US dollars. When I went back to double check my figures for this post, I found that for some reason the store is now showing prices in Australian dollars.

The prices are not simply converted. The price in AUD is almost 10% more expensive than the previous USD prices.

As a result, the up-front cost for an Australasian new user of Delphi is now over $2100 and SA is $480 (US $) meaning that it would be 63 years before the total spend on Oxygene reaches the same as the total spend on Delphi.

Not perhaps relevant to the wider world, but of interest to those it may affect – not to mention disappointing.

56 thoughts on “Delphi and Oxygene – A Cost of Ownership Comparison”

      1. No, please stop lying. The database connections you mentioned included calling external libraries and that you can do on Delphi putting a single component becomes doing all by hand, as in dos times!

        Show me the code for open a database connections with oxygene, start a transaction, open a table, insert a record or delete one…

        1. It wasn’t a technical post exploring database connectivity. It was a basic cost comparison.

          There are differences in database connectivity support but you weren’t specific with your “question”. When I get to database connectivity I will deal with database connectivity. But for now I can say that the needs of a mobile device in this area are vastly different from those of a desktop application, and the capabilities in Delphi on mobile devices are largely (but not entirely) irrelevant.

        2. As long as we’re playing database challenges, it’s been seven years since the introduction of iteration to Delphi. Show me the ability to iterate through query results (and I don’t mean “While not EOF”). Oh, and if you could, please show me the ability to access said results without typing something along the lines of


            1. That’s my point. 🙂 It’s hard to see because of the indenting, but my challenge was to Daniel defending Delphi’s database capabilities, not to Deltics and Oxygene.

              I’ve found I’ve gained both the ability to iterate through query results and directly refer to result fields (e.g. results.name) with Python, by the way. I believe this is better than Oxygene too, but the only example I could find was a site written in Japanese. The Oxygene Language Wiki didn’t have any examples; just listing the names of example projects that are included with the product. 🙁 No general viewable or downloadable documentation that I could find, either.

              1. I got that. I just took the opportunity to expand on the vagueness of the roadmap with some further insight into the fact that the vagueness is not just an accident of poor presentation. 😉

                The Oxygene documentation is definitely an area that could be improved imho, no argument from me on that score.

          1. Unified Interbase library had this. But Henri Gourvest wasalways very bad on dicumentation and also got fed up with EMBT and quit Delphi year ago…

      2. FireDAC SA is cheaper than AnyDAC SA. For people who still believe that Delphi or C++ Builder are the best option for WinXX.

        Delphi Pro SA is 280 EUR
        AnyDAC SA is 150 EUR

        I can’t complain about XE4,. Installed it today on my book i5 into a Win7/64 box on Parallels. Pretty fast. The problem with 64bit debugging is gone.

        At the moment my altar versions for Delphi as well as VS pro with C# are XE and 2013. I will wait and see what Win 8.1 and Win 9 will bring. From a TCO perspective and I think you talk of one seat … if you use open source then you – need – neither Delphi nor VS.

  1. Worst situation in Europe. 1950 USD = 1950 EUR is real 2570 USD!!

    2570 USD (embt) VS 700 USD (oxygene) …
    580 USD (embt SA) VS 500 USD (oxygene) …

    EMBT increased SA not by 10% but 50%! 300 USD/EUR + 150 USD/EUR mobile addon!

  2. Why that comparision? Delphi is much cheaper than a Porsche and more expensive than a banana…. Oxygene is .net based. .net is managed software crap. Hello to reverse engineering and to your competitors. I don’t want oxygene.

    1. Oxygene for .NET is .NET based.
      Oxygene for Java is Java based, not .NET
      Oxygene for Cocoa is, I believe, LLVM based, but certainly not .NET

      If you are only interested in the Android and iOS support in Oxygene (which applies in my case, incidentally) you can ignore the .NET support entirely.

      Bottom line: You don’t have to use it but this comparison was for people who are considering it for mobile development and are interested in the cost comparison vs Delphi (when faced with new user costs).

      1. JVM is also managed GC VM like CLR

        Though i doubt that reversign his code is really that large of an issue for average programmer

    2. ” Oxygene is .net based. .net is managed software crap. Hello to reverse engineering and to your competitors. I don’t want oxygene.”

      That’s not a fair assessment of either .Net or Oxygene.

      A strong argument can be made for Delphi based on its merits, so there’s no need for hyperbole.

    3. Agreed. Working on crap makes your money. Nothing specific to .net or Java. That’s is the sad part of the IT business.70% of your salary are pain and suffering money, 20% are for the mobility and 10% is what a programmer is worth if everything else works smooth. Not saying this reflects the reality but that’s how customers see things.

    4. >Oxygene is .net based.

      A fact those not living on Delphi Island (that mist-shrouded isle completely isolated and cut off from the mainland) haven’t cared about in ten years.

      >.net is managed software crap.

      When Embarcadero’s CEO tried dredging up this outdated rhetoric in an interview, the reporter commented on his blog post-interview that talking to him made him feel like it was still 1995. 😉 The “crap” you speak of is one of the most popular programming languages in the (Windows) world. If only Delphi were 1/15 that crappy.

      Managed is the future (as well as the present) outside of Delphi Island.

      To quote The Register recently….

      >…the assembled chipheads were led through a four-hour deep dive
      >into the latest developments on marrying the power of CPUs, GPUs,
      >DSPs, DMA engines, codecs, and other accelerators through the
      >development of an open source programming model.
      >The tutorial was conducted by members of the HSA – heterogeneous
      >system architecture – Foundation, a consortium of SoC vendors and IP
      >designers, software companies, academics, and others including such
      >heavyweights as ARM, AMD, and Samsung. The mission of the
      >Foundation, founded last June, is “to make it dramatically easier to
      >program heterogeneous parallel devices.”
      >According to Rogers, heterogeneous computing is nothing less than
      >the third era of computing, the first two being the single-core era and
      >the muti-core era. In each era of computing, he said, the first
      >programming models were hard to use but were able to harness the full
      >performance of the chips.
      >”In the case of single core,” Rogers said, “we started with assembly
      >code, then we went to much better abstractions: structured languages,
      >objected-oriented languages, managed languages. At each stage you
      >give up a little bit of performance for massive improvements in
      >productivity, and the platform volumes grow extremely fast as
      >programmers can use the platforms much more efficiently.”

      They go on to talk about integrating CPUs, GPUs, DSPs, etc. together through a language as high-level as C++ or Java and how close they are to getting there. And of course it’ll all be open standards/open source.

      But the relevant point to your comment is that contrary to the streak of Luddite-ism that seems to run through the Delphi community, the outside world views managed code as offering huge productivity (and security/reliability) improvements. Given two of the top three languages are managed (C# and Java), and most of the rest of the others are too (Python, Ruby, Javascript, PHP, etc.) it’s quite clear that all of this “native” talk is going to fall on deaf ears. It’s not something people are concerned with anymore, especially in an era where entry-level CPUs are quad-core and provide more horsepower than the average user needs. Managed code is seen as a plus, not a minus, if there’s any opinion at all.

      > Hello to reverse engineering and to your competitors.

      You do have a EULA and a copyright, don’t you? Do you have sort of magic formula they could steal? And somehow get away with stealing (risking their entire business in the process)? And Delphi’s somehow non-reversible? Even though Delphi itself is always cracked within a week of its release?

      These are tired old criticisms that simply aren’t very applicable in 2013.

      1. Theres a huge difference between the level you need to crack a software, and the amount of software you can buy to produce entire source code from any .net project. I just work with one, cannot make access a net dll from delphi, just get it and dissasembly with all the source code, unit names, etc, all the code there… You must be kidding, no thanks my business have many secrets to expose so easy to anybody without ethics.

      2. >> Hello to reverse engineering and to your competitors.

        >You do have a EULA and a copyright, don’t you? Do you have sort of >magic formula they could steal? And somehow get away with stealing >(risking their entire business in the process)? And Delphi’s somehow >non-reversible?

        Not a one of the so said “delphi decompilers” that I got hands (or heard) in the last 15 years really decompiled delphi code, most of them just extracted the frm resources. The best of them extracted the assembler generated for the events. No one generated compilable pascal source code.

        On the other hand, decompilers for .NET and JAVA are plenty and get perfectly compilable (or almost) code easily. NET ones can even translate the code from IL to any CLS-compliant language. Even a monkey can do that.

        That’s why no .net stack is complete without an program to minimize that characteristic: an obfuscator. I don’t know Java, but I believe that’s not that much different.

        >Even though Delphi itself is always cracked within a
        >week of its release?

        It’s an entirely different thing. Hacking an protection scheme is not an problem to someone really motivated and accostumated to hacking.
        VS, Adobe tools, Windows and other big software are also hacked in days (or few weeks) after release.

        Decompiling an natively compiled executable is COMPLETELY different challenge. And in 15 years no one even got to win the delphi compiler in that challegne

        1. Decompiling to a specific source language operating at a higher level than ‘C’ is undoubtedly more difficult and is a challenge that someone is only going to undertake if there it is going to be sufficiently worthwhile. The decompiler not only has to disassemble the code (relatively easy) but also incorporate knowledge of the compiler and RTL library composition of the target source language.

          In the case of Delphi code for example, a decompiler should be able to recognise RTL operations on strings and represent them as such in the decompiled source, but a generic x86 decompiler without this specific knowledge of the Delphi RTL can still successfully decompile to the naive ‘C’ code equivalent.

          This absolutely is not impossible, not even particularly difficult. But it would be a hell of a lot of work for very little point.

          The fact that nobody has felt it worthwhile tackling for Delphi specifically is not an indication of any particular strength of security, only a manifestation of “Security through obscurity”.

          The net effect is of course “more secure” source code. But someone who thinks you have an algorithm worth stealing won’t be much concerned about reverse engineering to your specific original source code, just to some source code they can work with. If anything it seems to me that the fact that they can’t decompile to Delphi would make it less likely that they will “get caught” doing so.

          1. It’s particularly difficult if you take into consideration many compiler optimizations make detect the intent of a piece of assembly difficult even to a human programmer decipher, let alone an program.

            1. Compiler optimizations? in Delphi classic (not LLVM) compiler ? They have any significant impact on ASM code readability ? No…

        2. It is the same for Java.

          Many people decompile Android of their phones to fix something and recompile it back, and they say that once you did it it is really a routine no-brainer task

  3. To do a true TCO analysis you need to consider the cost of the human capital required in each case. How difficult is it to either find devs that know the tool or to ramp up a dev to use the tool? How many devs does it take? How much do you have to pay them? Can you really get devs to use the tool in the first place? How much code will have to be written to complete the integration of the tool/framework with the app’s main functionality? What kind of dev talent do you have on hand?

    These kinds of considerations completely dwarf the price and upgrade costs.

    1. You saw the part where I acknowledged that and are just choosing to ignore it, or didn’t actually read the article so didn’t see that acknowledgement ?

      Just asking.

  4. Ok, you will probably need a bit more time with RO to realize how pricing works. My renewal came on mid August and I was surprised with an increase of 40% from my last year cost. Why? how? no idea.

    They are a good company, but documentation (yes, that wiki) is miles and miles away from Delphi’s one and bug regressions are common, you just learned to live with them. (yes, more common than Delphi’s).

    Finally, I understand why a Delphi shop will better just stick with a common language that gives them all than having to go through a conversion and learning curve. XE4 for us is great, IDE is extremely stable and we are loving certain features like livebindings.

    I can see your enthusiasm in cutting EMB’s wings, I ignore your motives and the reasons behind them, but you just started with Oxygene. Lazaurus and who knows what, give them some time and then talk.

    1. Yes, I believe they increased their prices when Nougat went to release status. Renewals and new user pricing increased. I see no problem with paying more for getting more.

      With Embarcadero I had a renewal increase together with a reduction in product capability – they removed iOS support from XE3 – and when upgrade and purchase prices had not themselves increased.

      1. They increased prices by almost 40%.RO was never ‘cheap’. If you say I want to be in the position to fix the infrastructure products in a somehow convenient fashion you need Oxygene and the tools that the platform vendors provide out of the box. RO does make sense if you have specific demand. RO is not another wsdltoobjc combined with Java stacks. The TCO comparision in case of RO are little cheaper (assuming teams) than the Java Stack JBOSS for example. JBOSS is still about 5 to 10% of IBM, Oracle Stack’s price …

        Delphi is not in this league. You can come into this area of you consider RTCSDK.Then you touch RAD Studio Enterprise + StreamSec + scalemm + Fire/AnyDAC + Habari (optional).

        The other way would be pure mORMot.

        From TCO perspective simply use ASP.net and fast hardware or mORMot.

        1. We don’t aim to be “cheap”. We aim to provide great tools and what i believe are fair prices (that do need to sustain our business, but do not pay for yachts and beach front homes).

          1. Agreed. Would not make lots of sense at the Spree anyway similar to the Danube here.

            TCO does count when infrastructure comes into play.When we talk about TCO we must come to the point where find a useful comparison. I simply chose for the Java stacks in order to find a good comparison. JBOSS with the micro vm approach is a good one … Oracle and IBM ship bloatware made up things invented a long time ago no one ever really needed, RAD Studio is something similar if we talk about ‘IDE’s and Compilers’

            EMB do not bear a comparison with RO. Two different worlds. Most of the people here are simply candidates who will not choose for Delphi and my impression is that those who still do are not aware that their day had come a long time ago. At the time of Delphi 4/Midas very likely.

            Look at EMB website – ‘consultancy’. with a tool store.

            The whole history of EMB during the last years was about consolidating sales channels and such things …. they are aim(ing)/ed at becoming something bigger aka ‘Inprise’. That’s my guess. There was a statement on a blog once. Not sure if this is a certain kind ‘motivating’ people to work hard a low salary.

            There is a difference between making money and shipping quality software.

          2. You increased prices by 40% but you added a stack. The price increased because of lower EUR exchange rate too. I don’t intend to blame anyone because of the prices. Those have been increased after a significant drop before.4 DAs combined are cheaper on an avg. than 3 before in practice, there is always one for free.

            I was just waiting this time because I was simply thinking of using just DA .net + Coca.

            I think we will see stronger increases during this decade and little beyond in the price level the whole western world. Prices will almost double imo. From next year on + 10 at a general level..

            Oxygene is a matter of taste, matter of good taste. Oxygene addresses precisely the developers needs.

            I am not a developer:) Oxygene works pretty well.

    2. FTR, we did have “special offer” pricing in place before Nougat (the Cocoa support in Oxygene) was officially released in May. That lower pricing, combined with that many users qualified even lower renewal pricing *from* Prism does make the current/official/renewal pricing higher, yes.

      Official pricing for Oxygene is $699 for new users, $499 renewal (the special offer was $499 for new users, and iirc $349 renewal from Prism).

      I’m not sure if it is entirely fair to talk about a “price increase” in the context of having benefited from a special offer previously. But i certainly apologize if the mechanisms had not been made clear enough.

    3. That “they are a good company” is an important statement. Exempli gratia: I had problems trying to make their product DataAbstract work in my application, so when it was the time for renewal, I emailed them what was basically a rant about what I thought were shortcomings on their product, and that I wasn’t renewing because of it (what a whiner!) I didn’t just received a personal and thoughtful email from Marc himself, but he also extended my license for a full year. That’s pure class in my book.

  5. I can not see the benefit os SA on Delphi, each year they sell a new product , and worst XE4 was half a year, Would anybody help me to see the benefit?

    1. With our SA on XE3 we got XE4 and will get XE5 as well. In this case XE4 was not as expensive as a normal release, but if we would upgrade to every new release we would pay much more than with SA.

      As we are interested in features like FireMonkey and mobile development we’ll have to keep on with the newest versions. And I personally like to use the newest versions of software, let it be Delphi or Windows or other.

  6. To be fair, RAD Studio’s release frequency does not matter if you purchase and maintain SA. RAD Studio’s main problem right now is FireMonkey’s still immature status. If they get it right, it would have significant advantages. I only wish they would have given up some of the cross-platform-unfriendly functionality and instead created more of a wrapper framework, but one with more cross platform consistencies than Oxygene. Somehow the middle-ground is missing.

  7. Oxygene is simply not a Delphi replacement. Both environments are not compatible. Oxygene is not even compatible with himself. Using Delphi, I can use the same code on Win32, Win64, OSx, iOS and Android, including the user interface (FMX). Oxygene can’t do that. And Delphi generate true native code for all platforms. This is not the case at all for Oxygene whatever RemObject may say.
    So you cannot compare the price since the two products are actually very different altough at first glance they could looks similar.

    1. Using Oxygene I can use the same code on .NET (Windows 32-bit, 64-bit and Linux), Java, Android, iOS and OS X. Of course, to do this I have to make sure I use only certain things if I wish to use the same code unmodified across all of those. This is no different than Delphi. The “certain thing” in that case is FireMonkey and in that case your capability to support various platforms is contingent upon and dependent upon that framework being adequately updated by Embarcadero.

      You want to support iOS 7 ? Well, as an Apple Developer (which you have to be, even with Delphi) you get the iOS 7 SDK betas. But you can’t make use of them in your Delphi applications (without a lot of hassle) and your Delphi iOS app won’t even look like an iOS 7 application unless and until Embarcadero enable that. And probably charge you extra for the privilege, or try. Graphic designers are expensive you know. 😉

      I do not know what it is you think that RemObjects have been saying that isn’t true. The only people making bogus claims about Oxygene are those doing so from a position of apparent ignorance or wilfully misrepresenting the facts.

      As for legitimacy of the comparison, for somebody interested in a tool for mobile development, i.e. without the burden and baggage of legacy Delphi code the two are absolutely comparable. Just as Delphi can be compared by the same person with Eclipse and Xcode which are truly incompatible with each other.

      1. Is your statement about Embarcadero “probably charging you extra for the privilege, or try” a bogus claim, apparent ignorance or willfully misrepresenting the facts?

        1. It’s impossible to misrepresent “facts” that do not as yet exist. One can only speculate as to what those facts might turn out to be. Which is what I did.

          As far as I know Embarcadero haven’t disclosed pricing or a release date for XE5 as yet, let alone said anything about iOS 7 support specifically, beyond the observation that they have a graphic designer (:face-palm:) working on that. So I don’t know that they will be charging extra for it, but neither can anyone say yet with certainty that they won’t.

          Unless you are privy to some information ? Care to share ? 😉

          In any event, I think it was quite clear that I was speculating, so accusations of “misrepresenting facts” is entirely unfair. I was not presenting anything as fact, let alone contradicting any established fact.

          And of course, that speculation was based on recent precedent and intimations concerning other aspects of the XE5 release.

          At the RAD Studio event they showed slides that mentioned “REST Connectors”, with support for various REST web services (the likes of Twitter, DropBox etc). David Intersimone did say that these would be released and more made available and mentioned that there may be additional costs involved for obtaining those (not a quote, just an emphasis – I forget the exact wording that David I used, but the essence was that they might not be free/included).

          It’s not as if they haven’t tried charging for additional styles before … e.g. the “Jet Pack”.

          1. > and mentioned that there may be additional costs involved for
            >obtaining those (not a quote, just an emphasis – I forget the
            >exact wording that David I used, but the essence was that they
            >might not be free/included).

            I believe the exact wording was “Come on, baby needs a new pair of shoes”.

          2. Anyone who expects a free update to XE4 with iOS7 support — especially with XE5 being imminent, and probably shipping before iOS7 — seriously needs their head examined, i would say.

            The very idea is as ludicrous as the fact that such an update is *needed*, to begin with 😉

          3. iOS7 support (in XE5) will come as an incremental update. according to a recent world tour presentation

            1. Did they also explicitly confirm that the incremental update would be free ?

              XE4 was an “incremental update” over XE3 (for a Pro user refusing to be led by the nose to the Mobile Add-on trough), yet they still had the cheek to charge for it.

              Additional REST connectors could be described as an “incremental update” but David I (also at a world tour presentation) was quite clear that they haven’t yet decided whether to charge extra for those or not.

    1. Indeed. Another great thing about RemObjects is that they are very open and forthcoming about what they are working on and what they won’t be working on.

  8. You mean Embarcadero “considering adding to the roapmap” Linux support, Win/RT support, etc. Isn’t good enough for you? Why, that’s as firm a commitment as my considering to add climbing Mt. Everest to my to-do list! 😉

    1. He-he. Again, I didn’t make a song and dance about it since to do so would have attracted more accusations of being a Negative Ninny, but that roadmap masks a huge amount of uncertainty that came out during the world tour presentation.

      WinRT and Linux on the roadmap ? Sure. Time frames…. ah well… there-in lies the rub.
      You will note that anything beyond iOS and Android (2013) is undated. Newsflash: The future will be in the future!

      You’ll have to forgive me if I don’t hold the front page to break that news. 😉

      But in response to questions from the floor we gained this further insight: Improvements to the current botch job for Windows 8/RT support are contingent upon what Microsoft do. Embarcadero’s Windows strategy is based as far as I can tell, on waiting until whoever takes over from Ballmer takes over and what he/she might or might not do. Reading between the lines, I think Embarcadero have written themselves into a technological dead-end with their approach and they need co-operation from Microsoft to get around that; co-operation that isn’t forthcoming under the current management and so they are forced to pin their hopes on a more friendly regime in the future.

      In any event, Linux will be after that, just server at first but maybe desktop as well, they haven’t really decided and it sort of depends and it will be after Windows. Or maybe before, depending on what Microsoft do. Or don’t do. But look! It’s on the roadmap, so relax!

      Good luck basing your decisions on such information. 😉

      Now go and read the RemObjects discussion thread that Donovan linked to. Absolute answers are given about what will not be done and the reasons behind those decisions given and explained (whether you like the answer or not, at least you know and can make your decisions as a result) and timeframes given for things that will be done – again, maybe not soon enough for some people, but at least you know and can put some semblance of a plan in place accordingly.

      1. “Absolute answers are given about what will not be done and the reasons behind those decisions given and explained (whether you like the answer or not, at least you know and can make your decisions as a result)”

        If this is important to you, how do you even CONSIDER developing for .NET Framework? Ok… Now you are using WinForms and bang! Now it is deprecated in favor of what? Ah yes, WPF. Ops! Wait! Seems to me that WPF will follow WinForms, will it? Don’t know… how knows? What else will MS drop and make your 1 million LOC program obsolete in 24 hours?

        In 1998 I was working for a company and we had to decide if we would use VB or Delphi for the next BIG project. Delphi was chosen and the time proved us correct. If we went to the MS way, we would be SOOOO screwed when VB became useless overnight.

        1. Who said I am developing for .NET ? My interest in Oxygene is (currently at least) limited strictly to Java/Android and iOS/OSX support (and perhaps Win RT/WinPhone 8). The Java/Android/iOS/OS X use cases for Oxygene do not involve .NET development.

          1. You are missing the point entirely. I didn’t say you are developing for .NET. But if “Absolute answers are given about what will not be done…” is important, how can ONE consider ANY .NET based product for development? When I read your recent posts, seems to me (and I guess to most readers) that you are saying that Delphi is huge pile of crap and Oxygene (not only Oxygene for Java or for Cocoa) is a better option than Delphi. So… Should I understand by your previous answer that Delphi is better than Oxygene for Windows development?

            1. Then I don’t know what point you think you were trying to make. I have often said the same thing about .NET myself. I don’t know how much of Oxygene depends on .NET. As far as I know, some parts of Delphi remain dependent on .NET. So if you are trying to make some point about the comparative advantage of one over the other on that score your reasoning is not at all clear.

              I am not saying and have never said that Delphi is a huge pile of crap. FireMonkey on the other hand, yes that is a massive turd of titanic proportions. Flawed both in conception and implementation.

              Oxygene is certainly better than Delphi for mobile development (and in some respects better even than the platform native tool chains). As for Windows development, it depends what you mean. For Windows RT/Windows 8 Delphi is a non-starter, so Oxygene is absolutely “better”. For Win32/64 Oxygene doesn’t even try to compete so comparison or point scoring on that basis isn’t just unfair it’s entirely meaningless.

              Delphi is still the best tool for Win32/64 development imho but risks falling behind as a consequence of the FireMonkey folly.

  9. ->>>Managed is the future

    Marketing argument for .net-environment-producing companies.
    Echoed by people with no ideas, who have no idea how to produce fancy software.

    People with this unreflected undifferentiated view “Managed is the future ” says a lot about their simple onedimensional view of software programming.

    Test: Today there are twice as much c++ jobs than c# jobs on stepstone.
    Hahahah, and MS itself deliveres a .net-free new platform WindowsRT, returning to com-like architecture.

    Managed is delivery of knowlede to competition and the way to locked machinery, where only the vendors have full access to.


Comments are closed.