Saturday, July 6, 2013

Inprise Reprise

I was reminded recently that Delphi was Borland Delphi first, then Inprise Delphi briefly, then back to Borland Delphi, and then more recently, CodeGear Delphi, and then after the Borland/Codegear split, it became Embarcadero Delphi.

I would love it if anybody who knows more of the real details would come along and fill me in, but from where the Delphi user sat, this is what the whole Inprise thing looked like to us:

Borland in the early days was Philipp Kahn's company.  It was a software company that sold general utilities for microcomputer users.   For DOS, there was  SideKick, an early "PIM" (personal information management) program for DOS, launched in 1983, the same year that TurboPascal was first launched.  You may remember that TurboPascal first was a CP/M tool.  Originally written for Z80 by Anders Hejlsberg, and running on a single board Zilog Z80 CPU based hobbyist computer called the NasCom, that few of us ever heard of,  what became TurboPascal later was originally known as BLS Pascal. When  this code was ported from Z80 to 8086, and the incredibly successful TurboPascal for DOS was born.  That same compiler codebase was used in the creation of Delphi 1.0 for Windows 3.0 (16 bit), and Delphi 2.0 for Windows 95 (32 bit).    I started using TurboPascal around version 5.0, and remember being very excited when TurboPascal 5.5 came out, which included this new Object Oriented stuff.   I believe I paid less than $100 for TurboPascal 5.5 from my campus computer store, and it came in a very large box, with a lot of very nice manuals.    In the DOS era, paper manuals were an essential programming tool.  Online help on an 80x25 or 80x43 EGA DOS text screen was not much of a "help" to programmers, and I relied heavily on the paper manuals while learning and using the system.

 Borland sold millions of copies of TurboPascal in the DOS era.  So from a humble hobby-computing market, they got big.  What happens when companies succeed financially and start getting bigger?  I guess they hire a lot of people, promote some of them to middle management, and generally bloat out from their humble startup days and into their days of fat.  At microsoft, famously at one point, there were more than 10 levels of middle and product and senior management between each developer and the CEO.   I have no inside information on life at Borland circa 1995 (Delphi 1), or when the Inprise debacle started, during the Del Yocam era, in 1998.  I have heard some tales but I will not repeat them.

Instead I wish to reflect on the simple fact that by renaming yourself and abandoning your constituency, you alienate all your current customers.  There were actions by Borland staffers and corporate leadership prior to 1998 that alienated some DOS and early-Windows-era customers, but the Inprise era is spectacular for the sheer ineptitude and bad timing of the move. As a person who often wonders why Delphi did not achieve more corporate traction than it did,  the later JBuilder-is-the-future fiasco is still second in the list of disasters to the "Abandonment of Borland brand" inspired under Del Yocam's time leading Borland.   On the internet newsgroups,  and at Delphi user groups, the move to the "Inprise" name was met with shock.   Why did the community even care? It's just a name, after all.

No, it wasn't. The "Inprise" name change was basically a message that "We're not that DOS era tools company anymore, and we think we're ready to move into big ticket Enterprise software".   The enterprise software enterprise failed.  Inprise failed. Borland failed.  Later on Borland went chasing after ALM (application lifecycle management) as a new Enterprise era, and abandoned codegear, and Embarcadero picked it up for a song.

So, what is this Enterprise level tools software that every software developer who wants to build enterprise software needs? This is very much still an open question.   Enterprise software development tools, if you will forgive me for answering my own question, are "Snake Oil", pure and simple. Large companies in general need all the same software development tools and functionality that medium and small companies have.  Yes they have the money to buy a high end edition, if that higher edition really helps, and those higher editions exist, and yes people buy them.  I am not saying that nobody buys it.   I'm saying that the tools don't deliver a measurable Enterprise productivity boost that they promise.  In short, I am saying that no high end $5000 development tool provides quite as much inside the box as it promises on the outside of the box and that the claims of "Enterprise" software products often outstrip what they can really deliver.    

 What they have that other companies do not have is (or so we hope) a large pile of cash that they are willing to part with, and additional fear and anxiety that salespeople can trade on, and receive money for for intangible deliverables like "Enterprise readiness" and "Enterprise level functionality", or best of all "Five-Nines" reliability.  

 It's quality sauce, performance and speed as an extra cheese topping, on your mid-market pizza, that makes your Enterprise Pizza.    The word "Enterprise" is still with us, in CodeGear/Embarcadero Delphi land, as the name of an edition of Delphi.

What do the high-SKU Enterprise and Architect editions of Delphi offer me that I would pay for?  Actually, very little. Now in XE4, the new database layer, AnyDAC FireDAC is actually great, and I would almost buy Enterprise or Architect to get it. Almost.

What else?  I don't currently like DataSnap much, but it is definitely the most important and most valuable thing that comes with Delphi Enterprise and Architect.    If Embarcadero could improve DataSnap to the point that people like me want to buy it, that would probably make it worth buying.

What else, else?  Well there's the blobby-gram builder tools, and the code metrics.  Guess what. I think blobby grams are useless, and the code metrics feature is inferior to the $99 Peganza Pascal Analyzer. You've got to do better to earn my dollars for those features.

I really do want to see the Enterprise and Architect editions succeed in the free market and sell lots of copies.  That will do as much to keep Delphi going and growing into the future, as having it become more popular would.   But Delphi is facing a clear and present danger;  New user adoption levels are so low, and the number of publicly findable Delphi jobs is at a deadly near-zero level.  Developers cannot find Delphi jobs, and Delphi employers cannot find Delphi developers.  As the software development manager and team implementation leader at a very small Delphi company, I am painfully aware of both sides of this equation.   I am a developer, and I try to lead a small software team through releases and bug fixing.

The way out of Delphi's current "No Jobs/No Developers" bind, when competing against a free Visual Studio express edition has got to be the opposite direction to the direction that the leaders during the Inprise period at Borland chose.

 I see a considerable pressure coming out of Delphi's product management to drive the dwindling number of Delphi faithful up the curve towards Enterprise and Architect.  I say, most of us are not budging.   Taking away features from Delphi Pro will only hurt Delphi and Embarcadero, terminate Software Assurance agreements and alienate the small shops that still use Delphi.

 What needs to happen is a return to the Borland/DOS era product market and reach.   Somehow Embarcadero needs to find a way to sell 30 million copies of $99 to $399 products, either in one lump sum, or even as an annual $99 rental.  The future of Delphi depends on it.

Was Delphi Starter the right move? I can't say as I don't know the sales and revenue from it, but I can say that it was not enough to make a dent in the NoJobs/NoDevelopers issue.  There needs to be something else done to address the perception that Delphi is a dead end. It's still the best technology out there for building applications.  Unfortunately, it's perceived as a a career-limiting and company-growth -limiting move. That perception needs to be addressed, and changed, with main force.  The cross-platform focus (iOS and then Android) is definitely going to add something to the Delphi toolbox that will attract new people, but something needs to be done to get more developers onto the platform.  A new generation of Delphi developers, these ones should be under 30 instead of graybeards over 40 like me.


  1. This comment has been removed by the author.

  2. Thank you for the long term perspective. I started with Turbo C 1.0 and Turbo Pascal v. 4.0 and remember the buzz that TP 5.5's OOP created and I agree with everything in your post.

    I also see FireMonkey as yet another vehicle of demise for Delphi/Embarcadero. It is what it is not by design, but because Embarcadero took the easy route and purchased FireMonkey from a third party. It will be a maintenance nightmare and always lag behind. Just look at the looming iOS 6 -> 7 implications. Embarcadero failed to learn anything from the success stories of Lazarus/FPC with LCL, wxWidgets and QT (at least from a design/implementation perspective, and ignoring the economics).

    Unfortunately, many of these issues are signs of our times. Big vendors see the level of sopistication that open source and free software has reached. Taken together with cloud-based computing, success of iOS, Google Docs, web based email services, ... they are painting a future with individual users on the cloud for their documents and using rented products such as Office 365 and Adobe CC line (Adobe having killed off CS) for managing them. Meanwhile, corporations are shelling millions for their IT needs (e.g. an individual medical center will pay up to $50,000,000.00 to implement a propritary EHR), probably because they have the money and otherwise lack vision and talent.

    The Turbo Pascal/Delphi history goes back a couple of decades. Those who fail to learn from history are doomed to repeat its mistakes. It needs to be argued that it is entirely our (users') own fault that we have come to this juncture. This is what we paid for, and as long as we continue paying for it, this is what we will get. Maybe it is time for Delphi to go to the ground, and either stay there or rise again to meet today's needs and challenges. If Lazarus could, then so might Delphi too.

    I for one see a bright future for GNU/Linux and OSS. Those of us who correctly and ethically harness its economics will have a share in its future.

    1. I really appreciate this post and I like this very much. I am waiting for new post here and Please keep it up in future.
      License management software

  3. 'It will be a maintenance nightmare and always lag behind. Just look at the looming iOS 6 -> 7 implications.'

    If it's a 'maintenance nightmare' it's because VGScene wasn't well written and the time wasn't taken to rewrite it properly, not because iOS 7 rolls out a new visual 'look'.

    'Embarcadero failed to learn anything from the success stories of Lazarus/FPC with LCL, wxWidgets and QT (at least from a design/implementation perspective, and ignoring the economics).'

    Do you have any LCL, wxWidgets and/or QT iOS apps I can have a look at to see how those frameworks are dealing with the iOS 7 issue? Oh, right... In the LCL's case, the deprecation of Carbon is going to make even OS X problematic in the not-too distant future; in the case of QT, it looks like its iOS support when it does come will have to fake the look and feel as much as FMX (

    Conversely, it is actually possible to overstate FMX's non-nativeness, believe it or not. In particular, its 2D drawing API is pretty good at abstracting a common interface from Direct2D and Quartz that is as easy to use as the VCL's, but much more capable (paths, attributed text, gradients beyond a simple, single function, etc.). Beyond that, EMBT also did thankfully dump the custom ShowMessage/MessageDlg implementation for native wrappers in XE3, though I'd naturally like to see this sort of thing continue - putting a native edit control underneath TEdit and TMemo whould be the no.1 on my list, closely followed by getting rid of the horrible custom popup menu implementation.

    'I for one see a bright future for GNU/Linux'

    Yes, next year has been the year of the Linux desktop for about 15 years now...

    1. I said it is so not by design, but because they went out and just bought something instead of designing it from the ground up. And it will be a maintenance nightmare, especially for users. It is riddled with bugs. Just grab a TMemo, and select some text and see how the text jumps around. And this is with XE4 and latest updates.

      "Do you have any LCL, wxWidgets ..."
      That is precisely the point. There were lessons to be learned. Both in areas of their failure that will be repeated and in their successes that are ignored.

      Linux has an even brighter future because of the proprietary headaches that platform vendors are creating. There is a World-wide hardware manufacturing industry, and there is a capable and free operating system. Soon enough, industry and high-end customers will add 2 and 2 together. Adoption of Linux in the work place will have a downstream effect on the consumer market.

      "Yes, next year has been the year of the Linux desktop for about 15 years now..."
      Yes, and this is the first year that I am running into casual (non-IT staff) users of Ubuntu at work saying it is fast and easy to use.

  4. I think the main problem is that Embarcadero's management does not understand how for example schools work. Of course the school editions are very cheap in comparison to the normal versions. But this does not help because even the few bucks are more than a school has to pay for Visual Studio Express or for Java. And because schools do not have much money they have to choose C# or Java instead of Delphi.

    I know a few teachers who would like to use Delphi. But they can't, just because the school would have to pay for Delphi.

    So it really is a foolish decision not to give Delphi to the schools for free. Embarcadero can't earn much with the school versions, but even this small price is too much for schools. Of course they would have to invest money to give free copies to schools, but it is very little in comparison to the possibilities which would emerge.

    Unfortunately it seems the management has too little imagination to form a better future for Delphi (assuming the best of the possibilities which come to my mind when having a look at this poor management).

    We use Delphi XE4 Enterprise and are on SA. But here in Germany we also have the problem, that we don't find developers...

  5. You show to be unable to understand what enterprise software is as Inprise did. It is not true that large companies use the same software small ones do. Enterprise software needs to be scalable, reliable, secure, manageable and deployable in ways other software isn't. It doesn't matter how many single computers run your software, if it lacks the above requirements, it's not enterprise software. Windows became enterprise software only with Windows 2000, before Active Directory it lacked too many features to be a real enterprise software, no matter how on how many PCs it already run. Excel and Office are not enterprise software, Outlook/Exchange is. Oracle is enterprise software, Firebird is not. Java is a language for enterprise software, Delphi is not, not because the language itself, but because it lacks the frameworks to write and deploy real enterprise software.
    Yocam made the mistake to believe a simple name change and a label on the box were enough, while not adding real enterprise support in Delphi beyond some SQL drivers for enterprise DBs. Datasnap was added in Delphi 3, but since then it was very little upgraded and improved, most of its code is still designed against Win95/NT DCOM. Then they saw that thing called the Internet and tried to make Delphi a web tools - something it could never became. Then there was Linux, then .NET, now iOS and Android. Meanwhile the new Datasnap implementation lacked so many features needed in an enterprise applications (especially security), that it was almost a joke. For years Delphi had not state-of-the-art debugging tools, lacked a profiler (which was available for TP!), and there was no VCS intehration but using third party tools, and even today it's fairly limited. Windows services VCL support was added only in Delphi 4, and it's fairly limited today. A lot of Windows APIs needed to write software working in large deployments are still not integrated within the VCL.
    Inprise never took advantage of the money it spend buying Visigenic, and with time yes, the Enterprise SKU became overprices.
    But Embarcadero doen't really need to sell a cheap tools for small ISVs, because it's not there you really make money today. It has to make the higher end SKUs appealing again, adding real enterprise features.
    We're working on software that is being deployed on over 70,000 machines in a very large company. It has to be managed centrally, and its servers needs to handle that amount of clients, a large percentage of them connected at the same time. We're writing it in Delphi, but we had to overcome too many limitations, because too many needed improvements compared to competitors were never implemented due to lack of focus.
    Turn Delphi in a small tool for simple software, and it will have far less users than today. Turbo Pascal days are over, the IT landscape changed a lot since the '80s and the early '90s. It's what Borland and its other names, and too many small Delphi developers, still refuse to see and understand.

  6. @kmorwath; I know exactly what Enterprise Software is. What I said, which I think you missed, is that Delphi "Enterprise" and "Architect" SKUs do almost nothing to make your job writing software that "is being deployed to over 70,000 machines in a very large company" any easier. It sounds to me like you are saying I'm missing the point, then going on to agree with me that Embarcadero (Codegear, Borland, and Inprise) have not gone on to build DataSnap into a real Enterprise system.

    Anybody remember what Inprise was peddling? Middleware (Corba brokers) that were supposed to make Enterprise software a reality. Seriously over-sold and seriously under-delivered. If the whole Visibroker thing wasn't underwhelming enough, try ECO, and Bold, the next few round of Seriously Over Sold and Under Delivered "Enterprise" development
    technology, which was then unceremoniously yanked from the product, leaving anybody who relied on it high and dry.

    I am not saying that Enterprises (large companies) don't want any extra stuff. Hell, they sure do. But there is no silver bullets, and there ain't no free lunches, and there ain't no commercial enterprise software frameworks worth owning.

    Imagine me looking like Morpheus here, and saying this: "What if I told you that none of that Enterprise stuff can actually deliver what it promises. "

    1. You said enterprise software is "snake oil". It is not. There are several requirements you have to meet that simply don't exist in personal or SMB software.
      Sure, Inprise failed to deliver a real "enterprise" version of Delphi - Embarcadero still thinks that it means a few database drivers and an underpowered Datasnap. But It wasn't the idea to make Delphi grow the mistake - was - and is - its execution.
      Implementing TP was easier, it was a simple compiler and s simple IDE (I'm using it since version 1.0. when it allowed only .COM executables!), and DOS was a simple, single task, single thread OS. There were no networks, or very simple ones, simple needs, simple UIs, very little expectations.
      That era is long gone. It won't be back. IMHO it's very naïve to believe it could be back and Delphi could return to be a $99 tool (but later TP versions were more expensive TP/BP 7.0 was not that cheap) and survive.
      Developers grow as well, and soon they have to tackle more complex challenges and needs, those that didn't exist thirty years ago.
      Turn Delphi into a simpler tool, and what will happen? Good developers will soon outgrow it, and switch to other more professional tools.
      But who would start using a tool they know they have to leave as soon as they have to deliver more complex software? There are plenty of simple tools to write simpler applications - just you don't see them in any real software company. They can sustain some little companies, but not one like Borland was, and Embarcadero should be. Sure. it could stop to play in the Major League and demote itself in a minor one. Just, many of us needs to be players in the Major League, and need tools able to help us. I don't care to spend $5000 for an excellent tool, because it would pay itself soon. I'm much more worried about a $399 tool that can't deliver but the simpler applications. Just one month spent in trying to overcome a tool limitations or bugs costs me about $5000 - the math is simple...

  7. By "Snake Oil" I means someone sells something that claims to do something that it does not actually do. You can criticize $399 software for not doing what you want it to do, and I can criticize $5000 software for not doing what I want it to do, and neither of us is contradicting the other.

    What I would like you to point out, that would falsify my snake-oil idea, is the name of a $5000 Enterprise Software Tool that actually does something that I can't do just as well with Delphi Professional. Again, there is some subjectivity here, in both my claim and yours. I am not claiming to know your world, only mine. And I am claiming that nothing Embarcadero (or anybody else) sells in the $1999 to $5999 range would help ME one bit. Your mileage may vary.

    1. Your words are, actually " Enterprise software, if you will forgive me for answering my own question is "Snake Oil", pure and simple. Large companies in general need all the same software tools and functionality that medium and small companies have." That's very different from saying "Delphi Enterprise has very little to offer for its price". It is not true that large companies "in general" need all the same software used by SMBs. If you're a public company, you may have more regulations to comply with. If you have some certifications, you have more rules to comply. If you have thousand (or ten of thousands , or more) users, you have much more complex systems. And that is true regardless if you use Delphi or not.
      It is true that Borland failed to deliver a real enterprise tool, just overpriced database drivers. But any attempt to deliver a "tool for '80s" is doomed to fail. That doesn't mean Delphi SKU shouldn't be segmented to target SMBs developers as well with cheaper version, but if it doesn't offer an upgrade path to SKUs to deliver software beyond the SMBs needs it's doomed to fail as well, because many developers don't work for SMBs only, and for their whole working life. Many will grow and will move to jobs where they have to be able to develop - and deliver - complex software. They need a tool that allows it. If Delphi can't grow with them, probably they would never start with such a tool to begin with. That's what the advocates of a new, cheap "Turbo Pascal" fail to understand. Delphi has to offer young developers more than a cheap tool - they need a tool to grow with. It it can't grow, there are better choices, and unluckily some are even free...

    2. Would you be happy, kmorwath, if I said, "Enterprise software has a real definition, but has no real instances that satisfy that definition?". That is what "Snake Oil" means. You are arguing semantics, I'm arguing market reality. That whoosh sound is the thing I am saying flying past you without you seeing the distinction between what you are saying and what I am saying. I don't see that we are really fundamentally disagreeing here. I agree with you about everything except where you're telling me what I'm really saying. I am not communicating my point clearly enough to everyone, and as that's my responsibility since I'm the original writer here, I wish I knew how to make that point clearer.

    3. "software has a real definition, but has no real instances that satisfy that definition". Please show me a proof... otherwise it's just FUD. Isn't Exchange enterprise software? Isn't Oracle with its RAC and Exadata machines (and its applications) enterprise software? Isn't Windows 2012, or VMWare vSphere, enterprise software with all their management features and large deploys? Maybe it's just your experience that is too limited?
      Sure, there is bad software and good software there as well, and often in large companies those in charge to buy software have no the background needed to make a good choice, but that has nothing to do with software, but with management.
      Bu trying to assert that Delphi doesn't need to target anything beyond SMBs needs because there is no real software beyond it it's not true and even a bit arrogant. I can't understand why everybody now is trying to destroy Delphi value trying to aim it at small developers needs only. See what is being said about the next releases, powerful features being removed in exchange for nothing. This won't save Delphi nor make it more popular, it will just make it less appealing than it is now.

    4. Hi KMorwath. Again WHOOSH. None of those are Visual Studio, or RAD Studio, or SOFTWARE DEVELOPMENT and PROGRAMMING tools. Please point to me ONE programming tool that YOU think is worth $5000 that programmers like you, should be buying to help them build apps that ship to 70,000 desktops at a big company.

    5. What do you believe Oracle uses to compile and test Oracle for Windows? Delphi and C++ Builder? Or what does VMware uses? Or Microsoft? There are development tools like Visual Studio which are designed to fill the needs of both small teams writing software for SMBs and large ones writing large and complex software systems, and those like Delphi and C++ Builder that think that an "Enterprise" label is enough, or think that removing pointers from a native compiled language is a good idea. There are compiler that delivers state-of-the-art code - for the latest processors - and other that for years delivered 386 code only. There are RTL that are large and optimized for heavy tasks, and others that are written to minimize efforts. There are tools that comes with excellent debugging and profiling tools, other that has to rely on third parties to output a stack trace, or to write a decent memory manager. There are tools that come with a good help, and those that don't. Visual Studio Premium costs $6000, but look what it brings to you. That's what we have to buy besides Delphi, to cover all of our needs. If you develop software for SMBs only probably you don't spend that much and just buy the Professional and that's ok, but VS is designed to go far beyond that - and for some tasks you maybe also use Intel compilers and tools - if you really need extreme performance. Unluckily these are designed to integrate with VS, not RAD Studio... again, it looks your experience is really limited when it comes to enterprise software. Nothing wrong with that, but it's useless to keep on firing on something you know very little. It doesn't help you to assert your point, it just shows your assertions are based on wrong assumptions.

  8. If you can read Chinese... some interesting stories about the old Borland:

    I personally think Delphi need a FREE edition asap... Otherwise the beginners are mostly forced to use the free ones... VS Express, Lazarus, etc...

  9. The problem Embarcadero are facing is that the IDE is very tired, lacks functionality found in more up to date IDE's like Visual Studio and Eclipse adn they don't seem to want to advance it.

    If Embarcadero were serious about firemonkey, they'd rewrite the IDE in FMX and make it cross platform.

    By adding more platforms, they are increasing the maintenance they require for each release (look at the FMX regressions in Desktop apps due to iOS work) and they don't seem to have enough resources to solve this at present.

    1. This is absolutely true and has been said before. The real test of any software toolchain/framework's maturity is its use in implementing itself. FireMonkey is nowhere near that mark. If Embarcadero could pull it off, it would invariably end up fixing FireMonkey during the process and make it ready for prime time. Until then, FireMonkey will not be ready for general production use. I really wish more users would demand this, as it would be the surest path to FireMonkey's maturity and reliability.

  10. I started as a hardware guy, a logic designer. From there, I moved into Z80 assembly language. I still have my TP 1.0 manual (Z80 CP/M version). Although it is easy *now* to talk about how simple TP 1.0 was, you must bear in mind that a the time, the conventional wisdom was that a) you couldn't implement a high quality compiler for an 8-bit target and b) you couldn't implement any sort of real compiler on an 8-bit host. Whitesmith's C took many steps and about 4 minutes to compile, link, and load Hello World -- if it didn't crash.

    TP 1.0 was rightfully acknowledged as a real game changer. I used it, and used it on the Z80 in preference to the PC. Once I had written the code on my Z80 (where I had a much better and faster environment than that of a 4.7MHz PC), I simply recompiled on the PC.

    Philippe Kahn was a polarizing individual with real vision. He also was a showman and a real marketing person. On his watch, Borland grew at a very impressive rate, and made money sufficient to make the big SV campus a reality -- on $50 and $100 products. Love him or hate him (and I won't claim he was lovable, even at a distance), Kahn kept things moving, and made me *want* to buy Borland tools, even those for which I had no real need. I wanted to support the company, as it was so much better than any of the alternatives.

    With TP 4.0 came the first really great manuals from Borland. The language manual was the thickest software book I had seen at the time, and I read it in a two day marathon. It was superb, and so was the compiler.

    Along came Sprint, at a time when I was wrestling with Word, fighting to get it to do as I wished, and with no regrets, I moved my manual to Sprint, in a long weekend. That began a love affair about which I am still wistful. Sprint was to this day the most productive writing tool I have used.

    After the board sent Kahn packing, things began to decline. Regardless of name, they have never since had anything approaching successful marketing. And there has not been much vision in evidence in the upper management.

    I was privileged to be a late participant in beta work before Delphi 1 was released. (Hey, it's been 18 years -- sue me for violating that NDA.) It was a revelation as nothing had been since my first exposure to TP.

    These days, I am on DXE, and see no reason to spend for a newer release. Bugs are my daily fare, and the bugs I know are at least less expensive than finding workarounds for those I do not know. Although my license is for Enterprise, I would have difficulty making a case to upgrade at that level. Probably drop back to Pro, if I do upgrade.

    I look now at Oxygene, and am likely to do new work there. The client I have (yes, just one) for Delphi work was found by pure chance, and I doubt I will find another. I still love the language, but the tool stands increasingly between me ant the language as a barrier.

    Meanwhile, the powers that be declare that those of us who haunt the NGs and other fora are of no significance, and that there is no money to be made in fixing the thousands of significant defects. And that, gentlemen, is the road to dusty death.

    1. In the old days Borland was not a development tools company also. They did a lot of money from Sidekick, Quattro (Lotus sued Borland for it, not TP...), and Paradox. But let's look at TP history, at least in the DOS world. TP 1-3 were fairly limited. They were fast, but only output .COM files. That meant one single 64k code segment, one single 64k data segment. The heap could be used at first only with Mark and Release procedures, which didn't allow for random allocations. It wasn't until TP4 that it became a real DOS development tool able to output .EXE files (before you had to swap in and out code segments using Chain() and .CHN files, or buy the TurboPower linker...) - still no debugger. Meanwhile prices were increasing. Then came 5.0 and 5.5 that added a debugger and OOP. Still, it has no DOS extenders, many C compilers could use them - meaning it was still limited to 640k on 386 and 486 machines which had several MBs of RAM. TP 6 added a UI library (TurboVision), but only BP7 came with a DOS extender when it was already too late, Windows had already taken off. Prices were much higher than the original $49 and $99, people like to forget it. And still then, TP was often late to release some needed features for some real development needs.
      Meanwhile Borland had made the huge mistake of acquiring dBase, took too much to port its flagship applications to Windows (Quattro) or ported it the wrong way (Paradox) while Windows killed the TSR app market. The attempt to play against MS in the office app space put Borland squarely in MS sight - and it didn't take long to be the defeated one. Many of these mistakes were Khan's, including the beautiful but expensive building.
      In a few years VB eclipsed TP/Delphi, Excel Quattro, and Access dBase/Paradox. Borland C++ too was updated too slowly, and lost its place in Windows development to VS. Borland found itself without appealing products but Delphi, and even with it delivered a 16 bit product the year Windows 95 moved people to 32 bit computing, and then updated it slower and slower... a release each year is useless if real improvements takes years to be implemented. Several useless web frameworks, the BDE was deprecated by the already deprecated dbExpress, Datasnap was introduced and then forgotten, then rewritten using dbExpress (in turn deprecated!), then Linux was the future, no, it is .NET, sorry we're wrong, it's native, but multiplatform with a UI framework that has more bugs than Delphi 2005 (we've fixed some in 2006 but you need to buy 2007 is you need a working version...) Unicode? 64 bit? You could wait, couldn't you? Look, we've a nre toy, iOS... ooops, we've not yet released it fully that Android is boomimg... wait... we've an Android tool in development, in two or three versions it will be usable...
      Borland/Inprise/Borland/CodeGear/Embarcadero has one big issue: there are people still there after all those huge mistakes, and no one gives them the deserved pink slip. Meanwhile a lot of good people went away.

  11. I've used Delphi 3 and Delphi 5, back in the day, and a bit of C++ Builder 5, too. Then, I've spent a few years away from a technical role, and about a year ago I've decided to return. I looked at 3 alternatives, at the time: C#, C++, and Delphi.

    For C#, I had VC# Express and MonoDevelop.

    For C++, I had Qt Creator, or, if I wanted to jump through some hoops, CodeBlocks + wxWidgets. Of course, there's also VC++ Express, although native C++ has no GUI builder.

    As a hobbyist, I couldn't justify the cost of either Delphi or C++ Builder, even the Starter editions, cheap though these may be. Ergo, on top of the usual language wars ("Pascal is dead/a kiddy language/etc"), and the perception of career-limiting moves, Delphi places an additional barrier (cost) right at the entry point.

    And if you lose people at the entry point, it doesn't matter how many multi-platform/enterprise bells and whistles you have, because those people won't stick around to find out.

  12. I heard once that David Intersimone deeply regretted letting dBase get out of hand.

    I recall that at one time Borland owned both contenders in the xBase world, those being dBase, and Foxpro.

    I recall also (after running it on our mini) that Foxpro for Unix ended up in Microsoft's hands, whereupon they soon squeezed it's neck until it died. At the time, we had a realtime order processing app that served 100 terminals, 200 printers, with a database having 600,000 customers and 40,000 items. The Mini was an ALR rackmount with a (dual) 486 CPU and 256 MB of Ram. What made it so fast was the AMI megaraid disk channel. After installing it, we removed one of the 486 CPU's and still had a 20% increase in speed. The entire app was written in Foxpro, and it ran realtime no problem. Once in awhile it would blow an index, but reindexing the entire database took just a few seconds.

    We had to retire the system as we could no longer legally purchase Foxpro for Unix.

  13. Wait ... Maybe that was Ashton Tate who owned both dBase and Foxpro. It's been awhile....

  14. Just for fun, while uneployed, I downloaded the RemObjects Oxygene command line compiler for .Net, 64bit, .Net 4 I think it was.

    I wrote a single form front end for a database app, complete with multi-threaded indicator widgets for various record states as the user scrolled through the grid.

    I sensed then that RemObjects was breaking Pascal in favor of making it more cross-compatible with C# as a target. Like breaking the constructor model, which is implemented using frankencode in c#.

    It seems that Microsoft, after finally getting to a fairly stable point with Windows 7, is throwing all away in favor of, what ? Windows 8 ?

    My last Delphi purchase was Rad Studio 10 Pro, which was OK I guess, but way too expensive.