More and more in the past weeks while working with Delphi on the next release of out main applications, I started to ask myself if Delphi can still be considered an "enterprise" level development tool. Codegear's site says the "enterprise" features are:
- Database server connectivity to InterBase, Blackfish SQL, MySQL, Microsoft SQL Server, Oracle, DB2, Informix and Sybase
- DataSnap multi-tier database application development
- Blackfish SQL deployment on systems with 5 users, 2GB database size
- VCL for the Web with no connection limit
- Additional UML modeling capabilities
Can in 2009 non-local database connectivity to SQL servers still be considered an "enterprise" level feature? Back in 1995 when desktop database meant only file based database like dBase or Paradox maybe, but today when there are desktop versions of high-end SQL database like SQL Server Express or Oracle Express?
And the Blackfish database? It could be barely a BDE/Paradox replacement - but does a managed database make sense for a Windows-only deployment? It made sense when it was a Java database (deploy it wherever Java runs), and anyway both SQL Server Express and Oracle XE have not Blackfish limits (only CPU/RAM/database size). A native, embedded database would be a better offer - and that's why many are already using Firebird embedded - now Interbase followed Firebird, let's see if Delphi gets rid of the "database no one needed"™
And then a VCL for the Web with "no limits" (sic!) . That's because the one in the Pro editions has a five connection limit, making it a trial, not a feature. Again, does it make sense in 2009, when every developer can easily get all the Internet "power" he needs with no connection limits, simply using Apache and PHP, Python or Ruby? Is web development today an "enterprise" feature, when even the small shop has its own web site and web applications?
Actually, the only real enterprise level features would be the ability to develop more complex, distributed applications, and the integrations of tools to allow development teams to work together easily.
When Datasnap was introduced in Delphi 3.0 (1997), it was ahead of its time. Unluckily, in more than ten year little was done to improve and build upon it, and its advanced features was often very little documented. It was too tied to DCOM, yet while DCOM improved, Datasnap is still at a Windows 95/NT4 level. For example, it does not allow to connect with a different identity, or set per process DCOM security instead of setting machine wide permission via dcomcnfg.exe. Yes, something could be done, but it requires pure DCOM programming - a complex task for most programmers. Moreover, many important bugs were never fixed (see qc #8814 for an example).
After an attempt to make it work over SOAP - and SOAP is another technology Delphi started to exploit version 6, just to enter later the "Borland/Codegear unfinished" limbo, lacking support for later standards, and having interoperability issues. Again, how can Codegear dub a tool "enteprise" when it has issue to work with others? I know it's not a Delphi fault in itself, it's lack of commitment and development - but users find themselves in a quagmire of half-cooked implementations.
The last attempt, Datasnap 2009, is a strange attempt to build a JSON RPC model built over the dbExpress transport layer. Although it removed DCOM, in its first iteration it looks too much like a way to call remote functions as if they were database "stored procedures" (set params, call, read params), in many ways a step backward from interfaces, type checking and early binding DCOM allows. Maybe good for some applications, but dreadful for more complex ones - and when properly used DCOM offers a lot in authentication, authorization, data integrity and security. All features "enterprise level" applications needs. Meanwhile Microsoft rolled out its Windows Communication Foundation framework, that offers much more than Datasnap, for example queued messages over Microsoft Message Queuing - persistent/transactional queues are very often used in "enterprise" applications.
Somewhat along Datasnap line moved Bold, first added, then moved to .NET, then the company was splitted out, and then? An OPF could have been an enterprise feature - again Delphi was an early adopter just to be left behind.
The other "enterprise" feature, the teamwork concept, is now made of only of some UML modelling capabilities - but among the options, this is the less useful. Delphi lacks, for example, any integration with version control systems, even free ones like CVS or Subversion. At least the Eclipse-based Jbuilder has it.
In the old days there was an attempt to integrate PVCS, later when Borland bought Startbase StarTeam, Together and Caliber were somewhat integrated - removing ModelMaker introduced in Delphi 7 - now only the UML part is left, but I'd wonder if any real UML developer used it.
Another area an "enterprise" development tool could cover could be profiling/optimization to allow for better scalability, but again Borland and then Codegear never thought about it in Delphi (while in JBuilder something was done). Add the lack of a 64 bit compiler for some time yet, while many server are now running 64-bit Windows, and the picture is complete.
What makes it worse is that Codegear still looks to have still the wrong people in the wrong place. Both Intersimone and Hodges may be Delphi enthusiasts, but they look unable to drive Delphi development and marketing in the right direction. The 1995 mindset is still the rule in Scotts Valley.
Both the Professional and Enterprise versions look to have the wrong feature set and price. Pro users lacks the connectivity and Internet features in a world dominated by SQL databases and remote applications, while Enterprise users for a much bigger price get very few real "enterprise" features
Is Delphi still an enterprise level development tool, or is just an overpriced tool that lost too many chances to deliver what it promised?