Your reviewer found some newsgroup gems:
Disturbing Trend:
"I've been searching for a new gig for several weeks now and have interviewed with several companies. Every company I've interviewed with has intentions of moving away from Delphi. This is a very disturbing trend.
When I ask why, invariably the perception is that Delphi is old and out dated. A company today told me that it was going to C# because "upgrading its Delphi 5 app to a later version would be too much trouble". It is willing to rewrite its software in another language rather than upgrade!
How do we change this perception?"
Lajos writes:
I don't think so. At the moment in the USA I'm afraid it's more hard to find any Delphi job. I'm looking for 4 month without any luck.
In some job postings there is a Delphi as a language they need a developer with a Delphi skill enough just to make some changes. But most of time Delphi is just a legacy product they did and moved to C#.
Mr David writes:
What makes you think the perception is wrong?
If you look at history for this past decade, the Borland (Delphi/C++ Builder VCL products) have lagged behind their major competitor, Microsoft, by months, often years.
They 'owned' the C++ market prior to C++ Builder, but then gave away compatibility (and the ability to write drivers, etc.) when they made the VCL switch to C++ Builder. They still haven't made it possible use C++ Builder stuff in Delphi, which means that there C++ product is essentially a 'stub' product.
The whole 'Delphi.NET' stuff showed how impossible it was going to be to keep pace with MS, especially on their own turf. It finally became obvious even to Borland, and they terminated it.
The fact that they are so far behind on the 64-bit curve shows that they are continuing that trend, and the fact that documentation is still so poor (let alone in comparison to the MS offerings) means that there is no way to get new folks reasonably involved in the product.
If I were a software manager, looking at a completely subjective breakdown of doing a re-write of the software (for any of several ancillary reasons, such as new features of the operating systems, larger memory needs, new GUI features, etc.), then the evaluation of doing a re-write in C# vs. doing an upgrade/add-on in Delphi, looking at who I think will be keeping up with technology for the NEXT decade, the record of reliability/support for the product, etc., I'd be hard-pressed to argue that a company should stay with Delphi.
Embarcadero really hasn't done much to fix this, either, and I do understand that they're living with the baggage that Borland left behind, but that is part of what they bought when they bought the product line.
Here's one aspect of how things could have been 'better' over the years:
-- I don't know how much "catch-up" they can do from this point, but hopefully you'll get the drift.
1. Embarcadero should be their own third-party vendor (at least for many things). Folks argue that they can't possibly lower the price of the product, they need the revenue stream. I would argue that I spend as much, or more, on third-party tools as I do on the basic product itself. With the loss of TurboPower, for example, there was a market for (at least maintaining/updating) that type of product line. I have/use the TMS line of products, but the documentation is HORRID (arguably worse than Delphi, which is saying something). I use madExcept, some scheduling tools, charting tools, etc. If Embarcadero LOWERED the price of the main tool, and charged for some 'additional modules' (i.e., third-party add-ons), that would be a significant revenue stream.
2. Documentation. This means getting some books out, or re-issuing some of the old ones (buy the @^!*# rights from some of the authors, for heavens' sake, and re-issue them as free PDF files, if nothing else). Get the help system working, even if it means doing one from scratch. Get the samples updated/working, etc. Do a WHOLE LOT of white papers, 'how to' guides, upgrading guides, etc.
3. Do better with the quality assurance/beta tests. Lots of ways this can be handled, but the current methods simply aren't working very well. Just look at how poorly the 'update' functions work in your OWN PRODUCT -- you can't even tell if product is current, you often have to manually download updates, installation procedures fail, etc.
4. Get rid of the 'product activation' crap, and go back to the simpler methods of licensing. I'm not going to re-argue the whole activation/licensing thing right now, but I am absolutely convinced that this stuff provides no real benefit overall for most software. I, and most folks I know, will actively shy away from using products that require this, or finding methods to subvert it. It just creates problems for the 'honest' user, and doesn't really discourage the dishonest ones for more than five minutes. That's my short list...
:)
There's person called Largo which sounds uncannily similar to Embarcadero whose objective seems to milk Delphi developers of their hard earned money
